WanVideo VRAM Management
The aggressive offload option for tight VRAM
- vram_management_args
VRAM is the wall in local video generation. Not "would be nice to have more" - genuinely the thing that decides whether Wan runs at all on your card. WanVideoWrapper's usual lever for this is block swapping, where transformer blocks get shuttled between GPU and system RAM so the whole model never has to sit in VRAM at once. WanVideoVRAMManagement is the more aggressive alternative: an offloading method lifted from DiffSynth-Studio that reduces memory use harder than block swapping does, at the cost of being slower.
Reach for it when block swap alone isn't enough - when you've swapped every block you can and Wan 14B still won't fit, or you're trying to squeeze onto something like a 12GB (or lower) card and you'll happily trade minutes for the run completing at all. If block swapping already fits comfortably, skip this; the speed penalty isn't worth paying for headroom you don't need.
How it works
Block swapping moves whole transformer blocks off the GPU between uses. The DiffSynth-Studio approach this node wraps is finer-grained and more thorough about pushing model tensors to the offload device and pulling them back only when they're needed for compute. That granularity is exactly why it saves more memory and why it's slower - more transfers over the PCIe bus, more waiting on them. It produces a VRAM_MANAGEMENTARGS bundle that the model loader/sampler consumes to run in this mode.
The input and output that matter
There's only one knob:
offload_percent(FLOAT, 0 to 1, default 1) - how much of the eligible model to offload. At1it offloads everything it can, for maximum VRAM savings and maximum slowdown. Dial it down toward0to keep more resident on the GPU (faster, less saved) if you have a little room to spare. Treat it as a slider between "barely fits, slow" and "fits fine, faster."
The output is vram_management_args (VRAM_MANAGEMENTARGS) - wire it into the node that accepts it (the Wan model loader / sampler side of your graph) so the run actually uses this offload strategy.
How to install it
ComfyUI Manager: search ComfyUI-WanVideoWrapper, install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt
then restart. Nothing to download for this node specifically - it's a strategy, not a model.
Common issues & troubleshooting
It's slow, and that's the deal. This is the aggressive option by design - the node description itself says it can be slower than block swapping. If speed matters more than the last few GB, use block swapping instead, or lower offload_percent.
You're stacking it with block swap and things get weird. These are two different offload strategies solving the same problem. Pick one as your primary lever. Piling maximum block swap and offload_percent 1 on top of each other is usually just paying the transfer tax twice for diminishing returns - tune one at a time and watch actual VRAM.
Quantize before you offload. Offloading buys headroom but doesn't shrink the model. If you're this tight on VRAM, a Q5_K_M or Q8 GGUF quant of Wan 14B gets you under the ceiling more cheaply than heavy offloading - the community runs 14B on 10–16GB cards mostly via GGUF, then uses offloading for whatever's still over the line. Combine the two rather than leaning on offload alone.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| offload_percent | FLOAT | 1.000–1 | Percentage of parameters to offload |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| vram_management_args | VRAM_MANAGEMENTARGS | — |