fix(fv-ml1): pin vLLM KV in bytes on meromero (22 GiB) and coder; gen-small KV 8 -> 5.5 GiB
meromero-rp sized its KV from --gpu-memory-utilization, and vLLM's profile counts co-booting neighbours as its own non-torch memory. Three boots gave 20.37 / 26.74 / 29.04 GiB of KV, and the 2026-10-05 Docker-move restart cut GPU 1 free memory to 3,981 MiB, below intern-decision's 32k-token budget. Coder read negative KV on every co-boot. Both are now pinned, so util only gates the boot check (meromero util 0.52 -> 0.47, just above its footprint). GPU 0 plateaus at ~60 MiB free 1-2 days after a boot (Beszel), so gen-small's KV drops to 5.5 GiB (461,215 tokens, 1.76x) and parakeet-nemo stays on GPU 0 with room for its 3,840 MiB cap. GPU 3 stays clear. Applied with playbooks/fv-ml1-kv-pin-20261005.yaml: GPU 1 free 3,981 -> 11,801 MiB, GPU 0 495 -> 5,039 MiB right after boot; all nine seats healthy.
This commit is contained in:
@@ -58,7 +58,7 @@ services:
|
||||
# avoids the util-fraction fight between co-resident seats. fp8 KV + an A3B's small
|
||||
# attention footprint make this cheap; tuned to a sane concurrency band, not max.
|
||||
- --kv-cache-memory
|
||||
- "${GEN_SMALL_KV_CACHE_MEMORY:-8589934592}"
|
||||
- "${GEN_SMALL_KV_CACHE_MEMORY:-5905580032}"
|
||||
- --max-model-len
|
||||
- "${GEN_SMALL_MAX_MODEL_LEN:-262144}"
|
||||
- --max-num-seqs
|
||||
|
||||
Reference in New Issue
Block a user