Technical
Block Swap, Explained: The Technique Behind Almost Every Low-VRAM Video Workflow
· RenderBob team
Scroll through almost any low-VRAM video workflow in ComfyUI and you will find block swap doing the heavy lifting under a different node name each time.

Scroll through almost any low-VRAM video workflow in ComfyUI right now, HunyuanVideo, SeedVR2 upscaling, various Wan setups, and you will find the same mechanism doing the heavy lifting under a different node name each time: block swap. It is the load-bearing VRAM technique in the current ecosystem, and it is worth knowing on its own terms.
The idea
A video diffusion model is built from repeated computational blocks. HunyuanVideo, for instance, has both double blocks and single blocks, with double blocks generally more memory-intensive. Block swap offloads a configurable number of these blocks to CPU RAM instead of keeping the whole model resident on the GPU, swapping them back to VRAM only when that block's computation is needed in the forward pass. It is the same placement-not-holding idea covered in this blog's Colibrì pieces, applied at a finer grain and to a diffusion architecture instead of an MoE language model: only the part currently computing needs to be on the GPU.
What you actually control
Most implementations expose a numeric knob for how many blocks to swap, typically ranging up to the 30s or 40s depending on the architecture, plus booleans for offloading components such as the text or image input layers when those eat meaningful VRAM on their own. HyVideoBlockSwap splits double blocks (0–20) and single blocks (0–40). SeedVR2 uses a single blocks_to_swap control, up to 32 on the 3B model and 36 on the 7B, and tells you to increase it when you run out of memory. The tuning logic is the same everywhere: more free VRAM, swap fewer blocks (less CPU-GPU traffic, faster); less VRAM, swap more (more traffic, slower, but it fits).
The trade-off
Every block swapped to CPU adds a round trip across the PCIe bus for every forward pass that needs it. That cost is the whole value proposition: you trade time for a job that otherwise would not fit. On a card with tight VRAM, aggressive block swap is the difference between a slow completion and an OOM. On a card with adequate VRAM, cranking it up just makes a fast job slower.
Start at zero or a minimal value and increase it when you actually hit an OOM. This is a knob to dial up reactively, not a safety margin to pre-apply. The correct value is specific to free VRAM at runtime, so pin it per hardware profile in a shared studio registry rather than leaving each artist to rediscover it.
More from the blog
- W4A4 and W4A8: The New Quantization Toolkit for Squeezing More Out of a Checkpoint
ComfyUI's Quantization Toolkit, formerly the INT8 Toolkit, adds native W4A4, W4A8 and W8A8 quantisation, including LoRA support. Here is what the notation means and how to pick a mode.
- The FP8 File That Silently Runs at FP16: A VRAM Gotcha Worth Knowing
A checkpoint saved in FP8 does not guarantee it runs at FP8. Some loaders and backends upcast the weights, so the file is small and the memory it consumes is not.