Qwen-Image-2512 on the 780M, and the 'Qwen-Image-2.0' that isn't real
I wanted to test a current open-weight image model on the same 780M box that’s already running LTX Video and MiniMax Music3 through ComfyUI-TheRock. Krea 2 came up as an obvious candidate: open weights since June, FP8 quantization small enough for the box’s 32GB of shared memory. Before settling on it, I checked what else was worth comparing.
A model that doesn’t exist for download
The comparison turned up Qwen-Image-2.0, announced in February with numbers that read well: 7B parameters, Apache-2.0, native 2K output. Several write-ups described it as open-weight, and every one of them was wrong. A GitHub issue on ComfyUI’s own repo, requesting support for the model, got a one-line answer from a maintainer: it’s not an OSS model.
Alibaba’s actual open releases use a different naming scheme, dated by year and month rather than a semantic version number. The real, downloadable model, currently the strongest open-source option by Alibaba’s own blind-evaluation numbers, is Qwen-Image-2512: a December 2025 update to the original 20B model from August. The “2.0” coverage was accurate about the announcement. It described a product that exists only behind Alibaba’s own API.
Setup
ComfyUI-TheRock already had Qwen-Image’s architecture built in, along with the ComfyUI-GGUF node needed for a quantized version small enough to fit. Three files, about 22.87GB total: the diffusion model at Q4_K_M (13.24GB), the Qwen2.5-VL-7B text encoder at fp8 (9.38GB), and the VAE (0.25GB). Q4_K_M leaves roughly 9GB of headroom in the 32GB shared pool, which matters more here than on a discrete GPU: there’s no separate VRAM to fail into if something goes over budget, just the same memory everything else on the machine needs too.
First generation
A 1024x1024 image at 20 steps took 19 minutes and 41 seconds. The startup log explains most of that: 6022MB of the model loaded onto the GPU, 6716MB staged in system memory and swapped in as needed, roughly half the weights moving back and forth every step. Steps landed at a steady 57 seconds each. Step two took almost exactly as long as step one, ruling out one-time warmup as the explanation. The constant swap between GPU memory and system memory sets the pace here.
That lands next to SDXL’s ~4.1 seconds per step at the same 1024x1024 resolution on the same chip: roughly 14 times slower per step, for a model with something like eight times the parameter count before quantization. SDXL fits inside VRAM whole, where Qwen-Image-2512 doesn’t even at Q4_K_M, and that difference accounts for most of the gap.
VAE decode finished cleanly. Worth mentioning only because the ZLUDA setup on this same chip used to hit a real cuDNN crash at exactly this step, one of two open issues that post never fully closed.
Testing against real sprites
The next test used actual game assets: P1 and P2, the two chibi characters from Craymel Ball, with sprite sheets already sitting on disk from earlier work. One generation ran from a plain text description. A second ran img2img against a real sprite frame, cropped down to a single clean pose and upscaled from its native 120px height.
Img2img came out faster. The reason took some checking: denoise below 1.0 doesn’t reduce the step count in this ComfyUI build, the progress bar shows the full 20 steps regardless of the setting. The real difference was resolution. The sprite frames were 512x768 and 432x768, well under the first test’s 1024x1024, and fewer pixels brought the per-step time down from 57 seconds to about 33. The img2img output kept the actual outfit colors and silhouette in a way the text-only version, working from a description alone, couldn’t match.
A scene from the art plan
A last generation aimed further from a toy prompt: a photorealistic dusk street scene, built from the art direction document for a private worldbuilding project of mine. That document specifies its target look in real detail: an orange-to-navy sunset gradient, backlit silhouettes, power lines strung between poles, vending machines doubling as light sources, a red postbox, an oden stall, a bathhouse entrance. It’s written for a stylized, hand-drawn-inspired in-game look. The color and composition brief still translated directly into a text prompt. At 1280x768, 20 steps, this one took about 17 minutes, close to the first test despite the different aspect ratio, since the pixel count landed in the same range.
Result
Four generations landed on one real number: a 20B-class model runs on integrated graphics with no dedicated VRAM, at 15 to 20 minutes per image depending on resolution. The bottleneck is the constant swap between roughly 6GB of loaded weights and the rest sitting in system memory. A smaller quantization would likely close part of that gap. Dropping resolution below 768px on the long edge would close more of it, at some cost to detail.
Half an hour of research before any of this pointed at a model that isn’t available for download. A two-line comment on a GitHub issue turned out more reliable than any of the several articles covering the announcement.