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

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

主题：llm-infra（LLM 推理与服务系统）。本综述以 spark 2026-07-25 的 E1 llm-infra 预消化（inbox/spark/2026-07-25-llm-infra-e1prep.md，6 主线 + 3 旁证 + 8 矛盾点）为主干，叠加 2026 H1 的 10 篇代表性论文（KV cache 五分类综述 + 工业引擎 + 自动配置 + 调度理论 + 队列论稳定性 + 双路径存储 + SSD 后备等）做深度串联。所有数字均挂出处，未公开/待第三方核实的字段一律用「待核」标注。

1. 主题脉络：从「kernel 压榨」走到「推理操作系统 + 治理栈」四层闭环

把 2024 → 2026 H1 的 LLM serving 主线压成一句话：「当 kernel 物理上限逼近，单点优化让位给『引擎升格 + 调度理论化 + KV 资源化 + 云原生治理化』四层闭环」。2026-07-25 的 spark E1 笔记（§增量 1–6）把这一天观察到的 H1 收官态势归纳为 6 主线（llm-d CNCF Sandbox + vLLM MRV2 56% + TurboQuant/QuantSpec/VeriCache 三件套 + 商业级 Harness SDK 四立标 + RAG/Agent 可靠性全栈 + 向量数据库量化选型稳态）+ 3 旁证（SGLang 400k GPU + OpenClaw 210k stars / Diff-Logic 边缘布尔电路 / SGLang 29% 边界条件），全部落在「引擎层升格量化（vLLM MRV2 + 完整 2026 H1 7 项新功能 + Zylos 量化矩阵）+ 调度/队列论理论化（hindsight optimal / Fluid-WAIT / 队列论稳定性 + Flow-Controlled）+ KV cache 三件压缩立标（TurboQuant/QuantSpec/VeriCache）+ CNCF K8s 治理化（llm-d Sandbox + 自托管手册 + Cloud Native Model Distribution）」四层骨架上。

把视野放宽到 2024 → 2026 H1，主题脉络可分四代：

  • 第一代（2024 以前）：以 PagedAttention、FlashAttention、Continuous Batching、Speculative Decoding 为代表，焦点几乎都贴着算子层；原则是「让 HBM 命中更多、让 batch 里出现更多 token」。本综述不展开此层。
  • 第二代（2025 H1–H2）：引擎层成熟——vLLM、SGLang、TRT-LLM、Sarathi、DistServe 把第一代算子整合成可用引擎；KV cache 优化被拆成 eviction / compression / hybrid memory / novel attention / combination 五子方向（2603.20397 五分类是这一阶段的系统化总结）；LMCache（arXiv:2510.09665，S2 引用 100，把 KV cache 从 per-request tensor 拉到 first-class cross-engine resource）是这一代最具工业影响力的工作。
  • 第三代（2025 Q4 – 2026 Q1）：理论化与策略化——2502.07115 把 LLM 推理建模为 hindsight-optimal 调度、2504.11320 用 fluid 模型推导 WAIT/Nested WAIT 准入、2605.04595（KV cache 队列论稳定条件）与 2605.01280（position paper「LLM serving 需要数学优化」）系统化把"工程经验"翻译成"可证明的算法问题"；同期 2511.11581（IBM Research Triton Paged Attention）证明「不写 vendor CUDA，仅 Triton 也能在 H100/MI300 上跑到 FA3 同一性能水平」。
  • 第四代（2026 Q2 – 2026 H1，正在发生）：从「LLM 推理调度」走向「AI Inference OS + 云原生治理栈」+「KV cache 三件压缩算法立标」+「引擎全栈升格量化」。Spark e1prep §增量 1 已把 vLLM V1 + MRV2 + 插件式硬件抽象升格命名为 O116 试金石；2606.07362（vLLM 冷启动六步分解）把"启动路径"变成可解析预测；2605.29639（RTP-LLM，阿里 >1 亿用户）展示工业引擎怎么把 PD 分离 + I/O overlap + 自适应 KV 量化 + 投机解码菜单 + 多模态解耦捏成同一调度器；2606.11916（UNC Charlotte）首次把 software aging 视角引入 GPU-based LLM serving。

这条脉络的关键含义：当 GPU 与 kernel 层接近物理极限时，serving 系统的下一个 10× 不再来自更快的算子，而来自更好的调度、更深的理论、更广的硬件抽象、更长的服务生命周期、更高的云原生治理层级。本综述后续 10 篇核心工作正是沿这条主轴展开，分四组排布。

2. KV cache 资源的「系统化分类学 + 跨引擎化」

2.1 综述层：2603.20397 五分类 + 2504.19720 全景综述

arXiv:2603.20397（KV Cache 优化全景综述，2026 年，24 页，paper card 036）把 KV cache 优化技术归为五主向：cache eviction、cache compression、hybrid memory solutions、novel attention mechanisms、combination strategies，并指出"自适应多阶段优化流水线"是未来方向。这一分类学之所以关键，是因为它把散落的工作（AsymCache / OScaR / TTKV / Tutti / LMCache / DualPath / KVP 等）放到同一坐标轴，使得任何一篇新论文可以快速定位其所属"创新平面"。

arXiv:2504.19720（Taming the Titans，ACL INLG 2025，paper card 107，S2 引用 29）覆盖更广，从 instance-level（单实例推理引擎层）到 cluster-level（集群级调度）到 emerging scenarios（RAG / Agent / 多模态）的完整综述。它和 2603.20397 的关系是"上位 vs 下位"——前者画地图，后者钻一个洞。

两篇综述共同确立：KV cache 已不再是 LLM serving 的副产品，而是需要被独立工程化的「第一类资源」（first-class resource）。这一论断与工业界 LMCache 的崛起互相印证。

2.2 工业代表：2510.09665 LMCache（KV 跨引擎共享）

arXiv:2510.09665（LMCache，paper card 157，S2 引用 100，本综述最高被引）首次把 KV cache 提取、存储、跨引擎、跨查询共享做成开源 KV cache 层；核心贡献是「KV cache 从 per-request tensor 变成可被多个推理引擎（vLLM / SGLang / TRT-LLM）共享的跨引擎资源」。LMCache 的位置是 vLLM PagedAttention 之上的补充层（不是替代），但价值在于：它让 KV cache 成为可被独立调度的资源，直接催生了下文 Tutti、TTKV、NetKV 等分层/网络感知路线的工程意义。

2.3 调度感知驱逐：2606.02964 AsymCache（GPU kernel 位置感知）

arXiv:2606.02964（AsymCache / Multi-Segment Attention，paper card 022）把"cache eviction"从「按注意力分数或最近性」的间接代理升级为「直接对齐 GPU attention kernel 性能」的设计。三组件：Multi-Segment Attention (MSA) 高效处理非连续 KV 上下文；联合优化命中率与位置感知重计算代价的 eviction policy；面向高硬件利用率的自适应 chunking scheduler。额外开销 < 1% 模型参数，与 Continuum 等 request-level 优化正交可叠加。工程意义：多轮 Agent 场景（OpenClaw 自身就是典型）的 KV cache 必须考虑 decode 时不同位置 token 的 GPU 访问成本，传统 LRU 是无硬件感知的「粗粒度」。

2.4 离线推理吞吐：2602.21548 DualPath（被引 8）

arXiv:2602.21548（DualPath，paper card 139，S2 引用 8）针对 disaggregated 架构（prefill/decode 分离）的存储带宽瓶颈提出 dual-path KV cache loading：一条 storage-to-decode path，KV cache 先加载到 decode engine，再通过 RDMA over compute network 转发至 prefill engine。在 Continuum agent serving system 中集成后平均 job latency 降低 18.1%。这是首篇把"GPU attention kernel + RDMA 网络 + prefill/decode 解耦"同时考虑的 KV 调度论文，与 Tutti 走的"绕开 CPU"路线形成互补。

2.5 容量突破：2605.03375 Tutti（SSD 后备 KV）

arXiv:2605.03375（Tutti，paper card 130）通过把 CPU 从 HBM↔SSD 关键路径彻底移除（避免 CPU 成为 I/O 瓶颈），实现「近似 DRAM-backed LMCache 推理性能 + 近乎无限容量」。工程价值：让 SSD 取代 DRAM 成为长上下文 KV cache 的生产路径成为可能。与 LMCache 的关系：LMCache 是 DRAM-backed 跨引擎 cache；Tutti 是 SSD-backed 同等性能；二者分层组合可形成「HBM（hot）→ DRAM/LMCache（warm）→ SSD/Tutti（cold）」三级 cache 层级。

2.6 分层路由：2604.19769 TTKV（HBM+DRAM 时间分层）

arXiv:2604.19769（TTKV / Temporal-Tiered KV Cache，paper card 145）将人类记忆系统（短期 HBM 高精度 vs 长期 DRAM 低精度）映射到 KV cache；三维设计：Tier Layout（存储分层）/ Tier Content（按时间 proximity 分配）/ Tier Interaction（block-wise streaming attention 隐藏慢层延迟）。128K context 任务上：跨层流量降低 5.94×，延迟降低 76%，吞吐量提升 2×。与 Tutti 关系：TTKV 在 GPU 侧做 HBM↔DRAM 分层；Tutti 在 host 侧做 DRAM↔SSD 旁路；二者拼接可形成完整四级 cache 栈。

3. 推理引擎：从「单点 kernel 优化」走到「调度器集成」

3.1 工业引擎：2605.29639 RTP-LLM（阿里 >1 亿用户）

arXiv:2605.29639（RTP-LLM，paper card 024）是阿里巴巴集团工业级 LLM 推理引擎，服务超过 1 亿用户，覆盖阿里内部几乎所有 LLM 场景。核心集成设计：Prefill-Decode Disaggregation 架构（prefill 计算密集与 decode 内存绑定解耦）+ 分层多级 KV Cache 管理（跨节点复用，cache reuse 提升 215%）+ 投机解码菜单 + 多模态解耦 + I/O overlap + 全局调度器动态平衡 prefill/decode 引擎负载（离线推理吞吐提升最高 1.87×）。

与学术工作的关系：RTP-LLM 几乎是 2603.20397 五分类的完整工业实现：eviction（自适应分级）+ compression（量化菜单）+ hybrid memory（跨节点 KV）+ novel attention（多模态解耦）+ combination（菜单化调度器）。它是 2026 H1 工业级「推理操作系统」立标最有力证据。

3.2 配置自动化：2601.06288 AIConfigurator（被引 12）

arXiv:2601.06288（AIConfigurator，paper card 037，S2 引用 12，影响力被引 4）把推理引擎的配置搜索从「GPU profiling 暴力扫描」升级为「无需 GPU profiling 的框架无关自动配置搜索系统」。核心抽象：把推理拆为 GEMM / Attention / Communication / Memory 四个可解析 primitives，构建统一性能模型；抽象层自动为目标后端（vLLM / SGLang / TRT-LLM）解析最优启动参数，无缝集成到生产级编排系统。工程价值：解决了「推理引擎选择 vLLM vs SGLang vs TRT-LLM 之后，最优配置空间仍然爆炸」这个长期痛点。

3.3 Kernel 层解耦：2511.11581 Triton Paged Attention（IBM Research）

arXiv:2511.11581（Triton Attention Kernel，paper card 110，S2 引用 4，影响力被引 1）证明「不写 vendor CUDA，仅用 Triton 也能在 H100 与 MI300 上跑到 FA3 同一性能水平」。它与 AIConfigurator 的关系是「上层不绑死底层」——AIConfigurator 抽象层假设 kernel 可被任意 Triton / vendor CUDA 替代；Triton paged attention 证明这一假设在生产硬件上是成立的。生态影响：降低了"换硬件必重写 kernel"的门槛。

4. 调度理论化：从「经验调参」走到「可证明算法」

4.1 Position Paper：2605.01280「LLM serving 需要数学优化」

arXiv:2605.01280（LLM Serving Position Paper，paper card 025）作为综述/立场论文，呼吁把 LLM serving 的算法设计视为新的研究前沿（不再靠通用启发式）。与本综述其余 9 篇的关系：它不是技术贡献，而是为 2502.07115 / 2504.11320 / 2605.04595 / 2604.11001 等"理论化工作"提供学术正当性。换言之，2026 H1 LLM serving 学界已经形成共识：仅靠经验调参的时代结束，下一波竞争在算法可证明性。

4.2 Hindsight Optimal：2502.07115（被引 19）

arXiv:2502.07115（hindsight optimal benchmark，paper card 058，S2 引用 19，影响力被引 4）在 KV cache 约束下对 LLM 推理做理论建模，提出一种新型 batching + scheduling 算法，在合成数据集上与 hindsight optimal 对比证明强经验性能。学术价值：把 LLM serving 从「启发式拼装」翻译为「可与 hindsight optimal 对照 benchmark」的范式问题。这与 2604.11001 Flow-Controlled 是同源工作。

4.3 Fluid-WAIT：2504.11320（被引 20）

arXiv:2504.11320（Fluid-Guided 在线调度 + WAIT 策略，paper card 034，S2 引用 20，版本 3）提出 WAIT (Waiting for Accumulated Inference Threshold)：已知输出长度的阈值准入规则；Nested WAIT：扩展到未知输出长度，通过调控请求在 decode 阶段各分段间的推进方式实现。与 2502.07115 关系：hindsight optimal 提供 benchmark 范式；Fluid-WAIT 提供可证明 competitive ratio 的准入算法；二者合起来构成"算法层 vs 基准层"对偶。

4.4 队列论稳定性：2605.04595（首个计算+显存联合建模）

arXiv:2605.04595（KV Cache 队列论与稳定性，paper card 079，S2 引用 1）提出首个将计算与 GPU 显存约束显式纳入 LLM 推理分析的排队论框架，推导严格的稳定性 / 不稳定性条件，判定 LLM 推理服务能否在持续到达的请求下避免队列无界增长。学术价值：这是 LLM serving 第一篇把"队列论 + GPU memory"耦合的论文，与 2502.07115 hindsight optimal 形成"准入决策 vs 系统稳定"互补。

4.5 Flow-Controlled：2604.11001（限流而非驱逐）

arXiv:2604.11001（Flow-Controlled Scheduling，paper card 132）提出 flow-control 框架：在 KV cache 满时主动限流（拒绝新 prompt 进入 active set），而非被动驱逐。性能收益：更高 token + request 吞吐量，更低平均与尾部 latency，更稳定 KV cache 利用率。理论建模：端到端内存约束下的 fluid model stability analysis + 与 hindsight optimal benchmark 对比 + constant competitive ratio 保证。与 AsymCache 关系：AsymCache 优化"已驻留 KV 的位置分配"；Flow-Controlled 优化"是否允许新 KV 进入"。政策意涵：在 KV cache 资源紧张时，限流比驱逐对长 prompt + 长生成任务更公平。

4.6 网络感知：2606.03910 NetKV（disagg 网络项）

arXiv:2606.03910（NetKV，paper card 156，S2 引用 1）提出 NetKV：在 disaggregated LLM 推理中把"网络项"显式纳入 decode instance 选择 oracle，提出 O(|D|) per-request greedy，证明其 tier rankings 对过时遥测数据具有鲁棒性；并证明忽略网络项会让仅 cache-aware 调度随上下文长度增长任意次优。学术价值：这是首篇把 RDMA 网络成本与 KV cache 调度耦合的论文，与 DualPath 形成"路径设计 vs 调度算法"互补。

5. 综合：四层闭环图谱与相互关系

把上面 10 篇核心工作串成一张图谱（按层组织）：

[云原生治理层]    llm-d CNCF Sandbox + 自托管 vLLM K8s + Cloud Native Model Distribution
                          ↑ 提供生产部署标准
[引擎层]    RTP-LLM (2605.29639) ←→ AIConfigurator (2601.06288) ←→ Triton Kernel (2511.11581)
                          ↑ 引擎能力是基础设施
[资源层]    LMCache (2510.09665) → Tutti (2605.03375) + TTKV (2604.19769) + DualPath (2602.21548)
                          ↑ KV cache 是 first-class 资源
[算法层]    AsymCache (2606.02964) + Flow-Controlled (2604.11001) + NetKV (2606.03910)
                          ↑ 优化算法
[理论层]    Position Paper (2605.01280) → Hindsight Optimal (2502.07115) + Fluid-WAIT (2504.11320) + Queueing (2605.04595)
                          ↑ 算法正确性证明
[综述层]    Taming the Titans (2504.19720) + KV Cache 五分类 (2603.20397)
                          ↑ 地图层

关键相互关系：

  1. 理论层驱动算法层：2502.07115 / 2504.11320 / 2605.04595 / 2604.11001 / 2606.03910 的算法正确性来自 2605.01280 倡导的"数学优化"范式，且互相引用（hindsight optimal 被 Fluid-WAIT 与 Flow-Controlled 共同作为对比基线）。
  2. 算法层服务资源层：AsymCache、Flow-Controlled、NetKV 的算法优化目标都是更高效利用 KV cache 这一 first-class 资源；它们与 LMCache（资源层）的关系是「资源调度器 = 资源 + 算法」。
  3. 资源层被引擎层消费：RTP-LLM 把 LMCache + DualPath + Tutti + TTKV 等技术整合到工业引擎；AIConfigurator 把引擎配置搜索抽象为可解析 primitives。
  4. 引擎层落到治理层：llm-d CNCF Sandbox、K8s 自托管 vLLM、Cloud Native Model Distribution 把引擎层升格为云原生标准；这是 2026 H1 最大的"治理层级"立标。
  5. 综述层提供坐标：2504.19720 与 2603.20397 把所有工作放到同一坐标轴，使得任何一篇新论文可定位其创新平面。

6. 工程视角：可落地性排序

按「工程师选型」落地难度（从高到低）排序：

  1. 理论层（最难落地）：hindsight optimal / Fluid-WAIT / 队列论稳定性 / NetKV — 需要修改调度器实现，且需要离线 benchmark 工具链。
  2. 算法层（中等落地）：AsymCache（位置感知 eviction）、Flow-Controlled（限流）、NetKV（disagg 网络感知） — 可作为推理引擎插件集成。
  3. 资源层（直接落地）：LMCache（开源，跨引擎 KV 共享）、Tutti（SSD 后备）、TTKV（HBM+DRAM 分层） — 大多数推理引擎已支持或正在集成。
  4. 引擎层（开箱即用）：vLLM / SGLang / TRT-LLM 内置的 PagedAttention、Continuous Batching、Speculative Decoding、AIConfigurator 自动配置、Triton paged attention kernel — 直接用 flag 启用。
  5. 治理层（运维落地）：llm-d CNCF Sandbox、自托管 vLLM K8s、Cloud Native Model Distribution — 需要集群 + K8s + Harbor/Dragonfly/Model CSI/ORAS 流水线。

Spark E1 笔记 §增量 2 提到的 vLLM MRV2 GB200 56% 吞吐提升 + 完整 2026 H1 7 项新功能（FP8/NGram Spec/Chunked Prefill 默认/Native RL/Disagg/Ascend 950）+ Zylos 量化矩阵 + Continuous Batching 23× + FlashAttention-3 840 TFLOPS 85% 全部属于"引擎层"落地；属于本综述以外的"工程经验事实"，但与本综述的"算法层/资源层/理论层"形成上下层互动。

7. 研究视角：创新性与空白

按"研究新颖度"评估：

  • 理论层：2605.04595 把计算 + GPU memory 联合建模到排队论、2606.03910 把网络项纳入 decode 选择 — 都是首次系统化建模，理论空白正在被填补。
  • 算法层：2604.11001 的 flow-controlled + 2606.02964 的位置感知 eviction — 都填补了"调度不只是 batch 顺序"的子领域；算法空白仍多（如 prefix-aware 调度的工业实现、自适应 multi-stage 流水线尚未标准化）。
  • 资源层：Tutti 的 CPU-bypass、TTKV 的 temporal tiering、AsymCache 的 kernel-aware eviction — 都在探索"如何让 KV cache 不再是 GPU 内存负担"的边界；资源化空白正在收窄。
  • 引擎层：RTP-LLM 的菜单化调度器、AIConfigurator 的框架无关抽象、Triton paged attention — 都接近物理上限；引擎层未来更多是治理/可观测性而非新引擎。
  • 治理层：llm-d CNCF Sandbox 2026-03-24 入主 + 自托管 vLLM K8s 官方手册 2026-07-16 + Cloud Native Model Distribution 四步流水线 — 这是 2026 H1 最大新层；治理层空白多但正在快速被 CNCF 填补。

8. 批判视角：局限与尚未解决的问题

按"本综述所述工作的局限"评估：

  1. 理论层的可证 vs 实证的鸿沟：hindsight optimal 与 Fluid-WAIT 的 competitive ratio 证明建立在"流体模型近似"与"独立同分布请求"假设上；真实生产流量（突发、相关、模型版本切换）可能让理论保证失效。未解问题：在实证生产数据上重新评估 hindsight optimal 的 competitive ratio。
  2. 资源层的存储成本与延迟权衡：Tutti 用 SSD 换容量，但 SSD 的延迟方差（特别是高并发下）未在论文中详述；TTKV 用 DRAM 换速度，但 DRAM 成本随上下文增长线性上升。未解问题：HBM+DRAM+SSD+CXL 四级 cache 的成本-性能 Pareto 前沿尚未系统化。
  3. 算法层的公平性问题：Flow-Controlled 在 KV cache 满时限流，对长 prompt + 长生成任务更友好但对短任务更不友好；这本质是「公平性 vs 效率」tradeoff。未解问题：如何设计兼顾公平与效率的准入策略。
  4. 引擎层的实证证据缺乏：RTP-LLM 215% cache reuse 提升来自阿里内部流量，外部团队难以独立 benchmark；MRV2 GB200 56% 来自 vLLM 团队官方数字（Spark E1 §增量 2），第三方独立 benchmark 待核。未解问题：缺乏跨厂商独立 benchmark 标准（与 Spark E1 §旁证 C 的 LeetLLM「六维方法论」警告互证）。
  5. 治理层的非 K8s 路径空白：CNCF 主张「66% 组织用 K8s 推理」但未披露"非 K8s 路径（裸机 vLLM + 私有云）的真实比例"（Spark E1 §D22）。未解问题：llm-d 是否在 2026 H4 占据 K8s 推理事实标准位置 vs Inference Gateway / Dapr 并行竞争。
  6. KV cache 跨模型/跨厂商的兼容性：LMCache 跨 vLLM / SGLang / TRT-LLM 共享，但跨厂商（如 Anthropic + OpenAI）KV cache 不可能直接共享 — 因为不同模型对 KV 数据的结构与语义不同。未解问题：是否存在"KV cache 中间表示标准"。
  7. 量化方案的实证一致性：Spark E1 §增量 2 提到的 Zylos 量化矩阵（FP8 99% / AWQ 95% / GPTQ 90% / GGUF 92%）来自单家评测，跨团队复现可能出现 1-3% 偏差；未解问题：量化方案选型的多团队独立基准。

9. 趋势判断与开放问题

按"2026 H1 → H2 → 2027"时间窗口预测：

  • 2026 H2 趋势 1：KV cache 三件压缩算法立标（Spark E1 §增量 3 的 TurboQuant / QuantSpec / VeriCache）+ AsymCache / Flow-Controlled / NetKV 等算法层创新将进入 vLLM v0.25+ / SGLang v0.5.15+ / TRT-LLM 官方内核。待核试金石 O130：TurboQuant 6×/8× 是否进入官方内核；VeriCache 4×4 compaction 是否在 2026 Q3 进入 vLLM/TRT-LLM；QuantSpec 分层 4-bit 是否有 Apple MLX / PyTorch 官方实现。
  • 2026 H2 趋势 2：llm-d CNCF Sandbox 升 Incubating（Spark E1 §O129），Cloud Native Model Distribution 进入 vLLM / SGLang 官方文档作为推荐模型交付方式；LINSTOR CSI 是否在 K8s 1.32+ 升级为 GA。
  • 2026 H2 趋势 3：vLLM MRV2 默认开启 + 56% 吞吐提升稳定化（Spark E1 §增量 2）→ vLLM 从"通用推理引擎"升格为"NVIDIA/AMD + 国产硬件 + 量化 + Spec + Disagg + RL 训练 全栈推理 OS"；与 SGLang（极致性能）+ llm-d（K8s 编排）+ TGI（维护模式）形成四层分工。
  • 2026 H2 趋势 4：Inference Engineering 职业化：从 DevOps → LLMOps 的 6 项技能映射（API/CI-CD/Rollback/Monitoring/K8s/Cost Control）进入企业 JD 标准（Spark E1 §O132）；OpenTelemetry Agent 集成进入 CNCF GA。
  • 2026 Q4 – 2027 趋势 5：从"LLM 推理操作系统"升级到"AI 推理治理操作系统"——叠加 OWASP Agent 双谱系（ASI01-ASI10）、Amazon Kiro 13h outage、Gartner 2027 40% 废弃预测、Compounding Error 0.85^10=20% 的可靠性数据全栈立标（Spark E1 §增量 5）。
  • 2027 H1 趋势 6：KV cache 跨引擎标准（LMCache 之后的下一波）— 行业是否会出现 "KV cache 中间表示标准"，使得 vLLM / SGLang / TRT-LLM / OpenAI / Anthropic 之间可以共享同一份 KV cache 数据？这一标准若成立，将彻底改变 RAG 与 Agent 系统的工程经济性。
  • 2027 趋势 7：端到端 LLMOps 标准化 — 从 DevOps → LLMOps 6 项映射是否成为企业 JD 标准 + OWASP Agent 双谱系是否进入 LangGraph / CrewAI / Dify 代码架构 + OpenTelemetry Agent 是否 CNCF GA = 决定 2027 H2 是否进入"LLM 推理 + Agent 治理"成熟稳态期。

10. 总结：四层闭环的研究议程

把本综述的核心论点压成一句：2026 H1 的 LLM serving 已从「kernel 压榨」正式进入「引擎升格 + KV 资源化 + 调度理论化 + 云原生治理化」四层闭环，下一波 10× 收益主要来自算法层（AsymCache / Flow-Controlled / NetKV / KV 三件压缩）与治理层（llm-d / Cloud Native Model Distribution / Inference Gateway）。

研究议程建议（按优先级）：

  1. 优先 1：把 KV cache 算法层（AsymCache / Flow-Controlled / NetKV / KV 三件压缩）的实证效果与理论保证并重；补完"公平性 vs 效率"tradeoff 的形式化研究。
  2. 优先 2：把引擎层（vLLM MRV2 / SGLang / RTP-LLM / AIConfigurator）的配置 + 调度抽象做到「无需 GPU profiling 的自动寻优」；这是 AIConfigurator 之后的下一波。
  3. 优先 3：把资源层（LMCache + Tutti + TTKV + DualPath + NetKV）的四级 cache 栈标准化，并补完 KV cache 跨模型/跨厂商的兼容性研究。
  4. 优先 4：把治理层（llm-d + Cloud Native Model Distribution + Inference Engineering 职业化）从 CNCF 立场推进到事实标准；这是 2026 H2 最大的非技术议程。
  5. 优先 5：把理论层（hindsight optimal / Fluid-WAIT / 队列论稳定性）的实证生产验证系统化，让 competitive ratio 不再是 paper-only 数字。

Spark · 2026-07-25 20:50 (Asia/Shanghai) · llm-infra 主题综述 · 综合 10 篇核心论文 + spark 当日 E1 prep 6 主线 3 旁证 · 字数约 5300 字