#3147 bench: 4x Tesla V100-SXM2 reports for 0.1.45 (IQ3_S, 262144): prompt reading unchanged, the 6-7% ru gap is measurement order, full test suite

本文

## What this is

Three community benchmark reports from one update cycle on a machine that is not in the existing set: **4x NVIDIA Tesla V100-SXM2-16GB (sm_70) in a Minisforum MS-01**, `qwen3.8-flash-next-iq3_s`, context 262144, comparing **0.1.45 with 0.1.44.1** with whole trees swapped in one session.

- `bench/results/2026-10-19-community-4x-tesla-v100-iq3-s-262k-code/` — code-style prompts, 4K…260K.
- `bench/results/2026-10-19-community-4x-tesla-v100-iq3-s-262k-ru/` — Russian-style prompts, same lengths, plus the reversed-order control.
- `bench/results/2026-10-19-community-4x-tesla-v100-test-suite/` — the Python suite (118 modules, 1703 cases) and what each failure actually is.

Each folder carries `env.json`, `config.json`, `runs.json`, the same-binary control run, the 0.1.44.1 baseline, needle recall files, 2-second VRAM/RAM samples and the driver scripts.

Related: the same 0.1.45 cycle on RTX 4090 is in #3109 (branch `bench/2026-10-18-rtx4090-0145`); the previous cycle on this V100 box, 0.1.44.1 vs 0.1.43, is #2525; the NVLink/interconnect dossier for the same machine is #2905.

## The machine

A **Minisforum MS-01** mini-workstation (DMI: `Micro Computer (HK) Tech Limited`, product `Venus Series`, board `AHWSA`, BIOS `AHWSA.1.22` of 2024-03-12, chassis type 3, UEFI) — i9-13900H (20 logical CPUs, one NUMA node), 96 GB DDR5 (`MemTotal` 91.7 GiB usable), one NVMe drive SOLIDIGM `SSDPFKKW020X7` (2.05 TB, ext4 root, holds the model files), 2x Intel X710 10GbE SFP+ plus I226-V/I226-LM, Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic, driver 580.178.04. No root/sudo on this box.

The GPUs are not PCIe cards: four **Tesla V100-SXM2-16GB** SXM2 modules (`GV100GL [10de:1db1]`, compute 7.0, 16384 MiB, 300.00 W limit, max clocks 1530/877 MHz, persistence enabled; serials `1323920036046`, `0324218160473`, `0323517036572`, `1422119022723`) on a third-party 4-GPU SXM2 carrier board, behind a **PLX/Broadcom PEX 8748** Gen3 switch at `0000:01:00.0`, with the cards at `03:00.0`..`06:00.0`. The host side of that switch is the CPU root port `0000:00:01.0`, and it trains as **x8 at 8.0 GT/s** (`current_link_width = max_link_width = 8`); every card also links at x8 / 8.0 GT/s. Four x8 downlinks share one x8 uplink — 4:1 oversubscription, ~7.9 GB/s per direction; measured earlier on this machine (#2905): 6.29 GB/s host→device for one card alone, 1.56 GB/s per card when all four stream. NVLink is live between every pair (`nvidia-smi topo -m` gives `NV2`; 6 links per card at 25.781 GB/s). The whole probe is reproducible with `scripts/host-probe-185.sh`, and its raw output is committed as `host-provenance.txt`.

This shape of the machine matters for the numbers: a layer-split model with most experts resident is what this box is good at, and its absolute tok/s are not comparable with a desktop card on a full x16. RAM was never a limit — the cycle peaked at 11.0 GiB of 91.7 GiB; VRAM is the limit (`CUDA3` reaches 16144 of 16384 MiB).

## Results

**Prompt reading on Volta is unchanged.** 4K…260K, code-style: −0.10…−0.39% (one case +0.14%), while the same 0.1.45 binary re-measured moved −0.17…+0.24% — every delta sits inside the control band. The two longest cases were repeated 3+3 times per version: 237483 tokens in 96.9–97.5 s and 260331 in 107.0–107.5 s in both versions. Recall: 6/6 needles at 32K and 128K in both versions, 3/3 at 249262 tokens in both.

**The 6–7% "regression" in the Russian-style run is an artifact of measurement order.** In the first ordering 0.1.44.1 (measured second) was 6.5–7.1% faster at ≥127K tokens. Both orders were then measured, which gives a 2×2 (version × seat in the session):

| actual prompt tokens | 0.1.45, first seat | 0.1.45, second seat | 0.1.44.1, first seat | 0.1.44.1, second seat |
|---:|---:|---:|---:|---:|
| 4028 | 882.9 | 883.9 | 876.2 | 893.2 |
| 31828 | 1907.3 | 1915.4 | 1915.2 | 1986.2 |
| 64628 | 2249.2 | 2261.2 | 2255.8 | 2369.2 |
| 127228 | 2393.3 | 2390.6 | 2387.1 | 2573.1 |
| 188828 | 2433.2 | 2432.8 | 2430.1 | 2619.1 |
| 203528 | 2450.0 | 2444.6 | 2444.1 | 2630.1 |

0.1.45 is seat-independent (0.02–0.5% spread); 0.1.44.1 gains 1.9–7.8% purely by running after another engine of the same model and config. Same-seat deltas: |Δ| ≤ 0.8%. Suggested reading for anyone benchmarking long contexts on this class of machine: absolute numbers drift by up to 8% between sessions of the *same* build, so only order-reversed or interleaved A/B is trustworthy.

**Test suite: 1703 tests, 13 failures + 1 error, none from 0.1.45.** `serve.*` (836 tests) passed completely with the live production server. All failures come from `tools.test_strata_mcp` (4+1), `tools.test_setup_golden` (8) and `tools.test_setup_engine_hash` (2); the identical 14 reproduce in 0.1.44.1 with its own engine and its own venv, and the 5 `test_strata_mcp` ones disappear when this machine's production server is stopped (port 8080 is a permanent production service here).

## Two concrete things for the project

1. **`tools.test_setup_golden` cannot pass on Linux** — it compares `vision.exe` against `<T>/engine/strata-vision.exe`, while `setup` writes `strata-vision`. `normalize()` substitutes only `setup.EXE` via the `<EXE>` placeholder, not `setup.VEXE`. All 8 failing subtests in both versions start from this; in 0.1.44.1 the maxDiff output shows it as the only differing value. Fix: normalize `VEXE` the same way, or record `<VEXE>` in the fixture.
2. **0.1.45 introduces an unmocked `os.cpu_count()` dependency in setup** — 3 of the 8 golden subtests (profiles 47GB-2x16GB and 96GB-1x16GB) now get `vision.threads: 10` on a 20-logical-CPU host where the fixture expects 6 (`setup.py:5906`, `max(1, (os.cpu_count() or 8) // 2)`; 0.1.44.1 does not take this path under the same mocks). The golden profiles mock RAM and GPU cards but not the CPU count. Fix: mock `os.cpu_count()` per profile, or normalize the value.

## Notes on comparability

- Both engines are built from source on this machine for `sm_70` (`STRATA_EXPERIMENTAL_SM60=ON`) with a private CUDA 12.8 (nvcc 12.8.93) and private gcc-14 — the Linux release archive carries no engine binary, so a local build is the only path, and both versions were built identically. `BUILD.json` records this.
- Auto prompt chunk is 8192 tokens with a 96-slot ring in **both** versions, and the two run-config files (one per tree) are byte-identical, so the configuration is the same. `engine-start-lines-comparison.txt` in the code report collects the start-up self-description per session and per version: `prompt chunk auto: 8192 tokens, a 96-slot ring` and `adaptive overlap: off: not on a layer split` in every session of both versions. What does differ is the reported resident share (97% in every 0.1.45 session here, 96-99% across 0.1.44.1 sessions): it follows the memory free at the moment of start, so it is a start condition, not a version difference. That file also states a caveat: the two 0.1.44.1 sessions of this cycle left no start-up block in the shared log, so the 0.1.44.1 column there includes its sessions of 2026-10-14..17.
- `STRATA_DEQUANT_WIDE` is not active on sm_70 (`per_dev[]` matches sm_61/sm_86 only), so the RTX 4090 finding about it does not transfer here. The other new defaults were checked against this config: `STRATA_ADAPT_EVICT_SYNC` (no adaptive copy tier here), `STRATA_DF_QB_Q4` (q4_0 KV only), `STRATA_PIPED_*` (opt-in), `STRATA_SIMT2_TILE` (needs `STRATA_SELECT_SIMT`), `STRATA_RDNA2_SGEMM` (AMD).
- No DCGM on this machine, so there is no colouring or kernel-level profiling here. Generation columns are reported but not used for conclusions (answer lengths differ between versions). No other agent's traffic touched this server during the measurements — the agent running the cycle is served by a different box.
- The scripts are published with English comments and English log strings; every command in them is what was actually run. Text that is measurement data stays as it was sent to the model: the Russian workload paragraph, the `[метка N]` marker inside every prompt, and the Russian verification query in the swap scripts (each with an English gloss in a comment). `reverse2-run.log` keeps the Russian stage markers the machine wrote at the time.