Hardware vs settings
Which graph and which dials for the machine you have. Two numbers matter and they are not the same number: VRAM decides whether the dilated pass fits, system RAM decides whether the whole pipeline fits, because the decoded frames of pass 1, the smeared frames and the recovered frames all live on the host as float images. People with a 24 GB card and 32 GB of RAM hit the RAM wall first.
Everything here was measured on one box (RTX PRO 6000 Blackwell 96 GB,
91 GB RAM) with the smaller cards simulated by fencing VRAM and RAM to a
hard budget, so a "16 GB" row means a real 16 GiB ceiling, desktop
included. Cells marked extrapolated come from the fitted line in
LOWVRAM.md
and have not been rendered. If you run one of those, your seconds per step
is the most useful thing you can send back.
Pick a row
| VRAM | RAM | start from | checkpoint | what to expect |
|---|---|---|---|---|
| 96 GB | 64 GB+ | examples/motion_pipeline_ref2va_audioinit.json |
int8 | 192 frames at 1 MP in ~12 min; a 702-frame de-rope at 1376x768 renders with everything resident |
| 32 GB | 64 GB | the same, or motion_pipeline_lowvram.json past ~10 s |
int8 or W4A8 | the 702-frame de-rope at 25 GiB peak, 318 s/step, same speed as the 96 GB card (the step is attention-bound at that length) |
| 24 GB | 32 GB | motion_pipeline_lowvram.json |
W4A8 | 702 frames at 23.5 GiB peak, 25.8 GB RSS; 906 frames renders at 515 s/step with RAM at the edge (29.8 GB) |
| 16 GB | 32 GB | motion_pipeline_lowvram.json |
W4A8 + NVFP4 text encoder | 702 frames at 15.5 GiB peak, 27.4 GB RSS, 316 s/step; 906 frames does not fit |
| 15 GiB (a 16 GB card with its desktop up) | 48 GB | the same with kv_store = kvi8s |
W4A8 | the exact K/V store runs out of memory at the second forward; kvi8r renders (+9.5 GiB, 374 s/step), kvi8s renders (219 s/step), kvi8s + trim_forward renders with zero allocator trims |
| 12 GB | any | not measured | the line says ~150k packed tokens, roughly a 5 s clip de-roped at 1 MP. motion_pipeline_rolling_window_lowvram.json makes peak memory follow the window, not the clip, and is the graph to try; reports wanted |
The ComfyUI flags the small-card rows were measured with: dynamic VRAM on
(the default since 0.33), --fast-disk, and nothing else. --reserve-vram
is a global hammer and was not needed on any row.
How long a clip fits
Packed tokens is the unit the card cares about, not seconds. A frame at
1376x768 is about 310 tokens after dilation, and a de-rope at d_max 4
on a bursty clip roughly doubles to triples the frame count, so the
dilated pass is what you are sizing for, not the clip you typed.
| VRAM | max packed tokens | dilated frames at 1376x768, one pass | RAM at that length, single pass / full pipeline |
|---|---|---|---|
| 16 GB | ~230k | ~740 (measured: 702 renders, 906 does not) | ~28 / ~40 GB |
| 24 GB | ~380k | ~1230 (measured: 906 renders) | ~33 / ~45 GB |
| 32 GB | ~530k | ~1720 extrapolated | ~39 / ~51 GB extrapolated |
Beyond the row you are on, the answers in order of cheapness: lower
d_max (3 instead of 4 is a third fewer dilated frames), raise q (0.85
dilates only the hottest spans), drop the resolution of pass 1 and let
motion_pipeline_upscale_derope.json
do the de-rope at the size you want, then the rolling window.
Seconds per step
The only per-step number we can give you is ours, and it scales superlinearly with tokens (exponent ~1.7), so double the frames costs more than double the time:
| clip | card | s/step |
|---|---|---|
| 5 s at 1024x1024, plain pipeline | RTX PRO 6000 | ~11.5 |
| 702 dilated frames at 1376x768 (~217k tokens), pass 2 | RTX PRO 6000, or a fenced 16 to 32 GB budget of it | 311 to 318 |
A 5090 user reported the VAE encode of 120 frames at ~1 MP at 20.5 s (fp16) and 0.41 s with the TAE encoder; our own encoder line is 0.35 s per dilated frame at 1.2 MP, flat 5 GiB, and the int8 VAE is no faster at encoding (it only halves the weights). The encode is the stage that hurts most on a small card, which is why the TAE matters: it needs a ComfyUI newer than 2026-08-17 (core PR #15695).
Quality tiers on the same hardware
Every row above also has a time dial that is not hardware at all:
| want | pass 1 | pass 2 | cost vs one baseline |
|---|---|---|---|
| scout a prompt | 0.2 MP, 12 steps | turbo, 0.4 MP | ~1x, 95 s on our card |
| the normal final | 12 steps, base model | turbo, 6-step beta, inject 0.70 |
~1.3x |
| the slow final | 25 steps | base model, inject 0.70 | ~3.5x |
The middle row is the August 19 recipe and it wants the whole recipe
(linear_quadratic + gradient_estimation on pass 1, beta on pass 2,
seeded audio): the turbo LoRA dropped into the 25-step graph on its own
renders jerky. examples/README.md has the two
recipes side by side.
System RAM, specifically
Measured on the 702-frame de-rope: 25.8 to 27.4 GB RSS on the small-card
rows, with the text encoder's CPU mirror the avoidable part. What helps,
in order: H3 Evict Text Encoder after each prompt encode (1 to 2.5 GiB
of VRAM peak back on a 16 GB card, and the mirror goes with it), keeping
pass 1 at the resolution you need and no higher, and not running two
ComfyUI instances that each hold a copy of the weights on the host. A
--gpu-only instance removes the host mirror entirely but makes unload a
no-op, so it only suits a card that holds everything.
Send numbers back
An issue with your card, RAM, ComfyUI version, the graph, the packed token
count from the H3 Jerk Oracle cost readout, and your seconds per step
fills in a row of this page for everyone after you. Failures on content
unlike ours are worth more than successes on content like ours.