F1 - llama-cli is chat-first; harness runs need llama-server

At commit 067de937, --no-conversation is unsupported and an EOF'd stdin loops forever on the chat prompt. Scripted/harness runs use llama-server (or llama-completion) + HTTP, always timeout-wrapped. Evidence: step 4a entry. Status: ACTIVE (bound as HARNESS-RULES 1-3).

F2 - download completion = byte/hash match vs origin authority, never exit 0

Wi-Fi drops and wrapper-shell bashisms both produced clean-looking partial or never-ran fetches. Pin sizes/oids from the origin API first; verify on arrival. Evidence: step 4c entries. Status: ACTIVE (HARNESS-RULES Rule 4; promoted fleet-wide as download-integrity.md).

F3 - effective-bandwidth quant clusters (single-cluster reading)

Q4_K artefacts land 84-100% of the naive bandwidth ceiling; MXFP4 lands ~64-69%. Declared confound: both MXFP4 points were gpt-oss family. Evidence: step 5 gate (53.44 = 64%), step 7 Row A (77.76 = 68.8%). Status: SUPERSEDED by F11 (2026-07-03) - the clusters are real but the mechanism is a tg-only dequant tax; prefill pays no MXFP4 penalty.

F4 - MoE-first on this silicon is empirical; dense Q4_K runs at ~naive ceiling

Qwen3-30B-A3B generates 3.8x faster than dense Qwen3-14B (92.83 vs 24.39 tg) while being the stronger model; the dense 14B sits at ~100% of its 220/9.0GB naive ceiling. Dense-at-interactive-speed is physics-limited. Evidence: step 6 workhorse + 14B entries. Status: ACTIVE.

F5 - depth slopes follow active-set/KV fraction; smooth, no cliffs

tg at d8192 vs d0: gpt-oss -9.1/-9.5%, GLM-4.5-Air -13.2%, Qwen3-30B-A3B -28%, Qwen3.6-35B hybrid -6.8% (shallowest - linear attention). The smaller the active set, the larger the KV-read fraction per token. Evidence: step 5/6/7 entries. Status: ACTIVE (Step 8 Block 1 extends every model from 2 depth points to 5-6).

F6 - memory-edge behaviour at ~68GiB weights

Weights within ~4GiB of the 71.65GiB device-local heap: combined -d invocations DeviceLost-abort, and pp-at-depth CV blows out (21% vs the matrix-typical 1-2%). Operational rule: models >~60GiB use split invocations; treat memory-pressured pp as low-confidence. Evidence: step 6 GLM-4.5-Air entry. Status: ACTIVE.

F7 - DeltaNet hybrids carry a per-token cost the weight-bytes model misses

Qwen3.6-35B-A3B on Q4_K: tg ~54-57% of naive (below even the MXFP4 cluster) beside HEALTHY pp (996 t/s) and the flattest depth slope in the matrix. Recurrent-state read/write traffic and/or immature Vulkan recurrent kernels are the candidate drags (not separable via llama-bench). Evidence: step 7 Row B entry. Status: ACTIVE.

F8 - GLM-4.7-Flash runs the deepseek2 (MLA) graph; MLA-MoE lands ~66% of naive

llama-bench identifies the artefact as deepseek2 30B.A3B; on Q4_K it achieves ~66% of naive - a distinct band below pure-MoE's ~84%. Evidence: step 7 Row C entry. Status: ACTIVE (generality test = F12).

F9 - "A3B" is a label, not a price

Three A3B-class MoEs, same quant family, same hardware, span 1.57x on tg: 92.8 (pure MoE) / 71.9 (MLA) / 59.3 (DeltaNet hybrid). Active-parameter count alone cannot price a model; architecture dominates. Evidence: step 7 Row C entry. Status: ACTIVE.

F10 - corridor rule form (pre-screen pricing model)

t/s ~= (220 GB/s / active bytes per token) x arch factor x quant factor. Ladder as re-priced at Step 8 end-state (n per constant): dense ~1.00 (n=3, family-clean; small-dense onset 0.89 at 4B, n=1); pure MoE ~0.84-0.86 (n=2); MLA-MoE per-model 0.66-0.80, NOT a single class (n=2, see F12); DeltaNet hybrid ~0.55 (n=1); quant factor Q4_K baseline 1.0, post-hoc MXFP4 ~0.81 tg-only (n=1 isolated). Evidence: step 7 addendum + step 8 end-state entry. Status: ACTIVE, with the standing caveat (Alastair, Step 8 approval): constants rest on n=1-3 points on one machine/stack and are expected to move with kernel releases - the METHOD (pre-registration, quant-isolation pairs, repeatability triplets, stack-fingerprinted tables, re-run triggers) is the durable asset, not the numbers.

F11 - MXFP4 is a tg-only dequant tax, ~0.81 multiplier (same-model isolation)

GLM-4.7-Flash Q4_K_M vs MXFP4_MOE pair: the MXFP4 artefact is 7.3% smaller yet generates 12.5% slower (81% of Q4_K's per-byte efficiency); pp512 is +4.5% ABOVE the Q4_K leg. Depth slopes are quant-invariant, so MLA-at-depth is an arch property. Supersedes F3's single-cluster reading. Native-MXFP4 (gpt-oss) evidence is consistent but family-confounded per the pre-declared caveat. Evidence: step 7 quant-isolation pre-registration + addendum entries. Status: ACTIVE.

F12 - MLA-MoE ~0.66 is NOT a constant class; it was Flash-specific

RESOLVED 2026-07-04 (Step 8 Block 2d, amended fork): DeepSeek-V2-Lite - the archetype of the same deepseek2 graph GLM-4.7-Flash runs - lands tg128 110.80 = ~80% of its ~139 t/s naive ceiling: the >=99 arm, decisive, in pure-MoE territory (0.84), nowhere near 0.66. MLA alone does not price a model; the corridor rule's MLA-MoE factor is downgraded to a per-model range (0.66-0.80, n=2) pending a mechanism split. Method note: under the brief's original mis-derived thresholds this measurement would have been INCONCLUSIVE - the pin-time re-derivation (declared amendment) made it decisive. Secondary replication: the MLA steep-depth signature holds and amplifies (tg -59.8% at 8K, steepest in the matrix; per-token depth cost 2-3x the pure-MoE rows). Evidence: step 8 Block 2d entry. Status: RESOLVED.

F13 - every instant badge dies with depth; the death depth is a measured number

Six-point depth curves (0-32K): every model that clears ~70 t/s fresh loses it under context. Interpolated crossings: GLM-4.7-Flash Q4 ~230 TOKENS (a hairline badge is a fragile badge), Qwen3-4B ~2.2K, DeepSeek-V2-Lite ~3.2K, gpt-oss-20b ~5.5-9K (measurement-sensitive: its curve is nearly flat at the line, so +/-2% run noise moves the crossing a whole bracket), Qwen3-30B ~6.9K. Consulting form: never quote an instant claim without its expiry depth. Evidence: step 8 Block 1 entries + end-state badge table. Status: ACTIVE.

F14 - architecture rank is depth-dependent: the workhorse crossover at ~16K

Qwen3-30B (pure MoE) vs Qwen3.6-35B (DeltaNet hybrid): 92 vs 59 at d0, tie at ~16K (53.2 vs 52.5), hybrid ahead 25% at 32K (47.9 vs 38.3) - and the hybrid keeps 60% of its prefill at 32K where the pure MoE keeps 16%. "Which model is faster" has no answer without a working depth; model selection needs the workload's context profile. Evidence: step 8 Block 1 (Qwen3-30B + Qwen3.6-35B curves). Status: ACTIVE.

F15 - single-run noise is ~±1.5%; UMA bus contention arrives as jitter, not slowdown

Repeatability triplet (identical invocations, window start/middle/ end): 90.63/93.41/92.30, CV 1.52% - the true error bar on any single-run number, ~3x within-run CV, non-monotonic (not thermal: every leg starts 46-47degC). Contamination experiment (3c): a ~17MB/s download shifts tg by -0.6% (null); a sustained ~GB/s disk-read+hash leaves the mean intact (+1.4%) but inflates within-run sigma ~4x. Client form: on unified memory you can ingest while serving - throughput holds, latency jitter rises. Unresolved tail: one cross-evening pair (gpt-oss-20b, -3.3%/-4.4%) exceeds the triplet band - model-specific drift, watch. Evidence: step 8 3b/3c entries. Status: ACTIVE.

F16 - q8_0 KV cache is a working depth lever; flash attention is free

Same-model isolation (Qwen3-30B, six depths): -fa on alone = baseline within noise at every depth (auto already optimal). Adding q8_0 K+V: -3.8% at d0, break-even ~4-6K, +8.5% at 16K, +14.7% at 32K, KV footprint halved. It does NOT rescue instant badges (the 70-line crossing moves ~6.9K -> ~7.1K) - it buys deep-context throughput and capacity. Deployment rule of thumb: fresh-chat workloads skip it, long-context workloads want it. Evidence: step 8 Block 3d entry. Status: ACTIVE.

F17 - concurrency scaling is architecture-dependent; the single-user ranking widens under fleet load

llama-server, 4K ctx/slot, 128-token requests: Qwen3-30B (pure MoE Q4_K) scales 72.9 -> 193.5 t/s aggregate from 1 to 16 slots (2.66x, no sharp knee, still rising); gpt-oss-20b (native MXFP4, SWA) plateaus after ~4 slots (59.9 -> 109.0, 1.82x). Their 1.2x single-user gap becomes 1.8x aggregate at 16 slots. Instant-tier frontier (per-stream

= 70) is 1 slot on this hardware; TTFT p50 grows ~6x from 1 to 16 slots. q8 KV is effectively free under concurrency (-0.6 to -2.3% multi-slot) while halving the KV budget that caps slots. Candidate mechanism for the plateau (MXFP4 batched dequant vs attention path) untested - a GLM-4.7-Flash quant-pair concurrency run would isolate it. Client form: "what the fleet gets at burst" depends on architecture as much as the single-user number - measure both. Evidence: step 9 results entry; raw JSON bench-step9-*. Status: ACTIVE. Mechanism refined by F18: the gpt-oss plateau is architecture, not quant (E2 quant-pair, 2026-07-04).

F18 - MLA anti-scales under concurrency; concurrency behaviour now spans 3.8x by architecture

Same-model GLM-4.7-Flash pair (Q4_K_M vs MXFP4_MOE), slots 1/4/16: both quants LOSE aggregate throughput as slots rise (16-slot/1-slot ratios 0.70 and 0.76 - parallel, so quant is exonerated and the gpt-oss F17 plateau is attributed to architecture). The architecture-concurrency ladder on this stack: pure MoE 2.66x, gpt-oss/SWA 1.82x, MLA-MoE ~0.7x (ANTI-scaling, ~20s TTFT at 16 slots). Candidate mechanism: MLA latent decompression is per-token compute that batching multiplies rather than amortizes (consistent with F8's prefill collapse). Deployment rule: MLA models are single-user machines here - never behind a multi-slot server. The single-user throughput ranking and the fleet ranking are DIFFERENT orderings; size neither from the other. Evidence: results/experiments.md E2; raw bench-e2-*.json. Status: ACTIVE. Attribution strengthened by E4 (Scout/chunked attention scales 2.72x@8 - best measured - so anti-scaling is not a general MoE trait).

F19 - the fleet's 12K-context capability floor is high; small-model tax is judgment, not context

Two independently designed eval suites (needle retrieval + summariz- ation, then multi-hop arithmetic/cross-reference over real technical logs) both FAILED to separate the resident instruct models at 12K context - every model from 2.3GB Qwen3-4B up scored >=83%, most 100%. The only real failures across both suites: Qwen3-4B misclassifying spam as urgent (judgment), and Qwen3-Coder-30B making the sole arithmetic slip (ironic; every base model computed correctly). Deployment guidance: choose models on speed, concurrency behaviour (F17/F18), and judgment-critical tasks - not on long-context anxiety below 12K. Separation likely requires >32K, adversarial documents, or long structured generation (suite v3 candidates). Evidence: results/eval-pilot.md + results/experiments.md E7. Status: ACTIVE. Extended by E10: under enumeration pressure the 4B MISATTRIBUTES real values to wrong models (worse than omission) - small models need source-checking on any generated table.

F20 - eval verdicts depend on serving config: the reasoning-channel budget tax

gpt-oss-20b failed E9/E10 tasks it can plainly do (6/6 on the harder E8) because its harmony "Thinking" channel leaks into content under llama-server --jinja and consumes max_tokens before the answer - 1333 chars of correct systematic scanning, then truncation. Verdicts flip on max_tokens, not capability. Deployment rules: (1) reasoning models need 2-4x the token budget of instruct models for equivalent tasks, or template-level channel separation; (2) any eval report must state max_tokens and template handling or its scores are not comparable - the WER-normalization lesson (E11), applied to LLM grading. Related: F8/F13's context caveats - eval design keeps rediscovering that the RULER is half the measurement. Evidence: results/experiments.md E9/E10; raw JSONs. Status: ACTIVE.

F21 - speculative decoding spans 0.53x-3.73x by workload; silently inert without --spec-type

Same model (Qwen3-32B), same 0.6B draft, same flags: 3.73x on repetitive text (16/16 acceptance), +17% on explanatory prose, 0.53x - a HALVING - on analytical/creative prompts, where the target pays to verify rejected drafts. Deployment rules: (1) spec decode defaults OFF; enable per-workload after measuring on the production prompt mix; candidates are boilerplate/templated/structured output; (2) at 067de937 -md alone loads-but-never-uses the draft - --spec-type draft-simple is required, and the only tell is one INFO line; (3) fast MoE targets gain little even on friendly text (+9%): spec decode is a slow-dense-model tool. Any published spec-decode speedup that does not state its workload is not comparable (the F20/E11 ruler lesson, third appearance). Evidence: results/experiments.md E13; raw bench-e13-*. Status: ACTIVE.

F22 - Vulkan and ROCm split by workload phase (generation vs prefill)

Same model / machine / session (Qwen3-30B-A3B, E18, 2026-07-05, ROCm 7.2.4 gfx1151 native): Vulkan wins generation (tg) at every depth (+29.5% at d0, narrowing to +7.8% at 32K); ROCm wins prefill (pp) at every depth (+6.6% at d0, WIDENING to +79% at 32K - ROCm's 32K pp 323.68 vs Vulkan 180.77 = 1.79x). Mechanism: prefill is compute-bound (ROCm's mature rocBLAS/hipBLAS GEMM kernels win, advantage compounds with the longer-context attention at depth); generation is memory-bandwidth-bound (Vulkan's leaner per-token path wins; HIP runtime has more per-token overhead). Confirms the community "ROCm better at long context" claim WITH PRECISION - it is prefill, not generation. Deployment rule: pick the backend by which phase dominates the workload - long-prompt/short-output (document QA, RAG ingest, summarization, extraction) -> ROCm; short-prompt/long-output (chat, drafting) -> Vulkan. Both backends handled 32K with no OOM (ROCm sees the full 108GB GTT as VRAM). Practical: the E15 84K-doc ingest (~17 min on Vulkan) would shorten materially on ROCm (extrapolation beyond 32K flagged). This is the first cross-backend finding; all prior constants are Vulkan-only (F10 status note). Evidence: results/experiments.md E18; raw bench-e18-{vulkan,rocm}.md. Status: ACTIVE - but ARCHITECTURE-SPECIFIC; the ROCm-wins-prefill half holds only for pure MoE and INVERTS for MLA. See F23.

F23 - the Vulkan/ROCm split is architecture-dependent and depth-explosive

Extends/qualifies F22 with two additions (E18a deep pure-MoE; E18b MLA): 1. Pure MoE (Qwen3-30B): ROCm's prefill advantage EXPLODES with depth - 1.79x (32K) -> 3.55x (64K) -> 8.08x (96K). Vulkan prefill COLLAPSES past 32K (pp 180.77 -> 53.39 -> 16.57; at 96K pp 16.57 falls below its own tg 18.40), while ROCm holds (323.68 -> 189.53 -> 133.86). Practical: an 84K-doc ingest drops from ~17 min (Vulkan, E15) to ~2-3 min on ROCm. 2. MLA (GLM-4.7-Flash): the split INVERTS - Vulkan wins BOTH phases at every depth, ROCm never wins, and ROCm's prefill deficit widens with depth (Vulkan +1.6% at d0 -> +19.4% at 32K). ROCm does not rescue Vulkan's MLA prefill collapse (F8); it collapses harder. Generation (tg): Vulkan wins for both architectures, gap shrinking to noise at extreme depth. DEPLOYMENT RULE (corrected, business-grade): ROCm is a large and growing win ONLY for pure-MoE prefill-heavy work (document ingest, RAG, summarization); for MLA models use Vulkan for everything; generation-heavy chat is always Vulkan. Vulkan is the safe default; ROCm is a targeted optimization for one model class. Mechanism candidate: MLA's latent-projection matmul shapes don't favour rocBLAS the way standard-attention GEMMs do (not separable here). Evidence: results/experiments.md E18a/E18b; raw bench-e18a-deep-, bench-e18b-glm-. Status: ACTIVE.