inference · 知识库活文档

  • 更新：Oct27午：DeepInfer开源栈+aisimulate部署生成器+KServe CRD路由+KV约束调度负结果+Nanbeige本地部署；引→546

一、现状全景：LLM 推理工业化成熟与框架格局

1.1 六引擎格局与 2026 Q4 生态快照

TGI 正式进入维护模式（2026-03-21，Hugging Face 官方）：ongoing work 限制为 small bug fixes、文档更新与轻量维护；官方推荐迁移目标为 vLLM、SGLang 及 llama.cpp / MLX 等本地引擎。这是 2026 年推理引擎格局最大里程碑事件——Hugging Face 官方认证两强格局。

GitHub Stars 生态成熟度快照（2026-10）：Ollama 182,296 stars（2026-10-06）；vLLM ~92.7K；SGLang ~36.4K（vLLM 的 39%）。2.5× 差距反映生态成熟度差异。

antirez/ds4：C 单文件 DeepSeek V4 Flash 专用推理引擎（GitHub Trending，21.9K ⭐）：single-purpose 引擎（只跑 DeepSeek V4 Flash/PRO），与 llama.cpp 的 generalism 形成"一个模型跑透"对照；C 单文件零外部依赖，Metal / CUDA / ROCm 三端原生。实测 Mac M5 Max FP16 460 tok/s prefill / 39 tok/s decode；DGX Spark GB10 vLLM fork 52 tok/s。量化混合精度——IQ2_XXS（routed experts gate/up）+ Q2_K（down proj）+ FP8 E4M3（dense/attention）+ BF16（embeddings）。OpenAI 兼容 API、1M token context、thinking mode。MIT；作者为 Redis 作者 Salvatore Sanfilippo。

DeepSeek DeepInfer 开源（AINews / swyx 已核查，2026-10-25）：按 vision encode / prefill / decode 三阶段解耦；推荐部署形态为 prefill 用 8 卡机、decode 用 64–128 卡超节点，decode 侧靠 wide expert parallelism 分摊 MoE 专家。能力清单含 attention/data/context parallelism、EPLB、DSpark 式投机解码、SWA bounded replay、异步调度、结构化输出、batch-invariant inference、确定性采样；环境要求 Linux + Python 3.12 + CUDA 13，或华为 Ascend 950（DEEPINFER_ACCELERATOR=nvidia|ascend，CANN 9.2）。文中明确提醒在线服务仍需外部 KV cache 管理与 P/D 解耦。⚠ 155 万亿 tokens/天、每卡每小时 38 美元属转述的官方口径，不足以支撑硬件构成结论；未含源码级验证。

vLLM on Vera Rubin NVL72（Spheron Blog，Oct 2026）：吞吐 >7.8× vs GB200 基线——Vera Rubin 的内存带宽优势首次在 vLLM 官方生态得到量化验证。⚠ 基准条件（对比对象、batch size、序列长、模型、量化）未披露。

推理引擎选型决策树（2026-10 修订版）：

高并发 + 通用batch → vLLM（生态最大，92.7K GitHub stars）
共享前缀 + 多轮 + agent → SGLang（RadixAttention 优势，36.4K stars）
H100 单机极致低延迟 → TensorRT-LLM（首 token 延迟最低 0.54s）
本地开发 / 边缘 / CPU → llama.cpp
DeepSeek V4 Flash 专用极致优化 → ds4（C 单文件，MIT，21.9K ⭐）
Apple Silicon 本地推理（Qwen/Nemotron） → Kapitsa（experimental，209 ⭐）
量化模型 + 国产生态 + 昇腾 → LMDeploy（TurboMind C++ 引擎）

AWS DLC vLLM 0.31.0 + ARM64 无 GPU 推理（GitHub aws/deep-learning-containers，2026-10）：vLLM Server ARM64 CPU v1.0（基于 vLLM 0.30.0，Graviton AL2023 无 GPU 路径）；镜像矩阵含 vLLM 0.30.0（Ubuntu）、vLLM Server v2.5（AL2023）、vLLM-Omni 0.28.0、SGLang v1.4。意义：补全 AWS 推理容器从 GPU 加速到纯 CPU 推理的最后覆盖。

vLLM-Ascend 昇腾部署实战（CSDN Oct 2026）：pip / Docker / 离线脚本三路径，OpenAI 接口对齐，支持多机多卡。避坑 checklist：/etc/ld.so.conf.d/ascend.conf + ldconfig 静默失败、CANN 版本五件套、set_env.sh 环境变量管理。DeepSeek-V4 on 昇腾 910B 压测调优（agent.csdn.net 2026-10）：关键参数 --max-num-batched-tokens 8192、--gpu-memory-utilization 0.9、--enable-chunked-prefill；DNS 抖动致 QPS 跳变的排障路径。

vLLM-Kunlun 昆仑芯适配（CSDN Oct 2026）：KunlunDevicePlugin 插件化方案；Attention 层延迟 152.6ms → 42.3ms（约 3.6× 加速），手段为算子融合、向量化、RMS Norm 深度优化。⚠ 证据缺口：实测环境（GPU 型号、batch size、模型尺寸）未在 snippet 中呈现，CUDA→昆仑迁移 diff 需完整上下文验证可复现性。

NVIDIA Ian Buck 访谈关键信号（Substack，2026-10，Tae Kim 主持）：GPU 路线图 Blackwell 首发 4× token、Vera Rubin 开局 3×（OpenAI Astra）、72h 自优化后 6×；Dynamo 定位为"inference OS"（跨数据中心调度并复制 KV）；CUDA 1.0 至今仍可运行。⚠ 数字来自被采访方，缺独立复测；ASIC $/token 并列数据未给；"OS for inference" 属营销扩张用法，不应作体系结构断言。

1.2 vLLM v0.30 / SGLang v1.2.1 双雄深度对比

vLLM v0.30.0（2026-09-22，762 commits / 315 contributors / 104 新特性）——九项关键特性： - Fast Start：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）取代旧 PagedAttention V1；H200 初始化 3.5×（28.9s→8.2s）；Spheron 实测（Qwen3-0.6B @ GB200）MRV2 56% 更高吞吐 - 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 调度 draft-verification budget，MiniMax-M3-MXFP8 EAGLE-3 达 2.09× - Disaggregated prefill/decode/encode：P/D/E 三路解耦，支持 AMD MORI-IO（MI300X） - Eagle3/EAGLE 3.1 speculative decoding：低并发（1-4）30-45% decode 加速，中并发（10-20）15-20%——投机解码生产成熟度分水岭

vLLM v0.30 changelog Sep 28 追加（+12 项）：Dynamic SD；DFlash with FlashInfer；mixed KV page sizes；EAGLE3 for Qwen3；reduced TP communication for large-vocab drafts；EAGLE multimodal encoder cache fixes；runtime draft weight update；hybrid (SWA + full attention) DFlash drafters；SWA support for qwen-eagle3；Gemma4-12B DSpark draft model；DSv4 DSpark on AMD；separate kv_cache_dtype for speculative_config。

vLLM v0.30.1rc1 生产 pin 建议（AI Infrastructure Digest 2026-09-27）：建议 pin 到 v0.30.1rc1，避开 v0.30.0 已知 bug——GLM-5.3 集成中 DFlash/DSpark 内存损坏；Mamba/GDN 元数据在 KV cache grouping 下复用 bug。⚠ v0.30.0 的 Mamba bug 与 SGLang Mamba bug 相互独立，不能互相替代修复。

⚠ P0 vLLM Bug：Qwen3.8 + DFlash2/DSpark + Prefix Cache Hit = Corrupted Output（v0.30 / v0.31，Oct 2026）：触发条件为 Qwen3.8-27B target + compressed-tensors NVFP4 checkpoint + hidden-state speculative drafter (DFlash2/DSpark) + prefix-cache hit + vLLM 0.30 或 0.31；症状是早期请求正常，随后出现重复 token 的连贯输出。Workaround："attention_backend": "TRITON_ATTN"（v0.31.0 实测可修复 FP8 target）、强制 cache miss（cache_salt）、或关闭 speculative decoding。不影响 MTP drafter、vLLM 0.29、非 Qwen3.8 系列。来源：GitHub Issue #60174 + RAMGPT 独立分析。

SGLang v1.2.1（2026-09-23，LeetLLM 核查版）：2026-09-23 发布 v1.2.1 稳定版；v1.2.1 相较 v0.5.20 的具体 changelog 需核实 release notes。⚠ LiquidAI LFM2.5-24B-A2B 基准使用 SGLang 0.5.22.dev 开发版（commit 488869c2d0f3321299488bcf221934df40b06454），正式版 vs 开发版 benchmark 不可直接对比。

SGLang 五项关键特性：RL Sampling Masks（每 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×）；FlashInfer all-to-all routed MoE（flashinfer_trtllm_routed，DeepSeek V3 类 MoE 落地加速）；FP8 MLA 128K 优化（SGLang Project 官方，DeepSeek V4 系列 FP8 + MLA 在 128K 上下文额外 +20%）。

SGLang Model Gateway（SGLang v0.5.6，CSDN Oct 2026）：生产级多模型网关，统一 OpenAI 兼容 API、per-model 限流、prefix-aware 路由；含完整 K8s YAML 模板（Deployment, replicas=4, namespace=production）；集成 HiCache KVCache Offload，支持跨模型共享 KV cache。

⚠ SGLang 0.5.20 自限速工程隐患（Oct 11 Winder.ai 实测，P0 生产警示）：SGLang 0.5.20 会在内部检测到 state cache 不足时自动降低并发度（caps its own concurrency to fit its state cache），但该行为仅在日志中提示、不在 API 层暴露，客户端无法通过 API 判断自己是否被限速。工程隐患：配置了期望并发度但 SGLang 静默 cap，实际 QPS 低于配置值且无错误响应，难以诊断的"静默降级"——与"Qwen3.8-27B SGLang 默认将并发限制在 20"是同一底层问题的不同侧面。

SGLang 2026-10 月 Bug 集中（4 个 GitHub Issues，生产警示）：#43488 DSV4.1+Flash+DSPARK CUDA OOM 崩溃（每 15-25 分钟稳定复现），根因是 CUDA allocator 而非 KV pool 泄漏——只盯 KV pool 利用率会误判正常；#43557 PD disaggregation 模式切换 illegal memory access；#43523 多模态 transport slice 队列 abort 泄漏；#43402 DeepSeekV3Detector streaming 静默丢弃（相同 increment counter 的两个工具调用第一个被静默丢弃）。

⚠ SGLang 29% 性能领先条件性修正（Spheron Oct 2026，重要选型前提）：SGLang 在 prefix-heavy traffic（共享 system prompt + 多轮 agent）下领先 vLLM ~29%，优势完全来自 RadixAttention 的 prefix reuse——请求独立无共享前缀时差距缩小到 1-4%。H100 Llama 3.1 8B 实测：SGLang/LMDeploy ~16,200 tok/s vs vLLM ~12,500 tok/s。决策树补充：共享 system prompt + 短用户轮次 → SGLang；完全独立请求 → vLLM；量化模型 + 受限硬件 → LMDeploy。

SGLang vs vLLM 量化对比（Spheron Oct 2026 + Winder.ai Sep 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 显著受益
Qwen3.8-27B H100 50并发 1,610 tok/s 1,725 tok/s SGLang 领先约 7%
Blackwell / B200 native ✅ FlashAttention 4 backend on SM100/SM103 正在追赶 vLLM Blackwell 原生优势
Speculative decoding ✅ EAGLE3/EAGLE 3.1 + MRV2 成熟集成 ⚠ 实验性 vLLM 更成熟
结构化输出高流量 中等 99.8% 成功率 SGLang 原生优势
EAGLE 3.1 生产 ✅ 完整生产支持 ⚠ 实验性 vLLM 领先

Qwen3.8-27B 混合注意力三引擎 Bug 对照（Winder.ai Oct 2026）：vLLM 0.30 在 H100 上拒绝启动直到降低 sequence limit；SGLang 0.5.20 静默将并发限制在 20，直到 state cache 扩大到能容纳 50 个并发请求；TRT-LLM 1.2.1 无法加载 Qwen3.8，1.3.0rc28 FP8 checkpoint 启动失败（2026-09 open bug）。

SGLang BCG（Breakable CUDA Graph）生产回归隐患（LMSYS Org 2026-08-17）：在 attention boundary 插入 eager break，缩小 CUDA Graph 捕获范围。实测收益（Qwen3-235B-A22B）：graph builds 5× faster vs tc_piecewise；Prefill up to 1.93× faster vs eager；GPU 成本节省估算 $2,467/月（10×H100 24/7）。⚠ 回归隐患：kernel coverage 72.7% 但 idle 占 61.3% window time，per-layer graph break idle 约 590µs/layer，部分用户报告启用后性能反而下降；BCG 已成 SGLang prefill 默认策略（2026-04-24 合并），升级 v0.5.19/v0.5.20 后默认行为已变，生产部署建议做 A/B 测试。

1.3 推理引擎可复现性与静默超参数

推理后端诱导方差（arXiv:2605.19537，⭐⭐⭐⭐⭐）： - 不同推理引擎对同一模型同一输入产生显著不同的 token 分布 - L40 GPU 上后端诱导方差 up to 17.2% Max-Max 差

Silent Hyperparameter — 推理后端导致 Benchmark 偏差高达 16 个百分点（arXiv:2605.19537v1）：同一模型 + 同一权重 + 同一提示，推理后端不同 → Benchmark 结果偏差高达 16 个百分点；L40 上后端诱导方差 up to 17.2% Max-Max 差。含义：推理后端（vLLM / llama.cpp / TensorRT 等）是不容忽视的"静默超参数"。工程影响：可复现性评估必须将后端作为受控变量；后端不同的跨论文 benchmark 不可直接比较。生产必须：所有 benchmark 报告必须注明推理引擎版本和硬件配置。

vLLM Batch Invariance — Temperature=0 非确定性（Spheron Blog 2026-09-30）： - 根因：Continuous Batching 下即使 temperature=0 也存在非确定性输出——Batch-Invariant Kernels 对输入 token 的不同排列产生不同算子融合 - SGLang 修复：Deterministic Attention，平均吞吐降 34.35% - 影响场景：RL 数据生成、可复现评测、精确 Benchmarking——多数生产 API 场景可忽略

推理后端 16pp 偏差警示进入 benchmark SOP：该发现已推动 LLM 系统可复现性 SOP 的修订——推理引擎选择必须作为受控变量写入实验设计规范。

1.4 六引擎五档并发×cost Benchmark（2026-10 实测矩阵）

H100 80GB + Llama 3.3 70B FP8 + 200 prompts（Spheron Blog 2026-10，★生产级可复现）：

引擎 50 并发吞吐 TTFT p50 冷启动 $ / M output tok
vLLM 1,850 tok/s 120ms ~62s $0.26
SGLang 1,920 tok/s 112ms ~58s $0.27
TensorRT-LLM 2,100 tok/s 105ms ~28min $0.30

H100 Llama 3.1 8B 五档并发实测（Winder.AI Sep 2026，多源确认）：

引擎 1 concurrent 10 concurrent 50 concurrent TTFT p50 @50 $ / M output tok
SGLang 154 tok/s 1,233 tok/s 3,617 tok/s 0.73s $0.26–0.44
vLLM 150 tok/s 1,235 tok/s 3,688 tok/s 0.68s $0.26–0.61
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

关键格局判断： - vLLM 50 并发吞吐（3,688 tok/s）略优于 SGLang（3,617），SGLang TTFT p50（112ms vs 120ms）更快——各领先一维 - TensorRT-LLM TTFT p50 105ms 最低，冷启动 ~28min 是唯一缺点 - SGLang 与 LMDeploy 差距仅 0.5%（16,215 vs 16,132），量化模型部署首选 LMDeploy - SGLang Agent 工作流专项优势：10 次工具调用场景领先 vLLM 127%（420ms vs 185ms）

Blackwell RTX PRO 6000 实测（Winder.ai Oct 2026，Qwen3.8-27B hybrid linear-attention，8× RTX PRO 6000，50 并发）：

引擎 Throughput 备注
SGLang 1,725 tokens/s 社区针对 Blackwell 非官方 build
vLLM 1,610 tokens/s FP8 packed path 存在兼容问题

⚠ vLLM FP8 packed path 在 Blackwell 存在兼容问题，SGLang 用社区非官方 build 适配，两者差距约 7%。

1.5 vLLM 生产部署工程体系（CSDN Oct 2026，高价值源码级解读）

vLLM 生产部署工程体系（CSDN Oct 2026）：production-stack 源码级解读（⭐⭐⭐⭐⭐）——框架对比（vLLM / SGLang / TensorRT-LLM）+ 量化 + 基准 + 投机采样 + KV Cache + 设备部署 + MLflow/HF 集成 + 模型版本管理 + 灰度发布，含 YAML 配置；vLLM 生态 K8s 集成实战——vLLM + SGLang K8s 多模型部署指南；Kubernetes + vLLM 弹性推理架构——单端口管理与多模型方案对比；KV Cache 原理详解（PhilZhou）——为何只缓存 K/V 不缓存 Q。

1.6 2026-10 引擎与部署项目增量信号（repo card 级证据）

  • raullenchai/Rapid-MLX（4022 ⭐ / 周增 +55 / Python）：Apple Silicon 上基于 MLX 的 OpenAI + Anthropic 双协议推理服务器，主打 coding agent 工具调用可靠性——17 种工具解析器、prompt cache、推理分离、云端路由；自述同权重下比 mlx-lm 最高 4×、缓存 TTFT 0.08s。⚠ 均为自述，无第三方复现，测试模型/并发/缓存条件未给。
  • recursive-oss/rec（225 ⭐ / 周增 +49 / Apache-2.0 / experimental，2026-10-23）：自述 "Our lightning-fast inference engine"。⚠ 无 README 摘要、无模型支持清单、无吞吐延迟基准、无 API 兼容性声明；仅作"轻量专用引擎持续涌现"的信号，不可据以选型。（2026-10-27 重新采集，计数变化不构成新观点。）
  • NVIDIA/flare-local-inference（638 ⭐ / 周增 +88 / Apache-2.0 / research）：NVIDIA 名下本地推理仓库，2026-10-24 有提交。⚠ repo card 无简介与正文，功能范围完全未知。
  • eagle-hq/EAGLE-4（957 ⭐ / 周增 +0 / 2026-10-24）：官方说明 "Official Inference Code of EAGLE-4"。⚠ 不可据此宣称 EAGLE-4 优于 EAGLE 3.1：draft 架构、接受率、加速比、是否合入主线全无数据。
  • Lore-Hex/token-exchange-neocloud-in-a-box 本轮复查（非新观点）：重新采集为 51 ⭐ / 周增 +0，功能描述不变（Intel TDX + NVIDIA 机密计算节点，面向 DeepSeek-V4.1-Flash 与 GLM-5.3，上架 TrustedRouter）；按"采集时间/热度变化不算新观点"处理，仅更新计数，详见 §5.6。
  • colinhacks/reylo（1297 ⭐ / 周增 +737 / Rust / MIT，2026-10-26）：SQL 文件导入 TypeScript 的类型推导工具。⚠ 关键词命中"inference"但属编译器类型推导，与 LLM 推理服务无关，本档不纳入；仅记录以免后续重复误纳。

二、KV Cache 管理：六纪元与技术路线图

2.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 范式

LMCache — 跨引擎 KV Cache 共享层（arXiv:2510.09665v2，⭐⭐⭐⭐⭐）：首个跨 vLLM 与 SGLang 的 KV cache 共享开源方案，把 KV cache 移出 GPU 显存存入 host/CPU/远端存储，支持跨引擎跨请求复用；两条路径为 Cache Offloading（Prefix Reuse）与 PD Disaggregation。性能：LMCache + vLLM 在多轮问答与文档分析负载上最高 15× 吞吐提升。三大贡献：批量 KV 数据搬运（批量化 + compute/IO 流水线重叠）、模块化 KV Connector、First-class Control API（跨 GPU/CPU/存储/网络层编排）。 - 生产洞察（LMCache 真实用户数据）：从远端存储拉取 KV 对 prefill 延迟有显著收益；Context truncation 可将 prefix cache hit ratio 降低一半——对依赖前缀复用的 Agent 工作流影响显著。 - ⚠ 可信度注意：benchmark 数字来自 LMCache 自身团队，非中立第三方；跨引擎共享依赖 tokenizer/权重/分块策略一致，模型升级后 cache 失效代价未量化。源码：github.com/LMCache/LMCache

KV Cache 定位升格（LMCache Blog 2026-04-28 + arXiv:2608.01526）：LMCache 官方博文《Stop Calling It KV Cache — It's Something Much Bigger》指出 KV Cache 已成存储/通信/调度原语，不只是 serving 优化产物；NVIDIA 推出 CMX（原 ICMS）标准化推理上下文存储；LMCache、TensorRT、NVIDIA Dynamo、llm-d 均围绕 KV Cache 构建生态；arXiv:2608.01526 "An Internet for the KV Cache" 是 OSDI 2026 论文。

2.2 vLLM Tiered KV Cache Offloading（2026-09-10 官方博文）

vLLM 正式实现 GPU→CPU→NVMe 三层 KV Cache Offloading 动态调度： - 与 OSDI 2026 KV Cache Disaggregation（arXiv:2608.01526）共同构成完整三层体系：软件层（vLLM Tiered Offloading）、板级（DUAL-BLADE）、芯片级（HotInfra PIM） - 与 galahad-kv NVMe 持久化（arXiv:2610.10845）形成互补：galahad-kv 是 byte-exact 原子上下文持久化，vLLM Tiered 是运行时动态调度 - ⚠ 调度策略细节待核实：vLLM 官方博文未明确三层调度触发条件（基于 LRU / token 重要性 / 前缀共享率中的哪一种）；该细节影响生产配置决策

三层 KV Cache Offloading 完整体系（2026 Q4）：

层级 方案 论文/项目 状态
软件层（OS） vLLM Tiered Offloading vLLM 官方 Blog 2026-09-10 ✅ 正式实现
板级 DUAL-BLADE NVMe-direct arXiv:2608.13867 学术研究
芯片级 HotInfra PIM OSDI 2026 学术研究
持久化 galahad-kv arXiv:2610.10845 学术研究

2.3 Cache Compression（Era 5 核心）

KVTC — KV Cache Transform Coding（arXiv:2511.01815，ICLR 2026，⭐⭐⭐⭐⭐）：将经典媒体压缩技术引入 KV cache，三阶段 pipeline——PCA 特征去相关（正交变换）→ 自适应量化（按方差非均匀分配位宽）→ 熵编码。核心性能：Llama 3、Mistral NeMo、R1-Qwen 2.5 上最高 20× 压缩比（特定场景 40×+），超越 token eviction、量化、SVD 等传统方法。工程意义：长上下文（100K+ tokens）KV cache 内存成本大幅降低——与 vLLM Tiered Offloading 形成存储卸载 vs 压缩算法两条并行路线，可叠加使用。已集成入 NVIDIA Dynamo + vLLM。

WUSH-KV — Data-Adaptive KV Cache 量化（arXiv:2609.38121，2026-09）：利用二阶统计量构建数据感知的正交变换，减少量化误差；与 SGLang 集成时采用 OSCAR-style percentile-clipped affine quantization；2-bit 下性能与 OSCAR transform 持平或更优。

1-bit KV Cache — Tailoring the Quantization Space（arXiv:2610.03027，Oct 2026）：1-bit KV cache 面临两个关键问题——不同 channel 对 QK⊤ 的影响不均等（某些 channel 重建误差对注意力得分影响更大），且 VQ 只在同组 channel 共享 codebook 时才能利用 channel 间依赖；技术贡献是为 codebook 设计引入注意力 logits 敏感性分析，实现更优的 1-bit 量化质量。

BP-KV — Behavior-Preserving KV Cache Compression（arXiv:2610.06479，Oct 2026，⭐⭐⭐⭐）：现有免训练 KV Cache 驱逐策略依赖代理重要性信号（注意力质量、PPL），而非直接评估"移除该 token 是否改变模型输出分布"。方法创新：从「信号保真」走向「行为保真」——通过驱逐前的前向统计量评估压缩缓存所诱导的 logits 与完整缓存下一 token 分布之间的 KL 散度。范式意义：首个将"行为保真"作为 KV Cache 压缩目标的免训练框架，对 vLLM/SGLang 的回收策略有直接替代参考价值。

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× 推理加速。

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）：将每个 ~16,000 token 块的 KV state 以加密形式存到本地 NVMe，回复时直接加载（byte-exact），无需重算。关键数据（Gemma 4 12B 与 31B @ H100，实测 50,000,000 tokens）：探测的每个块均从加密存储加载，无重算（100/100 块成功率）。⚠ 待核实：galahad-kv 开源代码 / Gemini 集成状态；生产环境 NVMe 带宽是否构成瓶颈。

2.4 KV Cache 三级驱逐策略体系（2026 Q4 完整图谱）

Continnum — KV Cache TTL 管理 for 多轮 Agent 工具调用场景（arXiv:2511.02230）：多轮 agent 场景下工具调用持续时间可变，现有 KV Cache 系统不感知 tool-call 特征导致调度次优；Continnum 引入 KV Cache TTL 机制，在 tool-call stall 时 pin KV cache。8×H100、OpenHands Agent + GLM-4.5-fp8 实测：Continnum 单节点 throughput 领先 ThunderAgent。与 AgentSysBench"模型推理不是 agentic 主要成本"的发现共同指向 agentic inference 成本优化新路径。

Multi-Segment Attention — 位置感知 block 级 KV Cache 驱逐（arXiv:2606.02964）： - 提出 block 级、位置感知的 KV cache 驱逐策略 - 与 Continnum（agent 场景）和 InferCept（请求级）可叠加 - 在 Continnum 基础上额外获得性能提升

三级驱逐策略体系：

层级 机制 论文/项目 适用场景
Block 级 Multi-Segment Attention（位置感知 block 驱逐） arXiv:2606.02964 细粒度 block 复用
请求级 InferCept — 请求内动态调度
Agentic TTL 级 Continnum（KV Cache TTL，tool-call stall pin） arXiv:2511.02230 多轮 agent 工具调用

2.5 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 尚未修复；高安全要求场景需使用有独立租户隔离的推理引擎。

HijackKV — 前缀级 KV Cache 复用安全威胁（USENIX Security 2026）： - 问题本质：前缀级 KV cache 复用因位置无关设计导致 cache hit 率低，同时引入新的攻击面 - 攻击机制：攻击者可通过共享 KV cache 实现跨请求的隐式信息泄露 - 核心矛盾：KV cache 复用的工程优化与安全隔离之间存在根本性张力——加速推理的优化同时创造侧信道 - 工程警示：多租户或共享 prefix 场景下，HijackKV 类攻击是必须评估的新威胁向量

LMDeploy SSRF 漏洞 CVE-2026-33626（Sysdig，2026-04-21）：Server-Side Request Forgery；攻击特征为探测 127.0.0.1:6379/3306/8080 等端口，利用 SSRF 访问 in-cluster 数据存储；受影响版本为 LMDeploy < 修复版本。⚠ 生产必须：确认部署的 LMDeploy 版本，优先升级。

三、调度理论与路由

3.1 调度算法与 JIL 攻击

JIL — Length Prediction Scheduling Attack（arXiv:2610.03430，Oct 2026，⭐⭐⭐⭐）：基于长度预测的 LLM 调度器（如 TRAIL）依赖预测输出长度分配优先级，而预测信号可被对抗性手段操纵。攻击机制：JIL（Jumping the Line）通过优化对抗性后缀，使 lightweight output-length probe 低估输出长度，从而获得更高调度优先级。关键数据：预测输出长度降低最多 83.4%，对抗性请求端到端完成时间缩短最多 1.53×。防御：将长度预测分组为粗粒度区间可减少 JIL 优势。⚠ vLLM 与 SGLang 现有默认调度器尚未实现该防御；高安全多租户场景需评估攻击面。

MC-SF / Online Scheduling for LLM Inference with KV Cache Constraints（arXiv:2502.07115，v5 2026-01-15，摘要级精读）：形式化 KV Cache 动态内存增长 + 批量调度的在线调度问题——KV 占用随解码步线性增长，内存上限直接决定可并发批大小。四段式贡献：① hindsight optimal benchmark——整数规划（IP）在"知晓全部未来到达与长度"理想下求最小总推理时延，是下界参照物而非可部署算法；② 不可逼近性证明——任意到达过程下，任何确定性在线算法都不可能达到常数竞争比（最有价值的负结果，解释生产系统为何必须用 FCFS / SJF / continuous batching 启发式）；③ 据此提出多项式时间在线算法 MC-SF，仅在特定条件下给出常数竞争比；④ 实证线为合成数据集对比 hindsight optimal + 用真实公开推理数据集模拟 Llama2-70B 在 A100 上的表现。 - ⚠ 证据边界：摘要级证据，方法证明与实验章节未读；常数竞争比的条件假设摘要未交代；Llama2-70B 为模拟而非实机，GPU 争抢/显存碎片/NVLink 拓扑/抢占开销被简化；论文卡转述的"延迟 -76%、吞吐 2x、跨层流量 -5.94x"本次未核实，不作结论引用；v3 曾 withdrawn、v5 修订动因未查；论文卡"可复用信息"段落混入 HBM/DRAM 分层与 block-wise streaming attention，与本文调度主题不对应，属卡片层面信息污染风险。 - 后续验证：读 v5 方法与实验节确认条件假设与数字归属；核对卡片分层内容归属。

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）：三大系统性失败模式——难度盲区（最难查询反而不会升级）、长度反转（短答案查询更易被升级，但短回答往往最需要升级到更强模型）、语义匹配失败（语义相似但难度不同的查询给出相反路由决策）。覆盖基准 RouterBench / LLMRouterBench / RouterArena 均无法检测上述缺陷。工程意义：生产 Router 选型必须做对抗性测试，不能仅依赖标准基准。

3.2 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 分别定制计算格式、权重与存储布局。

NVIDIA Dynamo 1.0 GA（2026-03-16，GTC，Apache 许可证）： - 定位为AI 工厂分布式推理操作系统，2026-03-16 GTC 正式 GA，开源（Apache 许可） - 核心能力：分布式推理 + KV-Cache 感知路由 + KV Cache Manager；支持 SGLang / TensorRT-LLM / vLLM 作为引擎，Dynamo 作为统一编排层 - 性能数据：Blackwell 平台上 DeepSeek R1 吞吐提升最高 7×（NVIDIA 官方 benchmarks）；KV-aware Router 4× lower TTFT + 1.5× higher throughput；ModelExpress 大 MoE checkpoint 恢复 up to 7× - 三大核心组件：NIXL KV cache transport（跨 NVLink/InfiniBand 传输 KV tensor）、KV-aware Router、ModelExpress checkpoint 恢复 - 云厂商集成：AWS、Azure、Google Cloud、OCI；社区 8.3K stars（Oct 2026） - ⚠ 可信度注意：7× 来自 NVIDIA 官方 benchmark，非中立第三方；实际收益与 workload、集群拓扑强相关

⚠ SGLang PD Disaggregation 缺失：SGLang 在 PD Disagg（Prefill-Decode 分离）上落后于 vLLM，这对需要大规模 PD 分离的生产部署是重要选型因素；vLLM 已实现完整 PD Disagg 生产支持。

3.3 NVIDIA Dynamo Session-Aware Agentic 推理（PyTorch Blog 2026-10-08）

Session-Aware Agentic Inference with NVIDIA Dynamo（PyTorch Blog，2026-10-08，⭐⭐⭐⭐⭐）：

核心问题：传统请求级推理基础设施无法感知 agent session——单个 agent session 包含大型初始 prefill（数万 token 的 system prompt + 工具定义）、多轮工具调用间 KV cache 保持 resident、以及并行运行的 subagent。核心矛盾：session 壁钟时间大部分消耗在工具调用之间，KV cache 保持常驻但没有生成 token。

Session ID 统一标识符：Dynamo 为每个 agentic chain 分配稳定 session ID，同一 trajectory 内所有 LLM 请求共享 session_id，child session 携带 parent_session_id 连接 subagent。开箱即用编码 agent 支持：Claude Code（x-claude-code-session-id / x-claude-code-agent-id）、Codex（thread-id）、OpenCode（x-opencode-session-id）；自定义 harness 通过 X-Dynamo-Session-ID 单 header 接入，X-Dynamo-Parent-Session-ID 支持 subagent 层级。

Session-Aware 调度：路由与准入控制感知 session working sets（完整 session KV cache 大小），在工具边界施加背压（backpressure）减少 cache thrashing——session 规模超阈值时主动限制新请求进入，防止 KV 被逐出。

Shared KV Cache Indexer（实验性）：共享池 indexer 让 router 在请求放置时感知外部存储中的可复用 KV cache（不只 GPU 显存内）。

Programmatic KV Cache（KvHint 接口）：Session-Prefix Indexer——Dynamo 给 policy intent、引擎执行 session 级前缀索引策略；KvHint——orchestrator 向引擎声明 cache 策略意图（如"pin this session's KV for N seconds"），引擎负责具体 KV 管理；这是第一次在 vLLM 和 SGLang 上实现跨引擎的 session 级 cache 编排。

Tracing 与 Replay：DYN_REQUEST_TRACE=1 开启轻量 tracing，每个请求结束记录 request_end（不存 prompt/response 内容），携带 session 字段、输出 token 数、finish reason、KV cache 指标、工具调用名、per-block sequence hashes；sequence hashes 可离线 replay（dynamo.replay 或 AIPerf），无需重跑模型或工具。

⚠ 可信度注意：数据来自 NVIDIA 官方 PyTorch blog，非中立第三方；KvHint benchmark 数字未披露；session-aware backpressure 阈值未公开；tracing 数据留在引擎侧，不含业务内容。

3.4 长 Prefill 调度冻结：RAG 场景的一等阻塞问题

24K token RAG prompt 触发 1.8-2.4s 调度冻结（2026-10-21 Jay 工程简报）：24K token 的 RAG prompt 在 vLLM 侧触发约 1.8-2.4s 调度冻结，指向长 prefill 阻塞排队这一真实瓶颈。 - 工程含义：与 §1.2 vLLM-Ascend 的 --enable-chunked-prefill、§3.2 的 PD 分离互为印证——长 prefill 场景应优先 chunked prefill / PD 分离 / prefix caching，而非调大 batch。 - 交叉印证：同批 LFM2.5-24B-A2B 基准使用 SGLang 0.5.22.dev，与正式版 benchmark 不可直接对比（呼应 §1.2）。 - ⚠ vLLM 未标版本号、无对应 PR/issue，需回溯原始 issue 确认版本区间与修复状态。

四、投机解码与蒸馏部署

4.1 投机解码：新方法批量涌现（2026年9-10月）

EAGLE 3.1 生产标准确立（vLLM v0.22.0+，2026-05 合并主线）：

并发数 EAGLE-3 基线 EAGLE 3.1 提升 EAGLE-3 → EAGLE 3.1
Concurrency 1 1.00× 2.03× 2.03×
Concurrency 4 1.00× 1.71× 1.71×
Concurrency 16 1.00× 1.66× 1.66×
  • P-EAGLE（AWS 贡献）：在 EAGLE 3.1 基础上额外提升 20-30%（编码任务基准）；已于同期合入 vLLM 主线
  • 生产必配：--speculative-disable-by-batch-size 8——当并发 >8 时自动关闭投机解码，overhead 超过收益
  • ⚠ 已知 Bug（GitHub #25882 open）：量化 verifier + 非量化 drafter 组合启动失败，抛出 KeyError: 'layers.0.mlp.down_proj.weight'

⚠ P0 新 Bug：Qwen3.8 + DFlash2/DSpark + Prefix Cache Hit = Corrupted Output（v0.30 / v0.31）：机制详见 §1.2；影响所有 Qwen3.8 + hidden-state drafter + prefix caching 部署；Workaround 为 "attention_backend": "TRITON_ATTN" 或关闭投机解码；来源 GitHub Issue #60174 + RAMGPT 分析。

Surfing the Activation Wave — Multi-layer Hidden-state Selection for Speculative Decoding（arXiv:2610.12939，Oct 2026）：Decoder 不同层 hidden states 编码互补信息，现有方法依赖固定 position-based heuristic 选层，最优层子集选择是组合问题、穷举不可行；提出基于双标准（informativeness + geometry）的可计算层选择框架。⚠ 待核实：原文未经精读，双标准具体形式、与 SpecScale 实测条件的对比关系需读原文确认。

SpecScale — 投机解码在测试时计算扩展中的系统优化（arXiv:2609.39334，Oct 2026）：投机解码在小粒度、不规则任务上 GPU 利用率低，系统开销可能超过性能收益；提出轻量级 LLM serving 框架，支持 continuous batching、paged attention、prefix KV caching/sharing、fused attention kernels。核心发现：投机解码需要系统级支持才能在 test-time scaling 场景带来净收益。

新投机解码方法一览（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
SSD SGLang GitHub #19896 Speculative Speculative Decoding，消除 drafting 与 verification 顺序依赖；最高 2×（标准SD）/ 5×（AR）
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 端到端速度数据缺失（若 FP32 下 Orthrus 加速比崩溃，则 Orthrus 失去实用价值）；代码和 prompt 集未公开

BentoML 3× Speculative Decoding Guide（Oct 2026）：生产级投机解码实战指南——正确配置的投机解码在真实生产负载下可达 3× 加速。

4.2 蒸馏与长上下文推理

NoLiMa — 长上下文评测超越字面匹配（arXiv:2502.05167，ICML 2025，Adobe Research + LMU Munich）：传统 NIAH/RULER 依赖 needle 与 question 的词面重叠，模型可凭字面匹配通过，高估真实可用上下文长度；方法为设计极小词面重叠的 needle-question 对（虚构"人-目标"对），强制模型做隐式联想。关键发现（13 个商用/开源模型）：短上下文（<1K）大多数正常，32K 起多数准确率跌约一半，位置偏差不再主因，长度本身才是瓶颈；同批模型在 vanilla NIAH / RULER S-NIAH 仍得高分，说明传统榜单普遍高估真实可用长度。反例：Llama 3.3 70B 声称 128K，NoLiMa 有效长度仅 8K；GPT-4o、Claude、Gemini 在 32K 处普遍"腰斩"；CoT 提升但不根治。评测意义：所有声称 128K+ 的商用模型实际有效长度被系统性高估 4-16×。⚠ needle 为合成虚构人物，天然分布外。综合可信度 ★★★★☆。代码 adobe-research/NoLiMa。

QSA — Qwen Sparse Attention：长上下文稀疏注意力混合架构（Qwen4-Exp，transformers v5.16.0 官方支持）：首次实现 linear attention + sparse attention 混合架构——多 query head 对压缩的 key blocks 打分并选择最相关的连续 token blocks，保留不完整尾部 block 不压缩。实测：1M token context 下 prefill 快 7.6×、decode 快 4.9×；90% prefix-cache hit 场景 prefill 吞吐是 Qwen3.7-Plus 的 8.6×。配套架构：GatedResidual（GR） 4 分支残差流 + 动态读写门控；Per-Layer Embedding（PLE） 从 hashed token n-grams 与 dilated depthwise convolution 提取层特定词法特征。Qwen3.8-Flash-Next 规格：125B MoE backbone + 6B active/token + 51B n-gram + 4B MTP ≈ 180B total；Qwen4 尚未发布。⚠ QSA 是 Qwen4 架构预览，实测数字来自预发布架构。

Orthros — Phase-Aware Heterogeneous Attention（arXiv:2610.13735，Oct 2026，paper_card 1759）：高效注意力机制（linear / sliding window）通常需 interleaving 全注意力层解决 in-context recall 退化，但 quadratic bottleneck 未真正解除；Orthros 提出 phase-aware decoupling——不再按层类型静态分配计算模式，而按序列处理的 phase（段落/章节/语义单元）动态切换。核心价值：统一模块，无需预定义层类型。⚠ 待核实：TLDR 未给出具体 benchmark 数字，边界条件需读原文确认。

ReFold — 无训练可逆上下文压缩 for SWE Agents（arXiv:2610.07863，Oct 2026，⭐⭐⭐⭐）：无需训练的可逆压缩——压缩后的观察可完全恢复到原始上下文大小，支持需要完整上下文的验证步骤。数据（SWE-bench Verified，Qwen3.6-27B，full window w=8）：ReFold vs base 无质量损失；ReFold vs LLMLingua-2 保留原始方法全部观测，压缩观测体至 50% token。工程价值：直接提升 agent 上下文窗口利用率，可逆性保证验证步骤不丢关键信息。

Mid-Training KD Favors Reasoning（arXiv:2609.01532）：mid-training 做 forward KL 蒸馏仅提升推理，事实记忆几乎不变；pre-training 阶段同时提升推理和事实记忆。

Looped LM — 连续深度批处理（arXiv:2608.09444）：Looped LM 通过将一组共享层循环可变次数实现深度自适应推理。CDB（Continuous Depth Batching）——首个实现循环语言模型高效深度自适应批处理的方法。

QATFactory — 量化感知训练+蒸馏+NVFP4/MXFP4 部署对齐（arXiv:2609.39223，NVIDIA Labs，Oct 2026）：训练时量化与推理引擎行为不一致导致精度损失——vLLM 与 SGLang 的 fused kernel 行为不同，QAT 与部署存在语义鸿沟；QATFactory 每层可配置目标推理引擎（vLLM / SGLang / llama.cpp），支持 NVFP4、MXFP4、Q4_K；关键数据：Qwen3.5-9B NVFP4 checkpoint 精度接近 BF16 基线（BigCodeBench / LiveCodeBench）。

从零构建推理模型：全流程视频课程（Sebastian Raschka / Ahead of AI，2026-10 RSS）：11+ 小时代码视频，覆盖评测、inference-time scaling、强化学习与蒸馏（Python + PyTorch）。https://magazine.sebastianraschka.com/p/building-reasoning-models（RSS：https://magazine.sebastianraschka.com/feed）。⚠ 属课程/资源条目，无新 SOTA 数据与可比基准，只作方法论与内训入口。

低比特 n-gram 嵌入表量化（arXiv:2610.31646）：4-bit 量化 n-gram 表可省约 75% 表内存并保留 >99% 的 loss 改善；在 DeepSeek-V4.1-Flash 与 Qwen3.8-Flash-Next 上省 47–55% 内存、困惑度增幅 <1.2%。推理侧意义：n-gram 表是权重之外的常驻显存项（Qwen3.8-Flash-Next 的 51B n-gram 见 QSA 规格），4-bit 是独立于 KV cache 量化与词表特化的第三条内存杠杆；可迁移结论是"比特再少就明显掉点，短微调能回收大部分损失"。⚠ 摘要级转述，无仓库地址、量化库版本、消融表与置信区间；数字属"方向可信、量级待验"，不可直接作显存预算依据。

4.3 硬件故障与 Agent 可靠性

Hardware Faults in LLM Agents（arXiv:2610.12756，Oct 2026，MLforSystems + AI4Good Workshop）：传统 LLM 推理故障研究以模型输出为终点，本文延伸至完整 agent 执行轨迹；对比受信任硬件基准与注入故障后的 agent 行为差异，区分推理密集型与 agent 决策型任务。工程价值：对部署 agent 到边缘/GPU 集群的可靠性工程师有直接参考价值，chaos engineering 方法论可迁移到 agent 系统测试。

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 容量约束建模。

Agent Mosaic — agentic LLM 系统的机密性泄露识别（arXiv:2610.30418）：agent 从多份各自可访问的文档取回信息后拼接输出"马赛克式"敏感结论——单看任一文档都不越界，合起来却泄漏受管制结论。 - 实验规模：30 个合成场景（网络安全 / 医疗 / 军事），3 个 LLM agent 受控模拟下 10,800 条最终回答 + 两个开源 harness 中 live agent 的 1,440 条回答。 - 关键数据：在刻意设计为"单文档可答"的良性查询下，表现最好的 GPT-5.6-Sol 仍有 7.08% 的回答泄漏被禁止的复合结论（95% CI 3.75–10.67%）。 - 两条反向证据：可见分类标签与显式聚合规则确实能缓解泄漏但残余失败率仍不低；"拒答"本身也会暴露被禁止的结论，拒答率不能替代"是否泄漏推导结论"的度量——与 §2.5 共享 backend 侧信道属同一类评测口径问题。 - 推理侧含义：风险在检索-聚合链路而非模型"嘴严"，权限设计需按 clearance 做复合结论级过滤，而非逐文档授权。 - ⚠ 合成数据仅 30 例，外部效度有限；结论限定于"被评测设置中"。 - 同题延伸（本轮未核查正文）：https://www.trydeepteam.com/guides/guide-red-teaming-agentic-rag 的 ContextFlooding 类攻击；https://www.redfoxsec.com/blog/rag-pipeline-attack-scenarios-context-manipulation-and-data-leakage-explained 的间接提示注入与文档投毒路径。均为公开工程材料、非同行评审，仅作延伸线索。

五、成本工程与 llm-d CNCF K8s 编排

5.1 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。

ModelSphere — 生产级 LLM 推理基础设施（modelsphere，Apache-2.0，Oct 2026）：开源栈覆盖部署到调优全生命周期，Ansible + helmfile 离线部署，Helm charts 支持 sglang / vllm。核心组件：llm-operator——K8s HPA 基于 KV-cache 利用率、队列深度、TPM 做 LLM 专用扩缩容，首个把 KV-cache 指标直接引入 K8s autoscaling 决策的生产级 operator；cache_aware_router——路由至持有最长匹配 prompt 前缀的副本；continuation_gateway——流式生成中断或掉线时恢复；llm-autotune(-policies)——在闲置 GPU 上搜索 serving 配置；llm-bench + hang-watcher。工程价值：首次把 KV-cache aware 路由、SLO 感知调度、continuation gateway 整合为统一开源堆栈，与 llm-d 的 CNCF 路线互补。⚠ 各 repo 代码质量与生产案例未逐一验证。

NVIDIA Grove —— K8s 原生推理编排三层 CRD（NVIDIA Developer Blog 2026-09）：L1 PodClique 单角色副本组（prefill/decode/vision encoder 等）；L2 PodCliqueScalingGroups 多级弹性伸缩（同一角色的多副本集）；L3 PodCliqueSet 多组件系统描述（将 L1/L2 组合为完整系统）。

2026 Production Architecture Stack（Ken Huang Substack 10 章系列，2026）：Disaggregated P/D Nodes（prefill 与 decode 节点分离、独立扩缩容）；Global Prefix Caching Clusters（跨 region 前缀缓存）；API Gateways + Semantic Routers（语义层路由，支持模型路由与会话保持）；Edge SLM Deployment（DeepSeek-V4-Pro-Distill-Qwen 1.5B/7B/14B、LLaMA-3.2、SmolLM2、Phi-4 边缘部署）；NSA（Native Sparse Attention）（DeepSeek-V4 原生稀疏注意力，与 block-sparse attention + LongLoRA 共同构成 2026 长上下文扩展技术栈）。

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），推理成本持续下降。

Agent 三层内存架构成本模型（GMI Cloud 2026-10-04，生产决策核心）：

层级 存储介质 成本模型 关键洞察
Working Memory context window 本身 每 token 每次 forward pass 付成本 提取与合并的 LLM 调用成本是存储成本的 10-100 倍
Session Memory per-thread 状态 跨 turn 存活 最有效的成本决策：session 边界批量合并
Long-term Memory 跨会话知识 唯一真正困难的层 三大难点都是写入策略问题，非检索问题

5.3 部署框架与模型卡片

Tencent Hy3-FP8（295B MoE，HF 2026-10）：295B 总参 / 21B 激活 / 3.8B MTP / 80 层 / 256K context / 256 experts top-8，BF16；FP8 量化版，vLLM 与 SGLang 均适配。vLLM 部署：--speculative-config.method mtp --speculative-config.num_speculative_tokens 2；SGLang 类似 MTP 配置并含 tool-call-parser / reasoning-parser。盲评：270 位专家，Hy3 得分 2.67/4 vs GLM-5.1 的 2.51/4。⚠ MTP 加速比未披露、FP8 精度损失缺失。

HuatuoGPT-3-8B（FreedomIntelligence，HF 2026-10）： - 定位：医疗 LLM，基于 Qwen3-8B-Base + SeedRL 训练 - 部署：与 Qwen3-8B 用法相同，vLLM / SGLang 均支持 OpenAI 兼容接口 - ⚠ 证据缺口：对比 Qwen3-8B 的医疗任务分数未附；部署命令参数未展示

Nanbeige4.3-33B 本地部署（MindStudio 博客，已核查前段与 SGLang 命令）：三条路径——Transformers 需 trust_remote_code=True、use_fast=False；SGLang 用 --tp-size 4 --mem-fraction-static 0.8 --reasoning-parser qwen3 --tool-call-parser qwen3_coder；vLLM 走高吞吐生产。chat template 提供 enable_thinking / preserve_thinking / tools 三个开关，推荐 XML 工具调用格式。参数建议：agentic 与工具调用 temperature 1.0、上限 65536 new tokens；推理与对话 temperature 0.6、上限 262144。模型定位为蒸馏用 teacher（计划中的 3B 版本），512K 上下文；SWE-Bench Pro 与 GDPval 上落后。⚠ vLLM 段命令未取到；benchmark 结论源自模型卡片自述，未独立复现。

DeepSeek-V4.1-Flash 推理参考实现（HF 仓库 inference/，Oct 2026）：最小化可读参考实现（#minimal-inference），非生产级 serving engine；覆盖视觉编码器 + aligner、sliding-window + compressed sparse attention 双级索引器、engram n-gram 查找、MoE、Hyper-Connections、DSpark 前向路径；标准自回归采样，支持 torchrun 多节点；--expert-dtype fp4 转换脚本支持每 rank 独立 checkpoint。⚠ 定位为参考学习，与 vLLM / SGLang 生产级 serving 能力有本质差距。

vLLM Agentic API RFC — 合并 Rust 共享前端（GitHub vllm-project/agentic-api #362，Oct 2026）：移除 Agentic API 部署模式下多余 HTTP 前缀层，直接复用 vLLM 共享前端库（Rust 栈）；被阻塞于 Issue #361，关联 #359 / #314 / #73。工程意义：消除不必要 HTTP 层开销、简化 Agentic 部署架构。⚠ RFC 状态：方向明确，实现细节与生产落地时间未知。

Inferact — vLLM 团队企业扩张（A16zjobs Substack，Oct 2026）：vLLM 团队成员创立 Inferact 获大额种子轮（A16zJobs 2026-10 职位发布），招聘 Kernel Engineering、TPU Performance、Developer Relations（年薪 $400K+）。工程意义：vLLM 核心团队向企业级 inference 扩展的信号，说明推理优化正深入硬件层。⚠ 融资细节与产品形态未披露。

llm-d v1.0（2026-10，llm-d.ai 官方博客，已核查）：llm-d 首个正式大版本，确立分布式推理编排层 "Day 2" 基线。硬件覆盖 AMD MI355X（AINIC）、TPU（TorchTPU）、NVIDIA Hopper / Blackwell / GB200 / GB300 部署指南；能力面含前缀缓存路由、KEDA 自动扩缩容、MoRI-IO / NIXL / TPU Sync 支撑的 prefill-decode 分离与分级 KV offload。自述指标：TPU 7x 上 agentic coding 负载 TTFT 中位数下降 >85%、总吞吐 2.4x。⚠ 均为厂商自述基准，非独立复现；GPU 侧数字未列。生态：500+ 贡献者、25+ 组织；2026-03-24 加入 CNCF Sandbox。

TorchTPU 原生后端（Google Developers Blog，2026-10-20，Qi Zhou / Chris Chan）：宣布 vLLM（与 Inferact 合作）与 SGLang（与 RadixArk 合作）的 TorchTPU 后端，并引用 Meta 的 SGLang-TorchTPU 大规模生产部署声明。⚠ 网页截断，集成细节与生产案例数据未获取。

ModelExpress —— 权重重分发进入一等公民（ai-dynamo/modelexpress DEPLOYMENT.md）：经 NVIDIA NIXL over RDMA 做 GPU-to-GPU 权重传输；vLLM 0.23.0+ 原生支持 --load-format modelexpress；SGLang 侧为 remote_instance + modelexpress 后端配置。脉络定位：§1.2 vLLM Fast Start、§3.2 Dynamo 1.0 GA "ModelExpress checkpoint 恢复 up to 7×" 与本条构成同一脉络的三个数据点——权重分发从引擎内部细节升格为编排层一等职责。⚠ vLLM 0.23.0 与 NIXL 集成稳定性、ModelExpress 与 dynamo 的组织关系未核实。

dynamo（ai-dynamo/dynamo）：数据中心级分布式推理 serving 框架，作为准入层编排支持 vLLM / SGLang / TensorRT-LLM 多后端。⚠ 命名混淆：此处 dynamo 与 §3.2 NVIDIA Dynamo 1.0 GA 同名，公开资料未澄清二者关系；与 llm-d / Ray Serve 分工边界不明。

5.4 集群侧部署与编排增量（2026-10-25 ~ 10-27 fresh）

KServe v0.17/v0.18 LLMInferenceService（RecsysFrontier 日报，已核查原文但属二手汇编）：一个 CRD 生成 Deployment / Service / Gateway / HTTPRoute / InferencePool，路由按队列深度与 KV-cache 状态打分选择副本。工程意义：把"队列深度 + KV 状态"从各家自研 router 逻辑下沉为 K8s 原生 CRD，与 §5.1 ModelSphere 的 cache_aware_router / llm-operator 属同一收敛方向。⚠ 日报作者明确未在 GPU 集群实机验证，且为二手转述，不宜作权威对比。

OME（Open Model Engine）—— 多运行时控制面（搜索线索 · 待核查）：摘要显示把 GPU bin-packing 调度、SGLang/vLLM/TensorRT-LLM/Triton 多运行时接入、自动运行时选型、prefill-decode 分离、灰度发布以及 InferenceReplica/TrafficMap 控制面抽象放在一起。⚠ 仅搜索摘要、未取正文，实现与生产可用性未知，不作选型依据。

Dynamo aisimulate —— Slurm 部署生成器（ai-dynamo/aisimulate 文档，已核查原文）：--deployment-target slurm 生成带 Pyxis/Enroot 的自包含 Dynamo bundle，支持 vLLM / SGLang / TRT-LLM 的聚合与 P/D 分离模式，含单节点多副本；所有 worker GPU 总数须落在 NodeConfig.num_gpus_per_node 内，多机 worker、专用 encode 池、Dynamo Planner 会被直接拒绝而非静默改拓扑（设计取向：拓扑错误早失败）。校验器读取后端参数 schema（vLLM EngineArgs、SGLang ServerArgs、TRT-LLM TorchLlmArgs），但不校验 llm-d Helm 值、GPU 容量、端点就绪与性能；TRT-LLM 需把 engine YAML 放到脚本 /workspace/engine_configs/。⚠ 文档声明测试覆盖产物快照与 shell 语法、CPU supervisor 用真实 HTTP 探测，本次未执行命令；集群实跑结果未核。

llm-d 定位补充（GitHub llm-d/llm-d，已核查摘要）：定位在 vLLM / SGLang 之上的生产级推理编排层，主打跨模型服务器的调度与扩缩容，强调把"模型服务"与"流量治理"分离——与 §5.1 llm-d v1.0 路线连续。

Reflection AI Beam 部署侧拆解（RecsysFrontier 日报，二手汇编）：Beam 为 501B 总参 / 23B 激活 / 1M 有效上下文 / Apache 2.0；部署路径有 SageMaker JumpStart 与 HyperPod Inference 两条；文章重点在总参与激活参如何分别决定 checkpoint 存储、显存分片与单 token 算力，并给出 H100/H200/B200 选型与并发-延迟规划。⚠ 二手转述，未实机验证。

Apple RSI-Inference Bench（RecsysFrontier 日报，二手汇编）：10 万美元 API token、5 万 GPU 小时，最佳 agent pass@1 仅 26.7%——把"agent 能否改进推理系统"变成独立评测品类。⚠ 二手汇编，评测口径与复现条件未核实。

5.5 推理成本新杠杆：词表特化与权重可移植性

词表特化降低推理成本 77%（HF Blog · Dharma AI vocabx）：对 SLM 做词表专精化，可在真实应用中把推理成本降低 77%。推理侧意义：把成本杠杆从"量化 / 批调度 / 硬件"扩展到词表与分词层。⚠ 厂商自述，模型规模、序列长度、硬件与成本口径未披露。

Qwen3.8-Max 把"模型选择"与"推理承载方选择"解耦（cioinsights，已核查）：2.4T 稀疏 MoE、推理激活约 95B、多模态输入、1M token 上下文；云上定价 $2/M 输入 token、$6/M 输出 token；同一权重可由不同运营方托管，模型可移植性成为采购问题。⚠ 权重开放条款在付费墙后未取得；未核实是否已有第三方托管同权重。

5.6 端侧与机密推理

Kapitsa 热度跃升（nace-ai/kapitsa，repo card 2026-10-22）：Apache-2.0、C++、209 ⭐ / 周增 +378、最近提交 2026-10-21；专为 Qwen 与 Nemotron 优化的 Apple Silicon 推理引擎，OpenAI + Anthropic API 兼容。 - 相比上一轮 105 ⭐，周增 +378 说明关注度快速上升，但成熟度仍为 experimental。

机密 GPU 推理云（Lore-Hex/token-exchange-neocloud-in-a-box，2026-10-22 首次采集）：开源"box 里的机密 GPU 推理云"，Intel TDX + NVIDIA 机密计算节点，面向 DeepSeek-V4.1-Flash 与 GLM-5.3，可验证并上架 TrustedRouter；Python，Apache-2.0，52 ⭐，experimental。与 §2.5 对照：Shadow in the Cache（arXiv:2508.09442）指出 KV 在显存中明文存储，机密计算是硬件级隔离路线；但与跨节点 prefix cache 复用的兼容性未说明。⚠ 无生产案例与性能数据。

5.8 边缘与专用加速器线索

本批 HF Blog 另含两条推理侧相关但正文未核查（仅标题级）的条目，留档待查： - Profiling TorchNeuron (Part 1)（https://huggingface.co/blog/amazon/profiling-torchneuron-part-1）：Trainium 上 Neuron 编译栈的系统级 profiling，对应"推理成本工程在专用加速器上的可观测性"缺口；⚠ 无正文、无指标与版本，不作性能结论。 - Granite Speech 5.0（https://huggingface.co/blog/ibm-granite/granite-speech-5）：ASR/翻译模型更准更快声明；⚠ 无正文、无延迟吞吐口径，作为 ASR 推理栈跟踪线索保留。

SSD 承载 LLM 推理：Expert Pack vs SSD-LLaMA（搜索线索 · 待核查）：MoE 权重外置 NVMe 的连续布局设计，核心论点是碎片读是延迟瓶颈、连续块是带宽瓶颈。⚠ 仅摘要，无命令、无环境、无实测数据，DeepSeek-V4-Flash / Kimi-K3 的消费级硬件可跑性未核。

Blackwell（SM120 / CUDA 13.2）SGLang+vLLM 镜像仓库（local-inference-lab/blackwell-llm-docker，搜索线索 · 待核查）：多版本发布说明，涉及 r29/r33 包改名、压缩 MLA 校验器容量契约（384/512 行取代固定 256）、TP8 自动 owner reduction、TP2/TP4 远端 push 需显式开启、K6 小 M dispatch 的 SM120 能力门控。⚠ 仓库归属与可信度未核、构建脚本未执行、性能结论无实测支撑。

Elastic 可观测性速览（Elastic Observability Labs 栏目页，标题/片段级证据）：Telemetry Policy 主张把遥测策略从"组件启动时固化"改为"运行期可改"，片段称可把运行中 Java 应用的 trace 采样率从 5% 调到 1% 而不重启 JVM；另有 EDOT Android（Gradle 依赖接入移动 APM）、Elastic Agent 9.3（日志/指标/追踪统一 OTel Collector 管线）、9.5（小日志文件身份由已有字节构建、越过 1024 字节阈值后重链接以避免重复摄取）。⚠ 厂商自述、无独立基准、正文未取得；对推理侧的意义仅在"采样/遥测策略运行期可配置"这一方向，不作性能结论。

同批 Kumo Relational 与本文档主题不相关，未纳入正文。

5.7 跨域可迁移方法（推荐系统侧材料，仅取推理侧结论）

SPAR —— 语义 ID 解码树的分支平衡（arXiv:2610.27898）：Prefix-Balanced Semantic IDs；相对最强基线 HitRate 平均 +2.66%、目标前缀保留率 +5.79pp、流量加权最大子分支占比 -32.84%；7 天 A/B 覆盖优酷 10% 流量，人均观看时长 +3.95%、播放转化 +3.38%。⚠ 推理侧可迁移点：树状/分层解码的流量倾斜与分支平衡，与 vLLM/SGLang 批调度的长尾结构同源。⚠ Youku 生产数据不可复现，代码是否开源未说明。

ECHO —— 级联同构算子与蒸馏引导的 100K 序列建模（arXiv:2610.28569）：L=100K 序列长度下，在线序列分支 FLOPs 相对端到端模型降低约 160×；三项部署优化——公共用户输入复用、紧凑记录编码、key 侧投影吸收。⚠ 推理侧可迁移点："离线重、在线轻"的 FLOPs 分工与 §4.2 蒸馏部署、§3.2 PD 分离的算力分层一致；"公共输入复用"与本档 KV prefix 复用同源。⚠ GAUC 数值与基线型号未给。

AutoSim —— 模拟器可信度必须先被量化（arXiv:2610.28054）：TREC iKAT 三年数据上与 NIST 排序一致（Kendall's τ = 0.66 / 0.91 / 0.91，p≤0.002）；真实-模拟判别器量化 prompt 式模拟器偏差——判别 AUC 无法降到 0.85 以下，微调权重可降到 0.45；prompt 模拟器 nDCG 高估 +0.136，57% 轮次返回真实用户找不到的相关段落，足以翻转上线决策。⚠ 推理侧可迁移点：任何"用代理流量/模拟器替代真实请求做上线决策"的做法，须先量化代理与真实的偏差上限。⚠ 评测对象是检索式对话搜索，与 LLM 推理不直接对应。

本批已丢弃来源（留档）：Multimodal Reranking Is a System One Decision（arXiv:2610.28435）正文只到主张层面，无重排指标、数据集、基线对照与模型发布；KLS 猜想为纯数学结论，无实现与性能接口——均不满足可核查门槛。

本批跨主题材料（留档，不入正文论点）：Jay 2026-10-27 工程简报/筛选中的推荐系统跨空间蒸馏（arXiv:2610.32943，IDM/CMM 两目标，Recall@10 +15.39%、NDCG@10 +8.28%）、LLM 批量抽取 legacy 预临床报告（arXiv:2610.32616，仅方法描述无量化与源码）、Agentic Memory Management 研究议程（arXiv:2610.32464，观点框架无实现）、Thinking/Spelling 分离的高效生成式推荐（arXiv:2610.32980，excerpt 截断、缺速度与开销口径）、UAE GovTrust 双语检索作用域过滤（arXiv:2610.32608，未核查）——均属推荐/检索/对齐主题，推理侧仅留接口线索，不展开。

Real NVP（arXiv:1605.08803，paper card 级证据）：可逆非体积保持变换的无监督密度估计模型，提供精确对数似然、精确采样与精确后验推断。⚠ 与本档推理侧主题（serving / 量化 / 调度 / KV cache / 成本）无直接接口，仅作生成模型基础工作留档；其被引变化不作为本轮新观点。

Real NVP（arXiv:1605.08803，paper card 级证据）：可逆非体积保持变换的无监督密度估计模型，提供精确对数似然、精确采样与精确后验推断。⚠ 与本档推理侧主题（serving / 量化 / 调度 / KV cache / 成本）无直接接口，仅作生成模型基础工作留档；其被引变化不作为本轮新观点。

六、开放问题与趋势

6.1 开放问题

  1. Orthrus FP32 速度数据（⚠ P0）：BF16 下仅 45% 轨迹匹配、FP32 恢复 100%，FP32 下加速比是否崩溃仍未披露；代码与 prompt 集未公开
  2. vLLM Tiered KV Offloading 调度策略：三层调度触发条件（LRU / token 重要性 / 前缀共享率）未公开
  3. QSA 7.6×/4.9× 数字测试条件：QSA 为 Qwen4 预发布架构，batch size、硬件、workload 需读原文确认
  4. Surfing the Activation Wave 可计算性：双标准可能存在组合爆炸，需原文精读确认
  5. ReFold 50% token 减少的具体数字：SWE-bench Verified 完整指标（pass@8 等）是否随压缩一并报告
  6. HijackKV 攻击实用性门槛：多租户隔离下是否存在可操作的跨请求信息泄露路径
  7. vLLM Production Stack 2026 GA P0 落地时间：KV-cache-aware autoscaling 与 KEDA 集成 Q4 目标是否如期
  8. KVTC 20× 压缩比场景条件：平均 vs 最优压缩比、重建质量（perplexity 损失）待核实
  9. Inference backend 16pp 偏差分布：最极端还是平均？涉及哪些模型与 benchmark？
  10. NoLiMa 短上下文基线 ablation：需读原文 §4.3 确认以排除分布外干扰
  11. LMCache 15× 吞吐数字来源：来自 LMCache 自身团队，非中立第三方；具体配置需读全文
  12. Context truncation 降低 prefix cache hit ratio 一半：触发条件未量化
  13. Dynamo Session-Aware 背压阈值：未公开，生产配置参考缺失
  14. SGLang v1.2.1 vs v0.5.20 具体 changelog：需核实 release notes
  15. Kapitsa experimental 稳定性：生产可用性边界未确认；生产案例与 P99 延迟缺失
  16. llm-d v1.0 / dynamo / ModelExpress 分工边界：dynamo 与 NVIDIA Dynamo 同名问题无定论
  17. llm-d v1.0 TPU 数字独立性：TTFT -85%、吞吐 2.4x 均厂商自述，GPU 侧数字完全缺失
  18. vLLM 长 prefill 冻结的版本区间与修复状态：无版本号与 PR/issue，无法判断已知行为还是回归
  19. vocabx 77% 成本下降口径：是否含服务端开销、模型规模、序列长度与硬件均未披露
  20. 机密推理与 prefix cache 复用兼容性：TDX / NVIDIA CC 节点上 KV 能否跨节点复用、PD 分离是否受限未说明
  21. EAGLE-4 官方推理代码技术口径：draft 架构、接受率、加速比、是否合入主线全无数据
  22. n-gram 表量化对照口径：4-bit 省 75% 与 47–55% 的差异来源、评测集与解码设置未披露
  23. Agent Mosaic 外部效度：合成 30 场景、7.08% 泄漏率能否外推；"拒答也泄漏"尚无标准度量
  24. MC-SF 常数竞争比的条件假设：覆盖哪些到达/长度分布未交代；Llama2-70B 为模拟而非实机
  25. 论文卡 arXiv:2502.07115 信息污染：卡片混入 HBM/DRAM 分层与 block-wise streaming attention，与调度主题不符
  26. KServe LLMInferenceService 与 OME 生产验证：CRD 路由打分与 bin-packing 控制面均为二手或摘要级证据
  27. DeepInfer 官方口径数字：155 万亿 tokens/天、$38/卡·小时属转述；8 卡 prefill / 64–128 卡 decode 的容量规划依据未给出
  28. Blackwell SM120 容器与 SSD Expert Pack 性能口径：仅摘要级线索，无命令、无环境、无实测

6.2 趋势

  • 第三拐点：瓶颈从 per-inference FLOPS 转向系统级（并发会话、KV-cache 持久化、长上下文跨轮累积、工具调用外部状态）
  • MoE Serving 三件套确立：CascadeEP（异步专家调度）+ Speculating Experts（预测预取）+ CrossPool（冷启动多 LLM）构成 2026Q4 标准优化手段
  • BP-KV 行为保持压缩范式：从「信号保真」到「行为保真」（输出分布 KL 散度），KV cache 压缩方法论完成范式转换
  • EAGLE 3.1 生产标准确立：并发保持能力（1.71× @ conc4 / 1.66× @ conc16）解决高并发收益衰减
  • SSD（Speculative Speculative Decoding）：消除 drafting 与 verification 的顺序依赖，2×/5× 加速
  • KVTC + WUSH-KV + 1-bit KVTC 三层压缩：2026 Q4 KV cache 压缩从单点突破走向体系化（ICLR 2026 批量验证）
  • 推理后端作为静默超参数：arXiv:2605.19537 的 16pp 偏差推动所有 benchmark 报告注明引擎版本
  • SGLang 29% 条件性共识形成：prefix-heavy traffic 领先 ~29%，独立请求差距 1-4%——选型必须有流量模式前提
  • ds4 C 单文件专用引擎崛起：Redis 作者出品的 DeepSeek V4 Flash 专用引擎（21.9K ⭐）开辟"一个模型跑透"路线
  • KV Cache 定位升格：从"优化技巧"到"存储/通信/调度原语"——LMCache / NVIDIA CMX / llm-d / Dynamo 均围绕它构建生态
  • JIL 调度器安全新维度：长度预测调度器攻击面成为多租户 LLM 服务的工程议题
  • SGLang 0.5.20 自限速隐患：静默 cap concurrency 不在 API 层暴露——推动引擎必须公开内部状态
  • NoLiMa 推动长上下评测范式转移：从"字面匹配"到"隐式联想"，声称 128K+ 的商用模型有效长度被高估 4-16×
  • LMCache 跨引擎 KV 共享升格：vLLM 与 SGLang 的 KV cache 互操作性首次有开源方案
  • Dynamo Session-Aware 填补 Agentic Serving 空白：request-level → program-level；KvHint 实现 orchestrator 与引擎的 cache 策略协同
  • Context Truncation 警示进入生产规范：真实数据证明可将 prefix cache hit ratio 降低 50%
  • ICML 2026 复现危机常态化：23% 论文至少一条 claim 被证伪；inference 领域优化 claim 需带"独立验证状态"
  • Dynamo 1.0 GA 确立 disaggregated inference 成熟度：7× @ DeepSeek R1 Blackwell 与 vLLM PD 5K tok/s @ NVL72 共同构成工程化已成熟信号
  • Qwen3.8 系列多引擎 bug 集中爆发：vLLM DFlash2/DSpark 破坏性 bug + SGLang 静默并发 cap + TRT-LLM FP8 启动失败，指向 hybrid architecture 兼容性挑战
  • ModelSphere 填补开源生产基础设施空白：KV-cache aware routing + HPA 基于 KV-cache 指标，与 llm-d CNCF 路线互补
  • vLLM Agentic API RFC 指向 Rust 前端统一：移除 HTTP 前缀层 + 复用共享前端，落地后简化 Agentic 部署
  • 编排层四层分工定型：llm-d（K8s/CNCF）+ dynamo（准入与多后端）+ ModelExpress（NIXL 权重分发）+ 引擎
  • 硬件后端从 CUDA 一枝走向多后端并行：TPU（TorchTPU）、AMD（AINIC / MoRI-IO）与 NVIDIA 并列进入官方部署指南
  • 权重重分发升格为一等公民：--load-format modelexpress + NIXL over RDMA 使模型加载变成编排层能力
  • 长 prefill 阻塞成为 RAG 场景一等调度问题：24K prompt → 1.8-2.4s 冻结，chunked prefill / PD 分离从可选优化变为默认前提
  • 成本下降的新杠杆在词表与结构层：vocabx 77% 与量化、调度、硬件三条路径并列
  • 模型可移植性成为采购条款：多运营方托管同权重 + 机密计算部署，指向"推理资产可迁移"
  • 端侧与本地引擎分化加速：Rapid-MLX（4.0K ⭐，主打工具调用正确性）与 rec、flare 新入场者同批出现
  • 投机解码实现层换代：EAGLE-4 官方推理代码公开，竞争延伸到官方实现与引擎合入节奏
  • 推理栈可复现性下沉为引擎原生能力：DeepInfer 把 batch-invariant inference 与确定性采样列为开箱能力
  • DeepInfer 把 P/D 解耦与宽专家并行推到默认形态：prefill 8 卡机 + decode 64–128 卡超节点、wide EP、DSpark 式投机解码同栈，MoE 服务硬件-拓扑耦合度上升
  • KV 感知路由下沉为 K8s 原生 CRD：KServe LLMInferenceService 以队列深度 + KV-cache 状态打分选副本，与 ModelSphere/llm-d 收敛到同一抽象
  • 调度理论开始给出"不可能性"结论：arXiv:2502.07115 证明任意到达下确定性在线算法无常数竞争比——启发式调度是理论必然而非工程懒惰
  • 集群部署从"手写 manifest"走向生成器：aisimulate 对不合法拓扑直接拒绝而非静默改写，拓扑正确性前移为构建期不变量

七、引用与参考

arXiv:1605.08803 · arXiv:2309.06180 · arXiv:2403.05527 · arXiv:2404.19769 · arXiv:2412.14219 · arXiv:2501.01005 · arXiv:2501.09136 · arXiv:2502.05167 · 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.17715 · 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.15232 · arXiv:2601.20408 · arXiv:2602.05073 · arXiv:2602.06036 · arXiv:2602.09323 · arXiv:2602.14516 · arXiv:2602.21548 · arXiv:2603.04428 · arXiv:2603.09619 · arXiv:2603.10342 · arXiv:2603.13358 · arXiv:2603.15569 · arXiv:2603.16104 · arXiv:2603.19289 · arXiv:2603.20397 · arXiv:2603.21354 · 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.19537 · 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.20295 · 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.09701 · arXiv:2607.13125 · arXiv:2607.16859 · arXiv:2607.17715 · 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.13867 · 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.24797 · arXiv:2609.24972 · arXiv:2609.25053 · arXiv:2609.26333 · arXiv:2609.26550 · arXiv:2609.26777 · arXiv:2609.26796 · 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.38121 · arXiv:2609.39096 · arXiv:2609.39334 · arXiv:2610.00182 · arXiv:2610.00267 · arXiv:2610.00544 · arXiv:2610.00559 · 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.03027 · 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.07219 · arXiv:2610.07863 · arXiv:2610.08077 · arXiv:2610.08463 · arXiv:2610.09684 · arXiv:2610.10845 · arXiv:2610.12756 · arXiv:2610.12939 · arXiv:2610.13348 · arXiv:2610.13735 · arXiv:2610.27898 · arXiv:2610.28054 · arXiv:2610.28435 · arXiv:2610.28569 · arXiv:2610.30418 · arXiv:2610.31646 · arXiv:2610.32464 · arXiv:2610.32608 · arXiv:2610.32616 · arXiv:2610.32943 · arXiv:2610.32980

本次变更

2026-10-27 | Tom

  • Oct27午：DeepInfer开源栈(P/D解耦+宽EP+确定性采样)+aisimulate Slurm部署生成器+KServe LLMInferenceService KV感知路由+OME控制面(待核查)+Nanbeige4.3-33B本地部署+MC-SF不可逼近性负结果；引→546

2026-10-25 | Tom

  • Oct25午：EAGLE-4官方推理代码+Rapid-MLX端侧引擎(自述4×mlx-lm)+rec/flare新引擎信号+n-gram表4-bit量化(省47-55%内存)+Agent Mosaic马赛克泄露(7.08%)；引→532

2026-10-22 | Tom

  • Oct22午：llm-d v1.0编排基线(TTFT-85%/2.4x自述)+TorchTPU后端+ModelExpress NIXL权重分发+vLLM长prefill冻结1.8-2.4s+vocabx成本-77%+机密推理box；引→530