frank-medium: 3x batch over 2 slots, and rebalance the split to pay for it

The operator's revised spec: batch x3 (6144/1536), parallel 2, a 1.5 GiB per-card
floor, and the context maximised inside it.

Measured at 262144 with the old 38:27 split, 3x batch was brutally asymmetric:
ROCm1 (output layers + the drafter's graphs) paid ~3.3 GiB where ROCm0 paid
~1.7, leaving the draft-carrying card at 0.08 GiB free against ROCm0's 3.78.
One -ts step is worth ~1.5 GiB at this batch, so the balance is a measurement:
41:24 overshot (1.47 / 2.38), 40:25 landed at 1.92 / 1.96 GiB free.

That balance is also what maximises the context -- an unbalanced split would have
to buy its headroom out of CTX_SIZE, and CTX_SIZE is already at the model's
trained window (262144), now split over two slots of 131072. Verified under two
concurrent 1832-token prompts: 200/200, 1.87 / 1.86 GiB free, n_slots = 2,
n_ctx_slot = 131072, tool calls intact, and DSpark drafting on BOTH slots
(acceptance 0.38/0.22 and 0.52/0.43).

8192/2048 does not fit at this context at all: its 2020 MiB pp buffer fails to
allocate on ROCm1, and 4096/1024 fits but leaves 1.11 GiB -- both recorded in
the env's sizing table.

The unit seam now models both cards (share + draft + ubatch-scaled buffers,
calibrated to the rocm-smi figures to within 0.002%), asserts the 1.5 GiB floor
on each, and asserts the two cards stay within 0.5 GiB of each other. Both
assertions were confirmed to FAIL on a deliberately bad config (ubatch 8192, and
a 1:1 split) rather than pass by construction.

AGENTS.md

@@ -24,7 +24,7 @@ merge absorbed the former `vllmScripts` repo, history preserved).
 
 | Target | Service | Runtime | Model | Port |
 |--------|---------|---------|-------|------|
-| Dankserver | `frank-medium` | mainline llama.cpp master fb27a525 (root systemd unit, gfx1201 HIP build) | ajgazin Swift-Qwen3.8-27B-Uncensored-Dynamic-MTP UD-Q8_K_XL + magnitudedev Qwen3.8-27B-DSpark Q8_0 drafter, 2x Radeon AI PRO R9700 in ONE layer-split process (38:27), 262144 ctx / 1 slot, text only | 7770 |
+| Dankserver | `frank-medium` | mainline llama.cpp master fb27a525 (root systemd unit, gfx1201 HIP build) | ajgazin Swift-Qwen3.8-27B-Uncensored-Dynamic-MTP UD-Q8_K_XL + magnitudedev Qwen3.8-27B-DSpark Q8_0 drafter, 2x Radeon AI PRO R9700 in ONE layer-split process (40:25), 262144 ctx over 2 slots, batch 6144x1536, text only | 7770 |
 | Dankclaw | `frank-large` | halogen-flash-server 0.5.8 (rootless Quadlet) | peonist-ai Qwen3.8-Flash-Next w4b `.hgn` on the gfx1151 iGPU (Strix Halo LPDDR), 200192 ctx per conversation over one 400384-position KV pool / 2 slots, text only | 7770 |
 | Dankclaw | `frank-small` | mainline llama.cpp master 37b53fd (root systemd unit) | ISTA-DASLab Qwen3.8-27B-GSQ-RCO IQ3_S (`-mtp` + BF16 mmproj) on the RTX 3090, 131072 ctx / 1 slot, MTP speculative decoding, the fleet's vision endpoint | 7771 |
 
@@ -305,7 +305,9 @@ systemd unit `scripts/frank-medium.service`) serving
 `ajgazin/Swift-Qwen3.8-27B-Uncensored-Dynamic-MTP-GGUF` at **UD-Q8_K_XL**
 (29.29 GiB) with the **magnitudedev DSpark** `Q8_0` drafter chained to the
 draftless **ngram-mod** matcher, in **one process across both R9700s**,
-`--split-mode layer` at a **38:27 tensor split**, 262144 ctx / 1 slot, text only.
+`--split-mode layer` at a **40:25 tensor split** (the balance point for the
+deployed batch: the drafter rides ROCm1, so it takes fewer target layers),
+262144 ctx over **2 slots** of 131072, batch 6144x1536, text only.
 
 **Layer split is why both cards now serve ONE model.** Tensor parallelism is
 impossible (see the PCIe lesson below), and so is vLLM's pipeline parallelism —
@@ -509,6 +511,15 @@ linked runbooks.
   drafter's GGUF header before sizing any spec-decode deployment, and prefer a
   skewed `-ts` over a context cut when the full window matters. See
   [[frank-medium-llamacpp-dflash2]].
+- **The compute buffers of a bigger `--ubatch-size` land ~4x heavier on the card
+  that holds the output layers and the drafter.** On frank-medium (2026-09-16)
+  ubatch 512 -> 1536 cost ROCm1 ~3.3 GiB against ROCm0's ~1.7, which left the
+  draft-carrying card at 0.08 GiB free under a split that was balanced at the
+  smaller batch. A split balanced at one batch is unbalanced at another: ~1.5
+  GiB of load moves per `-ts` step at this size, so re-measure the balance after
+  changing the batch (and remember 8192/2048 does not fit at 262144 at all --
+  its 2020 MiB pp buffer fails to allocate). See
+  [[frank-medium-llamacpp-dflash2]].
 - **ngram-mod prints no startup banner.** The load log shows the drafter's
   `adding speculative implementation 'draft-dflash'` and nothing at all for the
   matcher, so a chain can look unengaged while it is working. Identify it