A local AI runtime reserves memory after a request so future tensors can reuse device blocks without paying repeated allocation and synchronization costs.
The visible result can look like a leak: GPU compute falls to zero, the reply is complete, but the process still occupies most of the accelerator memory. Part of that footprint may be live model weights or KV state, while another part belongs to a caching allocator, execution context, graph capture, library workspace, or model keep-alive policy. The sections below distinguish active allocations from reusable reservations and show when persistent memory is normal, wasteful, or evidence of a real leak.
Device Allocation Is Expensive Enough to Cache
Request-time tensors are created and released repeatedly. Returning every block to the driver can introduce synchronization and make the next request rebuild the same memory layout.
PyTorchโs CUDA allocator separates cached allocator blocks from tensors that remain actively allocated.
Keeping free blocks inside the process improves repeated-request latency, but another AI service cannot use those bytes until the allocator releases them to the driver.
Allocated, Reserved, and Device-Free Memory Are Different Metrics
Allocated memory belongs to live tensors. Reserved memory is managed by the runtime allocator and can include both live allocations and currently unused reusable blocks.
A runtime can therefore show a reserved-memory gap even after temporary tensors are destroyed.
Device tools such as nvidia-smi report the processโs driver-visible footprint, not which blocks are logically free inside the framework.
Model and Runtime State May Intentionally Remain Warm
The process may keep model weights, tokenizer state, kernels, execution graphs, and accelerator contexts ready because unloading them would turn the next request into a cold start.
ZimaSpaceโs explanation of model residency shows why a warm service consumes memory even when no user is currently generating tokens.
This is a deliberate capacity-latency trade. The memory is idle from a compute perspective but still valuable as ready state.
Fragmentation Can Leave Reserved Blocks Poorly Reusable
A pool may contain enough unused bytes in total while its block sizes do not match the next request. Variable prompts, image shapes, batches, and model switches can create a fragmented reservation pattern.
GMLake studies allocator fragmentation caused by irregular allocation sizes.
In that case, the retained memory is neither actively useful nor available to other processes, and a process restart may temporarily restore a cleaner layout.
Measure Whether the Footprint Stabilizes or Grows
Run the same fixed request repeatedly and record allocated, reserved, KV cache, model weight, and device-free memory after each completion.
A stable high-water mark suggests normal caching or keep-alive behavior. A footprint that grows with every identical request and never reuses old blocks suggests a leak, unbounded cache, retained session, or workload variation.
Test cache-release controls only after confirming which state they remove. Emptying unused allocator blocks does not unload live model weights, and unloading the model can damage response time.
For a multi-service home server, define a memory budget and idle policy per runtime so one serviceโs reservation does not silently prevent another from starting.
Tech & AI HUB
More to Read

Why Do Smart Home Predictions Become Less Accurate After Seasonal Routine Changes?
Seasonal routines change the relationship between time, sensors, occupancy, and desired actions, making a model trained on older habits stale.

Why Does a Home NVR Miss Brief Events When Object Tracking Is Enabled?
Tracking needs enough detections to start and confirm a trajectory, so a brief object can disappear before the NVR creates a valid event.

Why Do AI Photo Labels Change After a Model Upgrade?
A model upgrade changes the representation and ranking used to assign labels, so the same photo can cross different semantic or confidence boundaries.

