inference · E1 预消化简报(2026-08-03)
执行人： Tom · E1 日间预消化轮(inference 主题) 覆盖时段： 2026-08-02 22:00 → 2026-08-03 22:00（约 24 小时） 基线：
organized/knowledge/inference.md（2026-08-02 更新 · 十节 · 引用→139；基线含 vLLM Model Runner v2 / PD Disaggregation AMD MI300X MORI-IO / Spheron 50K-500K tokens / HF Dharma idle GPU / vLLM Conference 2026-08-24 / LMCache MLSys 30+ / Modular MAX / AMPD / GoodServe / LAAR / Harvest / Token-Operations 四层 / MCP 2.0 等 E1-0802 增量） 检查来源： work-queue.md + inbox/jay/(2026-08-03T1735-jay-evening-briefing-agents-vecdb-inference-aug2026 25KB AIMultiple 29% vLLM/SGLang架构差距★★★/airllm 4GB单卡70B★★★/Netflix Triton+vLLM生产★★★/TencentDB Agent Memory★★/ds4 antirez DeepSeek-V4★★ · 2026-08-03T1450-jay-engineering-filter-round4 15KB MLOps CAIN 2026 continuous batching★★★/MCP工具描述smelly arXiv 2602.14878★★/AdaSpec+SSD+NexusQuant★★★ · 2026-08-03T1050-jay-engineering-filter 17KB vLLM/SGLang/LMDeploy benchmark矩阵★★★/AI Engineer Stack 2026★★★/Cordum 6种Agent故障模式★★/Context Engineering企业多Agent架构★★/Guardrails三法则★★★/AgentCompass arXiv 2607.13705★★/Agent Harness Survey arXiv 2606.20683★★ · 2026-08-03-kv-cache-optimization-survey 38KB KV Cache五大方向综述 arXiv 2603.20397 ★★★(v2重写，移除AI补全命名)★/Fluid-Guided补全作者★ · 2026-08-03-llm-inference-research-briefing 20KB KV Cache综述+Netflix+Fluid-Guided+Workload-Router-Pool★ · 2026-08-03-llm-inference-ai-engineering 18KB Colibri纯C MoE★/pgvector 0.8★★/pgvectorscale★/MCP 2026生态★★★/HF transformers v5.14★★/HF安全事件★★★ · 2026-08-03T1105-jay-daily-briefing · 2026-08-03-datadog-ai-engineering-report · 2026-08-03-acl-2026-system-demos) + inbox/tom/(2026-08-03-0900-hf-daily-2026-08-03 · 2026-08-03T0840-agent-rag-longcontext-radar · 2026-08-03T1440-agent-rag-longcontext-radar · 2026-08-03T2040-agent-rag-longcontext-radar-v2 · 2026-08-03_agents-lite · 2026-08-03-evaluation-e1prep · 2026-08-03-rag-e1prep) + inbox/spark/(2026-08-03-llm-infra-e1prep 邻接：Datadog 容量天花板 + SGLang 3件CVE + airllm + 29%架构差距 + KV Cache综述 + PROTEA/ArcLight) + inbox/flyp/(2026-08-03-risk-e1prep · 2026-08-03-multimodal-e1prep · 2026-08-03-1550-Beyond-pass1-Reliability-Science-Long-Horizon-LLM-Agents-critical-read) + paper_cards/693-700 共8张新卡(693 TFGformer/694 RAG/695 visual generation/696 extraction/697 image editing/698 world model/699 image generation/700 RL post-training；主分类 inference-systems 0 张) 性质： 预消化简报 · 不重写活文档 · 供今晚活文档接力参考
0. 综述判断
本场 inference 主题 24h 窗口增量性质：中密度（6 主线 + 1 重要修正 + 1 警示）。
本场无主分类 inference-systems 新增 paper_card（连续第 4 个零新增日），但工程层提供了 6 条有实质数字和实测数据支撑的增量。最重要的信号是 AIMultiple 实测确认 SGLang vs vLLM 29% 吞吐量差距是架构层面（scheduling overhead）而非 kernel 层面——即使给 vLLM 换上与 SGLang 相同的 FlashInfer kernel，差距仍然存在，这意味着两引擎的架构设计差异是根本性的。airllm 4GB 单卡跑 70B 是内存优化路径的第三条路（不同于 GGUF 量化，layer-wise compression + chunked context processing）。NexusQuant 的 6.1x KV cache 压缩率 + 一行代码替换是今日最具生产直接可用性的增量。SGLang 3 件未修复 CVE（CVE-2026-3059/3060/3989）经 CERT/CC 协调 6 个月未修复，CVSS 9.8 Critical，是本场最重要的警示。KV Cache 综述 v2 重写修正了 v1 的 AI 补全命名错误（含 Flash Attention O(n²) 修正），本场以 small additions 为主，无大幅章节重构必要。
1. 核心增量（6 主线）
增量 1【推理引擎 §1 / 调度 §2.2】SGLang vs vLLM 29% 吞吐量差距是架构层面而非 kernel 层面（AIMultiple 实测★★★ 建议补）
来源： inbox/jay/2026-08-03T1735-jay-evening-briefing-agents-vecdb-inference-aug2026.md §三 + inbox/jay/2026-08-03-llm-inference-ai-engineering.md §一.1 + inbox/jay/2026-08-03T1050-jay-engineering-filter.md 条目1（★★★★★ benchmark 矩阵）
两条来源综合展开：
核心数据（AIMultiple H100 80GB · Llama 3.3 70B FP8）： - SGLang：16,215 tok/s - LMDeploy：16,132 tok/s - vLLM（FlashInfer 优化后）：12,553 tok/s - 差距：29%（架构层面，非 kernel 层面）
关键推论：即使给 vLLM 换上与 SGLang 相同的 FlashInfer kernel，吞吐量仍落后 29%。结论：瓶颈不在数学 kernel，而在引擎内部调度开销（scheduling overhead）。
Spheron H100 Benchmark（Llama 3.3 70B FP8）对照： | 引擎 | TTFT（冷启动） | 吞吐 | 峰值显存 | |------|--------------|------|---------| | vLLM | 中等 | 基线 | 基线 | | SGLang | 最快 | +29% vs vLLM | 略高 | | TensorRT-LLM | 最快（编译 28min） | 最高 | 最低 |
选型决策树（jay 工程筛选原文）：
首次上生产 → vLLM（稳定、文档全）
多轮 Agent 对话、共享前缀 → SGLang（RadixAttention）
量化模型、低配硬件 → LMDeploy
固定模型、不频繁更新 → TensorRT-LLM
与活文档关系：inference.md §1 已收 vLLM 0.26.0 + SGLang v0.6 + TGI EOL；§1 已收 Modular MAX 第五引擎；§2.2 调度已收 AMPD/LAR/GoodServe；但 SGLang vs vLLM 29% 架构层面差距（scheduling overhead 是瓶颈根因，非 kernel）未入位；Spheron benchmark 选型决策树未作为独立节点入位
建议归入：§1 推理引擎（扩展现有 vLLM vs SGLang 小节，新增「AIMultiple 实测：H100 80GB Llama 3.3 70B FP8 SGLang 16,215 tok/s vs vLLM 12,553 tok/s（FlashInfer 优化后），差距 29% 为架构层面（scheduling overhead），即使同 kernel 仍存在 + Spheron benchmark 对照 + 选型决策树」）；§2.2 调度（邻接，scheduling overhead 根因分析）；新增 O187 试金石："本机构常用模型在 vLLM vs SGLang 的 p50/p99 延迟分布；SGLang RadixAttention 在多轮 Agent 对话场景的 prefix overlap 率与吞吐增益相关性"
增量 2【推理优化 §2.5 / 内存优化 §2.3】airllm：4GB 单卡跑 70B（layer-wise compression + chunked context processing ★★★ 建议补）
来源： inbox/jay/2026-08-03T1735-jay-evening-briefing-agents-vecdb-inference-aug2026.md 条目1（GitHub Trending 高价值 1） + inbox/spark/2026-08-03-llm-infra-e1prep.md 增量邻接
核心展开：
- GitHub： lyogavin/airllm（26.7k stars，2026-08-03 +819 stars）
- 核心能力： 70B 参数大模型推理，仅需 4GB GPU 显存（传统 llama.cpp/Ollama 需 40GB+）
- 技术路径：layer-wise memory compression + chunked context processing，无需量化即可压缩内存占用
- 与 GGUF 量化的区别：airllm 走的是压缩推理路径，适合无法改量化权重的商业模型（版权顾虑场景）
- 可信度：高（26k stars 社区验证；原始技术文档需进一步核验压缩比具体数字）
- 来源： https://github.com/lyogavin/airllm
与活文档关系：inference.md §2.5 推理优化已收 Token-Operations 四层 + FlashInfer + P-EAGLE/MeanCache；§2.3 KV cache 已收 Harvest/LMCache/Agent Memory；但 airllm layer-wise compression 第三条路（区别于 GGUF 量化）未入位；4GB 单卡 70B 的内存占用数字（vs llama.cpp 40GB+）是量化记忆优化路径的新锚点
建议归入：§2.5 推理优化（新增「airllm：layer-wise memory compression + chunked context processing 第三条路（非 GGUF 量化）+ 4GB 单卡跑 70B（vs llama.cpp 40GB+）+ 适合无法量化权重的商业模型版权场景 + lyogavin/airllm 26k stars · 2026-08-03」）；新增 O188 试金石："airllm 官方 README 压缩算法细节和模型覆盖列表；本机构商业模型的量化 vs airllm 路径选择评估"
增量 3【KV Cache §2.3 / 推理优化 §2.5】NexusQuant：免训练 KV Cache 压缩 6.1x + 一行代码 drop-in（★★★ 建议补）
来源： inbox/jay/2026-08-03T1450-jay-engineering-filter-round4.md 条目5（★★★★☆ NexusQuant 单项）+ inbox/jay/2026-08-03T1050-jay-engineering-filter.md 条目5（NexusQuant 参考级）
核心展开： - 技术方案：E8 晶格量化 + 注意力感知 token 逐出，免训练 KV Cache 压缩 - 实测数据：6.1x 压缩率，Mistral-7B PPL 仅 +0.276%（几乎无损） - 使用方式：一行代码替换（drop-in one-liner） - 代码状态：已开源（Awesome-LLM-Inference 页面有链接） - 定位：与 KIVI（2-bit 量化）/ KVQuant（FP4/INT4）/ ZipCache（跨层共享压缩）并列的 KV cache 压缩方案；E8 晶格量化是不同于量化的另一技术路线 - 可信度：中高（Awesome-LLM-Inference 跟踪，GitHub 开源，具体压缩比有实测数字）
与活文档关系：inference.md §2.3 KV cache 已收 KIVI/KVQuant/ZipCache（来自 KV Cache 综述 arXiv 2603.20397）；§2.5 已收 NexusQuant 在 speculative decoding 变体上下文中出现；但 NexusQuant E8 晶格量化 + 6.1x 压缩率 + 一行 drop-in 未作为独立节点入位；KIVI/KVQuant 已入位，NexusQuant 作为第三条量化路线（E8 晶格）补齐
建议归入：§2.3 KV cache（扩展 cache compression 小节，新增「NexusQuant：E8 晶格量化 + 注意力感知 token 逐出 + 6.1x 压缩率 + Mistral-7B PPL +0.276% + 一行 drop-in · 免训练 · 开源 · 第三条 KV 压缩路线（区别于 KIVI 2-bit / KVQuant FP4）」）；新增 O189 试金石："NexusQuant 在本机构常用模型（非 Mistral-7B）的实测压缩率；E8 晶格量化与 standard INT4 量化的精度/压缩率对比"
增量 4【推理优化 §2.5】SSD Speculative Decoding：draft 和 verify 并行执行（arXiv 2603.03251 ★★ 建议补）
来源： inbox/jay/2026-08-03T1450-jay-engineering-filter-round4.md 条目5（综合 AdaSpec + SSD + NexusQuant）
核心展开： - arXiv： 2603.03251（2026-05） - 核心创新：SSD = Speculative Speculative Decoding；draft 和 verify 并行执行（而非传统 SD 的顺序执行） - 传统 SD：draft 生成 → verify 顺序等待 - SSD：draft 在独立 GPU 上预计算多个可能的推测，与 verify 并行 - 实测：Llama-3.1-70B TP=4 H100s，batch size=1，greedy decoding，Llama-3.2-1B draft model - 相比传统 SD 吞吐量提升：显著（具体数字需核验原文） - 上下文：与 Lossy Verification（2607.26627，已在 inference.md §3）在"投机解码优化方向"上互补——Lossy 是放松验证严格性，SSD 是并行化 draft/verify 流水线
与活文档关系：inference.md §3 投机解码已收 Lossy Verification（2607.26627）；SSD（2603.03251）的并行 draft/verify 架构与 Lossy Verification 是两条正交的投机解码优化路径，未入位
建议归入：§3 投机解码（新增「SSD Speculative Speculative Decoding arXiv 2603.03251：draft + verify 并行执行（独立 GPU 预计算）+ Llama-3.1-70B TP=4 H100s 实测 + 与 Lossy Verification 正交 · 流水线并行 vs 放松验证严格性」）；新增 O190 试金石："SSD 相比标准 E2E SD 的实际吞吐增益数字；SSD 在 batch size > 1 场景的收益变化"
增量 5【调度 §2.2 / 系统栈 §2.10】Workload-Router-Pool Architecture：LLM 推理静默质量回归检测（arXiv 2603.21354v2 ★★ 建议补）
来源： inbox/jay/2026-08-03-llm-inference-research-briefing.md §backend 高价值条目 + inbox/jay/2026-08-03-llm-inference-ai-engineering.md §backend
核心展开： - arXiv： 2603.21354v2 - 核心创新：提出 LLM 推理架构的第三个维度——silent drift detection（静默质量回归检测） - 通过 per-(model, domain) 统计量时间序列监控，检测提供商侧模型更新引入的质量回归 - 3σ 偏离触发自动流量重平衡 - 真实事故记录：2026 年 3 月，某前沿模型静默退化到中等质量（提供商侧更新未公告） - 相关同期工作：AgServe（会话感知 KV-cache）、Helium（Agent 工作流即查询计划）、Sutradhara（编排器共设计）、Continuum（KV-cache TTL pinning）、Concur（拥塞控制并发） - 与 Datadog 的关系：Datadog 关注的是 rate limit 报错（外部可观测），Workload-Router-Pool 关注的是质量静默退化（外部不可直接观测，需要统计监控）
与活文档关系：inference.md §2.2 调度已收 AMPD/LAR/GoodServe（E2E-SLO goodput）；§2.10 系统栈已收 GH200 NVL2 + SuperInfer；但静默质量回归检测（第三个维度：quality drift）作为独立生产运维维度未入位；与 Datadog rate limit 监控形成"外部可观测"+"内部质量静默退化"的双层监控覆盖
建议归入：§2.2 调度（新增「Workload-Router-Pool：静默质量回归检测 + per-(model, domain) 时间序列统计 + 3σ 触发自动流量重平衡 + 2026-03 真实事故记录 + 与 Datadog rate limit 监控互补（外部报错 vs 内部质量）」）；§2.10 系统栈（邻接，生产运维第三维度：quality drift detection）；新增 O191 试金石："本机构模型调用质量监控方案；是否已有 per-(model, domain) 质量时间序列；提供商模型版本变更通知机制"
增量 6【调度 §2.2】arXiv 2605.01280 Position Paper：LLM Serving 需要数学优化而非仅靠启发式（★★★★★ 建议补）
来源： inbox/jay/2026-08-03-llm-inference-research-briefing.md §backend 高价值条目 + inbox/jay/2026-08-03-llm-inference-ai-engineering.md §backend + paper_cards/025-2605-01280
核心展开： - arXiv： 2605.01280v1 - 标题： LLM Serving 需要数学优化框架，而非启发式方法 - 核心论点：LLM Serving 系统的调度问题需要严格的数学优化框架（在线优化理论），而非单纯依赖工程启发式 - 技术方案：Chen et al. (2026) 开发了在线优化框架，解决 barrier-synchronized、sticky-assignment 设置下的 data-parallel LLM 解码问题 - 理论保证：提供最坏情况保障 Ω(√(B log G)) 因子，优于纯启发式方法 - 定位：与 Fluid-Guided（2504.11320，KV cache 内存约束调度）并列的理论层贡献；与 GoodServe E2E-SLO（2605.16867）启发式 goodput 调度互补（理论 vs 实证）
与活文档关系：inference.md §2.2 调度已收 GoodServe E2E-SLO goodput（2605.16867，启发式实证）；arXiv 2605.01280 的数学优化框架（理论层）未入位；与 Fluid-Guided（2504.11320）一起构成调度层「理论+实证」双层覆盖
建议归入：§2.2 调度（新增「arXiv 2605.01280 Position Paper：LLM Serving 调度需要数学优化框架（非仅启发式）+ barrier-synchronized sticky-assignment + Ω(√(B log G)) 最坏情况保障 + 与 GoodServe（实证 goodput）/Fluid-Guided（内存约束）形成理论/实证双层覆盖」）；新增 O192 试金石："理论框架与 vLLM/SGLang 实际调度器的实现差异；Ω(√(B log G)) 在生产工作负载下的实际调度效果"
2. 重要修正（1 条）
修正 1【KV Cache §2.3 / 注意力机制 §2.4】Flash Attention 复杂度 O(n²) 未改变——IO-aware 优化而非计算复杂度优化（v2 重写核心修正）
来源： inbox/jay/2026-08-03-kv-cache-optimization-survey.md v2 §2.4（v2 核心修正段）
修正内容：
上一期（v1）KV Cache 综述草稿将 Flash Attention 归类为「O(n²) → O(n log n) 优化」——这是错误的。
正确描述： - Flash Attention 仍然是 O(n²) 计算复杂度 - Flash Attention 的优化是 IO-aware exact attention：通过 tile 划分减少 HBM（High Bandwidth Memory）访问次数 - 核心改进：减少 HBM 访问（从 O(n²) 次访问降至更少的 tile 级别访问），而非改变算法渐近复杂度 - Flash Attention 系列（arXiv 2205.14135 / 2307.08691 / 2407.08608）：IO-aware exact attention 的工业实现标杆
v2 移除的 AI 补全命名（原 v1 错误引用）： - ~~"MInference 1.0"~~ → MInference（arXiv 2407.02490）存在，但是 attention 计算优化方向，不是 eviction 方向；v1 类别归属错误 - ~~"Lookback Decoding"~~ → v1 自创命名，未在原文核验 - ~~"InfiniPot"~~ → 论文原文中未出现，疑似 AI 补全 - ~~"LongChain Serving"~~ → 论文原文中未出现，疑似 AI 补全
建议归入：§2.4 注意力机制（修正 Flash Attention 描述：从「O(n²)→O(n log n)」修正为「仍是 O(n²)，但 IO-aware tile 划分减少 HBM 访问次数」）；§2.3 KV cache（邻接，Flash Attention 作用于 KV cache 管理效率）；新增 O193 试金石："本机构生产环境 Flash Attention 版本（v2/v3）与 IO 优化收益对应关系；tile size 配置对 HBM 访问量的实际影响"
3. 值得警惕的矛盾或待核实说法
| # | 矛盾/待核实项 | 来源 | 风险级别 | 建议行动 |
|---|---|---|---|---|
| 1 | airllm 4GB 单卡 70B 压缩算法细节：26k stars 社区验证，但压缩比具体数字、支持的模型列表未经学术 peer review；layer-wise compression 算法是否与 LinguaPull / MiniMax 等有重叠技术路径 | jay evening briefing | 🟡 待核实 | 核验官方 GitHub README 模型覆盖列表和压缩比数据 |
| 2 | SGLang vs vLLM 29% 差距的模型覆盖：AIMultiple 测试基于 Llama 3.3 70B FP8；差距是否在其他模型（8B / 8x22B MoE / 405B）上也成立？ | jay engineering-filter | 🟡 待核实 | 核验 AIMultiple 完整 benchmark 报告；是否有其他模型的对照数据 |
| 3 | NexusQuant E8 晶格量化生产可用性：6.1x 压缩率基于 Mistral-7B；是否在大规模（70B+）模型和长上下文（100K+）场景同样有效？ | jay engineering-filter-round4 | 🟡 待核实 | GitHub 仓库实测；与 vLLM 集成方式确认 |
| 4 | SSD 并行 draft/verify 的硬件要求：SSD 需要「draft 在独立 GPU 上预计算」，是否意味着需要至少 2 GPU 拓扑（draft GPU + verify GPU）？这会限制其在单卡环境的应用 | jay engineering-filter-round4 | 🟡 待核实 | 核验 arXiv:2603.03251 原文硬件配置；单 GPU 备选方案 |
| 5 | SGLang 3 件 CVE 未修复状态：CVE-2026-3059/3060/3989 经 CERT/CC 协调 6 个月未修复；SGLang 2026-08 版本是否已包含任何缓解措施？ | spark llm-infra e1prep | 🔴 高警示 | 核验 SGLang GitHub 最新 release notes；localhost binding + msgpack 缓解是否已默认启用 |
| 6 | Workload-Router-Pool 3σ 检测参数：per-(model, domain) 统计量时间序列 + 3σ 触发阈值——3σ 对 LLM 输出质量是否合适？LLM 输出分布是否近似正态？ | jay inference-research-briefing | 🟡 待核实 | 论文是否讨论了其他阈值选择或自适应阈值方案 |
4. 本次涉及 arXiv 号列表
| arXiv 号 | 论文/主题 | 增量归属 | 建议归位节 |
|---|---|---|---|
| 2607.26627 | Lossy Verification in Speculative Decoding（已在 inference.md §3；E1-0802 基线覆盖） | 基线继承 | §3/§8.2 |
| 2605.16867 | GoodServe E2E-SLO Goodput 调度（已在 inference.md §2.2；E1-0802 基线覆盖） | 基线继承 | §2.2 |
| 2602.14516v2 | AMPD Multi-round Disaggregated Serving（已在 inference.md §2.2；E1-0802 基线覆盖） | 基线继承 | §2.2 |
| 2604.15732v1 | LAAR Long-Context NUMA-Aware Routing（已在 inference.md §2.2；E1-0802 基线覆盖） | 基线继承 | §2.2 |
| 2602.00328v1 | Harvest P2P GPU Cache（已在 inference.md §2.3；E1-0802 基线覆盖） | 基线继承 | §2.3 |
| 2603.04428v1 | Agent Memory Edge Q4 KV Cache（已在 inference.md §2.3；E1-0802 基线覆盖） | 基线继承 | §2.3 |
| 2606.20295v1 | Token-Operations 四层架构（已在 inference.md §2.5；E1-0802 基线覆盖） | 基线继承 | §2.5 |
| 2603.20397 | KV Cache 优化全景综述（已在 inference.md §2.3；v2 重写，修正 Flash Attention O(n²) 修正已覆盖） | 基线继承（修正） | §2.3 |
| 2504.11320 | Fluid-Guided Online Scheduling（已在 inference.md §2.2；作者/发表年已补全） | 基线继承（补全） | §2.2 |
| 2605.01280 | LLM Serving 需要数学优化而非仅靠启发式（Position Paper，Chen et al. MIT/Amazon） | 🆕 增量 6 | §2.2 |
| 2603.03251 | SSD Speculative Speculative Decoding（并行 draft+verify，2026-05） | 🆕 增量 4 | §3 |
| 2603.21354v2 | Workload-Router-Pool：静默质量回归检测（2026） | 🆕 增量 5 | §2.2/§2.10 |
| 2602.14878 | MCP 工具描述效率问题（smelly tool descriptions，ACM 2026-02） | 邻接参考（agent 生态） | §7（邻接） |
5. 本次不纳入的已知条目（已在上期或 E1-0802 基线覆盖）
| 条目 | arXiv 号 | 不纳入原因 |
|---|---|---|
vLLM Model Runner v2（GPU-native Triton kernels + --model-impl transformers） |
HF Blog 2026-07-08 | 已在 E1-0802 基线覆盖；无 8-3 专项新信息 |
| vLLM PD Disaggregation AMD MI300X + MORI-IO | vLLM Korea Meetup 2026 | 已在 E1-0802 基线覆盖 |
| Spheron Context Engineering Guide（50K-500K tokens/请求 + vLLM APC 16-token block） | Spheron Blog 2026-08 | 已在 E1-0802 基线覆盖 |
| HF Dharma AI Blog（idle GPU = P&L 损失） | HF Blog 2026-07-30 | 已在 E1-0802 基线覆盖 |
| vLLM Conference 2026-08-24~26 | GitHub Trending 2026-08 | 已在 E1-0802 基线覆盖 |
| LMCache MLSys 2026 30+ 部署 | MLSys 2026 invited talk | 已在 E1-0802 基线覆盖 |
| Modular MAX 第五引擎 | effloow.com 2026-04 | 已在 E1-0802 基线覆盖 |
| Netflix Triton + vLLM 生产实践 | InfoQ 2026-07-27 | 已在 jay inference-research-briefing 中覆盖；无独立 arXiv |
| KV Cache 五大方向（arXiv 2603.20397） | 2603.20397 | 已在基线；但 Flash Attention 修正（O(n²) 未改变）已在本场修正节覆盖 |
| Colibri 纯 C MoE 推理引擎 | GitHub Trending 2026-08 | 已在 jay evening briefing覆盖；无独立 arXiv；精读后确认模型后补入 §1 |
| pgvector 0.8 + pgvectorscale | Timescale/AWS 2026 | 已在 jay inference-research-briefing 覆盖；主分类 database，非 pure inference-systems |
6. 已检查来源清单
以下来源经本次扫描确认无 inference 主题新增或已在上方增量中覆盖，避免重复检索：
inbox/jay/2026-08-03T1735-jay-evening-briefing-agents-vecdb-inference-aug2026.md→ 主要来源：airllm（增量2）+ AIMultiple 29% vLLM/SGLang（增量1）+ Netflix Triton+vLLM（已知）+ TencentDB Agent Memory（agent 主题）+ ds4 antirez DeepSeek-V4（llama.cpp 生态）+ vLLM vs SGLang vs LMDeploy benchmark矩阵（增量1）+ AI Engineer Stack 2026（agent 主题）+ Substack context engineering（agent 主题）；无 pure inference-systems 学术新增inbox/jay/2026-08-03T1450-jay-engineering-filter-round4.md→ 主要来源：NexusQuant（增量3）+ SSD（增量4）+ AdaSpec（SLO-aware SD）+ AI Engineer Stack 2026（agent）+ MLOps CAIN 2026 continuous batching（邻接 inference）+ MCP tool smelly（邻接）+ On-Premises RAG Blueprint（rag 主题）；NexusQuant + SSD 为 inference 专项新增inbox/jay/2026-08-03T1050-jay-engineering-filter.md→ 主要来源：vLLM/SGLang benchmark矩阵（增量1）+ AI Engineer Stack（agent）+ Cordum 6种Agent故障模式（agent）+ Context Engineering企业多Agent（agent）+ Guardrails三法则（agent）+ AgentCompass arXiv 2607.13705（agent eval）+ Agent Harness Survey arXiv 2606.20683（agent）；无 pure inference-systems 学术新增inbox/jay/2026-08-03-kv-cache-optimization-survey.md→ v2 重写，修正 v1 AI 补全命名错误（Flash Attention O(n²) 修正 + 移除 MInference 1.0/Lookback Decoding/InfiniPot/LongChain Serving）；KV Cache 五大方向综述（已在基线）；Fluid-Guided 补全作者/年份；Flash Attention 修正是本场重要修正项inbox/jay/2026-08-03-llm-inference-research-briefing.md→ KV Cache 综述 + Netflix Triton+vLLM + Fluid-Guided + Workload-Router-Pool（增量5）；无 pure inference-systems 学术新增（综述性质）inbox/jay/2026-08-03-llm-inference-ai-engineering.md→ Colibri + pgvector 0.8 + pgvectorscale + MCP 2026生态 + HF transformers v5.14 + HF安全事件；主分类 llm-infra/database/agent，非 pure inference-systemsinbox/jay/2026-08-03-datadog-ai-engineering-report.md→ Datadog LLM call span 5% → 2% 报错率（已在 spark llm-infra e1prep 覆盖；邻接 inference 生产可靠性数据）inbox/tom/2026-08-03-0900-hf-daily-2026-08-03.md→ HF Daily 8-03 票榜 15 件（全部为 8-02 续立，无 eval 主分类新条目；inference 相关：Σ-Mem 2607.27958 已在 agent/memory 建卡）inbox/tom/2026-08-03T0840/1440/2040-agent-rag-longcontext-radar.md→ Agent/RAG/Long-Context 主题；无 inference 专项新增inbox/tom/2026-08-03_agents-lite.md→ Agent 主题（Σ-Mem/Memory Provenance Laundering/Filesystem-Based Memory）inbox/tom/2026-08-03-evaluation-e1prep.md→ evaluation 主题专项（2条 ACL 2026 Demo + 1条 Datadog 邻接）inbox/tom/2026-08-03-rag-e1prep.md→ RAG 主题专项inbox/spark/2026-08-03-llm-infra-e1prep.md→ llm-infra 主题（Datadog 容量天花板 + SGLang 3件CVE + airllm + 29%架构差距 + KV Cache综述 + PROTEA/ArcLight）；邻接 inference 的 Datadog/airllm/架构差距已在本场覆盖inbox/flyp/2026-08-03-risk-e1prep.md→ risk 主题专项inbox/flyp/2026-08-03-multimodal-e1prep.md→ multimodal 主题专项inbox/flyp/2026-08-03-1550-Beyond-pass1-Reliability-Science-Long-Horizon-LLM-Agents-critical-read.md→ Beyond pass@1 reliability（agent memory scaffold 反方；邻接 agent inference 场景，但主分类 agent，非 pure inference-systems）- paper_cards/693-700 共 8 张新卡 → 主分类 inference-systems 0 张（693 time series/694 rag/695 visual generation/696 extraction/697 image editing/698 world model/699 image generation/700 RL post-training）；连续第 4 个零新增日
7. 本次 E1 预消化结论
增量条数：6 主线 + 1 重要修正 + 1 警示
结论：inference 主题 8-2 22:00 → 8-3 22:00 约 24h 窗口为中密度，主因仍是 paper_cards 主分类 inference-systems 连续第 4 个零新增日，但工程层提供了 6 条有实质数字和实测数据支撑的增量，以及 1 条重要的 Flash Attention 描述修正。本场最重要的信号是 SGLang vs vLLM 29% 吞吐量差距被 AIMultiple 独立实测确认为架构层面（scheduling overhead），而非 kernel 层面——即使同 FlashInfer kernel 也无法消除，这对理解两引擎的本质差异有重要意义。airllm 4GB 单卡 70B 是内存优化第三条路（不同于量化，layer-wise compression），为版权受限场景提供了新选择。NexusQuant 6.1x 压缩率 + 一行 drop-in 是今日最具生产直接可用性的工程增量。SSD 并行 draft/verify 与 Lossy Verification 形成正交的投机解码优化双路径。Workload-Router-Pool 的静默质量回归检测为 LLM 生产运维开辟了第三个维度（quality drift，与 Datadog rate limit 外部可观测互补）。SGLang 3 件 CVE 6 个月未修复是本场最高优先级警示。建议今晚活文档接力以 small additions 为主，Flash Attention 修正作为重要补丁插入 §2.4。
建议今晚活文档接力动作： 1. AIMultiple 29% vLLM/SGLang 架构差距 入 §1 + §2.2（scheduling overhead 根因） 2. airllm 4GB 单卡 70B 入 §2.5（第三条内存优化路） 3. NexusQuant 6.1x + E8 晶格量化 入 §2.3（KIVI/KVQuant/ZipCache 后第三条压缩路线） 4. SSD 2603.03251 入 §3（与 Lossy Verification 并列的正交流水线优化） 5. Workload-Router-Pool 2603.21354v2 入 §2.2 + §2.10（quality drift 检测第三维度） 6. arXiv 2605.01280 数学优化框架 入 §2.2（与 GoodServe/Fluid-Guided 形成理论/实证三层） 7. Flash Attention O(n²) 修正 入 §2.4（重要补丁，修正 v1 错误） 8. SGLang CVE-2026-3059/3060/3989 警示 入 §1.4（已有 13 CVE → 16 CVE） 9. O187-O193 试金石 写入候选池