docs: update llama.cpp comparison with 8192 results (OOM fixed)

Re-ran the full comparison at --max-seq-len 8192 now that xserv handles it:
- OOM finding resolved — pool sized to available VRAM + vLLM-style host swap;
  8192 runs with 0 swap events (swap is the overload safety net).
- Quality at parity with equal context: AIME 20.0% vs 20.0%, GSM8K 98% vs 96%.
- Speed unchanged relative to llama.cpp (~0.42-0.60x); TPOT is bandwidth-bound.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/16-llama-cpp-comparison.md

@@ -126,8 +126,7 @@ HF_ENDPOINT=https://hf-mirror.com python3 -m tools.bench.fetch_datasets
 
 **Full sweep on dash5 (recommended):**
 ```bash
-# 4096 ctx because xserv OOMs at 8192 (see Known constraints)
-./tools/sync-and-build.sh bench -- --max-seq-len 4096 --quality-limit 50
+./tools/sync-and-build.sh bench -- --max-seq-len 8192 --quality-limit 50
 ./tools/sync-and-build.sh fetch-bench-out
 open bench-out/comparison-*.md
 ```
@@ -179,17 +178,18 @@ python3 -m tools.bench.runner \
 
 ## Known constraints / findings
 
-- **xserv OOMs at `--max-seq-len 8192` + `--max-batch 4`.** xserv eagerly
-  pre-allocates its paged-KV pool (`total_blocks = blocks_per_seq · max_batch ·
-  2`, ≈9GB at 8192) on top of the 16GB weights, exceeding 32GB at startup
-  (`paged_kv_cache.rs` `alloc paged K pool: OutOfMemory`). llama.cpp allocates
-  KV lazily and fits 8192 easily. Until xserv's sizing is fixed, run the
-  comparison at `--max-seq-len 4096` (xserv peaks ~28GB there). The benchmark
-  surfaced this — it's tracked as a follow-up fix.
-- When the xserv engine thread dies, the request handler panics on the poisoned
-  `engine_sender` mutex and every subsequent request fails with "server
-  disconnected". The driver records these as per-request errors (no crash), so a
-  broken engine shows up as `errs=N` / `accuracy 0%` rather than a hung run.
+- **xserv OOM at `--max-seq-len 8192` — fixed.** xserv used to pre-allocate its
+  paged-KV pool (`total_blocks = blocks_per_seq · max_batch · 2`, ≈9GB at 8192)
+  on top of the 16GB weights, exceeding 32GB at startup (`paged_kv_cache.rs`
+  `alloc paged K pool: OutOfMemory`). Now the pool is sized to *available VRAM*
+  (`cudaMemGetInfo`) and overflow is swapped to pinned host memory (vLLM-style
+  preemption, `--swap-space-gb`). The 8192 comparison runs cleanly with 0 swap
+  events; swap is verified separately under a forced-small pool. The benchmark
+  surfaced the OOM — a good example of the baseline doing its job.
+- When the xserv engine thread dies, the API now returns a clean 503 (the
+  request handler uses a poison-tolerant lock instead of cascading
+  mutex-poison panics). The driver records any failure as a per-request error,
+  so a broken engine shows up as `errs=N` / `accuracy 0%` rather than a hung run.
 
 ## Future extensions