ComfyUI Out of Memory: HostBuffer & DynamicVRAM Fix

Short answer: add --disable-dynamic-vram to your launch command and restart. If ComfyUI started OOMing, hanging at "Model Initializing...", or running several times slower on a graph that worked last month, the cause is almost certainly DynamicVRAM — the memory manager ComfyUI switched on by default in February 2026. And --lowvram will not help you, because ComfyUI's own help text for that flag now reads, verbatim: "Doesn't do anything if dynamic vram is enabled."

If your console shows HostBuffer.read_file_slice failed immediately before the CUDA out-of-memory traceback, you have hit a specific, dated regression — not a "your GPU is too small" problem. That is issue #15255, opened 2026-08-03, and with 60 comments it is the most-commented open issue on the ComfyUI tracker. It has its own section below, including the two extra flags multi-GPU reporters needed.

That verbatim --lowvram sentence is why so many people have added the flag, restarted, and watched nothing change.

Everything below was read directly out of comfy/cli_args.py on ComfyUI master on 18 August 2026, pinned against v0.33.1 (released 2026-08-13); the issue tracker was re-read on 23 August 2026. This subsystem changes weekly, so re-verify the flag names against your own install before you trust any article, including this one. There is a one-line command for that in the Measure It Yourself section.

---

The 30-Second Fix

Append the flag to however you normally launch ComfyUI, then restart the server. Nothing else changes.

# Linux / macOS / manual install
python main.py --disable-dynamic-vram

# Windows portable — edit run_nvidia_gpu.bat and append the flag
# to the existing python line, e.g.
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --disable-dynamic-vram

Its help string is "Disable dynamic VRAM and use estimate based model loading" — in other words, the pre-2026 behaviour that every guide written before March 2026 silently assumes you are running.

Run your problem workflow again. If the OOM, hang or slowdown is gone, you have your answer and you can stop reading. If it is unchanged, DynamicVRAM was not your problem — jump to Symptom → Cause → Fix, because several of the failures people blame on it are something else wearing its clothes.

---

Which Error String Do You Have?

Find the line your console actually printed, not the one you assume it printed. DynamicVRAM produces at least nine distinct failure signatures, and they do not all have the same fix — one of them is cleared by a package downgrade rather than a flag, and two have no fix at all yet. Every row below is an open report on Comfy-Org/ComfyUI, re-read 2026-08-23; issue titles and error strings are quoted, not paraphrased.

Source: Comfy-Org/ComfyUI issue tracker, is:issue HostBuffer, read 2026-08-23. Run that search yourself before you act on any of it — states and comment counts move daily.

---

Why Does HostBuffer.read_file_slice Fail?

The single biggest ComfyUI memory story right now is issue #15255, and it is not a small-GPU problem. Its title, verbatim:

Dynamic VRAM streaming crashes all generations with HostBuffer.read_file_slice failed → CUDA OOM (regression after Aug 3 2026 update) (CORE-398)

Opened 2026-08-03, labelled Bug, assigned to maintainer rattus128, and still open on 2026-08-23. Sixty comments make it the most-commented open issue on the repository. The reason it deserves its own section rather than a row in a table: the word "regression" is doing real work. All generations crash, on setups that were fine the day before, which is a very different diagnosis from "your card ran out of room."

The signature is a pair of lines, in this order:

HostBuffer.read_file_slice failed
torch.AcceleratorError: CUDA error: out of memory

If you only read the second line you will conclude you need a bigger GPU. The first line is the one that identifies the bug — it comes from the comfy-aimdo streaming layer trying to read a slice of a model file off disk into a host buffer, and failing before anything about your VRAM capacity is relevant.

What the maintainer says. In a pinned comment dated 2026-08-06, rattus128 writes: "I have a working theory that this is a bug in Cuda." The thread notes it reproduces reliably only on multi-GPU configurations, and the maintainer has published a standalone diagnostic, windows_cuda_host_memory_diagnostic.py, asking affected users to run it from the same Python environment ComfyUI uses and post the output. PR #15610 is linked from the issue. Read the thread before you assume it is fixed — that status can change in a week.

What reporters in the thread found that worked:

# 1. The primary escape hatch — works for single- and multi-GPU alike
python main.py --disable-dynamic-vram

# 2. Multi-GPU only: pin ComfyUI to one device
python main.py --cuda-device 0

# 3. Multi-GPU only: if you must keep DynamicVRAM on
python main.py --disable-pinned-memory

Option 2 is the tell. If restricting ComfyUI to a single GPU makes an out-of-memory error disappear, the problem was never memory capacity — you just removed the multi-GPU host-buffer path the bug lives in. Anyone with two cards who has been buying a third to "fix" ComfyUI OOMs should try that one-line flag first; our best GPUs for image generation ranking is for people who genuinely need more silicon, not for people working around a streaming bug.

---

Should I Pin comfy-kitchen to 0.2.30?

There is a second HostBuffer failure with a completely different fix: a package downgrade, not a flag. Issue #15591, opened 2026-08-13 and still open, is titled:

[Bug] CUDA illegal memory access / HostBuffer.truncate failed with comfy-kitchen 0.2.31 during dynamic VRAM load (MiniMaxH3)

The two strings to match against your own console:

CUDA error: an illegal memory access was encountered
RuntimeError: HostBuffer.truncate failed

Note truncate, not read_file_slice — different call, different bug, different remedy. The reporter's crash happens during KSampler on a MiniMaxH3 video job (73 frames on a 12GB card), inside the partially_unload_ram / hostbuf.truncate step. The version boundary they identified is narrow and specific:

So the workaround is one line, run inside the same virtual environment ComfyUI launches from:

pip show comfy-kitchen          # check what you actually have first
pip install comfy-kitchen==0.2.30

Two honest caveats. Pinning a dependency below what your ComfyUI build expects can break unrelated things, so treat this as a diagnostic probe rather than a permanent configuration — if 0.2.30 clears the crash, you have confirmed the cause and can wait for the fixed release instead of living on an old package. And this pin is specific to the truncate signature; it is not a general answer to the Aug 3 read_file_slice regression above, which reporters there address with flags.

---

Why --lowvram Does Nothing Now

--lowvram was not removed. It was quietly demoted to a no-op on any default install.

Here is the exact line from comfy/cli_args.py:

vram_group.add_argument("--lowvram", action="store_true",
    help="Doesn't do anything if dynamic vram is enabled. If dynamic vram "
         "isn't being used this option makes the text encoders run on the CPU.")

The wording arrived in PR #13922, "Remove useless option and clarify what lowvram does", merged 2026-05-16. The behaviour change that made it necessary landed earlier:

Source: commit history of comfy/cli_args.py, Comfy-Org/ComfyUI, read 2026-08-18.

So the advice in every ComfyUI OOM thread predating March 2026 — including, until recently, the VRAM section of our own ComfyUI complete guide — is aimed at a memory manager you are no longer running.

---

Are You Even On It?

ComfyUI does not print "DynamicVRAM: enabled" at startup. You have to derive it from your own launch flags. This is the single most useful thing on this page, because it explains a contradiction people keep tripping over.

The gate is one function, reproduced verbatim from comfy/cli_args.py:

def enables_dynamic_vram():
    if args.enable_dynamic_vram:
        return True
    return (not args.disable_dynamic_vram
            and not args.highvram
            and not args.gpu_only
            and not args.novram
            and not args.cpu)

Read it as a table:

That is the whole mystery. --novram, --highvram, --gpu-only and --cpu all turn DynamicVRAM off as a side effect of setting a different VRAM state — so the person who tried --novram in desperation reported "fixed!" and credited the wrong flag, while the person who followed the standard --lowvram advice saw literally no change and concluded the problem was their GPU. Both were looking at the same switch from opposite sides.

Two practical consequences. First, if someone in a thread tells you --novram fixed their OOM, try --disable-dynamic-vram instead — you probably get the fix without also forcing every model onto the CPU. Second, the startup line ComfyUI does print, Set vram state to: NORMAL_VRAM, tells you nothing about DynamicVRAM. Do not read it as confirmation either way.

---

Every Memory Flag, Verified

These are the memory-related arguments as they exist in comfy/cli_args.py on master at v0.33.1. Help text is quoted, not paraphrased.

--gpu-only, --highvram, --lowvram, --novram and --cpu are a mutually exclusive group in the parser — pass two and argparse rejects the launch. --disable-dynamic-vram is not in that group, so it composes freely with the others.

Two flags worth singling out. --vram-headroom is the one written for DynamicVRAM, and it is unusually aggressive: it keeps VRAM free "even counting VRAM from other apps", which is what you want on a machine where the same GPU is also driving your monitors. And --fast-disk is the opposite of a general-purpose fix — it prefers disk-backed offload, so it helps on fast NVMe and is exactly the wrong choice if your models live on a spinning disk or a network share. More on that in a moment.

If you are here because a specific model will not fit rather than because an update broke things, that is a different problem — see Run FLUX on a Low-VRAM GPU and FLUX VRAM requirements by GPU, or check the model against our VRAM calculator first.

---

Symptom → Cause → Fix

Ordered by how often each one is the real cause, judged by open-issue volume on Comfy-Org/ComfyUI as of 2026-08-23. Every issue number below is a real, open report you can read yourself. The two HostBuffer signatures have their own sections above (#15255 and #15591) because their fixes differ from everything here.

1. Everything got slower after an update, and your models are on a hard drive or network share

The most-reported flavour of this regression. DynamicVRAM streams weights on demand instead of loading them once, so when the backing store is slow, it re-reads constantly. Issue #15661 (opened 2026-08-16) is titled "Performance regression after recent updates: DynamicVRAM / AIMDO causes extreme slowdowns when models are on HDD" and attaches a feature request for a "prefer GPU / disable dynamic memory" option — which tells you the reporter had not found --disable-dynamic-vram either.

Fix: --disable-dynamic-vram. Do not reach for --fast-disk here; it prefers disk-backed loading, which is the direction you are trying to run away from. --fast-disk is for NVMe owners who want more disk streaming, not less.

2. Straight OOM: "Allocation on device"

The phrase people paste into Google is the exact torch allocator string Allocation on device, and the important thing to know is that it comes from PyTorch's CUDA/HIP allocator, not from ComfyUI — so it tells you memory ran out, and nothing at all about why. Under DynamicVRAM it can now fire mid-sample rather than at load time, which is why it feels different from the OOMs you are used to. You can see the current volume for yourself with the tracker's own search: is:issue "out of memory".

Before you treat this as a capacity problem, scroll up one line in your console. If HostBuffer.read_file_slice failed precedes it, you are in the Aug 3 regression, not out of VRAM. Issue #14340 (2026-06-08) is the other flavour worth knowing — "VRAM OOM on Linux with large singular allocation but should be within limits" — where a single oversized allocation fails even though total free memory looks adequate.

Fix, in order: try --disable-dynamic-vram first. If you want to keep DynamicVRAM, give it room instead: --vram-headroom 2 (start at 2GB) so it stops competing with your desktop compositor and browser for the last gigabyte.

3. Infinite hang at "Model Initializing..."

Not a crash, not an error — the UI just stops. Issue #15628 (opened 2026-08-14) reports it in its title: "[Bug] MiniMaxH3: DynamicVRAM causes infinite hang at 'Model Initializing...' on RTX 4070 12GB; custom nodes surface underlying CUDA illegal memory access." Its close relative is #15591 (2026-08-13), "[Bug] CUDA illegal memory access / HostBuffer.truncate failed with comfy-kitchen 0.2.31 during dynamic VRAM load (MiniMaxH3)" — same model family, same illegal-memory-access root, but that one has a package-level fix rather than a flag-level one.

Fix: --disable-dynamic-vram. If you see HostBuffer.truncate failed anywhere in the traceback, go to the comfy-kitchen version pin instead — flags will not clear that one. If the hang survives both, it is not this bug and you should check your custom nodes; a node throwing during load looks identical from the front end.

4. WSL: model set pinned into "Shared GPU memory" for no reason

Issue #15679 (opened 2026-08-16): "DynamicVRAM on WSL pins the entire model set into Shared GPU memory for no benefit." Shared GPU memory is system RAM presented to the GPU through the WSL driver, and it is dramatically slower than real VRAM. Windows Task Manager shows this clearly — if your dedicated VRAM is half empty while shared GPU memory is pegged, you are in it.

Fix: --disable-dynamic-vram, and consider --disable-pinned-memory if the shared-memory usage persists.

5. --reserve-vram appears to do nothing

Issue #15666 (opened 2026-08-16) is literally titled "--reserve-vram ignored", and it was still open on 2026-08-23. The flag was reworked for DynamicVRAM in PR #14480 (2026-06-15). Argparse accepts it and the launch succeeds, which is exactly why it wastes people's time — there is no error to tell you the value was discarded.

Fix: use --vram-headroom N instead — it is the flag actually written for the DynamicVRAM path. If you need the old semantics, --disable-dynamic-vram restores the estimate-based loader that --reserve-vram was designed against.

6. AMD / ROCm: blank or corrupted outputs

Issue #15436 (opened 2026-08-08): "Blank invalid/outputs using dynamic vram on ROCM 7.14 on gfx1201". Issue #15484 (2026-08-11) reports a ROCm/Windows VAE slowdown under Dynamic VRAM that a forced unload stabilises. Note the symptom here is wrong pixels, not an error — you can lose an afternoon before you suspect memory management at all.

Fix: --disable-dynamic-vram before you start bisecting your workflow. If your ComfyUI is producing black or empty images generally, that has several unrelated causes too.

7. Host buffer grows until RAM is exhausted on long runs

Issue #15575 (2026-08-13) documents an AIMDO host buffer growing across a single long prompt — "618x hostbuf_grow ERROR, ~12% slowdown" with a LoRA-loaded workflow. If your system RAM climbs steadily over a long batch and never comes back down, this is a candidate.

Fix: --disable-dynamic-vram, or cap the RAM cache with --cache-ram 4 and see whether the growth stops.

8. First generation is fine, the second one dies

The most misleading pattern of the lot, because a successful first run convinces you your setup is correct. Issue #15269 (opened 2026-08-03) is titled "DynamicVRAM + AIMDO 0.4.11 causes 'VRAM Allocation failed (non OOM)' and 'Fault failed: 2' on second generation (QwenImage)". Note the words non OOM in ComfyUI's own message: the allocator is reporting a failure that is explicitly not an out-of-memory condition, which is the manager admitting the fault is its own. The same class of failure has been open since March in issue #12943, "aimdo:VRAM Allocation failed (non OOM) in 17.1", so this is not purely an August problem.

Fix: --disable-dynamic-vram. Neither issue has a maintainer fix as of 2026-08-23, so the flag is the only lever on your side of the machine. If you are on QwenImage specifically, keep an eye on #15269 rather than rebuilding your workflow.

---

What This Page Does Not Claim

We do not own the hardware to benchmark this, so there is no invented performance table anywhere on this page. That matters, because the honest state of DynamicVRAM is that it is a genuine improvement on some configurations and a serious regression on others, and nobody — including NVIDIA, Comfy-Org, or us — has published the split.

What is source-verified: the flags exist, the defaults are what we describe, --lowvram is inert, and every issue number, title and error string above was read off the public tracker on 2026-08-23. What we are explicitly not claiming: that --disable-dynamic-vram will be faster for you. On a machine with fast NVMe storage and plenty of system RAM, DynamicVRAM is doing useful work and turning it off may cost you the ability to run a model at all.

We are also not claiming a root cause for the Aug 3 regression. The maintainer's own pinned position is a theory — "I have a working theory that this is a bug in Cuda" — and a theory from the person who wrote the code is still a theory. The pattern in the issue tracker is that the losers are consistently multi-GPU rigs, HDD or network-backed model storage, WSL, and ROCm. If none of those describe you, benchmark before you disable anything permanently.

---

Measure It Yourself

Two commands settle it in five minutes. First, confirm which flags your install actually has, rather than trusting any article:

python main.py --help | grep -A2 -- "--disable-dynamic-vram"
python main.py --help | grep -A2 -- "--lowvram"

If the --lowvram help text on your machine still mentions dynamic vram, you are on a build that matches this page. If those flags do not exist at all, you are on something older than 2026-03-16 and none of this applies to you.

Then run the same workflow twice, changing exactly one thing:

# Run A — default (DynamicVRAM on)
python main.py

# Run B — same workflow, manager off
python main.py --disable-dynamic-vram

Watch VRAM live in a second terminal with nvidia-smi --query-gpu=memory.used --format=csv -l 1 (or rocm-smi on AMD), and take wall-clock time from the ComfyUI console, which prints "Prompt executed in X seconds" after every run. Record peak VRAM, wall-clock, and whether it OOMs. Three numbers, two runs, and you know the answer for your machine instead of somebody else's.

Do this with a workflow you actually use. An SDXL graph and a video graph can land on opposite sides of this — video models are the ones filling the issue tracker, and a clean SDXL result tells you nothing about them. If you are setting up a comparison from scratch, our ComfyUI FLUX workflow guide and SDXL vs FLUX comparison both include graphs you can reuse as a fixed baseline.

---

Verdict

1. If it broke after an update, try --disable-dynamic-vram first. One flag, instantly reversible, and it addresses seven of the eight symptoms above.
2. Read the line above the OOM. HostBuffer.read_file_slice failed means #15255 and a flag; HostBuffer.truncate failed means #15591 and pip install comfy-kitchen==0.2.30. Same word, different bug, different fix — and neither one means your GPU is too small.
3. Stop adding --lowvram. It is a no-op on a default install and has been since the February 2026 default flip. The source says so in plain English.
4. --novram "working" is a red herring. It disables DynamicVRAM as a side effect while also forcing everything to CPU. You almost certainly want just the first half.
5. On two or more GPUs, try --cuda-device 0 before you buy anything. If pinning to a single card clears the OOM, you did not have a capacity problem — you had the multi-GPU host-buffer bug.
6. If you want to keep DynamicVRAM, give it headroom. --vram-headroom 2 is a gentler intervention than switching the whole manager off, and it accounts for VRAM used by other applications.
7. Benchmark before you make it permanent. DynamicVRAM is not a mistake — it is a real improvement on the right hardware. Multi-GPU rigs, HDD-backed models, WSL and ROCm are where it currently hurts.

Recheck date: mid-November 2026. ComfyUI shipped v0.24.0 through v0.33.1 between 2026-06-03 and 2026-08-13 — twelve tagged releases in ten weeks — and every issue cited here was still open on 2026-08-23. #15255 in particular has an assignee and a linked PR, so it may well be resolved before you read this; check the issue before you apply the workaround. Flag names and defaults in this area have a short shelf life, and the --help command above is always more current than we are.

For hardware planning rather than firefighting, our best GPUs for image generation ranking covers what actually clears these workloads without flag gymnastics.

---

Sources

• comfy/cli_args.py, ComfyUI master — every flag name, default and help string quoted above; read 2026-08-18
• Issue #15255 — "Dynamic VRAM streaming crashes all generations with HostBuffer.read_file_slice failed → CUDA OOM (regression after Aug 3 2026 update) (CORE-398)"; opened 2026-08-03, open with 60 comments, assigned to rattus128, pinned maintainer comment 2026-08-06, linked PR #15610
• Issue #15591 — "[Bug] CUDA illegal memory access / HostBuffer.truncate failed with comfy-kitchen 0.2.31 during dynamic VRAM load (MiniMaxH3)"; opened 2026-08-13; source of the 0.2.31 broken / 0.2.30 working boundary
• Issue #15269 — "DynamicVRAM + AIMDO 0.4.11 causes 'VRAM Allocation failed (non OOM)' and 'Fault failed: 2' on second generation (QwenImage)"; opened 2026-08-03
• Issue #14340 — "VRAM OOM on Linux with large singular allocation but should be within limits"; opened 2026-06-08
• Comfy-Org/ComfyUI issue tracker — issues #15759, #15679, #15666, #15661, #15628, #15575, #15484, #15436, #12943 — all confirmed open with the titles quoted above on 2026-08-23
• ComfyUI releases — v0.33.1 published 2026-08-13; release cadence v0.24.0 (2026-06-03) through v0.33.1
• Commit history of comfy/cli_args.py — PRs #11845, #12658, #13002, #13922, #14480 with merge dates

---

FAQ