llm-infra · E1 预消化简报(2026-07-26)
作者:spark · 主题:LLM Infrastructure · 类型:E1 日间预消化 覆盖时段:2026-07-25 18:40 → 2026-07-26 18:40(约 24 小时增量) 基线:
organized/knowledge/llm-infra.md(9 天未更新,截至 2026-07-17 05:00 Wave3 §V 7-17 凌晨版:11 维全景 + C1-C35 + D1-D18 + O1-O118 + T1-T24)+work-queue.md(2026-07-26 18:00 自动检测:llm-infra 主题活文档 9 天未更新 · 待建卡 0 · 待富化 62) 覆盖来源:inbox/jay/7-26 当日 6 份主稿(evening-engineering-filter 17:00 · 1735 mcp-spec-agentframeworks-inference-vecdb · csdn-substack-llm-inference-rag-weekly 08:22 · rag-agent-llm-systems-briefing 11:06 · engineering-e1prep-v36 11:23 · csdn-llm-rag-agent 12:21)+inbox/tom/7-26 3 份(rag-e1prep-v45 + agent-rag-longcontext-radar 08:40 + inference-e1prep 7-25 沿用)+inbox/spark/7-26 3 份 RSS 通稿(gradient-flow + chip-huyen + 3blue1brown,无 llm-infra 重大新工程增量)+inbox/stephen/7-26-1245-coordination-check-noon(确认本场接力主题 = llm-infra 9 天未更新待补救)+paper_cards/近 3 天新卡(IDs 561-597 共 37 张,主分类 llm-infra 0 张;包含 2617.21557 OpenForgeRL agent 主分类 + 2607.04763 ReOPD agent 主分类,均为 OpenAlex 经典回填 1412.6115/2305.06161 等);本场定位「7-25 11 主线大波收尾 → 7-26 中密度补充 6 主线」第五轮抢修。 结论:中密度(6 主线 + 2 旁证 + 2 矛盾点),核心动作 = (1) arXiv:2605.01280 LLM Serving 数学优化立场论文完整展开(Chen et al. 2026 在线调度算法 + Ω(√(B log G)) 改善因子 + LLM Serving 应借鉴 OR 而非启发式);(2) arXiv:2605.11733 Energy-to-Token 全新评估框架(每日 140T token 调用 + ByteDance Doubao 120T/天 + 高质量人类生成数据 2026-2028 窗口期相对稀缺 + 与机器生成 token 泛滥矛盾);(3) arXiv:2606.14589 Fail-Plausible 五类静默失败分类法完整披露(8 周生产数据 + 22 postmortem + 28 manifestation + Class D fail-plausible 取代传统 gray failure + 4,286 测试 + 827 治理检查未能阻止任何新发事故);(4) vLLM K8s 生产 OOM 三陷阱 runbook 实战(GPU 内存公式 + Pod 启动即 OOM + 就绪探测后 OOM + T4 16GB 错觉 + KEDA queue depth 触发 + NCCL --ipc=host 共享内存);(5) Microsoft Agent Framework 1.0(2026-04-03)统一 Semantic Kernel + AutoGen + Alice Labs 框架评分新晋 S 级 + Claude Agent SDK 2026-06 hierarchical subagent = 企业 Agent 框架 2026 H1 重大格局变动;(6) MCP 2026-07-28 RC 核心变更 6 件(移除 Mcp-Session-Id SEP-2567 + Server 发起请求 SEP-2260 + Extensions 独立版本管理 SEP-2133 + Tasks extension SEP-2663 + OIDC Dynamic Client Registration SEP-837 + MCP Apps SEP-1865 sandboxed iframe)= Agent 协议栈生态模块化关键里程碑
一、核心增量(6 主线 + 2 旁证,按活文档归位顺序)
增量 1【推理调度 §2.2】arXiv:2605.01280 LLM Serving 需要数学优化立场论文完整展开(★★ 必补)
- 来源:
inbox/jay/2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md高价值 3 +organized/knowledge/llm-infra.md§2.2 已收一行(arXiv:2605.01280 OR 数学框架 Ω(√(B log G)))
arXiv:2605.01280 立场论文完整展开: - 核心主张:LLM Serving 系统应借鉴运筹学(Operations Research)数学优化方法,而非依赖 trace 驱动的启发式调优 - 数学优化的核心优势:可提供 worst-case 理论保证,不依赖特定 trace 分布或到达频率,启发式方法无法提供此类保障 - Chen et al. (2026) 请求路由 + DP load balancing 算法:在 barrier-synchronized + sticky-assignment 设置下,证明即使请求序列是对抗性的,其算法相对默认策略的 long-run average imbalance 改善因子为 Ω(√(B log G)),其中 B 是 per-worker batch size,G 是 worker 数量 - 与实际系统的差距:理论结果在 batch size 越大、集群规模越大时优势越显著——正是大规模 LLM Serving 的场景 - 方法论含义:当前生产系统大量依赖 P99 trace 调优,但这无法保证 worst-case 表现;数学优化方法正在从学术进入系统实现阶段 - 后续核验:Chen et al. (2026) 完整整数规划 formulation 和证明;vLLM/SGLang 生产调度器是否有类似理论框架落地
- 与活文档关系:§2.2 调度 9 学派已有 OR 数学框架(arXiv:2605.01280)一行,本次首次完整披露「立场论文 + Chen et al. 2026 引用 + Ω(√(B log G)) 改善因子的数学解释 + 与 P99 trace 调优的方法论对比」=「数学优化取代启发式」方法论立标
- 建议归入:§2.2 调度 9 学派 + OR 数学框架(新增「立场论文展开:Chen et al. 2026 + Ω(√(B log G)) 改善因子解释 + 数学优化取代启发式方法论」小节)+ §6.1 核心推理引擎与基准(补充 arXiv:2605.01280 的关键论文 ID 与论文标题);新增 C50 共识候选:"LLM Serving 系统设计应从 P99 trace 启发式调优转向运筹学数学优化框架,理论保证在 batch size 越大、集群规模越大时优势越显著;Chen et al. 2026 在线调度算法 Ω(√(B log G)) 改善因子是首个被 arXiv:2605.01280 完整披露的理论下界";新增 O130 试金石:"vLLM/SGLang 是否在 2026 H2 集成 Chen et al. 2026 类在线调度算法;LLM Serving 数学优化框架是否进入 SIGMOD/OSDI/SOSP 2027 评审主流"
增量 2【推理经济学 §2.11 / 新增节】arXiv:2605.11733 LLM 推理应评估为"能量-Token 产出"全新评估框架(★★ 必补)
- 来源:
inbox/jay/2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md高价值 4 + 全新未入活文档
arXiv:2605.11733 Energy-to-Token 评估框架: - 核心主张:到 2026 年 3 月,每日 token 调用量 ~140T(较 2024 年初增长 ~1000×),仅 ByteDance Doubao 就达 ~120T/天;提出应将 LLM 推理评估为单位能量/token 产出的效率,而非单纯的速度或准确率 - 2026 年 API 价格表(截至 2026-04,美元/M token input/output,表格整理自原文): - 各主流厂商前沿推理模型分层定价 - DeepSeek 使用 cache-miss input 价格,Pro discount 有时限 - 定价差异与 P(t) 天花板约束(区域算力可用性)一致 - 数据稀缺性论点:高质量人类生成文本数据可能在 2026-2028 窗口期相对模型规模变得更加稀缺,与推理能力增长形成矛盾 - 机器生成 token 泛滥 vs 人类策展信息相对稀缺:这对 RAG 系统质量评估有深远影响 - 工程评价:"Energy-to-Token" 评估框架是 2026 年基础设施成本优化的重要方向,对于需要精细化成本核算的 AI Native 企业(每日数十亿 token 调用)具有直接财务意义
- 与活文档关系:§2.11 §V 7-16 fresh 集锦 + §V 沿革条目 + §1 现状全景 11 维均未收录「Energy-to-Token 评估框架 + 140T token 调用量 + Doubao 120T/天 + 高质量人类数据 2026-2028 稀缺」这一经济学视角。活文档目前聚焦"推理跑得更快/更省/更稳"的工程视角,本次是首次完整披露「能量-Token 产出」经济学评估框架。
- 建议归入:§1 现状全景 11 维(在「横切层 11」或新设「经济学评估层 12」补充"Energy-to-Token 评估框架 + 140T token/日 + Doubao 120T/日 + 高质量人类数据 2026-2028 稀缺")+ §2.11 §V 7-16 fresh 集锦(沿用 §V 7-17+8 增补)+ §5 趋势(新增 T25 趋势候选:"LLM 推理评估从速度/准确率转向单位能量/token 产出 + 经济学视角取代纯工程视角")+ §6.7 新增参考文献(补充 arXiv:2605.11733 LLM-Energy-Token-Production);新增 C51 共识候选:"LLM 推理评估维度从速度/准确率转向 Energy-to-Token 产出效率;每日 140T token 调用(2026-03)较 2024 年初增长 ~1000×;ByteDance Doubao 单独贡献 120T/天;高质量人类生成数据 2026-2028 窗口期相对模型规模变得更加稀缺,与机器生成 token 泛滥形成结构性矛盾";新增 D23 争议候选:"Energy-to-Token 评估框架 vs 传统 P99 latency 评估的实证有效性;ByteDance Doubao 120T/天 是 API 调用量还是实际推理 token 量,数据来源需要交叉核验";新增 O131 试金石:"Energy-to-Token 评估是否在 2026 H2 进入 SIGMOD/SOSP/OSDI 评审主流;开源工具能否实测『能量/token』比率;高质量人类生成数据稀缺性何时从论点变为可量化事实"
增量 3【服务层并发安全 §2.5 + §2.6】arXiv:2606.14589 Fail-Plausible 五类静默失败分类法完整披露(★★ 必补)
- 来源:
inbox/jay/2026-07-26-evening-engineering-filter.md高价值 2 +organized/knowledge/llm-infra.md§2.5 仅一行(arXiv:2606.14589 Fail-Plausible)
arXiv:2606.14589 "Silent Failures in Production LLM Agent Systems: A Longitudinal Study"(2026-06)完整展开:
8 周真实生产数据: - 1 个 personal-assistant agent runtime(2026-03 起连续生产) - 约 40 个定时任务、8 个 LLM provider、1 个 tool-governance proxy、1 个 knowledge-base memory plane - 防御:4,286 个单元测试 + 827 个声明式治理检查 - 8 周窗口:22 个完整 postmortem,28 次静默失败 manifestation
五类静默失败分类法(机制导向): | 类别 | 机制 | 关键特征 | |------|------|---------| | A. 环境与平台怪癖 | Environment & platform quirks | 特定环境才能复现,dev 环境无表现 | | B. 设计假设错配 | Design-assumption mismatches | 假设在生产负载下不成立 | | C. 错误吞没与稀释 | Error swallowing and dilution | 错误被捕获但级别不够,未上报告警 | | D. 链式幻觉与伪造 | Fail-plausible chained fabrication | ⭐ LLM 专有;系统不报错误,LLM 将错误转化为流畅合理的叙述内容交付给用户 | | E. 操作遗漏与取证盲点 | Operational omission & forensic blind spots | 错误存在但日志/监控未覆盖 |
Class D 是 LLM 时代特有的 gray failure 升级: - 传统 gray failure:观察者看不见 - Fail-plausible:观察者被失败本身用流畅的谎言说服 - 即:LLM 把错误变成了"看起来完全正常"的输出
防御有效性的实际数据: - 4,286 测试 + 827 声明式检查:未能阻止任何新发事故(ex ante) - 但成功阻止了 87% 的历史事故再次发生(recurring) - 最佳检测器:人类阅读产品输出(非自动化监控) - 最长故障:不在复杂代码中,而在简单正确组件之间的接缝处
"失败作为因果链"复盘方法论:
Postmortem as causal chain
→ Lessons as meta-rules
→ Meta-rules as scanners
→ Guards proven by sabotage
→ Declared state converged by [methods]
- 与活文档关系:§2.5 安全 9 Bug + Token-Flow Firewall + Trajel + Provably-Safe LLM + Software Aging + Grok Build 数据泄露,已收 arXiv:2606.14589 一行但未披露完整五类分类法;§2.6 并行化四大轴线 + AI-first data systems 邻接:End-to-End Pipeline §2.0 (iv) Service Concurrency Safety 已有 GRIEF + 9 CVE + Software Aging + Grok Build 0.2.93 lethal trifecta,但未将 fail-plausible 5 类分类法 + 8 周生产数据作为服务层并发安全的核心经验数据入位
- 建议归入:§2.5 安全(新增「LLM Agent Fail-Plausible 五类分类法(8 周生产数据 + 22 postmortem + 28 manifestation + Class D fail-plausible 取代 gray failure + 防御数据 4,286 测试 + 827 治理检查 ex ante 失败率 + 87% 重复事故阻断 + 最佳检测器=人类阅读 + 最长故障在组件接缝)」作为「Agent 静默失败邻接」小节)+ §2.0 (iv) Service Concurrency Safety(补充 arXiv:2606.14589 五类分类法机制描述)+ §6.5 Agent 安全/记忆/评估(补充 arXiv:2606.14589 关键论文 ID 与五类分类法);新增 C52 共识候选:"LLM Agent 静默失败分类法五类(环境怪癖 / 设计假设错配 / 错误吞没 / Fail-Plausible 链式幻觉与伪造 / 操作遗漏与取证盲点)成为 2026 H1 LLM 系统特有故障模式的标准分类;Class D fail-plausible 是传统 gray failure 的 LLM 升级版(观察者被失败本身用流畅谎言说服);8 周生产数据:40 个定时任务 + 8 个 LLM provider + 22 postmortem + 28 manifestation;4,286 测试 + 827 治理检查 ex ante 阻止新发事故率=0,recurring 阻断率=87%;最佳检测器=人类阅读产品输出";新增 D24 争议候选:"LLM Agent 静默失败的可观测性工具(LLM-judge + Langfuse + Phoenix + Arize)是否能取代人类阅读产品输出成为最佳检测器;fail-plausible 防御机制(sabotage 测试 / scanners)能否在 2026 H2 落地到生产框架(LangGraph / CrewAI / Microsoft Agent Framework)"
增量 4【分布式推理 §2.7 / §2.10】vLLM Kubernetes 生产 OOM 三陷阱 runbook 实战(★ 必补)
- 来源:
inbox/jay/2026-07-26-evening-engineering-filter.md高价值 1
GPU 内存计算公式(实操版):
GPU memory needed = (model_params_B × 2 GB) # FP16 weights
+ 25% for KV cache # attention states
+ overhead
- 7B FP16 ≈ 14GB weights,可放在单张 24GB GPU
- 70B FP16 ≈ 140GB,需要 2× A100 80GB 或 4× A100 40GB(tensor parallelism)
- INT4 量化后 70B ≈ 35GB,可放单张 A100 80GB
OOM 三大陷阱(真实错误模式):
| 陷阱 | 症状 | 根因 | 修复 |
|------|------|------|------|
| 陷阱1:Pod 启动即 OOM | gpu-memory-utilization 过高或 max-model-len 过大 | 权重 + KV cache 预分配总和超 GPU 总容量 | 先算数学再部署 |
| 陷阱2:就绪探测后 OOM | Pod 通过 readiness probe,随后 OOMKilled | 空闲时模型"能装下",但并发请求 KV cache 需求超出 | 降低 max-num-seqs 或增加 headroom |
| 陷阱3:T4 16GB 错觉 | 权重约 16GB + CUDA overhead 1GB,KV cache 剩余 -1GB | 权重能加载,但 KV cache 预分配叠加后 OOM | 调低 gpu-memory-utilization |
核心配置参数(实测推荐):
args:
- --model
- meta-llama/Llama-3-8b
- --max-model-len
- "8192"
- --gpu-memory-utilization
- "0.85" # 不默认 0.90,留 headroom 给 CUDA fragmentation
- --enable-prefix-caching
- --enable-chunked-prefill
监控验证命令(可复现):
watch -n1 nvidia-smi --query-gpu=memory.used,memory.free,utilization.gpu --format=csv
峰值负载时 memory.used 须在租户配额内,memory.free 始终不低于 CUDA context + activation buffer 预留量
KEDA 自动扩缩容(替换 HPA-on-CPU): - GPU memory 是静态指标(vLLM 预分配),不能触发 HPA - 用 KEDA 按 queue depth 触发扩缩 - vLLM 不暴露 queue depth 指标 → 需配合 Prometheus 自定义 metrics
NCCL 错误陷阱(多 GPU TP 场景):
- --ipc=host flag:NCCL 用共享内存做节点内 GPU 通信
- 共享内存不足时产生 cryptic NCCL runtime error
- 与 dev namespace 4-line volume mount 配置强相关
- 与活文档关系:§2.7 工程化工具链 + Agent Frameworks 七大 + Harness 三件套 + LiteLLM + eBPF KubeCon EU 2026 + Inference Engineering 职业化 + CNCF llm-d + K8s v1.36 + Istio GA 已有部署栈完整描述(LINSTOR CSI + 三资源 manifest + KEDA + Prometheus + Grafana 监控栈);但 vLLM K8s 生产 OOM runbook 是缺失:KEDA 仅有概述,GPU 内存公式、3 大陷阱、配置 YAML、监控命令、NCCL --ipc=host 共享内存陷阱均未作为生产实战 runbook 入位
- 建议归入:§2.7 工程化工具链(新增「vLLM K8s 生产 OOM 三陷阱 runbook」作为生产实战补充小节 = GPU 内存公式 + OOM 三陷阱表 + 配置 YAML + 监控命令 + KEDA queue depth + NCCL --ipc=host)+ §2.10 Cloud-Native 推理 2026 H1 完整栈(补充"KEDA queue depth 触发 + vLLM Prometheus 自定义 metrics 暴露");新增 O132 试金石:"vLLM 是否在 2026 H2 暴露 queue depth 官方指标;KEDA vLLM scaler 是否进入 vLLM Helm chart 默认配置;NCCL --ipc=host 是否在 K8s RuntimeClass 1.32+ 成为默认安全策略"
增量 5【Agent Frameworks §2.7】Microsoft Agent Framework 1.0 统一 Semantic Kernel + AutoGen + Claude Agent SDK hierarchical subagent = 企业 Agent 框架 2026 H1 重大格局变动(★ 必补)
- 来源:
inbox/jay/2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md高价值 2 +organized/knowledge/llm-infra.md§2.7 已有 7 大生产排名
Alice Labs — AI Agent 框架 2026 生产评分(18+ 部署经验):
| 框架 | 版本 | 关键更新 | Alice Labs 评分 |
|---|---|---|---|
| LangGraph | 1.0 GA(2025-10) | Q2 2026 per-node timeout + durable streaming | 生产 S 级 |
| Claude Agent SDK | renamed 2026-Q1 | hierarchical subagent spawning(2026-06) | 生产 S 级 |
| Microsoft Agent Framework | 1.0(2026-04-03) | Semantic Kernel + AutoGen 统一 | 新晋 |
| CrewAI | 1.14(2026-05~06) | pluggable-backend releases | 生产 A 级 |
| LlamaIndex Workflows | 1.0(2026-06-22) | — | 生产 A 级 |
| Pydantic AI | V2(2026-06-23) | harness-first redesign | 生产 A 级 |
| AG2 / AutoGen | legacy | 仅用于学术多 agent 对话研究 | B 级 |
核心工程决策维度(Alice Labs 框架):Cost · Latency · Efficacy · Assurance · Reliability
工程评价:Microsoft Agent Framework 1.0 是 2026 年最大变量——统一 Semantic Kernel 和 AutoGen 后,企业客户从"二选一"变成"统一接入",预计会显著压缩 CrewAI 和 LlamaIndex 的企业份额。LangGraph 1.0 凭 durable streaming 和 per-node timeout 补全了生产可观测性短板
- 与活文档关系:§2.7 已有 Agent Frameworks 七大生产排名 + 沿革(7-15 evening 入位),但Microsoft Agent Framework 1.0 仅在「7 大生产排名」一句话:未将 2026-04-03 1.0 发布日期 + Semantic Kernel+AutoGen 统一 + 企业格局影响作为 2026 H1 重大格局变动单独入位
- 建议归入:§2.7(新增「Microsoft Agent Framework 1.0(2026-04-03)+ Semantic Kernel + AutoGen 统一 = 企业 Agent 框架 2026 H1 重大格局变动」小节 + Claude Agent SDK 2026-Q1 rename + 2026-06 hierarchical subagent spawning 邻接)+ §2.8 Agent 记忆 + RAG 演进(补充 Claude Agent SDK hierarchical subagent 生产规模数据待核)+ §6.5 Agent 安全/记忆/评估(补充 Alice Labs 18+ 部署经验框架评分);新增 C53 共识候选:"Microsoft Agent Framework 1.0(2026-04-03)统一 Semantic Kernel + AutoGen = 企业 Agent 框架 2026 H1 重大格局变动;Claude Agent SDK 2026-Q1 rename + 2026-06 hierarchical subagent = Anthropic 体系完整;LangGraph 1.0 GA 2025-10 + Q2 2026 per-node timeout + durable streaming 补全生产可观测性短板;Alice Labs 评分体系 Cost/Latency/Efficacy/Assurance/Reliability 5 维成为 Agent 框架选型标准";新增 O133 试金石:"Microsoft Agent Framework 1.0 是否在 Azure AI Studio 成为默认 Agent 框架 + 与 LangGraph 1.0 / Claude Agent SDK 形成三足鼎立;LlamaIndex Workflows 1.0 与 Pydantic AI V2 是否在企业份额被压缩;CrewAI pluggable-backend 是否能维持 A 级"
增量 6【Agent 协议栈 §2.7】MCP 2026-07-28 RC 核心变更 6 件 = Agent 协议栈生态模块化关键里程碑(★ 必补)
- 来源:
inbox/jay/2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md高价值 1
MCP 2026-07-28 规范候选版核心变更(官方 blog 提前披露):
- 移除 Mcp-Session-Id 与协议级 session(SEP-2567):简化了有状态协议设计,客户端不再依赖 server 端 session 追踪
- Server 发起的请求必须在客户端请求处理期间(SEP-2260):解决了 long-running server 发起的回调无法关联上下文的问题
- Extensions 独立版本管理(SEP-2133):reverse-DNS ID 标识 + extensions 独立仓库 + 独立维护者 + 独立于规范版本演进——这是 MCP 生态模块化的关键里程碑
- Tasks extension 重塑生命周期(SEP-2663):server 可返回 task handle,客户端通过
tasks/get、tasks/update、tasks/cancel驱动异步任务,适配 stateless model 的流式推理场景 - OIDC Dynamic Client Registration 修复(SEP-837):修复桌面/CLI 客户端被 Authorization Server 错误标记为 "web" 类型导致 localhost redirect URI 被拒的问题
- MCP Apps(SEP-1865):server 可推送 sandboxed iframe HTML 界面,实现富交互式工具,无需每个 host 单独实现 UI 渲染
工程评价:Tasks extension 对生产级异步 agent 工具调用(文档处理、代码执行、网页抓取等长时间任务)意义重大。Extensions 独立版本化意味着 MCP 生态将从"大一统规范"向"模块化插件体系"演进
- 与活文档关系:§2.7 已有 MCP/A2A/AP2 三层协议栈(MCP 97M 月下载 / GitHub 37K stars / 5800+ servers / 10K+ active / Anthropic 创建 2025-12 捐 Linux Foundation AAIF),未收录 MCP 2026-07-28 RC 6 件核心变更
- 建议归入:§2.7(新增「MCP 2026-07-28 RC 6 件核心变更 = ① SEP-2567 移除 Mcp-Session-Id ② SEP-2260 Server 发起请求必须在客户端请求处理期间 ③ SEP-2133 Extensions 独立版本管理(reverse-DNS ID + 独立仓库 + 独立维护者) ④ SEP-2663 Tasks extension(适配 stateless model 流式推理) ⑤ SEP-837 OIDC Dynamic Client Registration 修复 ⑥ SEP-1865 MCP Apps sandboxed iframe」);新增 O134 试金石:"MCP 2026-07-28 RC 是否在 2026-08 GA;Tasks extension 是否被 Claude Desktop / Zed IDE / Cursor 1 个月内支持;MCP Apps sandboxed iframe 是否取代 host-specific UI 实现"
二、旁证(2 件)
旁证 1【Agent 训练 §2.6 / §2.8】OpenForgeRL arXiv:2607.21557 Harness 原生训练 + ReOPD arXiv:2607.04763 多轮在策略蒸馏
- 来源:
inbox/jay/2026-07-26-engineering-e1prep.md增量 7 +paper_cards/585-2607-21557.md+paper_cards/576-2607-04763.md
OpenForgeRL arXiv:2607.21557:现代 AI Agent 依赖 Claude Code / Codex / OpenClaw 等推理 harness,但现有 SFT/RL 栈无法原生表达有状态多进程 harness 推理。OpenForgeRL 提出轻量代理方案:代理服务化处理 harness 模型调用,同时记录完整轨迹用于 RL 训练。直接解决 Agentic Engineering 学科化中 Harness 训练闭环问题
ReOPD arXiv:2607.04763 Multi-Turn On-Policy Distillation with Prefix Replay:多轮 Agent 交互中,教师模型轨迹作为回放前缀,学生在选定步骤执行动作,教师提供密集逐步监督。环境外(off-environment)替代全在线 OPD,降低多轮 Agent 训练成本
- 与活文档关系:活文档 §2.6 并行化四大轴线 + §2.8 Agent 记忆 + RAG 演进未收 OpenForgeRL 与 ReOPD;但 spark 7-26 agent-e1prep 增量已落位 §2.7 Agent 训练基础设施邻接(沿用 jay engineering-e1prep);两篇均为 agent 主分类 paper_cards(副分类 engineering),与 llm-infra 主线邻接
- 建议归入:§2.6 并行化四大轴线(邻接「Agent 训练基础设施:OpenForgeRL Harness 原生训练 + ReOPD 多轮蒸馏 prefix replay」)+ §2.8 Agent 记忆 + RAG 演进(邻接「训练基础设施层:OpenForgeRL 与 ReOPD 形成『Harness 训练 + 多轮蒸馏』训练闭环两件套」)+ §6.5 Agent 安全/记忆/评估(补充 arXiv:2607.21557 + arXiv:2607.04763)
旁证 2【推理工程 §2.9】vLLM vs TensorRT-LLM 2026 生产选型指南 = 「快速迭代+多模型」vs「深度优化+单模型」市场分割
- 来源:
inbox/jay/2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md高价值 5
vLLM 优势场景:开箱即用 HuggingFace 模型 + OpenAI-compatible API + PagedAttention + continuous batching + prefix caching 开源透明;适合模型频繁变更、多种模型同时服务、MaaS 场景
TensorRT-LLM 优势场景:NVIDIA GPU 专用优化 + 编译后执行图高度定制 + H100/A100 上吞吐最高、延迟最低;适合单一稳定模型长期生产、延迟 SLO 严苛场景 + MoE 架构(DeepSeek-V3 等)支持持续完善
工程决策流程(Yotta Labs 建议):
模型稳定吗?→ 否 → vLLM
↓ 是
NVIDIA GPU 为主?→ 否 → vLLM 或 SGLang
↓ 是
延迟/吞吐 SLO 严苛?→ 是 → TensorRT-LLM
↓ 否
模型种类多?→ 是 → vLLM
实际工程常见模式:先用 vLLM 验证模型和功能,规模稳定后将高流量模型迁移到 TensorRT-LLM。SGLang 处于两者之间,以 RadixAttention prefix caching 和灵活调度为差异化
- 与活文档关系:§2.9 推理引擎决策 8 维度已有 vLLM vs SGLang 2026 三方 benchmark 决策树 + 8 维度 D1-D8,未将 vLLM vs TensorRT-LLM 决策树作为「推理引擎决策树 v2.0」完整入位;活文档 §2.9 已有 TRT-LLM v1.2 RC(PyTorch 主导路径确认),但生产选型决策树仍以 vLLM vs SGLang 为中心,未引入 TensorRT-LLM 作为「单模型生产场景」第三选项
- 建议归入:§2.9 推理引擎决策 8 维度(新增「vLLM vs TensorRT-LLM 2026 生产选型决策树 v2.0」邻接 + 「快速迭代+多模型」vs「深度优化+单模型」市场分割)+ §6.1 核心推理引擎与基准(补充 vLLM + SGLang + TensorRT-LLM + LMDeploy 四引擎决策树);新增 O135 试金石:"vLLM 是否在 2026 H2 集成编译优化路径(替代 TensorRT-LLM 的部分场景);TensorRT-LLM v1.2 PyTorch 主导路径是否在 2026 H2 落地到生产部署;SGLang RadixAttention 是否成为「快速迭代+多模型」与「深度优化+单模型」之外的第三选项"
三、值得警惕的矛盾或待核实说法
| # | 说法 | 来源 | 警示类型 | 状态 |
|---|---|---|---|---|
| 1 | ByteDance Doubao 单独贡献 120T token/天(2026-03 较 2024 年初增长 ~1000× 整体 140T/天) | arXiv:2605.11733 Energy-to-Token 立场论文(增量 2) | ⚠️ 数据传染 / 数据来源不明——140T/天 + Doubao 120T/天 数字未给具体计算方法(API 调用量 vs 实际推理 token 量 vs 用户对话量 vs 内部调用量) | 维持 ⚠️ 警示,建议读者通过 ByteDance 官方 2026 Q1 财报或 AI Lab 公告独立核验 |
| 2 | arXiv:2605.11733 "Energy-to-Token" 评估框架在 2026 H2 进入主流 | 增量 2 来源立场论文 + jay 7-26-1735 briefing 后续行动 | ⚠️ 立场论文 vs 实证研究——这是 arXiv 立场论文(position paper),非实证 benchmark;是否有 SIGMOD/SOSP/OSDI 2026 H2 评审会议接受实证论文需要追踪 | 维持 ⚠️ 警示,建议关注 ICML 2026 / NeurIPS 2026 / SIGCOMM 2026 评审会议 |
| 3 | arXiv:2606.14589 "Fail-Plausible" 五类分类法+ 4,286 测试 + 827 治理检查 ex ante 阻止新发事故率=0 + recurring 阻断率=87% + 最佳检测器=人类阅读产品输出 | 增量 3 来源 arXiv:2606.14589(2026-06 论文) | ⚠️ 单来源数据 + 单一生产环境——只有 1 个 personal-assistant agent runtime + 8 周窗口 + 40 个定时任务;是否具有跨生产环境普适性需要追踪 | 维持 ⚠️ 警示,新增数据后(更多生产环境 + 12 周窗口)需要重新评估 |
| 4 | vLLM K8s 生产 OOM 三陷阱 + GPU 内存公式 + 配置 YAML(增量 4 来源 thegoodshell.com / kubenatives.com / dev.to) | jay 7-26-evening-engineering-filter | ⚠️ 多源印证但来源均为博客 + 社区文章——GPU 内存公式「25% for KV cache」是粗略估计,实际 KV cache 占比因 model + sequence length + batch size 变化显著(7B 1K context 可能 < 10%,70B 128K context 可能 > 50%) | 维持 ⚠️ 警示,建议引用时标注「博客经验数据,实际占比需独立 benchmark」 |
| 5 | Microsoft Agent Framework 1.0 统一 Semantic Kernel + AutoGen + Claude Agent SDK 2026-Q1 rename + 2026-06 hierarchical subagent spawning = 企业 Agent 框架 2026 H1 重大格局变动 | 增量 5 来源 Alice Labs 18+ 部署经验评分(alicelabs.ai/en/insights/best-ai-agent-frameworks-2026) | ⚠️ 第三方评分体系主观性——Alice Labs 是 AI 工程咨询公司,18 个生产部署数据可能集中在特定客户类型(企业 vs 初创);是否具有跨公司类型普适性需要追踪 | 维持 ⚠️ 警示,与 Simon Willison / LangChain 评分体系对比验证已在 jay 7-26-1735 briefing 后续行动列出 |
| 6 | MCP 2026-07-28 RC 6 件核心变更(SEP-2567/2260/2133/2663/837/1865) | 增量 6 来源 MCP 官方 blog blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate | 🟢 官方规范变更,可信度高,但需关注 GA 时间线——官方 blog 提前披露 RC 内容,实际 GA 时间 + 各主流 MCP client(Claude Desktop / Zed IDE / Cursor)支持时间线待跟踪 | 维持 🟢,关注 2026-08 GA |
四、可引用的 arXiv 号列表
| arXiv 号 | 论文/系统 | 主题归属 | 在活文档状态 |
|---|---|---|---|
| 2605.01280 | LLM Serving 应借鉴 OR 数学优化而非启发式立场论文 + Chen et al. 2026 Ω(√(B log G)) 改善因子 | 推理调度 | ✅ 已入 §2.2(一行,本次完整展开) |
| 2605.11733 | LLM 推理应评估为「能量-Token 产出」立场论文 + 140T token/日 + Doubao 120T/日 + 高质量人类数据 2026-2028 稀缺 | 推理经济学(全新) | ❌ 未入活文档,本场新增 |
| 2606.14589 | Silent Failures in Production LLM Agent Systems(8 周数据 + 5 类分类法 + Class D fail-plausible) | 服务层并发安全 / Agent 静默失败 | ⚠️ 已入 §2.5 一行,本次完整展开五类分类法 |
| 2607.21557 | OpenForgeRL Harness 原生训练闭环 | Agent 训练 | ❌ 未入活文档,本场新增(旁证) |
| 2607.04763 | ReOPD Multi-Turn On-Policy Distillation with Prefix Replay | Agent 训练 | ❌ 未入活文档,本场新增(旁证) |
| 2607.19058 | SkewAdam MoE 40% 内存 + 1.3× 训练(沿用 7-25) | 训练工程 | 已知(沿用 v36 §2.87) |
| 2607.21503 | Agentic Context Management(沿用 7-23) | Agent 评测 | 已知(沿用 7-23) |
| 2504.19874 | TurboQuant ICLR 2026(沿用 7-25) | KV 量化 | ✅ 已入 §2.3 极激进压缩路线 |
五、归位建议总览(给今晚活文档接力)
§2.2 调度 9 学派:新增「OR 数学框架立场论文完整展开 + Chen et al. 2026 Ω(√(B log G))」(对应增量 1) §1 现状全景 11 维(新增「经济学评估层 12」或 §2.11 §V fresh 集锦):补充「Energy-to-Token 评估框架 + 140T token/日 + Doubao 120T/日」(对应增量 2) §5 趋势(新增 T25 趋势候选):「LLM 推理评估从速度/准确率转向单位能量/token 产出 + 经济学视角取代纯工程视角」(对应增量 2) §2.5 安全(新增「LLM Agent Fail-Plausible 五类分类法」小节):8 周生产数据 + 22 postmortem + 28 manifestation + Class D fail-plausible + 4,286 测试 ex ante 阻止率=0 + recurring 阻断率=87% + 最佳检测器=人类阅读(对应增量 3) §2.0 (iv) Service Concurrency Safety:补充 arXiv:2606.14589 五类分类法机制描述(对应增量 3) §2.7 工程化工具链(新增「vLLM K8s 生产 OOM 三陷阱 runbook」小节):GPU 内存公式 + OOM 三陷阱表 + 配置 YAML + 监控命令 + KEDA queue depth + NCCL --ipc=host(对应增量 4) §2.10 Cloud-Native 推理 2026 H1 完整栈:补充 KEDA queue depth 触发 + vLLM Prometheus 自定义 metrics 暴露(对应增量 4) §2.7 工程化工具链(新增「Microsoft Agent Framework 1.0 统一 Semantic Kernel + AutoGen = 企业 Agent 框架 2026 H1 重大格局变动」):Microsoft Agent Framework 1.0(2026-04-03) + Claude Agent SDK 2026-Q1 rename + 2026-06 hierarchical subagent spawning(对应增量 5) §2.8 Agent 记忆 + RAG 演进:补充 Claude Agent SDK hierarchical subagent 生产规模数据待核(对应增量 5) §2.7(新增「MCP 2026-07-28 RC 6 件核心变更」):SEP-2567 + SEP-2260 + SEP-2133 + SEP-2663 + SEP-837 + SEP-1865(对应增量 6) §2.6 并行化四大轴线(邻接「Agent 训练基础设施」):OpenForgeRL Harness 原生训练 + ReOPD 多轮蒸馏 prefix replay(对应旁证 1) §2.9 推理引擎决策 8 维度(新增「vLLM vs TensorRT-LLM 2026 生产选型决策树 v2.0」):「快速迭代+多模型」vs「深度优化+单模型」市场分割(对应旁证 2)
新增共识候选 6 条:C50(数学优化取代启发式)/ C51(Energy-to-Token 评估)/ C52(Fail-Plausible 五类分类法)/ C53(Microsoft Agent Framework 1.0 统一)/ C54(MCP 2026-07-28 RC 6 件)/ C55(vLLM K8s OOM 三陷阱 runbook) 新增争议候选 3 条:D23(Energy-to-Token vs P99 latency 评估)/ D24(fail-plausible 可观测性工具能否取代人类阅读)/ D25(MCP Tasks extension 是否适配 stateless model 流式推理) 新增趋势候选 1 条:T25(LLM 推理评估从速度/准确率转向能量-Token 产出 + 经济学视角取代纯工程视角) 新增试金石 6 条:O130(数学优化是否进入 SIGMOD/OSDI/SOSP 2027 评审主流)/ O131(Energy-to-Token 评估开源工具能否实测能量/token 比率 + 高质量人类数据稀缺性何时可量化)/ O132(vLLM 是否暴露 queue depth 官方指标 + KEDA vLLM scaler 是否进入 Helm chart)/ O133(Microsoft Agent Framework 1.0 是否在 Azure AI Studio 成为默认 + LangGraph/Claude Agent SDK 三足鼎立)/ O134(MCP 2026-07-28 RC GA 时间线 + Tasks extension 支持时间线)/ O135(vLLM 是否集成编译优化路径 + TensorRT-LLM PyTorch 主导路径落地) 新增参考文献 2 条(§6.7):arXiv:2605.11733 LLM-Energy-Token-Production + arXiv:2607.21557 OpenForgeRL-Harness-Training
六、本场检查过的来源清单
jay/inbox(7-26 6 份主稿): 2026-07-26-engineering-e1prep.md(11:23 · v36 · 7 增量 + 4 警示)✅ 2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb.md(17:35 · 8 高价值条目)✅ 2026-07-26-evening-engineering-filter.md(17:00 · vLLM K8s OOM runbook + Fail-Plausible + AI Agents Stack 2026)✅ 2026-07-26-csdn-substack-llm-inference-rag-weekly.md(08:22 · 14 条)✅ 2026-07-26-rag-agent-llm-systems-briefing.md(11:06 · 7 条)✅ 2026-07-26-csdn-llm-rag-agent.md(12:21 · 6 件)✅
tom/inbox(7-26 3 份): 2026-07-26-rag-e1prep.md(08:50 · v45 · 6 增量 + 8 未建卡 arXiv)✅ 2026-07-26T0840-agent-rag-longcontext-radar.md(8 候选 + 3 高价值)✅ 2026-07-25-inference-e1prep.md(22:00 · v25 · 4 增量,沿用 7-25)✅
spark/inbox(7-26 3 份 RSS,无 E1 落地): 2026-07-26-1000-rss-gradient-flow.md(三个新模型观察 + 开源 AI 支出判断)✅ 2026-07-26-1001-rss-chip-huyen.md(AI 工程常见陷阱 + Agents)✅ 2026-07-26-1003-rss-yt-3blue1brown.md(交叉熵 · 完美编码)✅
stephen/inbox(7-26 协调棒): 2026-07-26-1245-stephen-coordination-check-noon.md(确认本场接力主题 = llm-infra 9 天未更新待补救)✅
flyp/inbox(7-26 无直接 llm-infra 新工程增量): 2026-07-26-multimodal-e1prep.md(42KB · v32 → v33 准备棒)✅ 2026-07-26-0950-Structured-Dynamics-Model-position-paper-critical-read.md(10.3KB · 周日班)✅
paper_cards(近 3 天新卡 IDs 561-597 共 37 张): - 主分类 llm-infra:0 张(本场无新增 llm-infra 主分类卡片) - 主分类 agent:7 张(含 569-2607.20734, 575-2607.19238 FinanceComplexQA, 576-2607.04763 ReOPD, 583-2308-08155, 585-2607.21557 OpenForgeRL, 567-2607.21051, 564-2607.21503 Agentic Context Management) - 主分类 multimodal:6 张 - 主分类 evaluation:3 张 - 主分类 engineering:多张(均为 OpenAlex 经典回填 1412-6115 / 2305.06161 / 2307.10169 / 2305.01210 / 2305.10403 / 1603.09320 等)
work-queue.md(2026-07-26 18:00): - 待建卡:0 - 待更新主题活文档:llm-infra 9 天未更新 ✅ - 待富化:62 张卡缺 TLDR(待 cron_s2 覆盖)
七、结论
状态:✅ 完成预消化 增量条数:6 主线 + 2 旁证 + 6 警示(主线密度低于 7-25 11 主线,符合「7-25 大波收尾 → 7-26 中密度补充」第五轮抢修节奏) 涉及 arXiv 号:2 个新号(arXiv:2605.11733 Energy-to-Token 全新 + arXiv:2607.21557 OpenForgeRL 旁证)+ 2 个已知号深化(arXiv:2605.01280 数学优化立场论文完整展开 + arXiv:2606.14589 Fail-Plausible 五类分类法完整披露)+ 1 个已知号沿用(arXiv:2504.19874 TurboQuant)+ 3 个 agent 主分类邻接(arXiv:2607.04763 ReOPD + arXiv:2607.21503 Agentic Context Management + arXiv:2607.19058 SkewAdam)
核心结构:增量 1(数学优化取代启发式,§2.2 调度 9 学派邻接)+ 增量 2(Energy-to-Token 全新评估框架,§1 现状全景 + §5 趋势邻接)+ 增量 3(Fail-Plausible 五类分类法,§2.5 安全 + §2.0 (iv) 邻接)+ 增量 4(vLLM K8s OOM runbook,§2.7 工程化工具链 + §2.10 Cloud-Native 邻接)+ 增量 5(Microsoft Agent Framework 1.0 统一,§2.7 + §2.8 邻接)+ 增量 6(MCP 2026-07-28 RC 6 件核心变更,§2.7 协议栈邻接)+ 旁证 1(OpenForgeRL + ReOPD Agent 训练基础设施,§2.6 + §2.8 邻接)+ 旁证 2(vLLM vs TensorRT-LLM 决策树 v2.0,§2.9 决策 8 维度邻接)
主要填补: - §2.2 调度 9 学派 = arXiv:2605.01280 立场论文完整展开 + Chen et al. 2026 Ω(√(B log G)) 改善因子解释 + 数学优化取代启发式方法论 - §1 现状全景 11 维 = 新增「经济学评估层 12」 Energy-to-Token 视角(arXiv:2605.11733) - §2.5 安全 = Fail-Plausible 五类分类法(8 周生产数据 + 22 postmortem + Class D fail-plausible + 防御数据 4,286 测试 ex ante 阻止率=0 + recurring 阻断率=87%) - §2.7 工程化工具链 = vLLM K8s OOM runbook + Microsoft Agent Framework 1.0 统一 Semantic Kernel + AutoGen + MCP 2026-07-28 RC 6 件核心变更 - §2.9 推理引擎决策 8 维度 = vLLM vs TensorRT-LLM 决策树 v2.0(「快速迭代+多模型」vs「深度优化+单模型」市场分割)
无显著新增量时如实写明:本场增量密度低于 7-25 11 主线 + 3 旁证 + 2 矛盾点,符合「7-25 大波收尾 → 7-26 中密度补充」节奏;6 警示均为增量 1-6 来源论文的可信度边界标注(立场论文 vs 实证研究 + 单生产环境数据 + 多源印证但博客经验 + 第三方评分体系主观性 + 官方规范变更 GA 时间线待跟踪),非新发现的数据传染或矛盾点;paper_cards 近 3 天主分类 llm-infra 新增 0 张,延续 7-25 同期趋势(纯 inference-systems 卡片持续缺位)
Spark · 2026-07-26 18:40 (Asia/Shanghai) · llm-infra E1 预消化