docs: the ubatch optimum, the rebalance, and the live atomics chain

New page [[frank-medium-batch-ubatch]]: the sweep's method (one invocation per
cell, a VRAM sampler per cell, 64k prefill measured AT 64k depth), the full
batch x ubatch matrix, the depth-0 control, the deployed-shape VRAM table, and
the limitations — including the one that cost me two runs, that amdgpu does not
return ~26 GiB at once, so a reload after a kill fails with "unable to allocate
ROCm0 buffer" and reads exactly like a configuration that does not fit.

AGENTS.md: the batch lesson now carries the measured curve (the peak at 512, the
10 % loss at 2048, the irrelevant logical batch, the invariant decode) instead
of the "~3.3 vs ~1.7 GiB" figure, which was measured at the bench's shape; at
the deployed shape the asymmetry is 2.41 against 1.30. Fleet row and the
frank-medium section now say 35:30 and batch 6144x512.

Runbook: deployed flags, the split history with the ubatch-512 table, the fault
note, and the verified VRAM (6.44 / 6.90 idle, 6.23 / 6.64 under two concurrent
requests).

Dual-R9700-Cooperation: the live capability table (card 0 ReqEn+ against card 1
ReqEn-, x1 effective link on card 1) and an honest label on the M.2_2 riser
premise — it is ASUS's spec sheet, not a measurement, and CPU-attached does not
imply Routing+ on this board (00:08.3 is CPU-side and Routing-).

log.md: the round trip recorded, newest first.

serverAppConfigs-docs/LLM/frank-medium-llamacpp-dflash2.md

@@ -1,7 +1,7 @@
 ---
 type: configuration
 title: frank-medium llama.cpp Runbook (DFlash2 drafter)
-description: The ACTIVE frank-medium deployment since 2026-09-16 — mainline llama.cpp on Dankserver serving ajgazin/Swift-Qwen3.8-27B-Uncensored-Dynamic-MTP at UD-Q8_K_XL with the z-lab Qwen3.8-27B-DFlash2 Q8_0 drafter, as ONE layer-split process across both Radeon AI PRO R9700 cards at a 36:29 split, 262144 ctx over two slots.
+description: The ACTIVE frank-medium deployment since 2026-09-16 — mainline llama.cpp on Dankserver serving ajgazin/Swift-Qwen3.8-27B-Uncensored-Dynamic-MTP at UD-Q8_K_XL with the z-lab Qwen3.8-27B-DFlash2 Q8_0 drafter, as ONE layer-split process across both Radeon AI PRO R9700 cards at a 35:30 split, 262144 ctx over two slots.
 tags:
   - frank-medium
   - dankserver
@@ -144,10 +144,10 @@ Deployed flags:
 
 | Flag | Value | Why |
 |---|---|---|
-| `--split-mode` / `--device` / `--tensor-split` | `layer` / `ROCm0,ROCm1` / `36,29` | both cards, one model, no collective; the split is skewed because ROCm1 carries the drafter, and it is one LAYER of granularity — 0.43 GiB on a DeltaNet boundary, 1.43 GiB on an attention one |
+| `--split-mode` / `--device` / `--tensor-split` | `layer` / `ROCm0,ROCm1` / `35,30` | both cards, one model, no collective; the split is skewed because ROCm1 carries the drafter, and it is one LAYER of granularity — 0.43 GiB on a DeltaNet boundary, 1.43 GiB on an attention one |
 | `--gpu-layers` / `--fit` | `999` / `off` | everything on the cards; auto-fit must not resize a context we set |
 | `--ctx-size` / `--parallel` | `262144` / `2` | the model's whole window over two slots of 131072; `--parallel` **divides** the context |
-| `--batch-size` / `--ubatch-size` | `6144` / `1536` | 3x the defaults; `--ubatch-size` is what the compute buffers cost, and it is what forced the rebalance |
+| `--batch-size` / `--ubatch-size` | `6144` / `512` | measured: ubatch 512 is the prefill optimum *and* the cheapest point on the curve; the logical batch is throughput- and VRAM-neutral. See [[frank-medium-batch-ubatch]] |
 | `--ctx-checkpoints` / `--cache-ram` | `0` / `8192` | no per-slot KV snapshots (the build's default); the RAM-side prompt cache is capped at 8 GiB |
 | `--flash-attn` / cache types | `on` / `f16` K and V | an agentic checkpoint is the wrong place to spend KV precision |
 | `--spec-type` / `--spec-draft-n-max` | `draft-dflash,ngram-mod` / `7` | DFlash2 blocks are 8 tokens, so 7 drafts is the ceiling; ngram-mod rides the chain as a draftless second proposer |
@@ -227,25 +227,38 @@ qwen35 is 16 x (3 Gated DeltaNet + 1 Gated Attention), so a step is worth
 of that table — 37,28 -> 38,27 moves a DeltaNet layer, 38,27 -> 39,26 an
 attention layer. Balance by measurement, never by interpolating.
 
-36:29 is both the minimum and the point that leaves the most room: it clears the
-operator's 1.5 GiB-per-card floor by 3.2 GiB, so no headroom has to be bought
-out of `CTX_SIZE` and the model's full 262144-token window stays.
+**Then the batch moved, and the split followed it** (2026-09-16, the same day
+— see [[frank-medium-batch-ubatch]]). 36:29 was the balance at ubatch **1536**;
+the sweep showed 512 is both faster and 3.71 GiB cheaper, and — because the
+compute buffers cost ROCm1 nearly twice what they cost ROCm0 — shrinking them
+handed ROCm1 1.31 GiB more than it handed ROCm0:
+
+| `-ts` | ubatch | GPU 0 free | GPU 1 free | gap |
+|---|---:|---:|---:|---:|
+| 36,29 | 1536 | 4.71 GiB | 4.91 GiB | 0.20 |
+| 36,29 | 512 | 6.01 GiB | 7.32 GiB | 1.31 |
+| **35,30 — deployed** | **512** | **6.44 GiB** | **6.90 GiB** | **0.46** |
+
+35:30's 0.46 GiB gap is one DeltaNet layer's worth, which is the floor here: no
+split can be tuned finer than a layer, so the 0.20 GiB of the old configuration
+is not reachable at this batch. It clears the operator's 1.5 GiB-per-card floor
+by ~5 GiB, so no headroom is bought out of `CTX_SIZE` and the model's full
+262144-token window stays.
 
 A batch of 8192/2048 failed here under DSpark — its 2020 MiB pp buffer could not
 be allocated on ROCm1, which had 0.08 GiB free. That was a *contiguity* failure,
-not a total-bytes one, and it has **not** been re-measured with DFlash2's ~4.9
-GiB of headroom. (`tests/frank_medium_unit.bats` fits the deployed point and
-predicts it still would not fit, but that is an extrapolation of a coefficient
-fitted at ubatch 1536.)
+not a total-bytes one, and the sweep has since removed the reason to care: with
+the batch geometry measured, there is nothing to gain by making either knob
+larger, so the question is closed rather than pending.
 
 > **A fault to watch.** A 39:26 split, at 1x batch and one slot, died on its
 > eighth request: the amdgpu driver logged SDMA0 UTCL2 page faults and the
 > engine surfaced `ROCm error: an illegal memory access was encountered` ->
 > `ggml_abort` — a fault in the cross-card boundary copy, which is this layer
-> split's hot path. It has not reproduced (36:29 has since served the whole
-> verification battery and the e2e gate; 39:26 itself was only *loaded* at the
-> deployed batch, not exercised), and it is **not** an OOM: no amount of
-> headroom would prevent it.
+> split's hot path. It has not reproduced (36:29 served the whole verification
+> battery and the e2e gate, and 35:30 at ubatch 512 is the deployed shape now;
+> 39:26 itself was only *loaded* at the deployed batch, not exercised), and it
+> is **not** an OOM: no amount of headroom would prevent it.
 
 ## Verified serving behaviour (2026-09-16)
 
@@ -267,11 +280,11 @@ fitted at ubatch 1536.)
   `draft_dflash` symbol with `block_size=7` and a Markov head, so read the
   numbers, not the implementation name.
 - Both cards hold the model and they are **balanced**: at 262144 with the
-  deployed batch and split, `rocm-smi` reports **4.71 GiB free on GPU 0 and
-  4.91 GiB on GPU 1** of 31.86 GiB each — the same figures the balance search
-  predicted to 0.01 GiB. Under load (two concurrent requests, one per slot) they
-  sit at 4.43 / 4.61, a 0.18 GiB gap, and both are far above the operator's
-  1.5 GiB floor.
+  deployed batch and split, `rocm-smi` reports **6.44 GiB free on GPU 0 and
+  6.90 GiB on GPU 1** of 31.86 GiB each — reproducing the pre-deploy
+  measurement of the same shape to 0.01 GiB. Under load (two concurrent
+  requests, one per slot) they sit at **6.23 / 6.64**, and both are far above
+  the operator's 1.5 GiB floor.
 - Drafting is live on **both slots**, which is what a 2-slot deployment has to
   prove: `slot print_timing` reported `draft acceptance = 0.62857 (44 accepted /
   70 generated), mean len = 5.40` and `0.48214 (27 / 56)` on slot 1, and
@@ -444,7 +457,7 @@ produced wrong numbers on this fleet:
 
 - **It separates devices differently from `llama-server`.** `/` splits devices
   *within one configuration*, `,` splits *sweep values* — so this service's
-  `--tensor-split 36,29` is `-ts 36/29` to llama-bench, and the comma form
+  `--tensor-split 35,30` is `-ts 35/30` to llama-bench, and the comma form
   silently benches each card on its own instead. Likewise `--device
   ROCm0,ROCm1` → `-dev ROCm0/ROCm1`.
 - **There is no `-c`.** The context is a consequence of the test shape:
@@ -518,3 +531,6 @@ gets the server defaults above; a client that sends its own wins. Text only.
 - [[frank-small-qwen38-gsq-rco]] — the fleet's other llama.cpp endpoint (RTX
   3090, MTP, the image path)
 - [[Dankserver System Specs]] — hardware inventory
+- [[frank-medium-batch-ubatch]] — the batch/ubatch sweep that set the deployed
+  geometry and moved this split from 36:29 to 35:30: the ubatch optimum at 512,
+  why the logical batch is free, and the harness traps