Qwen-Image-2.1 ComfyUI Troubleshooting 2026: 1024 Artifacts, MPS VAE, VRAM & Multi-GPU
Qwen-Image-2.1 arrived in ComfyUI with native support, but some of the most useful troubleshooting information is coming from very recent, configuration-specific reports. If your image edit suddenly contains broadband noise, your Apple Silicon workflow produces a badly degraded reference image, or a Windows multi-GPU run aborts while the model is being staged, the important question is not simply “Is Qwen-Image-2.1 broken?”
The more useful question is: Which exact execution path is failing?
This guide walks through the current ComfyUI/Qwen-Image-2.1 issues that have been reported around 1024-sized image-edit grids, MPS VAE encoding, dynamic VRAM and Windows multi-GPU staging. The reports are useful diagnostics, not proof that every Qwen-Image-2.1 installation has the same bug.
What changed with Qwen-Image-2.1 in ComfyUI?
Qwen-Image-2.1 is a unified text-to-image and image-editing model. ComfyUI provides native workflows for both text-to-image and image editing, with model files supplied through the Comfy-Org Qwen-Image-2.1 repository. The current model package includes BF16 and INT8 ConvRot diffusion-model weights, BF16 and INT8 text encoders, and a BF16 VAE. Comfy-Org Qwen-Image-2.1 model repository.
The official ComfyUI workflow templates also point users to the current model files and explicitly recommend updating ComfyUI before troubleshooting runtime problems. Official Qwen-Image-2.1 workflow template.
| Symptom | Reported trigger | First isolation test |
|---|---|---|
| Broadband noise during image edit | Target grid resolving to 1024 in a Qwen-Image-2.1 edit path | Test a nearby size such as 992 or 1056 |
| Bad image-edit reference on Apple Silicon | Qwen-Image-2.1 VAE encode on MPS | Run the VAE encode/decode path on CPU |
| Corruption after model reload/reallocation | Reported with --enable-dynamic-vram on a ROCm setup | Repeat without dynamic VRAM |
| ComfyUI aborts during model initialization | Reported Windows multi-GPU staging path | Test single GPU and disable dynamic/staging-related options |
First: update and reproduce with the official workflow
Before changing precision flags, custom nodes or memory settings, start from the official workflow. ComfyUI's Qwen-Image-2.1 template currently links directly to the supported model files and says to update ComfyUI before reporting runtime problems. Official Qwen-Image-2.1 image-edit workflow.
For a clean troubleshooting run:
- Update ComfyUI to a current version.
- Use the official Qwen-Image-2.1 workflow.
- Temporarily disable custom nodes.
- Record your OS, GPU, VRAM, PyTorch version and ComfyUI version.
- Use one fixed input image and one fixed seed.
- Change only one variable per test.
This matters because a report involving a custom node, an older workflow, a particular driver and a special memory flag cannot automatically be generalized to every Qwen-Image-2.1 user.
Issue 1: Qwen-Image-2.1 image edit produces noise at a 1024 grid
One recent ComfyUI issue reports a particularly interesting image-edit artifact: broadband high-frequency noise when the effective image grid resolves to exactly 1024. The reporter tested a clean ComfyUI checkout with no custom nodes and found that 992 and 1056 were clean while the 1024 case was corrupted. The report also says the behavior reproduced on both CPU and MPS for that environment, which is important because it makes the symptom different from an MPS-only VAE problem. ComfyUI issue #16435.
There is an important detail that is easy to miss: the trigger is the effective grid, not merely whether the UI field literally contains the number 1024.
The report explains that the image-edit workflow can use resolution=0, which preserves the reference image size after rounding to a multiple of 32. A 1024×1024 reference can therefore still create a 1024 grid and reproduce the artifact.
How to test the 1024-grid problem
Use the same image, seed and prompt, then test several nearby effective resolutions:
992 × 992
1024 × 1024
1056 × 1056If the 1024 case fails while the neighboring sizes are clean, you have a strong reproduction of the reported configuration-specific behavior.
Do not immediately conclude that Qwen-Image-2.1 always fails at 1024. The issue is a report against a particular ComfyUI state and workflow path, and another user in the same issue reported different behavior on CUDA. That is exactly why controlled reproduction is more useful than a blanket claim.
Why changing VAE precision may not fix this particular symptom
The issue report says the reporter tested flags including --fp32-vae and --cpu-vae and did not eliminate this specific 1024-grid artifact. It also reports that disabling the Qwen image cache and changing attention implementations did not change the result. Those observations are useful for narrowing the fault, but they should not be treated as universal behavior across all ComfyUI versions and hardware.
If your own 1024 test fails, first determine whether changing the effective grid fixes it. That is a much cleaner diagnostic than stacking multiple precision flags.
Issue 2: Qwen-Image-2.1 VAE encode on Apple Silicon MPS
There is a separate recent report involving Qwen-Image-2.1's VAE encode path on Apple Silicon. In ComfyUI issue #16433, the reporter measured a large quality difference between an MPS VAE encode→decode round trip and the same operation on CPU. The report says the MPS path produced severe image corruption while moving the VAE to CPU restored the round-trip quality. ComfyUI issue #16433.
This distinction matters because text-to-image and image editing do not exercise exactly the same VAE path.
Text-to-image primarily needs the VAE to decode the generated latent into an image. Image editing can require vae.encode() to turn the reference image into latents. A problem in encode can therefore make image editing look broken even when ordinary text-to-image generation appears fine.
The clean MPS diagnostic
If you are on Apple Silicon and image editing looks corrupted:
- Run the official Qwen-Image-2.1 text-to-image workflow.
- Run the official image-edit workflow with the same installation.
- If text-to-image is clean but image editing is degraded, isolate the reference-image/VAE encode path.
- Test the VAE on CPU using the appropriate ComfyUI option.
- Compare the result before changing model weights or sampler settings.
The reported issue found that --cpu-vae resolved its VAE encode/decode corruption, while --fp32-vae did not materially change the reported MPS result. Again, this is evidence for reproducing and isolating that particular issue, not a guarantee that CPU VAE is the permanent solution for every Mac.
Why --fp32-vae is not the same as moving the VAE to CPU
These options solve different classes of problems. Changing precision changes how the VAE calculations are represented. Moving the VAE to CPU changes the execution backend.
If a backend-specific operation is producing incorrect results, increasing precision may leave the underlying backend path unchanged. That is why a controlled CPU-VAE comparison is valuable.
The trade-off is speed. CPU VAE processing can make image editing substantially slower, especially at larger resolutions.
Issue 3: dynamic VRAM corruption after model reload
Another recent ComfyUI report describes Qwen-Image-2.1 output corruption after model reload or memory reallocation when --enable-dynamic-vram was enabled. The reported environment was ROCm-based, and the reporter found that removing dynamic VRAM made the tested sequence clean. ComfyUI issue #16437.
The key clue is that the first generation can be correct and later generations become corrupted after something causes model data to be re-staged or reallocated.
The reported reproduction sequence was roughly:
1. Generate at 1024×1024 → clean
2. Change prompt → corruption
3. Change resolution → corruption
4. Return to the original settings → corruption persists
5. Restart ComfyUI → first generation becomes clean againThat pattern is very different from a prompt-quality problem. It points you toward memory lifecycle and model staging rather than the text prompt itself.
How to isolate dynamic VRAM
If you see a similar pattern:
- Restart ComfyUI.
- Run the workflow once.
- Repeat after changing the prompt.
- Repeat after changing resolution.
- Record exactly when corruption starts.
- Restart with dynamic VRAM disabled.
- Repeat the same sequence.
If the behavior changes only when dynamic VRAM is enabled, you have a much stronger configuration-specific signal than simply saying “Qwen-Image is broken.”
Do not mix this test with simultaneous changes to precision, attention implementation, VAE placement and GPU selection. You want one variable to explain the result.
Issue 4: Windows multi-GPU crashes during model staging
A separate issue reports a hard ComfyUI abort on Windows 11 when Qwen-Image-2.1 image editing is run on a two-GPU setup. The reported machine used two RTX 5060 Ti 16 GB GPUs, and the crash occurred during model initialization/staging rather than after a normal completed generation. ComfyUI issue #16443.
The report identifies dynamic VRAM loading as active and discusses the staging-buffer/prefetch path as an area for investigation. The mechanism was not confirmed in the report, so it should be treated as a hypothesis rather than an established root cause.
What to test on Windows multi-GPU
If your failure looks like a hard abort at “Model Initializing” rather than a bad image:
| Test | Purpose |
|---|---|
| Single GPU | Determines whether the failure depends on multi-GPU execution. |
| Disable custom nodes | Removes third-party code from the reproduction. |
| Disable dynamic VRAM | Tests whether memory staging is involved. |
| Update ComfyUI | Rules out an already-fixed runtime problem. |
| Record driver/CUDA/PyTorch versions | Makes the reproduction actionable. |
If single-GPU execution is stable but the identical workflow crashes with two GPUs, that is useful evidence. It does not prove that every multi-GPU system has the same failure.
Do not confuse the four problems
These reports can look similar in screenshots, but they have different signatures.
| Problem | Typical clue | Likely isolation direction |
|---|---|---|
| 1024-grid image-edit artifact | One effective grid produces broadband noise while nearby sizes are clean | Resolution/effective latent grid |
| MPS VAE encode issue | Reference-image editing is degraded on Apple Silicon; CPU VAE improves it | VAE backend/encode path |
| Dynamic-VRAM corruption | First run is clean, later reload/reallocation causes persistent corruption | Memory staging/reload path |
| Windows multi-GPU crash | Process aborts during model initialization/staging | GPU topology/staging/runtime |
A disciplined Qwen-Image-2.1 troubleshooting workflow
When something goes wrong, use this order instead of changing ten settings at once.
1. Verify the model files
Use the official Comfy-Org Qwen-Image-2.1 repository and the workflow template's current model links. The repository currently lists the BF16 and INT8 ConvRot diffusion weights and the corresponding text encoders and VAE. Official Comfy-Org model files.
2. Update ComfyUI
The official workflow template explicitly tells users to update ComfyUI before reporting runtime errors. Do that before debugging an older installation.
3. Disable custom nodes
Use a clean startup where possible. If the official workflow works with custom nodes disabled but fails with them enabled, you have a meaningful direction for the investigation.
4. Establish a baseline
Get one clean text-to-image generation. Then test image editing separately. This immediately tells you whether the failure is limited to the reference-image path.
5. Change one variable
For example:
Baseline
↓
Change only resolution
↓
Change only VAE device
↓
Change only dynamic VRAM
↓
Change only GPU countKeep a small table of each run, including resolution, GPU, backend, precision, flags, seed and result.
6. Reproduce before optimizing
Do not start by enabling every memory-saving flag because your GPU is close to its limit. First determine whether the default workflow works. Then add memory optimizations one at a time.
What not to do
- Do not assume every visual artifact is a VAE problem. The 1024-grid report and MPS VAE report have different signatures.
- Do not treat a GitHub issue as a universal bug. Hardware, versions and flags matter.
- Do not stack flags randomly. You lose the ability to identify the actual trigger.
- Do not benchmark a broken configuration. First establish that the output is correct.
- Do not ignore the effective resolution. A workflow setting of zero can still resolve to a problematic image grid.
- Do not expose private model servers unnecessarily. If your ComfyUI installation is remotely accessible, protect the interface and API appropriately.
VRAM and hardware considerations
Qwen-Image-2.1's ComfyUI package provides both BF16 and INT8 ConvRot diffusion weights, giving users different memory/precision trade-offs. The official repository lists both options. Qwen-Image-2.1 model files.
But a smaller weight file does not mean the entire workflow has the same memory requirements. You also have the text encoder, VAE, intermediate activations, reference images, attention state and ComfyUI's model-management behavior.
If you are close to your hardware limit, a memory-management option can be useful. The problem is that a memory optimization can also introduce a different execution path. That is why a stable baseline matters before you enable aggressive offloading or dynamic memory features.
Apple Silicon: a practical decision tree
- Text-to-image works, image editing fails: test the VAE encode path.
- Image editing becomes clean with CPU VAE: keep CPU VAE as a diagnostic workaround while tracking the upstream issue.
- Both T2I and editing fail: check model files, workflow, ComfyUI version and general MPS behavior.
- Only a particular effective resolution fails: test neighboring resolutions before changing precision.
This is much more informative than immediately reinstalling PyTorch.
Windows multi-GPU: a practical decision tree
- Run the official workflow on one GPU.
- Confirm that one-GPU generation is stable.
- Enable the second GPU and reproduce.
- If the crash appears only with multiple GPUs, record the exact staging point and runtime versions.
- Test with dynamic VRAM disabled if your setup permits it.
- Only after the baseline is stable should you experiment with additional memory optimizations.
When you should wait instead of forcing a workaround
If a problem reproduces consistently on a clean installation and you have a clear upstream issue, repeatedly changing unrelated settings may only hide the problem.
A good workaround should have a clear trade-off. For example, testing CPU VAE can establish whether MPS VAE encode is involved, while using a nearby resolution can establish whether the effective 1024 grid is involved. These are diagnostic choices with understandable consequences.
If you need maximum stability for production image generation, consider keeping a known-good ComfyUI environment separate from an experimental installation where you test new Qwen-Image-2.1 workflows and runtime options.
FAQ
Is Qwen-Image-2.1 broken at 1024×1024?
There is a recent ComfyUI report of an image-edit artifact when the effective grid resolves to 1024, including cases where a 1024 reference image is preserved by the workflow. Another CUDA report in the same discussion had different results, so this should be treated as a configuration-specific issue rather than a universal failure.
Why does Qwen-Image-2.1 image editing look worse on my Mac?
A recent ComfyUI issue reports severe VAE encode/decode corruption on MPS while CPU VAE produced a clean round trip. Test the VAE on CPU to determine whether your problem follows that pattern.
Will --fp32-vae fix Qwen-Image-2.1 MPS problems?
Not necessarily. In the reported MPS VAE issue, changing VAE precision did not materially resolve the encode problem, while CPU VAE did. Your results can differ with software versions and hardware.
Why does my first Qwen-Image-2.1 generation work and later generations become corrupted?
If you use dynamic VRAM, compare the behavior with dynamic VRAM disabled. A recent report describes corruption appearing after prompt changes or memory reallocation and disappearing after a restart without dynamic VRAM.
Why does ComfyUI crash at Model Initializing on Windows?
A recent report describes a hard abort during Qwen-Image-2.1 model staging on a Windows multi-GPU system. Test single-GPU execution, disable custom nodes, update ComfyUI and record your runtime versions before changing other variables.
Where should I get Qwen-Image-2.1 ComfyUI model files?
Use the official Comfy-Org Qwen-Image-2.1 repository and the model links provided in the official ComfyUI workflow templates.
Related GyanAangan guides
- ComfyUI Qwen-Image-2.1 Setup Guide 2026 — installation, model files and basic workflows.
- Best Local AI Models in 2026 Based on Your RAM — hardware-oriented model selection.
- Ollama vs LM Studio — local model runner comparison.
- AnythingLLM + Ollama RAG Setup Guide — another practical local AI stack.
Official sources
- Comfy-Org Qwen-Image-2.1 model repository
- Official ComfyUI Qwen-Image-2.1 image-edit workflow
- ComfyUI issue #16435 — 1024-grid image-edit artifact
- ComfyUI issue #16433 — MPS VAE encode report
- ComfyUI issue #16437 — dynamic VRAM report
- ComfyUI issue #16443 — Windows multi-GPU crash report
The practical takeaway: troubleshoot Qwen-Image-2.1 by reproducing the smallest possible failure. If 1024 alone fails, test the effective grid. If Mac image editing fails but text-to-image works, test VAE encode on CPU. If corruption appears after memory reloads, test dynamic VRAM. If Windows crashes during staging on multiple GPUs, reduce to one GPU. Those tests tell you much more than repeatedly changing prompts, samplers or precision settings.