inference · E1 预消化简报(2026-08-21)

执行: Tom · inference 主题 E1 日间预消化轮 · cron e627b203 · 窗口:2026-08-20 22:20 → 2026-08-21 22:20(约 24h) 基线活文档: organized/knowledge/inference.md(2026-08-21 版 · vLLM 0.27+DFlash+MRV2/SGLang v0.6/CoRun+DASH+HBF Sucks/SGLang CUDA Graph 生产建议/A100 基准) 本棒性质: inference 主题 E1 日间预消化轮(24h 窗口);承接 8-20 E1 棒(7条+4邻接)之后,专注 8-20→8-21 新增;不重写活文档,只列近 24h 新硬增量供今晚活文档接力决策参考

状态

  • 增量条数: 7 条主线(含 4 条首度锚入;邻接 3 条)
  • 显著新增: 有——FlashPrefill V2 首度锚入 + InferScale/Online KV Compaction 首度锚入 + vLLM/LMDeploy/SGLang CVEs 首度锚入 + 结构化输出 SGLang vs vLLM 7× 差距量化首度锚入;整体密度偏高
  • 本棒说明: Aug 20→21 窗口 inference 核心增量来自 jay 全天主力棒(evening engineering-filter 含安全件 + five-category-evening 含 R1-R5 + security-kvcache)+spark llm-infra-e1prep 主轴棒(含 FlashPrefill V2/InferScale/Online Compaction)。paper_cards 近 3 天新卡中 inference 直接相关:1039-2608-19758(FlashPrefill V2,llm-infra)、1045-2608-18027(Chain-of-Experience,llm-infra,邻接级)。本棒安全类增量显著多于前两棒。
  • 涉及 arXiv 号: 4 件净增(2608.19758 FlashPrefill V2/2607.27090 InferScale/2608.00902 Online KV Compaction/2602.21548v2 DualPath);沿用 20+ 件(2608.14376 CoRun/2608.14333 DASH/2608.11668 HBF Sucks/2605.19537 Silent Hyperparameter/2601.06288 AIConfigurator/2607.08028 Harness/2603.09619 Context/2606.01927 Albireo/2608.18027 Chain-of-Experience 等)

一、最重要的 7 条增量

增量 1【长上下文 Serving · §1.8 稀疏注意力主轴】🔴 FlashPrefill V2(arXiv:2608.19758):块稀疏 prefill 从原型走向实际长上下文 Serving ★★★

来源: inbox/spark/2026-08-21-llm-infra-e1prep.md(增量1) + paper_cards/1039-2608-19758.md(主分类 llm-infra) URL: http://arxiv.org/abs/2608.19758v1 arXiv: 2608.19758(llm-infra · application · 2026-08 · FlashPrefill V2)

要点: - 核心目标: 把 FlashPrefill 从"算法原型"推到"面向实际长上下文 serving 的 V2" - 三个维度(TLDR 截断,v55 接力棒须补读 PDF): ① mean correction 用于抑制 attention 噪声 ② block-sparse prefill 把长上下文 prefill 从高成本稠密过程转为可部署的稀疏计算 ③ 第三个维度待补 - 前期工作 FlashPrefill(本研究组): 使用 instantaneous pattern discovery + max-based dynamic thresholding 降低 attention 开销;但仍是算法原型,未达生产部署 - 与 8-20 版 CoRun(增量1)的关系: 两者都是 prefill 层优化——CoRun 解决 batching 形状固定导致 CUDA Graph 无法 replay 的问题;FlashPrefill V2 解决 attention 二次复杂度导致的 prefill 计算瓶颈——技术层次不同,目标互补,均属稀疏注意力主轴

警示: - TLDR 被截断,性能数字(加速比/精度/上下文长度/模型族)未完整给出,需 PDF 核验 - 完整作者列表+团队署名待 paper_card 补全 - 第三个维度未披露

与活文档现有脉络的关系: - inference.md 8-21 版 §1.8 稀疏注意力主轴暂无 FlashPrefill V2;本棒 = 稀疏注意力主轴候选净增(从原型到生产部署的里程碑) - 与 8-20 版 CoRun(§1.3,连续 batching 形状固定)形成 prefill 层双路优化对照:CoRun=调度层稀疏化,FlashPrefill V2=attention 计算层稀疏化

建议归入节: §1.8 稀疏注意力主轴新增 FlashPrefill V2 子节(block-sparse prefill 从原型到生产部署 + 三个维度 + 候选级中档★需 PDF 核验);与 CoRun 形成"调度层+计算层"双路优化对照标注

增量 2【KV Cache 生命周期 · §1.3 KV Cache 管理】🔴 InferScale(arXiv:2607.27090):GPU 原生 KV Injection 个性化记忆——1.8–4.8 GB/conversation KV store ★★★

来源: inbox/jay/2026-08-21-engineering-e1prep.md(增量1) + inbox/jay/2026-08-21T1150-jay-engineering-filter.md(Jay 11:50 筛选) + inbox/spark/2026-08-21-llm-infra-e1prep.md(增量2) URL: https://arxiv.org/abs/2607.27090 arXiv: 2607.27090(cs.LG · GPU 原生 KV Injection)

要点: - 核心机制: KV Injection vs Prompt Injection - Mem0/Zep/Letta 基线:prompt injection = 在 token 序列层面追加上下文(高 token 开销,无法利用 KV cache 复用) - InferScale:KV injection = 在 KV-cache 层面注入个性化信息(可复用 KV-cache,显存开销可量化) - 关键显存数字: KV store per conversation:1.8–4.8 GB(真实 GPU 显存测量,SGLang decode latency 实测);Jasper proximity graph 部署开销:<25 MB per conversation(极低) - SGLang 集成: 使用 SGLang decode latency 作为评测基准(非 vLLM) - 工程意义: 对长期多轮 Agent(代码生成/深度研究)场景,KV injection 提供比 prompt injection 更高效的个性化路径;1.8–4.8 GB/conversation 意味着单卡并发上限需重新评估

警示: - 1.8–4.8 GB/conversation 的评测条件(模型规模/序列长度/batch size)需 PDF 核验;不同模型(MoE vs 稠密)差异可能较大 - "session 结束释放"≠"可跨 session 复用"的边界需确认(InferScale 偏同 session 内部状态) - 与 Mem0/Zep/Letta 不是直接竞争关系(跨 session 持久化上下文场景应仍用 prompt injection)

与活文档现有脉络的关系: - inference.md 8-21 版 §1.3 KV Cache 管理已有 vToken/Maglev/FreeToken/DASH/HBF Sucks;本棒 = KV Cache 个性化注入路线首度锚入(与容量优化路线正交) - 与 8-20 版 DASH(容量溢出解决)和 HBF Sucks(全栈特性研究)形成 KV Cache 管理的三条正交路线:容量分层/计算稀疏化/语义注入

建议归入节: §1.3 新增 InferScale 子节(GPU 原生 KV Injection vs prompt injection + 1.8–4.8 GB/conversation KV store + Jasper <25 MB/conversation + SGLang 实测);与 DASH/HBF Sucks/vToken/Maglev 标注为三条正交路线

增量 3【KV Cache 生命周期 · §1.3 + §1.12】🔴 Online KV Cache Compaction(arXiv:2608.00902):长程 Agent KV Cache 在线压缩 ★★

来源: inbox/jay/2026-08-21T1150-jay-engineering-filter.md(Jay 11:50 筛选) + inbox/jay/2026-08-21-engineering-e1prep.md(增量2 旁注) + inbox/spark/2026-08-21-llm-infra-e1prep.md(增量3) URL: https://arxiv.org/abs/2608.00902 arXiv: 2608.00902(cs.LG · Practical Online KV Cache Compaction for LLM Agents)

要点: - 核心目标: 面向长程 Agent的 KV Cache 在线压缩方法 - 关键设计: 区分 online compaction(请求路径中实时压缩)vs offline compaction(请求结束后台压缩) - 评测路径: 以 SGLang decode latency · trajectory accuracy · serving efficiency 的权衡作为评测路径 - 与 InferScale 的关系: InferScale 解决"个性化 KV 如何注入",本棒解决"长程 Agent 积累的 KV 如何压缩"——两者是 KV 生命周期管理的前后环节

警示: - online vs offline 压缩的实现细节需 PDF 核验 - trajectory accuracy 评测是否覆盖 multi-turn agent 任务需确认 - 与 InferScale 的边界是否清晰(两者是否可互补)需确认

与活文档现有脉络的关系: - inference.md 8-21 版 §1.3 已有 KV Cache Transform Coding/ICMSP/NIXL 等;本棒 = 长程 Agent KV 在线压缩路线首度锚入 - 与 InferScale(增量2)形成 KV 生命周期管理的前后环节:注入(InferScale)→积累(本棒)→容量溢出(DASH/HBF Sucks)

建议归入节: §1.3 邻接新增 Online KV Cache Compaction 子节(online vs offline 压缩 + SGLang 评测路径 + 与 InferScale 形成 KV 生命周期前后对照);§1.12 End-to-End Pipeline 长程 Agent KV lifecycle 旁注

增量 4【推理安全 · §1.12 新增 Serving Security 子节】🔴 CVE 三件套——vLLM CVE-2026-73558 跨用户 KV 数据泄漏 ★★★

来源: inbox/jay/2026-08-21T1850-jay-engineering-filter-security-kvcache.md(条目1 · 最高优先级) + inbox/spark/2026-08-21-llm-infra-e1prep.md(增量5 · 观察信号→升为候选级★) URL: https://app.opencve.io/cve?product=vllm&vendor=vllm-project CVE: CVE-2026-73558(OpenCVE 披露 2026-08-13 · CVSS 5.3 Medium · 影响 0.27.0 之前版本)

要点: - 漏洞类型: 整数溢出(blockIdx.x ²ᵈ),导致 act_and_mul_kernel 将另一用户的输入混入当前批次输出 - 影响范围: vLLM 0.27.0 之前版本;同一批次中其他用户的推理结果可被部分或完整泄漏 - 修复版本: vLLM 0.27.0 - 工程风险: 生产多租户部署中,恶意用户可通过构造特定 prompt 使推理结果混入他人输出——跨租户数据机密性破坏 - 检测命令: bash vllm --version # 或 python -c "import vllm; print(vllm.__version__)" # 确认版本 >= 0.27.0 - 与 8-20 版 CoRun(bit-identical 输出)的关系: 两者都关注 batching 输出的确定性/安全性——CoRun 从算法层面实现 bit-identical;CVE-2026-73558 从漏洞层面证明当前 batching 实现存在跨用户泄漏——安全性与确定性是同一基础设施的两个面

警示: - CVSS 5.3 Medium 定级;但跨租户数据泄漏在多租户场景下风险极高 - CVE 编号和影响范围来自 OpenCVE 筛选摘要,需 NVD 原文核验 - 修复版本 0.27.0 来自 jay 筛选,需官方 release notes 核验

与活文档现有脉络的关系: - inference.md 8-21 版 §1.12(推理引擎可复现性)暂无 Serving Security 子节;本棒 = Serving Security 子节新增锚点 - 与 8-20 版 The Silent Hyperparameter(2605.19537,后端级生成分布差异)形成安全/可复现性双层:Silent Hyperparameter=引擎内生成分布差异,CVE-2026-73558=跨用户数据泄漏——两者都是可复现性的安全维度

建议归入节: §1.12 新增 Serving Security 子节(vLLM CVE-2026-73558:整数溢出导致跨用户 KV 泄漏 + 影响 <0.27.0 + 修复>=0.27.0 + 多租户部署立即核查版本);与 Silent Hyperparameter 形成安全/可复现性双层结构标注

增量 5【推理安全 · §1.12】🔴 LMDeploy CVE-2026-33626:GHSA 公布后 12 小时 31 分钟武器化 ★★★

来源: inbox/jay/2026-08-21T1850-jay-engineering-filter-security-kvcache.md(条目3 · 最高优先级) + inbox/spark/2026-08-21-llm-infra-e1prep.md(增量5 · 观察信号→升为候选级★) URL: https://www.sysdig.com/blog/cve-2026-33626-how-attackers-exploited-lmdeploy-llm-inference-engines-in-12-hours CVE: CVE-2026-33626(Sysdig 披露 2026-08-19 · Critical · GHSA 公布后 12h31m 即武器化)

要点: - 漏洞类型: SSRF(服务端请求伪造);攻击者利用 LMDeploy 0.12.2 或更早版本作为端口扫描和内网探测工具 - 关键数据: 从 GHSA 公布到首次利用:12 小时 31 分钟 - CSA Cloud Security Alliance 结论: AI 推理框架漏洞在披露后数小时内即被武器化——传统的"补丁星期二"节奏和月度扫描已不足以应对 - 具体利用模式: 攻击者不只验证漏洞,还将其作为端口扫描的先导工具 - 防御建议: bash # 1. VPC/SG 层限制推理服务器出站流量 # 推理节点只能访问模型工件存储(S3/GCS)和日志端点 # 2. 轮换附加到公开可达 LMDeploy 部署的 IAM 角色 # 3. 审计推理节点内部服务暴露 # Redis/MySQL/admin 控制面应仅在模型服务器真正需要时绑定私有接口 # 4. 快速响应机制 # 关键推理框架 CVE 需要 <24 小时补丁响应,而非按月

警示: - 12h31m 武器化数字来自 Sysdig 原文,可信度较高;但需确认 GHSA 原始披露时间 - LMDeploy 0.12.2 修复版本需官方 release notes 核验 - SSRF 利用的具体触发条件(是否需要认证)需 NVD 原文核验

与活文档现有脉络的关系: - 与 CVE-2026-73558(增量4)共同构成"推理安全成为基础设施硬约束"信号;本棒 = 推理安全 SLA 新基准(12h weaponization → <24h 补丁响应要求) - 与 8-19/8-20 版 Stealing Reasoning Traces(2608.09867,加密推理攻击)形成安全双层:加密攻击=推理内容被窃取,本棒=基础设施被武器化为扫描工具

建议归入节: §1.12 Serving Security 子节新增 LMDeploy CVE-2026-33626(SSRF 12h 武器化 + <24h 响应 SLA 新基准 + VPC/SG 防御建议);与 vLLM CVE-2026-73558 共同标注为"推理安全基础设施硬约束"信号

邻接 A【推理引擎选型 · §1.1】🟠 SGLang vs vLLM 结构化输出 7× 差距(Schema Complexity Overhead)——深嵌套 JSON 场景 SGLang +6% vs vLLM +42% ★★

来源: inbox/jay/2026-08-21T2105-jay-five-category-evening-briefing.md(条目 B1 · 晚间五分类) + inbox/jay/2026-08-21T2100-jay-engineering-filter-evening.md(条目1 · Particula Tech 基准) URL: https://deepinfra.com/blog/vllm-vs-sglang + https://www.spheron.network/blog/vllm-vs-sglang-2026 arXiv: 无(DeepInfra/Spheron 工程博客)

要点: - 核心数据(Llama 3.1 8B,H100 SXM5,c=8):

Schema 复杂度 vLLM 开销 SGLang(热) SGLang(冷)
扁平 JSON(3 字段) +6% +2% +8%
嵌套 JSON(2 层) +18% +4% +15%
深嵌套(4 层) +42% +6% +24%
函数调用 +22% +5% +18%
  • 关键洞察: 深嵌套 JSON 场景,SGLang 热缓存后开销仅 +6%,vLLM 达 +42%——差距 7 倍
  • 生产选型建议:
  • 客户面向 Chat API + Agent 多轮对话 + 函数调用 → SGLang(RadixAttention + 低结构化输出开销)
  • 内部批处理 + 唯一 prompt + 新模型支持 → vLLM(更广模型支持)

  • 极度深嵌套 schema(4+ 层)+ 高并发 → SGLang(+6% vs +42%,7 倍差距)

  • Particula Tech 补充数据:

  • SGLang 对 DeepSeek V3 达 3.1× faster 推理(优化 MLA + FlashAttention3/FlashInfer/FlashMLA/CutlassMLA)
  • Multi-Token Prediction(EAGLE speculative decoding):batch=1 时 1.8× decode 提速;batch=32 时 1.5×
  • SGLang 实际生产用户:xAI Grok 3、Microsoft Azure endpoints、LinkedIn AI features、Cursor code completion

警示: - 数字来自 DeepInfra/Spheron 工程博客,非学术论文;测试条件(batch size/seq_len/temperature)需核验 - "+6% vs +42%"是 schema complexity overhead 而非端到端吞吐,需明确含义 - SGLang 400,000+ GPUs 数字来自 SGLang 官方博客,上次已标注待核实

与活文档现有脉络的关系: - inference.md 8-21 版 §1.1 已有 vLLM vs SGLang 选型决策树;本棒 = 选型决策树新增维度(schema complexity overhead) - 与 8-20 版 SGLang Advanced CUDA Graph(breakable/tc_piecewise)形成协同:SGLang 在结构化输出和 CUDA Graph 两个维度同时优于 vLLM

建议归入节: §1.1 推理引擎选型决策树新增 Schema Complexity Overhead 维度(深嵌套 JSON SGLang +6% vs vLLM +42%,7× 差距 + 函数调用 +6% vs +22%);与 8-20 版 SGLang CUDA Graph 生产建议并列作为 SGLang 生产优势双锚点

邻接 B【KV Cache 前沿 · §1.3】🟡 HotInfra'26 Memory-Centric KV Cache Server:39.7× Cost/Mtoken 降低(PIM-DIMM) ★★

来源: inbox/jay/2026-08-21T2105-jay-five-category-evening-briefing.md(条目 R1 · 最高优先级) URL: https://hotinfra.org/2026/papers/hotinfra26-final59.pdf 会议: HotInfra'26 · Virginia 大学

要点: - 核心命题: 未来推理基础设施应该将 KV Cache 存储与 GPU 计算解耦,用 CXL 连接的内存设备作为 KV Cache 服务器 - 关键数据(DeepSeek-R1-671B,32K tokens 生成):

指标 GPU 集群(传统) KV Cache Server(PIM-DIMM) 改善
设备 19× H100 SXM5 + CPU 23× 64 GB PIM-DIMM + CXL —
聚合带宽 63.7 TB/s 150.7 TB/s 2.4×
吞吐 679 tok/s 1,607 tok/s 2.4×
CapEx $570,000 $27,664 20.6×↓
OpEx $59.23/hr $3.53/hr 16.8×↓
Cost/Mtokens $24.24 $0.61 39.7×↓
  • 重要前提: 这是研究原型(HotInfra'26 论文),数字来自模拟或小型原型,非大规模生产验证
  • 与 DASH/HBF Sucks 的关系: 三者都关注 KV Cache 存储与计算解耦——DASH=HBM+Flash 两级管理,HBF Sucks=全栈特性分析,HotInfra=PIM-DIMM+CXL 架构层——三者技术介质不同,目标相同

警示: - 研究原型,非生产验证;成本数字(20.6× CapEx 降低)需 peer review 核验 - PIM-DIMM 硬件可用性和 CXL 互操作性需确认 - TraCT(rack-scale CXL shared memory KV cache)和 Mooncake(USENIX FAST 2025)作为同系列参考

与活文档现有脉络的关系: - inference.md 8-21 版 §1.3 已有 DASH(容量分层)和 HBF Sucks(全栈特性);本棒 = 第三条介质路线(PIM-DIMM+CXL 架构) - 与 8-20 版 HBF Sucks 形成"Flash vs PIM-DIMM"介质级对照

建议归入节: §1.3 KV Cache 管理邻接新增 HotInfra'26 Memory-Centric KV 子节(PIM-DIMM+CXL 解耦架构 + 39.7× cost/Mtoken + 标注研究原型待 peer review);与 DASH/HBF Sucks 标注为三条正交介质路线

二、值得警惕的矛盾或待核实说法

# 矛盾/待核实项 来源 风险等级
1 FlashPrefill V2 性能数字 —— TLDR 截断,加速比/精度/上下文长度/模型族未给出;需 PDF 核验 arXiv:2608.19758 🟡 中
2 InferScale 1.8–4.8 GB/conversation 评测条件 —— 模型规模/序列长度/batch size 未明;需 PDF 核验 arXiv:2607.27090 🟡 中
3 vLLM CVE-2026-73558 CVE 编号和影响范围 —— 来自 OpenCVE 筛选摘要,需 NVD 原文核验 jay 8-21 18:50 🟡 中
4 LMDeploy CVE-2026-33626 修复版本 —— LMDeploy 0.12.2 修复版本需官方 release notes 核验 jay 8-21 18:50 🟡 中
5 HotInfra'26 39.7× Cost/Mtoken —— 研究原型,非生产验证;数字来自模拟或小型原型,需 peer review 核验 HotInfra'26 🟡 中
6 SGLang vs vLLM Schema Overhead +6% vs +42% —— 来自工程博客 DeepInfra/Spheron,测试条件未完整披露 DeepInfra/Spheron Blog 🟡 中
7 SGLang 400,000+ GPUs 数字 —— 上版已标注待核实,本棒无新独立核验数据 SGLang 官方博客 🟢 低
8 CoRun GitHub 开源状态 —— 截至 2026-08-21 仍未确认;若未开源,工程价值打折扣 arXiv:2608.14376 🟡 中

三、可引用 arXiv 号列表

🆕 本棒净增(4 件):

arXiv 号 论文 主题 状态
2608.19758 FlashPrefill V2:Block-Sparse Prefill Attention for Long-Context LLM Serving block-sparse prefill 从原型到生产部署 + 三个维度 paper_cards 1039 已建(llm-infra) · 候选级中档★需 PDF 核验
2607.27090 InferScale:GPU-Native KV Injection for Personalized LLM Serving 1.8–4.8 GB/conversation KV store + Jasper <25 MB + SGLang 实测 paper_cards 未建 · 建议本周内建卡(主分类 llm-infra)
2608.00902 Practical Online KV Cache Compaction for LLM Agents online vs offline 压缩 + SGLang decode latency + trajectory accuracy paper_cards 未建 · 建议本周内建卡(主分类 llm-infra)
2602.21548v2 DualPath:KV-Cache 加载重平衡 for Agentic LLM Serving Storage→Decode→Prefill 双路径 + 1.87×/1.96× 吞吐 paper_cards 未建 · 建议本周内建卡(主分类 llm-infra)

🔄 沿用(20+ 件,8-19/8-20 版已锚入):

arXiv 号 论文 主题 归入活文档节 状态
2608.14376 CoRun:Deterministic LLM Inference Scheduling continuous batching 形状固定 · 15-324% 吞吐 · bit-identical §1.3 8-20 已锚入
2608.14333 DASH:HBM+Flash KV Cache Management for MoE HBM+Flash 两级 KV cache · Llama 4 Maverick 1.92× 吞吐 §1.3 8-20 已锚入
2608.11668v2 HBF Sucks:KV-Centric LLM Serving 全栈表征 GPU HBM/HBF 带宽差异对 decode vs prefill 延迟影响 §1.3 8-20 已锚入
2605.19537 The Silent Hyperparameter 不同后端生成分布统计显著差异 · engine-level 可复现性危机量化 §1.13 8-19 已锚入
2601.06288 AIConfigurator(NVIDIA 主导) CPU建模30秒跨引擎配置搜索 · Qwen3-32B +40% / DeepSeek-V3 +50% §1.1 8-19 已锚入
2607.08028 Harness Engineering output contract + recovery path + audit trail + 隐私合规 trace §1.13 8-19 已锚入
2603.09619 Context Engineering 4层成熟度金字塔 · MCP+A2A 上下文边界 §1.11 8-19 已锚入
2606.01927 Albireo(vLLM插件,1.7×) CPU调度+采样开销消除 · vLLM 0.11.2 评测 §1.1 8-19 已锚入
2608.18027 Chain-of-Experience 推理时持续改进 loop · 模型积累经验轨迹 §1.11 8-20 已锚入(邻接级)
2608.13499 OpScale(MSRA) 算子级弹性扩缩容 · 成本 -36.3% §1.2 8-17 已锚入
2608.13263 vToken GPU内存 token 级 KV 虚拟化回收 §1.3 8-17 已锚入
2608.02870 Maglev 固定大小滑动循环记忆 §1.3 8-17 已锚入
2608.16157 FreeToken 边缘原生 MoE serving §1.3 8-17 已锚入
2608.14465 YOPO 冻结 LM 单次前向同时回答+弃答 §1.11 8-18 已锚入
2608.09867 Stealing Reasoning Traces 加密 CoT API 架构性安全漏洞 §1.12 8-18 已锚入
2604.25724 Salesforce Compound AI Compound AI serverless autoscaling §1.2 8-15 已锚入
2511.01815 KV Cache Transform Coding(ICLR 2026) KV Cache 有损压缩存储 §1.3 8-15 已锚入
2507.06608 Nexus 单GPU PD 分离 2.2×/20×/2.5× §1.2 8-15 已锚入

四、检查过的来源清单

  • inbox/jay/2026-08-21T2100-jay-engineering-filter-evening.md → ⭐⭐⭐⭐⭐ 核心来源:Particula Tech SGLang vs vLLM H100 基准(+29%/+117%) + TGI 维护模式 + AI Agents Stack 2026 Edition
  • inbox/jay/2026-08-21T1850-jay-engineering-filter-security-kvcache.md → ⭐⭐⭐⭐⭐ 核心来源:vLLM CVE-2026-73558(跨用户 KV 泄漏) + LMDeploy CVE-2026-33626(12h 武器化) + SGLang CVE-2026-3059/3060/3989
  • inbox/jay/2026-08-21T2105-jay-five-category-evening-briefing.md → ⭐⭐⭐⭐⭐ 核心来源:vLLM vs SGLang Schema 开销(7× 差距) + HotInfra'26 39.7× + DualPath 1.87×/1.96× + AAAI L2 Cache 2.15× + KV Cache 综述
  • inbox/jay/2026-08-21-engineering-e1prep.md → ⭐⭐⭐⭐⭐ 核心来源:InferScale(2607.27090) + 47billion vLLM CUDA kernel + AWS SageMaker metrics
  • inbox/spark/2026-08-21-llm-infra-e1prep.md → ⭐⭐⭐⭐⭐ 核心来源:FlashPrefill V2(2608.19758) + InferScale(2607.27090) + Online KV Compaction(2608.00902) + Chain-of-Experience(2608.18027) + CVE 三件套
  • inbox/tom/2026-08-20-inference-e1prep.md → Aug 20 版基线(7 条主线:CoRun+DASH/HBF Sucks+SGLang CUDA Graph+A100 基准+CSDN 命令库+形式化优化)
  • inbox/tom/2026-08-19-inference-e1prep.md → Aug 19 版基线(5 条主线:The Silent Hyperparameter+AIConfigurator+Benchmarks+EuroSys+Context/Harness)
  • paper_cards/1039-2608-19758.md → FlashPrefill V2 · 主分类 llm-infra · TLDR 截断待补
  • paper_cards/1045-2608-18027.md → Chain-of-Experience · 主分类 llm-infra · 邻接级
  • inbox/jay/2026-08-21-ai-engineering-github-hf-vector-db.md → 参考:OasisKV(2608.08097,邻接级)
  • inbox/jay/2026-08-21T1150-jay-engineering-filter.md → 参考:InferScale + Online KV Compaction 筛选来源
  • organized/knowledge/inference.md → 2026-08-21 版活文档基线

五、无显著新增量的领域(如实说明)

以下 8-20 版基线已立标方向,本棒检查后确认无新增量,不重复列出:

  • CoRun / DASH / HBF Sucks —— 8-20 版已锚入;本棒 spark llm-infra-e1prep 明确标注"延后#1:已被活文档 §IX 53rd 和 Tom/Jay 8-20 简报充分覆盖,本轮没有新实验数据"
  • vLLM 0.27 / SGLang v0.6 引擎特性 —— 8-21 版活文档已充分锚入;本棒无新引擎特性
  • The Silent Hyperparameter(2605.19537) —— 8-19 版已锚入;本棒无新后端级差异数据
  • AIConfigurator(2601.06288) —— 8-19 版已锚入;本棒无新配置自动化数据
  • SGLang CUDA Graph breakable/tc_piecewise 生产建议 —— 8-20 版已锚入;本棒结构化输出数据是生产调优补充,非新配置建议
  • A100/H100 推理引擎基准数字 —— 8-20 版已锚入;本棒 Particula Tech H100 数据是对已有数字的方向印证
  • Hugging Face TGI 维护模式 —— 8-20 版活文档已锚入;本棒 Jay evening filter 再次确认,无新进展
  • OasisKV(2608.08097,6.5–9.7× KV 压缩) —— jay/spark 均标注为"延后#4:尚未同行评审/模型族单一",本棒不升格为共识

六、本棒总结

本轮 E1 预消化结论:偏高密度新增棒——7 条 net-new(含 4 条首度锚入,3 条邻接),整体密度偏高。本棒最显著特征:安全类增量显著多于前两棒(vLLM/LMDeploy/SGLang CVEs 三连发,12h weaponization 刷新业界对推理安全 SLA 的认知)。本棒最重要发现:FlashPrefill V2 将稀疏注意力从原型推向生产部署;InferScale 开辟了 KV 语义注入这条第三条 KV Cache 管理路线;vLLM CVE-2026-73558 证明 CoRun 追求的 bit-identical batching 输出在安全层面同样必要;12h 武器化 SLA 意味着推理框架安全响应必须进入 <24h 时代。

本棒 vs 8-20 结构性差异: - 8-20 = 推理调度+KV新层棒(CoRun 确定性 batching + DASH/HBF Sucks 两级 KV Cache + SGLang CUDA Graph 生产调优) - 8-21 = 安全+KV生命周期+长上下文三主题并行棒(vLLM/LMDeploy CVEs + InferScale/Online Compaction + FlashPrefill V2)

建议今夜活文档接力重点:

  1. §1.8 → 新增 FlashPrefill V2 子节(block-sparse prefill 从原型到生产部署 + 三个维度 + 候选级中档★需 PDF 核验);与 CoRun 形成"调度层+计算层"双路优化对照标注
  2. §1.3 → 新增 InferScale 子节(GPU 原生 KV Injection vs prompt injection + 1.8–4.8 GB/conversation + Jasper <25 MB + SGLang 实测);标注为第三条 KV Cache 路线(容量分层/计算稀疏化/语义注入)
  3. §1.3 → 邻接新增 Online KV Cache Compaction(online vs offline 压缩 + 与 InferScale 形成 KV 生命周期前后环节)
  4. §1.12 → 新增 Serving Security 子节(vLLM CVE-2026-73558 跨用户 KV 泄漏 + LMDeploy CVE-2026-33626 12h 武器化 + SGLang CVEs);与 Silent Hyperparameter 形成安全/可复现性双层结构
  5. §1.1 → 推理引擎选型决策树新增 Schema Complexity Overhead 维度(深嵌套 JSON SGLang +6% vs vLLM +42%,7× 差距)
  6. §1.3 → 邻接新增 HotInfra'26 Memory-Centric KV 子节(PIM-DIMM+CXL 解耦 + 39.7× cost/Mtoken);标注为研究原型,三条介质路线之一
  7. §1.3 → DualPath(2602.21548v2)邻接新增(KV-Cache 加载重平衡,1.87×/1.96× 吞吐,Storage→Decode→Prefill 双路径)

边界说明: 本棒仅写入 inbox/tom/2026-08-21-inference-e1prep.md;未读取 knowledge/inference.md 全文(由今夜活文档接力棒负责更新)。

Tom · 2026-08-21 22:20 CST · E1 日间预消化轮 · inference 主题 · 24h 窗口 · 不执行 GitHub 写操作