무엇이 어느 카드에 들어가는가
What fits on which card

01What fits on which card

The number that decides whether a model is usable to you is not its parameter count — it is how much of your card it needs while it runs. Veizik keeps weights quantised on the host and streams them in per block, so the card holds the working set rather than the whole model. That is what puts a 30-billion parameter video model inside 12.48 GB.

The Step-Video row is someone else's achievement and we are labelling it as such. That 30B model reached 12.48 GB of video memory through DiffSynth's block-swap — an existing technique that is not part of our engine, and our own planner cannot even express it today. It also needed 96 GB of host RAM, which is the binding requirement, not the graphics card. We keep the row because we ran it and the number is real, and we mark it because a row sitting unlabelled on our own benchmark page would read as a claim about us. 이 행은 우리 기법이 아닙니다 — DiffSynth block-swap 이고, 진짜 제약은 GPU 가 아니라 호스트 RAM 96 GB 입니다. 실제로 돌린 값이라 남기고, 우리 것으로 읽히지 않도록 표시합니다.

Card class is the smallest bracket the working set fits inside with normal desktop headroom. It is not a guarantee for every resolution — a longer clip or a larger frame raises the working set, and veizik doctor reads your card and answers for the exact job you asked for.

Size does not predict the working set. CogVideoX at 2B needs more than LTX-Video at 2B, and more than Step-Video at 30B. Architecture — attention shape, expert count, VAE cost — decides this, not parameter count. That is the reason this table exists instead of a rule of thumb.

LTX-Video reads 9.55 GB on both rows. Those two runs differ by 14% in pixels and 67% in steps, and the figure is identical to three significant figures with zero spread across five runs. It is not a per-render peak; it is the size of the resident working-set arena, and it does not move with the workload. We report it as measured rather than smoothing it into something that looks more responsive.

모델이 쓸 만한지를 가르는 건 파라미터 수가 아니라 돌아가는 동안 카드를 얼마나 점유하는가입니다. 가중치를 호스트에 양자화된 채로 두고 블록 단위로 흘려보내므로 카드는 모델 전체가 아니라 워킹셋만 쥡니다. 300억 파라미터 영상 모델이 12.48 GB 안에 들어가는 이유입니다. 다만 크기가 워킹셋을 예측하지 않습니다 — 2B 인 CogVideoX 가 30B 인 Step-Video 보다 더 씁니다.

02What the fit costs, and what it costs us

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:

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:

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. The engine already self-emits its fused attention and its memory management; the int8 matmul runs on vendor tensor cores today, and bringing it fully in-house is in progress. 속도 배율은 일반 도구(예: DiffSynth, ~36.5 s/step) 대비이며, 그대로 싣습니다. 잘 튜닝된 bf16 오프로드(accelerate)는 호스트 RAM 만 충분하면 24 GB 카드에서 속도가 근접합니다 — 남들이 못 돌린다는 주장이 아닙니다. 다만 그건 에너지·메모리 열을 좁히지 못합니다: 모델 전체를 호스트 메모리에 쥐고 오프로드만큼 전력을 쓰므로, 상대가 누구든 더 적은 메모리·저전력· 품질parity 는 유지됩니다. 차이는 더 빠른 연산이 아니라 용량입니다 — 상주시키면 오프로드가 매 스텝 치르는 호스트↔카드 트래픽이 사라집니다. 엔진은 융합 어텐션과 메모리 관리를 이미 자체 방출하며, int8 행렬곱은 현재 벤더 텐서코어를 쓰고 전부 자체 방출로 가져오는 작업이 진행 중입니다.

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스텝) — 그래서 그렇게 적어 둡니다.

03What the free paths actually do

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 섹션 표시 참조).

04How these were measured

Runs were executed in July 2026 on a single NVIDIA RTX 3090 (24 GB) with the power cap recorded per run — 420 W on the repeated runs — as the sole tenant of that GPU, warm, with a fixed seed. The working set is the resident allocation reported by the runtime during the denoise loop, not a driver-level high-water mark.

A 24 GB card is the measurement rig, not a requirement. It is large enough to run every row above without the card itself becoming the limit, which is what makes the working-set figures comparable to one another. The Card class column, not the rig, is what tells you whether a model runs on your machine.

Repeated runs are marked. Where the Runs column shows 3 or 5, the figure is the median across that many executions and the spread is recorded in the run manifest. Where it shows 1, it is one execution and should be read as one execution.

2026년 7월, NVIDIA RTX 3090 (24 GB) 한 장을 단독 점유한 상태에서 워밍업 후 고정 시드로 측정했습니다(반복 런은 420 W 파워캡 확인). 24 GB 는 측정 장비이지 요구사양이 아닙니다 — 어느 행도 카드 자체가 한계가 되지 않을 만큼 커야 행끼리 비교가 되기 때문입니다. 여러분 기기에서 도는지를 알려주는 건 Card class 열입니다.

05Against the low-VRAM path

When a model fits comfortably, every runtime is about the same speed — the GPU is the only thing doing work. The differences appear when it does not fit, and the stock answer is sequential CPU offload: each layer is copied to the card, used once, and discarded, every step. It always finishes. It is always slow.

A row belongs in this section only when all five of these hold, because a speed ratio that omits any of them flips sign under re-measurement:

• Same model, same resolution, same frame count, same step count on both sides.
• The opposing configuration is named — sequential_cpu_offload and model_cpu_offload are different opponents and produce different ratios.
• The metric is named — seconds per step, with the warm-up step excluded and the median taken over the remaining steps. End-to-end wall time folds in model load and encode, which is a different question.
• Both sides ran on the same rented machine, in the same session, as sole tenant.
• The build is the release build, not a development build.

The re-measurement that satisfies all five is in progress on rented hardware. Rows appear here as each model completes. We would rather this section be short than have it be wrong.

모델이 넉넉히 들어갈 때는 어느 런타임이든 속도가 비슷합니다 — GPU 만 일하기 때문입니다. 차이는 안 들어갈 때 드러나고, 그때 기본 대안은 순차 CPU 오프로드입니다: 레이어를 매 스텝 카드로 복사해 한 번 쓰고 버립니다. 완주는 항상 하고, 느린 것도 항상입니다. 위 다섯 조건을 모두 만족하는 행만 여기 싣습니다 — 하나라도 빠진 배율은 재측정에서 부호가 뒤집히기 때문입니다.

06Run it yourself

Every row above corresponds to one command. veizik doctor reads your card and reports which of these it will run before you download anything.

$ veizik doctor
$ veizik render ltx-2b --res 768x448 --frames 49 --steps 30 --seed 42 --report

--report writes a run manifest beside the output: model hash, resolution, frame count, step count, seed, precision, working set, wall time, power cap. That manifest is the same artefact the rows above were built from, so a figure you produce is directly comparable to a figure we published — and if it disagrees, the manifest is what makes the disagreement legible.

위 각 행은 명령 하나에 대응합니다. --report 를 붙이면 산출물 옆에 실행 매니페스트(모델 해시·해상도·프레임·스텝·시드·정밀도·워킹셋·소요시간·파워캡)가 남고, 그게 위 표를 만든 것과 같은 형식이라 여러분 수치와 저희 수치를 바로 견줄 수 있습니다.

07What this page does not cover

• One GPU generation for the capacity tables. Every row in the fit and cost tables was measured on Ampere (RTX 3090); the 40-step head-to-head in section 02 is a separate 2026-08 session on a 24 GB-class card. Working sets are architecture-dependent in ways that do not always transfer; a newer card can change the picture in both directions.
• Not an output-quality comparison. These figures say a model ran and how much memory it held. They say nothing about whether the result looks better than another runtime's result.
• Hunyuan models are absent by licence, not by capability. The Tencent Hunyuan Community License does not apply in South Korea, the EU or the UK, so we publish no figures or outputs for that family. See model licences.
• Longer jobs are not extrapolated. A working set measured at 49 frames is not a prediction for 161 frames. Where we have not run the longer job, there is no row for it.

한 세대(Ampere) 측정이고, 출력 품질 비교가 아니며, Hunyuan 계열은 능력이 아니라 라이선스 때문에 빠져 있습니다(대한민국·EU·영국 미적용). 돌리지 않은 길이의 작업은 외삽하지 않습니다 — 행이 없으면 돌리지 않은 것입니다.