#2364 bench: community report, 4x RTX 3090 layer split, stock 0.1.44 against 0.1.43 with a patch series, 1 to 16 users

Beschreibung

This PR adds results only: the report folder
[`bench/results/2026-10-14-community-4x-rtx-3090-0144/`](https://github.com/havok2-htwo/Strata/blob/bench/2026-10-14-4x-rtx-3090/bench/results/2026-10-14-community-4x-rtx-3090-0144/README.md)
and one bullet in `docs/COMMUNITY_BENCHMARKS.md`. It changes no code.

**Hardware:** 4x RTX 3090 24 GB at a 380 W limit each. PCIe: two cards at Gen3 x16, two at Gen4 x8. The rest of
the machine is a Threadripper 3990X (no AVX-512) with 251 GiB RAM and an NVMe RAID0, running Ubuntu 24.04,
driver 580.178.04 and CUDA 13.0.

**Model:** Unsloth UD-IQ4_XS (shards match the pins in `setup.py`), with the native-experts pack and the MTP draft
made by setup. The context is 262,144 tokens with `--kv int8 --kv-resident 32768`, the layer split is `12,25,37`,
and all experts are resident in VRAM. Text only.

**Configs (same day, same engine arguments, each build with its own `serve/server.py`):**
- **stock:** v0.1.44 `ed4773eb`, built from source with setup.py's CUDA flags. It runs 8 slots in 4 groups of 2.
  8 is the most 0.1.44 runs on this split with its default pipelined groups (without `--batch-mtp`); with
  `--batch-mtp` and serial windows (`--batch-groups 1` or `STRATA_BATCH_MTP_SERIAL=1`) it accepts more, which we
  did not test. v0.1.44.1 (`296b59d2`) came out a few hours before the run and was not measured.
- **modified:** 0.1.43 plus our unmerged patch series, built with `-DSTRATA_MMQ_TAB=ON`. It runs 16 slots in 4
  groups of 4, with the opt-in switches listed in the README. This is the build we run in production. Source,
  pinned: [havok2-htwo/Strata at `08830ddf`](https://github.com/havok2-htwo/Strata/tree/08830ddf94213866c29dcd8ae4b70f0674670bed);
  the same commits as patches 0001-0052 in
  [havok2-htwo/StrataQ38FN at `4ece0ca`](https://github.com/havok2-htwo/StrataQ38FN/tree/4ece0ca829c17853b84742c31948c12b8c66c478/linux/patches/v0.1.43)
  plus the last commit `08830ddf` (server only).

**Aggregate output tok/s (stock / modified), 1 run per arm:**

| Workload | stock 0.1.44 | modified 0.1.43 |
| --- | ---: | ---: |
| 1 user, ~147-token prompt, 512 out | 111.7 | 116.2 |
| 8 users, same | 314.4 | 399.4 |
| 16 users, same | 292.9 (TTFT p50 8.69 s) | 516.7 (0.89 s) |
| 16 users, ~1.2K-token prompt | 238.1 (TTFT p50 6.96 s) | 406.5 (1.91 s) |
| 16 agents x 3 turns, temperature 0.7 | 92.0 (follow-up TTFT p50 9.91 s) | 151.9 (1.52 s) |

The greedy replies were **byte-identical between the two builds for all 82 sweep requests**. The README also
gives the engine's own timings:
- prompt read rates
- the admission copy into a slot, as the median per phase: 153-197 ms on stock, 1.0-13.2 ms on the modified build
- solo MTP acceptance in the 1-user level, identical in both builds (586 of 948, 61.8 %)
- a note on #2038: every solo request drafted in both builds, and a request admitted into a batch slot logs one
  `strata serve: prompt` line with 1 generated token and 0 of 0 drafts

**Limitations:**
- The 16-user rows mix 16 against 8 slots with everything else that differs. The 8-user row is the closer
  comparison, and there both builds carry 2 rows per group-step. Even there the gap mixes the patches and switches,
  the `-DSTRATA_MMQ_TAB=ON` build option and the 0.1.43 against 0.1.44 base.
- The modified build used about 26 GiB more system RAM after load (96.2 against 70.4 GiB, whole machine).
- No row isolates a single patch.
- There is one run per arm, in one order (modified first).
- Images, prompts above 20K tokens, more than 16 users, `--batch-mtp` (also stock above 8 slots in serial
  windows) and v0.1.44.1 are untested.

Two parts of the series (more than 8 slots on a layer split, and the device-to-device slot copy) would come as
separate PRs, each with its own A/B. This report does not measure either alone.

🤖 Generated with [Claude Code](https://claude.com/claude-code)