CUDA selection, GPU sharing budget, and embedding clustering

[Xore]

Migrated from docs/ROADMAP.md Release 4 and docs/WORK-LEDGER.md row GPU-001.

Source: docs/gpu-ml-worker-acceleration.md.

Scope

• CUDA selection with a reliable CPU fallback — reliable meaning tested, including the case where the GPU is present but busy.
• A tested GPU-sharing budget between the ML and LLM workers. Two processes assuming they own the card is an outage waiting for the first concurrent run.
• Embedding-based clustering with a versioned index mapping.

First step

Verify current CUDA/PyTorch compatibility on the live host and record the exact pins before editing anything. Requires measured CPU baselines from #62 and stable output contracts from #63.

[Xore]

#82 live pin verification found the guide's planned CUDA wheel is invalid: the official cu124 index has no PyTorch 2.13.0 (it stops at 2.6.0).

Verified replacement on the actual RTX 4000:

• torch==2.13.0+cu126 from the official cu126 index;
• CUDA runtime 12.6, cuDNN 9.10.2;
• wheel architecture list includes sm_75 and the device reports capability 7.5;
• deterministic GPU matrix check passed in a network-disabled container;
• the exact 2.13.0+cpu environment also clean-built and passed imports/pip check, so CUDA selection, GPU sharing budget, and embedding clustering #67 can keep a same-version CPU fallback.

Embedding proof also passed: sentence-transformers==3.0.1 with sentence-transformers/all-MiniLM-L6-v2 pinned to revision 1110a243fdf4706b3f48f1d95db1a4f5529b4d41, prefetched at build time, then loaded and encoded offline to shape (1, 384).

[Xore]

#83 synthetic canary adds a concrete sharing-budget measurement for #67: qwen3.5:4b used about 4.1 GiB on the RTX 4000 at 8192 context, ran 100% on GPU, and unloaded 32.047 s after the last request with a 30 s request keep-alive. GPU memory returned to the 1 MiB idle reading and no canary compute process remained. This leaves roughly half the 8 GiB card free while loaded, but #67 should still treat simultaneous training as a deliberate collision case and preserve the verified CPU fallback.

[Xore]

Following #84's move to post-0.1.0: since #67 was only in the 0.1.0 gate list as #84's dependency, it moves to post-0.1.0 backlog too. Still real, still worth doing — just not blocking the 0.1.0 cut.