Symptoms
Symptom cards: the literal line, the cause, the fix
Cards are written only for failures the lab hit and wrote up; each one links the report or guide where it was observed. Nothing on this page is a performance number.
Strix Halo (Ryzen AI Max+ 395)
-
dropping integrated GPU; to enable, set OLLAMA_IGPU_ENABLE=1Ollama
Ollama's Vulkan path drops integrated GPUs by default while the bundled ROCm backend picks up gfx1151 on its own, so the drop line needs no action; update Ollama only if no ROCm line follows, then confirm with ollama ps that the model sits fully on the GPU.
-
mem_info_vram_total: 512 MiBllama.cpp server (Vulkan)
On Linux the GPU reaches unified memory through GTT, and the ceiling is the TTM pages_limit kernel parameter, not the BIOS VRAM slice; raise ttm.pages_limit on the kernel command line, reboot, and re-read the sysfs files.
DGX Spark (GB10)
-
cuTensorMapEncodeTiled illegal memory accessvLLM
Driver 595.58.03 broke NVFP4 on GB10 with a cuTensorMapEncodeTiled illegal memory access; pin driver 580.142. In the same mainline vLLM build, kernels built for compute_120f unpacked NVFP4 weights in software, and VLLM_USE_FLASHINFER_MOE_FP4=0 was a workaround, not a fix.
-
dcgm-exporter is dead and NVML answers N/Adcgm-exporter / NVML
On GB10 unified memory, dcgm-exporter does not work and NVML returns N/A on many of the fields operators alert on; we parse nvidia-smi into node-exporter's textfile collector on a systemd timer, with a staleness alert on the collector itself.
-
the server must report the B12X backend, not the DEEPGEMM fallbackvLLM
vLLM's auto MoE backend skips the FlashInfer MXFP4 kernel shipped for DeepSeek-V4-Flash on GB10 and takes the DEEPGEMM fallback; pass --moe-backend flashinfer_b12x and confirm the B12X backend in the server log.
Any local stack
-
HTTP 200, empty answerllama.cpp server (Vulkan)
The reasoning pass spent the whole completion budget before the first answer token, so the server reported success with nothing to show; raise the budget or turn reasoning off, and count answer tokens instead of status codes.
-
thinking stream starts immediately — it is just not addressed to the userllama.cpp server (Vulkan)
The first streamed token is the model's reasoning block, not the reply, so time-to-first-token looks instant while the answer starts late or never; clock time to first answer token client-side, count empty answers as failures, switch reasoning off where the workload allows.
-
your container will show unhealthy while serving perfectlyllama.cpp server (Docker)
The llama.cpp server image ships a healthcheck aimed at port 8080; start the server on another port and Docker marks the container unhealthy while it serves fine. Keep 8080 inside the container or override the check.