Wan 2.2 A14B at 720p on a 24 GB GPU: why it runs out of memory and what to change
If you try Wan 2.2 T2V A14B at 1280×720 on a 24 GB card and get torch.OutOfMemoryError, you are not alone. A public bug report, reported in InvokeAI issue #9831 (2026-10-12) on an RTX 4090 24GB, lays out exactly when it fails, why, and which setting got it running. This post walks through that report and the official docs, step by step.
Everything below is quoted from the issue or from official documentation. We have not reproduced the runs ourselves.
1. The symptom and the conditions it was reported under
From InvokeAI issue #9831 (opened 2026-10-12, open, labelled bug, no comments when read on 2026-10-28):
- Machine: Windows 10, RTX 4090 with 24 GB VRAM, manual development checkout of InvokeAI main at 8111b5067e (7.0.0-alpha.1), Python 3.12, torch 2.13.0+cu130.
- Model: Wan 2.2 T2V A14B, GGUF Q4_K_M, both experts (High Noise and Low Noise), plus the Wan2.2-T2V-A14B-Diffusers components and the Lightning 4-step LoRAs (V1.1, high and low).
- Job: 1280×720, 81 frames, 4 steps, guidance 1.0, default invokeai.yaml.
- Error: torch.OutOfMemoryError in diffusers/models/transformers/transformer_wan.py:502.
The issue's results table (settings and outcome as reported; we list the memory outcome only):
| enable_partial_loading | device_working_mem_gb | Attention | Memory outcome reported in #9831 |
| --- | --- | --- | --- |
| true (default) | 3 (default) | PyTorch SDPA | OOM in the first transformer block, also at 832×480 |
| false | 3 | PyTorch SDPA | Completed, but VRAM full; overflowed into shared system memory |
| true | 10 | PyTorch SDPA | Completed (the issue's workaround for 24 GB) |
| true | 10 | SageAttention | Completed, but overflowed (about 1.2 GB more held than SDPA) |
| false | 3 | SageAttention | Completed, but overflowed into shared system memory |
Two details matter when you compare this with your own machine:
- The run with partial loading off did not really "fit". The issue says the card still overflowed and Windows moved memory to shared system memory instead of raising an OOM.
- This is a Windows machine on a 7.0.0 alpha development build. Linux, or a release build, may behave differently; the issue does not test them.
What to check
- Your error matches: torch.OutOfMemoryError in the Wan transformer, at the first denoise block.
- Your invokeai.yaml still has the defaults (enable_partial_loading: true, device_working_mem_gb: 3, or neither line set).
- On Windows, watch "Shared GPU memory" in Task Manager. If it climbs during generation, you are in the spill case, not the OOM case.
2. Why 24 GB is not enough here
Two experts, one at a time. The official Wan2.2 README (read 2026-10-28) describes the A14B models as a two-expert design: "a high-noise expert for the early stages, focusing on overall layout; and a low-noise expert for the later stages, refining video details. Each expert model has about 14B parameters, resulting in a total of 27B parameters but only 14B active parameters per step". So you download and load two diffusion models, but each denoise step uses one.
The official script's own guidance. For its single-GPU 1280*720 A14B command (with --offload_model True --convert_model_dtype), the README says: "This command can run on a GPU with at least 80GB VRAM." That statement is about the Wan repo's generate.py, not about InvokeAI or GGUF weights, but it tells you 720p A14B is not a small job.
What the issue found inside InvokeAI. According to #9831:
- Wan denoise has no working-memory estimate. _get_wan_transformer_working_mem_bytes returns None unless wan_memory_optimization is on, so the expert is loaded with the floor, device_working_mem_gb (3 GB), as its working memory.
- At 720p with 81 frames the transformer sees 75,600 tokens, "and the activations need far more than 3 GB."
- With partial loading on, the cache frees only 2,003 MB of the 10.8 GB UMT5 text encoder before loading the 9.2 GB expert, so the first block runs out of memory with 21.3 GiB allocated.
In short: model weights plus text encoder plus the attention activations for 75,600 tokens do not fit in 24 GB, and InvokeAI reserves only 3 GB for the activations by default.
What to check
- The InvokeAI log around model loading: is the text encoder still partly in VRAM when the expert loads?
- Your resolution and frame count. The 75,600-token figure is for 1280×720 with 81 frames only.
3. Local settings to change
3a. Raise the working memory
InvokeAI's Low-VRAM mode docs (read 2026-10-28): "Invoke reserves 3GB VRAM as working memory by default", and you can raise it in invokeai.yaml to prevent OOMs (the docs' example sets 4).
The issue's workaround for this exact case on 24 GB is 10:
# invokeai.yaml — workaround reported in InvokeAI issue #9831 for 24 GB
device_working_mem_gb: 10
With that, partial loading on and SDPA, the issue reports the 720p, 81-frame job completing. Invoke needs a restart after you edit the file.
What to check
- The OOM is gone and Task Manager's shared GPU memory stays flat during denoise.
- If you also set max_cache_vram_gb, the docs say to keep it at or below your VRAM minus device_working_mem_gb minus reserve_vram_gb.
3b. Keep partial loading on, and turn off the Windows sysmem fallback
The docs say Low-VRAM mode is enabled by default via enable_partial_loading: true. In the issue, turning it off did not prevent the overflow: the encoder was unloaded, but the run spilled into shared memory.
The same docs ask Windows users to disable the Nvidia sysmem fallback: NVIDIA Control Panel → 3D Settings → Manage 3D Settings → "CUDA - Sysmem Fallback Policy" → "Prefer No Sysmem Fallback". With it disabled, an overflow shows up as an OOM you can act on instead of silently spilling into shared system memory.
What to check
- enable_partial_loading is true (or absent) in invokeai.yaml.
- On Windows, the NVIDIA Control Panel setting reads "Prefer No Sysmem Fallback".
3c. Try wan_memory_optimization (opt-in)
From the same docs page: setting wan_memory_optimization: true makes partial-load Wan transformer weights "target about 2 GiB resident and stream remaining layers from RAM". It "reduces peak VRAM during both denoise and decode, but generation can be substantially slower and requires enough system RAM for offloaded weights." The docs also note same-seed output may differ slightly from the baseline path.
The issue explains that this flag is also what turns on Wan's working-memory estimate. It does not report a run with the flag on, so we have no figures for it.
wan_memory_optimization: true
What to check
- Free system RAM during generation; the docs say offloaded weights need it.
- Compare a short test clip against your baseline before committing to long runs.
3d. Lower the resolution, and treat frame count with care
The issue's only other resolution is 832×480. With default settings it also ran out of memory. With partial loading on and device_working_mem_gb: 10, it fit with both attention backends.
The issue tests 81 frames only. Fewer frames means a shorter clip, but the issue gives no figures for it, so try it on your own setup rather than relying on a number from us.
What to check
- At 832×480, the default settings still fail in the issue. Raise device_working_mem_gb as well; do not rely on resolution alone.
3e. Quantization, and the official script's flags
The issue already used GGUF Q4_K_M weights for both experts and still ran out of memory at default settings. Lower-bit weights alone did not fix it there; working memory did.
If you use the Wan repo's own generate.py instead of InvokeAI, the README says: "If you encounter OOM (Out-of-Memory) issues, you can use the --offload_model True, --convert_model_dtype and --t5_cpu options to reduce GPU memory usage."
On attention, these are figures reported in InvokeAI issue #9831 (one RTX 4090 24GB on Windows), not measured by us and not a claim about CloudGPU cards: the issue reports SageAttention held about 1.2 GB more than SDPA at 75,600 tokens, which pushed that card over the edge at 720p. At 832×480, the issue reports both backends fit.
What to check
- If you switched to SageAttention and shared GPU memory now climbs at 720p, switch back to SDPA and compare.
- The Wan2.2 model weights are licensed Apache-2.0 (per the README and the model card); check the license of any community GGUF build you download separately.
4. If local settings are still not enough: run the same workflow on a card with more VRAM
If the slower settings are not an option for you, the other route is more VRAM. On CloudGPU you can rent a card with more VRAM, billed per minute, and set up the same InvokeAI workflow on it. Cards listed on /pricing when we read it on 2026-10-28 include:
| Card on /pricing | VRAM (as shown on /pricing) |
| --- | --- |
| RTX 5090 32G | 32 GB |
| RTX 4090 48G | 48 GB |
| A100 80G | 80 GB |
To be clear about what this does and does not mean:
- We have not tested Wan 2.2 A14B, InvokeAI or this workflow on any of these cards. The only difference we can state is more VRAM than a 24 GB card.
- VRAM need depends on model, precision and workflow. See How much VRAM do I need to run an LLM?
- Billing is per minute, rounded up, with a 1-minute minimum, and stops when you destroy the instance (terms). Rates per card are on /pricing.
What to check
- Before renting, compare the VRAM column above with what your settings needed locally (the InvokeAI log and Task Manager tell you where it ran out).
- Destroy the instance when the job is done, so billing stops.
FAQ
Why does Wan 2.2 A14B run out of memory at 720p on a 24 GB GPU in InvokeAI?
According to InvokeAI issue #9831, Wan denoise has no working-memory estimate unless wan_memory_optimization is on, so InvokeAI reserves only the default 3 GB for activations. At 1280×720 with 81 frames the transformer sees 75,600 tokens, and the activations need far more than that.
What setting fixed it in the issue?
device_working_mem_gb: 10 in invokeai.yaml, with partial loading left on. The issue reports the 720p, 81-frame job then completed on an RTX 4090 24GB (Windows 10, InvokeAI 7.0.0-alpha.1).
Does turning off partial loading help?
Not in the issue. With enable_partial_loading: false the card still overflowed, and Windows moved memory to shared system memory instead of raising an OOM.
Does lowering the resolution to 832×480 avoid the OOM?
Not on its own. The issue reports an OOM at 832×480 with default settings too; with device_working_mem_gb: 10 it fit.
What does the official Wan2.2 README say about VRAM for A14B at 720p?
For its own single-GPU generate.py command at 1280*720, it says the command "can run on a GPU with at least 80GB VRAM", and suggests --offload_model True, --convert_model_dtype and --t5_cpu for OOM issues.
Sources
- InvokeAI issue #9831, InvokeAI#9831 (opened 2026-10-12; read 2026-10-28)
- Wan2.2 README (GitHub), Wan-Video/Wan2.2 (read 2026-10-28)
- Wan2.2-T2V-A14B model card, huggingface.co (read 2026-10-28)
- InvokeAI docs, Low-VRAM mode, invoke.ai (read 2026-10-28)
- CloudGPU /pricing and /terms (read 2026-10-28)
InvokeAI: Professional Creative AI Tools for Visual Media (29k stars)
What it does
All text below is quoted directly from the project README.
>Invoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies.
Other features:
- Free to use under a commercially-friendly license
- Download and install on compatible hardware
- Generate, refine, iterate on images, and build workflows
- Support for ckpt, diffusers, and some gguf models
- Upscaling Tools
- Embedding Manager & Support
- Model Manager & Support
- Object Segmentation & Selection Models (SAM / SAM2)
>To get started with Invoke, Download the Launcher.
Repository
invoke-ai/InvokeAI
Repository stats
|Metric|Value|
|:-|:-|
|Stars|28,700|
|Forks|3,061|
|Last release|v6.14.2 (2026-09-27)|
|Languages|TypeScript 58.2%, Python 41%, JavaScript 0.8%|
|Contributors|396|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 36, cursoragent: 34, claude: 175|
|AI co-authored commits|Claude: 565, Cursor: 1, Copilot: 20|
Main contributor
|Field|Value|
|:-|:-|
|Name|psychedelicious|
|GitHub|@psychedelicious|
|Commits to this repo|7,538 (top contributor)|
|Website|psychedelicio.us|
|Followers|92|
|Public repos|51|
|On GitHub since|2013-06-25|
----------------------------------------------------------------------------------------
Discover the best GitHub repos without the endless scrolling.
Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter.
👉 Get the best repos & community insights - Free
5 points
Mentions
Wan 2.2 A14B at 720p on a 24 GB GPU: why it runs out of memory and what to change If you try Wan 2.2 T2V A14B at 1280×720 on a 24 GB card and get torch.OutOfMemoryError, you are not alone. A public bug report, reported in InvokeAI issue #9831 (2026-10-12) on an RTX 4090 24GB, lays out exactly when it fails, why, and which setting got it running. This post walks through that report and the official docs, step by step. Everything below is quoted from the issue or from official documentation. We have not reproduced the runs ourselves. 1. The symptom and the conditions it was reported under From InvokeAI issue #9831 (opened 2026-10-12, open, labelled bug, no comments when read on 2026-10-28): - Machine: Windows 10, RTX 4090 with 24 GB VRAM, manual development checkout of InvokeAI main at 8111b5067e (7.0.0-alpha.1), Python 3.12, torch 2.13.0+cu130. - Model: Wan 2.2 T2V A14B, GGUF Q4_K_M, both experts (High Noise and Low Noise), plus the Wan2.2-T2V-A14B-Diffusers components and the Lightning 4-step LoRAs (V1.1, high and low). - Job: 1280×720, 81 frames, 4 steps, guidance 1.0, default invokeai.yaml. - Error: torch.OutOfMemoryError in diffusers/models/transformers/transformer_wan.py:502. The issue's results table (settings and outcome as reported; we list the memory outcome only): | enable_partial_loading | device_working_mem_gb | Attention | Memory outcome reported in #9831 | | --- | --- | --- | --- | | true (default) | 3 (default) | PyTorch SDPA | OOM in the first transformer block, also at 832×480 | | false | 3 | PyTorch SDPA | Completed, but VRAM full; overflowed into shared system memory | | true | 10 | PyTorch SDPA | Completed (the issue's workaround for 24 GB) | | true | 10 | SageAttention | Completed, but overflowed (about 1.2 GB more held than SDPA) | | false | 3 | SageAttention | Completed, but overflowed into shared system memory | Two details matter when you compare this with your own machine: - The run with partial loading off did not really "fit". The issue says the card still overflowed and Windows moved memory to shared system memory instead of raising an OOM. - This is a Windows machine on a 7.0.0 alpha development build. Linux, or a release build, may behave differently; the issue does not test them. What to check - Your error matches: torch.OutOfMemoryError in the Wan transformer, at the first denoise block. - Your invokeai.yaml still has the defaults (enable_partial_loading: true, device_working_mem_gb: 3, or neither line set). - On Windows, watch "Shared GPU memory" in Task Manager. If it climbs during generation, you are in the spill case, not the OOM case. 2. Why 24 GB is not enough here Two experts, one at a time. The official Wan2.2 README (read 2026-10-28) describes the A14B models as a two-expert design: "a high-noise expert for the early stages, focusing on overall layout; and a low-noise expert for the later stages, refining video details. Each expert model has about 14B parameters, resulting in a total of 27B parameters but only 14B active parameters per step". So you download and load two diffusion models, but each denoise step uses one. The official script's own guidance. For its single-GPU 1280*720 A14B command (with --offload_model True --convert_model_dtype), the README says: "This command can run on a GPU with at least 80GB VRAM." That statement is about the Wan repo's generate.py, not about InvokeAI or GGUF weights, but it tells you 720p A14B is not a small job. What the issue found inside InvokeAI. According to #9831: - Wan denoise has no working-memory estimate. _get_wan_transformer_working_mem_bytes returns None unless wan_memory_optimization is on, so the expert is loaded with the floor, device_working_mem_gb (3 GB), as its working memory. - At 720p with 81 frames the transformer sees 75,600 tokens, "and the activations need far more than 3 GB." - With partial loading on, the cache frees only 2,003 MB of the 10.8 GB UMT5 text encoder before loading the 9.2 GB expert, so the first block runs out of memory with 21.3 GiB allocated. In short: model weights plus text encoder plus the attention activations for 75,600 tokens do not fit in 24 GB, and InvokeAI reserves only 3 GB for the activations by default. What to check - The InvokeAI log around model loading: is the text encoder still partly in VRAM when the expert loads? - Your resolution and frame count. The 75,600-token figure is for 1280×720 with 81 frames only. 3. Local settings to change 3a. Raise the working memory InvokeAI's Low-VRAM mode docs (read 2026-10-28): "Invoke reserves 3GB VRAM as working memory by default", and you can raise it in invokeai.yaml to prevent OOMs (the docs' example sets 4). The issue's workaround for this exact case on 24 GB is 10: # invokeai.yaml — workaround reported in InvokeAI issue #9831 for 24 GB device_working_mem_gb: 10 With that, partial loading on and SDPA, the issue reports the 720p, 81-frame job completing. Invoke needs a restart after you edit the file. What to check - The OOM is gone and Task Manager's shared GPU memory stays flat during denoise. - If you also set max_cache_vram_gb, the docs say to keep it at or below your VRAM minus device_working_mem_gb minus reserve_vram_gb. 3b. Keep partial loading on, and turn off the Windows sysmem fallback The docs say Low-VRAM mode is enabled by default via enable_partial_loading: true. In the issue, turning it off did not prevent the overflow: the encoder was unloaded, but the run spilled into shared memory. The same docs ask Windows users to disable the Nvidia sysmem fallback: NVIDIA Control Panel → 3D Settings → Manage 3D Settings → "CUDA - Sysmem Fallback Policy" → "Prefer No Sysmem Fallback". With it disabled, an overflow shows up as an OOM you can act on instead of silently spilling into shared system memory. What to check - enable_partial_loading is true (or absent) in invokeai.yaml. - On Windows, the NVIDIA Control Panel setting reads "Prefer No Sysmem Fallback". 3c. Try wan_memory_optimization (opt-in) From the same docs page: setting wan_memory_optimization: true makes partial-load Wan transformer weights "target about 2 GiB resident and stream remaining layers from RAM". It "reduces peak VRAM during both denoise and decode, but generation can be substantially slower and requires enough system RAM for offloaded weights." The docs also note same-seed output may differ slightly from the baseline path. The issue explains that this flag is also what turns on Wan's working-memory estimate. It does not report a run with the flag on, so we have no figures for it. wan_memory_optimization: true What to check - Free system RAM during generation; the docs say offloaded weights need it. - Compare a short test clip against your baseline before committing to long runs. 3d. Lower the resolution, and treat frame count with care The issue's only other resolution is 832×480. With default settings it also ran out of memory. With partial loading on and device_working_mem_gb: 10, it fit with both attention backends. The issue tests 81 frames only. Fewer frames means a shorter clip, but the issue gives no figures for it, so try it on your own setup rather than relying on a number from us. What to check - At 832×480, the default settings still fail in the issue. Raise device_working_mem_gb as well; do not rely on resolution alone. 3e. Quantization, and the official script's flags The issue already used GGUF Q4_K_M weights for both experts and still ran out of memory at default settings. Lower-bit weights alone did not fix it there; working memory did. If you use the Wan repo's own generate.py instead of InvokeAI, the README says: "If you encounter OOM (Out-of-Memory) issues, you can use the --offload_model True, --convert_model_dtype and --t5_cpu options to reduce GPU memory usage." On attention, these are figures reported in InvokeAI issue #9831 (one RTX 4090 24GB on Windows), not measured by us and not a claim about CloudGPU cards: the issue reports SageAttention held about 1.2 GB more than SDPA at 75,600 tokens, which pushed that card over the edge at 720p. At 832×480, the issue reports both backends fit. What to check - If you switched to SageAttention and shared GPU memory now climbs at 720p, switch back to SDPA and compare. - The Wan2.2 model weights are licensed Apache-2.0 (per the README and the model card); check the license of any community GGUF build you download separately. 4. If local settings are still not enough: run the same workflow on a card with more VRAM If the slower settings are not an option for you, the other route is more VRAM. On CloudGPU you can rent a card with more VRAM, billed per minute, and set up the same InvokeAI workflow on it. Cards listed on /pricing when we read it on 2026-10-28 include: | Card on /pricing | VRAM (as shown on /pricing) | | --- | --- | | RTX 5090 32G | 32 GB | | RTX 4090 48G | 48 GB | | A100 80G | 80 GB | To be clear about what this does and does not mean: - We have not tested Wan 2.2 A14B, InvokeAI or this workflow on any of these cards. The only difference we can state is more VRAM than a 24 GB card. - VRAM need depends on model, precision and workflow. See How much VRAM do I need to run an LLM? - Billing is per minute, rounded up, with a 1-minute minimum, and stops when you destroy the instance (terms). Rates per card are on /pricing. What to check - Before renting, compare the VRAM column above with what your settings needed locally (the InvokeAI log and Task Manager tell you where it ran out). - Destroy the instance when the job is done, so billing stops. FAQ Why does Wan 2.2 A14B run out of memory at 720p on a 24 GB GPU in InvokeAI? According to InvokeAI issue #9831, Wan denoise has no working-memory estimate unless wan_memory_optimization is on, so InvokeAI reserves only the default 3 GB for activations. At 1280×720 with 81 frames the transformer sees 75,600 tokens, and the activations need far more than that. What setting fixed it in the issue? device_working_mem_gb: 10 in invokeai.yaml, with partial loading left on. The issue reports the 720p, 81-frame job then completed on an RTX 4090 24GB (Windows 10, InvokeAI 7.0.0-alpha.1). Does turning off partial loading help? Not in the issue. With enable_partial_loading: false the card still overflowed, and Windows moved memory to shared system memory instead of raising an OOM. Does lowering the resolution to 832×480 avoid the OOM? Not on its own. The issue reports an OOM at 832×480 with default settings too; with device_working_mem_gb: 10 it fit. What does the official Wan2.2 README say about VRAM for A14B at 720p? For its own single-GPU generate.py command at 1280*720, it says the command "can run on a GPU with at least 80GB VRAM", and suggests --offload_model True, --convert_model_dtype and --t5_cpu for OOM issues. Sources - InvokeAI issue #9831, InvokeAI#9831 (opened 2026-10-12; read 2026-10-28) - Wan2.2 README (GitHub), Wan-Video/Wan2.2 (read 2026-10-28) - Wan2.2-T2V-A14B model card, huggingface.co (read 2026-10-28) - InvokeAI docs, Low-VRAM mode, invoke.ai (read 2026-10-28) - CloudGPU /pricing and /terms (read 2026-10-28)
STUDIO SÁNG TẠO HÌNH ẢNH AI CHUYÊN NGHIỆP THAY THẾ MIDJOURNEY: INVOKEAI CUNG CẤP CÔNG CỤ INFINITE CANVAS ĐỈNH CAO Sử dụng các dịch vụ sinh ảnh thương mại như Midjourney trên Discord mang lại nhiều bất tiện: bạn không thể kiểm soát chính xác vùng cần sửa (Inpainting/Outpainting), không thể sử dụng mô hình tùy biến của riêng mình và chi phí đăng ký định kỳ đắt đỏ. InvokeAI là công cụ sáng tạo nghệ thuật bằng trí tuệ nhân tạo (Generative AI Creative Engine) mã nguồn mở chuyên nghiệp hàng đầu dành cho các họa sĩ, nhà thiết kế đồ họa và studio sáng tạo. Tech Stack: Được xây dựng bằng Python và PyTorch ở backend, giao diện frontend được thiết kế cực kỳ hiện đại và trực quan bằng React, TypeScript và Chakra UI. Hỗ trợ đầy đủ Stable Diffusion 1.5, SDXL và Flux. Tại sao nên dùng? - Tính năng Unified Canvas vô hạn đỉnh cao: Cho phép bạn vẽ mở rộng bức tranh ra bốn phía (Outpainting), chỉnh sửa chi tiết từng vùng nhỏ (Inpainting) và ghép nối nhiều yếu tố hình ảnh trực tiếp trên một mặt phẳng vô cực trực quan hệt như trong Photoshop. - Quản lý tài nguyên và thư viện thông minh: Dễ dàng quản lý hàng trăm model checkpoint, LoRA, ControlNet và Textual Inversion với giao diện phân loại và tìm kiếm mượt mà. - Hỗ trợ tối ưu hóa phần cứng đa dạng: Hoạt động trơn tru trên cả GPU NVIDIA (CUDA), GPU AMD (ROCm) và Apple Silicon (Metal Performance Shaders). Dự án sở hữu hơn 24.000 stars trên GitHub và được xem là giao diện sáng tạo hình ảnh AI có trải nghiệm người dùng (UX) chuyên nghiệp và tinh tế nhất hiện nay. Link tham khảo: invoke-ai/InvokeAI #OpenSourceVN #VNOSS #opensourcevn #vnoss #DevCommunity #InvokeAI #StableDiffusion #GenerativeAI #CreativeTools #Python #React
Repo link: invoke-ai/InvokeAI Runs 100% locally — nothing uploads. What paid tool should I replace next?
Stop Paying $119.88 for Adobe Firefly Standard — This Free GitHub Repo Replaces It Adobe Firefly Standard costs $119.88 a year. Invoke is free, open source, and runs entirely on your own machine. Invoke has 28,805 stars on GitHub and is licensed under Apache-2.0. Your data never leaves your own machine — nothing gets uploaded to anyone's cloud. ⭐ Repo: invoke-ai/InvokeAI 🌐 Site: invoke-ai.github.io ── SYSTEM REQUIREMENTS ── Windows: Windows 10 or newer (Invoke Launcher installer) · 8 GB minimum for SD1.5, 16 GB for SDXL, 32 GB for FLUX · Invoke Launcher installs Python and Invoke automatically macOS: macOS 14 or newer (Invoke Launcher DMG) · 16 GB or more unified memory recommended · Invoke Launcher installs Python and Invoke automatically ── WHAT YOU GET ── • TEXT TO IMAGE • UNIFIED CANVAS • INPAINTING • MODEL MANAGER • NODE WORKFLOWS I post free open-source replacements for paid software every single day. If you're tired of subscriptions eating your budget, subscribe — there's a new one tomorrow. Searching for: invokeai tutorial, invoke ai install, adobe firefly alternative free, free ai image generator offline, stable diffusion local install, invokeai vs comfyui #Shorts #Invoke #OpenSource #SelfHosted Pricing shown is Adobe Firefly Standard plan, US$9.99 per month billed monthly with 2,000 generative credits ($119.88 a year), checked 2026-10-21. Prices change — verify before you buy.
This caricature was created with open source (FREE), Invoke AI v7.xx at home without needing or relying on my internet connection. invoke-ai/InvokeAI
InvokeAI: Professional Creative AI Tools for Visual Media (29k stars) What it does All text below is quoted directly from the project README. >Invoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. Other features: - Free to use under a commercially-friendly license - Download and install on compatible hardware - Generate, refine, iterate on images, and build workflows - Support for ckpt, diffusers, and some gguf models - Upscaling Tools - Embedding Manager & Support - Model Manager & Support - Object Segmentation & Selection Models (SAM / SAM2) >To get started with Invoke, Download the Launcher. Repository invoke-ai/InvokeAI Repository stats |Metric|Value| |:-|:-| |Stars|28,700| |Forks|3,061| |Last release|v6.14.2 (2026-09-27)| |Languages|TypeScript 58.2%, Python 41%, JavaScript 0.8%| |Contributors|396| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 36, cursoragent: 34, claude: 175| |AI co-authored commits|Claude: 565, Cursor: 1, Copilot: 20| Main contributor |Field|Value| |:-|:-| |Name|psychedelicious| |GitHub|@psychedelicious| |Commits to this repo|7,538 (top contributor)| |Website|psychedelicio.us| |Followers|92| |Public repos|51| |On GitHub since|2013-06-25| ---------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free
Links VoiceStudio: debpalash/VoiceStudio Odysseus: odysseus-dev/odysseus Free LLM APIs: mnfst/awesome-free-llm-apis Vane: ItzCrazyKns/Vane InvokeAI: invoke-ai/InvokeAI ACE-Step: ace-step/ACE-Step OpenShorts: mutonby/openshorts Dyad: dyad-sh/dyad OpenManus: FoundationAgents/OpenManus Upscayl: upscayl/upscayl These are alternatives, not drop-in replacements. Some run fully locally, some still need API keys, and several need a capable GPU or Docker. Check each project’s own installation instructions and licence before you rely on it.
⚡ [Top 5 AI Repos This Week] InvokeAI: The Free Tool Taking Over GitHub! #shorts Discover invoke-ai/InvokeAI: Invoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. The solution offers an industry leading WebUI, and serves as the foundation for multiple commercial products. 💬 Comment "INVOKEAI" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: invoke-ai/InvokeAI 📊 Repository Specs: ⭐ Stars: 28,637 🍴 Forks: 3,047 💻 Language: TypeScript 📜 License: Apache-2.0 #shorts #invokeai #aiart #generativeart #imagegeneration #ai #artificialintelligence #machinelearning #deeplearning
3. InvokeAI Stable Diffusionで画像を作って、何度でも手直しを重ねていけるWebツール 生成から修正までの手順ごと、ワークフローに組んでおける invoke-ai/InvokeAI t.co