24°
Portada del artículo: ComfyUI vs Forge on a 16 GB GPU: they tie on SDXL, and ComfyUI is twice as fast with Z-Image when the models do not fit
AIBenchmarksImage generationLocal inference

ComfyUI vs Forge on a 16 GB GPU: they tie on SDXL, and ComfyUI is twice as fast with Z-Image when the models do not fit

I measured ComfyUI, Forge Neo and the original Forge with the same files, seeds and settings on an RTX 4070 Ti SUPER, with diffusers as a baseline. With SDXL they tie at 6.7 s per image. With Z-Image Turbo, which does not fit together with its text encoder, ComfyUI takes 6.75 s and Forge Neo 13.4 s; with Qwen-Image fp8, 75.7 s against 96.0 s. The logs point to how each one manages memory between RAM and the GPU.

Efrain Garay 18 October 2026

Playing summary

I use ComfyUI for the studio’s images and videos on this 16 GB card, and I had never compared it with Forge on the same machine. What I find about which of the two is faster is videos and opinions. Almost nobody runs both tools with the same files, the same seed and the same settings, and writes the time down.

Before measuring I found the first thing: the original Forge had its last commit on its main branch on June 26, 2025, and its code only has engines for SD 1.5, SD 2, SDXL, SD 3.5, Flux and Chroma. Its continuation is Forge Neo, which runs Z-Image, Qwen-Image and Wan 2.2. So I compared ComfyUI with Forge Neo on everything, and with the original Forge only where it can: SDXL.

Narrated: the 16 GB GPU as a room where the models fit or not. With SDXL, ComfyUI and Forge Neo tie at 6.7 s per image; with Z-Image Turbo, which does not fit, Forge Neo logs 7 s per image of memory management and ComfyUI is twice as fast; with Qwen-Image, 21 % less time.Watch it in the reel viewer →

What I measured, and under which rules

Before the first run I wrote down a measurement sheet with the models, the settings, the metrics and the decision rule, and I amended it in writing before every change.

  • Tools: ComfyUI v0.41.3 and Forge Neo (commit f7f23149), both with PyTorch 2.13 and Python 3.12, without xformers, SageAttention or FlashAttention. The original Forge (commit dfdcbab6) runs on its own stack, PyTorch 2.3.1 and Python 3.10, the one its installer sets up.
  • Models: SDXL base 1.0 in fp16 (1024², 30 steps, Euler, CFG 7). Z-Image Turbo in bf16 with its 4B Qwen3 encoder (1024², 8 steps, res_multistep, CFG 1, shift 3). Qwen-Image 2512 in fp8 with its 7B Qwen2.5-VL encoder (1328², 20 steps, Euler, CFG 4, shift 3.1). The same files in every tool.
  • Images: 12 fixed prompts and 3 seeds, 36 paired images per tool and model, in interleaved blocks (ComfyUI, Forge, ComfyUI, Forge…) with the server restarted between blocks.
  • Time: an outside stopwatch around each whole HTTP request, until the PNG is in hand. Separately, the cold start: from launching the process to the first image (with the process restarted, not with an empty disk cache).
  • Memory: the peak VRAM of the whole card and the peak RAM of the server’s process tree, sampled every 100 ms.
  • Rule: a tool is «faster» if the 95 % confidence interval of the median time ratio excludes 1 and the difference is at least 5 %; they «tie» if the interval fits entirely within ±5 %.
  • Baseline: diffusers without a UI, with settings as close as possible, as a reference for what generating costs with another library. It is a different engine, so it does not isolate the cost of the UI.

What broke before measuring

  • Port 8188 was already taken, by this machine’s production ComfyUI. The first test talked to that server, which does not have these models, and got an error back. The measured ComfyUI runs on 8288.
  • ComfyUI’s cache faked my first timing. In the smoke test, the first measured image took 0.05 s: the warm-up used the same prompt and seed, and ComfyUI reuses the outputs of nodes whose inputs did not change. Forge has no such cache. I fixed it before measuring: the warm-up uses a prompt outside the set, and the pairs are ordered so that two consecutive requests never share a prompt, so neither tool reuses the previous request’s text encoding. It is a real ComfyUI advantage when you repeat a prompt, but I did not measure it.
  • NixOS: Triton looks for the CUDA library through /sbin/ldconfig, which does not exist there, and Python could not find the certificates to download files. I solved it with TRITON_LIBCUDA_PATH and SSL_CERT_FILE.

Speed: they tie while the model fits

One image per lane at the measured pace: each tool fills its lane in its median seconds per image

SDXL · 1024², 30 steps · fits in the card real time

ComfyUI6.7 s/image
Forge Neo6.7 s/image
Forge (original)6.8 s/image
diffusers (baseline)6.8 s/image

Z-Image Turbo · 1024², 8 steps · 19 GiB of models for 16 GB ×2 sped up

ComfyUI6.8 s/image
Forge Neo13.4 s/image
diffusers (baseline)15.8 s/image

Qwen-Image 2512 fp8 · 1328², 20 steps · 28 GiB of models for 16 GB ×12 sped up

ComfyUI75.7 s/image
Forge Neo96.0 s/image

With SDXL there is no difference. ComfyUI and Forge Neo take 6.71 s per image, and the original Forge 6.76 s. All three comparisons tie under the rule: ComfyUI against Forge Neo gives a ratio of 1.004, with an interval from 0.997 to 1.007. The baseline, plain diffusers, takes 6.85 s, 2 % more than the tools.

With Z-Image Turbo, ComfyUI took 6.75 s and Forge Neo 13.4 s: the ratio is 0.506, with an interval from 0.502 to 0.510. With Qwen-Image fp8, 75.7 s against 96.0 s: 0.787, from 0.785 to 0.788. In both cases ComfyUI is faster under the rule. Image-to-image variation is low: between the 10th and 90th percentiles, the tools stray at most 4 % from their median (Forge Neo with Z-Image); diffusers with Z-Image reaches 15 %. The exception is the first measured image of each Forge Neo block: with Z-Image it took between 14.7 and 29.5 s and with Qwen-Image between 126 and 171 s, because the warm-up does not leave it in steady state. That is 3 of 36 images and it does not change the median.

Why: the weights, between RAM and the GPU

SDXL fits entirely in the card. Z-Image Turbo does not: its diffusion model weighs 11.5 GiB on disk and its text encoder 7.5 GiB. Neither does Qwen-Image: 19 GiB of model and 8.7 GiB of encoder. Each tool has to decide what it keeps on the GPU and when.

Where the time goes when the models do not fit in 16 GB
Where the time goes when the models do not fit in 16 GBSystem RAM · 31 GBGPU · 16 GBDiT · encoder · VAEDiT · encoder · VAEComfyUI: dynamic loading, 0 unloadsForge Neo: loads and unloads models per imageZ-Image TurboComfyUI6.8 sZ-Image TurboForge Neo13.4 sQwen-Image fp8ComfyUI75.7 sQwen-Image fp8Forge Neo96.0 srest of the imageForge Neo «Moving model(s)» time (its log)

The logs show two different strategies. ComfyUI v0.41 notes that it prepares each model for «dynamic VRAM loading», that it uses «async weight offloading with 2 streams» and, from the first image on, «0 models unloaded»: its model-unload counter stays at zero. That does not mean it moves no weights, only that it does not do it by unloading models. Forge Neo, on every image, writes three «Moving model(s) has taken X seconds» lines and partial unloads of several GB («Unloaded partially»); that stopwatch covers all the memory management when loading models, not just the copies. With Z-Image those three lines add up to a median of 7.2 s per image, and the gap between the two tools is 6.6 s: the two numbers are the same size, which is consistent with that management explaining the gap. With Qwen-Image they add up to 9.4 s of a 20.3 s gap; I suppose the rest comes from computing with part of the model still in RAM, but I did not measure that.

The baseline points the same way. When the model does not fit, diffusers moves whole models between RAM and the GPU (enable_model_cpu_offload), and with Z-Image it took 15.8 s per image: more than Forge Neo and more than twice ComfyUI.

Quality: practically the same image

With the same seed, ComfyUI and Forge Neo give practically the same image on all three models, with differences in details and in drawn text, a sign that they generate the initial noise the same way. The original Forge and diffusers give a different composition with the same seed, just as valid. The CLIP score of each image against its prompt ranges from 24 to 42 depending on the image, and its average per tool stayed between 30.0 and 30.9. CLIP measures how close the image is to the text, not its aesthetic quality: all I can say is that the averages were close on this set, with no equivalence test.

Three prompts with the same seed in Z-Image Turbo: ComfyUI and Forge Neo give the same image; diffusers, another composition.
Z-Image Turbo, same prompts and seeds: ComfyUI, Forge Neo and diffusers.

Cold start and memory

From launching the process to the first image, ComfyUI was faster on both models that do not fit: with Z-Image, between 24 and 29 s against 37 to 55 s for Forge Neo; with Qwen-Image, between 100 and 121 s against 127 to 147 s. With SDXL, all of them take between 10 and 23 s.

In video memory, ComfyUI gets closer to the ceiling: a 15.5 GiB peak with Z-Image and with Qwen-Image, against 13.9 and 14.2 GiB for Forge Neo. In system RAM they are even: about 21 GiB with Z-Image for both, and 25.6 against 27.1 GiB with Qwen-Image. This machine has 31 GB of RAM, so Qwen-Image fp8 leaves it almost full.

A curiosity: Wan 2.2

I ran a single video clip per tool, with the recipe I already use on this card: Wan 2.2 A14B in GGUF Q5_K_M (high and low noise models), 832x480, 81 frames (5 s at 16 fps), 20 steps switching model at step 10. ComfyUI took 877 s and Forge Neo 932 s, and the two videos look very much alike (a frame at 2.5 s from each in the gist). In a first run Forge Neo switched model at step 18 instead of 10, because by default it times that switch by noise level, not by steps; the audit caught it and I repeated its clip with the switch by steps. It is a single clip per tool, so it is not enough to claim one is faster.

Threats to validity

  • A single card, a single machine with 31 GB of RAM and one operating system (NixOS). With more RAM or a 24 GB card the order may change.
  • Both tools change every week. What I measured holds for the pinned versions; Forge Neo may adopt something like ComfyUI’s dynamic loading.
  • I used each tool’s default settings, and they are not symmetric: ComfyUI uses the cudaMallocAsync allocator by default and Forge Neo the native one. Forge Neo suggests --cuda-malloc in its log and has --pin-shared-memory and --cuda-stream; I did not test them.
  • The block order was fixed (ComfyUI first) and there were only three restarts per tool; I did not control the card’s temperature or clocks.
  • I measured the original Forge only with SDXL, and on another PyTorch version.
  • The Z-Image baseline uses the official repository in diffusers format and its default scheduler, because diffusers has no res_multistep; there is no baseline for Qwen-Image fp8.
  • The memory-management explanation rests on the times the logs themselves record, not on an experiment that changes it.
  • Wan 2.2 is a single run per tool.

Verdict

On this 16 GB card and with these models: with SDXL, which fits entirely, ComfyUI, Forge Neo and the original Forge take the same time, and ComfyUI and Forge Neo also give practically the same image with the same seed. With Z-Image Turbo and Qwen-Image fp8, which do not fit, ComfyUI was faster: twice as fast with Z-Image and 21 % less time per image with Qwen-Image, and its logs point to how it manages memory. Forge Neo is still the way to use Forge with these models, and the original Forge has fallen behind.

Frequently asked questions

ComfyUI vs Forge: which one is faster?

It depends on whether the model fits in the card. With SDXL, which fits entirely in 16 GB, ComfyUI, Forge Neo and the original Forge tie: 6.71, 6.71 and 6.76 seconds per image. With Z-Image Turbo, whose model and text encoder add up to 19 GiB, ComfyUI took 6.75 s and Forge Neo 13.4 s. With Qwen-Image in fp8, about 28 GiB between model and encoder, 75.7 s against 96.0 s.

Why is ComfyUI faster when the model does not fit?

The logs point to memory management. ComfyUI v0.41 writes «dynamic VRAM loading» and its unload counter stays at «0 models unloaded»; Forge Neo writes three «Moving model(s) has taken X seconds» lines per image, which with Z-Image add up to 7.2 s, the same size as the 6.6 s gap between the two. With Qwen-Image they add up to 9.4 s of a 20.3 s gap. It is consistent with that explanation, but I did not test it by turning anything off.

Is Forge still around?

lllyasviel's original Forge had its last commit on its main branch on June 26, 2025, and its code only has engines for SD 1.5, SD 2, SDXL, SD 3.5, Flux and Chroma: not Z-Image, Qwen-Image or Wan 2.2. Its active continuation is Haoming02's Forge Neo, which supports them. I measured the original only with SDXL.

Does image quality change between ComfyUI and Forge?

In my images, ComfyUI and Forge Neo give practically the same image with the same seed, with differences in details and in drawn text. The average CLIP score against the prompt stayed between 30.0 and 30.9 for every tool; that measures how well the image matches the text, not aesthetic quality.

And with video, Wan 2.2?

I ran it once, as a curiosity: an 81-frame 832x480 clip with Wan 2.2 A14B in GGUF Q5_K_M took 877 s in ComfyUI and 932 s in Forge Neo. With a single clip there is no way to say one is faster.

Can I reproduce it?

Yes. The sheet with the rules set before measuring and its five amendments, the prompts, the measurement harness, the baseline, the scoring and the raw timings are in the repository and in a gist linked in the sources.

Sources

Measured on October 18, 2026 on a 16 GB RTX 4070 Ti SUPER (Ada, sm_89) with 31 GB of RAM, on NixOS. ComfyUI v0.41.3 (8713616), Forge Neo f7f23149, original Forge dfdcbab6, diffusers 0.41.0; PyTorch 2.13.0+cu130 (the original Forge, 2.3.1+cu121). 36 images per tool and model: 12 prompts and 3 seeds.

NEWSLETTER · MEASURED

A new measurement, when there is one.

Each post with its numbers, its failures and the scripts to repeat it. One to three emails a month. Unsubscribe with one click.

LATEST

I run Listmonk on my own server; your address stays there. You confirm by email before getting anything.

Comments

No comments yet. The first one is yours.

Reviewed before publishing. The email is not stored and never appears anywhere.