#3505 [Benchmark] One R9700 with IQ2_XS: one client, two clients, and four levers that did not help

Description

## Problem

Two clients on one R9700 do not share the GPU once their contexts are deep, and the numbers we measured first were wrong in three separate ways before we found out why.

On a 32 GB R9700 (gfx1201) with the original Flash-Next IQ2_XS pack and engine 0.1.46.1 (`9ae93f7b`):

- one client decodes at 74-78 tok/s at 32K, and at **75.4 +- 8.8 tok/s at a 178K context**;
- two clients at 32K do share the GPU (batch windows carry 3.05-3.29 rows) and get 22-46 tok/s each;
- two clients at 178K **do not** share it: windows carry 1.50-1.82 rows, the MTP drafter still accepts 63-82% of its proposals there, and each client ends up at **8-10 tok/s end to end** - because the other client's fresh 178K read (about 80 s of GPU-serial prompt reading at ~2,230 tok/s) sits in front of it.

## Result

The report adds the measurement and the mechanism, and it says what did not help. Four Strata-specific levers were measured against the deep two-client case and none of them moved it: `--lookup-chain 4` (8.86 tok/s per request), `--adapt-async 1` (9.45), `--mtp-window 4096` (10.24), `--kv-resident 131072` (8.76) against 8.3-10.2 for the base. The MTP drafter is not the problem: it still accepts most proposals at 178K, the slots simply stop sharing windows.

## Approach

`llama-benchy --strata` (the maintained Strata fork of eugr/llama-benchy) against a running `serve/server.py`: fresh prompts, `reasoning_effort=none`, `--no-cache`, with the engine's own per-request log lines and `strata batch:` window summaries as the mechanism evidence. The report includes the raw per-run numbers in `results.json`.

Two findings in the report affect how other people should measure, and both are reproducible from the log:

1. **This build is not bit-reproducible run to run.** Two identical greedy requests, same prompt and settings, produced different text (different SHA-256 of the reply), as did two requests with no override. The engine's own log says the GPU computes cached experts and rounds differently from the CPU, and the adaptive tier moves experts between the paths. The identity gate in the docs does not reproduce here, so only speed claims are defensible on this build.
2. **The server shares engine batch slots across concurrent same-model requests.** A script that sends two clients the same template and word pool is not measuring two fresh prompts: the second client reads one token and reports 6,876 tok/s of prompt processing. The prompt has to differ per request and the engine's `N reused` log line is the check.

## Validation

- Engine 0.1.46.1, HIP, gfx1201, built from source (`src 85733a7e5e473b25`), llama.cpp `3cf03257f219afbe7334045ff7c6a06ac68c627d`; ROCm 7.10.0a20251120 wheels, hipBLASLt 100200, WMMA on, own 43-row table.
- Every number in the report comes from the tool's own output or the engine's log lines of the same run; per-run values are in `results.json`.
- The four depth levers were each measured once per configuration, not interleaved with the base, which is why the report calls them "no effect" rather than reporting deltas. The one interleaved A/B we ran (base against `--mtp-window 4096`, two rounds each) is reported with both arms' numbers, and it shows no effect: 74.98 against 74.63 tok/s solo.
- An early reading of `--mtp-window 4096` looked like +13% prompt throughput; with the arms interleaved it was drift (base 2,303.5 and 2,368.1 tok/s against 2,317.1 and 2,398.6). The report says so.

## Limits

- One card, one quantization (IQ2_XS), one engine build, one host with shared CPUs.
- Not the `strata bench run` standard protocol, and no recall (needle) checks. The community guide asks for a same-day run of the build under test next to the candidate; we did not run upstream's build side by side, so these numbers are not directly comparable with any other report.
- The two-client figures are two concurrent requests of the same model. A mixed workload (one deep agent session plus one short interactive client) was not measured.
- `--spec-min-p 0.35` was measured with the engine's per-request override and with thinking on, so only its paired comparison is comparable; the report says so.

## Related

- The earlier R9700 report ([2026-10-08-community-r9700-linux](../2026-10-08-community-r9700-linux/README.md)) used IQ3_S on an experimental 0.1.40.3 build. This one uses the current engine, IQ2_XS, and two clients.