H3 VRAM Headroom (obvpm)

This node exists because of a specific, infuriating bug-shaped thing that isn't a bug. The author measured it live on a 32 GB card: a 5.9-second prepend at 960x544, where the first sampling step took four minutes at 100% GPU utilisation and 117 W, then the run carried on at its normal 6.6 s per step. A computing step on that card draws 570 W. 117 W at full utilisation is a GPU waiting on memory.

Nothing errored. Nothing logged. It reads as a hang at "Model Initializing", which is only core's label for "step one hasn't returned".

What was happening

The adapter had 35.7 GB committed against 32.6 GB physically present - ComfyUI holding 30 GB on its own, with a browser, OBS, three video players and the rest of a desktop taking about 5 more. Windows was paging VRAM over PCIe. Silently.

Two contributing facts. Core's dynamic loader keeps about a quarter of a gigabyte free and fills the rest with weights - correct on a card it has to itself, wrong beside a desktop. And core's activation estimate only sizes the target latent, leaving out every token that isn't the target. For H3, keyframe rows and reference images ride in a constant payload the estimate never counts: a both-mode 39-frame window at 960x544 is 6,120 tokens on top of an 18,870-token target, a third more again. Which is why prepends and bridges tip over where a plain extend doesn't.

What the node does

For the duration of one sampling run it raises the loader's headroom to headroom_gb plus the run's keyframe and reference tokens multiplied by their measured cost, then puts it back afterwards. Raising the headroom evicts weight pages, and they stream from RAM instead - a little slower per step, never a spill.

Three widgets decide the behaviour:

• enabled - off is a true no-op; the model passes through untouched. This is a real pass-through, not a zero setting.
• headroom_gb - VRAM to keep free while sampling, default 3. Think of it as "about what the other programs hold": 1 on a bare desktop, 3 with a browser open, 5 or 6 while recording. Too high only costs speed, because more weights stream from RAM. Too low is the stall the node exists for.
• count_guides - default on. Adds room for the run's keyframe rows and references sized from their actual latents, on top of your headroom, instead of trusting core's estimate for the target alone. Prepend and bridge runs are where this earns its keep.

Placement: anywhere on the model path before the sampler - model in, model out. The bundled workflow puts it near the front of the chain, and runs it with headroom_gb at 2 (because a workflow author's desktop isn't yours).

If you run under the classic loader (--disable-dynamic-vram), the same amount goes into core's reserve for other applications instead - which is what --reserve-vram sets. So on that setup this node is a per-run version of the flag your launch script was already fighting with.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/chanon/comfyui-obvpm-timeline

Restart ComfyUI. There are no Python dependencies - the pack's pyproject declares an empty list on purpose, since torch, torchaudio, numpy, safetensors and av already ship with ComfyUI. Requires ComfyUI 2026-08-13 or later for the core H3 nodes. In Manager, search the pack title comfyui-obvpm-timeline; every node carries an (obvpm) suffix, so obvpm in the node menu finds the whole set.

Troubleshooting

• Still stalling. Raise headroom_gb toward what your desktop actually holds, and check Task Manager or nvidia-smi mid-run rather than after it. The tell is utilisation high and power draw low.
• Everything got slower per step. You set it too high. Weight streaming from RAM is the cost of the headroom; there's an optimum and it's near what your other programs occupy, not as high as the slider goes.
• No effect at all. enabled off, or the node is downstream of the sampler on the model path - it has to sit before it.
• It didn't help a plain text-to-video run. Expected: a simple extend or root generation has little in the way of extra conditioning tokens, so the guard's main contribution (count_guides) has nothing to add. It's the prepends, bridges and multi-reference runs that tip.
• You're using a small card and hoping this fixes a genuine out-of-memory. It won't. This prevents pathological paging on a card that should fit; it isn't a substitute for a smaller window or lower resolution.

Boring node, disproportionate payoff. If your GPU draws a third of its normal power while "busy", you've found the reason.