{
  "_about": "fak position rows for the 'memory' group. dim_id links each to a _taxonomy.json dimension.",
  "rows": [
    {
      "id": "kv-cache-memory-efficiency-concurrency",
      "dim_id": "kv-cache-memory-efficiency-concurrency",
      "axis": "KV-cache memory efficiency and max concurrent sequences (paging / fragmentation)",
      "category": "kv-cache",
      "competitor": "vLLM (PagedAttention); vAttention (paging without PagedAttention); SGLang (token-level KV pool)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/pdf/2309.06180 (2023-09)",
      "fak_value": null,
      "unit": "% KV memory waste / max concurrent seqs",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No PagedAttention-style memory-waste or max-concurrency number in BENCHMARK-AUTHORITY.md. CLAIMS.md L161 [STUB] 'No zero-copy KV co-residence with an external serving engine' (copy-CAS path, paging into the working set is residency decomposition, not anti-fragmentation KV paging).",
      "apples_to_apples": true,
      "comparison_note": "OUT OF SCOPE / disclosed capability gap: fak owns its own in-kernel KV cache via copy-CAS (that IS the fusion), with no PagedAttention-style block paging to drive KV-memory waste toward <4% or to maximize concurrent-sequence count on fixed VRAM. CLAIMS marks external zero-copy KV co-residence an explicit [STUB] (~120h, out of scope). No memory-efficiency or max-concurrency number exists; reuses the named-gap row vllm-zero-copy-kv.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "prefix-caching-kv-reuse",
      "dim_id": "prefix-caching-kv-reuse",
      "axis": "Prefix caching / automatic KV reuse across requests (shared-context workloads)",
      "category": "kv-cache",
      "competitor": "fak's own deterministic token-reuse ceiling (the exact upper bound)",
      "competitor_class": "theoretical-ceiling",
      "competitor_value": 7.5,
      "competitor_source": "fak's exact token-reuse count (prefill_token_speedup=7.50 in the same committed artifact) — the model-independent theoretical maximum, not an external competitor.",
      "fak_value": 6.95,
      "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 rows 'radix-live-vs-ceiling' (live 6.95x vs 7.50x token ceiling, artifact workloads[0].live_prefill_speedup=6.951) and 'kv-hit-rate' (86.7% in SGLang band); BENCHMARK-AUTHORITY.md RadixAttention Model Ladder (135M 4.58x -> 1.5B 6.95x), commit 92896a4. Split-reuse == recompute max|delta|=0.",
      "apples_to_apples": true,
      "comparison_note": "A ceiling is approached, never led: live wall-clock climbs toward the 7.50× token bound with model size (135M 4.58× → 360M 5.40× → 0.5B 6.20× → 1.5B 6.95×), confirming the residual gap is clone/memcpy overhead that vanishes on larger models, not an architectural limit.",
      "measured_on": "2026-06-19",
      "verify": {
        "field": "workloads[0].live_prefill_speedup",
        "expect": 6.951232568881241,
        "tol": 1e-06
      }
    },
    {
      "id": "prefix-cache-ttft-impact",
      "dim_id": "prefix-cache-ttft-impact",
      "axis": "Prefix/KV-cache reuse impact on TTFT (cache-hit latency)",
      "category": "kv-cache",
      "competitor": "fak's own deterministic token-reuse ceiling (the exact upper bound)",
      "competitor_class": "theoretical-ceiling",
      "competitor_value": 7.5,
      "competitor_source": "fak's exact token-reuse count (prefill_token_speedup=7.50 in the same committed artifact) — the model-independent theoretical maximum, not an external competitor.",
      "fak_value": 6.95,
      "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": "experiments/radixattention/radixbench-qwen2.5-1.5b-q8-agents-fresh-20260619.json (commit 92896a4): live_prefill_speedup=6.95x climbing to the 7.50x exact token-reuse ceiling; cache hit 86.7% (FCFS 62.1% -> cache-aware), inside SGLang's published 50-99% band; split-reuse proven bit-identical to recompute (max|delta|=0).",
      "apples_to_apples": true,
      "comparison_note": "A ceiling is approached, never led: live wall-clock climbs toward the 7.50× token bound with model size (135M 4.58× → 360M 5.40× → 0.5B 6.20× → 1.5B 6.95×), confirming the residual gap is clone/memcpy overhead that vanishes on larger models, not an architectural limit.",
      "measured_on": "2026-06-19",
      "verify": {
        "field": "workloads[0].live_prefill_speedup",
        "expect": 6.951232568881241,
        "tol": 1e-06
      }
    },
    {
      "id": "paged-kv-memory-utilization",
      "dim_id": "paged-kv-memory-utilization",
      "axis": "Paged KV block management and memory utilization (anti-fragmentation)",
      "category": "kv-cache",
      "competitor": "vLLM (PagedAttention); SGLang; TensorRT-LLM",
      "competitor_class": "sota",
      "competitor_value": 96.3,
      "competitor_source": "https://arxiv.org/abs/2309.06180 (2023-09)",
      "fak_value": null,
      "unit": "% KV memory utilization",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No memory-utilization figure in BENCHMARK-AUTHORITY.md or CLAIMS.md. CLAIMS line 85: in-kernel model owns its KV cache as a Go structure; internal/radixkv rebuilds RadixAttention (edge-split via Evict) over it, but there is no paged-block utilization / fragmentation % measured.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE for a reuse kernel. fak does not implement a PagedAttention-style block allocator; it owns a contiguous kernel-owned KVCache (CLAIMS 'In-kernel model') and a radix tree over it for reuse, not anti-fragmentation block management. No utilization % is measured against vLLM's ~96.3%, so no parity is claimed.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "automatic-prefix-caching-hit-rate",
      "dim_id": "automatic-prefix-caching-hit-rate",
      "axis": "Automatic prefix caching / RadixAttention prefix reuse and cache hit rate",
      "category": "kv-cache",
      "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": "BENCHMARK-AUTHORITY.md 'RadixAttention hit rate 86.7% (FCFS 62.1% -> cache-aware)' commit 92896a4, artifact radixbench-qwen2.5-1.5b-q8-agents-fresh-20260619.json; CLAIMS line 93 (radixkv 77.2-88.2% across shapes, inside SGLang's verified 50-99% band, reuse bit-identical to recompute max|Δ|=0).",
      "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": "non-prefix-kv-reuse-cacheblend",
      "dim_id": "non-prefix-kv-reuse-cacheblend",
      "axis": "Non-prefix / cross-document KV reuse (RAG chunk caching)",
      "category": "kv-cache",
      "competitor": "LMCache (CacheBlend)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://blog.lmcache.ai/en/2024/10/09/beyond-prefix-caching-how-lmcache-speeds-up-rag-by-4-5x-by-one-line-of-change/ (2024-10)",
      "fak_value": null,
      "unit": "x TTFT reduction (non-prefix chunks)",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No CacheBlend-style non-prefix / cross-document KV reuse in CLAIMS.md or BENCHMARK-AUTHORITY.md. internal/radixkv (CLAIMS line 93) is longest-PREFIX match only; CanShare (line 90) requires a byte-identical PrefixDigest. No partial-recomputation cross-chunk KV fusion exists.",
      "apples_to_apples": false,
      "comparison_note": "REAL GAP fak should measure. fak's reuse is strictly prefix-shaped (radix longest-prefix + byte-identical PrefixDigest share gate); it has nothing analogous to CacheBlend's ~15%-recompute reuse of non-prefix RAG chunks. For a kernel whose entire thesis is KV reuse, cross-document/non-prefix reuse is an adjacent capability worth measuring, not an out-of-scope axis.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "kv-offloading-tiered-capacity",
      "dim_id": "kv-offloading-tiered-capacity",
      "axis": "KV-cache offloading to CPU/host/NVMe/remote (multi-tier hierarchy depth)",
      "category": "kv-cache",
      "competitor": "LMCache; Mooncake (Mooncake Store)",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://github.com/lmcache/lmcache (2026-01)",
      "fak_value": null,
      "unit": "x access bandwidth / capacity multiple",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "in-flight",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "CLAIMS line 142: internal/cachemeta models HBM->DRAM->CXL/NUMA-far->Disk tiers with per-tier TTL, demote-not-evict, and a hardware-cost-driven PlanPlacement; cmd/hwcachedemo is deterministic (28000 prefill tokens saved by demoting vs blind LRU). Explicitly the payload-free POLICY plane: cachemeta touches no bytes; physical movement is left to an engine adapter.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE as a measured head-to-head, though the policy plane is shipped. fak models a multi-tier hierarchy (incl. CXL/NUMA-far) and decides demote-vs-evict, but it moves no KV bytes and has no access-bandwidth or capacity-multiple number against LMCache's claimed ~7x faster CPU access / ~100x capacity or Mooncake's pooled store. The demote demo's '28000 tokens saved' is vs blind LRU on its own engine, not a cross-tier bandwidth comparison.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "kv-compression-eviction",
      "dim_id": "kv-compression-eviction",
      "axis": "KV compression / token eviction under a fixed cache budget",
      "category": "kv-cache",
      "competitor": "H2O; StreamingLLM; SnapKV; Quest",
      "competitor_class": "tuned",
      "competitor_value": null,
      "competitor_source": "https://arxiv.org/pdf/2406.10774 (2024-06)",
      "fak_value": null,
      "unit": "quality @ token budget",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "CLAIMS line 85/87/93: KVCache.Evict and the quarantine-evict bridge are bit-EXACT (evicted == never-saw, max|Δ|=0), and internal/radixkv EvictNode adds policy-driven span eviction over LRU. But every fak eviction is exact/lossless removal of a chosen span, not lossy compression of a retained cache under a fixed budget; no quality-vs-budget curve is measured.",
      "apples_to_apples": false,
      "comparison_note": "REAL GAP on the lossy-compression axis. fak does provable EXACT eviction (the deletion-cert / quarantine-evict story, a containment strength), not budget-bounded token-dropping that trades quality like H2O/SnapKV/Quest. There is no fak accuracy-at-256/1024-token-budget number, so no parity/lead is claimed; the H2O-class quality-under-budget question is unmeasured for fak. (correctness-oracle reasoning: where fak IS exact-vs-oracle it is parity, but that is on eviction equivalence, not on this compression-quality dimension.)",
      "measured_on": "2026-06-23"
    },
    {
      "id": "kv-transfer-disaggregation",
      "dim_id": "kv-transfer-disaggregation",
      "axis": "KV-cache transfer for prefill/decode disaggregation (NIXL / NCCL / UCX)",
      "category": "kv-cache",
      "competitor": "NVIDIA NIXL; NVIDIA Dynamo; Mooncake",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://developer.nvidia.com/blog/enhancing-distributed-inference-performance-with-the-nvidia-inference-transfer-library/ (2025-04)",
      "fak_value": null,
      "unit": "TTFT inflation / transfer bandwidth",
      "higher_is_better": true,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "No prefill/decode disaggregation or NIXL/NCCL/UCX KV transfer in CLAIMS.md. cachemeta emits KVTransfer offload/restore DIRECTIVES (line 142) and a coherence bus broadcasts refutations (BENCHMARK-AUTHORITY causal-invalidation row), but no cross-GPU KV transport, no layerwise overlap, no measured transfer bandwidth or TTFT-inflation figure.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE for a single-process reuse kernel. fak has no prefill/decode disaggregation and moves no KV over the wire; the KVTransfer directives are policy-plane intents consumed by an external adapter. It claims nothing against NIXL/Dynamo point-to-point RDMA transfer or layerwise overlap.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "kv-cache-aware-routing",
      "dim_id": "kv-cache-aware-routing",
      "axis": "KV-cache-aware / prefix-aware request routing across a fleet",
      "category": "kv-cache",
      "competitor": "NVIDIA Dynamo (KV-aware router); SGLang router; Baseten",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_range": [
        50,
        99
      ],
      "competitor_source": "Baseten-on-Dynamo 0.89 cross-replica cache hit across 4 replicas (https://www.baseten.co/blog/how-baseten-achieved-2x-faster-inference-with-nvidia-dynamo/, 2025-01); SGLang RadixAttention published 50-99% hit-rate band (arXiv:2312.07104, NeurIPS 2024).",
      "fak_value": 93.97,
      "unit": "% cross-replica prefix-KV cache-hit",
      "higher_is_better": true,
      "verdict": "parity",
      "status": "shipped",
      "fak_commit": "",
      "fak_artifact": "experiments/kv-fleet-routing/kv-fleet-routing-hitrate-20260627.json",
      "fak_doc": "internal/gateway/kv_fleet_routing.go (MeasureKVAwareFleetRouting) witnessed by TestKVAwareFleetRoutingHitRate; artifact kv-fleet-routing-hitrate-20260627.json (verify kv_aware_locality.hit_rate=0.9396551724137931). Composes the on-instance kv-hit-rate recovery (FCFS 62.1% -> 86.7%) + the coherence bus into a cross-GPU residency router.",
      "apples_to_apples": false,
      "comparison_note": "Closed at the fleet axis. fak previously had cache-aware SCHEDULING within one kernel instance + a coherence bus but no cross-GPU request-to-cached-block ROUTER; gateway.FleetCacheRouter now scores prefix residency across instances to pick the worker already holding the prefix (the Dynamo Smart Router pattern). WITNESSED number: 93.97% cross-instance prefix-KV hit rate on a Zipf-skewed shared-prefix agent fleet, a +10.4% lift over the cache-blind round-robin gateway.ReplicaRouter does today (85.13%) -> the fleet analogue of the on-instance 86.7%. Sits inside the published cross-replica cache-hit band (50-99%) and clears Baseten-on-Dynamo's 0.89 -> parity. FENCE: this is the routing-DECISION hit rate from a deterministic host-free simulation (no GPUs) -> apples_to_apples=false (same metric class as Baseten's live cross-replica hit, different apparatus). The downstream wall-clock win those hits cause on real GPUs (Baseten -50% TTFT / +62% output tok/s; GORGO 2.5x median TTFT) is host-gated and NOT claimed by this number.",
      "measured_on": "2026-06-27",
      "verify": {
        "field": "kv_aware_locality.hit_rate",
        "expect": 0.9396551724137931,
        "tol": 1e-06
      }
    },
    {
      "id": "attention-arch-kv-footprint",
      "dim_id": "attention-arch-kv-footprint",
      "axis": "Attention architecture impact on KV footprint (MQA/GQA/MLA bytes-per-token)",
      "category": "kv-cache",
      "competitor": "DeepSeek-V2/V3 (MLA); GQA-based models (Llama-3, Qwen)",
      "competitor_class": "sota",
      "competitor_value": 70,
      "competitor_source": "https://arxiv.org/html/2502.14837v1 (2025-02)",
      "fak_value": null,
      "unit": "KB/token KV footprint",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "CLAIMS line 146: fak's CUDA flash-attention is correct for MHA/GQA/MQA (cosine=1.0) and line 147 serves GLM-5.2's DSA attention (dense path pure-GPU, sparse DSA still host-side). fak SERVES these architectures faithfully but measures no bytes-per-token KV footprint and ships no MLA-style footprint reduction of its own.",
      "apples_to_apples": false,
      "comparison_note": "OUT OF SCOPE. KV footprint per token is a MODEL-architecture property (MLA vs GQA), and fak is a serving kernel, not a model designer; it faithfully serves whatever attention shape the checkpoint defines (MHA/GQA/MQA argmax-exact, GLM-5.2 DSA dense path on-GPU via the in-kernel GLM-5.2 / DeepSeek-class work, #1010 / #1026) but claims no KB/token figure against DeepSeek MLA's ~70 KB/token (the v6.0 / DeepSeek-R1 reference attention). Analogous to the swebench-resolve-rate fence: the kernel inherits, it does not set, this number.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "kv-cache-quantization-accuracy",
      "dim_id": "kv-cache-quantization-accuracy",
      "axis": "KV-cache quantization (FP8 / INT8 / KIVI sub-4-bit) accuracy at long context",
      "category": "kv-cache",
      "competitor": "vLLM (--kv-cache-dtype fp8, E4M3); KIVI (2-bit asymmetric); KVTuner (mixed-precision); KVQuant",
      "competitor_class": "sota",
      "competitor_value": null,
      "competitor_source": "https://vllm-project.github.io/2026/04/22/fp8-kvcache.html (2026-04)",
      "fak_value": null,
      "unit": "accuracy-point loss at long context",
      "higher_is_better": false,
      "verdict": "no-claim",
      "status": "stub",
      "fak_commit": "",
      "fak_artifact": "",
      "fak_doc": "none for KV QUANTIZATION accuracy — fak's KV cache is a kernel-owned f32 structure; its KV claims are bit-exact eviction (max|Δ|=0, KV-quarantine bridge) and radix prefix reuse, NOT a quantized (FP8/INT8/KIVI) KV cache with a long-context accuracy study",
      "apples_to_apples": true,
      "comparison_note": "REAL GAP fak should be aware of, but currently OUT OF SCOPE. fak owns its KV cache (that IS the reuse/eviction moat) but stores it at f32 — there is no FP8/INT8/sub-4-bit KV quantization and therefore no long-context accuracy-retention number. fak's adjacent KV claims (bit-exact Evict/quarantine, 86.7% radix hit-rate) are reuse/correctness properties on an UNQUANTIZED cache, not KV-quant accuracy, so no parity is implied. KV quantization is the natural lever a serving-stack-facing fak would eventually measure.",
      "measured_on": "2026-06-23"
    },
    {
      "id": "cross-request-prefix-cache-reuse",
      "dim_id": "cross-request-prefix-cache-reuse",
      "axis": "Automatic cross-request prefix / KV-cache reuse (shared system prompts, agent scaffolds, few-shot)",
      "category": "kv-cache",
      "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": "BENCHMARK-AUTHORITY.md RadixAttention ladder; experiments/radixattention/radixbench-qwen2.5-1.5b-q8-agents-fresh-20260619.json (commit 92896a4); CLAIMS.md 'RadixAttention parity vs SGLang' [SHIPPED]",
      "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
      }
    }
  ]
}