Reporting VRAM via torch.cuda.mem_get_info lazily creates the CUDA primary
context (~256 MiB on an RTX 3090). An engine that never loads a torch model
(the GGUF/llama.cpp engine) therefore pinned ~256 MiB just to answer health
polls, the capability probe and the load-path eviction check — and that stray
context was enough to tip a borderline 4-bit Wan2.2 A14B video load into OOM.

New codai/models/gpu_query.py queries VRAM without a context: pynvml first,
nvidia-smi fallback, torch only if a context already exists. visible_gpu_memory()
scopes to the engine's cards via CUDA_VISIBLE_DEVICES (matched by index OR UUID;
empty value -> no CUDA cards, e.g. the Vulkan/Radeon engine).

Wired into the idle health poll (api/app.py), the capability probe
(broker/capabilities.py) and the load-path free-VRAM checks
(models/manager.py: _get_free_vram_gb / _free_vram_snapshot). Adds nvidia-ml-py
to requirements-nvidia.txt and the update overlay. Bumps to 0.1.28.

Net: the GGUF engine sits at 0 MiB while idle (its real context comes from
llama.cpp on model load and is freed on unload), returning the headroom that
makes the A14B load fit instead of OOM-ing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RdMufYvtTbtGDWsiZVoXce