RFC: HRX (Loom) + NPU, and Vulkan out once HRX meets the gates

[bong-water-water-bong]

Proposal. The engine becomes HRX (AMD's ggml-hrx, kernels written in Loom) for the GPU plus the NPU, and Vulkan is removed. The removal lands only once HRX meets the gates below; until then Vulkan stays the default and nothing is taken out.

Why. HRX is AMD's own backend for this hardware, its kernels are ours to write and fix (the #123/#140 race fix, the ZAYA and Laya kernels, #180), and it is the path the NPU and GPU work already share. Carrying two GPU stacks doubles the pins (third_party/llama.cpp-vulkan and the HRX build), the bump workflows, the packaging and the test matrix.

What Vulkan does today (main at f362a09).

• It is the default device: config/route-policy.json sends every Laya class to vulkan, and --device auto picks it for GGUFs.
• It is the fastest decode we have measured on most models. ZAYA1-8B Q4_K_M: Vulkan 93.0 tok/s, ROCm 61.5, HRX 47.9 (docs/vulkan.md). On Qwen3-Coder-30B-A3B, Vulkan decodes about 10% faster than the ROCm W4A4 route and wins for prompts under ~2K tokens (tools/e2e_bench.py: time to first token and effective speed; W4A4 vs Vulkan end to end #202).
• Upstream features arrive there first, because its pin follows ggml-org's latest release: Qwen3.8 MTP (--mtp), DFlash2 (--dflash), and Zamba2 (carried ggml-org#21412). Qwen3.8-Flash-Next loads on Vulkan and fails to load on the HRX pin.
• PR-Agent's model (coder-llm) runs on it.

Where HRX stands. It maps nearly the same models: 94.77% of HF text-generation models against Vulkan's 94.87%, and 64.31% against 64.32% checked end to end (census 2026-09-28). Its prompt processing already beats Vulkan's on long prompts (HRX prefill + Vulkan decode: -26% time on an 8K prompt, Qwen2.5-7B). Known issues (docs/hrx.md): several sequences per batch fail (3-D MUL_MAT), -fa off fails, and each new shape pays a JIT compile on first use.

Gates before removal (each measured on Strix Halo, numbers in the PR that removes Vulkan):

1. Decode within 10% of today's Vulkan on the showcase models: Qwen3-0.6B, Qwen3-Coder-30B-A3B, Qwen3.8-27B, ZAYA1-8B (93.0 today on Vulkan).
2. Every architecture the registry marks checked on Vulkan is checked on HRX, including Qwen3.8-Flash-Next and the Zyphra family.
3. --mtp, --dflash, --parallel (several sequences per batch) and --mmproj work on HRX.
4. First-request latency: per-shape JIT warm-up no longer costs tens of seconds on a long prompt (it cost 46 s on a 5.4K prompt, 2026-09-27).
5. serve_e2e, smoke_serve and the Lemonade recipe test pass with no Vulkan in the build.

Then, in one PR: drop third_party/llama.cpp-vulkan and bump-llama-vulkan.yml, the vulkan device in 1bit serve and route-policy.json, the Vulkan builds in packaging, weekly.sh and build-windows.sh, and the Vulkan columns in the registry; move PR-Agent to HRX; update the docs, the site and NOTICE.

Not in scope. The ROCm lean route (Hadamard W4A4), ZINC and DwarfStar are separate backends; each gets its own decision.

Open questions. Windows builds use Vulkan (build-windows.sh); HRX has no Windows path yet. The ONNX WebGPU provider (Dawn) sits on Vulkan too.

[bong-water-water-bong]

Credit where it's due: this direction is geramyL's (a moderator on Lemonade's Discord). Reviewing the Laya work, they said "we want it on the NPU / vulkan version of it already exists / HRX + LOOM + NPU". We moved only the Laya scorer to HRX then (#208). The owner now agrees it's the right call for the whole engine, and this RFC is how we get there without losing speed or models on the way.