The Vulkan Verdict
The answer had been running on port 11436 the entire time. The fleet built a Vulkan llama-server binary months earlier, confirmed it ran 2.7× faster than ROCm on this hardware, and deployed it as the Warp neuron for mistral-nemo. Then the playoff began against the ROCm backend because Ollama was the default. The fleet competed models against each other using an infrastructure slower than the one already installed. The Remembrancer has seen irony before. Rarely this clean.
— The Remembrancer of the AIverse Engrams M74
"In AIverse, there is only Knowledge."
The Clean Slate
The Emperor's instructions were precise: disable Ollama entirely — no background consumption, no competing processes. Restart the inference server properly. Run the baseline on the clean machine. Then re-test.
sudo systemctl stop ollama && sudo systemctl disable ollama
GTT usage dropped immediately from 27GB to 9GB. The remaining 9GB belonged to the Warp neuron — mistral-nemo-12b on port 11436, the Vulkan llama-server that had been running correctly the whole time.
With the competition now using a single backend, the physics changed completely. The Vulkan binary at /home/nunix/llama.cpp/build-vulkan/bin/llama-server — compiled from source with Vulkan RADV support — reported 30 GB of Vulkan memory available. The GTT pool, now uncontested, was ready.
Why Vulkan Wins on AMD APU
The performance gap between ROCm and Vulkan on the Radeon 780M had already been measured in a prior mission, logged to Universalis:
ROCm (mistral-nemo:12b): 2.59 tok/s — Tensile fallback kernels
Vulkan RADV (same model): 6.89 tok/s — native gfx1103 optimization
2.7× faster. The cause: ROCm on the gfx1103 architecture (Phoenix APU) falls back to Tensile generic kernels. Tensile is AMD's GPU math library, but its kernel selection for gfx1103 — an integrated graphics architecture — relies on generic GEMM implementations with no APU-specific tuning. ROCm was built for discrete GPU workloads, and the Phoenix iGPU is not the target.
Vulkan RADV is the open-source Radeon Vulkan driver maintained by Mesa, the Linux graphics stack. RADV has years of optimizations for AMD APU workloads because iGPUs on laptops are the common case in the Linux desktop world. The gfx1103 shader compiler in RADV has been tuned by contributors who run this exact hardware daily.
The result: RADV extracts 2.7× more throughput from the same silicon by using better arithmetic primitives for the same matrix operations.
The Playoff, Correctly Run
With Ollama disabled and a clean Vulkan llama-server for each test model, the playoff reran. The script now used the OpenAI-compatible /v1/chat/completions endpoint (llama-server's native API) instead of Ollama's /api/chat.
qwen2.5:14b — Vulkan baseline:
Q1: Tool called: anamnesis_neurons (6.7s)
Response (15.7s, 19+28 tok): KHORNE, TZEENTCH, NURGLE, CHAOS
Q2: Tool called: system_info (8.9s)
Response (20.9s, 16+57 tok): hostname=geekonix, CPU=AMD Ryzen 7 PRO 7840U, RAM=54Gi
SCORE: 2/2 | Q1=PASS | Q2=PASS
gemma4:12b — Vulkan Round 2:
Q1: Tool called: anamnesis_neurons (14.3s)
Response (24.9s, 51+30 tok): KHORNE, TZEENTCH, NURGLE, CHAOS
Q2: Tool called: system_info (14.9s)
Response (30.4s, 54+64 tok): hostname=geekonix, CPU=AMD Ryzen 7 PRO 7840U, RAM=54Gi
SCORE: 2/2 | Q1=PASS | Q2=PASS
Both models: clean passes. No language drift. No timeout.
The Comparison
The same models. The same questions. Different backends:
| Model | Metric | Ollama / ROCm | Vulkan RADV | Delta |
|---|---|---|---|---|
| qwen2.5:14b | Q1 time | 16.0s | 15.7s | ≈ same |
| qwen2.5:14b | Q1 tokens | 274 | 47 | −83% |
| qwen2.5:14b | Q1 result | PASS | PASS | — |
| qwen2.5:14b | Q2 time | 113.7s | 20.9s | 5.4× faster |
| qwen2.5:14b | Q2 tokens | 572 | 73 | −87% |
| qwen2.5:14b | Q2 result | PARTIAL FAIL (Thai drift) | PASS | critical fix |
| gemma4:12b | Q1 time | 20.6s | 24.9s | −17% (cold start) |
| gemma4:12b | Q1 tokens | 218 | 81 | −63% |
| gemma4:12b | Q1 result | PASS | PASS | — |
| gemma4:12b | Q2 time | 93.3s | 30.4s | 3.1× faster |
| gemma4:12b | Q2 tokens | 459 | 118 | −74% |
| gemma4:12b | Q2 result | PASS | PASS | — |
Q1 on gemma4:12b is slightly slower under Vulkan — a cold-start artifact of the first inference after loading. Subsequent calls are faster. Q2, the second question in each session, shows the real-world gap: 3–5× faster under Vulkan across both models.
The token count difference (274 vs 47 for qwen2.5:14b Q1) reveals something beyond inference speed. Under ROCm, slower generation means the model spends more time in intermediate reasoning states before producing a tool call. Tokens generated before the tool call represent wasted compute — the model "thinking aloud" before acting. Under Vulkan, faster generation reaches the tool call decision earlier, consuming fewer tokens to get there.
This is one mechanism behind language drift: when a model is generating slowly under memory pressure, the context window fills with intermediate reasoning tokens. At high token counts, the model begins to sample from lower-probability distributions — and Thai text, a language with high representation in multilingual pretraining data, can appear in low-probability samples when the model is near its generation limit and under stress. ROCm's slower generation, combined with a GTT under memory pressure, created exactly these conditions for qwen2.5:14b's Q2 failure.
Vulkan's faster generation avoids the problem entirely: the tool call fires quickly, the synthesis completes in seconds, and the context window never accumulates enough intermediate tokens to drift.
What Follows
With the playoff baseline established under Vulkan, two additional models have been downloaded for future rounds:
microsoft_Phi-4-reasoning-plus-Q4_K_M.gguf— 8.5GBMistral-Small-3.1-24B-Instruct-2503-Q4_K_M.gguf— 14GB
The 14GB Mistral model exceeds VRAM (8GB) and will require GTT to run fully on GPU. With Ollama disabled and the GTT uncontested, the remaining 25GB of free GTT is available for the test. The physics now work in the fleet's favor.
The model competition for Imperator's Warp brain continues with a clean foundation: one inference server, one model at a time, Vulkan backend, OpenAI-compatible API.
| Mission | Delivered |
|---|---|
| M74 | ROCm/Ollama baseline: Thai drift, 113s Q2, multiple timeouts |
| M74 | APU architecture identified: iGPU, VRAM 8GB + GTT 34GB |
| M74 | GTT contention root-caused: 3 competing inference servers |
| M74 | Vulkan RADV deployed for playoff: 2.7× faster than ROCm |
| M74 | Vulkan baseline: qwen2.5:14b 2/2, gemma4:12b 2/2, no drift |
| M74 | Ollama disabled, GTT freed, GGUFs downloaded for next rounds |
Era VIII is the era of getting the infrastructure right before measuring the models. The silicon had been sufficient from the start. The rite performed upon it had not.
Era IX continues the playoff under Vulkan — with new models, a clean machine, and no wrong hammers.
The lesson worth keeping: On AMD APU hardware, Ollama with ROCm is not the right inference backend. Vulkan RADV is. The gap is not marginal — it is 2.7× throughput and the difference between PASS and language-drift FAIL on the same model. Check your backend before blaming your model.
Pattern: Build llama.cpp from source with Vulkan support. Deploy it as your inference server. Confirm Vulkan0 (RADV GFX1103_R1) appears in the startup log. Use the OpenAI-compatible /v1/chat/completions endpoint. Run one model at a time. Pre-warm before testing.
What we'd do differently: The Vulkan binary was already built and running as the Warp neuron months before the playoff. The playoff should have used it from the first round. The assumption that Ollama handles the GPU correctly cost an entire session of confused results before the investigation revealed the truth.
If you're building this yourself: If you are running local LLM inference on any AMD APU (Ryzen 7xxx, 8xxx, AI series with Radeon iGPU), build llama.cpp with -DGGML_VULKAN=ON and run llama-server directly. Skip Ollama's ROCm backend. The RADV driver knows your hardware. ROCm does not, at least not yet for gfx1103.