ComfyUI Pinned Memory OOM on Video Models: Why –disable-pinned-memory Fixes Wan and H3 Crashes

You have 16GB or 32GB of VRAM, nvidia-smi shows gigabytes of free memory, yet your Wan 2.2 or MiniMax H3 video workflow dies with HostBuffer.read_file_slice failed followed by CUDA error: out of memory. You have already disabled custom nodes, enlarged the Windows pagefile, and tried --disable-dynamic-vram — and the crash still shows up. This is exactly the situation a growing number of users landed in across mid-2026, and the fix for many of them was one flag they had never heard of: --disable-pinned-memory.

This article explains what pinned (page-locked) host memory actually does in ComfyUI, why it can create memory pressure instead of relieving it, how to diagnose the failure, and the three launch flags that get large video models through an otherwise clean environment. It is grounded in the ComfyUI issue tracker and the official Dynamic VRAM announcement — no fabricated benchmarks, just the mechanism and the documented workarounds.

The Symptom: OOM With Free VRAM, Specifically on Video Models

The signature error looks like this in the console, usually after the sampler has already started and often on the second or later run of a session:

[ERROR] !!! Exception during processing !!!
RuntimeError: HostBuffer.read_file_slice failed
...
torch.AcceleratorError: CUDA error: out of memory

Two things make this error frustrating to debug. First, it appears on models that previously worked — and it surfaces most often on the large video models (Wan 2.1/2.2, MiniMax H3, LTX) that stream most of their weights between system RAM and the GPU. Second, the numbers do not add up: the maintainers have logs where 57 GiB of physical RAM was free, pagefile use was under 1.5 GiB, and the disk was not close to full — yet the allocation still failed during a CUDA synchronize in the cleanup path (see Comfy-Org/ComfyUI issue #14250). That is the tell-tale sign that the failing allocation is outside PyTorch’s normal caching-allocator accounting — which points squarely at the custom offloader path (AIMDO/VBAR) and its pinned-host-memory registration.

If your crash matches this pattern — video model, free VRAM, fails during or immediately after a weight transfer — keep reading. If instead your simple SDXL image workflow OOMs with all VRAM visibly consumed, you have a different problem and should start with your resolution and batch size.

What Pinned Memory Actually Does (And Why It Is Not Free)

“Pinned” (or page-locked) host memory is RAM that the operating system and the GPU driver agree cannot be paged out to disk or relocated. It exists so the GPU can copy data to and from system RAM using high-bandwidth direct memory access (DMA) without the CPU having to bounce the data through an intermediate buffer. In practice that means faster CPU↔GPU transfers — which is why it sounds like a pure win for offloading-heavy workloads.

Here is the part that surprises people: pinned memory has a real cost. Because those pages cannot be swapped or moved, every byte of pinned host memory is a byte of RAM that is now unavailable to the rest of the system. A helpful maintainer answer in ComfyUI discussion #15527 spells out the sequence ComfyUI actually runs:

1. The pin_memory() path allocates host buffer space.
2. It asks the memory manager for a pin budget / registerable size.
3. It releases extra RAM headroom first, then calls cudaHostRegister.
4. If those checks fail, it reuses or “steals” an existing pin instead of making a new one.

The --disable-pinned-memory launch flag bypasses that entire path. So the real takeaway is not “pinned memory is slow,” but “pinned memory is additional non-pageable RAM you are committing on top of an already RAM-hungry workflow.”

Why Video Models Trigger This More Than Anything Else

A text-to-image workflow does offload weights, but it does not generate the same sustained RAM demand as a video model. A large Wan or H3 run simultaneously needs:

• Normal pageable RAM for frames, latent buffers, VAE encode/decode, and any custom-node state.
• Pinned (non-pageable) host memory registered for the fast CPU↔GPU weight transfers.
• VRAM for the active layers, with Dynamic VRAM or smart memory deciding what to evict moment to moment.

When VRAM is tight, the offloader moves more of the model through system RAM — and the pinned buffer has to be sized for those weight chunks. The result, as the discussion answer puts it, is that “the pinned path can make the system less forgiving even if a large pagefile exists.” Adding more pagefile helps normal pageable allocations but does nothing to make pinned host pages cheaper, because pinned pages never hit the pagefile in the first place. That is the concrete reason users report that “expanding virtual RAM” did not stop the Wan/H3 OOM.

Multi-GPU setups add another layer. In the current code path, an install with more than one NVIDIA GPU can end up registering pins per device, and on Windows ComfyUI may default to a single device unless told otherwise — which is why the maintainer note on issue #15255 recommends restricting to one GPU or disabling pinned memory for multi-GPU machines.

Diagnosing It: Confirm It Is the Pinned Path, Not Something Else

Before you flip the flag, take two minutes to rule out the cheaper explanations, because “OOM” is a catch-all that lumps together several unrelated failures:

• Disable all custom nodes and run a bare stock workflow. If the crash vanishes, a custom node — not pinned memory — is your culprit.
• Watch RAM, not just VRAM. On Windows open the Performance tab and look at “Committed” memory, not just the live usage number. Crashing at high-commit with a large pagefile strongly suggests the pageable/pinned split described above.
• Note the timing. A crash that happens right as sampling starts or during an offload, with VRAM still showing free headroom, is characteristic of the pinned/offloader path. A crash that happens only after VRAM climbs to 100% is a plain VRAM-capacity problem.

Once you have ruled those out, the cleanest confirmation is a controlled A/B: run the same workflow twice on the same checkpoint, once normally and once with the flag below. Maintainers explicitly asked for that A/B data because the failure is intermittent and hard to reproduce.

The Fix: Which Flag to Use and When

There are three related flags, and they do different things — pick the one that matches your setup rather than applying all three blindly.

1. --disable-pinned-memory — the targeted fix for the host-buffer / pinned-registration OOM described here. Reported to make stock MiniMax H3 and Wan workloads complete with no change to resolution, frame count, sampler, precision, or pagefile (issue #14250). There is a small trade-off: host-to-device transfers may be marginally slower without pinned buffers, so it is best treated as “stable default for video,” not something to immediately revert.
2. --disable-dynamic-vram — turns off the whole Dynamic VRAM subsystem. This is the broader hammer, and it fixes a separate regression where the dynamic offloader itself crashed every generation. Use it if you are on a Dynamic-VRAM regression, not specifically for pinned memory.
3. --cuda-device 0 (or a specific index) — restricts ComfyUI to a single GPU. This is the maintainer-recommended workaround for multi-GPU machines where per-device pinning is involved. If you genuinely want all GPUs, the note suggests --cuda-device all --disable-pinned-memory instead.

How you apply the flag depends on how you launch ComfyUI. In a plain terminal, it is simply part of the command: python main.py --disable-pinned-memory. For the desktop or portable app, add it to the launch arguments / extra arguments field. For the Windows portable install, edit the run_nvidia_gpu.bat and append the flag to the python main.py line.

What This Tells You About Your Machine (And When to Keep It Disabled)

The most useful lesson from the linked discussion is that disabling pinned memory is not a shameful workaround to undo later. If your machine is RAM-constrained relative to the model you run, disabling pinned memory is a legitimate production setting. Pinned memory helps when you have healthy headroom; it hurts when a 14B video model plus its buffers is already crowding your total RAM. On a 32GB–64GB machine streaming a Wan or H3 model, you can easily land on the wrong side of that line.

If disabling pinned memory resolves your crashes but you want that transfer speed back on a smaller, easily-fitting model, you can still leave it disabled globally and accept the modest transfer cost — the reliability win on large video jobs is almost always worth more than a few percent of copy throughput.

Conclusion and Where to Report Your Case

Free VRAM plus an OOM on a Wan or H3 video model is now a well-understood signature: it usually means pinned (non-pageable) host memory is being registered on an already-committed RAM budget. The order to work through is: disable custom nodes → watch committed RAM → add --disable-pinned-memory → if still failing on a multi-GPU box, add --cuda-device 0 or --disable-dynamic-vram. One of these reliably gets stock video workflows completing with no change to your actual generation settings.

If you can reproduce the failure consistently, the maintainers want your logs — the full startup log, the workflow JSON, and your exact GPU, driver, and OS versions. File the report on the Comfy-Org/ComfyUI issue tracker and reference the pinned-memory discussion so the data lands in the right place. For a deeper look at how the underlying memory system behaves day to day, see the official Dynamic VRAM announcement, and for the broader picture of how these offloading flags fit into running large models on consumer cards, check our companion guide on ComfyUI --lowvram vs --novram vs --normalvram and the block_swap and offload_device walkthrough.