NVIDIA PAIR routing to llama.cpp on an AMD ROCm node (2×R9700). Notes.

PAIR (NVIDIA's Personal AI Router) ships GPU telemetry only for NVIDIA nodes — AMD nodes report a blind fallback, so the scheduler can't see their load. I added AMD ROCm telemetry and got a two-node cluster routing to my tuned llama.cpp setup on the AMD box.

* Routes to llama.cpp/llama-swap on the AMD node — not just Ollama/LM Studio. PAIR only natively knows those two engines, but a custom manifest fronts an existing llama-swap (OpenAI-compatible) server, so my tuned llama.cpp serves the cluster directly.

* AMD GPU telemetry (utilization + VRAM) via amd-smi (ROCm 7.2.0), feeding the scheduler like the NVIDIA path does. Verified under the Go race detector and live on 2×R9700 (gfx1201) — utilization tracks load.

* Full stack builds and runs on Linux/ROCm; two-node cluster PIN-paired with an NVIDIA box, inventory advertised both ways.

* Full stack builds and runs on Linux/ROCm; Kubuntu (AMD/ROCm) node PIN-paired with a Windows 11 (NVIDIA) box — cross-OS cluster, inventory advertised both ways.

Vibe-coded, locally. Implementation written by a local Qwen model; the review/verification loop was local models too. Ran surprisingly well — the review caught real issues and, when I ran the tests myself, hadn't fabricated its results.

Setup gotchas:

* Fronting llama-swap (or any OpenAI-compatible server) needs a custom engine manifest. A process-mode manifest + adoption does it: PAIR probes the running port and adopts the live server instead of spawning its own. Quirks: runtime.bin is required even though it never launches anything, and list_models just maps /v1/models → data[].id.

* Manifests are embedded into the binary at build time. Editing the JSON on disk does nothing until you rebuild and restart the broker. Cost me an hour chasing a "broken" manifest that was fine — I just never rebuilt.

* Proxies are per-protocol, not per-node — a mixed cluster (Ollama on one node, OpenAI-compat on another) splits inventory across two proxy ports; no single endpoint lists everything.

Intel: untested. The change also touched an Intel xpu-smi backend, but I didn’t test it on my Intel hardware yet — built against synthetic fixtures only, field names and units unverified and possibly wrong. Leave it out of the registry until someone validates it on real Arc hardware. Flagging so nobody assumes it's proven.