The one-line verdict: On a 24 GB laptop GPU we got 12 of the newest open-weight generative model lines running across 21 measured configurations (image / image editing / video / video+audio / music / image-to-3D) — and proved with a controlled experiment that NVFP4 is the best quantization format for this machine: 22% faster and 27% smaller than INT8, with a quality difference that sits below the random seed noise floor.

This is not a "copy-paste the commands" tutorial. The hard part is never getting one model to run — it is deciding which of dozens of quantization variants to pick. This document lays the whole decision chain bare: how we reasoned, how we downloaded, how we built the graphs, how we measured, how we chose. Every number is measured on the machine, and every conclusion ships with a reproducible method.

🎯 Three ready-made plans (pick from the charts)

Four charts covering all 21 measured configurations. Every recommendation below uses only commercially usable (or clearly flagged conditional) models — the non-commercial YuE2, FLUX.2 Klein 9B and FLUX.1-dev have been removed from the recommendation slots and are only marked ❌ in the licence matrix.

Plan 1 · Best quality

The best producer per domain. If you are outside the US/EU/UK/KR block, video goes to MiniMax H3; otherwise Wan 2.2 5B.

Plan 2 · Efficiency first (best overall value)

Best time-per-quality. All Apache 2.0, no territory limits, no revenue threshold — the zero-friction set.

Plan 3 · Scenario matrix

Look up your specific scenario. Your need on the left; the current best answer and its licence boundary on the right.

Licence matrix

Check before commercial use. "The weights download" ≠ "the output is commercially usable".

Contents

0. Hardware and starting point

Why start at 24 GB? Because it is the only genuinely hard constraint in this document.

Raw compute on a modern laptop GPU is never the problem — an 8-step distilled model renders a 1024² image in about ten seconds on a 5090. What decides which models you can and cannot run is whether the weights fit in VRAM. And the newest generation of open-weight generative models shares a trend: the base model keeps getting bigger, and it now demands a separate text encoder that is just as big.

Look at the chart below. Note the 24 GB red line.

Three of these files — MiniMax H3's DiT at 21 GB, HunyuanVideo 1.5 at 16.7 GB, and MiniMax H3's text encoder at 15.7 GB — each individually exceeds 24 GB. Which means:

They can never be resident. On every single step, weights must be shuttled between VRAM and system RAM. That is why "picking the right quantization format" on this machine is not an optimization. It is the difference between running and not running.

1. TL;DR: the verdict

1.1 Selection table

The quantization answer does not change: if the GPU is Blackwell (sm_120/121), always pick NVFP4. Proof in §5.

1.2 Three rules you can apply immediately

1. Quantization: if the GPU is Blackwell (sm_120/121), always pick NVFP4. Proof in §5.
2. Offload or not: sum the base model and the encoder, and compare against VRAM. If the sum exceeds it, offloading is mandatory — and then every gigabyte quantization saves converts directly into speed.
3. Speed comes from fewer steps, not from smaller weights. An 8-step → 4-step LoRA buys far more than any weight quantization. Quantization makes the model fit; a distilled LoRA makes it fast. These are different problems.

2. How we reasoned: framing the constraint

2.1 The only hard constraint is VRAM, not compute

This deserves emphasis, because it determines every subsequent trade-off.

The common intuition — "if VRAM is short, use a smaller model" — does not apply here. The models we want are the newest and strongest, and they have no small variant. The only free variable is how many bits each weight occupies.

So the problem compresses into one sentence: what is the fewest bits per weight that costs nothing visible to the eye?

2.2 The four families of quantization (this is the foundation)

The phrase "4-bit quantization" lumps together three completely different things. Separate them first.

The most important row in that table is the first one.

W4A16 shrinks the weights but must expand them back to 16-bit to compute, so you save memory but save zero compute — and you pay extra dequantization overhead on top. This is exactly why people report "I switched to a 4-bit model and it got slower."

Remember it this way: W4A16 saves memory. W4A4 / NVFP4 save memory and bandwidth. Only the latter actually goes faster.

NVFP4 wins on this machine because it is Blackwell's native 4-bit floating-point format: it feeds tensor cores directly for 4-bit matrix multiplication, with no "expand first, then compute" round trip.

2.3 How to tell real NVFP4 apart (never trust the filename)

This is a trap we walked into. A great many community files named fp4 or nvfp4 are actually a different format, or only partially 4-bit.

The only reliable test is the tensor keys inside the safetensors file. Open the header (first 8 bytes, little-endian uint64 = header length → JSON) and look for this set:

weight_scale
weight_scale_2
input_scale
pre_quant_scale
TensorCoreNVFP4Layout   (group_size = 16)

A verified real NVFP4 file on this machine shows both F8_E4M3 (for block scales) and U8 in its dtype list. For example:

z_image_turbo_nvfp4.safetensors    4.51 GB   993 tensors   BF16, F32, F8_E4M3, U8   ✅ real NVFP4
qwen_3_4b_fp4_mixed.safetensors    3.48 GB  1081 tensors   BF16, F32, F8_E4M3, U8   ✅ real NVFP4

The decision tree below is the complete selection logic:

3. How we downloaded: moving several hundred GB

Downloading looks trivial until you multiply hundreds of gigabytes by unstable mirrors. A naive implementation can spend a whole day on it. We ran two batches: the first at 34 files / 125.6 GB, the second at 66 files / 332.8 GB (the four music lines + Wan 2.2 14B + HV1.5 super-resolution + Stable Audio 3) — both with zero corruption, built on three mechanisms.

3.1 Throughput, measured

The gap is an order of magnitude: modelscope is 7× faster than hf-mirror and 12× faster than huggingface. Multi-source fallback is therefore not a nicety — it is mandatory.

3.2 Mechanism one: three-tier fallback

Each file tries:  www.modelscope.cn  →  hf-mirror.com  →  huggingface.co

If a source fails, fall through to the next. The .part resume file is reusable across sources (both ends serve byte-identical content — verified).

3.3 Mechanism two: a silent watchdog (this one is essential)

This was our deepest trap.

We originally set a 45-second socket timeout. Then a file sat at 4.6%, 0.0 MB/s, for 19 minutes without raising a single error. The cause is nasty: the server dribbled a few KB every 30 seconds, which was just enough to keep the socket alive while making no real progress.

Lesson: a socket timeout cannot catch a "slow drip" stall. You need a second, application-level watchdog: if the byte count makes no real progress for 150 seconds, actively disconnect and retry; after 3 consecutive silent stalls, abandon that source and let the caller switch.

With this layer in place, the same network conditions never produced another infinite hang.

3.4 Mechanism three: Range probing and concurrency

modelscope does not support HEAD requests, so you cannot get a file size the normal way — and without a size you cannot verify anything. The fix is to range-request a single byte and read the total from the response header:

Range: bytes=0-0
→  HTTP/1.1 206 Partial Content
   Content-Range: bytes 0-0/16748116224        # ← the true byte count

Once you have the expected size, three things become possible:

1. Probe sizes concurrently (probe only, no download) → know the total and prioritise early
2. Compare byte counts after download → detect truncation and corruption precisely
3. Cross-validate two sources → the same file should report the same size on both

3.5 A meta-lesson: never probe source health during a download peak

We got this wrong once. While four parallel downloads were saturating the link, we probed the other sources — every probe timed out, and we concluded, incorrectly, that "both mirrors are unavailable, so the user must download manually."

They were perfectly healthy. The bandwidth was simply fully consumed.

Lesson: probe requests (speed tests, availability checks) and download requests compete for the same bandwidth. Either probe while idle, or rate-limit the probes separately.

4. How we built: ComfyUI node constraints

With the models on disk, the next job is turning them into a runnable graph. ComfyUI's official workflows live in two places:

• ComfyUI/blueprints/*.json — 116 official blueprints
• site-packages/comfyui_workflow_templates_json/templates/ — the same set

But they cannot be submitted as an API prompt directly, because they are in subgraph format: node types are UUIDs, and the real topology is buried inside definitions.subgraphs. We wrote bp_dump.py to flatten a subgraph into a node-and-wire listing — far more reliable than guessing the topology by hand.

4.1 Four node constraints you must know

Points 3 and 4 were our biggest correction of an assumption: when you see ImageToVideo, first check whether the image input is optional. If it is, the node also works as text-to-video.

4.2 What to do when there is no official blueprint

HunyuanVideo 1.5 has no official blueprint. You have to build the graph by hand from node signatures. Order matters:

1. Check DualCLIPLoader's type list to confirm hunyuan_video_15 exists
2. Confirm the latent channel count (1.5 uses 32 channels and spatial downsampling of 16 — unlike 1.0)
3. After building, run the free validation trick below

4.3 A free graph-validation trick (highly recommended)

While models are still downloading, a direct POST /prompt returns HTTP 400 with per-node node_errors. The key insight:

If the only errors are value_not_in_list — meaning "that model file is not in the list" — then the graph's structure and types are entirely correct.

That gives you a zero-cost dry run: you can validate a workflow before its weights finish downloading. All seven workflows in this project were validated this way before the downloads completed.

5. How we measured: the controlled A/B (the core of this document)

This is the most valuable section here, because we got it wrong the first time.

5.1 A plausible conclusion that was wrong

In the first comparison we ran two Z-Image-Turbo variants (int8 and nvfp4) and got:

PSNR = 13.82 dB

What does 13.82 dB mean? Conventionally, anything below 20 dB means "two visibly different images." Our conclusion at the time: "4-bit quantization really does degrade quality. NVFP4 is not good enough."

That conclusion was wrong, because we made a methodological error:

❌ The two variants used different text encoders. The int8 build was paired with qwen_3_4b.safetensors (bf16); the nvfp4 build with qwen_3_4b_fp4_mixed.safetensors (fp4).

So encoder differences were baked into that 13.82 dB. Quantization was never the culprit.

5.2 Why PSNR cannot be used naively on generative models

Before fixing the method, you have to internalise a counter-intuitive fact:

Diffusion sampling is chaotic.

Two models whose values agree to four decimal places will produce two completely different compositions after 8 sampling steps. This is not a bug — it is the nature of the process; sampling keeps amplifying tiny differences.

So "these two images have low PSNR" does not prove "one of them is worse." It only proves "these are two different samples."

To judge whether quantization damages quality, you need something else entirely: a noise baseline.

5.3 Designing the four-way control

We isolated the variable completely — identical encoder, identical prompt, identical 1024²/8-step configuration, with only the DiT quantization differing — and then added two "only the random seed changed" controls:

The test: if cross similarity is higher than seed similarity, then the perturbation caused by quantization is smaller than the randomness of sampling — meaning quantization error is negligible.

5.4 Results

5.5 Three hard conclusions

Conclusion one: the pipeline is deterministic.

The det arm measured PSNR = ∞ — the two images are byte-for-byte identical. This single fact is what makes the whole experiment attributable: since identical inputs necessarily produce identical outputs, the difference in the cross arm is 100% attributable to the quantization format itself, with zero runtime noise mixed in.

Had this failed — had a re-run produced a different image — then no cross-quantization difference could be attributed to anything, and the experiment would have been worthless.

Conclusion two: quantization perturbation < sampling noise.

cross difference (7.41%)  <  seed difference (16.89%)

Changing the quantization format alters the image less than picking a different random seed. That is the hard evidence that quantization is not costing quality.

Conclusion three: quality proxy metrics show no systematic difference.

PSNR is sensitive to trajectory divergence, so we measured five robust proxies as well:

The spread caused by changing only the seed within one quantization (int8: 776.5 → 705.4) already covers the entire cross-quantization difference (776.5 → 694.3). In other words: the quantization factor is drowned inside the seed factor's variance.

Color histogram L1 distance agrees:

det = 0.0000   |   cross = 0.0858   |   seedB = 0.1085   |   seed = 0.1256
                    ↑ cross-quant          ↑ within-seed      ↑ within-seed

The color-distribution difference across quantizations is smaller than the difference caused by changing the seed.

5.6 Final review: do they look the same?

Numbers aside, we did a human eye check. Four images laid out 2×2, deliberately arranged so that reading down a column = same seed, different quantization and reading across a row = same quantization, different seed:

┌──────────────────────┬──────────────────────┐
│  INT8  · seed 20260922│  INT8  · seed 20260923│
├──────────────────────┼──────────────────────┤
│ NVFP4  · seed 20260922│ NVFP4  · seed 20260923│
└──────────────────────┴──────────────────────┘
       ↑ column: same seed, cross-quant   ↑ row: same quant, cross-seed

The result matches the numbers exactly:

• Down a column (same seed, cross-quantization) → highly similar compositions (both expose the same distant rock spires on the left)
• Across a row (same quantization, different seed) → entirely different compositions

All four are competent, high-quality Huangshan sunrise renderings — semantically correct, richly detailed, free of artifacts. Quantization is not the variable. The seed is.

5.7 The methodology, distilled (reusable for any model)

Any "does quantization hurt quality?" comparison must satisfy three conditions:

1. Controlled: encoder, prompt, resolution, steps, sampler, and CFG all fixed — change one variable at a time
2. Has a noise baseline: you must also measure "same quantization, different seed", or you cannot separate quantization perturbation from sampling randomness
3. Has a determinism check: "same quantization + same seed" must reproduce byte-identically, or the conclusion is not attributable

Miss any one of these and the PSNR number will be misread.

6. How we chose: eight model lines in practice

6.1 Image generation — Z-Image-Turbo vs Qwen-Image 2512

Both lines run, and their results are close — so we need to explain why we keep both.

Z-Image-Turbo (the daily driver)

Its real advantage is a single point, but a hard one: the whole 8.33 GB stays resident in 24 GB, with zero offload. No step ever needs weights shuffled between VRAM and system RAM — the least fussy option for heavy, continuous use.

Qwen-Image 2512 + Lightning (high resolution / Chinese text)

It wins on two points:

1. Higher resolution: 1328² carries 68% more pixels than Z-Image's 1024², at slightly less time (12.2 s vs 13.8 s)
2. Chinese text rendering verified character by character: we rendered 「春风得意马蹄疾 / 一日看尽长安花」 plus 「茶香四溢 静心品茗 八方来客 岁月悠长」 and got 30/30 characters exact, zero typos, zero missing strokes (202.7 s / 50 steps)

⚠️ A correction to our own earlier work: an early version of this document listed "accurate Chinese text rendering" as a reason to pick Z-Image-Turbo. That was wrong. The 30/30 acceptance run above used Qwen-Image 2512, not Z-Image; Z-Image's Chinese rendering ability was never tested on its own. That early version also never mentioned Qwen-Image at all — an omission, now fixed here.

Verdict: keep both, split by use case.

• Frequent sketches, clean VRAM budget → Z-Image-Turbo (8.33 GB fully resident)
• High-resolution output, Chinese text in frame → Qwen-Image 2512 + Lightning

Worth recording separately: the Lightning LoRA took the same model from 206.7 s to 12.2 s — 16.9× faster — with detail, if anything, more present. This again confirms the §2 rule: speed comes from fewer steps, not from smaller weights.

6.2 Image editing — FLUX.2 Klein 4B

A counter-intuitive finding: BFL's official fp8 single file is only 4.07 GB, whereas the bf16 build is 7.75 GB — fp8 costs essentially nothing in quality and halves the size. When a vendor ships the good stuff directly, take it.

An even more counter-intuitive point: the 9B NVFP4 build is only 5.76 GB — smaller than the 4B bf16 build (7.75 GB). A bigger model in a smaller file. That is the value of 4 bits.

6.3 Video + audio — MiniMax H3

This is the heaviest line here, because it generates picture and sound together.

Offloading is mandatory. The DiT (21 GB) plus the encoder (15.7 GB) is 36.7 GB — far beyond 24 GB. So every generation shuttles weights between VRAM and RAM. That, not raw compute, is why it takes 519 seconds.

Output verification (a step you must not skip): ffprobe confirms h264 / 1344×768 / 24fps / 5.17 s + aac 32 kHz stereo. Extracting four frames into a contact sheet shows the imagery matching the prompt's timeline (an RGB-split "COMFYUI" title → chrome palm trees → sunset). This is not noise. It is usable video with usable audio.

6.4 Video only — three lines, each with one hard reason

We ran three video-only lines, and the conclusion is clean: they do not replace each other, they are three different trade-offs.

LTX-Video 2B distilled — the fastest

19.2 seconds for 5 seconds of 1216×704 video — the fastest we measured, 18× faster than Wan 2.2 5B. The cost is noticeably smaller motion: the frames are stable and semantically correct (teacup, bamboo tray, rain-streaked window all present), but the push-in is very gentle. Good for "check the composition and style fast"; not for "I need visible action".

Wan 2.2 5B TI2V — the best quality

This is the best video quality of the whole round. With one prompt (a hummingbird hovering at red flowers, wings beating fast, slow lateral camera move), the output shows clear motion blur on the wings, the bird's position changing frame by frame, and correct depth-of-field layering — every element of the prompt landed in the picture. The cost is speed: 355 seconds for 5 seconds.

wan2.2_ti2v_5B stands for TI2V = Text + Image to Video — it does both. This also confirms the general observation from §4.1: when a node is called ImageToVideo, first check whether its image input is optional — Wan22ImageToVideoLatent.start_image is optional, so leaving it unconnected gives you pure text-to-video.

Wan 2.2 14B MoE — the flagship tier, genuinely runnable with a 4-step LoRA

What this line proves is that a flagship MoE video model is usable on a 24 GB laptop. The two experts total 28.6 GB, far beyond VRAM, but because only one expert is loaded per step, combined with the LightX2V 4-step LoRA (collapsing 20 steps into 4), it actually finishes in 94 seconds.

⚠️ Trap we hit (worth recording separately): we substituted the template's wan_2.1_vae with the wan2.2_vae we already had, and VAEDecode failed immediately:

Given groups=1, weight of size [48, 48, 1, 1, 1],
expected input[1, 16, 21, 60, 104] to have 48 channels, but got 16 channels instead

Root cause: Wan 2.2's 5B line and 14B line do not use the same VAE (5B → wan2.2_vae, 14B → wan_2.1_vae), and the two have different channel counts (48 vs 16). Only the official templates settle it — every video_wan2_2_14B_* template points at wan_2.1_vae, and only the video_wan2_2_5B_* ones point at wan2.2_vae. Lesson: a similar filename is not a substitute. Use exactly what the template specifies.

HunyuanVideo 1.5 — cinematic, with built-in 1080p super-resolution

⚠️ On the 720p tier, we have to report a negative result. We ran the official 720p → 1080p super-resolution pipeline end to end (base 20 steps + SR 8 steps) and on a 24 GB laptop it ran a full 70 minutes without finishing, so we terminated it — which is itself the finding:

The 720p + SR path is not viable on a 24 GB laptop. No single step of the official template is "slow but bearable" — the baseline is simply far outside the acceptable range. If you need 1080p, the practical route is to render at 480p/720p and then use a separate upscaling pass, or switch to a line with no extra SR stage such as Wan 2.2 or LTX.

We state this explicitly because "it does not run" and "it runs slowly" are different kinds of information, and community workflow posts overwhelmingly report only successes. This path is infeasible on 24 GB — that is its only conclusion.

⚠️ A crucial conceptual distinction: 480p / 720p / i2v / SR are four different base models, not one model at different resolutions. The resolution in the filename is part of the model's identity.

Its most distinctive feature is that the official 720p template is itself a 720p → 1080p super-resolution pipeline: the base produces 1280×720 → LatentUpscaleModelLoader upscales the latent to 1920×1080 → a dedicated SR distilled model (8 steps, split at 4 by SplitSigmas) refines it, and both resolutions are saved as separate videos. In other words this line produces true 1080p, not a 720p upscale.

Four-step generation is the biggest win at the 480p tier — 117 seconds for 5 seconds of video, usable as an iteration sketch. Recommended workflow: prototype prompts at 480p, then commit to 720p.

Output verification: ffprobe confirms h264 / 848×480 / 24fps / 121 frames / 5.04 s. A frame contact sheet shows a temporally stable, subject-consistent result — "a pottery studio: the wheel slowly turns, wet clay is pulled taller into a vase between two hands, warm rim light from the left, blurred wooden shelves of bisque ware behind" — every element of the prompt is present.

Same-prompt comparison (this matters more than the table above)

The table above lists each config separately. A real comparison needs the same prompt — we ran all three lines on one identical Chinese prompt ("extreme close-up: a hummingbird hovers at red flowers sipping nectar, wings beating fast, sunlight through the petals, bokeh background, slow lateral camera move"):

LTX produced an entirely unrelated scene — not a rendering error, the prompt was simply not followed. We ran a three-step diagnosis:

1. Switch to the English version of the same prompt → still the same coastline → rules out "Chinese not supported"
2. Change the seed (20260922 → 777) → still the coastline → rules out bad luck
3. Switch to a completely different common prompt ("a red sports car driving on a desert highway at sunset") → the output became a parking lot / road (road, arid terrain — but no car)

Conclusion: LTX-Video 2B distilled at CFG=1 / 8 steps has very weak prompt adherence. It captures the broad scene type (outdoor, road, arid) but not specific subjects (a hummingbird, a sports car). The cause is the configuration we chose for speed — distilled + CFG-free + 8 steps — and that speed is paid for with prompt adherence.

This is the most important counter-example in the document: "it runs fast" and "it is usable" are two different things. LTX is 18× faster, but at CFG=1 / 8 steps it cannot reliably render what the prompt asks for. If you need prompt adherence, either raise CFG/steps (and get slower) or use Wan / MiniMax H3.

Choosing between the three

6.5 The one that does not run — FLUX.2 Klein 9B

This is the only line we could not get running, and the reason is instructive.

The error:

mat1 and mat2 shapes cannot be multiplied (1024x7680 and 12288x4096)

Root cause: the 9B model needs a Qwen3-VL text encoder of roughly 16.4 GB, and BFL ships it only in diffusers sharded format — which ComfyUI cannot load.

This is not a VRAM problem, and not a quantization problem. It is a weight-packaging problem. Three ways out:

1. Wait for ComfyUI's official single-file packaging of the encoder
2. Merge the diffusers shards into a ComfyUI-loadable single file yourself (16.4 GB download plus a conversion script)
3. Use the 4B — 42.3 seconds per image, and it is enough

Lesson: when picking a model, check not only "does it fit in VRAM" but also "is its weight format loadable by my tooling?" Many people overlook this precondition.

6.6 Music generation — a whole field filled in from zero

This was the biggest coverage gap: image and video were done long ago, while music had not been touched at all. (Worth distinguishing: MiniMax H3's audio track is video accompaniment — sound effects and ambience; it is not "generate a song from lyrics".)

We ran all four music lines that ComfyUI 0.37 supports natively:

Output verification (all checked with ffprobe):

ace15_turbo_song      mp3  48 kHz stereo  60.00 s  245 kbps
ace15_xl_turbo_song   mp3  48 kHz stereo  60.00 s  231 kbps
yue2_text2music       flac 48 kHz stereo  60.00 s
minimax_music3_song   mp3  44.1 kHz stereo 59.99 s

How to choose:

• Need commercial use → ACE-Step 1.5. Apache 2.0 means no revenue threshold, no territory exclusion — that is its biggest asset. It is also the fastest (29 seconds for a 60-second song), making it the best combined choice on quality / speed / licensing.
• Need the best full-song quality and it is not commercial → YuE2. It is the only one with a two-stage structure ("an LLM plans an ABC score first, then audio is generated") and it tops the benchmarks; but cc-by-nc forbids commercial use.
• MiniMax Music 3 is quality-oriented but 16× slower — not worth it unless you have a specific reason.

An easy licensing trap: open music models have far messier licences than video/image models. Several popular ones (MusicGen, early Stable Audio Open) are CC-BY-NC — the weights download fine, but the output cannot be used commercially. "It runs" and "you may use it" are two different things here.

6.7 Image → 3D — Hunyuan3D 2.1

The pipeline is three chained steps: first Z-Image renders a clean object image (a blue-and-white porcelain teapot on a plain white background, 15.0 s), it is copied into input/, then image-to-3D runs.

Output verification (parsing the GLB binary header + JSON chunk directly):

magic = "glTF"  version = 2  file length = 8,701,344
meshes = 1
  primitive: vertices = 202,768   triangles = 522,140
materials = 1   nodes = 1

A usable 520k-triangle mesh — not a point cloud, not voxel blocks, but a standard glTF 2.0 asset with a material, ready for Blender or a game engine.

6.8 Benchmark summary

All times are read from ComfyUI's server-side execution_start / execution_success timestamps — never wall-clock time or API round-trip time, which would fold queueing and model-loading into the number and inflate it.

Image

Video

Music / 3D

An honest note: we timed Z-Image twice and got 20.9 / 15.8 s and 17.7 / 13.8 s. Run-to-run variance in absolute terms is about ±15% (a laptop GPU throttles against thermal and power limits), but the relative result — nvfp4 is 22–25% faster than int8 — held in both runs.

When reporting performance, relative percentages are far more trustworthy than absolute values.

7. Optimization checklist (configs you can copy)

7.1 Ordered by payoff

7.2 Two VRAM traps you must know

Trap one: ComfyUI does not release models on its own. After generating one image, the model is still resident. Chaining a second generation — especially a video — very easily OOMs. Fix: call POST /free {"unload_models": true, "free_memory": true} before each submission.

⚠️ Note that /free returns an empty body. Do not try to parse it as JSON, or you will get a JSONDecodeError.

Trap two: the transient peak in VAE decoding. VAE decoding of high-resolution images or video creates a transient VRAM spike on the final step (several GB), producing the classic "the transformer finished and then it died at the last step." Fix: use VAEDecodeTiled.

8. Troubleshooting table

9. Toolchain

9.1 Tools

9.2 Quick start

# 1) Assumes ComfyUI is already serving on http://127.0.0.1:8188

# 2) Probe sizes and budget time first (downloads nothing)
python scripts/probe_more.py

# 3) Download the models (three-tier fallback)
python scripts/dl_more.py --workers 4

# 4) Three-layer validation (bytes + structure + dtype)
python scripts/verify_models.py --refresh

# 5) Convert an official template to an API workflow, then derive variants
python scripts/ui2api.py video_wan2_2_5B_ti2v.json -o wf.json
python scripts/mk_wf.py wan_smoke wan_full ltx_full hv15_720 hy3d

# 6) Run a batch sequentially (GPU serialized, per-job timeout)
python scripts/run_batch.py "workflows/wan22_5b_t2v_full.json@900"

# 7) Run a controlled A/B (same encoder, quantization is the only variable)
python tools/compare_ab.py
python tools/ab_metrics.py

9.3 Repository layout

.
├── README.md              # Chinese
├── README_EN.md           # English (this file)
├── index.html             # Online edition (adapts to your browser language)
├── assets/
│   ├── zh/                # Chinese charts (used by README.md)
│   └── en/                # English charts (used by README_EN.md)
├── data/                  # Raw measurements
├── docs/                  # Deep dives
├── scripts/               # Reproducible scripts
├── tools/                 # Analysis and charting tools
└── workflows/             # API-format workflows (26 of them)

9.4 The single most valuable tool: official template → API workflow

ComfyUI's official templates (comfyui_workflow_templates_json/templates/ and blueprints/) are in UI format for the frontend and cannot be POSTed to /prompt directly. You either rebuild the graph by hand or write a converter. We wrote ui2api.py and got it right once. The traps it had to solve are worth listing separately — every one of them fails silently:

The general lesson: a converter's mistakes almost always show up as "it submits but the result is wrong" or "parameters silently misaligned" — never as an error. So always do a dry-run submission (POST /prompt) after converting: when the graph and types are correct it reports only value_not_in_list (missing models). Anything else is a real problem.

9.5 An environment trap: Node cannot spawn child processes

We originally wrote the push script in Node (push-site.mjs), because it needs git hash-object -w --stdin-paths for CRLF normalization. But in this environment Node's execFileSync / spawnSync are completely unusable — even cmd.exe returns:

Error: spawnSync C:\Program Files\Git\cmd\git.exe EBUSY
    errno: -4082, code: 'EBUSY'

Measured side by side, same machine, same moment:

Conclusion: the restriction is Node-only, not environment-wide. The fix is to port the script to Python (scripts/push_site.py), matching the original line by line:

1. Never upload raw on-disk bytes — this machine runs core.autocrlf=true, so disk is CRLF while git stores LF. Round-trip through git hash-object -w --stdin-paths → git cat-file blob to get the normalized bytes, then base64-upload those.
2. Build trees with an ancestor closure — intermediate directories containing only subdirectories must still be registered, or a whole subtree silently vanishes from the commit.
3. Self-check before touching the ref — GET trees/<root>?recursive=1 and compare the blob count with the local file count; abort on any mismatch.

The general lesson: when a script suddenly reports EBUSY / EPERM, first pin down the boundary of the restriction with a minimal test (swap the caller, swap the target program) before deciding whether to fix the script or change tooling. We initially assumed "the scratch directory is locked", cleaned it, restarted processes — all useless. Only testing "can Node run cmd.exe at all?" revealed that Node's entire child-process capability was disabled.

10. Conclusion and what is next

10.1 Conclusions

1. 24 GB of VRAM is enough for the newest and strongest open-weight generative models — provided you accept offloading and choose the right quantization format
2. NVFP4 is the best choice on Blackwell — backed by a controlled experiment, not by a feeling
3. Quantization makes a model fit; a distilled LoRA makes it fast — neither substitutes for the other
4. Quantization comparisons on generative models require a noise baseline — otherwise PSNR is badly misread

10.2 Open items

11. Final verdict: one best choice

Once all 21 measurements are in, the question collapses from "what can each domain run" to a single line: if this 24 GB 5090 laptop could keep only one configuration, what would it be?

11.1 The single best choice per domain

11.2 If only one line survives — the answer is "image: Qwen-Image 2512 + Lightning"

The chain of reasons, each backed by a measurement:

1. Speed: 12.2 s at 1328² is the fastest image configuration in the whole table (Lens turbo at 13.6 s and 1024² is second)
2. Resolution: 1328² carries 68% more pixels than 1024² — the same twelve-odd seconds buys a materially larger usable image
3. Chinese: 30/30 characters exact — the only model whose Chinese rendering was verified
4. The cost is contained: 30.06 GB exceeds VRAM by 6 GB, and the offload penalty is already inside the 12.2 s

One sentence: image = Qwen-Image 2512 + Lightning; video = Wan 2.2 14B MoE + 4-step LoRA; music = ACE-Step 1.5 XL turbo; image editing = FLUX.2 Klein 9B fp8; 3D = Hunyuan3D 2.1. Five lines covering image / video / music / 3D, every one of them measured end to end on this 24 GB laptop.

11.3 The quantization verdict stands

If the GPU is Blackwell (sm_120/121), always pick NVFP4. Across five same-model dual-format comparisons on this machine, NVFP4 was always faster and smaller, with the quality delta below the noise floor. And §5's "22% faster" was measured with the optimized kernels disabled — a lower bound (see Appendix E ④).

Appendix F: Licences and legal boundaries (read this)

This is not legal advice. The table below is our own verification pass, marked "verified" or "not verified". Licences change — always re-check each model's HuggingFace / official page before use. Also keep three things apart: the licence of this repository's code, the licence of the model weights, and the licence of whatever you feed the model — they are three different questions.

F.1 This repository's licence

The code, scripts, charts and prose in this repo are MIT. It does not cover any model weights — weights carry their own licences (table below). You may freely use, modify and redistribute these scripts, but which model you run, and whether you may use it commercially, is decided by that model's own licence.

F.2 Licence of every model in this document

F.3 The biggest trap: FLUX.2 Klein's 4B and 9B have opposite licences

This is the easiest to trip over and the most consequential finding of this pass:

• FLUX.2 Klein 4B → Apache 2.0 (BFL's first fully Apache-2.0 FLUX-family model, commercial use allowed)
• FLUX.2 Klein 9B → FLUX Non-Commercial Licence (no commercial use)

The names are nearly identical; the licences are opposites. And §11 happens to recommend the 9B for image editing, so it must be stated plainly:

• Personal / research / non-commercial → use the 9B (18.9 s, better quality)
• Commercial → switch to the 4B (Apache 2.0, 42.3 s, still perfectly usable)

Related: FLUX.1-dev is also non-commercial — it appears here only as a baseline and does not belong in a commercial pipeline.

F.4 Hunyuan3D 2.1 — four hard constraints

Tencent's community licence is not a permissive open-source licence; it carries four explicit limits (taken from the LICENSE text):

1. Territory: the licence does not apply in the European Union, the United Kingdom, or South Korea (capitalised in the original; use outside the territory is unlicensed)
2. Commercial scale: above 1 million monthly active users you must request a licence from Tencent (hunyuan3d@tencent.com), granted at Tencent's sole discretion
3. Attribution: distributions must include a Notice file with the specified wording, and products must be marked "Powered by Tencent Hunyuan"
4. Non-competeness: you must not use the model or its outputs to train or improve any other AI model (other than Hunyuan3D itself and its derivatives)

One more that is easy to miss: the licence on the weights is not the licence on your input. If the photo you feed it for 3D reconstruction is not yours to use, the output is still a problem.

F.5 Two general conclusions

1. Music and video licences are far messier than image licences. CC-BY-NC is common among popular music models (YuE2, MusicGen, early Stable Audio Open); video models tend to ship "community licence + revenue threshold + territory exclusion" as a set. Treat the licence as a hard requirement on the same level as quality — which is why §11 puts ACE-Step (Apache 2.0) first for music and marks YuE2 non-commercial.

2. "The weights download" does not mean "the output is commercially usable". Every performance number in this document was measured under the premise that the weights are downloadable; whether you may use the output commercially is answered in F.2. Anything marked ❌ should stay out of a commercial pipeline no matter how good it is.

3. Territory exclusion restricts the deployment location, not the user's nationality. MiniMax H3 excludes US/EU/UK/KR, but mainland China is inside the licensed territory. The $20M revenue threshold is unreachable for individuals and small teams. The only practical obligation is a prominent "MiniMax H3" attribution in the product UI. So MiniMax H3 is a legitimate quality-first pick for mainland China users — do not exclude it on licence grounds.

Appendix A: Complete model manifest (100 files / 458.4 GB)

⚠️ A scope correction: an early version of this document put the manifest at "34 files / 125.6 GB" — that was only the last batch, not the whole thing. The real on-disk footprint is 100 weight files / 458.4 GB (deduplicated by realpath, so junction aliases are not double-counted). Below it is grouped by purpose, and marked with what was run and what was merely downloaded.

Appendix B: Raw measurements

See the data/ directory:

• data/quant-ab-metrics.md — full controlled A/B metrics
• data/benchmark-results.md — server-side time per workflow
• data/download-manifest.md — size and dtype of all 34 files
• data/coverage-round2.md
• data/coverage-round3.md — round 3: Wan 2.2 14B (4- vs 20-step), MiniMax H3 4-step, FLUX.2 Klein 9B unblocked, Lens, ERNIE, Stable Audio 3, plus the full 21-row benchmark — raw data for the round-2 coverage expansion (timings and output specs for the four music lines + Wan 2.2 14B + LTX + Hunyuan3D, the VAE trap, and the cu130 kernel evidence)
• data/licences-and-video-comparison.md — licence verification + same-prompt video comparison (three models on one prompt, and the three-step LTX diagnosis)

Appendix C: Glossary

Appendix D: Why a single repository, not one per model

We settled this before writing any code: should each model (say MiniMax H3) get its own repository?

The two options

Our call

A single repo, with per-topic deep dives under docs/.

One reason, but a hard one: what makes this guide valuable is the methodology, not any single model's parameters.

• Eight model lines spanning four domains (image / video / music / 3D) share the same reusable parts: the four-arm controlled A/B design, the multi-source downloader with a silent watchdog, three-layer model verification, server-authoritative timing, and the template→API converter. That fact alone is the strongest argument for a single repo — once the methodology is copied eight times, it is no longer one methodology.
• The non-reusable parts — each model's own node constraints and parameters — are small: one chapter (§6) covers them.
• Split into four repos, that methodology gets copied four times. Improve the A/B method in one repo and the other three never catch up — which is exactly how results stop being comparable.

Rule of thumb: the larger the shared method and the smaller the model-specific parameters, the more you should merge into a single repo. Conversely, splitting pays off only when each model genuinely needs its own toolchain and dataset.

When splitting would become right

Any one of these would justify it:

1. A model's toolchain becomes truly independent (e.g. it needs a dedicated training / fine-tuning pipeline)
2. The repo bloats until cloning is painful (bulk data or weights committed — note this repo ships scripts and charts only, no weights)
3. The team splits so that each model is maintained by a different person

Until then, the benefits of the single repo — reusable, comparable, explained in one pass — far outweigh the cost.

Appendix E: Coverage audit — what we ran, what we did not, and why

This section answers the question that is easiest to skip and most worth asking: "Did you try all the state-of-the-art models?" The honest answer is no. Coverage differs a lot between the three domains. Below is the full ledger, with the exact reason for every deliberate skip — including one corrected misjudgement.

E.1 Coverage at a glance

E.2 The models we deliberately skipped, and exactly why

① FLUX.2-dev — does not fit in VRAM

• Weight size: the DiT single file is fp8 35.46 GB
• Why skipped: this machine has 24 GB of VRAM, so that one file is 1.48× the entire VRAM. It is beyond "needs offloading" — it means moving 35 GB over PCIe on every step, and by the behaviour of comparable models the speed would collapse to unusable.
• Substitute: FLUX.2 Klein 4B (fp8, only 4.07 GB) runs and produces output.
• When to revisit: once an NVFP4 or GGUF build brings the DiT under 20 GB.

② LTX-2.3 — ⚠️ this was a misjudgement, and it needs correcting

• The original reason: fp8 weights are 29.15 GB > 24 GB, "does not fit".
• What was wrong: we only estimated the fp8 tier and forgot LTX-2.3 has GGUF quantizations. Community reports put Q3 GGUF on 12 GB cards and Q4_K_M on 16 GB cards. Rejecting a model that offers several quantization tiers because its highest-precision build does not fit is a methodological error.
• Why it was worth running: it is the only open model that natively emits synchronized audio and video in one pass (a 22B DiT = 14B video + 5B audio) — the other "with sound" route besides MiniMax H3.
• Corrected conclusion: it should not have been rejected; it should be re-run with GGUF Q4_K_M.
• A licensing footnote: LTX-2.3 is not Apache 2.0 (a great many articles get this wrong). It ships under the LTX-2 Community License: free commercial use below roughly $10M annual revenue.

③ LTX-2.5 — gated repository

• Why skipped: the HF repository returns 401; you must accept the licence on the HF page first.
• This is a process reason, not a technical one — it downloads once the licence is accepted.

④ Nunchaku Qwen-Image-2512 NVFP4 (W4A4 SVDQuant) — one cu130 short

• Why it was the most promising candidate: it combines NVFP4 (which we proved is best) with the strongest image model, Qwen-Image. The reported numbers are 238 ms/step @1024², so about 11.9 s for 50 steps, with the DiT shrinking from 20.4 GB to ~12 GB — theoretically delivering both quality and freedom from offloading.

• Why it was not run: it depends on optimized CUDA kernels (scaled_mm_svdquant_w4a4, convrot_w4a4_linear), and this machine's ComfyUI startup log states plainly:

  WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations.
  [INFO] Found comfy_kitchen backend cuda: {'available': True, 'disabled': True, ...}
  

  Our PyTorch is 2.11.0+cu128, so the comfy_kitchen CUDA backend is disabled. Without those kernels, SVDQuant W4A4 does not get its fast path — running it would not represent real performance.

• A more important corollary follows: the §5 NVFP4 result was measured with those optimized kernels disabled. In other words, "22% faster" is a conservative figure (a lower bound) — after moving to cu130 the gap should grow. This is a known, unverified optimistic bias in this document, stated here explicitly.

⑤ Wan 2.2 14B MoE — ✅ run this round

• Result: 93.8 seconds (832×480 / 81 frames / 4 steps). Both experts (14.29 GB each) plus the LightX2V 4-step LoRAs were downloaded and validated, then run through the PrimitiveBoolean-driven ComfySwitchNode 4-step / CFG 1 branch.
• Why this matters: it definitively answers whether a flagship MoE video model can run on this machine — yes. The two experts total 28.6 GB, far beyond VRAM, but because only one expert is loaded per step, combined with the 4-step LoRA, it produces a clip in 94 seconds.
• A real trap along the way: substituting the template's wan_2.1_vae with wan2.2_vae made VAEDecode fail on a channel mismatch (48 vs 16). Wan 2.2's 5B and 14B lines use different VAEs. See §6.4 and the §8 troubleshooting table.

⑥ HunyuanVideo 1.0 — superseded by 1.5

• The weights are on disk (DiT 13.17 GB + VAE 0.99 GB + llava-llama3 encoder 9.09 GB) but were not run.
• Why: HunyuanVideo 1.5 is the official successor to 1.0 (8.3B, 480p/720p, built-in SR), and 1.5 already runs. Running 1.0 again has archaeological value only — no selection value.
• Why they are kept: for archival comparison, and the llava-llama3 encoder may still be useful elsewhere.

⑦ Stable Audio 3 Medium — ✅ run this round

• The base model (9.22 GB) plus two encoders (qwen3.5_2b 4.55 GB, t5gemma_b_b_ul2 1.19 GB) were all in place, and it ran.
• Measured 13.8 s for a 60 s track (mp3 48 kHz stereo) — the fastest music model.
• But note its positioning: it is the SFX / short-clip / backing-track route, not "a song from lyrics". For full songs, ACE-Step 1.5 (commercially usable) and YuE2 (highest quality) remain the picks.

⑧ FLUX.2 Klein 9B — ⚠️ a second misjudgement, corrected: it was never blocked

• The original verdict: "the 9B needs a ~16.4 GB Qwen3-VL encoder that BFL ships only as diffusers shards, which ComfyUI cannot load."
• What was wrong: that was true of the BFL repository only. Comfy-Org/flux2-klein-9B publishes a single-file encoder, qwen_3_8b_fp8mixed.safetensors (8.66 GB). Together with the DiT from black-forest-labs/FLUX.2-klein-9b-fp8 (9.43 GB) and the small decoder (0.25 GB), that is 18.3 GB in total — fits comfortably.
• Measured: 18.9 s for a two-pass 9B edit at 1024², output produced.
• Lesson (same root as LTX-2.3): "the official repo ships shards" is not "no single file exists anywhere". Check the Comfy-Org repackage repositories first — they are the de-facto standard distribution channel for the ComfyUI ecosystem.

⑨ MusicGen / Stable Audio Open (early) — the licence forbids it

• Why excluded outright: the weights are CC-BY-NC (non-commercial). "It downloads" is not the same as "you may use the output" — for work that will be used long term and possibly commercially, they are out. (This is also why §6.6 recommends ACE-Step most strongly: Apache 2.0, no revenue threshold, no territory exclusion.)

E.3 The four categories mean different things

E.4 Two methodological lessons from this audit

1. A "does not fit" rejection must state which quantization tier it refers to. The LTX-2.3 lesson: rejecting a model that has GGUF Q3/Q4 builds because its fp8 build is 29 GB is wrong. The correct phrasing is "fp8 does not fit; GGUF Q4_K_M (16 GB) should work, unverified".
2. Every performance claim must state the conditions under which it holds. The §5 NVFP4 result was measured with the cu130 kernels disabled, so "22% faster" is a lower bound. Without stating the conditions, readers will mistake it for the hardware's ceiling.

License

MIT. Every measurement here comes from a real run on this machine — corrections and reproduction attempts are welcome.