[GH-ISSUE #87] System-wide network/internet throughput drops drastically after a generation runs, persists until ComfyUI process is closed #30

New issue

Open

opened 2026-10-26 22:23:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 22:23:49 +00:00

Owner

Originally created by @Andrzej76GT on GitHub (Aug 11, 2026).
Original GitHub issue: https://github.com/Comfy-Org/comfy-aimdo/issues/87

Environment

GPU: NVIDIA GeForce GTX 1650 (4096 MB VRAM, Turing architecture)
System RAM: 16 GB
OS: Windows
ComfyUI: portable Windows build, revision 30 bb131be9, released 2026-06-30
comfy-aimdo version: 0.4.10
comfy-kitchen version: 0.2.16
PyTorch: 2.12.0+cu126
Tested with Dynamic VRAM both enabled (default) and explicitly disabled (--disable-dynamic-vram) — see below

Symptom

Once at least one image generation has run in a ComfyUI session, overall system network throughput (measured with Ookla Speedtest, in Chrome, on a separate network-facing app) drops drastically — from a normal baseline of ~130 Mbps down to roughly 1–11 Mbps. This degraded state:

Persists through idle periods (i.e. it does NOT recover once the generation finishes and the queue is empty — confirmed by running a speedtest while ComfyUI was confirmed idle/no job running, well after the prompt had finished).
Recovers immediately upon fully closing the ComfyUI console/process (confirmed multiple times back-to-back: ~1.5–11 Mbps while running → ~130+ Mbps within seconds of closing the console window).
Is reproducible across multiple separate test sessions on different days.

What I ruled out

The ComfyUI python.exe process itself sending/receiving data: Task Manager's per-process Network column consistently shows ~0 Mb/s for the ComfyUI python.exe process throughout, even while the system-wide speedtest result is degraded. Confirmed via "Open file location" that the process is specifically ...\ComfyUI_windows_portable\python_embeded\python.exe (Python 3.12.10), not a different Python install.
Antivirus/firewall interference: added an explicit outbound+inbound Windows Firewall block rule for that exact python.exe path — made no difference to the symptom.
Other local Python processes: found other unrelated Python 3.10 processes running on the machine at the same time (a separate in-house application), confirmed via file path that they are unrelated to ComfyUI.
General connection instability: the connection (T-Mobile fixed wireless) is otherwise consistently stable — confirmed via repeated speedtests with ComfyUI fully closed, always in the 100+ Mbps range.

Hardware/driver angle I suspect (unconfirmed)

Given the pattern — only starts after the first active generation, not tied to whether a job is currently running, and only clears on full process exit — I suspect this may be related to comfy-aimdo's on-demand VRAM paging (VBAR reservation via cuMemAddressReserve/cuMemMap, CUDA driver hooking — "installing 6 hooks" in the startup log) staying active/resident for the lifetime of the process rather than being released between jobs. I don't have low-level tooling to confirm this is actually the cause vs. some other driver-level interaction (e.g. WDDM/GPU driver behavior specific to older Turing cards like the GTX 1650), so flagging it as a hypothesis rather than a diagnosis.

Steps to reproduce

Start ComfyUI (portable Windows build) with a GPU-heavy workflow (in my case: Z-Image Turbo GGUF Q4_K_M, 768x768, 8 steps).
Confirm baseline network speed with ComfyUI closed (should be normal for your connection).
Start ComfyUI, run one generation to completion.
With the queue empty and ComfyUI idle, run a speedtest again — throughput drops drastically.
Fully close the ComfyUI console — throughput recovers within seconds.

Question

Has anyone else observed anything like this? Is there a known interaction between the Dynamic VRAM / comfy-aimdo CUDA hooking mechanism and network throughput, particularly on older (Turing-generation) GPUs? Happy to provide full startup + generation logs if useful.

Originally created by @Andrzej76GT on GitHub (Aug 11, 2026). Original GitHub issue: https://github.com/Comfy-Org/comfy-aimdo/issues/87 Environment GPU: NVIDIA GeForce GTX 1650 (4096 MB VRAM, Turing architecture) System RAM: 16 GB OS: Windows ComfyUI: portable Windows build, revision 30 bb131be9, released 2026-06-30 comfy-aimdo version: 0.4.10 comfy-kitchen version: 0.2.16 PyTorch: 2.12.0+cu126 Tested with Dynamic VRAM both enabled (default) and explicitly disabled (--disable-dynamic-vram) — see below Symptom Once at least one image generation has run in a ComfyUI session, overall system network throughput (measured with Ookla Speedtest, in Chrome, on a separate network-facing app) drops drastically — from a normal baseline of ~130 Mbps down to roughly 1–11 Mbps. This degraded state: Persists through idle periods (i.e. it does NOT recover once the generation finishes and the queue is empty — confirmed by running a speedtest while ComfyUI was confirmed idle/no job running, well after the prompt had finished). Recovers immediately upon fully closing the ComfyUI console/process (confirmed multiple times back-to-back: ~1.5–11 Mbps while running → ~130+ Mbps within seconds of closing the console window). Is reproducible across multiple separate test sessions on different days. What I ruled out The ComfyUI python.exe process itself sending/receiving data: Task Manager's per-process Network column consistently shows ~0 Mb/s for the ComfyUI python.exe process throughout, even while the system-wide speedtest result is degraded. Confirmed via "Open file location" that the process is specifically ...\ComfyUI_windows_portable\python_embeded\python.exe (Python 3.12.10), not a different Python install. Antivirus/firewall interference: added an explicit outbound+inbound Windows Firewall block rule for that exact python.exe path — made no difference to the symptom. Other local Python processes: found other unrelated Python 3.10 processes running on the machine at the same time (a separate in-house application), confirmed via file path that they are unrelated to ComfyUI. General connection instability: the connection (T-Mobile fixed wireless) is otherwise consistently stable — confirmed via repeated speedtests with ComfyUI fully closed, always in the 100+ Mbps range. Hardware/driver angle I suspect (unconfirmed) Given the pattern — only starts after the first active generation, not tied to whether a job is currently running, and only clears on full process exit — I suspect this may be related to comfy-aimdo's on-demand VRAM paging (VBAR reservation via cuMemAddressReserve/cuMemMap, CUDA driver hooking — "installing 6 hooks" in the startup log) staying active/resident for the lifetime of the process rather than being released between jobs. I don't have low-level tooling to confirm this is actually the cause vs. some other driver-level interaction (e.g. WDDM/GPU driver behavior specific to older Turing cards like the GTX 1650), so flagging it as a hypothesis rather than a diagnosis. Steps to reproduce Start ComfyUI (portable Windows build) with a GPU-heavy workflow (in my case: Z-Image Turbo GGUF Q4_K_M, 768x768, 8 steps). Confirm baseline network speed with ComfyUI closed (should be normal for your connection). Start ComfyUI, run one generation to completion. With the queue empty and ComfyUI idle, run a speedtest again — throughput drops drastically. Fully close the ComfyUI console — throughput recovers within seconds. Question Has anyone else observed anything like this? Is there a known interaction between the Dynamic VRAM / comfy-aimdo CUDA hooking mechanism and network throughput, particularly on older (Turing-generation) GPUs? Happy to provide full startup + generation logs if useful.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Comfy-Org/comfy-aimdo#30

No description provided.

Rows
Columns