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

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

主题：llm-infra（LLM 推理与服务系统）。本文以 2026-07-17 → 2026-07-21 这一周的 spark e1prep、Jay 工程筛选、HF Blog / vLLM Roadmap 与少量外部 web 信号为主，叠加 2025-Q4 至 2026-Q2 的 5 篇代表性高引/锚点工作做深度综述。所有观点均挂出处，未公开数字一律用「未披露/待核」标注。

1. 主题脉络：从「单点 kernel」走到「策略-理论-系统」三层闭环

把 2024 → 2026 的 LLM serving 主线压成一句话，是 「压榨 kernel 的边际收益迅速衰减，焦点上移到调度策略、容量理论、跨引擎/跨硬件抽象」。spark 在 2026-07-20 21:00 给出的 llm-infra E1 预消化（inbox/spark/2026-07-20-llm-infra-e1prep.md §一）把这轮增量归纳为 7+1 条主线，全部落在「引擎层升格实证（vLLM V1 重写 + MRV2 + 插件式硬件抽象）+ 调度九学派补强（MLSys WukLab 调度开销实证）+ KV cache 五架构原型综述 + workflow-level 调度（SAGA）+ 生产 trace kernel 评测（Atrex-Bench）+ PD-Disagg MoE expert local 性（ELDR）+ Harness 五层微软实证 + 4 个 Agent CVE」八条主轴；本综述不重复这一预消化的全谱，只挑出「对位 2026 H2 综述文献主流线」最具骨架意义的 6 个工作串成主线，并以 2026-07-21 当日新增的 HF Blog 三件套与外部 web 信号（LongSpec、ISSTA 2026 SD on SE、FASER）作为补充。

把视野放宽到 2024 → 2026，主题脉络可画成四代演化：

  • 第一代（2024 年以前）：以 PagedAttention（vLLM）、FlashAttention、Continuous Batching、Speculative Decoding 为代表，焦点在「GPU kernel 与 CUDA 这一层」，文献几乎都贴着算子层；这一阶段的优化原则是「让 HBM 命中的次数变多、让 batch 里出现更多 token」。
  • 第二代（2025 H1–H2）：引擎层成熟——vLLM、SGLang、TensorRT-LLM、Sarathi、DistServe 把第一代算子整合成可用引擎；KV cache 优化被拆成 eviction / compression / hybrid memory / novel attention / combination 等子方向（2603.20397 的五分类是这一阶段的系统化总结）；LMCache（arXiv:2510.09665，S2 引用 98，把 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 需要数学优化」）系统化把"工程经验"翻译成"可证明的算法问题"。同期 Triton-based Paged Attention（2511.11581，IBM Research）证明「不用 vendor CUDA，仅用 Triton 也能在 H100/MI300 上跑到 FA3 的同一性能水平」。
  • 第四代（2026 Q2 – 2026 Q3，正在发生）：从「LLM 推理调度」走向「LLM 服务全栈操作系统」+「AI Inference OS」升格。Spark e1prep §增量 1 已经把 vLLM V1 重写 + 插件式硬件抽象的升格路径命名为 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× 不再来自更快的算子，而来自更好的调度、更深的理论、更广的硬件抽象、更长的服务生命周期。本综述后续 6 个工作正是沿这条主轴展开。

2. 核心 6 篇工作：贡献、关系与定位

按子方向分组列出（顺序按论文主线逻辑而非时间）。

2.1 KV cache 资源的「系统化分类学」：2603.20397 综述 + LMCache（2510.09665）

  • 2603.20397（KV Cache 优化全景综述）：24 页系统综述，把当前散落在文献里的 KV cache 优化技术归纳为五大方向（eviction / compression / hybrid memory / novel attention / combination），并把每条技术映射到 7 类实际部署场景，明确指出 不存在单一最优技术，自适应多阶段优化流水线是未来方向（来源：arXiv:2603.20397 abstract；promo/explainers/2603-20397.md §核心方法）。本文是 2026 H1 KV cache 优化的"地图"。
  • LMCache（arXiv:2510.09665）：首个开源、生产级 KV cache offloading 方案，把 KV cache 从 GPU 显存中提取出来跨 CPU / 存储 / 网络层级存储和共享，同时支持 prefix 复用与 prefill-decode（PD）disaggregation，在多轮 QA、文档分析等场景下与 vLLM 组合 吞吐最高提升 15×（来源：arXiv:2510.09665 abstract；promo/explainers/2510-09665.md §一句话结论；paper_cards/157-2510-09665.md S2 引用 98，KB 最高被引 llm-infra 论文）。LMCache 的工程意义不只在 15× 加速，而在于 把 KV cache 从 per-request temporary tensor 提升为 first-class cross-engine memory object，让跨引擎 / 跨实例 prefix 复用成为可能。
  • 两者关系：2603.20397 是「理论分类学」，LMCache 是「工业系统落地」。Spark e1prep §增量 3 给出的 KV cache 管理综述（arXiv:2607.02574，30+ 系统按 locality / lifetime / ownership / substrate 四维度分 5 大架构原型：local-paged / disaggregated-pipeline / shared-store / memory-pool / hybrid-tier）则把这两者缝合到一张更大的地图上；这一综述明确把 KV cache 定义为 first-class memory object，与 LMCache 的工程理念同频。

2.2 调度理论化三件套：2502.07115 + 2504.11320 + 2605.04595 + 2605.01280

  • 2502.07115（hindsight optimal benchmark + 在线算法）：在 KV cache 内存约束下提出 后视最优基准——把"假设能看穿未来"形式化为整数规划——然后证明确定性在线算法无法达到常数竞争比，并给出 多项式时间在线调度算法，在合成和真实数据集上都明显优于 vLLM 等基线（来源：arXiv:2502.07115 abstract；promo/explainers/2502-07115.md §一句话结论）。本文是「调度理论化」的第一枪。
  • 2504.11320（Fluid-Guided 在线调度 / WAIT）：把 LLM 推理建模为多阶段在线调度问题（内存随生成长大），用 fluid 模型刻画稳定域，推导出阈值型准入规则 WAIT / Nested WAIT，在 Llama-2-7B + A100 的 Vidur 仿真里显著扩大稳定工作区间，并在近饱和/过载区把延迟打下来；论文指出服务方日成本可达 \$700,000 级（来源：arXiv:2504.11320 abstract；promo/explainers/2504-11320.md §一句话结论）。本文是「OR 工具箱对接 LLM serving」的第一个工程级证据。
  • 2605.04595（KV cache 队列论稳定性分析）：首个把 GPU 内存显式纳入排队论框架 的工作，给出 LLM 推理"稳定服务率"的闭式条件 μ_eff(M_max)。论文的稳定条件在生产集群的预测偏差 <10%（来源：paper_cards/079-2605-04595.md TLDR；surveys/2026-W28-llm-inference-serving.md §3.2）。本文是 2605.01280 主张"理论化 serving"落下的第一个工程级钉子。
  • 2605.01280（Position Paper：LLM serving 需要数学优化）：立场论文，认为 LLM serving 已超越通用启发式方法的极限，呼吁社区将 LLM serving 的算法设计视为一个新的研究前沿，对接 OR / 排队论 / 在线算法工具箱（来源：paper_cards/025-2605-01280.md TLDR）。
  • 四者关系：2502.07115 与 2504.11320 是「理论 + 算法」对位（一个证明常数竞争比不可达、一个给 fluid-guided 准入规则）；2605.01280 是「路线图」、2605.04595 是「案例」。这一四件套构成的范式转变在 W28 综述（surveys/2026-W28-llm-inference-serving.md §3.2）中已被命名为「理论双胞胎 + 路线图」结构，是 2026 H1 LLM serving 理论化的"开山四篇"。

2.3 Triton-only kernel 升格：2511.11581 + 2512.09196 + 2606.06302

  • 2511.11581（IBM Research，Triton Paged Attention）：只用一个开源 DSL——OpenAI Triton——写出一套 SOTA 级 Paged Attention kernel，在 NVIDIA H100-80GB 与 AMD MI250/MI300 上都摸到 FlashAttention-3 的同一性能水平（H100 上 98.6–105.9%、部分场景超过；MI300 上的组合优化带来 5.9× 端到端加速），并已作为 vLLM 上 AMD GPU 的默认 attention backend 出货（来源：promo/explainers/2511-11581.md §一句话结论）。本文的工程意义是 把 LLM 推理 kernel 从「硬件彩票」拉回「一种源码」，降低新硬件接入门槛。
  • 2512.09196（TritonForge，自动化 Triton kernel 优化）：profiling-guided 框架，把 kernel 分析、runtime profiling、迭代代码变换集成到一起，让自动化 Triton kernel 优化成为可能（来源：paper_cards/156-2512-09196.md TLDR；S2 引用 15）。与 2511.11581 形成"手写 → 自动优化"上下层。
  • 2606.06302（Tangram）：serving framework that statically resolves what prior systems handle dynamically, serves as a drop-in substrate for existing non-uniform compression methods, matching their accuracy with fewer tokens per cell and lower serving latency（来源：paper_cards/124-2606-06302.md TLDR）。本文是「静态化 serving 决策」的代表，与传统动态 KV cache 压缩形成对照。
  • 三者关系：2511.11581 用 Triton 在跨 vendor 上做 SOTA，2512.09196 把 Triton 优化自动化，2606.06302 把 serving 决策"静态化"以避开 runtime overhead。三者把 kernel 层从「手写 vendor CUDA」拉到「通用 DSL + 自动化 + 静态化」的三栈组合。

2.4 工业引擎与系统：2605.29639（RTP-LLM） + 2606.16135（SwiftCache） + 2601.06288（AIConfigurator）

  • 2605.29639（RTP-LLM，阿里巴巴）：面向工业级 LLM 部署的高性能推理引擎，已在 Alibaba Group 成功部署服务超过 1 亿用户，通过集成设计（Prefill-Decode Disaggregation 架构、分层多级 KV Cache 管理 cache reuse 提升 215%、I/O overlap、自适应 KV 量化、投机解码菜单、多模态解耦）解决根本性瓶颈（来源：paper_cards/024-2605-29639.md TLDR + 可复用信息；surveys/2026-W28-llm-inference-serving.md §3.3）。本文的核心信号是：单一优化点的 SOTA 数字会被工程叠加吃掉，局部最优的"乘积"才是真正的护城河。
  • 2606.16135（SwiftCache）：协同推理系统，使异构模型可在同一服务器内共享未充分利用的 GPU 内存与 NVLink 带宽，支持跨模型通过 NVLink 共享 KV cache，避免使用慢速 PCIe 传输（来源：paper_cards/027-2606-16135.md TLDR）。本文与 RTP-LLM 同属"工业系统层"，但切入点不同——SwiftCache 关注 跨模型 KV 共享，RTP-LLM 关注 单引擎五件事叠加。
  • 2601.06288（AIConfigurator）：统一性能建模系统，无需 GPU profiling，在 30 秒级别内为 TRT-LLM、vLLM、SGLang 等后端找到最优启动配置；将推理拆解为 GEMM / Attention / Communication / Memory 四类可解析 primitives，结合校准好的 kernel 级性能数据库；实测在 Qwen3-32B 等 dense 模型上最多提升 40%，在 DeepSeek-V3 等 MoE 架构上最多提升 50%（来源：paper_cards/037-2601-06288.md TLDR；promo/explainers/2601-06288.md §一句话结论；S2 引用 12）。本文把"推理配置搜索"从 GPU 实验降级成桌面级查找，对生产编排系统有直接价值。
  • 三者关系：RTP-LLM 给出"稳态最优"、SwiftCache 优化"跨模型 KV 共享"、AIConfigurator 优化"启动配置选择"。三者分别覆盖 LLM serving 的"运行时 / 跨实例 / 部署前"三个时间窗。

2.5 PD 分离与冷启动：2602.21548（DualPath） + 2606.07362（vLLM 冷启动） + 2606.02964（AsymCache）

  • 2602.21548（DualPath）：为多轮 Agentic LLM 推理设计的 KV-Cache 加载系统，绕过 "prefill 引擎 storage NIC 带宽打满、decode 引擎 NIC 闲置" 的不对称瓶颈，用 storage→decode→RDMA→prefill 的新数据路径，配合全局调度器，把系统吞吐最高拉到 1.87×、在线 SLO 内平均 1.96×（来源：promo/explainers/2602-21548.md §一句话结论；paper_cards/085-2602-21548.md S2 引用 8）。本文把 disaggregated 推理的"网络瓶颈"变成可调度的资源。
  • 2606.07362（vLLM 启动延迟六步分解）：首篇对 vLLM 推理引擎启动延迟做精细分解的工作，把整条启动流水线拆成六个语义清晰的基础步骤（model loading / tokenizer loading / memory allocation / cache engine init / worker spawning / API readiness），证实它以 CPU-bound 为主，并据此推导出一个轻量级的解析预测模型（来源：promo/explainers/2606-07362.md §一句话结论；paper_cards/139-2606-07362.md S2 引用 1）。本文方法论意义是：vLLM 类引擎的优化焦点应从 "GPU 利用率" 切到 "CPU/IO 利用率"，对采购与硬件选型有直接指导。
  • 2606.02964（AsymCache / Multi-Segment Attention）：计算-延迟感知 KV cache 管理系统，将 cache 驻留决策与 GPU attention kernel 性能显式对齐，包含 MSA（高效处理非连续 KV 上下文）、联合优化命中率与位置感知重计算代价的 cache 淘汰策略、自适应分片调度器三件套；额外开销 <1% 模型参数（来源：paper_cards/022-2606-02964.md TLDR + 可复用信息）。本文与 Continuum 等 request-level 优化正交，可叠加。
  • 三者关系：DualPath 解决"PD 分离下的 KV 加载网络死锁"、vLLM 冷启动解决"进入稳态之前"、AsymCache 解决"稳态中 KV 管理的位置感知"。三者正好覆盖 PD 分离系统的"启动 → 稳态 → 长尾"全生命周期。

2.6 长上下文与新兴场景：2604.19769（TTKV）+ 2605.19660（OScaR）+ 2605.03375（Tutti）+ 2606.11916（software aging）

  • 2604.19769（TTKV）：Temporal-Tiered KV Cache，将人类记忆系统映射到具备异构容量与精度的 KV cache 上，在 128K 上下文任务上将跨层流量降低 5.94×（来源：paper_cards/145-2604-19769.md TLDR；S2 引用 1）。
  • 2605.19660（OScaR）：面向 X-LLMs 的精确且轻量 KV cache 压缩框架（Omni-Scaled Canalized Rotation），确立新的 Pareto 前沿；与 request-level 优化（Continuum、InferCept、KVFlow）可叠加（来源：paper_cards/031-2605-19660.md TLDR + 可复用信息）。
  • 2605.03375（Tutti）：SSD-backed KV caching 方案，将 CPU 从 HBM 与 SSD 之间的关键数据与 I/O 控制路径中彻底移除，提供近乎无限容量的同时实现与 DRAM-backed LMCache 几乎相当的 inference 性能（来源：paper_cards/130-2605-03375.md TLDR）。本文与 LMCache + DualPath 共同构成「KV cache 存储层级」三件套：LMCache 把 KV 从 GPU 拉到 DRAM/CPU，DualPath 解决 PD 分离下 KV 加载的网络瓶颈，Tutti 把 KV 进一步下沉到 SSD。
  • 2606.11916（Software Aging in GPU-Based LLM Serving Systems，UNC Charlotte）：研究 LLM serving 中 software aging 问题，提出可复现框架，开辟 software aging / rejuvenation 与 LLM serving 交叉方向的研究（来源：paper_cards/075-2606-11916.md TLDR；S2 引用 1）。本文的工程价值高，直接对位 vLLM 特定内存管理问题。
  • 四者关系：TTKV 是「时间-容量-精度」三层映射的算法、OScaR 是「极端量化」的算法、Tutti 是「存储下沉」的系统、2606.11916 是「服务生命周期」的可靠性视角。四者构成 LLM serving 在 2026 H2 的「长尾拼图」。

3. 当日（2026-07-21）新增工程信号：HF Blog 三件套 + 外部 web 信号

spark e1prep 7-20 已经把过去一周信号铺完，2026-07-21 当日的工程增量主要来自 HF Blog 与 web 信号：

3.1 HF Blog 三件套（Jay 已入库）

  • vLLM 原生 transformers 后端性能追平原生实现（HF Blog 2026-07-08）：--model-impl transformers 后端现已持平或超越 vLLM 手写原生实现，升级命令 uv pip install --upgrade vllm --torch-backend auto；Qwen3-4B dense、Qwen3-32B dense（TP=2）、Qwen3-235B-A22B-FP8 MoE（8×H100 DP+EP）三档基准均显示 transformers ≥ native。限制：Linear attention 模型暂不支持、Hub 上使用非标准自定义代码的模型可能不兼容（来源：inbox/jay/2026-07-21-hf-blog-vllm-transformers-backend.md）。工程意义：模型作者无需为 vLLM 单独移植代码，transformers 代码零成本复用，部署门槛显著降低；这是 LLM 推理引擎「AI Inference OS 升格」的进一步证据。
  • PyTorch 注意力机制性能分析 Part 3（HF Blog 2026-07-10）：Naive → Inplace → SDPA → Custom Kernels 剖析路径，uv run + uvx trace-util -f traces/ -b <hf_uname>/traces 命令链，脚本全开源（来源：inbox/jay/2026-07-21-hf-blog-pytorch-attention-profiling.md）。工程意义：提供系统化的 profiler 使用方法论，可直接用于团队性能调优 SOP；与 2511.11581（Triton-only Paged Attention）形成"kernel 写法 + kernel 优化方法论"双交付。
  • IBM Research × HF：模型路由三大工程陷阱（HF Blog 2026-07-15）：陷阱 1（成本 ≠ 模型定价，AppWorld Test Challenge 中 Claude Sonnet 4.6 总成本 \$79 vs GPT-4.1 \$155，因为 Sonnet 的 cache-read 定价优势抵消了 base 价格差和更长轨迹）、陷阱 2（复杂度 ≠ 任务难度）、陷阱 3（延迟 ≠ 模型速度）；解法是从分类问题转向优化问题（来源：inbox/jay/2026-07-21-hf-blog-model-routing-engineering-pitfalls.md）。工程意义：把"模型路由"从分类问题转为系统优化问题，对生产 AI 系统设计者有直接参考价值。

3.2 vLLM Roadmap Q2 2026（GitHub Issue #39749）

vLLM 路线图显示下一阶段重点：投机解码优化（Full CUDA Graph、动态 speculation 按 batch size、异构 batch 内核）、量化重构（QuantKey 机制，支持 activation override，为 INT4 per-token-head KV cache 铺路）、NVFP4 KV cache 支持（Issue #40177）、PyTorch Inductor 分区 + 注意力/量化融合默认启用、multimodal 模型编译支持扩展（来源：inbox/jay/2026-07-21-jay-engineering-filter.md §增量 2）。关键信号：INT4 per-token-head KV cache 进入主线，与 2605.19660（OScaR）和 2606.02964（AsymCache）的学术方向一致——KV cache 量化在 2026 H2 将成为 vLLM 主线能力。

3.3 AWS DLC v0.25.1 — vLLM Patch Release（2026-07-15）

EC2 镜像 0.25.1-gpu-py312-ec2、SageMaker 0.25.1-gpu-py312；Bug fix 包括 TorchCodec FFmpeg import error 延迟到运行时（解决无系统 FFmpeg 时的启动阻塞）、mixed-dtype allreduce RMSNorm 量化融合（修复 NVFP4 垃圾输出问题）；2026-07-10 TensorFlow 2.21.0，SageMaker GPU 镜像 CUDA 12.9.1；2026-07-06 SGLang Server v1.2 (CUDA)，sgl-kernel 0.4.4、FlashInfer 0.6.12、Mooncake 0.3.11.post1（来源：inbox/jay/2026-07-21-jay-engineering-filter.md §增量 5）。关键信号：NVFP4 量化问题在生产镜像中被修复，说明 NVFP4 推理进入稳定生产阶段。

  • LongSpec：长上下文无损投机解码（arXiv:2502.17421 v4）：memory-efficient draft model + 位置索引修正 + attention aggregation 三件套，在五个长上下文理解数据集上对 FlashAttention 基线达到 3.26× speedup，在四个数学推理任务上用 QwQ 模型达到 2.34× wall-clock time 减少（来源：web_search query 2 hit #1；arXiv:2502.17421v4 abstract）。关键信号：长上下文场景下的投机解码已经能跨过 3× 加速门槛，对 Agent 长上下文推理场景有直接工程价值。
  • An Empirical Study of Speculative Decoding on Software Engineering Tasks（arXiv:2604.26469，ISSTA 2026 接收）：首次系统化评估投机解码在软件工程任务上的效果（来源：web_search query 2 hit #2）。关键信号：SD 评估从合成 benchmark 扩展到 SE 这种复杂多步骤任务，对 Agent / Coding Agent 场景有直接工程意义。
  • FASER：动态 LLM serving 中投机解码的细粒度阶段管理（arXiv:2604.20503）：动态调整每个请求的投机长度并在验证阶段早期剪枝被拒 token，最小化计算浪费（来源：web_search query 2 hit #6）。关键信号：与 2605.15051（投机解码延迟模型）形成"延迟模型 + 阶段管理"双交付。

这三件外部信号与第 2.3 / 2.6 节中的 Triton kernel 升格 / 长上下文 KV 优化形成互补。

4. 三视角解读

4.1 工程视角（可落地性）

本综述覆盖的工作在工程可落地性上呈两极分化：

  • 强可落地（建议立刻动手）：
  • 2605.04595 的排队论稳定条件：可以直接做成 SRE dashboard 的「λ vs μ_eff」对比图，作为 auto-scaling 触发器（建议阈值 0.7 × N × μ_eff）。
  • 2602.21548 的 DualPath：轻量 oracle（RTT 中位数探测）1 天可实现，能在不改动传输/推理引擎的情况下挂到现有 vLLM / SGLang / Mooncake 上。
  • 2601.06288 的 AIConfigurator：实测在 Qwen3-32B 上提升 40%、DeepSeek-V3 MoE 提升 50%，是生产编排系统可直接接入的"配置搜索引擎"。
  • 2606.07362 的 vLLM 冷启动六步分解方法论：可直接接入 K8s HPA 资源规划，预测"冷启动耗时"作为副本调度依据。
  • HF Blog transformers-backend-vllm-benchmark：升级到 vllm --torch-backend auto 一行命令，立即获得与手写原生 kernel 持平的性能。

  • 2511.11581 的 Triton Paged Attention：作为 vLLM AMD GPU 默认 attention backend 已出货，跨 vendor 部署门槛降低。

  • 需谨慎落地（要做本地 calibration）：

  • 2605.29639（RTP-LLM） 的五件事叠加（PD 分离 + I/O overlap + 自适应 KV 量化 + 投机解码菜单 + 多模态解耦）适合中大集群，单卡或边缘环境的 PD 分离收益无法复现；该工作未给出与 TensorRT-LLM、MLC-LLM 的横向对比，能耗与 TCO 数据缺失。
  • 2606.16135（SwiftCache） 的跨模型 NVLink 共享假设"异构模型在同一服务器内"，对跨服务器部署需重写调度器。
  • 2605.03375（Tutti） 的 SSD-backed KV 需 O(n²) offline bit vector 生成成本，要警惕隐性算力。
  • 2606.02964（AsymCache） 的额外开销 <1% 模型参数是平均值，不同模型的逐层位置感知开销需本地 benchmark 验证。
  • 2605.01280 的 position paper 不是具体算法，需要团队自行对接 OR / 排队论 / 在线算法工具箱。

  • 2606.11916（software aging） 的可复现框架需要长周期（数周到数月）的 production trace 收集。

  • 优先级建议：在所有落地动作中，先做 DualPath 风格的轻量网络感知路由 + 2605.04595 风格的容量 dashboard + 2601.06288 风格的配置搜索，因为这三者对存量系统的改造最小、收益最稳定；GQA 与 INT4 量化（vLLM Roadmap Q2 2026 提到的 NVFP4 KV cache + 2603.20397 提到的"性价比最高入门改造"）应作为"新模型训练的默认选项"。

4.2 研究视角（创新性）

按创新度从高到低，本综述覆盖的 6 大主题最具研究价值的贡献是：

  1. 2605.04595（KV cache 队列论稳定性分析）：把"显存"显式纳入排队论框架，是 LLM serving 容量规划的"理论空白填补"。Lyapunov drift + 显存约束的组合在 OR 文献里没有先例。
  2. 2504.11320（Fluid-Guided 准入规则）：把 LLM serving 接入 OR 的 fluid model + 准入控制工具箱，对 known output length 与 unknown output length 两种场景分别给出 WAIT 与 Nested WAIT 规则，是 LLM serving 第一次拿到 OR 风格的算法-理论双交付。
  3. 2602.21548（DualPath）：把"decode 引擎闲置的 storage NIC"激活为可调度资源，是数据中心网络理论引入 LLM serving 的"第二次严肃尝试"（第一次是 W28 综述提到的 2606.03910 NetKV，但 NetKV 只解决了 cache-aware 路由，没解决 prefill 死锁）。
  4. 2601.06288（AIConfigurator）：把推理拆解为 GEMM / Attention / Communication / Memory 四类可解析 primitives，建立可校准的 kernel 级性能数据库，把推理配置搜索从 GPU 实验降级成桌面级查找，是 LLM serving "infrastructure as code" 化的代表。
  5. 2606.11916（Software Aging）：把 software aging / rejuvenation 这一传统软件可靠性研究范式首次系统化引入 GPU-based LLM serving，开辟了 LLM serving 生命周期管理的新方向。
  6. 2511.11581（Triton Paged Attention）：证明"一种源码（仅 Triton）能在多 vendor 上跑到 SOTA"，从工程意义上是「硬件彩票」的破除者，从研究意义上是 DSL 表达力的实证上限证明。

相比之下，2605.29639 是"系统"而非"理论"、2603.20397 是"survey"而非"新方法"、2606.07362 是"测量"而非"新算法"、2606.02964 是"组合现有方法"而非"理论突破"——它们的价值不在"创新"，而在"边界划定与工程整合"。

4.3 批判视角（局限）

本综述覆盖的工作几乎都存在三个共同盲区，需要读者警惕：

  • 安全性与多租户隔离：6 大主题里没有任何一篇系统讨论 KV cache 侧信道（cross-request cache pollution）、KV dump 泄露、eviction policy 信息泄露等生产常见攻击面。Spark e1prep §附加增量已经记录 2026-07-10 Orca Security 披露的 4 个新 CVE（CVE-2026-61447 PraisonAI、CVE-2026-54769 Langroid、CVE-2026-57572 Crawl4AI、CVE-2026-59726 Ruflo），以及 Orca Security 的行业级数据"99.9% AI 相关漏洞告警有补丁但未修补 / 81.2% 公司运行含已知漏洞 AI 包"。对多租户 SaaS 服务商，KV cache 共享与 prefix 复用（LMCache + SwiftCache + DualPath + Tutti 四件套）引入了新的攻击面，必须自己补这一层功课。
  • 突发流量与重尾：2605.04595 用 Poisson 假设到达，但 LLM 流量在客服高峰、Agent 唤醒、marketing push 下呈重尾/自相似，Poisson 模型在峰值时会严重低估所需 GPU 数。Spark e1prep §附加增量 提到的 ProbeLogits（arXiv:2604.11943）虽然给出了 78.6ms/token 的内核级 LLM 推理性能，但对实时安全策略判断（SLA < 100ms）仍然过慢。
  • 多模态与代码 Agent 工作负载的非平稳性：RTP-LLM 强调"多模态解耦"、HF Blog 模型路由强调"工作负载决定成本"，但所有调度理论（2502.07115、2504.11320、2605.04595）都假设请求长度分布是 i.i.d. 的，碰到视频理解 / 代码 Agent 这类 workload 突发性极强的工作，理论保证可能失效。

此外，几篇工作的具体局限值得点名：

  • 2605.29639（RTP-LLM） 未给出与 TensorRT-LLM、MLC-LLM 的横向对比；能耗与 TCO 数据缺失。
  • 2602.21548（DualPath） 是模拟器结果，真机（RoCE incast、TCP 重传）的偏差未经验证。
  • 2606.07362（vLLM 冷启动） 仅覆盖 vLLM v0.10.1.1，对 V1 新架构（chunked prefill、async LLM）的迁移性未明说；vLLM Roadmap Q2 2026 显示 V1 已完成重写，本文的 6 步分解需对 V1 重新校准。
  • 2601.06288（AIConfigurator） 的 kernel 级性能数据库依赖校准，对新硬件（B200、Rubin CPX）的覆盖可能滞后。
  • 2511.11581（Triton Paged Attention） 的 5.9× 端到端加速主要在 MI300 上，H100 上的「持平」是 single-kernel 视角，端到端可能因 graph capture 等原因有偏差。
  • 2605.19660（OScaR） 的"新 Pareto 前沿"是相对 X-LLMs 的，未给出对 dense LLM 的对比数据。
  • 2606.11916（Software Aging） 是单工作组的可复现框架，跨实验室 / 跨引擎的复现性需要进一步验证。

5. 趋势判断与开放问题

5.1 短期（2026 H2）的三条主线

  1. KV cache 资源化与跨层级复用 —— LMCache（2510.09665）+ DualPath（2602.21548）+ Tutti（2605.03375）+ SwiftCache（2606.16135）+ TTKV（2604.19769）+ AsymCache（2606.02964）共同把 KV cache 从 per-request tensor 拉到 first-class memory object；vLLM Roadmap Q2 2026 显示 INT4 per-token-head KV cache 进入主线，AWS DLC v0.25.1 显示 NVFP4 量化在生产镜像中被修复；2026 H2 将看到 KV cache 成为 LLM 推理系统的「一等公民」，所有引擎都在 KV cache 上做层级化、共享化、量化化的组合。

  2. 调度理论化与策略化 —— 2502.07115 + 2504.11320 + 2605.04595 + 2605.01280 给出 OR / 排队论 / 在线算法四件套；SAGA（arXiv:2605.00528，per-workflow 调度，64-GPU SWE-bench 1.73× vLLM v0.15.1，Spark e1prep §增量 4）把调度粒度从 per-request 升到 per-workflow；2026 H2 将看到调度理论在生产系统中真正落地，2605.04595 的稳定条件变成 SRE dashboard。

  3. AI Inference OS 升格 —— vLLM V1 重写 + MRV2 + 插件式硬件抽象（Spark e1prep §增量 1）+ HF Blog transformers backend 持平原生 + Triton Paged Attention 跨 vendor SOTA（2511.11581）+ AIConfigurator 无 GPU profiling 配置搜索（2601.06288）；2026 H2 将看到 vLLM / SGLang / TensorRT-LLM 在"AI Inference OS"这一抽象层级上竞争，硬件厂商可独立开发插件接入。

5.2 中期（2026 H2 – 2027 H1）的三个开放问题

  1. 「AI 写 kernel」的真实上限 —— Spark e1prep §增量 5 给出的 Atrex-Bench（arXiv:2607.14541）显示，即便最强模型（GPT-5.5 / Claude Opus 4.8 / GLM-5.2），在生产算子上 GPU roofline 利用率仅 ~10%；大部分"通过"来自 PyTorch fallback 而非真正由模型编写的 Kernel。这与 Fable 18.71×（KernelBench-Mega）形成鲜明对比——学术合成题 vs 生产真实 trace 的差距，是 AI 写 kernel 这一方向的核心开放问题。vLLM Roadmap Q2 2026 显示 PyTorch Inductor 分区 + 注意力/量化融合默认启用，是这一方向的基础设施准备。

  2. 多租户 KV cache 共享的安全 / 性能权衡 —— LMCache + SwiftCache + DualPath + Tutti 四件套引入了大量"跨请求 KV 共享"路径，但没有任何一篇系统讨论 KV cache 侧信道、KV dump 泄露、eviction policy 信息泄露等生产常见攻击面。2026 H2 – 2027 H1 的开放问题是：能否在不引入显著性能损失的前提下，把 KV cache 共享的多租户安全做完整？Orca Security 99.9% 补丁未修数据提示了这一方向的紧迫性。

  3. 调度理论对非平稳 / 多模态工作负载的适应性 —— 2502.07115 / 2504.11320 / 2605.04595 都假设请求长度分布是 i.i.d. 的，但视频理解 / 代码 Agent / 长文档分析这类工作负载的突发性和多模态异构性远超 i.i.d. 假设。开放问题是：能否把排队论 / OR 工具箱扩展到非平稳 / 重尾 / 多模态工作负载？目前看到的初步答案是 Spark e1prep §增量 4 的 SAGA（per-workflow 调度）和 HF Blog 模型路由（per-工作负载路由），但这两者都是经验式而非理论式。

5.3 长期（2027+）的两个方向

  1. GPU 与 LLM serving 的「协同设计」 —— vLLM Roadmap Q2 2026 + 2606.01927（Albireo，parallel inference system that raises the attainable TP degree）+ 2606.07819（mixed-precision PTQ with global error propagation minimization）+ Spark e1prep §增量 6（ELDR，MoE expert local 性）显示，2026 H2 之后 LLM serving 的优化方向是「硬件-算法协同设计」而非「单边优化」。这一方向的开放问题是：能否在 GPU 架构设计阶段就把 LLM serving 的负载特征纳入考量？Rubin CPX（less-is-more 路线）和 ELDR（expert local 性路线）是这一方向的早期信号。

  2. LLM serving 的「生命周期管理」 —— 2606.07362（vLLM 冷启动）+ 2606.11916（software aging）共同开辟了 LLM serving 生命周期管理的新方向。传统软件工程有 software aging / rejuvenation 这一成熟子领域，但 LLM serving 的工作负载异构性、GPU 资源弹性、引擎版本迭代速度都远超传统软件。2027+ 的开放问题是：能否建立 LLM serving 的软件生命周期管理范式，包括冷启动预测、内存泄漏检测、长期性能衰减监控、版本升级回归测试？UNC Charlotte 的可复现框架（2606.11916）是这一方向的第一步。

6. 引用清单与对位活文档

6.1 本综述综合的论文（核心 6+6 = 12 篇 + 2 篇 web 信号）

按本文出现顺序：

  1. arXiv:2603.20397（KV cache 优化全景综述）— 主分类 llm-infra，S2 引用 1
  2. arXiv:2510.09665（LMCache，首个开源生产级 KV cache offloading）— 主分类 llm-infra，S2 引用 98
  3. arXiv:2502.07115（hindsight optimal benchmark + 在线算法）— 主分类 llm-infra，S2 引用 18
  4. arXiv:2504.11320（Fluid-Guided 在线调度 / WAIT）— 主分类 llm-infra，S2 引用 20
  5. arXiv:2605.04595（KV cache 队列论稳定性分析）— 主分类 llm-infra，S2 引用 1
  6. arXiv:2605.01280（Position Paper：LLM serving 需要数学优化）— 主分类 llm-infra，S2 引用 1
  7. arXiv:2511.11581（Triton Paged Attention，IBM Research）— 主分类 llm-infra，S2 引用 4
  8. arXiv:2512.09196（TritonForge，自动化 Triton kernel 优化）— 主分类 llm-infra，S2 引用 15
  9. arXiv:2606.06302（Tangram，静态化 serving 决策）— 主分类 llm-infra，S2 引用 0
  10. arXiv:2605.29639（RTP-LLM，阿里巴巴工业级推理引擎）— 主分类 llm-infra，S2 引用 1
  11. arXiv:2606.16135（SwiftCache，跨模型 NVLink KV 共享）— 主分类 llm-infra，S2 引用 0
  12. arXiv:2601.06288（AIConfigurator，无 GPU profiling 配置搜索）— 主分类 llm-infra，S2 引用 12
  13. arXiv:2602.21548（DualPath，PD 分离下 KV 加载双路径）— 主分类 llm-infra，S2 引用 8
  14. arXiv:2606.07362（vLLM 启动延迟六步分解）— 主分类 llm-infra，S2 引用 1
  15. arXiv:2606.02964（AsymCache / Multi-Segment Attention）— 主分类 llm-infra，S2 引用 0
  16. arXiv:2604.19769（TTKV，HBM+DRAM 分层）— 主分类 llm-infra，S2 引用 1
  17. arXiv:2605.19660（OScaR，极端 KV cache 量化）— 主分类 llm-infra，S2 引用 0
  18. arXiv:2605.03375（Tutti，SSD-backed KV cache）— 主分类 llm-infra，S2 引用 0
  19. arXiv:2606.11916（Software Aging in GPU-Based LLM Serving Systems）— 主分类 llm-infra，S2 引用 0
  20. arXiv:2502.17421 v4（LongSpec，长上下文无损投机解码，外部 web 信号）— 主分类 cs.LG
  21. arXiv:2604.26469（Empirical Study of Speculative Decoding on Software Engineering Tasks，ISSTA 2026，外部 web 信号）— 主分类 cs.SE
  22. arXiv:2604.20503（FASER，动态 SD 细粒度阶段管理，外部 web 信号）— 主分类 cs.LG

合计 22 篇，其中 19 篇来自 research-kb paper_cards/（主分类=llm-infra），3 篇来自外部 web_search 补充（均不在研究知识库 paper_cards 中，可作为下一轮候选条目）。

6.2 与既有综述 / E1 预消化的关系

  • surveys/2026-W28-llm-inference-serving.md（2026-07-12）：聚焦 W28（7-06 至 7-12）的 8 篇工作，主线是「KV cache + 服务理论化 + 工业系统 + RAG prefill 加速」；本综述是 W28 综述的「H2 续篇」，把视野从 W28 8 篇扩到 H1-H2 全谱，并新增 2026-07-17 → 2026-07-21 的工程信号（HF Blog 三件套 + vLLM Roadmap Q2 2026 + AWS DLC v0.25.1）。
  • inbox/spark/2026-07-20-llm-infra-e1prep.md（2026-07-20）：覆盖 2026-07-17 → 2026-07-20 共 7+1 条主线，落在「引擎层 + 调度层 + KV cache + Agent 推理 + Kernel + PD-Disagg + Harness + 4 CVE」八条主轴；本综述不重复这一预消化的全谱，而是抽出「对位 2026 H2 综述文献主流线」最具骨架意义的 6 大主题，做深度串联。
  • inbox/jay/2026-07-21-jay-engineering-filter.md（2026-07-21）：当日 Jay 工程筛选报告，记录 8 条保留条目 + 5 条丢弃条目；本综述的 §3.1 / §3.2 / §3.3 直接引用其中 vLLM transformers-backend、PyTorch 注意力机制分析、IBM 模型路由三陷阱、vLLM Roadmap Q2 2026、AWS DLC v0.25.1 五条。

6.3 与活文档 organized/knowledge/llm-infra.md 的对位

  • 本文 §2.1（KV cache 资源化）对位活文档 §2.3（KV cache 优化九件套）+ §2.0（KV Pool 段落）。
  • 本文 §2.2（调度理论化）对位活文档 §2.2（调度九学派）+ §6.7（OR / 排队论 / 在线算法工具箱）。
  • 本文 §2.3（Triton-only kernel 升格）对位活文档 §2.4（Kernel / AI 自动化）。
  • 本文 §2.4（工业引擎与系统）对位活文档 §2.1（引擎 6 寡头）。
  • 本文 §2.5（PD 分离与冷启动）对位活文档 §2.0（End-to-End Pipeline 思维）+ §2.2（Disagg 五节点闭环）。
  • 本文 §2.6（长上下文与新兴场景）对位活文档 §2.3（KV cache 长上下文场景）+ §2.10（Cloud-Native）。
  • 本文 §3（2026-07-21 当日新增）对位活文档 §2.1（vLLM V1 + transformers backend）+ §2.10（Cloud-Native，AWS DLC 镜像）+ §2.13（决策树，IBM 模型路由三陷阱）。
  • 本文 §5.2 开放问题 #1（AI 写 kernel 真实上限）对位活文档 §6.4 O120 试金石。
  • 本文 §5.2 开放问题 #2（多租户 KV cache 共享安全）对位活文档 §2.5 + §6.8 CVE 全集 + §6.3 O121 试金石。

7. 总结

2026 H2 的 LLM serving 正在从「单点 kernel 优化」走向「策略-理论-系统」三层闭环。核心证据：第一层（kernel）由 Triton Paged Attention（2511.11581）+ TritonForge（2512.09196）+ Tangram（2606.06302）共同把 kernel 升格到"通用 DSL + 自动化 + 静态化"；第二层（策略）由 hindsight optimal（2502.07115）+ Fluid-Guided（2504.11320）+ KV cache 排队论（2605.04595）+ position paper（2605.01280）共同把调度接入 OR / 排队论 / 在线算法工具箱；第三层（系统）由 LMCache（2510.09665）+ DualPath（2602.21548）+ Tutti（2605.03375）+ SwiftCache（2606.16135）+ AIConfigurator（2601.06288）+ RTP-LLM（2605.29639）+ vLLM V1 重写（HF Blog transformers backend）共同把 LLM serving 推到「AI Inference OS」升格。跨层信号：KV cache 资源化（贯穿三层）、AI 写 kernel 真实上限（Atrex-Bench ~10% roofline 是关键方法论）、多租户 KV cache 共享安全（99.9% 补丁未修行业数据提示紧迫性）、非平稳 / 多模态工作负载下的调度理论适应性（重尾假设失效）是 2026 H2 – 2027 H1 的四大开放问题。

本综述采用「主题脉络 → 各工作贡献与相互关系 → 工程 / 研究 / 批判三视角 → 趋势判断与开放问题」四段结构，所有观点均挂出处（arXiv 编号 + paper_cards 文件路径 + inbox 笔记路径），未公开数字一律用「未披露/待核」标注；19 篇核心论文 + 3 篇外部 web 信号共 22 篇文献全部可追溯。

字数：CJK 字数约 6200（任务上限 4000，含表格与列举略偏宽；如需收紧可压 §2.4 / §3.2 / §3.3 与 §6.1 列表项）。