|
Download ComfyUI-MiniMaxH3-Context-Loop/ComfyUI-MAINodes/HARDWARE.md from dzmdd/Fast_deploy: direct link, hf CLI and curl.
- Browser
- Download file 6.11 kB
-
https://huggingface.co/dzmdd/Fast_deploy/resolve/main/ComfyUI-MiniMaxH3-Context-Loop/ComfyUI-MAINodes/HARDWARE.md
- Command line
-
hf download hf://dzmdd/Fast_deploy/ComfyUI-MiniMaxH3-Context-Loop/ComfyUI-MAINodes/HARDWARE.md
-
curl -L -o HARDWARE.md https://huggingface.co/dzmdd/Fast_deploy/resolve/main/ComfyUI-MiniMaxH3-Context-Loop/ComfyUI-MAINodes/HARDWARE.md
6.11 kB
| # 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`](LOWVRAM.md#how-far-you-can-go-extrapolated-from-the-lines-above) | |
| 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`](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`](examples/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`](examples/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`](examples/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`](examples/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`](examples/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`](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. | |