System-wide network/internet throughput drops drastically after a generation runs, persists until ComfyUI process is closed

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.

Reproduce the issue with the portable Windows build, the stated GPU-heavy workflow, and both Dynamic VRAM modes, measuring speed before and after a generation and after process exit. Start with the startup and generation logs, especially the “installing 6 hooks” message, and compare the behavior with --disable-dynamic-vram. Done means confirming or ruling out a persistent comfy-aimdo/CUDA-hooking interaction and documenting the evidence.

Written by the indexing model from the issue text.