From cc423567e7256eb6a095704d56288ddedc017cf4 Mon Sep 17 00:00:00 2001 From: claude Date: Sun, 2 Aug 2026 22:29:58 +0400 Subject: [PATCH] docs: record that contention is KFD presence, not a VRAM threshold (V-489) --- docs/offload.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/offload.md b/docs/offload.md index 7b2957f..4c6a6c8 100644 --- a/docs/offload.md +++ b/docs/offload.md @@ -71,6 +71,22 @@ It arbitrates nothing between callers. It reports whether it can take work and manages one process to back that answer. Maven never asks it to start anything and never learns that it did. +Contention is decided by presence under `/sys/class/kfd/kfd/proc`, not by a VRAM +threshold. A ROCm process registers there when it initialises HIP, before it +allocates anything. So the supervisor sees a contender during that job's startup, +and yields before the job loses the memory it asked for. A +threshold reads the card too late. By the time free VRAM has dropped, the other +job has already lost the allocation race. Free VRAM is still read, but only as a +precondition for loading, never as the eviction signal. One blind spot is known. +A job can take the card without registering on the KFD, as a Vulkan or a +video-decode job would. `describe()` logs every contender's comm, and that log is +how we find out whether the blind spot is real. + +`mavgpud` runs from a systemd unit on the workstation with +`deploy/mavgpud.json` as its config, and `llama_args` is passed to llama-server +untouched. The model, the context size, the layer count and the MTP flags are the +owner's business and not this daemon's schema. + ## What stays on homesrv, permanently The **embedder** (multilingual-e5-small, ONNX, CPU). It backs the classifier, which