{
  "_about": "fak position rows for the 'serving' group. dim_id links each to a _taxonomy.json dimension.",
  "rows": [
    {
      "id": "continuous-batching-aggregate-throughput",
      "dim_id": "continuous-batching-aggregate-throughput",
      "axis": "Continuous / in-flight (iteration-level) batching: max aggregate token throughput at high concurrency",
      "category": "throughput",
      "competitor": "vLLM (PagedAttention + continuous batching); Orca (iteration-level scheduling, originator); TensorRT-LLM (in-flight batching)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/pdf/2309.06180 (2023-09)",
      "fak_value": null,
      "unit": "req/s under concurrency",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "CLAIMS.md L163 ([SIMULATED] continuous-batching read-only telemetry, not on live serving path); CLAIMS.md L6 (SIMULATED tag definition); existing data.json row 'continuous-batching'.",
      "apples_to_apples": true,
      "comparison_note": "REAL GAP fak should measure but currently OUT OF SCOPE for the kernel as shipped: CLAIMS labels continuous/in-flight batching [SIMULATED] read-only telemetry, not on the live serving path, and the polymodel decode lane is explicitly SERIAL (at-most-one-model-decodes-per-step, off-mainline). Iteration-level batching is the defining vLLM/SGLang throughput lever; fak has NO shipped number. fak's fleet win is prefix-reuse work-ELIMINATION, a different axis from concurrent-decode batching, so no parity is implied.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "chunked-prefill-pd-interference",
      "dim_id": "chunked-prefill-pd-interference",
      "axis": "Chunked / piggyback prefill and prefill-decode interference (stall-free batching)",
      "category": "scheduling",
      "competitor": "Sarathi-Serve (chunked-prefill + stall-free scheduling); vLLM (chunked prefill); SGLang (chunked prefill)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/abs/2403.02310 (2024-03)",
      "fak_value": null,
      "unit": "× serving capacity under TBT SLO",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No chunked-prefill / TBT-SLO / prefill-decode-interference number in BENCHMARK-AUTHORITY.md or CLAIMS.md. fak's prefill rows (single-stream-prefill, radix-live-vs-ceiling) are single-stream or reuse, not stall-free chunked scheduling under load.",
      "apples_to_apples": true,
      "comparison_note": "OUT OF SCOPE for fak as a reuse kernel today, and an unmeasured GAP if pursued: Sarathi-Serve-style chunked/piggyback prefill caps per-iteration prefill work to bound TBT under decode interference. fak owns its own forward but has not built or measured chunked-prefill scheduling; no number exists, so no claim.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "cache-aware-scheduling-routing",
      "dim_id": "cache-aware-scheduling-routing",
      "axis": "Request scheduling and cache-aware routing (FCFS vs priority vs prefix/KV-cache-aware)",
      "category": "scheduling",
      "competitor": "SGLang RadixAttention published hit-rate band",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "SGLang: Zheng et al., 'Efficient Execution of Structured Language Model Programs', arXiv:2312.07104, NeurIPS 2024 — published 50–99% hit-rate band.",
      "fak_value": 86.7,
      "unit": "%",
      "higher_is_better": true,
      "verdict": "parity",
      "status": "shipped",
      "fak_commit": "92896a4",
      "fak_artifact": "experiments/radixattention/radixbench-qwen2.5-1.5b-q8-agents-fresh-20260619.json",
      "fak_doc": "data.json row 'kv-hit-rate'; BENCHMARK-AUTHORITY.md L23 + 'RadixAttention Model Ladder' (FCFS 62.1% -> cache-aware 86.7% = 100% of optimal); artifact radixbench-qwen2.5-1.5b-q8-agents-fresh-20260619.json (verify workloads[0].cache_hit_rate=0.8666666666666667). Commit 92896a4.",
      "apples_to_apples": true,
      "comparison_note": "fak measured on-box: cache-aware (≡ DFS) scheduling recovers FCFS 62.1% → 86.7% = 100% of optimal, inside SGLang's published band. Split-reuse proven bit-identical to recompute (max|Δ|=0), so the hit is a real reuse, not a numerics shortcut. FENCE: 86.7% is on radixbench's synthetic 'agents' workload (deliberately cache-favorable); on a REAL tau2-airline trace fak's measured addressable purity is ~0.7% (CLAIMS vDSO unit 33/83) — so this is a same-workload-as-SGLang reuse-mechanism parity, not a promise of 86.7% on every production corpus.",
      "measured_on": "2026-06-19",
      "competitor_range": [
        50,
        99
      ],
      "verify": {
        "field": "workloads[0].cache_hit_rate",
        "expect": 0.8666666666666667,
        "tol": 1e-06
      }
    },
    {
      "id": "absolute-tokens-per-second-mlperf",
      "dim_id": "absolute-tokens-per-second-mlperf",
      "axis": "Absolute aggregate tokens/s at scale on standardized hardware (MLPerf Inference)",
      "category": "throughput",
      "competitor": "NVIDIA GB300 NVL72 x4 (288 Blackwell Ultra GPUs, TensorRT-LLM/Dynamo); MLPerf Inference v6.0 submitters (DeepSeek-R1 671B MoE, offline)",
      "competitor_class": "sota",
      "competitor_value": 2494000,
      "competitor_source": "https://www.storagereview.com/news/nvidia-sets-mlperf-inference-v6-0-records-with-blackwell-ultra-platform (2026-04-01)",
      "fak_value": null,
      "unit": "tokens/s (standardized MLPerf hardware)",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No MLPerf submission or standardized-hardware aggregate tok/s in BENCHMARK-AUTHORITY.md. The only concurrent server number is the GPU server run (data.json 'served-throughput-vs-sglang', 1085.6 tok/s @ conc 64) which is fak-gateway-fronting-SGLang on non-MLPerf hardware/harness, not a standardized MLPerf result.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE BY DESIGN for a reuse kernel: MLPerf Inference v6.0 (2026-03-30) ranks absolute aggregate tok/s on standardized Blackwell-Ultra hardware, and its headline model is now DeepSeek-R1 671B MoE, not Llama-3.1-405B — NVIDIA's 288-GPU (4x GB300 NVL72) submission hit ~2.494M tok/s aggregate / 9,821 tok/s/GPU offline, superseding the old v5.x GB200 / 405B bar. fak has no MLPerf submission and its own generic engine ceilings at ~7B (data.json model-size-ceiling), so it is not in this race and does NOT intend an own-engine MLPerf-shaped 671B number; on a frontier MoE it FRONTS SGLang/llama.cpp rather than serving them itself. fak's actual DeepSeek-class-MoE serving path is the in-kernel GLM-5.2 work (#1010, #1026): MoE/FFN experts + router on its own pure GPU kernel (cosine=1.0, commit 498a4ab) but on a SINGLE device, so no standardized fak tok/s exists. See max-model-and-moe-coverage.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "interactive-latency-slo-tail",
      "dim_id": "interactive-latency-slo-tail",
      "axis": "Interactive latency SLO attainment: TTFT and TPOT/ITL tail under load",
      "category": "latency",
      "competitor": "MLPerf Inference v6.0 interactive scenario (DeepSeek-R1 / GPT-OSS 120B; TPOT <= 15 ms, TTFT <= 1.5-2.0 s P99); TensorRT-LLM; Sarathi-Serve / vLLM chunked prefill",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://mlcommons.org/2026/03/mlperf-inference-gpt-oss/ (2026-03-24)",
      "fak_value": null,
      "unit": "tok/s @ conc 64 (peak, fak-gateway vs raw SGLang)",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "data.json row 'served-throughput-vs-sglang'; artifact experiments/qwen36/dgx-r4-20260622/compare.json; docs/benchmarks/QWEN36-27B-GPU-SERVER-RESULTS.md s2. fak 1085.6 vs raw SGLang 1451.6 tok/s @ conc 64 on 8-GPU datacenter server, Qwen3.6-27B.",
      "apples_to_apples": true,
      "comparison_note": "fak ships no ms-level P99 TTFT/TPOT tail-latency number; the only live head-to-head is a THROUGHPUT sweep (it trails raw SGLang 0.75× at peak — see peak-serving-throughput-per-gpu). An honest gap on the latency-tail axis, not a measured trail.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "time-to-first-token",
      "dim_id": "time-to-first-token",
      "axis": "Time-to-first-token (TTFT) under realistic prefill",
      "category": "latency",
      "competitor": "MLPerf Inference v6.0 (DeepSeek-R1 interactive TTFT <= 1.5 s P99; Llama-3.1-405B interactive 4.5 s still defined); vLLM benchmark_serving; NVIDIA GenAI-Perf",
      "competitor_class": "sota",
      "competitor_value": 1500,
      "competitor_source": "https://mlcommons.org/2026/03/mlperf-inference-gpt-oss/ (2026-03-24)",
      "fak_value": null,
      "unit": "ms TTFT (P50/P99)",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No TTFT row exists in BENCHMARK-AUTHORITY.md or CLAIMS.md. fak commits prefill-WORK ratios (single-stream prefill 0.58x vs llama.cpp CPU; RadixAttention live prefill 4.58x-6.95x vs full re-prefill) but never a TTFT measured as a latency percentile at fixed ISL/concurrency. The committed fak-fronts-SGLang harness (experiments/qwen36/dgx-r4-20260622/compare.json) is NON-STREAMING -- it captures total request latency (E2EL, now committed; see end-to-end-request-latency) but cannot isolate the first-token wait, so it bounds but does not measure the TTFT tax.",
      "apples_to_apples": false,
      "comparison_note": "REAL GAP fak should measure. TTFT is adjacent to fak's actual lever (prefix-reuse cuts prefill tokens, which IS the dominant TTFT term on a cache hit), yet fak has never reported TTFT as a percentile under realistic prefill/concurrency the way MLPerf v6.0 (DeepSeek-R1 1.5 s P99 TTFT interactive; 405B 4.5 s still defined) or vLLM/GenAI-Perf do. The adjacent committed evidence is the +1804.9 ms E2EL gateway tax at conc 64 (end-to-end-request-latency), which is the UPPER BOUND on the TTFT tax since the gateway's admission decision (Decide 362 ns / AdmitChain <=87 us idle-box) runs before the first upstream byte. No-claim stands until a STREAMING run isolates the per-request TTFT distribution -- host-gated on the GPU box. The streaming-capable harness already exists: `fak webbench serving --dataset FILE --tracks ours,sglang --endpoints ours=<fak-gateway/v1>,sglang=<raw-sglang/v1>` captures per-request ttft_ms/itl_ms/tpot_ms over SSE (internal/webbench/serving.go MeasureSSERequest, ServingTrackStats.TTFTMillis). The committed compare.json was the OLDER non-streaming runner, so the only gap is a live fak-fronts-SGLang streaming run on the GPU box (off-box here), not new code.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "inter-token-latency-tpot",
      "dim_id": "inter-token-latency-tpot",
      "axis": "Inter-token latency / time-per-output-token (ITL/TPOT)",
      "category": "latency",
      "competitor": "MLPerf Inference v6.0 (DeepSeek-R1 / GPT-OSS 120B interactive TPOT <= 15 ms P99); vLLM benchmark_serving; NVIDIA GenAI-Perf",
      "competitor_class": "sota",
      "competitor_value": 15,
      "competitor_source": "https://mlcommons.org/2026/03/mlperf-inference-gpt-oss/ (2026-03-24)",
      "fak_value": null,
      "unit": "ms TPOT (P50/P99)",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "fak commits single-stream DECODE throughput (8.7 tok/s 7B Q8 CPU, ~0.55-0.73x of llama.cpp at HEAD 374776a; ~120 tok/s GPU parity), but throughput is not inter-token LATENCY: no TPOT/ITL percentile is committed in BENCHMARK-AUTHORITY.md or CLAIMS.md. The committed fak-fronts-SGLang harness (experiments/qwen36/dgx-r4-20260622/compare.json) is NON-STREAMING -- it captures total request latency (E2EL, now committed; see end-to-end-request-latency) but does not timestamp individual output tokens, so it cannot isolate the per-token (TPOT) component of the gateway tax.",
      "apples_to_apples": false,
      "comparison_note": "REAL GAP fak should measure. fak has decode-rate numbers (which trail llama.cpp single-stream, as it openly states it does not target single-stream) but never the per-output-token latency distribution MLPerf v6.0 encodes (<= 15 ms P99 TPOT interactive for DeepSeek-R1 / GPT-OSS 120B; the prior 80 ms is now the server-scenario bound). The adjacent committed evidence is the +1804.9 ms E2EL gateway tax at conc 64 (end-to-end-request-latency); since the gateway is a streaming pass-through that adjudicates ONCE at admission and does not re-decide per output token, most of that tax is front-loaded into TTFT, leaving a small per-token relay component -- but the non-streaming artifact cannot separate it. No-claim stands until a STREAMING run isolates the per-request TPOT/ITL distribution -- host-gated on the GPU box. The streaming-capable harness already exists: `fak webbench serving --dataset FILE --tracks ours,sglang --endpoints ours=<fak-gateway/v1>,sglang=<raw-sglang/v1>` captures per-request tpot_ms/itl_ms over SSE (internal/webbench/serving.go MeasureSSERequest, ServingTrackStats.TPOTMillis). The committed compare.json was the OLDER non-streaming runner, so the only gap is a live fak-fronts-SGLang streaming run on the GPU box (off-box here), not new code.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "end-to-end-request-latency",
      "dim_id": "end-to-end-request-latency",
      "axis": "End-to-end request latency (E2EL)",
      "category": "latency",
      "competitor": "Raw SGLang 0.5.10 (TP=8, no fak proxy), Qwen3.6-27B on an 8-GPU datacenter server — SAME load harness as fak-gateway (the gateway is the only delta); the absolute-latency SOTA bar is NVIDIA GenAI-Perf / vLLM benchmark_serving e2el percentile.",
      "competitor_class": "sota",
      "competitor_value": 7222.0,
      "competitor_source": "experiments/qwen36/dgx-r4-20260622/compare.json (raw-SGLang vs fak-gateway, conc 1->128, P50 request latency @ conc 64); QWEN36-27B-GPU-SERVER-RESULTS.md s2",
      "fak_value": 9026.9,
      "unit": "ms E2EL P50 @ conc 64",
      "higher_is_better": false,
      "verdict": "trails",
      "status": "shipped",
      "fak_commit": "044220f8",
      "fak_artifact": "experiments/qwen36/dgx-r4-20260622/compare.json",
      "fak_doc": "docs/benchmarks/QWEN36-27B-GPU-SERVER-RESULTS.md",
      "apples_to_apples": true,
      "comparison_note": "WITNESSED gateway tax, the honest framing. Same 8-GPU datacenter server / Qwen3.6-27B / load harness, fak-gateway-in-front vs raw SGLang (the gateway is the only delta). At peak conc 64 fak's E2EL P50 is 9026.9 ms vs raw 7222.0 ms -> a +1804.9 ms (0.80x) end-to-end gateway tax. This is the FULL fak-in-front delta (proxy relay overhead PLUS the queueing induced by fak's lower peak throughput, 0.75x; see peak-serving-throughput-per-gpu), NOT just the in-process adjudication primitive (Decide 362 ns / AdmitChain <=87 us idle-box) which is only the small floor under it. fak fronts the backend and does NOT claim to win the raw-latency race; its value is the adjudication/coherence/measurement plane.",
      "verify": {"field": "[0].p50_ms", "expect": 9026.858449913561, "tol": 0.01},
      "measured_on": "2026-06-22"
    },
    {
      "id": "tail-latency-percentiles",
      "dim_id": "tail-latency-percentiles",
      "axis": "Tail latency distribution (P50/P95/P99/P99.9)",
      "category": "latency",
      "competitor": "Raw SGLang 0.5.10 (TP=8, no fak proxy), Qwen3.6-27B on an 8-GPU datacenter server — SAME load harness as fak-gateway (the gateway is the only delta); MLPerf Inference encodes its SLOs at P99 and production practice flags P99>>P50 as a saturation red flag.",
      "competitor_class": "sota",
      "competitor_value": 8157.9,
      "competitor_source": "experiments/qwen36/dgx-r4-20260622/compare.json (raw-SGLang vs fak-gateway, conc 1->128, P99 request latency @ conc 64); QWEN36-27B-GPU-SERVER-RESULTS.md s2",
      "fak_value": 9997.6,
      "unit": "ms request-latency P99 @ conc 64",
      "higher_is_better": false,
      "verdict": "trails",
      "status": "shipped",
      "fak_commit": "044220f8",
      "fak_artifact": "experiments/qwen36/dgx-r4-20260622/compare.json",
      "fak_doc": "docs/benchmarks/QWEN36-27B-GPU-SERVER-RESULTS.md",
      "apples_to_apples": true,
      "comparison_note": "WITNESSED full request-latency tail on the same harness, fak-gateway-in-front vs raw SGLang. At peak conc 64 the committed distribution is fak P50/P95/P99 = 9026.9 / 9979.9 / 9997.6 ms vs raw 7222.0 / 8134.7 / 8157.9 ms; the P99 gateway tax is +1839.7 ms (0.82x). The tail is NOT widened by the gateway: fak's P99/P50 spread is 1.11x vs raw 1.13x, so fak shifts the WHOLE distribution by the ~+1.8 s tax rather than fattening the tail. Honest framing: fak fronts the backend and adds a measured tax, it does not claim to win the raw-latency race. (Sub-ms in-process primitive percentiles -- Decide 362 ns / AdmitChain <=87 us idle-box, BENCHMARK-AUTHORITY.md mac-m3pro-kernel-20260620 -- are the floor, not this under-load serving distribution.)",
      "verify": {"field": "[0].p99_ms", "expect": 9997.646578820422, "tol": 0.01},
      "measured_on": "2026-06-22"
    },
    {
      "id": "latency-throughput-pareto",
      "dim_id": "latency-throughput-pareto",
      "axis": "Latency-vs-throughput Pareto frontier",
      "category": "throughput",
      "competitor": "Sarathi-Serve (chunked prefill); DynaServe; vLLM/SGLang sweeps",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/pdf/2403.02310 (2024-03)",
      "fak_value": null,
      "unit": "x of raw SGLang tok/s @ conc 64 (peak)",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "experiments/qwen36/dgx-r4-20260622/compare.json + docs/benchmarks/QWEN36-27B-GPU-SERVER-RESULTS.md: fak-gateway vs raw SGLang on 8-GPU datacenter server / Qwen3.6-27B, concurrency sweep 1->128; fak/raw = 0.60x (conc 8) -> 0.75x (conc 64 peak, 1085.6 vs 1451.6 tok/s) -> 0.97x (conc 128).",
      "apples_to_apples": false,
      "comparison_note": "fak has not recorded a latency-vs-throughput Pareto frontier (no P99 TTFT/TPOT vs request-rate). The adjacent committed evidence is a throughput-vs-concurrency sweep where fak trails raw SGLang (see peak-serving-throughput-per-gpu). Named as a gap, not a Pareto measurement.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "prefill-decode-interference",
      "dim_id": "prefill-decode-interference",
      "axis": "Prefill-decode interference & chunked-prefill TTFT/TPOT tension",
      "category": "latency",
      "competitor": "Sarathi-Serve; vLLM chunked prefill; SGLang",
      "competitor_class": "sota",
      "competitor_value": 68,
      "competitor_source": "https://www.spheron.network/blog/llm-serving-optimization-continuous-batching-paged-attention/ (2026-01)",
      "fak_value": null,
      "unit": "% P95 ITL improvement from chunked prefill",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No chunked-prefill mechanism is shipped or claimed in CLAIMS.md / BENCHMARK-AUTHORITY.md. fak's own engine prefills a prefix once and clones it (NewBatchFromPrefix) but does not interleave long prefills with decode steps to smooth ITL.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE for a reuse kernel. Chunked prefill (Sarathi-Serve: ~68% P95 ITL improvement at 32K inputs) is a SCHEDULER technique inside a serving engine to remove decode-side ITL spikes; fak's own decode path is serial and small-model, and on the GPU server it fronts SGLang/llama.cpp which own this scheduling. fak makes no claim and shows no number on prefill-decode interference.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "peak-serving-throughput-per-gpu",
      "dim_id": "peak-serving-throughput-per-gpu",
      "axis": "Peak served throughput per accelerator (model-served-by-engine, MLPerf-grounded)",
      "category": "throughput",
      "competitor": "Raw SGLang 0.5.10 (TP=8, no fak proxy), Qwen3.6-27B on an 8-GPU datacenter server",
      "competitor_class": "sota",
      "competitor_value": 1451.6,
      "competitor_source": "experiments/qwen36/dgx-r4-20260622/compare.json (raw-SGLang vs fak-gateway, conc 1→128); QWEN36-27B-GPU-SERVER-RESULTS.md §2",
      "fak_value": 1085.6,
      "unit": "tok/s @ conc 64 (peak)",
      "higher_is_better": true,
      "verdict": "trails",
      "status": "shipped",
      "fak_commit": "",
      "fak_artifact": "experiments/qwen36/dgx-r4-20260622/compare.json",
      "fak_doc": "docs/benchmarks/QWEN36-27B-GPU-SERVER-RESULTS.md",
      "apples_to_apples": true,
      "comparison_note": "THE honest counter to the fleet 'lead' rows: this is the ONLY real concurrent-serving head-to-head against a LIVE SGLang process (same 8-GPU datacenter server / 27B / load harness, fak-in-front vs raw). fak TRAILS — it is the gateway/adjudication TAX: 0.60× worst (conc 8) → 0.75× at peak (conc 64) → ~0.97× converged at saturation (conc 128). fak's value here is the adjudication/coherence/measurement plane, NOT raw tok/s; the 4.1× fleet 'lead' is reuse-WORK eliminated on fak's own kernel held constant, a different axis from a throughput race against a tuned engine.",
      "measured_on": "2026-06-22"
    },
    {
      "id": "single-stream-decode-7b",
      "dim_id": "single-stream-decode-cpu",
      "axis": "Single-stream (one chat) decode throughput on CPU",
      "category": "single-stream",
      "competitor": "llama.cpp Metal (M3 Pro)",
      "competitor_class": "sota",
      "competitor_value": 17.3,
      "competitor_source": "llama.cpp llama-bench Metal, same M3 Pro box (build b9707); fak QWEN25-7B-RESULTS.md.",
      "fak_value": 8.7,
      "unit": "tok/s",
      "higher_is_better": true,
      "fak_commit": "34c74f4",
      "fak_artifact": "model-ladder/modelbench-qwen25-7b-q8.json",
      "fak_doc": "QWEN25-7B-RESULTS.md",
      "apples_to_apples": true,
      "comparison_note": "fak explicitly does NOT target single-stream raw throughput — one chat → use llama.cpp. The gap narrows with model size (0.39× → 0.53×, 1.5B → 7B) toward the shared ~150 GB/s unified-memory bandwidth floor; arm64 still lacks the register-blocked int8 GEMM tile that already exists on x86.",
      "measured_on": "2026-06-21",
      "verdict": "trails",
      "status": "shipped"
    },
    {
      "id": "single-stream-prefill",
      "dim_id": "single-stream-prefill-cpu",
      "axis": "Single-stream prefill throughput, apples-to-apples CPU-vs-CPU",
      "category": "single-stream",
      "competitor": "llama.cpp CPU, same box + Q8 weights (CPU-vs-CPU)",
      "competitor_class": "sota",
      "competitor_value": 1.0,
      "competitor_source": "llama.cpp CPU llama-bench, same box, Q8 weights; fak MODEL-LADDER-VS-SOTA (Regime A, CPU) · QWEN25-7B-RESULTS.md.",
      "fak_value": 0.12,
      "unit": "× of llama.cpp CPU",
      "higher_is_better": true,
      "fak_commit": "34c74f4",
      "fak_doc": "MODEL-LADDER-VS-SOTA-2026-06-21.md · QWEN25-7B-RESULTS.md",
      "apples_to_apples": true,
      "comparison_note": "Apples-to-apples CPU-vs-CPU is ~0.12× on arm64 (which lacks the register-blocked int8 GEMM tile); the x86 Zen5 per-token compute SLOPE already reaches parity (1.03×), the ceiling arm64 inherits once the tile lands. The often-cited 0.083× vs a Metal GPU is NOT apples-to-apples — ~12× of that gap is the GPU device, so it collapses toward ~0.12× once the device is removed.",
      "measured_on": "2026-06-21",
      "verdict": "trails",
      "status": "shipped"
    },
    {
      "id": "gpu-decode-parity",
      "dim_id": "single-stream-decode-gpu",
      "axis": "Single-stream decode throughput on a consumer GPU",
      "category": "single-stream",
      "competitor": "llama.cpp Q8_0 on the same RTX 4070 (-ngl 99)",
      "competitor_class": "sota",
      "competitor_value": 120.0,
      "competitor_range": [
        105,
        135
      ],
      "competitor_source": "llama.cpp llama-bench Q8_0, same box (120 ± 15 tok/s); fak GPU.md §3b + LLAMACPP-HEADTOHEAD-RESULTS.md.",
      "fak_value": 120.0,
      "unit": "tok/s",
      "higher_is_better": true,
      "fak_commit": "1029e37",
      "fak_doc": "GPU.md §3b · LLAMACPP-HEADTOHEAD-RESULTS.md",
      "apples_to_apples": false,
      "comparison_note": "Same GPU (RTX 4070, WSL2), but fak runs f32 — 4× the weight bytes of llama.cpp's 8-bit Q8_0 — so parity is reached at HIGHER precision and ~46% GPU utilization (a disclosed fak advantage, not a hidden tilt). Gated FAK_CUDA_GRAPH=1; small model that fits VRAM (a 7B f32 set won't fit WSL's ~15 GB, so large-model parity is not claimed).",
      "measured_on": "2026-06-20",
      "verdict": "parity",
      "status": "shipped"
    }
  ]
}