Nodes/ComfyUI-WanVideoWrapper/WanVideo VRAM Management
ComfyUI Node Runs on cloud

WanVideo VRAM Management

The aggressive offload option for tight VRAM

By kijai·Created about a year ago·Updated 2 months ago· 6,651
WanVideo VRAM Management
    • vram_management_args
    offload_percent1.00

    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. At 1 it offloads everything it can, for maximum VRAM savings and maximum slowdown. Dial it down toward 0 to 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.

    CategoryWanVideoWrapper

    Inputs (1)

    NameTypeDefaultDescription
    offload_percentFLOAT1.000–1Percentage of parameters to offload

    Outputs (1)

    NameTypeDescription
    vram_management_argsVRAM_MANAGEMENTARGS