inference · 知识库活文档
- 更新：Oct09午后：BP-KV行为保持压缩(2610.06479)+SSD(5×AR)+Spheron Oct26 SGLang vs vLLM量化对比+galahad-kv 50Mtoken原子上下文；引→471
一、现状全景：LLM 推理工业化成熟与框架格局
1.1 框架格局：vLLM v0.30 / SGLang v0.5.20 双雄并进，TGI 正式停服
TGI 正式进入维护模式（2026-03-21，Hugging Face 官方）：Hugging Face 正式将 TGI（Text Generation Inference）切换为维护模式，ongoing work 限制为 small bug fixes、documentation updates 和 lightweight maintenance。官方推荐迁移目标：vLLM、SGLang，以及 llama.cpp / MLX 等本地引擎。2026 年推理引擎格局最大里程碑事件——Hugging Face 官方认证两强格局。
GitHub Stars 生态成熟度快照（2026-09）：vLLM ~91K stars；SGLang ~36K stars（vLLM 的 39.6%）。差距 2.5× 反映生态成熟度差异。
vLLM v0.30.0（2026-09-22，762 commits / 315 contributors / 104 新特性）：
| 特性 | 核心内容 | 工程价值 |
|---|---|---|
| Fast Start | GPU 权重缓存守护进程；后量化+TP分片权重存 GPU 内存；--load-format ipc_cache 通过 CUDA IPC 直接映射 |
集群重启从数分钟降至秒级 |
| HiSparse 分层 KV Cache | host-resident tier for sparse MLA decode；KV pages spill 到 pinned host memory | H200/B200/GH200 峰值生成吞吐提升最高 4.7× |
| Model Runner V2（MRV2）全面默认化 | dual-batch overlap（eager + FULL CUDA graphs）；从 v0.28 开始dense模型默认路径；MRV2 完全取代旧 PagedAttention V1 后端 | H200 初始化 3.5× 加速（28.9s→8.2s）；Spheron 2026-08 实测（Qwen3-0.6B @ GB200）：MRV2 56% 更高吞吐；GLM-4.7-FP8 @ 4×GB200 6.3% 更低 TPOT |
| MXFP8 KV 支持（DeepSeek-V4.1-Flash） | 全 KV 在 SM100 以 MXFP8 存储 | Qwen3.8-2.4T 吞吐提升 >10% |
| Watermarking（Gumbel-max） | keyed PRF 加水印生成；per-request opt-out | 首个官方生成溯源机制 |
| RL weight sync | sharded_rdt P2P backend |
Kimi K2 BF16 48 节点 7.53s 权重传输 |
| Adaptive Verification（DSpark） | per-request confidence 调度 DSpark draft-verification budget | MiniMax-M3-MXFP8 EAGLE-3 达 2.09× |
| Disaggregated prefill/decode/encode | P/D/E 三路解耦；支持 AMD MORI-IO（MI300X） | 跨 Prefill/Decode 不同计算特征的资源池化 |
| 量化支持全面扩展 | MXFP8/MXFP4/NVFP4/INT8/INT4/GPTQ/AWQ/GGUF/compressed-tensors/ModelOpt/TorchAO | 全精度谱系覆盖 |
| Eagle3 speculative decoding | 低并发（1-4 requests）30-45% decode 加速；中并发（10-20）15-20% | 投机解码生产成熟度分水岭 |
vLLM v0.30 changelog Sep 28 追加（+12 项，新增重点）：Dynamic SD（#32374）；DFlash with FlashInfer（#43081）；mixed KV page sizes（#45181）；EAGLE3 support for Qwen3（#43132）；reduced TP communication for large-vocab drafts（#39419）；EAGLE multimodal encoder cache fixes（#46315）；runtime draft weight update（#46725）；hybrid (SWA + full attention) DFlash drafters（#47914）；SWA support for qwen-eagle3（#47568）；Gemma4-12B DSpark draft model（#47216）；DSv4 DSpark on AMD（#47419）；separate kv_cache_dtype for speculative_config（#48787）。
vLLM v0.30.1rc1 生产 pin 建议（AI Infrastructure Digest 2026-09-27，生产必须）：
- 生产部署建议 pin 到 v0.30.1rc1，避免 v0.30.0 已知 bug
- 已知 bug 清单：GLM-5.3 集成中的 DFlash/DSpark 内存损坏问题；Mamba/GDN 元数据在 KV cache grouping 下复用时的 bug
- ⚠ 生产警示：v0.30.0 的 Mamba bug 与 SGLang Mamba bug 独立，两者是不同引擎的不同 bug，不能互相替代修复
vLLM MORI-IO Read vs Write 模式（vLLM.ai Blog 2026-04-07，AMD 官方贡献）：
| 模式 | 环境变量 | 机制 | 适用场景 |
|---|---|---|---|
| Read 模式 | VLLM_MORIIO_CONNECTOR_READ_MODE=1 |
prefill 完成后 proxy 转发 KV block 位置给 decode；decode 通过 RDMA 主动拉取 KV 数据后再生成 | 长 prompt + 短输出；延迟更可预测 |
| Write 模式 | VLLM_MORIIO_CONNECTOR_READ_MODE=0 |
proxy 同时调度 prefill 和 decode；prefill 每计算完一层就把 KV 数据推入 decode 内存；decode 可在 prefill 全部完成前就开始生成 | 短 prompt + 长输出；TTFT 更低，架构更复杂 |
⚠ 瓶颈分析：KV 数据传输是 gigabytes 级传输，若 RDMA 配置不当，transfer itself becomes bottleneck。
vLLM 官方博客三篇系统性锚定（2026-09 vLLM.ai Blog）：
| 标题 | 核心内容 |
|---|---|
| Next-Level Inference: Prefill-Decode Disaggregation | AMD MI300X 8-GPU节点上的PD分离 + KV Cache高效传输 + ITL稳定性优化 |
| vLLM FP8 KV-cache validation across Hopper and Blackwell | Attention量化 + Flash Attention 3修复 + 显存节省 + Decode加速 |
| Disaggregated Serving for Hybrid SSM Models | 扩展NIXL到Mamba混合SSM模型（与SGLang GLM-5.3-Flash 34层线性注意力形成「混合线性注意力模型推理系统」完整体系） |
vLLM Production Stack 2026 GA 路线图（GitHub Issue #855，P0 优先级，Oct 2026 更新）：
| 优先级 | 特性 | 目标时间 |
|---|---|---|
| P0 | 高级自动扩缩容（KV-cache-aware autoscaling） | 2026 Q4–2027 Q1 |
| P0 | KV-cache 感知路由（per-request prefix-hash 感知调度） | 2026 Q4 |
| P0 | PD Disaggregation 生产支持 | 2027 Q1 |
| P0 | KEDA 集成（K8s 事件驱动扩缩容） | 2026 Q4 |
| P1 | vLLM Omni 多模态模型 K8s 部署 | 2027 Q1 |
SGLang v0.5.20（2026-09-18，713 PRs / 237 contributors）：
| 特性 | 核心内容 | 工程价值 |
|---|---|---|
| RL Sampling Masks | return_sampling_mask 每个 decode step 返回精确 token 支持 + log-probability |
batch=64 吞吐量 +52%；batch=1 +17% |
| Unified Radix Tree | SWA 组件 branching-point caching；统一 RadixAttention 作为 Prefix Cache 底层 | 所有模型统一前缀缓存策略 |
| Lean Attention Kernel | AMD MI355X 吞吐提升最高 1.52× | AMD 推理生态完善 |
| FlashInfer all-to-all routed MoE | flashinfer_trtllm_routed，DeepSeek V3 类 MoE 架构工程落地加速 |
DeepSeek MoE 推理效率提升 |
SGLang v0.6（2026-07-27，≤400,000 GPUs 全球部署）：DSpark 投机解码（DeepSeek-V4-Pro TP8 B300 bs=1 达 383.7 tok/s）；DFlash + Spec V2（>4.3× 基线吞吐）；PD Disagg GPU Staging Buffer（RDMA 请求数降低约 1000×）。SGLang 全球部署规模突破 400,000 GPU（xAI、AMD、NVIDIA、LinkedIn、Cursor、Oracle Cloud、GCP、Azure、AWS 共同验证）。
SGLang GB300 NVL72 里程碑（2026-02，SGLang Official Blog + NVIDIA 合作）：GB300 NVL72 rack-scale GPU 拓扑上实现 25× 推理性能提升。
SGLang RadixAttention vs vLLM PagedAttention — Spheron Oct 2026 量化对比（Oct 2026）：
| 维度 | vLLM | SGLang | 适用场景结论 |
|---|---|---|---|
| 通用负载 | ~12,500 tok/s | ~16,200 tok/s | 通用负载差距 ≤4%，SGLang 领先 |
| Prefix overlap >60% | 44 req/s（RAG共享前缀，100并发） | 72 req/s | SGLang RadixAttention 显著受益 |
| Blackwell / B200 native | ✅ FlashAttention 4 backend on SM100/SM103 | 正在追赶 | vLLM Blackwell 原生性能优势 |
| Speculative decoding | ✅ Eagle3/EAGLE2 + MRV2 成熟集成 | ⚠ 实验性 | vLLM 投机解码更成熟 |
| MoE / DeepSeek V4 | 差距 <10% | 差距 <10% | 两者基本持平 |
| 结构化输出高流量 | 中等 | 99.8% 成功率 | SGLang 原生优势 |
⚠ SGLang 在以下场景优先：prefix overlap >60%、多轮 Agent、RAG 管道、结构化输出重复大容量。vLLM 在以下场景优先：最广泛模型支持、Blackwell 原生性能、Eagle3 投机解码成熟度。
SGLang GLM-5.3-Flash 生产故障（HelixML 2026-09-25 真实生产数据，P0 生产警示）： - 背景：GLM-5.3-Flash 的 45 层中有 34 层是线性注意力（Linear Attention），而非标准 Transformer 注意力 - 故障：单个 313,000-token 的 prompt 在 SGLang 上产生了 51 个状态快照，占用 28 个缓存槽，导致所有其他对话的缓存被逐出——此时 token cache 仅填充了 72% - 根因：SGLang RadixAttention 缓存机制原本为标准 Transformer 设计，对线性注意力层的 state snapshot 管理存在盲区 - 缓解：对每个对话的快照数量加 cap，冷启动失败率从 7.6% 降至 1.1% - ⚠ 生产警示：混合注意力模型（MoE + Linear Attention）在中文社区被大量推荐，这个坑此前鲜有中文资料系统覆盖
Qwen3.8-27B 混合注意力三引擎 Bug 对照（Winder.ai Oct 2026）：
| 引擎 | 版本 | Bug 描述 |
|---|---|---|
| vLLM | 0.30 | Qwen3.8-27B 在 H100 上拒绝启动，直到降低 sequence limit |
| SGLang | 0.5.20 | Qwen3.8-27B 上静默将并发限制在 20——直到 state cache 扩大到能容纳 50 个并发请求之前，实际并发远低于配置值 |
| TRT-LLM | 1.2.1 | 无法加载 Qwen3.8 |
| TRT-LLM | 1.3.0rc28 | FP8 checkpoint 启动失败（2026-09 open bug） |
1.2 六引擎 2026 Q4 完整量化矩阵
6 引擎 Benchmark（Llama 3.1 8B / H100-80GB / 1000 ShareGPT prompts，PremAI / Winder AI / Spheron 多源确认）：
| 引擎 | 吞吐量 @50 并发 | TTFT p50 | p50 延迟 | $ / M output tok | |------|---------------|---------|---------|-----------------|------| | SGLang | ~16,200 tok/s | ~42ms | 4–21ms | $0.26–0.44 | | LMDeploy | ~16,132 tok/s | — | ~25ms | — | | vLLM | ~12,500 tok/s | ~45ms | 50–80ms | $0.26–0.61 | | TensorRT-LLM | ~10,000+ tok/s | 0.54ms | 35–50ms | $0.30 | | TGI | ~9,500 tok/s | ~60ms | ~60ms | — | | llama.cpp | ~6,000 tok/s | ~98ms | ~80ms | $1.38 |
关键格局判断： - SGLang 与 LMDeploy 差距仅 0.5%（16,215 vs 16,132），两者均显著领先 vLLM 29% - TGI 进入维护模式正式确认，新项目不推荐选 TGI - LMDeploy 确认第三引擎地位：纯 C++ TurboMind 引擎在 H100 上与 SGLang 并列 ~16,200 tok/s，量化模型部署首选 - SGLang Agent 工作流专项优势：10 次工具调用的 Agent 工作流场景 SGLang 领先 vLLM 127%（420ms vs 185ms，VRLA Tech Sep 30）
1.3 llm-d CNCF Sandbox + K8s 推理编排
llm-d 正式加入 CNCF Sandbox（2026-03-24）：创始成员 Red Hat + Google Cloud + IBM Research + CoreWeave + NVIDIA。
llm-d v0.8（2026-09 新增）：SGLang 正式加入成为 first-class inference engine（与 vLLM 并列）；首个 Agentic Serving Guide 正式上线；KV cache memory 降低 50-60%（GDS 支持）；benchmark 平台 prism.llm-d.ai；~3.1k tok/s per B200 decode GPU；16×16 B200 P/D 拓扑 up to 50k output tok/s。
NIXL 三传输后端 Benchmark（llm-d.ai/blog + kvcache-ai/Mooncake GitHub，Oct 2026）：
| 后端 | 底层协议 | 特性 | 适用场景 |
|---|---|---|---|
| UCCL | NCCL 通信 | NVIDIA 生态原生 | 纯 NVIDIA 集群 |
| UCX | libfabric | 通用高性能通信 | 异构 GPU 集群 |
| Mooncake | RDMA/TCP | Moonshot Kimi 生产验证，KV cache 专用 transfer engine | PD disaggregation KV 传输 |
Mooncake 版本历史：2025-12-23 SGLang 引入 Encode-Prefill-Decode (EPD) Disaggregation 以 Mooncake 为 backend；2026-02-12 Mooncake 正式加入 PyTorch Ecosystem；2026-01-28 FlexKV（Tencent+NVIDIA）支持 Mooncake Transfer Engine 做分布式 KVCache reuse。Mooncake EPD（Encode-Prefill-Decode）是多模态 PD disaggregation 的关键架构演进——Vision Transformer 输出可零拷贝 RDMA 传输。
NVIDIA Grove —— K8s 原生推理编排三层 CRD（NVIDIA Developer Blog 2026-09）：
| 层级 | CRD | 作用 |
|---|---|---|
| L1 | PodClique | 单角色副本组（prefill/decode/vision encoder 等） |
| L2 | PodCliqueScalingGroups | 多级弹性伸缩（同一角色的多副本集） |
| L3 | PodCliqueSet | 多组件系统描述（将 L1/L2 组合为完整系统） |
NVIDIA Dynamo 1.0 GA 正式取代 Triton：核心设计：分布式推理 + KV-Cache 感知路由 + KV Cache Manager。支持 SGLang、TensorRT-LLM、vLLM 作为引擎，Dynamo 作为统一编排层。KV-aware Router 4× lower TTFT + 1.5× higher throughput；ModelExpress 大 MoE checkpoint 恢复 up to 7×。
NVIDIA Dynamo v1.5.0 Feature Matrix（Oct 2026）：
| Feature | Disagg Serving | KV-Aware Routing | Multimodal | Spec Decoding | Request Cancellation |
|---|---|---|---|---|---|
| TRT-LLM | ✅ | ✅ | ✅ | ✅ | ✅ |
| vLLM | ✅ | ✅ | ✅ | ✅ | ✅ |
| SGLang | ✅ | ✅ | ✅ | ✅ | ✅ |
1.4 推理可靠性与可观测性
HookPoint — 推理可观测性 3.6% overhead（arXiv:2605.11093）：三种方案 overhead 对比： - HookPoint 自定义 CUDA kernel：overhead 仅 0.4–6.8%（平均 3.6%） - PyTorch forward hooks：overhead 34.0–59.8%（平均 46.9%） - NNsight：overhead 54.1–71.2%（平均 62.3%），Qwen3-14B batch=64 时 OOM
LLM Inference Engines Bug 实证分类（arXiv:2506.09713v2，⭐⭐⭐⭐⭐）：首个大规模系统性研究。28 种根因类型；Bug 两大根因类别：① Resource (RE)——资源管理机制直接导致；② Functionality (FC)——功能逻辑缺陷引发资源问题。
推理后端诱导方差（arXiv:2605.19537）：不同推理引擎对同一模型同一输入产生显著不同的 token 分布。L40 GPU 上后端诱导方差 up to 17.2% Max-Max 差。
vLLM Batch Invariance — Temperature=0 非确定性（Spheron Blog 2026-09-30）： - 根因：vLLM 在 Continuous Batching 模式下，即使 temperature=0 也存在非确定性输出——Batch-Invariant Kernels 对输入 token 的不同排列组合产生不同算子融合 - SGLang 修复：通过 Deterministic Attention 修复，但平均吞吐量降低 34.35% - 影响场景：RL 训练数据生成、可复现评测、精确 Benchmarking——大多数生产 API 场景可忽略
LLM 系统运维六大可操作性原则（Stack Overflow Blog 2026-10-08，Part 5）：
| 原则 | 核心内容 |
|---|---|
| 1. Gateway 作为单一瓶颈 | cost 测量、model routing、failover、kill switch 集中在 gateway 层——系统可 operable 的关键 |
2. decision_id 贯穿全链路 |
每个请求分配唯一 ID，连接 gateway/routing/observability/cost 四个维度 |
| 3. 跨租户隔离四原则 | HMAC 非对称签名（防伪造）+ 最短 TTL（防泄漏）+ 每 hop 验证（防注入）+ 跨租户拒绝记审计日志 |
| 4. Agent 平台两个失败极端 | 欠供给：无审计存储、一个共享 god credential；过供给：一个队列+三个数据库+服务网格，但服务本身无状态 |
| 5. 传统服务 vs LLM 系统的失败不对称 | 传统服务错返回 500；LLM 系统出错可在规模上快速执行错误动作——operability 是"运行"和"希望"的区别 |
| 6. vLLM 核心指标清单 | vllm:time_to_first_token_seconds（TTFT）+ vllm:kv_cache_usage_perc（KV 利用率）+ vllm:num_preemptions（抢占次数） |
Agent 三层内存架构成本模型（GMI Cloud 2026-10-04，生产决策核心）：
| 层级 | 存储介质 | 成本模型 | 关键洞察 |
|---|---|---|---|
| Working Memory | context window 本身 | 每 token 在每次 forward pass 付成本 | 提取和合并的 LLM 调用成本是存储成本的 10-100 倍 |
| Session Memory | per-thread 状态 | 跨 turn 存活 | 最有效的成本决策：session 边界批量合并（40轮对话末尾合并1次 = 1次提取调用），而非每消息合并 |
| Long-term Memory | 跨会话知识 | 唯一真正困难的层 | 三大难点都是写入策略问题（跨会话身份 + 时序抽象 + 内存过期），非检索问题 |
⚠ 颠覆直觉：dominant cost 是推理不是存储；更大的 context window 改变的是"什么塞进去 vs 什么按需检索"的权衡。
二、关键工作脉络：从单点突破到系统协同
2.1 PagedAttention 与 vLLM MRV2
PagedAttention（arXiv:2309.06180）：将 OS 虚拟内存分页管理思想引入 KV cache 管理——内存碎片从 60-80% 降至 <4%。
MRV2（vLLM 0.17+ 从头重写的模型执行层）：v0.28+ 成为 dense 模型默认路径。Spheron 2026-08 实测（Qwen3-0.6B @ GB200）：MRV2 56% 更高吞吐；GLM-4.7-FP8 @ 4×GB200 6.3% 更低 TPOT。v0.30 中 PagedAttention V1 后端完全移除，MRV2 + FlashAttention/FlashInfer/TRTLLM-GEN/FlashMLA/Triton 成为标准后端栈。
2.2 调度理论
MC-SF 在线调度算法（arXiv:2502.07115）：严格形式化 KV Cache 动态内存增长 + 批量调度的在线调度问题；证明确定性在线算法在对抗性到达模型下不存在常数竞争比；提出 MC-SF 算法，多项式时间常竞争比。
JIL — Length Prediction Scheduling Attack（arXiv:2610.03430，Oct 2026，⭐⭐⭐⭐）： - 核心问题：基于长度预测的 LLM 调度器（如 TRAIL）依赖预测输出长度分配优先级，但预测信号可被对抗性手段操纵 - 攻击机制：JIL（Jumping the Line）攻击通过优化对抗性后缀，使 lightweight output-length probe 低估请求的输出长度，从而获得更高调度优先级 - 关键数据：JIL 使预测输出长度降低最多 83.4%；对抗性请求端到端完成时间缩短最多 1.53× - 调度器侧防御：将长度预测分组为粗粒度区间，可减少 JIL 优势并减轻对正常请求的延迟 - ⚠ 生产警示：vLLM 和 SGLang 的现有默认调度器尚未实现粗粒度区间防御；高安全多租户场景需评估 JIL 攻击面
Cascade — SLO 感知延迟预算统一协调（arXiv:2608.06557）：将"延迟预算（SLO - 预测剩余服务时间）"作为调度和 KV Cache 管理的统一协调量；好吞吐提升最高 2.4×；SLO 违规率降低 40%。
OpScale — 算子级弹性伸缩（arXiv:2608.13499）：扩缩容单位从"整模型"细化到单个算子，实现亚秒级弹性。40×A100 + 24×GB200 集群生产轨迹验证：满足 SLO 前提下减少 36.3% GPU、28% 电力；固定成本预算下吞吐提升 44%。
Pareto Atlas — 54 锚点实测（arXiv:2609.17863）：vLLM 0.12.0 · Qwen2.5-7B-Instruct · RunPod L4/A100 80GB PCIe/H100 PCIe · FP16/AWQ/FP8 weights/FP8 KV cache/两种 speculation 配置。核心结论：不同优化组合构成帕累托前沿；不存在单一最优配置。
Dynamic LLM Routers Are Often Misguided（arXiv:2610.02762，Oct 2026）： - 三大系统性失败模式： 1. 难度盲区（Difficulty Blindness）：最难查询反而不会升级——路由器倾向于对简单问题升级（因为置信度低），对困难问题反而保持原模型（因为置信度高） 2. 长度反转（Length Reversal）：倾升级短答案查询（因为成本低、延迟敏感）——实际上短回答往往最需要升级到更强模型 3. 语义匹配失败（Semantic Mismatch）：路由器对语义相似但难度不同的查询给出相反路由决策 - 覆盖基准：RouterBench、LLMRouterBench、RouterArena——均无法检测上述缺陷 - 工程意义：生产 Router 选型必须进行对抗性测试，不能仅依赖标准基准
LLM-as-Jev — Jev 风格决策模型（arXiv:2610.02076）： - 核心问题：LLM 能否直接从 next-token 概率中提取校准决策（calibrated decisions），而非依赖额外 reward model - 方法：LLM-as-Jev 框架——从带括号数字标识符的下一 token 概率中提取校准决策；提供无需训练的推理方案 + 树分解列表式损失微调目标（KL 散度惩罚锚定基模型） - 工程意义：对 LLM Router 和 Agent 决策精度有直接参考价值；决策校准性与路由失败模式（难度盲区/长度反转）高度相关
2.3 Prefill-Decode Disaggregation 工程进展
vLLM PD Serving Qwen3.8-2.4T（vLLM.ai Blog Sep23）：GB300 NVL72 PD 配置；Throughput 5K tokens/s；TTFT 180ms；Decode Context Parallelism（DCP）长上下文 agentic 工作负载对比标准 tensor parallelism 实现 3× 吞吐量提升。
AMPD（arXiv:2602.14516）：多轮 Agent 场景 incremental prefill 导致传统 PD disaggregation 失效；AMPD 针对 incremental prefill 和两阶段模型部署优化。
Disaggregated Quantization（arXiv:2609.26333）：首个"量化层面的 Prefill-Decode 解耦"。核心问题：Prefill 和 Decode 对量化有不同的诉求——低精度算术可加速提示处理（Prefill），紧凑的权重量化可减少生成阶段的内存访问（Decode）。解决方案：DQ——针对 Prefill 和 Decode 分别定制计算格式、权重与存储布局。
MoE Serving 三件套（2026-10-02 新增重点）：
① CascadeEP（arXiv:2609.33252）—— MoE Prefill 异步专家调度： - 核心问题：MoE 模型中 expert loading（CPU→GPU copy）处于 critical path，产生明显 idle gap - 解法：将 CPU→GPU expert copy 与 GPU compute 完全 overlap - 验证：Qwen-30B-A3B Nsight trace 实测
② Speculating Experts（arXiv:2603.19289）—— MoE 推理专家预取加速，无需微调： - 核心问题：CPU-GPU copy 在 critical path，推理延迟不稳定 - 解法：用模型内部表征预测未来 token 的 expert 选择，提前将 expert 权重从 CPU 加载到 GPU - 关键特性：直接用于现有预训练 MoE 模型，无需微调；可集成进 vLLM/SGLang
③ CrossPool（arXiv:2606.24506）—— Cold MoE Multi-LLM Serving：针对冷启动 MoE 模型的多 LLM 联合服务策略
SlimWise — MoE 阶段层专家剪枝（arXiv:2609.34117，HF Daily Oct 08）： - 核心创新：在 Prefill 与 Decode 阶段之间解耦专家剪枝（decoupled expert pruning between Prefill and Decode）——针对 MoE 模型中 expert redundancy 问题，对 Prefill 和 Decode 两个阶段分别做专家剪枝 - 范式对比：现有 MoE serving 的 expert selection 在 token 层统一路由；SlimWise 将路由粒度提升到"阶段层" - 工程价值：vLLM/SGLang 当前 MoE 支持基本沿用 unified expert selection；SlimWise 提供按阶段细粒度路由，在 DeepSeek-V4 类 MoE 模型上有显著加速潜力 - 与 MoE Serving 三件套的互补关系：CascadeEP 解决 expert loading 延迟问题（异步调度），SlimWise 解决 expert redundancy 效率问题（预分馏剪枝）
SEIS — Self-Evolving Inference Systems（arXiv:2610.04646，IC-level，Oct 3 2026）： - 核心贡献：AI Agent 自动构建推理引擎（vLLM / SGLang / TensorRT-LLM），通过搜索配置空间（量化、投机解码、执行设置）自动调优 - 关键数据（Qwen3-0.6B on H100，单请求负载）： - 最佳进化引擎比原始 mini-sglang 吞吐量高出 3.27× - 比 vLLM / TensorRT-LLM / SGLang 均更快（单请求负载） - 准确率差异在 ±3 分以内（GSM8K / 长上下文检索任务） - 工程意义：首个 AutoML 驱动推理引擎调优框架；AI-for-Systems 的完整闭环验证
2.4 推理引擎可复现性
推理后端诱导方差（arXiv:2605.19537）：不同推理引擎对同一模型同一输入产生显著不同的 token 分布。L40 GPU 上后端诱导方差 up to 17.2% Max-Max 差。
Orthrus 损失性警示（arXiv:2609.15504，2026-09-14，P0）： - 独立复现发现：在 BF16 推理下仅 45% 轨迹精确匹配 AR 基线，FP32 下才恢复 100% 轨迹匹配 - 任务级 lm-eval-harness 评测无法检测到 45% vs 100% 的差异——现有评测范式存在系统性盲区 - ⚠ P0 最重要遗漏：FP32 端到端速度数据缺失（若 FP32 下 Orthrus 加速比崩溃，则 Orthrus 失去存在意义）；代码和 prompt 集未公开
GoodServe — Agentic LLM Inference Serving（arXiv:2605.16867）： - 核心问题：Agentic LLM 的关键指标是 TTLT（Time-To-Last-Token），不是 TTFT/TPOT——E2E-SLO 约束与传 chatbots 本质不同 - 方法：GoodServe 调度算法处理异构 GPU 资源上的 agentic 请求；KV Cache 容量约束建模 - 工程价值：E2E-SLO 概念对 agent 部署团队有直接价值
三、KV Cache 管理：六纪元与技术路线图
3.1 Five（+One）Eras of KVCache
The Five Eras of KVCache（ModCon 2026 / Modular Blog）：
- Era 1 — Naive Contiguous Allocation：无缓存，60-80% 碎片化浪费
- Era 2 — PagedAttention（vLLM 革命）：碎片降至 <4%
- Era 3 — Prefix Caching / RadixAttention（SGLang）：跨请求共享前缀
- Era 4 — Disaggregated KVCache（跨节点）：PD Disaggregation；Mooncake Store、llm-d 属于此 era
- Era 5 — Compression/Quantization（当前进行时）：TurboQuant / KVTC / GEAR / HiSparse / DASH / OasisKV；ICLR 2026 批量发布
- Era 6 — KV Cache 作为第一等数据对象（2026 新兴）：NVIDIA CMX 正式标准化 KV cache 存储类型；Memory Pool Architecture；KV Cache CDN 范式
Context Engineering 决策框架（Spheron Network 2026 Guide）：
比率 > 10:1 → Context Engineering 收益 > 模型级优化
比率 > 50:1 → Context 成本是主导因素，Prefix Caching 优先
2026 年 agent 典型请求：50,000-500,000 输入 tokens vs 几百输出 tokens。组合使用是生产级 LLM 推理的必备条件，而非可选项。
3.2 Cache Compression（Era 5 核心）
ACL 2026 Findings：KV Cache 系统优化系统性综述（arXiv:2607.08057，⭐⭐⭐⭐⭐）： - 定位：ACL 2026 官方接收，系统性综述 KV Cache 优化技术全貌 - Awesome 列表：jjiantong/Awesome-KV-Cache-Optimization
BP-KV — Behavior-Preserving KV Cache Compression（arXiv:2610.06479，Oct 2026，⭐⭐⭐⭐）： - 核心问题：现有免训练 KV Cache 驱逐策略依赖代理重要性信号（注意力质量、PPL），而非直接评估"移除该 token 是否改变模型输出分布" - 方法创新：评分离不开候选驱逐的标准是估计压缩后缓存是否改变模型输出分布——从「信号保真」走向「行为保真」 - 具体机制：通过驱逐前的前向统计量（pre-eviction forward statistics）评估压缩缓存所诱导的 logits 与完整缓存下一 token 分布之间的 KL 散度，为候选驱逐打分 - 范式意义：首个将"行为保真"作为 KV Cache 压缩目标的免训练框架；与 DeCoPrune（视频扩散去噪一致性）构成跨模态驱逐方法论双轴 - 工程价值：对 vLLM/SGLang 的 KV Cache 回收策略有直接替代参考价值；精度损失大幅低于 PPL-based 方法
DeCoPrune — KV-Cache Pruning via Denoising Consistency（arXiv:2609.39096）： - 核心问题：自回归视频扩散（Autoregressive Video Diffusion）的 KV cache 随生成历史持续增长，现有压缩策略无法直接衡量当前块是否贡献了超出已保留上下文的信息 - 方法：将 cache 压缩视为去噪一致性问题——去噪难度可作为 token 价值的有用代理 - 工程价值：训练免方法；流式视频生成 + 交互控制场景；token 持续增长是 autoregressive video diffusion 的核心瓶颈 - 范式意义：与 BP-KV 构成「跨模态驱逐方法论双轴」——BP-KV（LLM 行为保真）+ DeCoPrune（视频扩散去噪一致性）
GEAR（arXiv:2403.05527，被引 186 次）：统一量化 + 低秩近似 + 稀疏补救离群点；4-bit KV cache 近无损 + 2.38× 吞吐量 + 2.29× 峰值内存降低。
TurboQuant（arXiv:2504.19874，ICLR 2026，Google Research）：PolarQuant + QJL 两阶段管道，无需训练或校准。RTX 5090 32GB + Qwen3.5-27B-AWZ：4.4× 压缩比；H100 8× 推理加速。
KVTC（arXiv:2511.01815，ICLR 2026，NVIDIA）：达 20× 压缩，精度损失 <1 个百分点。集成入 NVIDIA Dynamo + vLLM。
vLLM FP8 KV-Cache 生产验证报告（vLLM.ai Blog Sep22）：Hopper/Blackwell 架构上注意力精度损失可忽略；Flash Attention 3 修复了早期 FA3 + FP8 组合的数值不稳定问题；内存节省约 50%。
Periodic Weak Spots — Chunked KV-Cache Compression 的相位敏感性（arXiv:2609.36322）： - 核心发现：使用 chunked KV-cache compression 的大型模型中存在系统性的不对称性——同一信息在某个 phase 易于检索，在另一个 phase 则困难
HiSparse（arXiv:2608.07009，Stanford+UIUC）：HBM 仅维护选定条目，已合并入 SGLang 上游。峰值生成吞吐提升最高 4.7×。
DASH（arXiv:2608.14333）：MoE LLM 专用双层 KV Cache（HBM + High-Bandwidth Flash）。Llama 4 Maverick KV cache 197.41 GB 超过单卡 HBM；DASH 吞吐量 1.92×，E2E 延迟降低 48%。
OasisKV（arXiv:2608.08097）：以显存为中心的 LLM 推理系统设计，通过 lookahead sparse prefetching 将完整 KV cache 存储与 HBM 解耦，首次实现 KV cache 容量可超出 HBM 上限。
galahad-kv — 50M Token 原子上下文持久化（arXiv:2610.10845）： - 核心问题：LLM 每次发送 prompt 时都要重新计算 KV state；context window 虽大但每次都是重算 - 解决方案：将每个 ~16,000 token 块的 KV state 以加密形式存到本地 NVMe，回复时直接加载（byte-exact），无需重算 - 关键数据（Gemma 4 12B 和 31B @ H100，实测 50,000,000 tokens）： - 探测的每个块均从加密存储加载，无重算（100/100 块成功率） - KV state 持久化到 NVMe，encrypted（安全隔离） - 范式意义：将 KV Cache 从"计算中间结果"重新定义为"可持久化的第一等状态对象"——实现 50M token 窗口且速度比每次重算更快、成本更低 - ⚠ 待核实：galahad-kv 开源代码/Gemini 集成状态；生产环境 NVMe 带宽是否构成瓶颈
3.3 KV Cache 安全新维度
Shadow in the Cache（arXiv:2508.09442，NDSS 2026）：KV-cache 在 GPU 显存中以明文存储，包含用户完整上下文。
Detokenization Leaks（arXiv:2609.06674，cs.CR，高亮）：共享 backend（Ollama / LM Studio）时，detokenization 时间可作为侧信道泄露其他用户 LLM 输出。受影响：Ollama（月活高增长，5200 万次/月下载）。加密通信无法防御此攻击。⚠ 截至 2026-10，Ollama 尚未修复此侧信道漏洞；高安全要求场景需使用有独立租户隔离的推理引擎。
四、蒸馏与部署压缩
4.1 投机解码：新方法批量涌现（2026年9-10月）
NVIDIA Co-Designing AI Models Using Speculative Decoding（2026-09-02）：model side（draft model architecture, speculation depth）与 system side（verification strategy, batch scheduling）的联合优化。核心观点：投机解码已进入"模型-系统协同设计"阶段，单独优化 draft model 或 verification strategy 均有明显瓶颈。
Speculative Speculative Decoding — SGLang GitHub Issue #19896（Oct 2026，GitHub Trending）： - 核心问题：标准投机解码仍受制于 drafting 和 verification 之间的顺序依赖——draft model 必须等待 target model 完成 token 验证后才能生成下一批 speculation - 解法：SSD（Speculative Speculative Decoding）——消除 drafting 与 verification 之间的顺序依赖，实现并行 drafting 和 verification - 关键数据： - 相比优化后的标准投机解码：最高 2× 加速 - 相比自回归基线：最高 5× 加速 - 工程状态：GitHub Issue #19896 已提出，SGLang 正在评估支持 - ⚠ 待核实：具体实现细节和 production readiness 状态
新投机解码方法一览（2026年9月）：
| 方法 | arXiv | 核心创新 |
|---|---|---|
| AceSpec | 2609.01343 | 非对称边缘-云协同框架，通信高效 LLM 推理 |
| OUTLETS | 2609.01453 | 基于投机解码骨架模型的输出长度预测 |
| SFAD | 2609.01437 | Speculative Factuality-Aware Decoding，事实性感知 |
| Verification-Aware Training | 2608.30135 | 面向 speculative decoding 的验证感知训练插件框架 |
| Revisiting Lossy Verification | 2607.26627 | 原则性分析有损验证方法，统一为截断式/协作式验证两类 |
| SSR | 2608.20359 | 自投机解码——同模型 partial-CoT 作 draft，满预算作 verify |
| Mixture of Attentions: SD 2.0 | Medium Oct 2026 | 通过多样化注意力头提升 draft verification 接受率；9.5% 解码速度提升 |
Orthrus 损失性警示 — "无损"投机解码的精确复现（arXiv:2609.15504，2026-09-14，P0）：独立复现发现：在 BF16 推理下仅 45% 轨迹精确匹配 AR 基线，FP32 下才恢复 100% 轨迹匹配。⚠ P0 最重要遗漏：FP32 端到端速度数据缺失；代码和 prompt 集未公开。
Adaptive Draft Sequence Length（HPCA 2026）：自适应 draft 序列长度——在 PIM 使能系统上动态调整投机解码 draft 深度。
BentoML 3× Speculative Decoding Guide（Oct 2026）：生产级投机解码实战指南。关键结论：正确配置的投机解码在真实生产负载下可达 3× 加速。
4.2 蒸馏新范式：推理能力优先
Mid-Training KD Favors Reasoning（arXiv:2609.01532）：mid-training 做 forward KL 蒸馏仅提升推理，事实记忆几乎不变；pre-training 阶段同时提升推理和事实记忆。
RISE — 递归自我外推策略蒸馏（arXiv:2609.05295）：学生模型在解决当前难度任务后，以更难的变体挑战自己，逐步扩展能力边界。
Looped LM — 连续深度批处理（arXiv:2608.09444）：Looped LM 通过将一组共享层循环可变次数实现深度自适应推理。CDB（Continuous Depth Batching）——首个实现循环语言模型高效深度自适应批处理的方法。
Looped LM 系统性分析（arXiv:2609.36636）： - recurrence 在低于训练视野的推理预算（知识任务）和超出训练视野的推理预算（推理任务）均有帮助，但在训练视野内的推理预算帮助有限 - recurrence 应应用在模型深层，而非浅层 - CDB 批处理策略应与任务类型联合优化
QATFactory — 量化感知训练+蒸馏+NVFP4/MXFP4 部署对齐（arXiv:2609.39223，NVIDIA Labs，Oct 2026）： - 核心问题：训练时量化与推理引擎行为不一致导致精度损失——vLLM 和 SGLang 的 fused kernel 行为不同，量化感知训练与部署存在语义鸿沟 - 解决方案：QATFactory——每层可配置目标推理引擎（vLLM / SGLang / llama.cpp），支持 NVFP4、MXFP4、Q4_K 格式 - 关键数据：Qwen3.5-9B NVFP4 checkpoint 精度接近 BF16 基线（BigCodeBench / LiveCodeBench 评测）
FP8 RL Pipeline 熵值异常飙升根因（arXiv:2609.22870，P0）：全流水线 FP8 RL 仍存在严重训练不稳定——训练中期熵值异常飙升（entropy surges）+ 输出乱码。⚠ 具体根因机制在原文 §3-§5，需读全文补充。
4.3 本地与边缘推理生态
HF Transformers 原生 GGUF 支持（HF Blog 2026-09-22）：Hugging Face transformers 库新增原生 GGUF 格式支持，通过标准 from_pretrained API 加载 llama.cpp 量化模型。
EdgeAgent — Apple Silicon UMA 多 Agent 推理（arXiv:2610.03394）： - 核心问题：端侧多 Agent LLM 推理——在 CPU-GPU 统一内存架构（Apple M 系列芯片）上高效调度多个并发 Agent 工作负载 - 核心技术贡献： - In-place KV Cache Freeze：Agent 等待外部工具执行时，KV Cache 不需要写出内存——工具执行完成后从冻结位置恢复推理，零重新 Prefill 开销 - UMA-aware 调度器：感知 CPU-GPU 统一内存的物理地址布局，优先调度同一内存区域的 Agent，最大化 Cache 局部性 - 硬件偏移映射压缩：冻结后的 Agent KV Cache 重新映射地址，为活跃 Agent 腾出物理内存 - 关键数据：RTX 4090 上 VLA decode loop：117–396ms；Jetson AGX Orin：304–2603ms；有效控制频率均远低于具身 AI 目标 30Hz
SWE-Serve — PR级推理工程 Benchmark（arXiv:2609.26777）： - 数据来源：SGLang 2025-12 以来合并 PR 的真实工程任务（PR 级 ground truth） - 覆盖 6 类任务族：model support、decoding、distributed execution、serving APIs
headroom — Token 压缩库（GitHub Trending 2026-09）：token 压缩库，减少 60-95% 输入同时保持精度，可作库/proxy/MCP server。
VLA 工作负载特征化（arXiv:2610.05062）：RTX 4090 上 VLA decode loop 实测延迟 117–396ms；Jetson AGX Orin 上 304–2603ms。
推理引擎选型决策树（2026-10 更新版，新增多LoRA轴）：
业务瓶颈分析
├── 需要多 LoRA 热切换
│ └── vLLM（SGLang 暂无 LoRA 支持）
├── 延迟敏感 + 高并发 + 结构化输出（Agent/RAG）
│ └── SGLang（RadixAttention，共享 KV Cache，结构化成功率 99.8%）
├── 极致单序列吞吐量 + NVIDIA 硬件
│ └── TensorRT-LLM（CUDA 融合编译）
├── 通用部署 + 生态成熟 + 国产 GPU（昇腾）
│ └── vLLM（0.29+ disaggregated P/D/E，支持昇腾/壁仞）
├── 量化模型 + H100 高吞吐 + 国产生态
│ └── LMDeploy（TurboMind C++ 引擎，与 SGLang 并列 16.2K tok/s）
├── 轻量 / 内部测试 / 快速迭代
│ └── Ollama（⚠ 高安全要求场景禁用共享 backend）
└── 多框架协同（Gateway 路由）
└── vLLM（通用）+ SGLang（Agent）+ TensorRT-LLM（高流量）按业务分层
AutoGen 进入维护模式 → Microsoft Agent Framework 1.0（2026-10 新增）： - 重大变化：2026 年，Microsoft 将 AutoGen + Semantic Kernel 合并为 Microsoft Agent Framework（MAF），2026 年 4 月达 v1.0 GA。AutoGen 本身进入 maintenance mode - 推理引擎与 Agent 框架关系：推理引擎（vLLM/SGLang）处理 GPU/批处理/量化，Agent 框架（LangGraph/CrewAI/MAF）处理工具/记忆/编排/评估——两者正交，LLM stack ≠ Agent stack
五、成本工程与基准测试
5.1 H100 单卡标准Benchmark
H100 单卡标准Benchmark（2026-10，LeetLLM Oct 2026 + Winder.ai Sep 29）：
| 引擎 | 1 concurrent | 10 concurrent | 50 concurrent | TTFT p50 @50 | $ / M output tok |
|---|---|---|---|---|---|
| vLLM | 150 tok/s | 1,235 tok/s | 3,688 tok/s | 0.68s | $0.26–0.61 |
| SGLang | 154 tok/s | 1,233 tok/s | 3,617 tok/s | 0.73s | $0.26–0.44 |
| TensorRT-LLM | 141 tok/s | 1,127 tok/s | 3,219 tok/s | 0.54ms | $0.30 |
| llama.cpp | 185 tok/s | 539 tok/s | 703 tok/s | 0.98s | $1.38 |
| Ollama | 79 tok/s | 239 tok/s | 277 tok/s | 1.70s | $3.50 |
RAG 共享前缀性能对比（Spheron Oct 2026，100 并发，50% 共享前缀）：
| 引擎 | 吞吐量 | KV Cache 节省 |
|---|---|---|
| SGLang | 72 req/s | 68% |
| TensorRT-LLM | 48 req/s | — |
| vLLM | 44 req/s | — |
⚠ 基准数据测试模型为 Llama 3.1 70B H100，未注明 SXM vs PCIe 型号，差距可达 20%，建议以自有环境实测为准。
MLPerf Inference v6.0 B200 @ 8卡官方数据（2026-04，NVIDIA 官方）：
| 配置 | 吞吐量 |
|---|---|
| Offline | 93,071 tokens/s |
| Server | 71,588 tokens/s |
⚠ SGLang 未提交 MLPerf v6.0——三方同硬件对比不存在。
Baseten B200 Blackwell 实测重要归因澄清（Baseten Blog 2026-10-02，生产警示）：⚠ 重要归因警示：Baseten "B200 +90% Decode / 2.33× TTFT" 数据来自 MetaInfer 定制引擎（Baseten 内部优化引擎），非通用 vLLM。正确表述："B200 上定制引擎（MetaInfer）比通用 vLLM 快 90%"，而非 "vLLM 在 B200 上快 90%"。
5.2 TCO 与成本换算
吞吐差距经济换算：SGLang/LMDeploy (~16,200) vs vLLM (~12,500) 的 29% 吞吐量差距 ≈ 每月 $15,000 GPU 成本节省（百万请求/天，PremAI 2026 横评）。
H100 定价趋势（2026）：H100 定价已降至 $3-4/hr（B2x from $8），推理成本持续下降。
六、开放问题与趋势
6.1 开放问题
- Orthrus FP32 速度数据（⚠ P0 最高优先级）：独立复现发现 BF16 下仅 45% 轨迹匹配，FP32 恢复 100%；但 FP32 下加速比是否崩溃仍未披露；代码和 prompt 集未公开
- FP8 RL 全流程不稳定根因：熵值异常飙升的具体机制在原文 §3-§5，需读全文补充（arXiv:2609.22870）
- vLLM-Ascend 昇腾 910B 生产数据：国产芯片推理能力对标 H100 的具体数字和生产适用性待核实
- BeaconKV 生产边界条件：在何种 KV cache 压力下 HBM 卸载开始产生边际收益递减
- Looped LM CDB 生产集成：Continuous Depth Batching 是否计划合入 vLLM 或 SGLang，具体时间表待确认
- HookPoint CUDA kernel 集成状态：是否已合入 vLLM 官方，overhead 数据（3.6%）是否可在生产环境复现
- TurboQuant 官方 Python 发布：截至 2026-10 尚无官方实现，关注 Google Research GitHub
- 推理后端诱导方差的 H100/B200 数字：arXiv:2605.19537 的 L40 数据（17.2%）是否在高端 GPU 上同样显著
- NVIDIA Dynamo SLA-Based Planner 生产验证：release/1.5.0 新功能，生产验证程度未知
- HIPFire 生产实战数据：GitHub Trending 新兴项目，实战性能数据缺乏独立验证
- galahad-kv 生产集成：开源代码/Gemini 集成状态；NVMe 带宽是否构成 50M token 场景瓶颈
- SSD 生产实现状态：Speculative Speculative Decoding 在 SGLang 的具体实现路径和 production readiness
- QATFactory 生产集成：GitHub repo 和 Hugging Face 配套 checkpoint 状态
- JIL 调度器防御落地：vLLM/SGLang 粗粒度区间防御实现状态
- LLM-as-Jev 决策校准实测：KL 散度惩罚 + 树分解列表式损失在生产 Router 中的实际效果
6.2 趋势
- 第三拐点：瓶颈从 per-inference FLOPS 转向系统级（并发会话管理、KV-cache 持久化，长上下文跨轮累积、工具调用外部状态管理）
- MoE Serving 三件套确立：CascadeEP（异步专家调度）+ Speculating Experts（预测预取）+ CrossPool（冷启动多 LLM）共同构成 2026Q4 MoE Serving 标准优化手段
- SlimWise MoE 阶段层专家剪枝：从 token 层统一路由到阶段层差异化剪枝，MoE serving 进入"调度+剪枝"双轴优化时代
- BP-KV + DeCoPrune 跨模态驱逐方法论双轴：从「信号保真」（注意力质量/PPL）到「行为保真」（输出分布 KL 散度）和「去噪一致性」（视频扩散），KV cache 压缩方法论完成范式转换
- 投机解码创新加速：SSD（Speculative Speculative Decoding）消除 drafting 与 verification 的顺序依赖，实现 2×（标准SD）/5×（AR）加速；HPCA 2026 和 SC26 新增自适应/集体投机解码方向
- LMDeploy 第三引擎确立：纯 C++ TurboMind 引擎在 H100 上与 SGLang 并列 ~16,200 tok/s，量化模型部署首选
- 混合注意力模型生产三坑：Qwen3.8-27B 类模型在 vLLM（sequence limit）、SGLang（state cache cap）和 SGLang Mamba（max_running_requests capped to 12）上均需专项调参
- 蒸馏-推理协同：FP8 RL 全流程不稳定问题尚未解决，"量化+纠错联合设计"成为新范式（QATFactory）
- 评测范式升级：Orthrus 复现发现 lm-eval-harness 无法检测 45% vs 100% 的系统性盲区；ICML 2026 复现挑战揭示 23% 论文 claim 证伪率
- 协议层标准化：MCP 无状态化 + llm-d CNCF Sandbox + NVIDIA Grove K8s 原生 CRD + NVIDIA NIM Profiles 标准化命名，Agent-Engine 接口层进入标准化阶段
- 解耦推理四维度完整图谱：AMPD（计算解耦）+ Mooncake（存储解耦）+ Dynamo（内存解耦）+ Disagg Quantization（量化解耦），共同构成 2026Q4 解耦推理完整体系
- AI-for-Systems 闭环：SEIS（2610.04646）验证 AI Agent 自动优化推理引擎的完整闭环；RoofLang（2609.12551）验证 AI Agent 自动设计推理系统配置——2026年正式进入 AI 自我优化推理系统阶段
- 调度器安全新维度：JIL 攻击（2610.03430）系统性揭示"长度预测调度器攻击面"——多租户 LLM 服务的调度层安全正式成为工程议题
- Agent 框架格局重塑：AutoGen 维护 + Microsoft Agent Framework 1.0 崛起；推理引擎（vLLM/SGLang）与 Agent 框架（LangGraph/CrewAI/MAF）正交分层
- LLM Router 三大失败模式：难度盲区 + 长度反转 + 语义匹配失败（2610.02762）——Router 选型必须对抗性测试，不能仅依赖标准基准
- LLM Operability 工程化：Stack Overflow Blog Part 5 将 LLM 系统运维提升为独立工程学科——Gateway 作为单一瓶颈 + decision_id 贯穿全链路 + 六大可操作性原则
- KV Cache 作为第一等状态对象：galahad-kv 将 KV state 持久化到 NVMe，实现 50M token 窗口且比重算更快——KV Cache 从"计算中间结果"演进为"可持久化状态"
- SGLang vs vLLM 选型精细化：Spheron Oct 2026 量化数据确立"prefix overlap >60% 时 SGLang 显著领先"的工程判断依据，vLLM 在 Blackwell 原生性能和 Eagle3 投机解码成熟度上保持优势
七、引用与参考
arXiv:2309.06180 · arXiv:2403.05527 · arXiv:2404.19769 · arXiv:2412.14219 · arXiv:2501.01005 · arXiv:2501.09136 · arXiv:2502.07115 · arXiv:2502.20330 · arXiv:2504.11320 · arXiv:2504.19720 · arXiv:2504.19874 · arXiv:2505.01280 · arXiv:2505.02922 · arXiv:2505.11329 · arXiv:2505.18825 · arXiv:2505.19537 · arXiv:2505.19660 · arXiv:2506.01927 · arXiv:2506.09713 · arXiv:2507.02574 · arXiv:2507.06608 · arXiv:2507.11507 · arXiv:2507.17715v · arXiv:2507.21596 · arXiv:2507.27042 · arXiv:2507.29167 · arXiv:2508.04925 · arXiv:2508.09442 · arXiv:2508.14544 · arXiv:2509.01809 · arXiv:2509.15000 · arXiv:2510.02758 · arXiv:2510.09665 · arXiv:2511.01815 · arXiv:2511.02230 · arXiv:2511.22880 · arXiv:2512.02337 · arXiv:2601.05047 · arXiv:2601.15232v · arXiv:2601.20408 · arXiv:2602.05073 · arXiv:2602.06036 · arXiv:2602.09323 · arXiv:2602.14516 · arXiv:2602.21548 · arXiv:2603.04428v · arXiv:2603.09619 · arXiv:2603.10342 · arXiv:2603.13358 · arXiv:2603.16104 · arXiv:2603.19289 · arXiv:2603.20397 · arXiv:2604.19769 · arXiv:2604.25724 · arXiv:2605.00528 · arXiv:2605.01280 · arXiv:2605.01604 · arXiv:2605.03375 · arXiv:2605.11093 · arXiv:2605.16867 · arXiv:2605.17613 · arXiv:2605.18825 · arXiv:2605.19537v · arXiv:2605.29639 · arXiv:2606.01927 · arXiv:2606.02964 · arXiv:2606.03458 · arXiv:2606.06090 · arXiv:2606.14589 · arXiv:2606.16135 · arXiv:2606.17104 · arXiv:2606.18431 · arXiv:2606.19746 · arXiv:2606.20295v · arXiv:2606.21649 · arXiv:2606.24506 · arXiv:2606.26875 · arXiv:2606.31145 · arXiv:2606.31519 · arXiv:2607.02574 · arXiv:2607.05708 · arXiv:2607.08057 · arXiv:2607.09172 · arXiv:2607.13125 · arXiv:2607.16859 · arXiv:2607.17715v · arXiv:2607.17979 · arXiv:2607.20468 · arXiv:2607.21596 · arXiv:2607.22157 · arXiv:2607.25431 · arXiv:2607.26004 · arXiv:2607.26627 · arXiv:2607.27042 · arXiv:2607.27945 · arXiv:2607.29167 · arXiv:2608.00902 · arXiv:2608.01526 · arXiv:2608.01735 · arXiv:2608.03216 · arXiv:2608.03487 · arXiv:2608.03893 · arXiv:2608.04010 · arXiv:2608.04771 · arXiv:2608.06557 · arXiv:2608.07009 · arXiv:2608.08097 · arXiv:2608.09444 · arXiv:2608.09867 · arXiv:2608.10615 · arXiv:2608.10812 · arXiv:2608.13040 · arXiv:2608.13237 · arXiv:2608.13391 · arXiv:2608.13426 · arXiv:2608.13499 · arXiv:2608.13667 · arXiv:2608.14277 · arXiv:2608.14333 · arXiv:2608.15380 · arXiv:2608.15869 · arXiv:2608.16157 · arXiv:2608.17391 · arXiv:2608.18027 · arXiv:2608.19662 · arXiv:2608.19758 · arXiv:2608.20359 · arXiv:2608.20953 · arXiv:2608.21281 · arXiv:2608.21500 · arXiv:2608.22643 · arXiv:2608.23670 · arXiv:2608.24040 · arXiv:2608.25832 · arXiv:2608.26070 · arXiv:2608.26530 · arXiv:2608.26623 · arXiv:2608.27455 · arXiv:2608.27529 · arXiv:2608.27875 · arXiv:2608.28460 · arXiv:2608.28911 · arXiv:2608.29188 · arXiv:2608.29974 · arXiv:2608.30135 · arXiv:2609.00581 · arXiv:2609.00891 · arXiv:2609.01072 · arXiv:2609.01343 · arXiv:2609.01437 · arXiv:2609.01453 · arXiv:2609.01532 · arXiv:2609.01572 · arXiv:2609.01601 · arXiv:2609.01836 · arXiv:2609.01925 · arXiv:2609.02029 · arXiv:2609.02496 · arXiv:2609.02998 · arXiv:2609.03430 · arXiv:2609.03949 · arXiv:2609.04010 · arXiv:2609.04263 · arXiv:2609.04490 · arXiv:2609.04971 · arXiv:2609.05295 · arXiv:2609.05565 · arXiv:2609.06008 · arXiv:2609.06128 · arXiv:2609.06674 · arXiv:2609.06702 · arXiv:2609.07139 · arXiv:2609.07529 · arXiv:2609.07821 · arXiv:2609.09085 · arXiv:2609.09156 · arXiv:2609.10226 · arXiv:2609.10266 · arXiv:2609.11085 · arXiv:2609.11209 · arXiv:2609.11294 · arXiv:2609.11412 · arXiv:2609.11582 · arXiv:2609.11699 · arXiv:2609.11744 · arXiv:2609.12551 · arXiv:2609.13141 · arXiv:2609.13285 · arXiv:2609.15504 · arXiv:2609.17391 · arXiv:2609.17475 · arXiv:2609.17652 · arXiv:2609.18063 · arXiv:2609.19169 · arXiv:2609.19499 · arXiv:2609.19656 · arXiv:2609.19657 · arXiv:2609.19969 · arXiv:2609.20511 · arXiv:2609.20519 · arXiv:2609.20612 · arXiv:2609.20625 · arXiv:2609.20715 · arXiv:2609.20784 · arXiv:2609.22870 · arXiv:2609.23087 · arXiv:2609.23130 · arXiv:2609.23130v · arXiv:2609.24797 · arXiv:2609.24972 · arXiv:2609.25053 · arXiv:2609.26333 · arXiv:2609.26550 · arXiv:2609.26796 · arXiv:2609.26777 · arXiv:2609.27746 · arXiv:2609.27981 · arXiv:2609.29421 · arXiv:2609.29845 · arXiv:2609.31291 · arXiv:2609.31415 · arXiv:2609.32259 · arXiv:2609.33252 · arXiv:2609.33485 · arXiv:2609.34117 · arXiv:2609.34645 · arXiv:2609.35629 · arXiv:2609.36322 · arXiv:2609.36636 · arXiv:2609.37725 · arXiv:2609.39096 · arXiv:2610.00267 · arXiv:2610.00544 · arXiv:2610.00559 · arXiv:2610.00182 · arXiv:2610.00905 · arXiv:2610.01428 · arXiv:2610.01767 · arXiv:2610.01871 · arXiv:2610.01936 · arXiv:2610.02076 · arXiv:2610.02150 · arXiv:2610.02191 · arXiv:2610.02196 · arXiv:2610.02304 · arXiv:2610.02508 · arXiv:2610.02710 · arXiv:2610.02732 · arXiv:2610.02762 · arXiv:2610.02772 · arXiv:2610.02840 · arXiv:2610.03020 · arXiv:2610.03136 · arXiv:2610.03140 · arXiv:2610.03240 · arXiv:2610.03367 · arXiv:2610.03394 · arXiv:2610.03421 · arXiv:2610.03430 · arXiv:2610.03509 · arXiv:2610.03574 · arXiv:2610.03632 · arXiv:2610.03664 · arXiv:2610.03710 · arXiv:2610.03715 · arXiv:2610.04116 · arXiv:2610.04616 · arXiv:2610.04631 · arXiv:2610.04646 · arXiv:2610.04722 · arXiv:2610.05033 · arXiv:2610.05062 · arXiv:2610.05162 · arXiv:2610.05622 · arXiv:2610.05709 · arXiv:2610.05782 · arXiv:2610.05826 · arXiv:2610.06184 · arXiv:2610.06479 · arXiv:2610.06666 · arXiv:2610.08463 · arXiv:2610.09684 · arXiv:2610.10845
本次变更
2026-10-09 | Tom
- Oct09午后：BP-KV行为保持压缩(2610.06479)+SSD(5×AR)+Spheron Oct26 SGLang vs vLLM量化对比+galahad-kv 50Mtoken原子上下文；引→471