ComfyUI “HostBuffer.read_file_slice failed” → CUDA Out of Memory: The Dynamic VRAM Regression (and 4 Working Fixes)

Your generation starts, the model stages into VRAM, the sampler kicks off — and then the console throws HostBuffer.read_file_slice failed immediately followed by CUDA error: out of memory. The frustrating part: nvidia-smi shows 14 GB of VRAM sitting free. You didn’t run out of memory. You hit a specific, dated regression in ComfyUI’s Dynamic VRAM streaming layer that shipped in the August 3, 2026 update.

This article walks through the exact symptoms, what actually causes the failure, how to confirm you have this bug (and not a real OOM), and four verified workarounds — plus what to do if your hardware or version doesn’t match any of them.

The symptom: a crash that looks like OOM but isn’t

The signature of this bug is the order of two lines in your console. Right before the full CUDA out-of-memory traceback, you’ll see a host-buffer read failure:

[ERROR] !!! Exception during processing !!! CUDA error: out of memory
  File "...\comfy\ops.py", line 228, in cast_modules_with_vbar
    handle_pin(s, pin, xfer_source, xfer_dest, subset=subset, size=dest_size)
  File "...\comfy_aimdo\host_buffer.py", line 109, in read_file_slice
    raise RuntimeError("HostBuffer.read_file_slice failed")
RuntimeError: HostBuffer.read_file_slice failed

On some setups the message appears in a slightly different form, coming from the native comfy-aimdo backing library rather than Python:

aimdo: src/hostbuf.c:283:ALL:hostbuf_read_file_slice: device copy failed result=2 device_ptr=... device=0 stream=... size=67108864

The tell is result=2, which maps to cudaErrorMemoryAllocation on the very first block of the first sampler step. The transfer that fails can be a large one (64 MiB) or a tiny one (19 MiB) — the size doesn’t matter. If your failure happens immediately during sampling, before any meaningful progress bar movement, and nvidia-smi confirms large amounts of free VRAM, you are almost certainly looking at this regression rather than an undersized GPU.

What makes it deceptive is that it is not a real memory shortage. Multiple reporters on the tracker confirm the crash reproduces on models both large and small, on RTX 4080, 5060 Ti, and 5080 cards, with 14+ GB of VRAM visibly free in nvidia-smi at the moment of failure. A genuine VRAM OOM fails late, after tiling through sampling steps, and your card will actually be pinned at 100% VRAM when it dies.

What actually breaks: the comfy-aimdo host-buffer layer

ComfyUI 0.30.x runs Dynamic VRAM streaming by default. This subsystem — implemented in a component called comfy-aimdo (version 0.4.11 at the time of writing, with a 0.4.12.dev3 also affected) — streams model weights between system RAM and the GPU on a pinned host buffer instead of loading the entire model into VRAM up front. It’s a worthwhile optimization for fixed-vRAM cards, but the August 3, 2026 update introduced a regression in exactly this layer.

The failure mode, as documented in ComfyUI issue #15255 (tagged CORE-398 and escalated to NVIDIA as a CUDA error), is a host-to-device copy that returns cudaErrorMemoryAllocation. The maintainers have flagged it as a CUDA-level error and linked three open pull requests (#15490, #15610, #15932) aimed at adding graceful fallback and guarding the free-memory query. As of this writing the issue is still open, so the workarounds below remain the practical path while the fix is in flight.

There’s also a second, related change worth knowing about, because it produces a similar-looking symptom that is actually a different behavior. ComfyUI 0.30.0 rewrote its RAM allocation strategy to commit more system RAM up front, trading disk reloads for higher RAM usage. Some users on smaller-RAM machines see RAM climb past 80% before an error, which can look like the same bug but is the new caching strategy rather than the CUDA copy failure. The maintainers’ guidance for that case is to launch with --fast-disk, which reverts to the older, lower-RAM, more disk-intensive loading. If your console shows the RAM figure — not VRAM — climbing before the crash, try --fast-disk before the Dynamic VRAM flags below.

Confirming the diagnosis in three steps

Before you start toggling flags, spend two minutes confirming which problem you actually have. The wrong fix wastes time and can mask the real issue.

1. Check the console order. Does HostBuffer.read_file_slice failed (or hostbuf_read_file_slice ... result=2) appear immediately before the CUDA OOM? If yes, it’s the Dynamic VRAM regression. If you see a plain CUDA OOM with no host-buffer line, it’s a conventional memory issue and you should look at --lowvram or a smaller model.
2. Check free VRAM at the moment of failure. Keep nvidia-smi running in a second terminal (nvidia-smi -l 1). If VRAM is still mostly free when the crash fires, it isn’t a real shortage.
3. Test with one flag. Restart ComfyUI with --disable-dynamic-vram and re-run the same workflow. If it completes, you’ve confirmed the regression.

One subtle pitfall: on multi-GPU or headless setups, the crash may leave the prompt_worker thread dead while the process itself stays alive holding ~31 GB. Retrying without a full restart will then make every subsequent prompt fail, which is why some people report “all generations broken” after the first crash. If you see persistent failures after an initial crash, fully restart ComfyUI before drawing any conclusions.

Four verified workarounds

These are drawn from the maintainers’ own pinned note on the issue and confirmed by multiple reporters. Apply them one at a time, in order of how invasive they are, and re-test after each.

1. Disable Dynamic VRAM (the most reliable fix)

This is the fix that the issue author and several commenters confirm resolves the crash completely on single-GPU machines. Add the flag to your launch command:

python main.py --disable-dynamic-vram

If you launch via the desktop app or a batch file, add --disable-dynamic-vram to the arguments there instead. Note that this disables the streaming optimization, so you’ll fall back to the prior memory behavior — on a 16 GB card you may need to re-enable --lowvram or --normalvram as appropriate for your model.

2. Disable pinned memory

The maintainers’ note also offers --disable-pinned-memory for multi-GPU configurations. This preserves some functionality while avoiding the pinned-host-buffer path that’s failing:

python main.py --disable-pinned-memory

This is the recommended first try specifically for multi-GPU setups, since the pinned-memory fast path is where the host-to-device copy goes wrong.

3. Restrict ComfyUI to a single GPU

The maintainers’ workaround note suggests --cuda-device 0 (or a higher index) to restrict ComfyUI to one GPU:

python main.py --cuda-device 0

Use this if you have a mixed multi-GPU setup (for example, a primary card plus a second card driving the display) and want to sidestep the multi-device host-buffer path entirely.

4. Downgrade to 0.29.x

Several reporters confirm that rolling back to a pre-regression build eliminates the problem. One user pinned a clean reproduction: Z-Image-Turbo’s first generation succeeds but the second hangs indefinitely at the KSampler stage, and downgrading from 0.30.0 to 0.29.0 makes both generations work flawlessly. If you need production output today and can’t afford to toggle flags, this is the bulletproof option — just remember you’ll miss the newer features until the fix lands.

For a clean install you can pin the older version through git or reinstall the desktop app at the prior release. If you maintain a portable install, keep a backup of your working version before any update so a one-command rollback is always available.

Common pitfalls people hit along the way

• Assuming it’s a weak GPU. The most damaging mistake is “fixing” a regression by buying more VRAM or shrinking your model. If the crash is instant and VRAM is free, hardware is not the problem.
• Mixing up RAM and VRAM climbs. A rising system RAM figure before the error points to the 0.30.0 RAM-strategy change (--fast-disk), not the Dynamic VRAM CUDA bug. Read which resource is actually climbing.
• Retrying without restarting. After a prompt_worker death the process may stay alive holding memory, so subsequent runs all fail. Restart fully before re-testing any flag.
• Chasing custom nodes. The issue reproduces on a clean environment with custom nodes disabled, so don’t burn hours bisecting your node set — this is a core regression.
• Ignoring the multi-GPU distinction. Single GPU → prefer --disable-dynamic-vram. Multi-GPU → try --disable-pinned-memory or --cuda-device first, per the maintainers’ note.

Verifying the fix

After applying a workaround, confirm it actually resolved the regression rather than just delaying it. Run the same workflow at least twice in a row — several reporters note the bug can pass the first generation and only fail (or hang) on the second. If you get two clean generations back-to-back with stable VRAM and RAM readings, you’re clear. Keep nvidia-smi -l 1 open during the test and confirm VRAM is released between generations, since the newer RAM strategy can also mask a partial fix by holding memory across runs.

Finally, subscribe to the status of issue #15255 and its linked pull requests (#15490, #15610, #15932). Once a graceful-fallback patch lands in a future release, you can safely remove the --disable-* flags and go back to full Dynamic VRAM streaming. When you do, re-run the two-generation test to confirm the fix sticks on your exact hardware.

Conclusion

HostBuffer.read_file_slice failed followed by CUDA error: out of memory is not your GPU failing — it’s a dated regression in ComfyUI 0.30.x’s Dynamic VRAM streaming, tracked as issue #15255, that breaks generations instantly despite abundant free VRAM. Confirm the console order and free-VRAM reading, then apply --disable-dynamic-vram (single GPU), --disable-pinned-memory or --cuda-device (multi-GPU), or roll back to 0.29.x for a bulletproof stopgap. If instead your system RAM is what climbs before the error, try --fast-disk. For more on keeping ComfyUI stable across version updates, see our guide on recovering ComfyUI after a Python 3.13 upgrade, and always cross-check your symptoms against the official ComfyUI troubleshooting guide.