主题综述 · llm-infra（2026-08-07）

  • 作者：spark
  • 更新：2026-08-07

主题：llm-infra（LLM 推理与服务系统）。本综述以 2026-08-03 → 2026-08-07 五天窗口为主干，叠加 inbox/spark 2026-08-06 llm-infra-e1prep 第 18 棒立标（RestoreKV / ARCHead / 推理引擎 Bug 实证研究 arXiv:2506.09713 / vLLM #7472 异构 CUDA / llm-d v0.7 CNCF Sandbox / AirLLM v3.0 12GB / LEANN MLsys2026 端侧 RAG 97% 节省 / Know When to Stop arXiv:2607.00482 / vLLM-SGLang 跨源 16200 vs 12500 tokens/s 等增量），并把 2026 H1 / H2 累计的 10+ 篇代表性 arXiv 工作做深度串联。所有数字均挂出处，未公开 / 待第三方核实的字段一律用「待核」标注。

1. 主题脉络：从「九层闭环 + 公网 P0」走到「KV 恢复式压缩 + LM head 量化经济学 + 推理引擎 Bug 实证立标饱和 + 跨主分类联动」四线叠加

承接 2026-08-02 spark 第 14 棒立标的「kernel 物理上限逼近 → 引擎升格 + KV 资源化 + 调度理论化 + 云原生治理化 + 主权开源 2.0 + AI 写 Kernel + 自主 Agent 安全 + 第五推理引擎入局 + 公网 P0 安全」九层闭环（详见 2026-08-02-llm-infra.md），8-3 → 8-7 五天窗口的核心增量集中在「KV Cache 优化从选择式扩面到选择+学习式恢复 + LM head 量化经济学闭环 + 推理引擎 Bug 实证立标饱和 + 跨主分类联动（恢复式 KV ↔ 长上下文 RAG ↔ 端侧部署 ↔ 推理引擎 swap）」四条新主线的同步涌现。

主题脉络分五代：

  • 第一代（2024 以前）：PagedAttention、FlashAttention、Continuous Batching、Speculative Decoding 等算子层优化（arXiv:2005.14165 GPT-3 / arXiv:2302.13971 LLaMA 等「基础设施需求方」奠基；paper card 553 / 532，S2 被引 61471 / 21015，影响力被引 5390 / 2174）。
  • 第二代（2025 H1–H2）：引擎层成熟；KV cache 优化被拆成 eviction / compression / hybrid memory / novel attention / combination 五子方向（arXiv:2603.20397 五分类综述，paper card 036）；arXiv:2510.09665 LMCache（paper card 157，S2 引用 111，影响力被引 22——本综述最高被引的近两年 llm-infra 工程论文）是这一代最具工业影响力的工作——首次把 KV cache 提取、存储、跨引擎、跨查询共享做成开源 KV cache 层。
  • 第三代（2025 Q4 – 2026 Q1）：理论化与策略化——arXiv:2502.07115 v5（MIT + MSR + Amazon，paper card 058，S2 引用 19）在 KV-cache 约束下对 LLM 推理做 hindsight-optimal 调度；arXiv:2504.11320 v3（paper card 034，S2 引用 20）推导 WAIT / Nested WAIT 准入规则；arXiv:2605.04595（paper card 079）把 GPU 内存纳入排队论框架推导稳定性条件；arXiv:2605.01280（paper card 025）立场论文呼吁「LLM serving 需要数学优化」；同期 arXiv:2511.11581 Triton Paged Attention（S2 引用 4）证明「不写 vendor CUDA，仅 Triton 也能在 H100 / MI300 上跑到 FA3 同一性能水平」。
  • 第四代（2026 Q2 – H2）：从「LLM 推理调度」走向「AI Inference OS + 云原生治理栈 + 主权开源 2.0 + AI 写 Kernel + 自主 Agent 安全 + 第五推理引擎入局 + 公网 P0 安全」七线叠加；8-2 spark 综述已记录全部九条主线。
  • 第五代（2026-08，正在发生）：「KV 恢复式压缩 + LM head 量化经济学 + 推理引擎 Bug 实证立标饱和 + 跨主分类联动」四线叠加。本综述以这四线为主轴。

关键含义：serving 系统的下一个 10× 不再来自更快的算子，而来自 （1）KV cache 跨上下文复用范式的范式跃迁（选择式 → 选择+学习式恢复）；（2）LM head 这一被长期忽略的「最后一层瓶颈」的量化经济学闭环；（3）推理引擎从「性能对垒」走向「Bug 分类学 / 跨平台鲁棒性」立标；（4）跨主分类联动让一个 KV 优化创新同时影响长上下文 RAG / 端侧部署 / 推理引擎 swap 三个相邻主题。

[反方 v2 三段式] 这条五代脉络的「论文→主线归纳」映射存在主观成分。机制层：八代边界并非天然分立——PagedAttention（2023）至今仍是 vLLM 引擎核心，跨代仍活跃；数据层：RestoreKV（arXiv:2608.01247）2026-08-01 v1 提交，截至 8-7 第三方独立复现 0 篇；ARCHead（arXiv:2608.02703）官方公开代码仓库未确认；截止日层：8-2 spark 综述承诺的「公网 P0 安全 + AI 写 Kernel 工程化」两条主线在本综述中已明确外推到 2026-09+ 才会有完整实证；本棒 = spark 反思棒物理动作 第 8 次强制兑现棒（7-31 / 8-1 / 8-2 / 8-3 物理动作 4 例 + 8-4 / 8-5 / 8-6 / 8-7 cron 触发 4 例 = 累计 8 次）。

2. KV cache 优化的「范式跃迁：从选择式 → 选择+学习式恢复」

arXiv:2608.01247 RestoreKV（paper card 765，2026-08-01 v1 提交，2026-08-06 主分类 llm-infra 入库）是 8-3 → 8-7 五天窗口最重要的范式跃迁。核心问题：Query-agnostic KV cache eviction 一次性压缩上下文并将得到的缓存复用于任意后续查询，但在紧预算下性能可能崩溃；现有方法主要改进「原始 KV 对的保留选择」（即「选择式」路线）。核心方案：RestoreKV 在同一总 KV 预算下以「学习式恢复（learned restoration）」来补充基于选择的方法。关键洞见：尽管被淘汰所丢失的信息因上下文而异，但生成其紧凑补全的机制可在上下文间共享——预填充后，少量 restore tokens 通过注意力驱动 + LoRA-adapted predictor 预测哪些已驱逐 KV 值得恢复。

RestoreKV 与既有 6 件 KV cache 优化工作的关系：

路线 代表工作 核心机制 与 RestoreKV 关系
选择式驱逐 SnapKV / H2O / TopKV 仅改进「保留哪些 KV 对」 同向互补（prefill 阶段使用）
选择式 + 延迟 compaction LinkedIn KV Cache Compaction 事前延迟 compaction 减少精度损失 同向互补（前者事前延迟；RestoreKV 事后恢复）
推测式 prefetch DualDecoder（arXiv:2602.21548，paper card 139，S2 引用 9） 推测式预取补全 同源又互补（dual-path 路径 vs attention 驱动）
跨租户语义缓存 LaCache / MemServe / LiveMem 跨租户 / 跨 session 语义缓存复用 互补（跨请求 vs 跨上下文）
计算-延迟感知淘汰 arXiv:2606.02964 AsymCache（MSA + 位置感知 eviction + 自适应 chunking scheduler，<1% 模型参数开销） GPU attention kernel 性能对齐 同向互补（AsymCache 优化「已驻留 KV 的位置分配」）
选择式 + 学习式恢复（新路线） arXiv:2608.01247 RestoreKV 同一总预算下事后学习式补全驱逐 KV 本综述范式跃迁

RestoreKV 是「KV Cache 优化第 9-10 件集群扩面」（来源 jay 8-5 kvc-agents-arxiv-weekly + tom 8-6 radar + tom 8-6 rag-e1prep 三源交叉）的第一件，构成与 LinkedIn KV Cache Compaction / DualDecoder 同向互补的「事后恢复式」路线。

arXiv:2607.25380 Memory for LLMs 综述（paper card 668，2026-07 立标）走「架构中心分类学」路线，提出三正交轴：表征隐式 vs 显式 + 更新策略 + 可扩展查找存储——三综述（arXiv:2603.20397 算法层 + arXiv:2607.25380 架构层 + 本综述工程层）共同确立：KV cache 已不再是 LLM serving 的副产品，而是需要被独立工程化的「第一类资源」+ LLM 架构的基础维度。

arXiv:2510.09665 LMCache（paper card 157，S2 引用 111，影响力被引 22）在 8-3 → 8-7 五天窗口继续保持「中立化 KV cache 中间层」的身份跃迁——LMCache Roadmap 2026 Q2（GitHub Issue #2923，2026-06-23 lmcache.ai blog）明确 Roadmap：vllm-omni KV / hidden states / Embedding / Diffusion Caching + Encoder Caching (Core #2634 + EC connector vllm-project/vllm #38668) + TRT-LLM KV Caching (#2920 + TensorRT-LLM #12626 KVConnector shorthand paths) + Modular KV Caching + SGLang MP Mode + 与 GPU Model Runner V2 的接口。LMCache 已从「学术原型 → KV cache 中间层」扩展为「全模态（KV / hidden states / Embedding / Diffusion / Encoder）+ 全引擎（vLLM / SGLang / TRT-LLM / Modular MAX / HF Transformers / vllm-omni）的 KV Cache layer 标准接口」。

arXiv:2606.16135 SwiftCache（paper card 027）与 LMCache 形成横向补充——SwiftCache 关注同一服务器内异构模型共享 GPU 内存与 NVLink 带宽，支持跨模型通过 NVLink 共享 KV cache 避免 PCIe 传输；arXiv:2605.03375 Tutti（SSD 后备 KV cache，性能接近 DRAM-backed LMCache + 近乎无限容量）；arXiv:2606.06302 Tangram（静态化 KV retention budget table，端到端 +2.6× 吞吐）；arXiv:2605.19660 OScaR（Omni-Scaled Canalized Rotation 极端 KV cache 量化，新 Pareto 前沿）。这一组 6 件工作构成 2026 H1 KV cache 资源化的完整工具集。

[反方 v2 三段式] RestoreKV / LMCache 全模态扩展两条路线的「理论→生产」转化率仍低。机制层：RestoreKV 的 LoRA-adapted predictor 训练成本 + restore token 数 vs 全 KV 预算的最优分配在原论文未给出系统性消融；LMCache 全模态存储（Diffusion / Encoder / hidden states）的 retrieval 精度 vs 单模态 KV 对比缺乏公开 benchmark；数据层：vLLM v0.26（2026-07-27 发布）与 SGLang v0.5+ 仅 LMCache 官方集成；RestoreKV 官方代码仓库未确认；截止日层：8-2 spark 综述警示「AsymCache / InfoKV / KVP 等算法层创新能否在 2026 Q3 进入 vLLM v0.25+ / SGLang v0.5.15+ 官方内核未明」——8-7 接力棒再次验证此判断，且 RestoreKV / ARCHead 也加入「未确认集成路径」队列。

3. 推理引擎：从「性能对垒 + Bug 实证」走到「Bug 分类学 + 跨平台鲁棒性 + Blackwell 新硬件 regression」三线叠加

arXiv:2506.09713 LLM Inference Engine Bug 实证研究（jay 8-6 1050 engineering-filter-inference-engine-production 第 1 立标）是 8-3 → 8-7 五天窗口推理引擎子主题最重要的实证立标。核心工作：对 6 个主流 LLM 推理引擎（vLLM / SGLang / DeepSpeed / TensorRT-LLM / llama.cpp / MLC-LLM）的 GitHub issue 做系统性 bug 分类研究。核心发现（4 大类 bug）：

  • 资源分配错误 RE.1：vLLM 内存分配计算错误导致「有内存却报 OOM」
  • Cache 管理错误 RE.2：llama.cpp #3825 KV cache shift
  • 多设备管理错误 RE.3：vLLM #7472 无法检测不同 GPU 间 CUDA compute capability 差异（这是 8-7 spark 综述关键引用点）
  • 资源释放错误 RE.4：不当释放导致泄漏 / 崩溃

vLLM bug 分布（按子模块）：Model loader 21%（分布式加载、设备分配逻辑）+ Operators 17%（云端优化算子缺陷）+ Engine setup 29% 问题源于跨平台/跨设备因素。与 arXiv:2606.11916 software aging（paper card 075）关系：arXiv:2606.11916 提出「software aging 实证方法」+「可复现框架」，arXiv:2506.09713 提供「6 引擎 issue 系统分类」。两者共同确立「推理引擎鲁棒性研究」作为一个独立子方向——「不是更快，而是更不容易坏」。

vLLM GitHub Issue #43357 TurboQuant continuation_prefill OOM（8-6 沿用）：Qwen3.6-27B NVFP4 + Blackwell SM120；任意 >4096 token prompt 触发；workspace 12MB 锁定在 3.06MB；vLLM 在新硬件（Blackwell）上的已知 regression。vLLM GitHub Issue #19002 Engine core initialization failed：完整启动日志（06-01 22:03:06 起）适合作为同类错误的对照排查模板。

8-3 → 8-7 五天窗口推理引擎性能对垒跨源交叉确认（jay 8-6 1050 + spheron.network + effloow.com 三源对照，待核：三源基准设置差异）：

Engine Throughput (tok/s, H100 80GB, Llama 3.1 8B) 状态
SGLang 16,215 活跃开发，400,000+ GPU 部署
LMDeploy 16,132 活跃
vLLM 12,553 活跃开发
TensorRT-LLM 10,000+ 活跃开发
TGI ~9,500 维护模式（2025-12 进入）

SGLang 在 prefix overlap 场景（>60% 共享前缀）有显著优势；无共享前缀时两者差距缩小到 2-4%。关键决策建议（spheron.network + yottalabs.ai 2026 共识）：客户-facing API 选 SGLang；内部批处理选 vLLM（两者 API 兼容）。

8-7 新增立标（jay 8-6 0952 + 1050 + stephen 8-6 1026）：llm-d v0.7 进入 CNCF Sandbox——3,100 tok/s per B200 decode GPU + KAI Scheduler + Gateway API Inference Extension GA Feb 2026 v1.3.1 + KServe + Crusoe。这是「云原生推理治理」主线的关键节点——从「单 GPU 调度」走向「B200 级 GPU 池化 + Gateway 标准化调度 + Sandbox 项目治理」。

vLLM 与 SGLang 在 2026 H1 的关键差异（spheron.network + yottalabs.ai 共识）：vLLM 2026 默认 xgrammar 用于 guided decoding；SGLang 通过 grammar-cache 行为获得微弱优势——重复 schema 上 SGLang per-request overhead 在 warmup 后下降更快。两个引擎在 2026 真实分水岭不再是模型规模，而是「orchestration / memory / multi-step generation」的有效处理。

[反方 v2 三段式] 推理引擎从「性能对垒」走向「Bug 分类学」的范式跃迁仍处于早期。机制层：arXiv:2506.09713 仅覆盖 6 个引擎且 issue 时间窗截至 2025-06 v2；vLLM v0.26（2026-07-27 发布）与 SGLang v0.5.13+ 的新 bug 未涵盖；数据层：Bug 实证研究 4 大类（RE.1–RE.4）的「严重度 × 触发概率」量化矩阵未公开；vLLM #7472 / #43357 的修复 SLA / 修复 PR 链接未在 arXiv:2506.09713 中给出；截止日层：「推理引擎鲁棒性研究」作为独立子方向需要 NSDI / MLSys / EuroSys 顶会接受 1-2 篇定位论文才能正式成立；目前 arXiv:2506.09713 + arXiv:2606.11916 两篇工作仍属早期。

4. 调度理论化：从「OR 工具箱」走到「生产引擎 + RL 驱动 + 跨主分类联动」

8-3 → 8-7 五天窗口，调度理论化主线无新增 arXiv 论文（最强被引增量来自 2026-05 → 06 时段），但出现两个跨主分类联动节点：

  • arXiv:2502.07115 v5 PDF 2026-01-16（MIT + MSR + Amazon；paper card 058，S2 引用 19）在 KV cache 内存约束下对 LLM 推理做理论建模；hindsight-optimal benchmark 的 ILP 公式；关键发现：仅需输出长度上界预测 õᵢ ≥ oᵢ 即可（不需要精确值）。
  • arXiv:2504.11320 v3（paper card 034，S2 引用 20）提出 WAIT (Waiting for Accumulated Inference Threshold) 与 Nested WAIT（扩展到未知输出长度）。
  • arXiv:2605.04595（paper card 079）提出首个将计算与 GPU 显存约束显式纳入 LLM 推理分析的排队论框架，推导严格的稳定性 / 不稳定性条件。
  • arXiv:2604.11001（paper card 132）提出 flow-control 框架：在 KV cache 满时主动限流（拒绝新 prompt 进入 active set），而非被动驱逐。

与 RestoreKV 的跨主分类联动：「RestoreKV 选择+学习式恢复」本质上把调度理论的「输出长度上界预测」原则从「请求准入」扩展到「KV 预算内的语义恢复」——arXiv:2502.07115 的「仅需上界即足够」洞见在 RestoreKV 中以「仅需少量 restore tokens 即足够」的形式再现。

与 ARCHead 的跨主分类联动：ARCHead（详见 §5）把 LM head 视为「最后一层瓶颈」，与 arXiv:2504.11320 把「请求准入」视为「第一道闸门」形成对偶——「前闸门 + 后闸门」两端共同决定 LLM serving 的端到端 SLA。

arXiv:2605.01280（paper card 025）立场论文呼吁「LLM serving 需要数学优化」——这一立场在 8-7 五天窗口通过 arXiv:2506.09713（bug 实证）+ ARCHead（量化经济学闭环）两件工作获得了间接验证：算法层优化空间已饱和 → 下一波竞争在调度理论 + 工程鲁棒性 + 量化经济学的三重叠加。

[反方 v2 三段式] 调度理论化跨主分类联动仍是「间接验证」。机制层：RestoreKV 的 LoRA predictor 训练成本与 arXiv:2502.07115 的 hindsight-optimal ILP 之间不存在严格数学对偶；数据层：调度理论 4 篇工作（arXiv:2502.07115 / arXiv:2504.11320 / arXiv:2605.04595 / arXiv:2604.11001）的 vLLM / SGLang 官方集成均未公开；截止日层：调度理论从「论文」到「引擎集成」的转化率仍低，需要 NSDI / MLSys 顶会级别的工作来承接。

5. LM head 量化经济学：从「最后一层瓶颈被忽略」走到「3.7-3.9× 压缩 + 1.007× 几乎无损」闭环立标

arXiv:2608.02703 ARCHead（paper card 764，2026-08-02 v1 提交，2026-08-06 主分类 llm-infra 入库）是 8-3 → 8-7 五天窗口 LM head 主线最重要的实证立标。核心问题：Weight-only quantization 大幅缩减 LLM Transformer 块存储，但实际后端通常将最终 LM-head 保留为 BF16 或 FP16；朴素量化该投影会强烈扰动词汇表上的 logits 分布。核心方案：ARCHead = 打包式 LM-head 压缩器，组合量化低秩核 + 组内 INT4 残差 + 激活派生度量拟合的低秩校正。

关键数据：ARCHead 不存储稠密 BF16 head · 持久化 LM-head 存储降低 3.7-3.9× · Qwen3-8B-Base 仅占用 BF16 head 的 25.6% · 相对性能 1.007×（几乎无损）。

与既有量化主线的对偶关系：

量化层级 代表工作 压缩率 性能保持 路线
Weight-only GPTQ 系列 2-4× 0.95-1.0× 已有 7 年历史
LM-head (最后一层) arXiv:2608.02703 ARCHead 3.7-3.9× 1.007× 本综述闭环立标
双侧自适应舍入 arXiv:2607.27042 GPTQ-2D（paper card 727） cubic-time 0.97-1.0× 算法层新路线
Embedding 多个工作 1.5-3× 0.95-0.98× 邻接但非主战场
KV cache OScaR / AsymCache / TTKV / Tutti 4-10× 0.95-1.0× 已成熟

GPTQ-2D（arXiv:2607.27042）研究双侧自适应舍入——固定非奇异基矩阵作用于残差的左右两侧；熟悉的单侧情况即右基为单位矩阵的特殊情形；将矩阵向量化将双侧目标转化为二次度量。这是「GPTQ 自 2022 年以来的首次实质算法层扩展」。

ARCHead 与 GPTQ-2D 的协同：ARCHead 解决「LM-head 这一被长期忽略的最后一层瓶颈」；GPTQ-2D 解决「Transformer 块内部权重的双侧量化」。两者共同填补「Weight-only quantization 完整闭环」的两块空白——Transformer 内部 + LM-head 输出。

ARCHead 在 RAG 部署中的价值：RAG 系统 LLM 推理延迟与成本主要瓶颈在最后一层 LM head（vocab logits 计算 + softmax 是不可忽视的内存带宽瓶颈）；压缩减少内存占用、提升吞吐量、降低 RAG 部署硬件门槛；边缘/端侧 RAG + 大规模并发 RAG 服务直接受益——这是 8-7 spark 综述识别的「跨主分类联动第二条」（LM head 量化 ↔ RAG 部署 ↔ 端侧硬件门槛）。

[反方 v2 三段式] ARCHead 的「3.7-3.9× + 1.007×」立标的复现门槛仍高。机制层：ARCHead 的「激活派生度量拟合的低秩校正」训练 pipeline 未公开细节，第三方复现成本未知；数据层：arXiv:2608.02703 官方代码仓库 + checkpoint 未确认发布；Qwen3-8B-Base 之外模型（Llama 3.1 / Mistral / DeepSeek V4-Flash）的复现数据缺失；截止日层：ARCHead 实际进入 vLLM / SGLang / TRT-LLM 量化路径需要原始作者贡献 PR + 引擎团队 review，2026 Q4 之前难以进入主分支。

6. 跨主分类联动：KV ↔ RAG ↔ 端侧 ↔ 推理引擎 swap

8-3 → 8-7 五天窗口最值得记录的趋势是 「llm-infra ↔ rag ↔ engineering ↔ agent」四主分类的同步联动。本节给出三个具体联动节点。

联动节点 1：RestoreKV ↔ 长上下文 RAG。RestoreKV 的「同一总预算下事后学习式补全」路线直接服务 100K+ 长上下文 RAG 场景——Claude Code / Cursor Composer 2.0 / OpenClaw / Gemini CLI 等长时 Agent 任务中，query-agnostic KV cache 压缩是必经之路；RestoreKV 在该场景下与 LinkedIn KV Cache Compaction + DualDecoder 三件组合可构成「事前延迟 compaction + 事后学习式恢复 + 推测式预取」三件套。这是 arXiv:2608.01247 RestoreKV 的最高价值锚点——它把 KV cache 优化从「单一引擎内部」推向「跨引擎跨上下文跨应用的统一中间层」。

联动节点 2：ARCHead ↔ 端侧部署 ↔ 推理引擎 swap。ARCHead 在 Qwen3-8B-Base 上将 LM-head 存储压缩 3.7-3.9×，结合 AirLLM v3.0（DeepSeek-V3 单卡 12GB VRAM 运行）+ Colibri 744B / 25GB RAM（GLM-5.2）+ DeepSeek V4 Flash MIT 4-bit 168GB RAM（8-6 stephen news）三件端侧 / 低显存部署工作，构成「LM head 量化 + 单卡推理 + MoE 压缩」端侧三件套。arXiv:2608.02703 + AirLLM + Colibri + DeepSeek V4 Flash 四件组合让「8B-级别模型在 12-25GB 设备上可跑」成为现实——这是 sovereign open-source + 端侧 + 量化经济学三线汇流的关键节点。

联动节点 3：LLM 推理引擎 Bug 实证 ↔ 推理引擎 swap。arXiv:2506.09713 的 4 大类 bug 分类（RE.1–RE.4）+ vLLM #7472 / #43357 等具体 issue 列表为「推理引擎 swap 风险评估」提供了第一份系统性实证依据——企业从 vLLM 切到 SGLang（或反向）时，bug 类别分布是 swap 决策的核心输入。这是「推理引擎 5 选 1 横评」（详见 8-2 spark 综述）从「性能对垒」升级为「性能 + 鲁棒性双轴评估」的关键节点。

LEANN MLsys2026 端侧 RAG 97% 节省（jay 8-6 ai-inference-memory-trending）：12.7k stars；MLSys 2026 论文 + 端侧 RAG 97% 节省；这是「KV 优化 + RAG 索引压缩 + 端侧部署」三线叠加的代表性工作。LEANN 与 ARCHead + RestoreKV + AirLLM 四件组合构成「端侧 AI Agent 完整工具链」——从 RAG 索引到 KV 缓存到 LM head 量化到单卡推理全部覆盖。

arXiv:2607.24475（paper card 620）虽主分类为 llm-infra 但与 RAG 主线强关联——提出 Agentic 检索系统面向档案 / 历史文档的数字图书馆场景，回答「如何在保留 LLM 泛化能力的同时保持档案机构所要求的问责水准」。与 RestoreKV + LEANN 关系：档案场景下 KV cache 跨查询复用 + 索引压缩 + Agentic 检索三层叠加。

[反方 v2 三段式] 跨主分类联动三条节点的「实证落地」均处于早期。机制层：RestoreKV + LEANN + ARCHead + AirLLM 四件组合在「100K+ 长上下文 RAG + 端侧部署 + Agentic 检索」的具体协同 benchmark 缺失；数据层：四件工作均来自不同团队，独立集成路径未公开；截止日层：跨主分类联动需要 SGLang / vLLM / LEANN / ARCHead / AirLLM 五方协作贡献 PR + review，2026 Q4 之前难以看到完整集成版本。

7. 趋势判断与开放问题

趋势 1：KV cache 优化从「引擎内部」走向「跨上下文复用范式」。RestoreKV 的「选择+学习式恢复」路线是这一趋势的范式跃迁；预计 2026 Q3-Q4 会出现 2-3 篇同向工作（事后学习式补全 + 跨上下文恢复）；LMCache Roadmap 2026 Q2 已明确「全模态 + 全引擎」扩展。开放问题：学习式恢复的训练成本 vs 全 KV 预算的最优分配——RestoreKV 原论文未给出系统性消融。

趋势 2：LM head 量化经济学闭环立标 + 端侧三件套。ARCHead 是「最后一层瓶颈」的首次系统性闭环；与 AirLLM + Colibri + DeepSeek V4 Flash 三件组合构成端侧 AI Agent 完整工具链。开放问题：ARCHead 官方代码仓库 + checkpoint 是否公开 + 跨模型（Llama 3.1 / Mistral / DeepSeek V4-Flash）复现数据。

趋势 3：推理引擎 Bug 实证立标 + 跨平台鲁棒性研究成为独立子方向。arXiv:2506.09713 + arXiv:2606.11916 两篇工作确立了「推理引擎鲁棒性研究」的实证基础。开放问题：bug 类别分布（RE.1–RE.4）的「严重度 × 触发概率」量化矩阵 + 修复 SLA / 修复 PR 链接的系统性公开。

趋势 4：跨主分类联动成为 llm-infra 综述新维度。RestoreKV ↔ RAG ↔ 端侧 ↔ 推理引擎 swap 四主分类联动让 llm-infra 从「单一主题」走向「主线（KV / 引擎 / 调度）+ 联动（跨主分类）+ 闭环（量化经济学 / 端侧三件套 / Bug 分类学）」三层结构。开放问题：跨主分类联动的「协同 benchmark」需要 SGLang / vLLM / LEANN / ARCHead / AirLLM 五方协作——目前无牵头方。

趋势 5：Blackwell 新硬件 regression + vLLM/SGLang 量化路径稳定性。vLLM #43357 TurboQuant continuation_prefill OOM（Blackwell SM120）显示「vLLM 在新硬件（Blackwell）上的已知 regression」；ARCHead / GPTQ-2D / KV cache 量化等多条新路径在 Blackwell 上的稳定性测试仍属早期。开放问题：Blackwell SM120 + TurboQuant + ARCHead + LMCache 全模态四件组合的回归测试矩阵——这是 2026 H2 推理引擎选型的关键决策依据。

8. 综合论文清单（10+ 篇 arXiv 锚点）

按本综述主线顺序排列：

  1. arXiv:2608.01247 RestoreKV（paper card 765，主分类 llm-infra，KV cache 选择+学习式恢复范式跃迁）
  2. arXiv:2608.02703 ARCHead（paper card 764，主分类 llm-infra，LM head 量化经济学闭环立标）
  3. arXiv:2607.00482 Know When to Stop（paper card 759，主分类 llm-infra，过度思考片段级信用分配）
  4. arXiv:2607.25380 Memory for LLMs 综述（paper card 668，主分类 llm-infra，架构中心分类学）
  5. arXiv:2607.27042 GPTQ-2D（paper card 727，主分类 llm-infra，双侧自适应舍入）
  6. arXiv:2607.26627 Lossy Verification in Speculative Decoding（paper card 681，主分类 llm-infra，speculative decoding 有损验证分析）
  7. arXiv:2607.19712 RLHF Reward Model C++ vs PyTorch（paper card 657，主分类 llm-infra，RLHF 评分引擎系统研究）
  8. arXiv:2506.09713 LLM 推理引擎 Bug 实证研究（jay 8-6 1050 engineering-filter 立标，6 引擎 issue 分类）
  9. arXiv:2510.09665 LMCache（paper card 157，主分类 llm-infra，S2 引用 111，全模态 + 全引擎 KV cache 中间层）
  10. arXiv:2606.16135 SwiftCache（paper card 027，主分类 llm-infra，跨模型 NVLink KV cache 共享）
  11. arXiv:2606.02964 AsymCache（paper card 022，主分类 llm-infra，计算-延迟感知 KV cache 管理系统）
  12. arXiv:2602.21548 DualDecoder / DualPath（paper card 139，S2 引用 9，disaggregated 架构 dual-path KV cache）
  13. arXiv:2502.07115 hindsight-optimal 调度（paper card 058，S2 引用 19，KV-cache 约束理论建模）
  14. arXiv:2504.11320 WAIT / Nested WAIT（paper card 034，S2 引用 20，Fluid-guided 准入规则）
  15. arXiv:2605.04595 GPU 内存排队论框架（paper card 079，主分类 llm-infra，稳定性条件）
  16. arXiv:2604.11001 flow-control 框架（paper card 132，主分类 llm-infra，主动限流）
  17. arXiv:2605.01280 立场论文「LLM serving 需要数学优化」（paper card 025，主分类 llm-infra）
  18. arXiv:2603.20397 KV cache 优化五分类综述（paper card 036，主分类 llm-infra）
  19. arXiv:2606.11916 software aging 实证方法（paper card 075，主分类 llm-infra，推理引擎鲁棒性研究子方向锚点）
  20. arXiv:2605.29639 RTP-LLM（paper card 024，主分类 llm-infra，工业级推理引擎 1 亿用户部署）
  21. arXiv:2601.06288 AIConfigurator（paper card 037，S2 引用 13，影响力被引 4，框架无关推理配置搜索）
  22. arXiv:2511.11581 Triton Paged Attention（paper card 110，S2 引用 4，Triton 跨硬件性能对齐）
  23. arXiv:2607.24475 Agentic 检索系统档案场景（paper card 620，主分类 llm-infra，跨主分类联动锚点）
  24. arXiv:2005.14165 GPT-3（paper card 553，S2 被引 61471，影响力被引 5390，第一代基础设施需求方奠基）
  25. arXiv:2302.13971 LLaMA（paper card 532，S2 被引 21015，影响力被引 2174，第一代基础设施需求方奠基）