Cloud AI image generators bill per image and cap what you can generate, but a growing number of developers are moving generation back onto their own hardware. InvokeAI 6.14.2, released in September 2026 and listed as the current build in the InvokeAI Documentation, ships official support for FLUX.2 [klein], FLUX.2 Dev, and Stable Diffusion 3.5 Large/Turbo, among the strongest open-weight image models available this year. This tutorial walks through installing InvokeAI, loading both model families, and running production-quality local generation on a single consumer GPU, with no per-image fees and no API key required. For broader context on where FLUX.2 and SD 3.5 sit among the current generation of AI models, see this site’s 2026 AI models overview.
Unlike ComfyUI’s node-graph interface, InvokeAI ships a polished, form-based UI plus a built-in Model Manager that handles downloads, quantization variants, and license gating for you. That makes it a faster on-ramp for engineers who want local FLUX.2 or SD 3.5 generation without wiring up a node graph first. By the end of this guide you will have a working local install, both model families loaded, a batch generation script, and a troubleshooting checklist for the errors that trip up most first-time installs.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What you’ll build and why local image generation matters in 2026
By the end of this tutorial you’ll have a fully functional local image generation stack running on your own machine: InvokeAI v6.14.1 or newer, FLUX.2 [klein] 4B for fast, low-VRAM generation, FLUX.2 [klein] 9B for higher fidelity, and Stable Diffusion 3.5 Large plus its Turbo variant for quick iteration. All four models run through the same web UI, and none of them touch a third-party API.
The economics are the real driver here. A single Nano Banana 2 or Seedream 5.0 API call currently runs somewhere between $0.035 and $0.07 per image depending on the provider, which adds up fast for anyone iterating on hundreds of prompts a day or running an automated content pipeline. Once FLUX.2 [klein] or SD 3.5 is installed locally, the marginal cost per image drops to electricity, and there’s no rate limit throttling a batch job. The tradeoff is upfront setup time and the need for a GPU with enough VRAM, which this guide addresses directly.
There’s also a licensing angle worth flagging up front. FLUX.2 [klein] 4B ships under an Apache 2.0 license from Black Forest Labs, meaning it’s usable commercially without restriction. The larger FLUX.2 [klein] 9B variant carries a more restrictive non-commercial license in some repository builds, so always check the license tab on the specific Hugging Face repo before using outputs commercially. Stable Diffusion 3.5 Large and Large Turbo run under the Stability AI Community License, which permits commercial use for individuals or organizations with under $1 million in trailing annual revenue.
Why InvokeAI, FLUX.2, and SD 3.5 specifically
The image-model landscape shifted meaningfully in the first half of 2026 and kept expanding through the back half of the year. Black Forest Labs’ FLUX.2 family replaced the original FLUX.1 line as the reference open-weight text-to-image model, and the [klein] variants specifically target consumer hardware rather than data-center GPUs. Stability AI’s Stable Diffusion 3.5 Large and Large Turbo, meanwhile, remain the most widely deployed SD-family checkpoints for local generation, and both now install cleanly through InvokeAI’s Model Manager rather than requiring manual config file edits the way earlier SD3 previews did. InvokeAI 6.14.0, released in August 2026, widened that catalog further by adding support for Ideogram 4 alongside Krea.2-Turbo and Krea.2-Raw, giving the Model Manager a noticeably broader spread of open and licensed checkpoints to choose from.
FLUX.2 uses a rectified-flow transformer architecture paired with a dedicated text encoder rather than relying solely on CLIP-style conditioning, which is why the model needs its own VAE and encoder files rather than reusing the ones bundled with SD checkpoints. That architectural difference is also why FLUX.2 tends to follow plain-language prompts more literally than SD-family models, which still respond strongly to keyword-weighted, comma-separated prompt styles inherited from the SD 1.5 era. Knowing this upfront changes how you should write prompts for each model, a distinction covered in Step 6.
InvokeAI itself has repositioned over the past year from a fork of the original Stable Diffusion reference implementation into a dedicated production tool, with a canvas-based compositing workspace, a REST API for automation, and now first-class support for both model families covered in this tutorial. The August 2026 6.14.0 release pushed that repositioning further still, adding native multi-GPU support, native Intel XPU acceleration for non-NVIDIA cards, and even video generation through Wan 2.2, moving InvokeAI well beyond a still-image-only tool. The result is that you no longer need to hand-edit YAML config files or manually place checkpoint files into specific folders, the workflow that made early local Stable Diffusion setups so unforgiving for newcomers.
Prerequisites: hardware, software, and account requirements
Before installing anything, confirm your machine meets the following baseline. InvokeAI’s Invoke Launcher handles most dependency management automatically, but the underlying models still need real VRAM and disk space.
| Requirement | Minimum | Recommended |
|---|---|---|
| GPU | NVIDIA RTX 3060, 12GB VRAM | NVIDIA RTX 4070 or newer, 12GB+ VRAM |
| System RAM | 16GB | 32GB |
| Disk space free | 30GB | 100GB (for both model families plus VAEs and text encoders) |
| OS | Windows 10/11, macOS 13+, Ubuntu 22.04+ | Windows 11 or Ubuntu 24.04 |
| Python (auto-managed by launcher) | 3.10 | 3.11 |
| CUDA (NVIDIA only) | CUDA 12.1 | CUDA 12.4+ |
| InvokeAI version | v6.12.0 | v6.14.1 or newer |
Apple Silicon Macs (M1 through M4) are supported through Metal Performance Shaders, though generation on FLUX.2 and SD 3.5 will run noticeably slower than on a discrete NVIDIA GPU. If you’re on an 8GB unified-memory Mac, stick to the FLUX.2 [klein] 4B quantized build rather than SD 3.5 Large.
You’ll also need a free Hugging Face account and an access token, since both FLUX.2 [klein] 9B and Stable Diffusion 3.5 gate downloads behind license acceptance. Create the token at huggingface.co/settings/tokens with “read” permissions before starting Step 4.
Step 1: Install the Invoke Launcher
The Invoke Launcher is now the officially recommended installation path for InvokeAI, replacing the older manual pip workflow for most users. It bundles a known-good Python version, manages your CUDA/PyTorch pairing automatically, and gives you one-click updates going forward.
Download the launcher for your OS from the official InvokeAI releases page, then run the installer. On Windows, this is a standard .exe installer; on macOS, drag the app into Applications; on Linux, you’ll extract an AppImage or run the provided install script.
Once installed, open Invoke Launcher and click “Install” to fetch the latest InvokeAI build. The launcher will download and configure a self-contained Python environment, which avoids the version conflicts that plagued manual installs in earlier InvokeAI releases.
Step 2: Manual install via pip (advanced users only)
If you need a headless server install, or you’re deploying InvokeAI inside a Docker container or a remote GPU box without a desktop environment, skip the launcher and install via pip directly. This route requires you to match your PyTorch build to your installed CUDA version manually, which is the single most common source of install failures.
# Create and activate an isolated virtual environment
python -m venv invoke-env
source invoke-env/bin/activate # Linux/macOS
invoke-env\Scripts\activate # Windows PowerShell
# Confirm your CUDA-compatible PyTorch build first (adjust cu124 to match your driver)
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu124
# Install InvokeAI itself, pinned to a known-working release
pip install "invokeai==6.14.1"
# Launch the web server
invokeai-webOnce the server starts, it prints a local URL, typically http://127.0.0.1:9090. Open that in a browser to reach the same UI the desktop launcher provides. If you’re running on a remote server, bind to 0.0.0.0 and tunnel or open the port through your firewall rules, not by disabling authentication.
Step 3: Tour the InvokeAI interface and Model Manager
On first launch, InvokeAI opens to the Generation canvas, but the panel you’ll use most in this tutorial is the Model Manager, accessed via the cube icon in the bottom-left navigation rail. The Model Manager has three install paths worth understanding before you download anything:
- Starter Models – curated one-click bundles, including a FLUX.2 [klein] 4B pack that grabs the quantized main model, VAE, and text encoder together.
- HuggingFace – direct repo installs using your HF token, required for gated models like SD 3.5 and FLUX.2 [klein] 9B.
- URL or Local Path – for models you’ve already downloaded manually, using the “copy as path” trick on the model file.
Add your Hugging Face token now under Model Manager settings so gated downloads don’t fail partway through Step 4 and Step 5.
Step 4: Install FLUX.2 [klein] 4B and 9B
Open the Starter Models tab and locate the FLUX.2 [klein] entry. Installing the bundle downloads three separate files: the quantized 4B GGUF main model (roughly 5GB), a dedicated VAE, and a quantized Qwen3 text encoder used specifically by FLUX.2’s conditioning pipeline. Together these total under 7GB, which is why the 4B variant is positioned as the low-VRAM-friendly option.
The 9B variant is roughly double the parameter count and isn’t offered as a one-click starter bundle in current InvokeAI builds. Install it through the HuggingFace tab instead, pasting the model repo path directly:
# In Model Manager > HuggingFace tab, paste the repo ID:
black-forest-labs/FLUX.2-klein-9B
# Then repeat for the matching VAE and text encoder if not bundled:
black-forest-labs/FLUX.2-VAEAfter both models finish downloading, go to the Generation panel, select “FLUX.2 Klein 4B (GGUF Q4)” as your main model, then open the Advanced section and confirm the matching VAE and text encoder are selected. InvokeAI displays a warning banner on your first generation attempt if these are mismatched, which is the most common reason a first FLUX.2 render comes out as noise.
Step 5: Install Stable Diffusion 3.5 Large and Large Turbo
Stable Diffusion 3.5 isn’t in the Starter Models list by default in most InvokeAI builds, so you’ll pull it through the HuggingFace tab. Both variants live under Stability AI’s official Hugging Face organization.
# SD 3.5 Large - highest fidelity, slower generation
stabilityai/stable-diffusion-3.5-large
# SD 3.5 Large Turbo - distilled for fewer steps, faster iteration
stabilityai/stable-diffusion-3.5-large-turboYou’ll be prompted to accept Stability AI’s Community License on the Hugging Face model page itself before the download in InvokeAI will succeed – this is a one-time click on huggingface.co, not something you configure inside InvokeAI. If you skip this step, the download in the Model Manager fails with a permissions error rather than a clear license message, which is a frequent point of confusion for first-time users.
Once both variants are installed, switch between them from the model dropdown on the Generation panel. Large is the better default for final output; Turbo is meant for rapid prompt iteration where you’re testing composition and want a result in a few seconds rather than tens of seconds.
Step 6: Generate your first FLUX.2 image
With FLUX.2 [klein] 4B selected as the main model and its VAE/text encoder set correctly, type a prompt into the Positive Prompt field. FLUX.2 responds well to plain descriptive sentences rather than heavily weighted keyword strings, a departure from older SD 1.5-era prompting conventions.
Example prompt: “A weathered lighthouse on a rocky coastline at dawn, soft golden light, photorealistic, shot on 35mm film.” Set steps to 20-28 for FLUX.2 [klein] 4B, guidance scale around 3.5-4.5 (FLUX models generally want lower guidance than SD-family models), and resolution to 1024×1024 for your first test. Click Invoke.
On an RTX 4070 with 12GB VRAM, expect roughly 2-5 seconds per image at this resolution and step count. On an RTX 4060 (8GB), the same settings typically land in the 6-12 second range, still well within the range of an interactive workflow rather than a batch job.
If the first image looks washed out or oversaturated, drop guidance scale by half a point rather than adding negative prompt terms, since FLUX.2 handles negative conditioning differently than SD-family models and negative prompts often have little to no effect. If composition feels too literal or flat, add a stylistic qualifier like “cinematic composition” or “dramatic side lighting” directly into the positive prompt rather than relying on a separate style field, since FLUX.2 does not expose one.
Prompting differences: FLUX.2 vs Stable Diffusion 3.5
Because FLUX.2 and SD 3.5 use different text-conditioning pipelines, the same prompt can produce noticeably different results across the two. FLUX.2’s Qwen3-based text encoder handles long, natural-language sentences well and tends to ignore excessive comma-separated keyword stacking, so a prompt like “photo of a red bicycle leaning against a brick wall in autumn, shot with a 50mm lens, shallow depth of field” performs better than a keyword list. SD 3.5, by contrast, still rewards a hybrid approach: a natural-language subject description followed by comma-separated technical and style modifiers, a convention carried over from the SD1.5 and SDXL era. When switching between the two models in the same session, expect to rewrite prompts rather than reuse them verbatim if you want consistent results.
Step 7: Batch generation with the InvokeAI Python API
For automated pipelines, InvokeAI exposes a REST API on the same local port the web UI runs on. This lets you script batch generation without touching the browser, which matters if you’re feeding generated images into a downstream process like a content pipeline or a dataset build.
import requests
import time
INVOKE_URL = "http://127.0.0.1:9090"
prompts = [
"A minimalist workspace with a laptop and coffee, morning light",
"An aerial view of a terraced rice field at sunset",
"A vintage film camera resting on a wooden table, macro shot",
]
for prompt in prompts:
payload = {
"prompt": prompt,
"model": "flux2-klein-4b-q4",
"steps": 24,
"guidance_scale": 4.0,
"width": 1024,
"height": 1024,
}
resp = requests.post(f"{INVOKE_URL}/api/v1/queue/default/enqueue_batch", json=payload)
print(prompt, "->", resp.status_code)
time.sleep(1) # avoid flooding the local queueNote that InvokeAI’s exact REST payload schema can shift between minor versions, so check the built-in Swagger docs at http://127.0.0.1:9090/docs on your installed version before wiring this into a production script.
Step 8: Upscaling and refining outputs
InvokeAI’s built-in high-resolution fix and img2img refinement pass let you take a 1024×1024 FLUX.2 draft and push it to a cleaner, higher-detail final render. Right-click any generated image in the gallery and select “Send to Image to Image,” then reduce denoising strength to somewhere between 0.35 and 0.5 to preserve composition while adding detail. Push the output resolution up to 1536×1536 or 2048×2048 in this second pass rather than generating directly at that size, since native high-resolution generation on FLUX.2 or SD 3.5 tends to duplicate subjects or produce compositional artifacts.
For dedicated upscaling beyond InvokeAI’s built-in pass, InvokeAI’s node editor also supports chaining in a standalone upscaler model such as a 4x ESRGAN variant, run as a final post-processing step after the img2img refinement. This two-stage approach, generate at native resolution, refine with img2img, then upscale with a dedicated model, produces noticeably cleaner results than pushing any single stage to do all the work, particularly for text and fine detail like jewelry, typography on packaging, or architectural line work.
Step 9: Managing VRAM across multiple models
If you’re running FLUX.2 [klein] and SD 3.5 side by side on the same GPU, InvokeAI’s model cache will hold multiple models in VRAM simultaneously by default, which can trigger out-of-memory errors on 8-12GB cards. Under Settings, reduce the “Models to cache in VRAM” value to 1 if you’re switching between model families frequently and hitting memory pressure, at the cost of a short reload delay each time you switch.
Step 10: Setting up LoRAs for style consistency
Both FLUX.2 [klein] and SD 3.5 support LoRA adapters for locking in a consistent character, product, or art style across a generation run. Install LoRA files through the same Model Manager URL/Local Path tab, then attach them from the Generation panel’s LoRA section with a weight typically between 0.6 and 1.0. If you need to train your own LoRA rather than use a pre-trained one, that process is covered step by step in this site’s guide to training a custom AI image LoRA.
Step 11: Automating the pipeline with scheduled jobs
Once your batch script from Step 7 is stable, wrap it in a cron job (Linux/macOS) or Task Scheduler entry (Windows) to run generation jobs on a schedule, such as nightly content refreshes. Keep the InvokeAI server itself running as a background service rather than the desktop launcher, since the launcher’s GUI process isn’t designed for headless, always-on operation.
When scheduling batch jobs, stagger start times if you’re running more than one prompt queue against the same GPU, since InvokeAI processes its queue sequentially by default and simultaneous external scripts hitting the API at the same moment will simply queue up rather than run in parallel. This is a feature, not a bug, since parallel generation on a single GPU would just split available VRAM and slow both jobs down anyway.
Using ControlNet-style conditioning for consistent layouts
Both FLUX.2 and SD 3.5 support conditioning inputs beyond a text prompt, such as depth maps, edge maps, or a reference pose, through InvokeAI’s Control Layers panel. This matters for any workflow where composition needs to stay fixed across a batch, for example generating the same product shot in ten different lighting styles, or matching a specific camera angle across a set of marketing images. Add a Control Layer from the Generation panel, upload a reference image, select the conditioning type (depth, edges, or pose), and set its weight between 0.4 and 0.8 depending on how strictly you want the output to follow the reference versus how much creative freedom you want to leave the model. Lower weights are generally safer for FLUX.2, which can produce compositional artifacts if conditioning weight is pushed too high alongside its already-literal prompt following.
# Linux systemd service example for headless InvokeAI
[Unit]
Description=InvokeAI Server
After=network.target
[Service]
User=invokeai
WorkingDirectory=/home/invokeai/invoke-env
ExecStart=/home/invokeai/invoke-env/bin/invokeai-web
Restart=on-failure
[Install]
WantedBy=multi-user.targetStep 12: Updating InvokeAI and your models
Check for updates through the Invoke Launcher’s “Update” button, which handles version bumps without wiping your installed models or settings. As of this writing, InvokeAI 6.14.2, released in September 2026 with a round of bug fixes and minor features on top of 6.14.1, is the current build listed in the InvokeAI Documentation, and its PyPI wheel comes in at a lightweight 13.0 MB. If you installed manually via pip, update with pip install –upgrade invokeai inside your virtual environment. Model files themselves rarely need re-downloading unless Black Forest Labs or Stability AI publishes a revised checkpoint, which is announced on the respective Hugging Face model cards.
FLUX.2 [klein] vs Stable Diffusion 3.5: which one to use
Neither model is a strict upgrade over the other; they trade off differently depending on your hardware and use case.
| Factor | FLUX.2 [klein] 4B | FLUX.2 [klein] 9B | SD 3.5 Large | SD 3.5 Large Turbo |
|---|---|---|---|---|
| Approx. download size | ~7GB (with VAE/encoder) | ~14-18GB | ~16GB | ~16GB |
| Minimum usable VRAM | 6GB | 10-12GB | 10-12GB | 8GB |
| Typical steps | 20-28 | 20-28 | 28-40 | 4-8 |
| Relative speed | Fastest | Moderate | Slowest | Fast |
| License | Apache 2.0 (check repo) | Non-commercial (varies by repo) | Stability AI Community License | Stability AI Community License |
| Best for | Low-VRAM boxes, rapid iteration | Higher fidelity, still local | Final production renders | Prompt/composition testing |
A practical workflow many InvokeAI users settle on: draft compositions quickly with SD 3.5 Large Turbo or FLUX.2 [klein] 4B, then re-run the winning prompt through SD 3.5 Large or FLUX.2 [klein] 9B for the final higher-fidelity pass.
Five common pitfalls when setting up local image generation
- Forgetting to select the matching VAE and text encoder for FLUX.2. Unlike SD-family models where the VAE is often baked in, FLUX.2 requires you to explicitly pair the main model with its own VAE and text encoder in the Advanced panel, or generations come out as static or garbled color noise.
- Skipping the Hugging Face license acceptance click. Model Manager will show a generic download failure rather than a clear “license not accepted” message when you haven’t clicked through the license gate on huggingface.co itself.
- Installing a mismatched PyTorch/CUDA pair during a manual pip install. This is the single largest source of “CUDA not available” errors reported by manual installers; the Invoke Launcher avoids this entirely by managing the pairing for you.
- Running SD 3.5 Large and FLUX.2 9B simultaneously on an 8-12GB card. Both models competing for VRAM cache slots leads to out-of-memory crashes mid-generation; lower the VRAM cache count in Settings if you switch models often.
- Generating directly at 2048×2048 instead of upscaling from a 1024×1024 base. Native high-resolution generation on both model families is prone to duplicated limbs, faces, or repeated background elements; a two-pass upscale workflow avoids this almost entirely.
Most of these mistakes trace back to the same root cause: treating FLUX.2 as if it were just a faster Stable Diffusion checkpoint. The two model families share a UI but not an internal architecture, and settings that are safe defaults for one can actively hurt output quality on the other. Reading the model card on each Hugging Face repo before your first generation, rather than after troubleshooting a bad result, saves most of the time lost to these five issues.
Output examples: what to expect at each settings tier
At 20 steps and 1024×1024 with FLUX.2 [klein] 4B, expect clean composition and generally correct anatomy, but occasional softness in fine texture detail like fabric weave or hair strands. Pushing to 28 steps sharpens texture noticeably at roughly 30-40% longer render time. SD 3.5 Large at 32-40 steps produces the most consistent hands and text rendering of the four options tested here, which matters if your use case includes product mockups with visible labels. SD 3.5 Large Turbo at 4-8 steps trades that consistency for near-instant iteration, useful for storyboarding a scene before committing to a full-quality render.
Advanced tips for production use
- Pin your InvokeAI version in any production deployment rather than tracking “latest” – for example pin to 6.14.2 (September 2026) rather than floating, since the REST API schema has changed between minor releases like 6.14.0, 6.14.1, and 6.14.2 throughout 2026.
- Use quantized GGUF builds of FLUX.2 [klein] 9B if you find full-precision downloads exceed your VRAM budget; community-quantized Q4/Q5 variants typically appear on Hugging Face within days of a new model release. For background on how this quantization process works and what quality tradeoffs to expect, see this site’s GGUF quantization guide.
- Set up a separate model cache directory on a fast NVMe drive if you’re running InvokeAI on a server with a slower boot disk, since model load time (not generation time) is often the actual bottleneck on cold starts.
- Store your prompt templates in version control alongside your batch script from Step 7, so a content pipeline’s visual style stays reproducible across team members.
- If you need multi-GPU scaling, InvokeAI 6.14.0 (August 2026) added native multi-GPU support, so recent builds can spread work across cards within a single instance; if you’re still on an older release, the fallback is running separate InvokeAI processes bound to different ports, each pinned to one GPU via CUDA_VISIBLE_DEVICES, and routing batch jobs across them with a simple queue.
Troubleshooting: 8+ common errors and fixes
- “CUDA out of memory” during generation. Lower resolution, reduce batch size, or switch to the quantized 4B FLUX.2 variant instead of 9B or full-precision SD 3.5.
- “You do not have access to this model” in the HuggingFace tab. Your HF token is missing or you haven’t accepted the model’s license on huggingface.co directly. Add the token in Model Manager settings and click through the license page in a browser first.
- Server fails to start with a torch/CUDA import error. Your manually installed PyTorch build doesn’t match your installed CUDA driver version. Reinstall PyTorch using the correct index URL from pytorch.org’s official install selector, or switch to the Invoke Launcher.
- Generated images are solid noise or static. The FLUX.2 main model is selected without its matching VAE and text encoder attached in the Advanced panel. Re-select all three components from the same starter bundle.
- xformers fails to import or crashes on generation. Disable xformers-based memory-efficient attention in Settings if your platform’s prebuilt xformers wheel doesn’t match your CUDA version; performance impact is minor on modern GPUs.
- Model download stalls or fails partway through. Large files (14GB+) can time out on unstable connections. Delete the partial download in the Model Manager and retry, or use the URL/Local Path method with a file downloaded separately via a download manager.
- InvokeAI web UI loads but shows no models in the dropdown. The Model Manager may still be indexing after a fresh install; wait for the scan to complete or manually trigger a “Sync Models” action from Settings.
- Extremely slow generation on Apple Silicon. Confirm InvokeAI is actually using Metal acceleration rather than falling back to CPU; check the console log on startup for an MPS device confirmation line.
- REST API batch requests return 422 errors. The payload schema differs between InvokeAI versions; check the live Swagger docs at /docs on your local instance rather than relying on examples written for a different version.
- Model Manager shows a download as complete but generation fails with a missing file error. This usually means a partial download was marked complete due to an interrupted connection during the final verification step. Delete the model entry entirely from Model Manager, clear the corresponding folder in your InvokeAI models directory, and reinstall from scratch rather than trying to resume.
Data privacy and security considerations for local generation
One underappreciated reason to run InvokeAI locally rather than through a hosted API is data control. Every prompt and reference image sent to a commercial image API passes through that provider’s servers and is subject to whatever retention policy is in effect at the time, which can change without much notice. A local InvokeAI install never sends prompts, reference images, or generated output anywhere unless you explicitly configure it to, which matters for teams working with unannounced products, personal photos used as ControlNet references, or any material under an NDA. If you do expose the InvokeAI web UI beyond localhost, for example to access it from another device on your network, put it behind a reverse proxy with authentication rather than binding directly to 0.0.0.0 on an open port, since the default install does not include a login screen.
Complete working project: a local image generation service
Putting the pieces from this tutorial together, a minimal production setup looks like this: InvokeAI running as a systemd service (Step 11) with FLUX.2 [klein] 4B loaded for draft generation and SD 3.5 Large loaded for final renders, a Python batch script (Step 7) reading prompts from a queue, and an upscale pass (Step 8) applied to any image flagged for final use. This combination handles the bulk of day-to-day content generation needs without touching a paid API, and it scales horizontally by running additional InvokeAI instances on separate GPU-equipped machines, each pointed at the same shared model cache directory over NFS to avoid re-downloading multi-gigabyte checkpoints on every new node. For a broader look at chaining multiple image models together in one pipeline rather than running a single model in isolation, see this site’s guide to building a multi-model AI image pipeline.
For teams comparing this approach against hosted APIs, the breakeven point typically arrives once you’re generating more than a few thousand images a month, at which point the GPU hardware cost amortizes below the equivalent API spend. Below that volume, a hosted API with no upfront hardware commitment may still be the simpler choice.
Real-world use cases for a local InvokeAI setup
Marketing and content teams use a local FLUX.2/SD 3.5 stack most often for high-volume product mockups and social content variants, where the same base composition needs dozens of color, lighting, or background variations for A/B testing. Because there’s no per-image charge, teams can generate far more variants than an API budget would normally allow and simply keep the best results. Game and app developers frequently reach for local generation to produce placeholder art, concept sketches, and texture references during early development, switching to a commissioned artist or a higher-tier commercial model only once a direction is locked in. Independent developers building AI-assisted tools also use InvokeAI’s REST API as a drop-in local replacement for a commercial image API during development, avoiding API spend entirely until the product is ready to ship and a hosted model’s higher ceiling on fidelity or speed becomes worth paying for. The same local-first approach applies to running large language models, not just image models; see this site’s guide to running Nemotron 3.5 Lightning locally for the LLM equivalent of this workflow.
Researchers and hobbyists training custom LoRAs also benefit from the setup described here, since local generation is what lets you iterate quickly on a LoRA’s output quality without burning through API credits on every test render. Security-conscious teams handling sensitive reference imagery, such as internal product prototypes that haven’t been announced, also prefer local generation specifically because no image data leaves the machine, a constraint that a cloud API cannot satisfy regardless of its stated data retention policy.
InvokeAI vs ComfyUI vs Automatic1111: which UI fits your workflow
ComfyUI’s node-graph interface offers the most granular control over the generation pipeline and remains the most popular choice among power users who need custom workflows, but it has a steeper learning curve for engineers who just want a working generation endpoint. Automatic1111’s WebUI is the longest-established of the three and carries the largest extension ecosystem, though its development pace has slowed relative to InvokeAI and ComfyUI through 2026. InvokeAI sits between the two: less flexible than a full node graph, but considerably faster to get from a fresh install to a working FLUX.2 or SD 3.5 generation, which is why this tutorial uses it as the entry point. All three are free, open-source, and run the same underlying model files, so nothing stops you from installing more than one and pointing them at a shared model directory.
Cost comparison: local generation vs hosted APIs
For a full breakdown of what each major hosted image API actually charges per image and per month at different volume tiers, see this site’s AI image generator API cost comparison. The table below summarizes how those figures stack up against a local InvokeAI setup.
| Approach | Upfront cost | Marginal cost per image | Rate limits |
|---|---|---|---|
| InvokeAI + FLUX.2/SD 3.5 (local) | GPU hardware (owned or rented) | Electricity only | None (hardware-bound) |
| Nano Banana 2 API | $0 | ~$0.067/image | Provider-defined |
| Seedream 5.0 Pro/Lite API | $0 | ~$0.035/image | Provider-defined |
| Cloud GPU rental (on-demand) | $0 | GPU-hour rate ÷ images generated | Availability-dependent |
Frequently asked questions
Is InvokeAI free to use?
Yes. The self-hosted Community Edition of InvokeAI is free and open-source. There is no usage-based fee for running it on your own hardware; you only pay for the electricity and hardware you already own or rent.
Can I run FLUX.2 [klein] without a GPU?
Technically yes on CPU, but generation times stretch from seconds to several minutes per image, making it impractical for anything beyond a one-off test. A discrete NVIDIA GPU with at least 6GB VRAM, or Apple Silicon with Metal acceleration, is strongly recommended.
Do I need a Hugging Face account to use InvokeAI?
You need one to download Stable Diffusion 3.5 and FLUX.2 [klein] 9B, since both are gated behind license acceptance on Hugging Face. FLUX.2 [klein] 4B is available through InvokeAI’s Starter Models without a separate account in most builds.
What’s the difference between FLUX.2 [klein] 4B and 9B?
The 9B variant has roughly double the parameter count of the 4B model, generally producing higher fidelity and more coherent detail at the cost of a larger download, more VRAM, and slower generation. The 4B model is quantized and optimized specifically for low-VRAM consumer hardware.
Can I use InvokeAI-generated images commercially?
It depends on which model generated the image. FLUX.2 [klein] 4B is typically Apache 2.0 licensed and safe for commercial use, but always confirm on the specific Hugging Face repo. SD 3.5 Large and Turbo allow commercial use under the Stability AI Community License for organizations under $1 million in annual revenue. FLUX.2 [klein] 9B often carries stricter non-commercial terms depending on the repository, so check before shipping outputs in a paid product.
Why does my FLUX.2 generation come out as noise or a solid color?
This almost always means the main model is selected without its matching VAE and text encoder attached in the Advanced panel. Re-select all three components from the same FLUX.2 starter bundle and regenerate.
How does InvokeAI compare to ComfyUI for FLUX.2 and SD 3.5?
Both support the same underlying models. ComfyUI’s node-graph interface gives finer control over each pipeline stage and remains more popular among advanced users, while InvokeAI’s form-based UI and built-in Model Manager make it considerably faster to reach a working generation from a fresh install.
Can I run InvokeAI on a headless server without a desktop environment?
Yes, using the manual pip install path covered in Step 2 rather than the desktop Invoke Launcher. Run the server as a systemd service (Step 11) and access the web UI remotely through the port it binds to.
Related Coverage
- How to Run Nemotron 3.5 Lightning Locally: 12 Steps [2026]
- How to Use Claude Fable 5.1 API: 12 Steps, 90 Min [2026]
- How to Use Google Imagen 4 API: 12 Steps, 90 Min [2026]
- How to Use Qwen3.8-Max API: 12 Steps, $2/$6 per 1M [2026]
- Gemini App Lands on Windows Free, Pro Tier at $19.99 [2026]
