The full head-to-head behind the homepage evidence card — measured internally, not yet externally reproduced. Evidence record →
Getting a 14-billion-parameter video model onto a 24 GB card is not the hard part any more. Free quantisation does it, and does it well enough that one GGUF repository is downloaded hundreds of thousands of times a month. What the free path does not tell you is what the fit costs in picture quality — and on a video model that cost is not spread evenly. It accumulates along the clip, so the last second looks worse than the first.
Same machine, sole tenant, same model, same output length:
| Path | Working set | Sharpness drift over the clip | Wall |
|---|---|---|---|
| Veizik native int8 | 6.5 GB | −11% | 430 s |
| Veizik int8 + SmoothQuant | 6.5 GB | −8% | 600 s |
| fp8, CPU offload reference | 17.7 GB | −47% | 752 s |
| ComfyUI native fp8 | 18 GB | — | 1,355 s |
Conditions. Wan2.2 image-to-video, 848×480, 81 frames, 16 fps, one RTX 3090 as sole tenant on one machine. Drift is the loss of sharpness measured from the first frame to the last — it is what makes a clip go soft as it plays, and it is the number the free path does not publish.
The step counts differ across these rows, and that reaches further than the clock. The int8 rows ran at 8 steps and the reference at 20, so the time column is not an identical-condition comparison and we do not present it as one. It also means the drift column compares a distilled short-step run against a longer one: drift is measured within each clip, first frame against last, so it is far less exposed to that than a clip-to-clip score would be — but it is not immune, and we would rather write that sentence than let someone else write it for us. The working set is the number least affected: 6.5 GB against 17.7 GB barely moves with step count.
The 40-step commercial setting, measured head-to-head under identical conditions. The table above is the 8-step distilled variant, run with layer streaming, which is why its working set is the smallest and its time column carries a step-count caveat. In a separate 2026-08 session on a single RTX 4090 (24 GB) we ran the configuration we would actually sell — Wan 2.2 image-to-video, 832×480, 40 steps, guidance 3.5, shift 5.0 — fully resident, and on the same card in the same session the fp8 host-offload path that is the stock way to fit this model when the weights will not stay on the card. Same engine, same card, same seed, the same 40 steps on both sides — so the step-count caveat is gone:
| Clip · Wan 2.2 I2V · 832×480 · 40 steps | Frames | int8 resident | fp8 host-offload | Faster | Energy int8 / offload |
|---|---|---|---|---|---|
| Strawberry splash | 49 | 447 s | 1,459 s | 3.26× | 35.8 / 79.0 Wh |
| Aurora over the lake | 49 | 461 s | 1,468 s | 3.19× | 37.0 / 81.3 Wh |
| Rainy cafe window | 49 | 441 s | 1,478 s | 3.35× | 36.7 / 81.5 Wh |
| Neon rain city | 49 | 439 s | 1,478 s | 3.37× | 36.7 / 81.4 Wh |
| Coastline aerial | 49 | 440 s | 1,473 s | 3.35× | 36.7 / 81.3 Wh |
| Coral reef | 49 | 442 s | 1,480 s | 3.35× | 36.7 / 81.4 Wh |
| Coastal supercar | 81 | 803 s | 1,949 s | 2.43× | 71.0 / 138.1 Wh |
That is 2.4–3.4× faster than the stock offload path a general-purpose tool such as DiffSynth uses to fit this model on a 24 GB card (~37 s/step, the throughput our fp8-offload arm reproduces), and we will not undersell it. The steadier wins are the three that hold against every way of fitting a 14B model on this card: 1.9–2.2× less energy per clip; about half the memory of a bf16 offload — resident int8 is ~14 GB on the card, where bf16 weights are ~28 GB held in host RAM and streamed each step; and quality parity — no collapse on any of the seven (zero black frames, zero NaN across all seven clips), and where the two runs keep the same denoise trajectory the resident int8 output tracks the fp8 reference at SSIM 0.96–0.998 (five of the seven; on the other two the runs diverge in camera path rather than in fidelity, so a frame-to-frame score understates the agreement).
The honest edge of this, so no one has to find it for us. The speed multiple is against general-purpose tools; a hard-tuned bf16 offload (accelerate) reaches roughly comparable speed on a 24 GB card when it has the host RAM for it — we are not claiming others cannot run this model. What that does not change is the other two columns: it holds the whole model in host memory and draws the energy the offload column shows, so the memory and power advantages stand whoever the opponent is. The win is capacity, not a faster multiply, and we will not dress it up as one: keeping int8 weights resident removes the per-step host↔card traffic the offload path pays. Runtime implementation details are proprietary and are intentionally not described here — this page reports what was measured, not how the engine produces it. 속도 배율은 일반 도구(예: DiffSynth, ~36.5 s/step) 대비이며, 그대로 싣습니다. 잘 튜닝된 bf16 오프로드(accelerate)는 호스트 RAM 만 충분하면 24 GB 카드에서 속도가 근접합니다 — 남들이 못 돌린다는 주장이 아닙니다. 다만 그건 에너지·메모리 열을 좁히지 못합니다: 모델 전체를 호스트 메모리에 쥐고 오프로드만큼 전력을 쓰므로, 상대가 누구든 더 적은 메모리·저전력· 품질parity 는 유지됩니다. 차이는 더 빠른 연산이 아니라 용량입니다 — 상주시키면 오프로드가 매 스텝 치르는 호스트↔카드 트래픽이 사라집니다. 런타임 구현 세부사항은 독점 기술이라 의도적으로 설명하지 않습니다 — 이 페이지는 무엇을 측정했는지만 보고합니다.
Measured internally on one machine. No third party has reproduced it. The harness and the run manifest are in the repository, and if your numbers disagree we would rather hear it than not.
14B 영상 모델을 24 GB 카드에 올리는 건 더 이상 어려운 일이 아닙니다. 무료 양자화가 해내고, 충분히 잘 해냅니다. 무료 경로가 말해주지 않는 건 그 맞춤의 대가가 화질에서 얼마인가이고, 영상에서 그 대가는 고르게 퍼지지 않습니다 — 클립을 따라 누적되어 마지막 1초가 첫 1초보다 나빠집니다. 같은 기계·같은 모델·같은 길이에서 fp8 경로는 선명도를 47% 잃고, veizik 은 8~11%를 잃습니다. 워킹셋은 6.5 GB 대 17.7 GB 입니다. 다만 시간 열은 동일조건 비교가 아닙니다(8스텝 대 20스텝) — 그래서 그렇게 적어 둡니다.
A page like this is worth nothing if it only measures us against a strawman, so here is the landscape as we found it when we went looking — including the parts that argue against us.
Start with what the model's own authors require. Alibaba's Wan 2.2 repository states that the A14B text-to-video and image-to-video commands each need a GPU with at least 80 GB — and it states that with the memory-saving flags already switched on. The 24 GB consumer-GPU claim in that repository belongs to the separate 5B model, not to A14B. Everything below, ours included, is the community and us working underneath a number the publisher set at 80.
And the free tooling is genuinely good, which we are not going to pretend otherwise. A full GGUF ladder exists for the A14B model, from Q2_K at about 5.3 GB per expert up to Q8_0 at 15.4 GB. ComfyUI supports the family in core, no custom node needed. The repackaged Wan 2.2 weights are downloaded millions of times a month. If you want this model on a small card and you are happy to find out what the quantisation cost is by eye, that path is free, well-trodden and you should use it.
An earlier version of this page said nobody had measured what that costs. That was wrong, and we have corrected it. Peer-reviewed work on exactly this model reports 4-bit weight and activation quantisation cutting peak memory by 59.3% against the bf16 baseline for a 0.9% drop in VBench average and 2.3% in imaging quality; a second team reports staying within 2–3.5% of fp16 on most axes. Low-bit quantisation of this model, done carefully, is close to free. We are not going to build a page on the pretence that it isn't.
Where the free stack does pay, by its own authors' account, is motion. The standard low-VRAM recipe pairs a quantised model with a 4-step distillation LoRA, and its publisher writes that "the motion speed in these videos tends to be slower compared to those produced by the base model using more inference steps." Users describe the result as slow-motion, and the common fix is to overdrive the LoRA and add steps back. That is the real cost of the popular path, and it is a cost in the thing video is for.
The same criticism reaches our own number, and we would rather say it than be told it. The 6.5 GB row is our 8-step distilled variant — the same family of shortcut. Our own run register says to keep it separate from the 40-step commercial configuration and never to merge the two, and we hold to that here. What the row demonstrates is a footprint and an intra-clip stability measurement, not a claim to have escaped distillation.
Step-Video 30B is the opposite case. Its official requirement is 78.55 GB of peak GPU memory at 768×768×204f, and the documented path is four GPUs plus a fifth for the text encoder and VAE. There is no GGUF quantisation of it, at any level, from anyone; ComfyUI's Step-Video node covers image-to-video only and its text-to-video node was never built; diffusers has no pipeline for it. The one free low-VRAM route is an auto-offload example that claims 24 GB at roughly double the time — and it was deleted from its upstream project in December 2025, so the link from Step-Video's own README now 404s. It survives only if you pin the old release.
And our own Step-Video row is that same free route, not our engine — see the mark on it in section 01. We are not claiming a model nobody else can run. Where we have something is the footprint and the measured cost of getting there; where we do not, this page says so.
무료 경로를 낮춰 말할 생각은 없습니다. Wan 2.2 는 GGUF 사다리(Q2_K 익스퍼트당 약 5.3 GB)와 ComfyUI 코어 지원이 있고 월 수백만 회 받아집니다 — 작은 카드에 올리는 것 자체는 무료로, 잘 닦인 길로 됩니다. 다만 그 대가가 얼마인지에 대한 공개 수치가 없습니다(A14B 양자화 단계별 PSNR/SSIM/VBench 를 찾지 못했습니다). 이 페이지가 하는 일은 "저쪽은 못 한다"가 아니라 "아무도 대가를 말하지 않았고 우리는 말한다"입니다. Step-Video 30B 는 반대 사례로, 공식 요구가 78.55 GB·GPU 4장+1장이고 GGUF 가 하나도 없지만 — 그 12.48 GB 기록은 우리 엔진이 아니라 그 무료 경로였습니다(01 섹션 표시 참조).
Full methodology and the reproduction harness: Benchmarks methodology. Raw evidence: VZK-WAN22-I2V-INT8-3090.