inference · 知识库活文档

  • 更新：2026-08-29 | SGLang v0.6+DSpark;vLLM Conf2026+Q3 Roadmap;Kimi K3;ACL KV六件;ReCo CoT;FreeToken;引→约295
  • vLLM Conference 2026（首届，SF，2026-08-25-26）与 Ray Summit 联合举办；State of vLLM 2026（Flat Model/MRV2迁移/speculative 1000+TPS/multi-tier KV offloading）；Q3 Roadmap 六大 SIG；vLLM v0.28 MRV2 默认化+dense 模型默认执行路径；async scheduling 即将默认开启；MoE shared expert overlap 优化；RLHF pause/resume 改进；Prefill Context Parallel 初始支持；vLLM v0.27.1 生产默认（CUDA 13.x）；vLLM 25K TPS/GPU on Qwen3.5-397B-A17B @ GB200 NVL72；vLLM Decode Context Parallelism（DCP，KV cache 分布到多卡）；P-EAGLE（Parallel EAGLE，vLLM mainline v0.17+，coding benchmark 4-5× 基线）；EAGLE3.1（vLLM Blog 2026-05-18）；EAGLE3 + AMD Quark（vLLM Blog 2026-07-10）；vLLM Router（prefill/decode aware load balancer，vLLM Blog 2025-12-13）；vLLM Speculators v0.3.0（可训练自定义 draft model，vLLM Blog 2025-12-09）

一、现状全景：LLM 推理服务工业化成熟与框架收敛

2026 年中，LLM 推理服务已从「能跑就行」进入「工业级优化」阶段。Google 2026-05 数据显示其每月处理 3.2 万亿 tokens（年化 38 万亿），推理占 AI 算力消耗已达约 2/3。推理工程正在成为独立于 AI 工程的学科。

1.1 框架格局：vLLM 与 SGLang 双雄趋同，TGI 正式落幕

vLLM 0.28（2026-08）：Model Runner V2（M2）成为 Qwen3 dense 模型的默认执行路径。Experimental Rust frontend 已合入主线，新增 DP Supervisor for data-parallel serving。Device selection 变更：vLLM 不再内部设置 CUDA_VISIBLE_DEVICES，改为提供新的 device_ids 参数（ROCm 上已开始 CUDA_VISIBLE_DEVICES 废弃窗口）。

vLLM v1 重新架构调度器（2026-08 官方博客系列）：重新架构调度器（更简单）+ 近零开销 prefix caching + 更清晰的 tensor parallelism + 多进程 API server + Qwen3.8-2.4T-A95B Day 0 支持。async scheduling 将很快默认开启；MoE shared expert overlap 优化（DeepSeek V4 等共享专家模型关键特性）；RLHF pause/resume 改进（异步 RL 关键）；Prefill Context Parallel 初始支持（长序列新并行方式）。

vLLM 0.28 MRV2 新功能矩阵（vLLM GitHub releases 2026-08 确认）：

功能 说明 生产意义
EVS（Embedding Vector Search） MRV2 原生支持向量检索任务，推理引擎直接服务向量搜索 推理+检索单引擎闭环
Realtime Embeddings 实时嵌入生成，与 EVS 协同 多模态 RAG / 表示学习场景
Mamba Hybrid Prefix Caching 对 Mamba 混合架构模型的 prefix caching 支持 状态空间模型 + Transformer 混合部署
Multimodal-Prefix Bidirectional Attention 多模态 prefix 的双向注意力机制 视觉语言模型的多模态 prefix 复用
Dynamic Speculative Decoding + Full CUDA Graphs 动态投机解码现已兼容完整 CUDA graphs 投机步骤 CPU 同步开销大幅降低
GraniteMoE 默认启用 MRV2 默认启用 GraniteMoE MoE 生产部署简化

MRV2 + Speculative Decoding 协同机制（Spheron 2026 MRV2 部署指南）：MRV1 已知开销——每步投机需 CPU 同步点验证 draft token 并构建下一步输入，在高深度（5-8 tokens）时每接受 token 增加显著延迟。MRV2 的 async scheduling 使 draft 和 target model prefill 在重叠的 GPU streams 上运行，从根本上消除了 MRV1 的同步瓶颈。MRV2 原生对 decode 阶段使用 CUDA Graphs，投机解码的整体吞吐改善显著。

vLLM Router（vLLM Blog 2025-12-13）：High-Performance and Prefill/Decode Aware Load Balancer for Large-scale Serving。生产级负载均衡器，感知 prefill/decode 阶段资源消耗差异，是大规模多节点推理集群的关键组件。

vLLM Speculators v0.3.0（vLLM Blog 2025-12-09）：统一库，用于构建、评估和存储服务于 vLLM 的投机解码算法。可训练自定义 draft model（speculator），与 vLLM 引擎无缝集成。

P-EAGLE（Parallel EAGLE，vLLM 官方博客 2026-03-11）：并行预测多个 draft token，多树推测（multi-tree speculation）。Coding benchmark 4-5× 基线，20-30% over EAGLE3。已进入 vLLM mainline（v0.17+）。P-EAGLE 的 CUDA Graph 集成与 MRV2 async scheduling 协同是 2026 年生产部署热点。EAGLE 3.1（vLLM Blog 2026-05-18）：EAGLE Team + vLLM + TorchSpec 三方协作推进，接受率与延迟进一步改善。

EAGLE3 + AMD Quark（vLLM Blog 2026-07-10）：EAGLE3 投机解码在 AMD Instinct 加速器上通过 Quark 框架集成入 vLLM，标志着 vLLM 的投机解码生态从 NVIDIA 扩展到 AMD ROCm。

vLLM 25K TPS/GPU on Qwen3.5（vLLM Blog 2026-07-29）：GB200 NVL72 分解式服务架构下达 25K total TPS/GPU；关键技术栈：Blackwell GDN kernels + HMA cache transfer + async scheduling fixes + srt-slurm recipes；Qwen3.5-397B-A17B（NVFP4 精度）。

vLLM Decode Context Parallelism（DCP，vLLM Blog 2026-08-06）：将 decode 阶段 KV cache 分布到多 GPU，计算保持在单卡。与传统 TP 切分不同，DCP 仅对 KV cache 做分布——适合 128K+ 上下文。SGLang 同时支持 DCP（称为 DP-attention），SGLang v0.6 中 --dp-size 与 --enable-dp-attention 参数组合对应 DCP 实现。

vLLM v0.27.1（2026-08-11）：生产默认推荐，PagedAttention + Continuous Batching，CUDA 13.x 支持。gpu_memory_utilization 默认值：7B → 0.95 / 13B → 0.85 / 70B → 0.90。

vLLM Conference 2026（2026-08-25-26，SF）：首届 vLLM Conference 与 Ray Summit 联合举办。State of vLLM 2026（Woosuk Kwon + Zachary Xi，Inferact）核心内容：Flat Model 与 Model Runner V2 迁移进度；disaggregated serving + multi-tier KV offloading；speculative decoding 目标 1000+ TPS；production-grade quantized KV cache compression。大会还涵盖 infra/CI/security 工作、AMDD Spark 支持 + Quark 生态、vLLM-Omni real-time full-duplex model 生产化（JoyVL / MiniCPM-o）、Cosmos3 / Qwen3-Omni 优化、视频生成 streaming + FastVideo 集成，以及 vLLM × RL Ecosystem Q3 2026 合作计划。

vLLM Q3 2026 Roadmap（GitHub Issue #48168，六大轴）：

  • SIG Core：完成 top-20 架构 Flat Model 迁移；完成 MRV2 迁移并 day-0 MRV2 only；生产稳定性与 failure ergonomics；调度器重构；KV Cache Manager 重新设计；Rust Frontend + tool-calling 重构 production ready；冷启动优化
  • SIG Speculative Decoding：UX 改进（speculation by default）；Dynamic Speculative Decoding（高并发异构 workload 优化）
  • SIG Backend：AMD DSpark 支持 + Quark 生态
  • vLLM-Omni：real-time full-duplex model 生产化（JoyVL / MiniCPM-o）；Cosmos3 / Qwen3-Omni 优化；视频生成 streaming + FastVideo 集成
  • RL Ecosystem：2026 Q3 vLLM × RL Ecosystem 合作

SGLang v0.6（2026-07-27，574 PRs）：DSpark 投机解码（DeepSeek-V4-Pro TP8 B300 bs=1 达 383.7 tok/s）+ DFlash + Spec V2（ICML 2026，>4.3× 基线吞吐，1.5× MTP）+ PD Disagg GPU Staging Buffer（RDMA 请求数降低约 1000×）+ 全球部署超过 400,000 GPUs + DeepSeek V4 Flash 0731 Day-0 支持。

SGLang DSpark 生产细节（LMSYS Blog 2026-07-06）：核心洞察：标准投机解码在 load 下存在 bottleneck——batch size B + K 个投机 token 时，target 每步验证 B×K 个 token，过了某点后得不偿失。DSpark 解法：confidence-driven variable-length verification，只在 draft model 自信的位置验证，使 gains 在 load 上升时依然保持。工程实现：full CUDA graphs over ragged per-request verify（trimmed batch replay 真正更小的 graph，而非 padded graph）。SGLang 同时支持 dense 和 sparse 模型（Qwen3、DeepSeek-V4）。官方命令示例：SGLANG_RAGGED_VERIFY_MODE=compact python3 -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V4-Flash-DSpark --speculative-algorithm DSPARK --tp 4 --dp-size 4 --enable-dp-attention --enable-dp-lm-head

SGLang DSpark Bug（AIME25 精度回退，GitHub Issue #32038）：SGLang v0.6 + DSpark 在 DeepSeek-V4-Flash 上实测发现 accuracy regression——AIME25 从 97.08%（无投机）降至 93.96%（DSpark 开启）。环境：4×B300 SXM6，PyTorch 2.11.0+cu130，sglang 0.0.0.dev1+gd6ef68881，flashinfer 0.6.14。这是 DSpark 实际生产部署的重大警示，issue 于 2026-07-22 由 fangtang1121 提交，官方 fix 尚在处理中。

SGLang Spec V2（LMSYS Blog 2026-07-06，ICML 2026）：>4.3× 基线吞吐，1.5× MTP（Mega Token Prediction）。Spec V2 的 verify 窗口动态调整机制与 DSpark 的 confidence-driven 验证形成互补，两者在 SGLang v0.6 中并存。

SGLang PD Disagg GPU Staging Buffer（LMSYS Blog 2026-07-06）：通过 RDMA 实现 prefill 和 decode 节点间 KV block 传输，RDMA 请求数降低约 1000×，是 disaggregated serving 在生产环境落地的关键技术。

SGLang v0.5.18（2026-08-22）：迁移至 PyTorch 2.13，移除 torchao 集成。支持 NVIDIA / AMD ROCm / Intel Xeon / Google TPU / 华为 Ascend NPU 多硬件路径。TTFT 最优 80ms，State Graph 多步推理单次调用完成。吞吐 2,800 tokens/s（vLLM 3,500），Agent 场景低延迟优先。

Kimi K3 Day-0 支持（SGLang v0.6 Release Notes）：K3（2.8T 参数 LatentMoE，896 experts，top-16 路由，3584-dim latent space，1M token 上下文）通过 SGLang 从 Day-0 获得完整支持：DCP（Decode Context Parallel）+ DSpark 投机解码 + chunked-prefill PP with TP decode + KDA-aware prefix caching + HiCache L2 over DCP + LoRA on quantized weights + reasoning + tool-call。K3 是 2026 年生产 Agent 场景最受关注的模型之一。

SGLang Agent-Assisted Development（LMSYS Blog 2026-07-02）：KDA-Pilot 三大优化已合入 SGLang upstream（截至 2026-06-27）：B200 native diffusion norm-scale-shift CUDA fast path（PR #27392，Qwen-Image-2512）；Cosmos3 VAE causal Conv3D cat/pad copy path（PR #29281）；LTX-2.3 residual-gate update path（PR #29361）。Cohere2Moe NVFP4 fused-MoE path（PR #27401）：1×B300 上 chat +21%，summarization +21%，比其他开源推理框架高 +4.1% / +6.8%。SGLang 与 LinkedIn 合作：生产团队与开源基础设施共同迭代。

SGLang Advanced CUDA Graph（LMSYS Blog 2026-08-17，生产调优重要）：full：捕获整个 prefill 为单个 CUDA Graph，实验性，仅 FlashAttention-4/FlashInfer 后端支持；breakable：分段捕获，可动态处理变长序列，生产推荐；tc_piecewise（torch.compile）：最小代码量（177 行 vs 521 行），生产推荐。prefill graph 构建速度：breakable / tc_piecewise 比 full 快 3.8–5.2×。

SGLang GTC 2026 亮点（LMSYS Blog 2026-03-25）：Miles RL Framework：解决训练-推理 mismatch，通过三项核心技术，SGLang 作为 RL 训练循环中的推理后端；LinkedIn 工程团队：SGLang 作为推荐系统的共享基础设施层——生产团队与开源基础设施共同迭代的典范。

vLLM vs SGLang 选型（2026-08 实测）：高并发（64+）时 SGLang 开始全面超越 vLLM；H100 @ Llama 3.1 8B 16K 上下文：SGLang 16,215 tok/s vs vLLM 12,553 tok/s（+29%）；shared-prefix 场景 SGLang 领先 2-29%（prefix overlap ratio > 60% → SGLang 显著领先）。

vLLM vs SGLang Schema Complexity Overhead（DeepInfra + Spheron + Particula Tech，2026-08）：

Schema 复杂度 vLLM 开销 SGLang（热） SGLang（冷）
扁平 JSON（3 字段） +6% +2% +8%
嵌套 JSON（2 层） +18% +4% +15%
深嵌套（4 层） +42% +6% +24%
函数调用 +22% +5% +18%

vLLM vs SGLang 2026 实测 benchmark（Llama 3.3 70B FP8 / H100 SXM5 80GB / TP=2，RunPod/Spheron/JarvisLabs/LeetLLM）：

配置 vLLM 吞吐
128/128 ~6,092 tok/s
1000/1000 ~4,181 tok/s
1000/2000 ~3,709 tok/s
2048/2048 ~2,786 tok/s

TTFT 基准（SGLang vs vLLM vs TRT-LLM vs TGI vs llama.cpp）：SGLang：~80ms；vLLM / TRT-LLM：~150ms；TGI：~250ms；llama.cpp：~800ms。

四引擎工程选型决策框架（The AI Engineer，Paolo Perrone，2026-04/2026-08 确认）：

引擎 定位 核心特性 适合场景
Ollama 本地快速启动 ollama run llama3.1 一命令运行；M4 Mac 跑 Qwen 2.5 32B ≈ 15 tokens/s 单用户、macOS/Windows 快速实验
vLLM 生产默认 PagedAttention 防 GPU 内存浪费；硬件覆盖最广；生态最大 通用生产级部署首选
SGLang 前缀复用密集 RadixAttention 前缀缓存；共享上下文吞吐量 +29%（vs vLLM） 多轮对话、RAG pipeline、Agent 循环
TensorRT-LLM 极致 NVIDIA 性能 手工调优；H100 上比 vLLM 高 15-30%；需 1-2 周编译调优 峰值性能优先、模型固定不变的生产场景
llama.cpp 边缘/本地 MTP 在 Qwen 3.6 27B 上 >×2 加速；Qwen 3.6 35B 上 MTP 有精度退化 CPU/边缘/无 GPU 环境

Modular MAX（第五推理引擎）：使用 graph-compiled Mojo 内核，在高并发场景下对 dense models 性能超越 vLLM。与 vLLM/SGLang/TensorRT-LLM/TGI/LMDeploy 并列为 2026 年五大推理引擎之一。

TensorRT-LLM v1.2.1（NVIDIA 2026，Blackwell 原生优化）：移除独立 TensorRT 引擎构建流程。Llama-3.1 70B TP=4 FP8：TRT-LLM 3,400 vs SGLang 2,900 vs vLLM 2,800 tok/s（InferenceEngineering.tech）。

Qwen3.8 on Ollama / Apple MLX（2026-08 新增）：Qwen3.8 系列（2.4T 稀疏 MoE，512 experts）已全面进入 Ollama、Apple MLX、MLX-VLM 等本地/边缘推理栈。Apple Silicon 被正式确立为一类推理目标。

llama.cpp 突破 100k GitHub Stars：Georgi Gerganov 创建的本地 LLM 推理引擎在量化生态（CPU/边缘/嵌入式）保持主导地位。

TGI（HuggingFace Text Generation Inference）已正式进入维护模式（第三次确认）：HuggingFace 官方博客（2026-08）、GitHub trending（2026-08-22）、LeetLLM 版本清单（2026-08）三方独立确认。TGI 只接受 minor bug fix PR，不再作为未来方向推荐；官方建议迁移路径为 vLLM 或 SGLang。

1.2 PD Disaggregation：正反案例对照与新兴架构

PD Disaggregation 成功场景（正面）：

  • DCP（Decode Context Parallelism，vLLM 2026-08）：KV cache 分布到多卡、计算在单卡，适合 128K+ 上下文。SGLang --dp-size + --enable-dp-attention 等效实现。
  • CXL+PIM（HotInfra 2026）：Prefill 在 GPU HBM，Decode 在 CPU+CXL DDRx，KV Cache 通过 CXL 共享内存互联；32K tokens 生成 DeepSeek-R1-671B 吞吐量 2.4×；CapEx 20.6× / OpEx 17×；Aggregate Bandwidth 63.7 TB/s → 150.7 TB/s（2.4×）。
  • AMPD（arXiv:2602.14516v2，ICML 2026）：自适应多轮 PD 路由，动态决定 co-locate/disaggregate。

PD Disaggregation 失效场景（反面）：

  • Not All Prefills Are Equal（arXiv:2603.13358）：系统论证了 PD disaggregation 在多轮 Agent 场景存在严重低效——多轮 Agent 每次用户输入都触发 prefill，而 prefill 高计算成本在短轮次下无法摊薄。多轮 Agent 场景建议用 native vLLM/SGLang。

1.3 llm-d CNCF Sandbox：Kubernetes 分布式推理编排一级公民

llm-d 正式加入 CNCF Sandbox（2026-03-24）：创始成员 Red Hat + Google Cloud + IBM Research + CoreWeave + NVIDIA。CNCN 背书 = 企业可用性已过临界点，KubeCon EU 2026（阿姆斯特丹）重点议题。

llm-d v0.7（2026-08）：KV cache memory 降低 50-60%（GDS GPUDirect Storage 支持）；EPD（Encode/Prefill/Decode）分解支持；Pure Go ZMQ 实现（消除 CGO 依赖）。

CNCN K8s AI 推理扩展（2026-08-11）：KRO + KAR v1.35 + Kubernetes AI Conformance Program + Kueue + llm-d + vLLM extension。66% 的 GenAI 推理运行在 K8s 上。

NVIDIA Dynamo 1.4.1（2026-08-22 更新）：KV Router + NIXL + Planner + OpenAI 兼容 API。KV Router 智能请求路由 + 前缀感知缓存；Planner SLA 感知调度。Baseten 实测：34-62% 性能提升。

NVIDIA Grove（Spheron 2026-05-19）：NVIDIA Kubernetes CRD，将 prefill/decode/router pods 封装为单一声明式资源，内置 startup ordering、gang scheduling、协同扩缩容；基于 NVIDIA DRA driver + NVLink topology-aware PodClique 放置。适用场景：disaggregated LLM inference 的大规模生产集群。

ai-dynamo/dynamo（GitHub 7.8k⭐，2026-08-21 更新）：数据中心级分布式推理 Serving 框架，Rust 实现，支持 vLLM / SGLang / TensorRT-LLM，Kubernetes 原生，disaggregated serving。与 NVIDIA Dynamo 1.4.1 / llm-d CNCF 关系待独立核验。

二、关键工作脉络：从单点突破到系统协同

2.1 PagedAttention 与 vLLM MRV2

arXiv:2309.06180（vLLM 团队）引入 PagedAttention，将操作系统虚拟内存分页管理思想引入 KV cache 管理。核心贡献：PagedAttention（GPU 显存按需分页分配，消除碎片）、Continuous Batching（动态插入新请求）、Prefix Caching（共享 KV cache 减少重复计算）、Chunked Prefill（大 prompt 分块处理避免饥饿）。

MRV2（Model Runner V2）是 vLLM 0.17+ 从头重写的模型执行层，在 v0.28+ 成为所有 dense 模型的默认执行路径。Spheron 2026-08 实测（Qwen3-0.6B @ GB200）：MRV2 带来 56% 更高吞吐，GLM-4.7-FP8 @ 4×GB200 带来 6.3% 更低 TPOT。MRV2 核心设计：① 解耦 persistent request state from per-step input tensors（消除 CachedRequestState 冗余备份）；② async dispatch 分离 CPU 调度与 GPU 执行；③ Triton kernels GPU-native 实现。FlashInfer 定位：Blackwell（B200/B300）FlashInfer 为默认 attention backend；Hopper（H100/H200）FlashAttention 默认，VLLM_ATTENTION_BACKEND=FLASHINFER 可选开启。

2.2 调度理论：GoodServe E2E-SLO Goodput 调度

GoodServe（arXiv:2605.16867）：Agentic LLM 推理的端到端 SLO Goodput 调度。核心问题：Agentic LLM 推理有明确的 E2E 延迟 SLO 要求，现有 batched serving 模式下 request-level response time 在 GPU 上的实际执行效率受 token 形状（LinL 和 LoutL）和竞争请求共同影响，难以精确计算。核心贡献：① 问题建模——在 GPU 异构资源上调度 agentic LLM 推理，将 GPU 组合作为输入条件而非优化目标；② Goodput 定义——满足 SLO 的请求比例（区别于 pure throughput）；③ 在线调度框架——异构 GPU 资源下最大化 goodput 的算法。与 SageServe / llm-d 互补：llm-d 是 K8s 协调层解决跨实例调度；GoodServe 是单节点 GPU 组合优化。

AMPD（arXiv:2602.14516v2，ICML 2026）：Multi-round 自适应 PD 分离。核心问题：多轮 LLM 推理（ReAct 风格 agent）中，prefill 和 decode 工作负载交替出现，传统 co-location 或固定 PD 分离策略均无法高效适应这种交错模式。方案：① 自适应路由机制（Adaptive Routing）——根据运行时 prefill/decode 负载动态分配资源；② Prefill 重新排序策略（Prefill Reordering Policy）——平衡 prefill 和 decode 负载；③ 与 Dynamo（NVIDIA 固定 PD 分离）对比——Dynamo 是静态分离，AMPD 是动态分离。目标基准：antlybench、BFCL 等 agent 基准。

LAAR（arXiv:2604.15732v1）：Long-Context NUMA-Aware 分布式 LLM 路由。核心问题：Long-context 场景下 GPU-CPU 之间的 NUMA 内存访问成为分布式 LLM serving 的瓶颈（GH200 NVL2 配置：144GB HBM + 480GB DRAM）。关键实现：① NUMA 亲和性配置——numactl 控制 NUMA memory affinity（GH200 真实环境）；② Envoy EPP Filter 实现——作为 External Processing Filter 策略实现，接入 llm-d MaxScorePicker；③ 路由逻辑——提取 request feature → 评估 Q(m,x) 成功率和 L(m,x) 延迟 → 选最低 cost 端点。适合 long-context RAG / 多文档推理场景。

Token-Operations 四层架构（arXiv:2606.20295v1）：Layer 1 Multi-model Fusion（模型能力量化、智能路由、级联、集成）；Layer 2 Model Optimization（Attention 改进、MoE、CoT、KV Cache 压缩、投机解码、量化、蒸馏）；Layer 3 Compute-Model Fusion（算子融合、内存访问优化、基础算子加速、引擎参数调优）；Layer 4 Compute-Network-Model Fusion（多节点并行、KV Cache 集群调度、粘性会话路由、语义缓存复用、动态批处理）。重要背景：中国国家数据局 2026-03 数据——中国日均 token 处理量已超 140 万亿（年化约 5 京）。

2.3 投机解码（Speculative Decoding）全景

主流 Drafting 算法（2026-08 更新）：

方法 核心机制 关键数据 状态
EAGLE3 自回归 draft，层层验证 Qwen3-Coder-Next 80B MoE：SWEBench 1.52× vLLM mainline
P-EAGLE（vLLM 2026-03） 并行预测多个 draft token，多树推测 Coding benchmark 4-5× 基线，20-30% over EAGLE3 vLLM mainline
DSpark（ICML 2026，LMSYS） Confidence-Driven Variable-Length，semi-autoregressive block draft + 自适应 verify window DeepSeek-V4-Pro TP8 B300：383.7 tok/s；bs=1-256 全范围最优；V4-Flash 60-85% per-user 加速，V4-Pro 57-78%；⚠️ AIME25 97.08→93.96 精度回退 SGLang mainline + vLLM plugin
DFlash（ICML 2026，LMSYS） Block diffusion drafting + KV injection >4.3× 基线吞吐，1.5× MTP；高并发 >8 时退化至基线以下 vLLM 0.27 集成
Arctic Inference（Snowflake） Suffix Decoding，CPU 上 20μs/token，无需 draft model 无 draft model vLLM 插件
SSD（Second Speculative Decoding） 二阶推测：draft model 自己验证自己后再交 target 验证 最高 2× over spec decode SGLang 已支持

vLLM Q3 Roadmap 投机解码重点：SIG Speculative Decoding 聚焦 UX 改进（speculation by default）与 Dynamic Speculative Decoding（高并发异构 workload 优化），目标 1000+ TPS。

DSpark 精度回退 Bug（GitHub Issue #32038，2026-07-22）：SGLang + DSpark 在 DeepSeek-V4-Flash 上开启投机解码后，AIME25 精度从 97.08% 降至 93.96%（-3.12%）。环境：4×B300 SXM6，PyTorch 2.11.0+cu130。官方 fix 进行中，生产环境开启 DSpark 需评估精度损失风险。

三、KV Cache 管理：五纪元与技术路线图

3.1 Five Eras of KVCache（Modular 2026-02 框架）

Modular 工程团队系统化梳理 KVCache 技术演进五个时代，提供第一个权威纵向技术分期框架：

  • Era 1 — Naive Contiguous Allocation：无缓存，KV tensor 连续分配，60-80% 碎片化内存浪费
  • Era 2 — PagedAttention（vLLM 革命）：内存碎片从 60-80% 降至 <4%；vLLM 核心贡献
  • Era 3 — Prefix Caching / RadixAttention（SGLang）：跨请求共享前缀 KV cache；SGLang RadixAttention 前缀树自动复用
  • Era 4 — Disaggregated KVCache（跨节点）：PD Disaggregation；KV Cache 分布到专用 workers 或跨节点；Mooncake Store、llm-d CNCF Sandbox 属于此 era
  • Era 5 — Compression/Quantization（当前进行时）：TurboQuant / ChunkKV / OBCache / DistillCache / ReCache / Topology-Aware v2；2026 年 ACL 2026 Findings 集中发布多件
  • Era 6 — KV Cache 作为第一等数据对象（2026 新兴）：HPCwire（2026-07-27）+ LMCache blog（2026-04-28）系统论证 KV cache 已从「优化技巧」演变为「核心基础设施」，与模型权重并列的存储项目；NVIDIA CMX（原 ICMS）正式将 KV cache 存储标准化为专用内存类型；Memory Pool Architecture 允许 KV cache 在多模型/多请求间池化复用

3.2 KV Cache 工程数学基础

KV Cache 显存公式：Memory = 2 × batch_size × seq_len × num_layers × num_kv_heads × head_dim × precision_bytes

Llama 2 70B 单序列 32K 上下文 KV Cache = 10.74 GB（80 层 × 8 KV heads × 128 head_dim × FP16）

PagedAttention 将内存碎片从 60-80% 降至 <4%

GQA（Grouped Query Attention）是降低 KV Cache 最重要的架构选择

3.3 ACL 2026 Findings：KV 优化件批量填补 Era 5

ACL 2026 Findings 新增 KV 优化件（六件）：

技术 来源 说明
MiniKV Akshat Sharma et al. 2-bit layer-discriminative KV 量化
KVTuner Xing Li et al. Sensitivity-aware layer-wise mixed-precision KV 量化
HiFC Inho Jeong et al. Flash-based KV cache swapping GPU memory ↔ SSD
TinyServe Dong Liu et al. Query-aware cache selection
QJL Amir Zandieh et al. 1-bit 量化 JL Transform for KV cache
ChunkKV Xiang Liu et al. 语义保留的 chunk 级 KV cache 压缩
OBCache Yuzhe Gu et al. Hessian 引导的 token 重要性评分最优脑剪枝
LLM-AnDPro Zijie Geng et al. 锚方向投影的 KV cache 精确 eviction
HCAttention Neurocomputing 2026 GPU cache 压缩至 12.5%，动态可逆 eviction 算法

KV Cache 优化全景综述（arXiv:2603.20397）：五大方向系统归纳——cache eviction、cache compression、混合内存方案、新型 attention 机制与组合策略。指出自适应多阶段优化流水线是未来研究的重要方向。

3.4 Cache Compression（压缩 — Era 5 核心）

GEAR（arXiv:2403.05527，被引 186 次）：三合一压缩（统一量化 + 低秩矩阵近似 + 稀疏矩阵补救离群点），4-bit KV cache 近无损 + 2.38× 吞吐量 + 2.29× 峰值内存降低。

TurboQuant（arXiv:2605.19660，ICLR 2026，Google Research）：两阶段管道——① PolarQuant（AISTATS 2026）：随机正交旋转重新分布方差，再用标量量化器精确量化 KV；② QJL（Quantized Johnson-Lindenstrauss）：对量化残差应用 1-bit QJL 校正。无需训练或校准。TurboQuant 正式发表 ICLR 2026：LongBench benchmark 全线质量保持。GitHub 开源实现（OnlyTerp/turboquant）已上线，AMD Quark Team 2026 在 vLLM 中产品化。

Quantization-Aware Healing（arXiv:2608.20953，2026-08）：低成本服务大语言模型日益意味着交付既经过结构压缩至部分参数、又量化到 4 bit 的模型。这两个步骤叠加后会显著降低推理、数学、代码以及长上下文能力。默认方案 QAT（Quantization-Aware Training）将压缩并量化后的模型重新拟合到硬标签——收敛缓慢且在峰值之后出现性能崩塌。Quantization-Aware Healing（QAH）替代方案：结构压缩后的模型从未见过完整精度信号，直接 QAT 拟合硬标签存在固有困难；QAH 通过轻量级修复阶段恢复压缩带来的精度损失，无需完整重训练。

HiSparse（arXiv:2608.07009，Stanford+UIUC）：精确的、与索引器无关的分层 KV cache，HBM 仅维护选定条目，首次让 KV cache 容量可超过 HBM 的请求也可服务。已合并入 SGLang 上游。峰值生成吞吐提升最高 4.7×。

FlashPrefill V2（arXiv:2608.19758，2026-08）：Block-Sparse Prefill Attention for Long-Context LLM Serving。引入均值修正项，有效抑制近似误差，即使在极端稀疏度下也能将性能下降保持在可控范围；使用 PackGQA 内存访问、warp specialization 和 pingpong 流水线重新设计稀疏注意力算子。⚠️ 47.26× 是 H200 FP8 数字；国内算力主要是 H20，两者算力/带宽/架构有差异，H20 实际加速比未独立核验。

DASH（arXiv:2608.14333）：High-Bandwidth Flash 与 HBM 双层 KV Cache 管理，专为 MoE LLM 设计。核心问题：MoE LLM KV cache 容量超 HBM（Llama 4 Maverick KV cache 197.41 GB，超过单卡 HBM）。HBM 吸收细粒度写入；Flash 批量写回。关键数据：Llama 4 Maverick 上比 RelayOnly 提升 1.92× 吞吐量，降低 E2E 延迟 48%。

ReCache（arXiv:2608.19662）：针对 Agent 工具 schema 重复编码场景的专项 KV cache 复用方案。关键数据（agent 场景实测）：TTFT 加速 3.655×；分配 KV 张量内存减少 92.43%；注意力加速 1.423×。

C²KV（arXiv:2607.17715，2026-08）：统一 KV cache 存储和内存传输框架，解决 LLM 非前缀上下文复用时的 KV 瓶颈。4× 压缩比下 NDCG@5 仍保持 0.71。使用轻量级 sidecar extractor + 可学习压缩 token，零参数变更实现 up to 17× 推理加速（极端上下文长度下）。核心洞察：PagedAttention 解决单请求内内存管理；C²KV 解决跨请求复用——两者正交可叠加。

An Internet for the KV Cache（arXiv:2608.01526，2026-08）：KV Cache 应成为基础设施级一等公民（类似 CDN）。联合优化：compression + offloading + prefetching + routing + recomputation + scheduling + model-level reuse。HotCloud/OSDI 级别论文视野，多步 Agent 工作负载（RAG、Tool Use、代码执行、多模态推理）天然产生大量重叠上下文，KV Cache 复用机会巨大但当前研究缺乏联合设计。引用系统：NVIDIA Dynamo（2026）、LMCache（2025 企业级 KV Cache 层）。

Online KV Cache Compaction for LLM Agents（arXiv:2608.00902，LinkedIn，2026-08）：针对 Agent 场景的在线 KV Cache 压缩实证研究。Agent 工作负载具有长时记忆、跨请求状态保持的特点，KV Cache 压缩尤为关键。对比两种 sequence-level compaction 家族：① Token Eviction（TE）——用 proxy queries 对缓存位置打分，保留注意力权重最高位置的原始 KV；② Attention Matching（AM）——在选择之上额外拟合加性注意力偏置，重建值使输出与完整 cache 匹配。核心发现：立即 compaction 通常会降精度；延迟到使用 agent 自身后续 generation 的 queries 时，能恢复大部分精度损失。Qwen3.5-27B 上 3.5× KV 压缩比 + 4.2× 吞吐量提升；Gemma-4-31B 上 1.7× 吞吐量提升。

ReCo：Reward-Coordinated KV Cache Compression for Reasoning（arXiv:2608.04771，2026-08）：CoT 推理场景 KV 压缩的关键发现——长度膨胀问题（Length Inflation）：现有 KV 压缩方法（R-KV、Cai et al. 2026；RPC、Song et al. 2026）压缩单 token 注意力成本，但 CoT 推理链被迫生成更多 token，部分抵消节省。在 R-KV 25% 压缩率下：DeepSeek-R1-Distill-Qwen-7B 平均生成长度从 3268→4538 tokens（+38.8%），DeepSeek-R1-Distill-Llama-8B 从 4409→7891 tokens（+79%）。ReCo 引入 Reward 信号协调，对 KV Cache 做差异化压缩，平衡缓存大小与推理质量。

Cross-Model KV Cache Transfer（arXiv:2608.03893，2026-08）：跨模型 KV Cache 复用挑战——源模型与目标模型层数、hidden dimension、KV head 配置可能不同。现有方法（C2C、LatentAlign、IAM、DroidSpeak）均需梯度训练或强架构约束。本文提出无需梯度、跨尺度（不同参数量的模型）、传输实际 KV 值、闭式解（closed-form）的映射方法。可泛化到同家族但不同规模模型（如 Qwen2.5-7B→Qwen2.5-14B）。

LiveMem（arXiv:2608.00902 同批次，2026-08）：长期 Agent 的状态连续性。核心问题定义：现有 context retention、summarization、retrieval 都无法在 working context 变化时保持持久状态。提出新抽象——state continuity under context turnover：通过固定容量 memory state 承载历史信息，生命周期独立于 active context。在 pretrained full-attention LLM 上额外增加 memory state，Main attention path 保留 bounded KV window（如滑动窗口），即使 supporting evidence 已从当前 context 移除，仍能回答相关问题。

PinSieve（arXiv:2608.24040）：生产级选择性 VLM Serving Agent + 企业内容质量分诊的可治理记忆飞轮。核心设计：仅作用于上游轻量模型未解决的灰色地带切片，在线暴露标量路由评分，保留受控人工升级机制。在该切片上，比上一版生产模块多过滤 2.05× 不可操作项，同时误报率略降。工程意义：生产 VLM serving 的 selective 路由 + governance + memory 飞轮联合设计范式；代表 2026 年企业级多模态推理部署的成熟度标杆。

Harvest P2P GPU Cache 共享（arXiv:2602.00328v1）：生产集群 GPU 利用率实证研究（FlexPipe，两大云厂商两周实测）。平均 GPU 显存利用率：43.48%；中位数：28.78%；38.44% 的采样落在 10-30% 利用率区间。机会主义 P2P GPU Cache 共享利用其他 GPU 的空闲显存存储 KV Cache，显著降低延迟。

Agent Memory 持久化 Q4 KV Cache（arXiv:2603.04428v1）：Edge 设备（手机/笔记本）上的多轮 Agent 推理，每次重启后 KV Cache 全部丢失，冷启动 TTFT 代价极高——论文实测 15.7s = 78.5s dead time。方案：跨会话持久化 KV Cache 到 disk（safetensors 格式）+ 支持 cache eviction 和 device sleep/wake 循环后的 warm-start + Q4（INT4）压缩减少存储开销。vllm-mlx 在 Apple Silicon 上比 llama.cpp 吞吐高 21-87%。

3.5 Hybrid Memory（混合存储）

TTKV（arXiv:2604.19769）：Temporal-Tiered KV Cache（HBM=短期，DRAM=长期）；128K 上下文任务跨层流量减少 5.94×，延迟降低 76%。

ICMSP / CMX（NVIDIA CES 2026）：三层存储（GPU HBM → CPU DRAM → NVMe SSD），cuFile GPU-direct NVMe + BlueField-4 DPU；NIXL（NVIDIA Inference Xfer Library）= KV block 传输协议。NVIDIA 将 ICMS 更名为 CMX（Compute Memory Transfer），正式将 KV cache 存储定位为与模型权重并列的基础设施层。

Mooncake（kvcache-ai/Mooncake）：Kimi 的 LLM 服务平台，PD 分离架构 + KVCache 池化。2026-05-07 vLLM 正式集成 Mooncake Store——vLLM + Mooncake Store 在真实 agentic traces 上实现 3.8× 更高吞吐、46× TTFT 降低、8.6× 端到端延迟降低。

HotInfra 2026 CXL+PIM KV Cache Server：Penguin Solutions MemoryAI（2026-03 量产）——3TB DDR5 + 8×1TB CXL add-in cards（最多 11TB），专为 KV cache offload from GPU HBM 设计，10× 比 NVMe-based 方案更快，NVIDIA Dynamo 原生兼容。DeepSeek-R1-671B 32K token 测试：2.4× 吞吐，CapEx 20.6× 降低，OpEx 16.8× 降低，带宽 150.7 TB/s（2.4×）。

3.6 KV Cache 可观测性工具链

kv-cache-analyzer（bs258q/kv-cache-analyzer，MIT）：生产 KV cache 的 CLI 分析工具，提供多场景 LRU hit rate 实测数字。

vLLM Prefix Caching 失效条件（工程实战）：

失效原因 机制 解决方案
空格差异 hash 不同 规范化 prompt 格式
tool definition 顺序变化 hash 不同 固定工具定义顺序
时间戳位置不对 hash 不同 时间戳移至独立字段
任意 token 差异 必须重新计算 共享前缀结构化

四、推理成本工程与基准

4.1 llm-d：Kubernetes 分布式推理编排成为 CNCF Sandbox

llm-d v0.7（2026-08）：KV cache memory 降低 50-60%（GDS GPUDirect Storage 支持）；EPD（Encode/Prefill/Decode）分解支持；Pure Go ZMQ 实现（消除 CGO 依赖）。核心组件：Endpoint Picker（EPP）+ KV Router + 预测延迟调度 + batch gateway。

NVIDIA Dynamo 1.4.1（2026-08-22 更新）：KV Router + NIXL + Planner + OpenAI 兼容 API。KV Router 智能请求路由 + 前缀感知缓存；Planner SLA 感知调度。Baseten 实测：34-62% 性能提升。

NVIDIA Grove（Spheron 2026-05-19）：disaggregated LLM inference 大规模生产集群的声明式 K8s 资源模型。

KEDA 按 KV cache pressure 扩缩：vllm:gpu_cache_usage_perc > 80–85% 触发 scale-up——比 queue depth 信号更提前（queue depth > 0 出现时已在加延迟）。

OpScale（arXiv:2608.13499，MSRA）：达成 SLO 达标率的同时，成本降低 36.3%。核心发现：prefill 是 compute-bound，decode 是 memory-bound——两者弹性特征迥异。

4.2 推理经济学与生产工程

推理后端诱导方差（arXiv:2605.19537v2）：核心发现：不同推理引擎（vLLM vs HuggingFace transformers vs TensorRT-LLM）运行相同模型时，benchmark 分数存在显著差异。"后端诱导方差"：可以错误地淘汰或抬升模型，影响学术排名和真实部署安全性。工程意义：AI infra 工程师必读；benchmark 设计时需将推理引擎作为控制变量。待核验：具体评测基准和数值范围需原文核验。

Patterson 推理硬件四大机会（arXiv:2601.05047，Ma & David Patterson，Google Research）：核心命题：LLM 推理的核心挑战是内存和互联，而非计算。四大研究机会：① High Bandwidth Flash（10× 内存容量，HBM 类带宽）；② Processing-Near-Memory / 3D 堆叠；③ 低延迟互联加速通信；④ 移动端适配方案。

Idle GPU = P&L 损失（HF Dharma AI Blog 2026-07-30）：类比：idle GPU = 接地飞机（airplane on the ground generates no revenue）。核心问题：GPU 空闲是 AI 基础设施的主要浪费来源（直接 P&L 损失）。三个维度：① GPU 利用率可视化（Harvest 43.48% 是实证基础）；② goodput scheduling（与 GoodServe E2E-SLO goodput 呼应）；③ 抢占式调度（Spot/Preemptible for inference）。

Spheron Context Engineering Guide（2026-08）：2026 年生产 Agent 单次请求实际输入 50,000–500,000 tokens。vLLM 自动前缀缓存（APC）默认 16-token block 粒度哈希复用。Context Engineering 是 2026 年生产 LLM 最大成本杠杆。

Continuous Batching 23× 吞吐基准（Anyscale，MLwithDev 2026-08）：Continuous Batching + vLLM PagedAttention = OPT-13B A100 40GB 上 23× 吞吐（vs naive batching）。

gpu_memory_utilization 软限制陷阱（CSDN 源码分析，2026-08）：gpu_memory_utilization 是软限制/目标预算，非硬限制；0.8 比 0.7 更容易 OOM——原因是 warmup dummy requests 阶段已分配大部分显存。CUDA graphs 额外开销：1~3 GiB per GPU。

4.3 LLM 推理引擎 Bug 分类：RETAIN 研究

RETAIN（arXiv:2506.09713，2025-06）：首个对 LLM 推理引擎 Bug 的系统性实证研究，覆盖 vLLM、SGLang、DeepSpeed、TensorRT-LLM、llama.cpp、MLC-LLM 六种引擎。

Bug 类型 vLLM 代表案例 根因
资源分配错误 (RE.1) — 内存分配计算错误导致 OOM（明明有可用内存却报 OOM）
Cache 管理错误 (RE.2) llama.cpp #3825 KV cache shift 操作实现缺陷
多设备管理错误 (RE.3) vLLM #7472 无法检测不同 GPU 间的 CUDA compute capability 差异，导致多卡设置错误
资源释放错误 (RE.4) 多个案例 不当资源释放导致泄漏/崩溃

vLLM 重点 bug 分布：Model loader 21%（分布式加载、设备分配逻辑）；Operators 17%（云端优化算子缺陷）。Engine setup 关键发现：29% 的问题源于跨平台/跨设备因素；vLLM issue #7472（异构 CUDA 环境不同 GPU compute capability 共存下错误检测和资源分配失败）是多卡部署高频痛点。

4.4 生产调试运行手册

vLLM OOM 诊断两型（Kubenatives Runbook）：

类型 触发条件 日志关键词 Exit Code
CPU OOM（OOMKilled） 容器超内存 limit Reason: OOMKilled 137
GPU OOM（CUDA OOM） KV cache 超显存 torch.cuda.OutOfMemoryError 1

CPU OOM 内存规则（按模型规模）：8B model: memory limit = 16-24 Gi / 13B model: memory limit = 24-32 Gi / 70B model: memory limit = 48-64 Gi

OOM 排查四步法（Spheron）：① --gpu-memory-utilization 从 0.90 降到 0.85；② 降低 --max-model-len（每 1024 token 上下文额外消耗 KV cache VRAM）；③ --dtype float16 → --dtype fp8（H100 上 VRAM 减半）；④ 增加 --tensor-parallel-size。

TTFT 慢诊断：增加 --max-num-seqs：并发序列不足，GPU 饱和度不够；增加 --max-num-batched-tokens：每 forward pass 处理 token 数过少；客户端逐个发请求等响应：vLLM 连续批处理需要并发请求流才能生效。

CUDA Graph 崩溃隔离：--enforce-eager 禁用 CUDA Graph，可隔离出导致崩溃的具体 CUDA 操作。

Docker 关键参数：--gpus all（GPU passthrough）+ --shm-size 256m（共享内存，tensor parallelism 必需）+ --ipc=host（替代 --shm-size，全量 host IPC namespace 访问）。⚠️ 不要给 vLLM pod 设置 CPU limits——CPU throttling 会拖慢 tokenization 和请求处理，只设 CPU requests 用于调度。

vLLM 生产监控端点：http://localhost:8000 + http://localhost:8000/metrics。

bench_serving 完整命令库（CSDN 实测）：SGLang benchmark 命令：python3 -m sglang.bench_serving --backend sglang --dataset-name random --num-prompts 1024 --random-input 1024 --random-output 128 --request-rate 128 --max-concurrency 128 --warmup-requests 16 --base-url http://localhost:30000；vLLM benchmark（含 pd-separated）：python3 -m sglang.bench_serving --backend vllm --model Qwen/Qwen3-32B-FP8 --dataset-name random --num-prompts 1024 --random-input 2048 --random-output 512 --max-concurrency 512 --warmup-requests 1 --pd-separated --base-url http://localhost:9000

Prometheus 内存监控规则：container_memory_working_set_bytes{container!="POD"} / on(pod) container_spec_memory_limit_bytes > 0.8

SGLang RadixAttention 高 cache hit rate 条件（75-95%，多轮 agent 场景）：固定 system prompt + tool definitions 放在 prompt 顶部（所有请求共享前缀）；工具 schema block 放在用户 query 之前（否则每个请求 unique prefix，cache 失效）；缓存体积太小（频繁驱逐）→ 增加 --max-radix-cache-len。

SGLang RadixAttention 驱逐策略：--radix-eviction-policy lru（选项: lru, lfu, fifo, mru, filo, priority）。

4.5 向量数据库与 RAG 推理协同

pgvector 0.8（2026 生产基线）：迭代扫描（Iterative Scan）——解决 filter+向量混合查询的截断问题——HNSW 索引在 filter 后可能返回不足 K 条结果，<100ms 延迟，<100M 向量场景完全够用；并行 HNSW 建索引：多核机器上建索引时间减少 30-50%；halfvec 量化：降低存储开销，适合成本敏感型项目；选型结论：已有 Postgres 基础设施 → 优先 pgvector；10M-50M 向量是迁移临界点；pgvector + pgvectorscale 让 RDBMS 重新成为向量搜索首选。

2026 VectorDB 选型格局：

数据库 定位 核心场景
Pinecone 托管生产 RAG 默认首选
Weaviate AI 原生混合搜索 多模态 RAG
Milvus/Zilliz 大规模开源向量 >100M 向量
Qdrant 过滤密集型自托管 自托管 RAG
Elasticsearch 企业混合+多模态 企业搜索
Chroma/FAISS 原型实验 快速实验
LanceDB 多模态 AI workloads 多模态
Redis 低延迟 AI apps 缓存+语义记忆
pgvector Postgres 团队 <100M 向量

4.6 HF State of Open Models: Summer 2026（关键生态数据）

指标 数据
HF Hub 模型总量 296 万（+22% YoY）
数据集总量 100 万（+40% YoY）
Spaces 总量 144 万（+44% YoY）
gguf 库仓库存量增长 464%（7 个月内）
Apple MLX 增长 148%
Qwen 衍生模型数 151,448（Llama 的 4.7×）

标志性转变：Agent（机器用户）首次成为 HF Hub 第一大用户类型——意味着基础设施需要面向机器友好的 API 和工具。

五、Agent 生产推理：三层架构收敛

5.1 Agentic 推理三层栈

MCP 2.0 无状态协议（2026-07-28）：废除 initialize/initialized 握手和 Mcp-Session-Id header；每个请求独立携带协议版本、客户端身份、客户端能力（放在 _meta 中）；任何请求可路由到任何服务器实例，支持原生 round-robin 负载均衡；MRTR（Multi Round-Trip Requests）：替代 server-initiated 双向流；攻击面新增：Handle Hijacking（模型可见字符串可被 echo 和传递）。

Lilian Weng Harness Engineering（2026-07-04）：Harness 定义：Harness = LLM + Memory + Tools + Planning + Action + Workflow Design + Eval + Permission Controls + Persistent State。三大设计模式：Workflow Automation（Goal-oriented loop）、File System as Persistent Memory、Sub-agent and Backend Jobs。

ByteByteGo OpenAI Agent Loop（2026-08-01）：Harness → API → Inference 三层架构。Harness 层：Persistent WebSockets、Stable prompt prefixes、Deferred tool discovery、Code Mode；API 层：Tokenize only delta、Parallel safety checks（race 机制）；Inference 层：Cache-aware routing、KV cache lifecycle management、Speculative decoding、PD separation。

5.2 ArcLight：ACL 2026 CPU 推理架构

ArcLight（ACL 2026 System Demonstrations）：在 CPU（而非 GPU）上运行 LLM 推理的轻量化架构，针对 Many-Core CPU 优化。与 llama.cpp/Ollama CPU 推理方向不同，ArcLight 专门针对 Many-Core CPU 拓扑做优化。

六、共识与争议

6.1 共识区域

  1. vLLM + SGLang 双雄格局已定：两框架在 2026 年已共同主导开源推理生态，TGI 正式退出历史舞台（TGI EOL 三重确认）。
  2. PagedAttention / RadixAttention 是基础：两技术分别解决了 vLLM 和 SGLang 的内存管理难题，是现代推理引擎的共同基石。
  3. MoE 模型对推理架构的冲击：Qwen3.8-2.4T（512 experts）、DeepSeek V4（共享专家）、Kimi K3（896 experts）等 MoE 模型使 shared expert overlap 成为 vLLM Q3 Roadmap 重点。
  4. KV Cache 压缩是 Era 5 主线：从 GEAR 到 TurboQuant、HiSparse、DASH，五纪元的 Era 5（压缩/量化）正被 ACL 2026 Findings 批量填补，TurboQuant 已正式发表 ICLR 2026。
  5. K8s 已是推理基础设施标准：66% GenAI 推理运行在 K8s 上，llm-d CNCF Sandbox 标志着 Kubernetes-native 推理编排进入主流。
  6. SGLang 的 Agent 场景天然优势：Schema overhead SGLang（热）深嵌套仅 +6% vs vLLM +42%，对工具调用密集 Agent 场景选型有直接指导意义。
  7. MRV2 已成 vLLM 默认执行路径：v0.28 对 dense 模型 MRV2 默认化，标志 vLLM 核心执行层进入新阶段。
  8. MRV2 + Speculative Decoding 协同优化：MRV2 的 async scheduling 解决 MRV1 投机解码 CPU 同步开销，动态投机解码 + 完整 CUDA graphs 是 2026 年生产部署热点。
  9. DSpark 的 confidence-driven 验证突破：DSpark 通过只验证 draft model 自信位置解决了标准投机解码在 load 下的 scaling 问题，是 ICML 2026 最有生产影响力的工作之一；但 AIME25 97.08→93.96 精度回退是生产部署重大警示（GitHub Issue #32038）。
  10. Miles RL + SGLang 集成：LinkedIn 等公司推动 SGLang 作为 RL 训练循环推理后端，解决训练-推理 mismatch 成为 RL Infrastructure 新方向。
  11. KV Cache 已成第一等数据对象：NVIDIA CMX 正式标准化 KV cache 存储类型，Memory Pool Architecture 从「优化技巧」演变为「核心基础设施」（HPCwire 2026-07 / LMCache 2026-04）。
  12. pgvector 0.8 确立生产基线：迭代扫描解决 filter 截断问题，Postgres 团队无需引入独立 VectorDB。
  13. Five Eras of KVCache 是权威纵向分期：Modular 五纪元框架将 vLLM（Era 2）、SGLang（Era 3）、PD Disagg/Era 4、Compression/Era 5 全部纳入统一叙事。
  14. vLLM Conference 2026 标志基础设施化：首届 vLLM Conference 与 Ray Summit 联合举办，vLLM 从开源项目演化为独立技术生态。
  15. RETAIN Bug 分类是生产故障排查索引：29% 的推理引擎问题源于跨平台/跨设备因素，vLLM #7472 是多卡部署高频痛点。
  16. ReCo CoT 长度膨胀是 KV 压缩新约束：R-KV 25% 压缩导致 DeepSeek-R1-Distill-Qwen-7B 生成长度 +38.8%、Llama-8B +79%，CoT 场景 KV 压缩不能只看缓存大小节省，还需评估生成长度膨胀对总计算量的抵消。
  17. FreeToken 边缘 MoE Serving 开启新方向：arXiv:2608.16157 将个人机器视为统一弹性推理平台，边缘推理的 MoE 化是 2027 年值得关注的范式转变。

6.2 开放争议

  1. PD Disaggregation 适用范围：多轮 Agent 场景（每次用户输入触发 prefill）→ NotAllPrefills 证明 disaggregation 失效；长上下文单请求场景 → CXL+PIM 2.4× 提升有效。场景分叉尚无统一理论。
  2. TurboQuant 数字：ICLR 2026 论文确认 3.5 bits/channel 绝对质量中性，2.5 bits 边缘退化。GitHub 开源实现已上线，AMD Quark Team 已产品化。数字矛盾闭合（评测条件差异）。
  3. FlashPrefill V2 H200 vs H20：47.26× 是 H200 FP8 数字；国内算力主要是 H20，两者算力/带宽/架构有差异，H20 实际加速比未独立核验。
  4. NVIDIA Dynamo 1.4.1 vs ai-dynamo/dynamo vs llm-d CNCF 三者关系：Dynamo 1.4.1 是 NVIDIA 官方商业版本；ai-dynamo/dynamo 是 GitHub 开源 Rust 版本（7.8k⭐）；llm-d 是 CNCF Sandbox 社区项目。三者技术继承关系未独立核验。
  5. 推理后端诱导方差（arXiv:2605.19537）：vLLM vs HuggingFace transformers vs TensorRT-LLM 同一模型 benchmark 分数显著差异，可能影响学术排名的可比性。具体量化范围、涉及基准、vLLM vs SGLang 方差对比待原文核验。
  6. Quantization-Aware Healing vs QAT：QAH 在压缩后 4-bit LLM 上的精度恢复效果在不同的模型架构和压缩方法上是否一致，尚未有系统性研究。
  7. RETAIN Bug 分类的工业代表性：基于 GitHub issue 的分类是否代表生产环境中最严重的问题（issue 多的不等于影响大的）。
  8. DSpark 精度回退的普遍性：AIME25 97.08→93.96 回退是否在所有推理任务类型上都会出现，还是仅在 math/reasoning 密集任务？fix 时间表未知。
  9. FreeToken 与 vLLM/SGLang 的关系：FreeToken 是否计划与主流推理引擎集成，还是独立生态？生态成熟度待观察。
  10. C²KV 17× claim：17× 推理加速 claim；arXiv 原文 NDCG@5 0.71 at 4× compression 更为保守。17× claim 需要原文核验实验条件。

七、趋势与开放问题

7.1 短期趋势（Q3-Q4 2026）

  1. vLLM Q3 Roadmap 六轴落地：MRV2 完成迁移、KV Cache Manager 重新设计、冷启动优化、async scheduling 默认开启，将显著改变生产部署格局。
  2. Speculative Decoding 1000+ TPS 目标：SIG Speculative Decoding 将 DFlash / DSpark / P-EAGLE 集成推向生产，默认开启将降低使用门槛。但 DSpark 精度回退 bug（#32038）需优先 fix。
  3. SGLang v0.6+ 的 RadixAttention 前缀复用优势在高并发 Agent 场景（prefix overlap > 60%）将持续扩大与 vLLM 的体验差距。
  4. ACL 2026 Findings 批量产出：ChunkKV / OBCache / LLM-AnDPro / HCAttention / MiniKV / KVTuner / HiFC / TinyServe / QJL 等 Era 5 路线补全，TurboQuant PolarQuant + QJL 两阶段管道正式发表。
  5. MCP 协议安全危机：Anthropic 官方 MCP SDK 命令执行漏洞（200,000+ 实例 1.5 亿+ 包下载量）+ 7 CVE 集中披露，OWASP MCP Top 10 β 发布，Agent 安全将成为 2026 下半年基础设施重点。
  6. CXL 量产落地：Penguin MemoryAI 首款量产 CXL KV cache 服务器 + NVIDIA Dynamo 原生兼容，CXL 正式进入生产部署阶段。
  7. MRV2 新功能矩阵生产化：EVS / realtime embeddings / Mamba hybrid prefix caching / multimodal-prefix bidirectional attention / dynamic speculative decoding 五项 MRV2 新功能在 Q3 路线图中落地。
  8. Miles RL + SGLang 集成：LinkedIn 等公司推动 SGLang 作为 RL 训练循环的推理后端，解决训练-推理 mismatch。
  9. PinSieve 生产 VLM Serving 范式：selective VLM routing + governance + memory 飞轮成为企业级多模态推理部署参考架构。
  10. NVIDIA CMX 正式落地：ICMS 更名 CMX 后与 Dynamo 1.4.1 深度集成，KV cache 存储正式成为独立于推理引擎的基础设施层。
  11. Quantization-Aware Healing 修复流水线普及：结构压缩+4-bit 量化双重压缩后的精度恢复，QAH 有望成为 2026 下半年部署标准流程。
  12. RETAIN Bug 分类驱动推理引擎质量工程：六引擎 bug 分类成为 vLLM/SGLang 各自质量门的系统性参照，vLLM #7472 的 fix 将改善多卡部署稳定性。

7.2 长期方向（2027-2028）

  1. KV Cache 作为内容分发系统：An Internet for the KV Cache（arXiv:2608.01526）概念框架指明方向——compression + offloading + prefetching + routing + recomputation + scheduling + model-level reuse 联合优化。
  2. CXL+PIM 硬件成熟：HotInfra 2026 已展示 2.4× 吞吐 + 20.6× CapEx 降低，但 CXL + PIM-DIMM 产业链尚未大规模量产，2027-2028 是关键窗口。
  3. Disaggregated Serving 走向多级：vLLM Conference State of vLLM 2026 已宣布 multi-tier KV offloading，Era 4 从单级 PD 走向多级缓存层次。
  4. Edge-Native MoE Serving：FreeToken（arXiv:2608.16157）将个人机器视为统一弹性推理平台，开放权重 → 可部署本地软件，边缘推理的 MoE 化是 2027 年值得关注的范式转变。
  5. Miles RL + SGLang 深度集成：SGLang 作为 RL 训练循环推理后端解决训练-推理 mismatch，若被更多 RL 框架采用，将重塑 RL Infrastructure 架构。
  6. Five Eras 演进到 Era 7：KV Cache 作为第一等数据对象（CMX 标准化 + Memory Pool Architecture）将从「优化技巧」演变为「核心基础设施」， Era 7 的具体形态将在 2027 年明朗化。
  7. CoT 推理 + KV 压缩联合优化：ReCo 揭示的长度膨胀问题将推动 CoT 专用 KV 压缩策略研究，非均匀压缩 + Reward 信号协调是 Era 5 的重要分支。

八、引用与参考

主要参考来源（inference.md 锚入的 arXiv 编号，已去重）：

  • arXiv:2303.05527
  • arXiv:2309.06180
  • arXiv:2311.06281
  • arXiv:2403.05527
  • arXiv:2404.19769
  • arXiv:2404.26557
  • arXiv:2502.07115
  • arXiv:2502.20330
  • arXiv:2504.11320
  • arXiv:2504.15464
  • arXiv:2504.19874
  • arXiv:2506.04565
  • arXiv:2506.09713
  • arXiv:2507.06608
  • arXiv:2509.09505
  • arXiv:2510.09665
  • arXiv:2511.01815
  • arXiv:2512.09196
  • arXiv:2601.06288
  • arXiv:2601.07711
  • arXiv:2601.09668
  • arXiv:2601.17549
  • arXiv:2601.19139
  • arXiv:2601.20309
  • arXiv:2602.00328
  • arXiv:2602.01129
  • arXiv:2602.04900
  • arXiv:2602.10238
  • arXiv:2602.11688v3
  • arXiv:2602.14516v2
  • arXiv:2602.19127
  • arXiv:2602.21548
  • arXiv:2603.04428
  • arXiv:2603.05527
  • arXiv:2603.07379
  • arXiv:2603.08739
  • arXiv:2603.09619
  • arXiv:2603.11768
  • arXiv:2603.12831
  • arXiv:2603.13358
  • arXiv:2603.15569
  • arXiv:2603.17456
  • arXiv:2603.20397
  • arXiv:2603.21354
  • arXiv:2604.00499
  • arXiv:2604.01395
  • arXiv:2604.01927
  • arXiv:2604.03143
  • arXiv:2604.07609
  • arXiv:2604.11001
  • arXiv:2604.12374
  • arXiv:2604.15464
  • arXiv:2604.15732
  • arXiv:2604.16395
  • arXiv:2604.16548
  • arXiv:2604.17227
  • arXiv:2604.19157
  • arXiv:2604.19769
  • arXiv:2604.25724
  • arXiv:2604.25899
  • arXiv:2604.26557
  • arXiv:2605.00528
  • arXiv:2605.01280
  • arXiv:2605.01920
  • arXiv:2605.02189
  • arXiv:2605.03344
  • arXiv:2605.03375
  • arXiv:2605.04595
  • arXiv:2605.05287
  • arXiv:2605.11186
  • arXiv:2605.11733
  • arXiv:2605.15051
  • arXiv:2605.16867
  • arXiv:2605.17613
  • arXiv:2605.19537
  • arXiv:2605.19660
  • arXiv:2605.23215
  • arXiv:2605.24217
  • arXiv:2605.27744
  • arXiv:2605.29639
  • arXiv:2605.31097
  • arXiv:2606.00760
  • arXiv:2606.01927
  • arXiv:2606.02964
  • arXiv:2606.03811
  • arXiv:2606.03910
  • arXiv:2606.06302
  • arXiv:2606.06535
  • arXiv:2606.07362
  • arXiv:2606.07819
  • arXiv:2606.08635
  • arXiv:2606.08950
  • arXiv:2606.08990
  • arXiv:2606.09713
  • arXiv:2606.11916
  • arXiv:2606.13681
  • arXiv:2606.14589
  • arXiv:2606.16135
  • arXiv:2606.16867
  • arXiv:2606.17104
  • arXiv:2606.19746
  • arXiv:2606.20295
  • arXiv:2606.25605
  • arXiv:2606.26875
  • arXiv:2606.28565
  • arXiv:2606.29708
  • arXiv:2606.30391
  • arXiv:2607.00482
  • arXiv:2607.00501
  • arXiv:2607.00760
  • arXiv:2607.01065
  • arXiv:2607.01299
  • arXiv:2607.01520
  • arXiv:2607.01792
  • arXiv:2607.02043
  • arXiv:2607.02574
  • arXiv:2607.05061
  • arXiv:2607.05376
  • arXiv:2607.05876
  • arXiv:2607.05936
  • arXiv:2607.06519
  • arXiv:2607.07953
  • arXiv:2607.08028
  • arXiv:2607.08057
  • arXiv:2607.09172
  • arXiv:2607.09248
  • arXiv:2607.09372
  • arXiv:2607.11643
  • arXiv:2607.11644
  • arXiv:2607.12756
  • arXiv:2607.13125
  • arXiv:2607.13960
  • arXiv:2607.14277
  • arXiv:2607.14541
  • arXiv:2607.17715
  • arXiv:2607.18141
  • arXiv:2607.19712
  • arXiv:2607.21848
  • arXiv:2607.22091
  • arXiv:2607.22157
  • arXiv:2607.22448
  • arXiv:2607.22529
  • arXiv:2607.23373
  • arXiv:2607.23693
  • arXiv:2607.23933
  • arXiv:2607.24027
  • arXiv:2607.24062
  • arXiv:2607.24475
  • arXiv:2607.25398
  • arXiv:2607.25431
  • arXiv:2607.26410
  • arXiv:2607.26475
  • arXiv:2607.26627
  • arXiv:2607.26637
  • arXiv:2607.27042
  • arXiv:2607.27090
  • arXiv:2607.27918
  • arXiv:2607.28319
  • arXiv:2607.28633
  • arXiv:2607.28675
  • arXiv:2607.29167
  • arXiv:2607.29377
  • arXiv:2607.29459
  • arXiv:2608.00101
  • arXiv:2608.00675
  • arXiv:2608.00742
  • arXiv:2608.00881
  • arXiv:2608.00902
  • arXiv:2608.00922
  • arXiv:2608.01247
  • arXiv:2608.01326
  • arXiv:2608.01462
  • arXiv:2608.01526
  • arXiv:2608.01628
  • arXiv:2608.01651
  • arXiv:2608.01718
  • arXiv:2608.01735
  • arXiv:2608.01964
  • arXiv:2608.01975
  • arXiv:2608.02162
  • arXiv:2608.02515
  • arXiv:2608.02703
  • arXiv:2608.02791
  • arXiv:2608.02870
  • arXiv:2608.02989
  • arXiv:2608.03036
  • arXiv:2608.03216
  • arXiv:2608.03392
  • arXiv:2608.03499
  • arXiv:2608.03796
  • arXiv:2608.03893
  • arXiv:2608.03994
  • arXiv:2608.04569
  • arXiv:2608.04771
  • arXiv:2608.05042
  • arXiv:2608.05219
  • arXiv:2608.05604
  • arXiv:2608.05784
  • arXiv:2608.06033
  • arXiv:2608.06111
  • arXiv:2608.06146
  • arXiv:2608.06216
  • arXiv:2608.06501
  • arXiv:2608.06751
  • arXiv:2608.06867
  • arXiv:2608.07009
  • arXiv:2608.07051
  • arXiv:2608.07152
  • arXiv:2608.07169
  • arXiv:2608.07458
  • arXiv:2608.07468
  • arXiv:2608.08020
  • arXiv:2608.08097
  • arXiv:2608.08311
  • arXiv:2608.08389
  • arXiv:2608.08627
  • arXiv:2608.08814
  • arXiv:2608.08878
  • arXiv:2608.08950
  • arXiv:2608.09096
  • arXiv:2608.09441
  • arXiv:2608.09802
  • arXiv:2608.09867
  • arXiv:2608.09888
  • arXiv:2608.09900
  • arXiv:2608.10288
  • arXiv:2608.10538
  • arXiv:2608.10628
  • arXiv:2608.10636
  • arXiv:2608.10812
  • arXiv:2608.10915
  • arXiv:2608.11030
  • arXiv:2608.11205
  • arXiv:2608.11668
  • arXiv:2608.11924
  • arXiv:2608.12123
  • arXiv:2608.12149
  • arXiv:2608.12253
  • arXiv:2608.12307
  • arXiv:2608.12440
  • arXiv:2608.13010
  • arXiv:2608.13263
  • arXiv:2608.13417
  • arXiv:2608.13426
  • arXiv:2608.13499
  • arXiv:2608.13667
  • arXiv:2608.13900
  • arXiv:2608.14054
  • arXiv:2608.14144
  • arXiv:2608.14333
  • arXiv:2608.14376
  • arXiv:2608.15389
  • arXiv:2608.15994
  • arXiv:2608.16157
  • arXiv:2608.16425
  • arXiv:2608.17402
  • arXiv:2608.19535
  • arXiv:2608.19621
  • arXiv:2608.19662
  • arXiv:2608.19758
  • arXiv:2608.20953
  • arXiv:2608.21252
  • arXiv:2608.21500
  • arXiv:2608.22876
  • arXiv:2608.24040
  • arXiv:2608.26070

主要参考 URL： - https://blog.modelcontextprotocol.io/posts/2026-07-28 - https://huggingface.co/collections/RedHatAI/speculator-models - https://arxiv.org/html/2608.14376v1 - https://arxiv.org/html/2608.14333v1 - https://arxiv.org/html/2608.01526v1 - http://localhost:30000 - http://localhost:8000 - http://localhost:8000/metrics - http://localhost:9000

本次变更

2026-08-29 | Tom

  • SGLang v0.6(574PR)+DSpark+Spec V2+PD Disagg GPU Staging Buffer;vLLM Conf2026+Q3 Roadmap六轴;Kimi K3 Day0 SGLang(LatentMoE 896 experts/1M上下文);ACL 2026 KV六件(MiniKV/KVTuner/HiFC/TinyServe/QJL/ChunkKV/OBCache/LLM-AnDPro/HCAttention);ReCo arXiv:2608.04771 CoT长度膨胀(R-KV压缩→DeepSeek-7B生成长度+38.8%);Cross-Model KV Transfer arXiv:2608.03893闭式解跨模型复用;FreeToken arXiv:2608.16157边缘MoE Serving;DSpark AIME25精度回退Bug(97.08→93.96,Gh#32038);An Internet for KV Cache新基础设施框架;vLLM v0.28 MRV2默认化+async scheduling;引→约295