🧹 VRAM Defragmenter

Chunked video generation has a memory problem that doesn't show up on the first cycle: it accumulates. Each loop leaves cached tensors, orphaned references, and a CUDA allocator holding reserved memory that the next cycle could really use. If you've ever watched a long Wan or LTX render start fine and then die with a CUDA OOM on cycle four, you've met this exact problem. MeisoftVRAMDefragmenter is the pack's attempt to reset that state between cycles.

The name oversells it slightly - this isn't defragmenting anything, it's a very thorough purge. But the author calls it the "Sacred Sequence," and fair enough, because it's a specific order of operations, not just a empty_cache():

How it works

Run through the source, the sequence is:

1. Set the PyTorch CUDA allocator to expandable_segments:True, so the memory pool can grow and shrink elastically.
2. If force_model_unload is on, call mm.unload_all_models() to push inactive models out of VRAM.
3. mm.cleanup_models() / mm.cleanup_models_gc() to clear ComfyUI's internal references.
4. Double gc.collect() pass to break stubborn circular references.
5. mm.soft_empty_cache(), then cuda.ipc_collect(), cuda.synchronize(), and cuda.empty_cache().
6. An OS-level trim: malloc_trim(0) via libc on Linux/WSL, or shrinking the process working set on Windows.

It logs how many GB it reclaimed on each run. That readout alone is worth it - you finally see what a video cycle leaks.

Inputs and outputs

• anything (*, required) - pure passthrough. You wire whatever the cycle produces through it so the node has a reason to exist in the chain. The value comes out untouched on the anything output.
• force_model_unload (BOOLEAN, default false) - whether to evict loaded models entirely. Leave it off unless you genuinely have models resident that the next cycle won't reuse; unloading mid-pipeline is how you end up reloading checkpoints every cycle.
• log (STRING) - the before/after memory stats, which is honestly the most interesting wire on the node.

Where it goes and what to expect

Placing it is the fiddly part. It needs to run after generation so it's purging a dirty state - put it late in the cycle, before the loop trigger fires the next one. Inside this pack, the intended flow is: generate chunk → stitcher caches frames → defragmenter purges → trigger re-queues.

Manage expectations: soft_empty_cache() already exists in stock ComfyUI, and on a healthy card this won't turn a 12GB card into a 16GB one. Where it genuinely helps is the forced unload_all_models() for the next cycle and the OS-level trim - on memory-hungry Linux boxes the malloc_trim actually returns real RAM. It's a cycle reset, not a hardware upgrade.

The one rule that matters

The README is emphatic about this and it's worth taking seriously: don't launch ComfyUI with --highvram. That flag pins models in VRAM and blocks mm.unload_all_models(), which silently turns this node into a no-op - and then your long loop OOMs anyway. Standard startup or --normalvram is the supported config for this pack.

Install

ComfyUI Manager → search "comfyui-sequential-batcher", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Meisoftcoltd/comfyui-sequential-batcher

Restart ComfyUI. No models to download - the only real dependency is PyTorch with CUDA, which you already have.