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

[roumani76-arch]

Mod Note:

This is a Cuda error and has been reported to NVIDIA

To workaround, please start comfy with --cuda-device 0 (or a higher number) to restrict comfy to a single GPU or use --disable-pinned-memory for multi GPU functionality

Please start from #15255 (comment) for the latest.

original report

Custom Node Testing

• I have tried disabling custom nodes and the issue persists (see how to disable custom nodes if you need help)

Expected Behavior

Dynamic VRAM streaming should work as it did prior to today's update, or fail gracefully without crashing the whole queue.

Actual Behavior

Environment:

ComfyUI version: 0.30.1
comfy-aimdo version: 0.4.11
comfy-kitchen version: 0.2.26
PyTorch: 2.10.0+cu130
OS: Windows (ComfyUI Desktop)
GPUs: RTX 5060 Ti (16GB, primary) + RTX 3060 (12GB, secondary)
Driver: NVIDIA 610.88, CUDA UMD 13.3

Summary:
After updating ComfyUI Desktop today (Aug 3, 2026), every generation — regardless of model (tested with Krea 2) — fails immediately during sampling with a host buffer read failure that cascades into a CUDA OOM error. This worked correctly before today's update.

Steps to reproduce:

Launch ComfyUI Desktop (dynamic VRAM enabled by default — log shows DynamicVRAM support detected and enabled)
Run any generation (tested: Krea 2 text-to-image)
Sampler starts, model loads and stages into VRAM normally
Crashes ~immediately with:
[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

During handling of the above exception, another exception occurred:
...
File "...\comfy\model_management.py", line 2005, in synchronize
torch.cuda.synchronize()
torch.AcceleratorError: CUDA error: out of memory

Notes:

nvidia-smi confirms this is not a real memory shortage — GPU 0 shows only ~2GB used out of 16.3GB before launch, 14+ GB free.
The crash is not model-size dependent — small and large models both fail identically.
Workaround confirmed: launching with --disable-dynamic-vram fixes it completely; all generations succeed normally with this flag.
This strongly points to a regression in comfy-aimdo's host-buffer/dynamic-VRAM-streaming layer introduced in today's update, since disabling that specific subsystem resolves the issue entirely.

Steps to Reproduce

Image generation in official Comfyui Krea2 turbo / z-image turbo workflows

Debug Logs

File "D:\ComfyUI\standalone-env\Lib\threading.py", line 995, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ComfyUI\ComfyUI\main.py", line 372, in prompt_worker
    e.execute(item[2], prompt_id, extra_data, item[4])
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ComfyUI\ComfyUI\execution.py", line 728, in execute
    asyncio.run(self.execute_async(prompt, prompt_id, extra_data, execute_outputs))
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ComfyUI\standalone-env\Lib\asyncio\runners.py", line 195, in run
    return runner.run(main)
           ~~~~~~~~~~^^^^^^
  File "D:\ComfyUI\standalone-env\Lib\asyncio\runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "D:\ComfyUI\standalone-env\Lib\asyncio\base_events.py", line 725, in run_until_complete
    return future.result()
           ~~~~~~~~~~~~~^^
  File "D:\ComfyUI\ComfyUI\execution.py", line 789, in execute_async
    result, error, ex = await execute(self.server, dynamic_prompt, self.caches, node_id, extra_data, executed, prompt_id, execution_list, pending_subgraph_results, pending_async_nodes, ui_node_outputs)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ComfyUI\ComfyUI\execution.py", line 645, in execute
    comfy.model_management.unload_all_models()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "D:\ComfyUI\ComfyUI\comfy\model_management.py", line 2027, in unload_all_models
    free_memory(1e30, device)
    ~~~~~~~~~~~^^^^^^^^^^^^^^
  File "D:\ComfyUI\ComfyUI\comfy\model_management.py", line 875, in free_memory
    memory_to_free = 0 if device is None else memory_required - get_free_memory(device)
                                                                ~~~~~~~~~~~~~~~^^^^^^^^
  File "D:\ComfyUI\ComfyUI\comfy\model_management.py", line 1747, in get_free_memory
    mem_free_cuda, _ = torch.cuda.mem_get_info(dev)
                       ~~~~~~~~~~~~~~~~~~~~~~~^^^^^
  File "D:\ComfyUI\ComfyUI\.venv\Lib\site-packages\torch\cuda\memory.py", line 897, in mem_get_info
    return torch.cuda.cudart().cudaMemGetInfo(device)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
torch.AcceleratorError: CUDA error: out of memory
Search for `cudaErrorMemoryAllocation' in https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html for more information.
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

[INFO] FETCH ComfyRegistry Data [DONE]
[INFO] [ComfyUI-Manager] default cache updated: https://api.comfy.org/nodes
FETCH DATA from: D:\ComfyUI\ComfyUI\user\__manager\cache\1514988643_custom-node-list.json [DONE]
[INFO] [ComfyUI-Manager] All startup tasks have been completed.

Other

No response

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• DynamicVRAM + AIMDO 0.4.11 causes “VRAM Allocation failed (non OOM)” and “Fault failed: 2” on second generation (QwenImage) #15269

🔗 Related PRs

#14215 - Avoid ROCm Conv3d crash in Qwen35 vision patch embedding by using equivalent linear projection [open]
#15215 - comfy-aimdo 0.4.11 [merged]
#15299 - Fix OOM_EXCEPTION fallback and guard mem_get_info in get_free_memory (#15255) [open]
#15348 - fix: Graceful fallback for dynamic VRAM init failures (closes #15255) [open]
#15349 - Add MiniMax H3 RTX 3060 Turbo profile [closed]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[SirWidebottom]

i get this too, on any workflow with v30.1,disabling dynamic vram or pinned memory gets it to work now.

[Davikar]

Same. Had do downgrade to 0.29.2.

[Pombaroom]

The same error. I did ZImage generations ok until this update. Now RAM consumption has become colossal! It goes over 80% and then gives me that error.
I have 24GB RAM and 16GB VRAM.
As SirWidebottom said

disabling dynamic vram or pinned memory gets it to work now.

It helped. (RAM consumption is 37%, btw)

[lzskrasia-spec]

I am experiencing what appears to be the exact same issue, but specifically with Z-Image-Turbo on ComfyUI v0.30.0. The first generation always succeeds without any issues, but the second generation gets stuck indefinitely at the KSampler stage — it never completes, and the process hangs. Real-time VRAM monitoring shows persistently high VRAM usage after the first generation, which never gets released properly. Downgrading ComfyUI from v0.30.0 to v0.29.0 completely resolves the issue; both generations work flawlessly after the downgrade. My hardware is an RTX 4080 with 16GB VRAM and 64GB system RAM. I have reproduced this multiple times with a completely clean v0.30.0 ComfyUI environment, running only Z-Image-Turbo with no other custom nodes or models loaded, and the issue persists every single time on the second generation. nvidia-smi shows plenty of free VRAM (around 14+ GB available), yet the sampler still gets stuck, which strongly suggests that the DynamicVRAM / comfy-aimdo 0.4.11 memory management regression is the root cause — exactly as described in this issue. Thank you for your work on this.

我遇到了几乎完全相同的问题，不过是在 Z-Image-Turbo 模型上，环境是 ComfyUI v0.30.0。第一张图总是能正常生成，但第二张图会无限卡在 KSampler 阶段，进度无法继续，整个流程卡死。实时显存监控显示，第一张图生成后显存占用一直居高不下，没有被正确释放。将 ComfyUI 从 v0.30.0 降级到 v0.29.0 后问题完全消失，两张图都能正常生成。我的硬件是 RTX 4080 16GB 显存和 64GB 系统内存。我在完全干净的 v0.30.0 ComfyUI 环境中多次复现了这个问题，仅加载 Z-Image-Turbo，没有任何其他自定义节点或模型，每次都在第二张图生成时卡住。nvidia-smi 显示显存仍有大量空闲（约 14GB 以上可用），但采样器仍然卡死，这强烈表明 DynamicVRAM / comfy-aimdo 0.4.11 的内存管理回归问题是根本原因，与本 issue 的描述完全一致。感谢开发者的辛勤工作。

[vizart-vj]

After updating to 0.30.1 have the same troubles with LTX and Minimax render. Infinite OOM. Z-Image works well.

[rattus128]

The same error. I did ZImage generations ok until this update. Now RAM consumption has become colossal! It goes over 80% and then gives me that error. I have 24GB RAM and 16GB VRAM. As SirWidebottom said

disabling dynamic vram or pinned memory gets it to work now.

It helped. (RAM consumption is 37%, btw)

Paste of our new RAM usage strategy - this is unlikely related to your crash:

TLDR: RAM management in comfy 0.30.0 has changed and uses more RAM than before to avoid loads from disks. If this is slower for you, start comfy with --fast-disk to change back to a lower RAM, but more disk intensive loading strategy. This is generally better for high speed NVME users.

In comfy 0.23.0 RAM management was changed to facilitate faster loads of models from disks and to unlock async offload to fast NVME disks. However some users, particularly with slower disks noticed performance issues with the new strategy and certain configurations would load models from disk when they previously wouldn't. In version 0.30 a new algorithm for balancing RAM allocation across models and workflows is implement to increase Comfys claim over the system RAM while also minimize RAM churn and disk reload for common usage patterns. To do this comfy now allocates and commits to as much RAM usage as it can get away with based on measured system RAM availability. It will still dynamically avoid swap/pagefile use as much as possible. This algorithm can be slightly slower for users with very fast disks due to extra RAM traffic or can put more pressure on system ram in general. --fast-disk can be added to the comfy startup args to prefer some extra disk loading over a lot of RAM allocation and traffic.

The performance improvement for users with slow disks is significantly larger than the performance loss for high speed disk usage which is why we are making this the new default mode.

Some users also have a fast C: and slow model disk. In this case the use of the pagefile/swap to buffer models can be an advantage over optimized original disk load. So if this is you, start comfy with --high-ram to fully avoid comfys anti-pagefile logic.

We are investigating options to auto-detect these variables and choose the best fit automatically in a future comfy release.

[rattus128]

Does --fask-disk solve it for people?

[SirWidebottom]

Does --fask-disk solve it for people?

@rattus128 for me, --fast disk worked, so did disabling dynamic vram or pinned memory. High vram got an OOM error.

[rattus128]

Ok @SirWidebottom and everyone else, are you able to help me out and put it back in the bad state and install this comfy-aimdo version? https://github.com/Comfy-Org/comfy-aimdo/actions/runs/30872550472. Download the wheel for your platform and pip install it.

It adds extra information that helps us distinguish possible root causes. We are having trouble reproducing this issue so the increased information will bring us closer to the variable that matters and a fix.

I will merge that to comfy-aimdo 0.4.12 anyway, but its immediately testable for those with this problem. Please paste the whole crash log from the first error. If in doubt, paste everything from "got prompt".

Please include your system information. If in doubt, paste entire comfy startup log.

[SirWidebottom]

@rattus128
here is the error after i installed the comfy-aimdo wheel
ComfyError.txt