{
  "_about": "fak position rows for the 'cost' group. dim_id links each to a _taxonomy.json dimension.",
  "rows": [
    {
      "id": "goodput-under-slo",
      "dim_id": "goodput-under-slo",
      "axis": "Goodput under an SLA (requests/s meeting TTFT and TPOT SLOs simultaneously)",
      "category": "cost-efficiency",
      "competitor": "DistServe (introduced goodput, P/D disaggregation); SGLang-PD; MuxWise (P/D multiplexing)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/abs/2401.09670 (2024-01)",
      "fak_value": null,
      "unit": "req/s meeting TTFT+TPOT SLO",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No goodput/SLA-attainment number exists in BENCHMARK-AUTHORITY.md or CLAIMS.md. The only concurrent-serving head-to-head (data.json 'served-throughput-vs-sglang') reports peak tok/s, not SLO-bounded goodput.",
      "apples_to_apples": true,
      "comparison_note": "REAL GAP fak should measure. fak ships no goodput-under-SLA number (no TTFT/TPOT SLO attainment curve). The GPU server run measured raw peak throughput at fixed concurrency, not requests meeting joint latency bounds. DistServe/MuxWise-style goodput is a standard serving-systems axis fak has zero evidence on; named as a gap, not parity.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "slo-constrained-goodput",
      "dim_id": "slo-constrained-goodput",
      "axis": "SLO-constrained goodput (per-GPU)",
      "category": "cost-efficiency",
      "competitor": "DistServe; DynaServe; NVIDIA Dynamo; GenAI-Perf goodput mode",
      "competitor_class": "sota",
      "competitor_value": 4.48,
      "competitor_source": "https://arxiv.org/html/2401.09670v1 (2024-01)",
      "fak_value": null,
      "unit": "SLO-attained req/s per GPU",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No goodput-under-SLO number exists. CLAIMS.md labels continuous-batching [SIMULATED] (read-only telemetry, not on the live serving path) and the polymodel decode lane is explicitly SERIAL/off-mainline, so fak has no SLO-constrained per-GPU goodput measurement.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE for a reuse kernel. SLO-constrained goodput is the metric of a full PD-disaggregating serving STACK (DistServe 4.48x goodput, GenAI-Perf goodput mode); fak is a kernel/adjudication plane that FRONTS such a stack (the GPU server run is SGLang-serves + fak-adjudicates) and does not own the scheduler that goodput measures. no-claim.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "effective-capacity-slo-gain",
      "dim_id": "effective-capacity-slo-gain",
      "axis": "End-to-end effective request capacity / cost gain from the KV system under SLO",
      "category": "cost-efficiency",
      "competitor": "Mooncake; LMCache + vLLM; NVIDIA Dynamo",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://www.usenix.org/conference/fast25/presentation/qin (2025-02)",
      "fak_value": null,
      "unit": "% effective request capacity under SLO",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No SLO-bound effective-capacity figure exists. The fleet multipliers (60.3x naive / 4.1x tuned, headline-qwen-50x5.json) are work-ELIMINATION on fak's own kernel held constant, not SLO-bounded request capacity; the only live concurrent-serving head-to-head (data.json served-throughput-vs-sglang, compare.json) shows fak at 0.60x->0.75x->~0.97x of raw SGLang, i.e. a gateway TAX, not a capacity gain.",
      "apples_to_apples": false,
      "comparison_note": "REAL GAP / honestly a non-win. fak has no Mooncake-style 'effective request capacity under SLO' number, and its one real concurrent-serving head-to-head (fak-gateway in front of SGLang on 8-GPU datacenter server) TRAILS raw SGLang (0.75x at peak) because the value added there is the adjudication/coherence/measurement plane, not throughput. So fak cannot claim the 59-498% capacity gain axis; conflating its reuse-work multipliers with SLO capacity would be dishonest.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "cost-per-million-tokens",
      "dim_id": "cost-per-million-tokens",
      "axis": "Inference unit economics ($ per 1M tokens) at realistic utilization",
      "category": "cost-efficiency",
      "competitor": "Hosted frontier APIs; vLLM/SGLang self-host on H100/H200; FP8/FP4 quantization",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://introl.com/blog/inference-unit-economics-true-cost-per-million-tokens-guide (2025-09-01)",
      "fak_value": null,
      "unit": "$ per 1M tokens at realistic utilization",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No $/token row in BENCHMARK-AUTHORITY.md or CLAIMS.md; fak measures work-elimination ratios (tokens/FLOPs), never a dollar figure or utilization-adjusted cost",
      "apples_to_apples": true,
      "comparison_note": "OUT OF SCOPE as a measured number for a reuse kernel, though it is the axis fak's reuse story IMPLIES. fak's headline is work eliminated (50x5 fleet 4.1x vs tuned / 60.3x vs naive; ultra-long-context ~4x vs warm cache vs ~40x vs naive) which translates to lower infra cost ON TOP of any model at the same quality, but fak has committed NO $/1M-token figure, no utilization model, and no quantization-cost number. Stating a dollar SOTA-relative position would invent a number. Honest no-claim.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "energy-tokens-per-watt",
      "dim_id": "energy-tokens-per-watt",
      "axis": "Energy efficiency (Wh per token / tokens-per-watt) and power-capped throughput",
      "category": "cost-efficiency",
      "competitor": "NVIDIA Blackwell (GB200/GB300, FP4); AMD MI355X (FP4)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/pdf/2603.06630 (2026-03-01)",
      "fak_value": null,
      "unit": "tokens per watt / Wh per token",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "CLAIMS.md Engine: token-per-watt is [SIMULATED] read-only telemetry, 'no watt source on the box'; tokens-per-watt scorecard row competitor_value=null",
      "apples_to_apples": true,
      "comparison_note": "REAL GAP, named not hidden. CLAIMS explicitly flags token-per-watt as [SIMULATED] because there is no power-telemetry source on the build box; the seam is real, the numbers are illustrative. Zero measured evidence against the empirical ~1e-4 to 2e-3 Wh/token band or any Blackwell/MI355X FP4 reference. fak can never be read as claiming efficiency parity; honest no-claim.",
      "measured_on": "2026-06-23"
    }
  ]
}