Verify the stack on the real Radeon R9700 box (GPU passthrough + Lazytainer idle-stop) #5
Notifications
Due Date
No due date set.
Depends on
Reference: haylan/LLM-Server#5
Reference in New Issue
Block a user
Part of #1
Blocked by: #4
Question
On the actual Ryzen 9 5950X / R9700 machine: bring the stack up via
docker compose up, confirm ROCm sees the GPU inside the llama.cpp container, confirm inference works end-to-end (Open WebUI chat + Anthropic-shim request), then confirm Lazytainer correctly stops the idle container after the configured timeout and cleanly restarts it on the next request without leaking VRAM or hitting the known ROCm 100%-idle-GPU bug (ROCm/ROCm#5706) — check GPU utilization before/after a stop/start cycle. Report pass/fail and any config fixes needed; if the ROCm/HIP backend misbehaves, note whether switching to llama.cpp's Vulkan backend resolves it (see the map's Not-yet-specified section).haylan referenced this issue2026-08-25 04:39:30 +00:00
Confirmed on real hardware. rocm-smi after normal use (llama-server + llama-server-fast both up):
free -havailable: 26Gi/31Gi, theused/buff/cachesplit is just llama.cpp's mmap'd model files in page cache, not a leak.Not yet done: the idle-stop cycle test this ticket also asks for (Lazytainer stop/start, check VRAM doesn't leak across a cycle) — moot for llama-server specifically per #40's finding (lazytainer's idle-stop doesn't reliably fire on it anyway, see docs/research/lazytainer-omniroute-idle-stop.md). Also stale: this ticket's "Open WebUI chat" mention predates OmniRoute replacing Open WebUI as the client surface (see #31) — verification should now mean a CLI request through OmniRoute, not Open WebUI.
Next candidate step (unstarted, needs a decision): try llama.cpp's Vulkan backend instead of ROCm/HIP, per the map's Not-yet-specified section — nobody has tested whether that avoids this bug on this card.
Confirmed on the real server (#49, merged): the interactive gum-based config sync in scripts/update.sh works as designed — the conflict screen appeared for the stale LLAMA_FAST_PARALLEL=2 vs git's 1, selecting it applied the fix, and the Auto Mode classifier (qwen-code, llama-server-fast) works now. gum's release asset naming matched what ensure_gum() expected — no fix needed there.
Outstanding from this thread's earlier GPU-pin findings (#47, also merged): GPU_MAX_HW_QUEUES=1 and the numeric-GID group_add fix — still worth a follow-up rocm-smi check with both llama-server and llama-server-fast up, if not already done.
Confirmed: GPU_MAX_HW_QUEUES=1 + the numeric-GID group_add fix (#47) resolved the 100%-GPU-pin with both llama-server and llama-server-fast up. Combined with the earlier classifier-context and gum-sync confirmations above, real-hardware verification for this stack is complete: GPU passthrough works, ROCm sees the card, inference works end-to-end (via OmniRoute, not Open WebUI — that premise is stale, see earlier comment), and the known-risk GPU pin bug is fixed and confirmed rather than just theorized. The original Lazytainer idle-stop cycle test is moot by design (#40: it doesn't reliably fire on llama-server regardless; switch-model.sh bypasses it intentionally) rather than untested. Closing.