llama.cpp's CUDA backend and PyTorch sharing one process corrupt the CUDA context:
after a GGUF model runs on an NVIDIA card, the next torch kernel dies with
"CUDA error: invalid argument". Seen in a township match — a gemma GGUF served a
chat completion on the nvidia engine, then the next Z-Image (diffusers) image gen
crashed in its Qwen3 text-encoder's sdpa mask (padding_mask.all()). Every Z-Image
run before llama.cpp touched CUDA succeeded; the first one after crashed. Evict+swap
in one process can't fix it — torch holds the (now-corrupted) context for the
process lifetime.

Fix: when GPUs are auto-detected and server.isolate_gguf_engine is True (default),
each NVIDIA torch engine gets a co-located sibling gguf engine on the SAME card
(own process -> own CUDA context). The torch engine drops the `gguf` capability and
serves transformers/diffusers; the sibling (backend=nvidia so GGUF takes the proven
CUDA-llama path, capabilities={gguf}) serves llama.cpp. Routing is already
capability-based, so GGUF goes to the gguf engine and HF/diffusers to the torch
engine. Both are real engine subprocesses, so the front's routing, VRAM/eviction and
thermal (cooperative pause + SIGSTOP on the process group) apply unchanged — and
SIGSTOPping the gguf engine no longer freezes the torch engine.

Ignored when engine_specs is set (declare the split yourself). Disable with
server.isolate_gguf_engine=false. Design + trade-offs (extra torch context, no
cross-engine eviction on a shared card) in docs/gguf-process-isolation.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RdMufYvtTbtGDWsiZVoXce