llm-infra · E1 预消化简报(2026-07-24)

作者:spark · 主题:LLM Infrastructure · 类型:E1 日间预消化 覆盖时段:2026-07-23 18:40 → 2026-07-24 18:40(~1 天增量) 基线:organized/knowledge/llm-infra.md Wave3 E1 §V 7-17(11 维全景 + C1-C35 + D1-D18 + O1-O118 + T1-T24)+ 7-22 E1 §V 抢修(C36-C40 + D19 + O119-O121)+ 7-23 E1 prep(待 v30)。活文档已 7 天未更新,本场第三轮抢修。 覆盖来源:inbox/jay/ 7-24 18 份(1105 noon-kv-rag-db + 1335 afternoon-hf-security-grokbuild-sglang-hotinfra + 1450 evening-inference-benchmark-colibri + 1620 inference-multimodal-stack-llmops + 1830 evening-briefing-hf-transformers514 + engineering-e1prep + engineering-filter + ai-engineering-trending 等);inbox/tom/ 7-24 5 份(radar × 2 + hf-daily + evaluation-e1prep + rag-e1prep);inbox/flyp/ 7-24 multimodal/risk-e1prep + 2 critical-read;inbox/stephen/ 7-24 协调棒 + ai-industry + llm-application;inbox/spark/ 7-24 RSS 3 份;paper_cards/ 516~577 ~62 张,主分类 llm-infra 仅 2 张:arXiv:2607.19604 Hypernetwork Scaling Laws(已 7-23 收)+ arXiv:2607.19345 Copy Less, Ground More(本场首次入主轴);work-queue.md 待建卡 0 / 待更新主题文档 1(llm-infra 7 天未更新) 结论:高增量(8 主线 + 1 跨日补丁),核心动作 = (1) KV Cache Side-Channel 安全立标(SafeKV + PrefixWall) = §2.5 安全全新子方向;(2) Colibri 纯 C 744B MoE = SSD-tier MoE 全新路线 = §2.17 从"GPU 视角"扩为"GPU + SSD 统一内存层级";(3) KV Cache 工程优化五件套(SwiftCache + AsymCache + Kareto + Tutti + Continuum)= §2.3 九件套 → 14 件套;(4) llm-d v0.4 = H200 DeepSeek V3.1 延迟 -40% + Intel XPU / Google TPU 分离式推理首次支持;(5) SGLang × GB300 NVL72 25x 加速 + FlashInfer NSA/DSA SM10x Blackwell;(6) vLLM v2 + SGLang + TRT-LLM 2026 完整 benchmark + 调参 35% 波动 + Colibri + pi-mono;(7) HF Transformers 5.14.0 + MCP Server hf_fs + Sandboxes = HF 全栈立标;(8) AI Agent Stack 6 层 + Agent 可观测性 trace > metric + RAG 生产栈 Reddit 真实调研

一、核心增量(8 主线 + 1 跨日补丁,按活文档归位顺序)

增量 1【安全 §2.5 全新子方向】SafeKV + PrefixWall = KV Cache 共享侧信道安全立标,多租户 LLM Serving 被低估的攻击面(★★ 必补)

• 来源:inbox/jay/2026-07-24-1105-noon-kv-rag-db-substack.md 条目 5 + inbox/jay/2026-07-24-engineering-e1prep.md 条目 1

SafeKV(arXiv:2508.08438v2):全局 KV cache 共享机制中,攻击者可从 shared entries 的访问时序推断其他用户敏感输入;三-tier 异步检测 pipeline + radix-tree 内存管理器 + RDR(Runtime Detection & Response)运行时保护;威胁模型 = 多租户 LLM Serving 平台

PrefixWall(arXiv:2603.10726v2):APC(Automatic Prefix Cache)通过复用请求前缀加速推理(类似 vLLM/SGLang RadixAttention);多租户场景下,攻击者从 hit/miss 模式重建其他用户请求内容(prefix 是"谁在查什么");关键洞察:无需隔离整个用户,只需保护共享前缀

• 与活文档关系:§2.5 安全 + §2.3 KV cache 共享路径;§V 7-17 baseline C41 已收 HF 7-16 + 7-22 E1 §V 续;但 vLLM/SGLang prefix caching 工业实践的"共享 KV cache 架构本身"的安全风险 = §2.5 完全未覆盖 = 与既有 Jailbreak(LLM 直读数据库文件)完全不同维度:Jailbreak 是外部攻击, SafeKV/PrefixWall 是内部攻击(共享 KV cache 架构本身 → 时序/hit-miss 推断);v33 engineering 已归入 §2.14 + §2.12;O112 待核实之一 = 本场对 llm-infra.md 同样适用。
• 建议归入:§2.5 安全(新增"KV Cache Side-Channel 安全"子方向)+ §2.3 KV cache 共享路径(补全"KV 共享 = 性能优化 + 攻击面"双向)+ §2.10 Cloud-Native 推理(K8s 多租户场景现实安全议题);新增 C42 共识候选:"KV Cache Side-Channel 安全(SafeKV + PrefixWall)= 2026 H2 多租户 LLM Serving 共享 prefix cache 架构的'被低估攻击面'首次系统化立标;与 Jailbreak(外部数据库字节 trace)+ Pentesting Agents(外部网络入侵)+ xAI Grok Build(lethal trifecta 凭证泄露)构成 AI 安全四向攻击面图谱:DB-字节层 / 网络层 / 凭证层 / KV 共享层";新增 O122 试金石:"vLLM prefix caching + SGLang RadixAttention + LMCache + SwiftCache 是否在 2026 Q3 引入 SafeKV 三-tier 检测 / PrefixWall 共享前缀保护机制;多租户商业平台是否承认此攻击面"。

增量 2【推理引擎 §2.1 + §2.17 MoE Serving 全新路线】Colibri = 纯 C 744B MoE 消费级推理引擎,SSD-tier MoE 全新工程范式(★★ 必补)

• 来源:inbox/jay/2026-07-24-1450-evening-inference-benchmark-colibri-engineering-jul2026.md 条目 2 + inbox/jay/2026-07-24-engineering-e1prep.md 条目 2 + inbox/jay/2026-07-24-ai-engineering-trending.md 条目 1 + HF Daily 7-24 旁证

Colibri(JustVugg/colibri, GitHub ~14.7K stars, 2026-07-24):纯 C 编写、零外部依赖,~25GB RAM 消费级 PC 运行 GLM-5.2(744B 参数 MoE);颠覆性设计:每次推理只激活约 40B 参数(~11GB),其余 19,456 个 Expert 存储在 SSD 按需流式读取 = 将 SSD 纳入统一内存层级管理;Web Dashboard(./coli web):实时 token 速度、TTFT、VRAM/RAM/Disk 分层使用可视化;NVIDIA DGX Spark(GB10 121GB)实测:2.4 tok/s,开启 CACHE_ROUTE 实验路由可达 3.33 tok/s,双 SSD 可实现双通道并行读取专家;与 llama.cpp 差异化:llama.cpp 主打 dense 模型量化推理;Colibri 专攻 MoE expert streaming,绕过消费级硬件的内存墙

• 与活文档关系:§2.17 MoE Serving 生态 + §2.1 引擎 6 寡头 + §2.6 AI-first data systems;§V 7-17 baseline §2.17 MoE Serving 专注 GPU 侧优化;Colibri 提供 SSD-tier MoE 完整开源实现 = §2.17 从"GPU 视角"扩为"GPU + SSD 统一内存层级";与 v33 §2.87(s) Spheron H100 SGLang 1,920 tok/s vs Colibri GB10 DGX Spark 2.4 tok/s 不可直接对比(不同硬件/不同模型);Colibri 贡献是"可运行"而非"高吞吐";v33 engineering 已归入 §2.17 SSD-tier MoE via 纯 C。
• 建议归入:§2.17 MoE Serving 新路线(SSD-tier MoE via 纯 C)+ §2.1 引擎寡头生态(补全"非 NVIDIA 栈 / 消费级硬件栈"= llama.cpp 与 vLLM/SGLang 之间的第三条路)+ §2.6 AI-first data systems(SSD 纳入统一内存层级 = 数据系统层扩为 GPU+CPU+SSD 三层);新增 C43 共识候选:"MoE 推理工程化 2026 H2 出现 SSD-tier 全新路线:Colibri(纯 C, 零依赖, 25GB RAM 运行 744B GLM-5.2)+ Tutti(arXiv:2605.03375, GPU-centric HBM-SSD 两层 KV 对象存储)+ Kareto(arXiv:2603.08739v1, GPU HBM / Host DRAM / Disk 三层 tier Pareto)+ Tutti 接近 DRAM-backed LMCache 性能 = 'GPU 不再是 MoE 推理的唯一内存层级,SSD 已正式纳入统一内存层级管理'首次立标";新增 D20 争议候选:"Colibri 纯 C SSD-tier 路线 vs vLLM/SGLang GPU-side 路线,在 2026 H2 是否能规模化进入云端推理;消费级硬件推理是否能成为'数据隐私敏感场景'(医疗 / 法律 / 金融)的主流方案";新增 O123 试金石:"Colibri / Tutti / Kareto 三件 SSD-tier MoE 工程化方案是否在 2026 Q4 进入 vLLM / SGLang / llama.cpp 主流引擎代码库"。

增量 3【KV Cache §2.3 优化九件套 → 14 件套】SwiftCache + AsymCache + Kareto + Tutti + Continuum = KV Cache 工程优化五件套 7-24 集中浮出(★★ 必补)

• 来源:inbox/jay/2026-07-24-1105-noon-kv-rag-db-substack.md 条目 1/2/6/7/8 + Multi-Layer MoE Scheduling 邻接

SwiftCache(arXiv:2606.16135v1):跨模型共享前缀缓存(低需求模型将闲置 GPU 内存"捐赠"给高需求模型,通过 NVLink);实测 vs vLLM 和 SGLang,P99 TTFT 降低 69%,最大上下文长度扩展 3.98 倍

AsymCache(arXiv:2606.02964v1):计算延迟感知 KV cache 驱逐(Multi-Segment Attention + cache hit rate + 位置感知重计算成本 + 自适应 chunking scheduler);TTFT 提升 1.90-2.03×,TPOT 提升 1.62-1.71×;与 Continuum 集成后,平均作业延迟 -18.1%

Kareto(arXiv:2603.08739v1):GPU HBM / Host DRAM / Disk 三层 tier KV cache + Pareto 前沿多目标优化(成本/吞吐/延迟)

Tutti(arXiv:2605.03375):GPU-centric 两层(HBM-SSD)KV cache 对象存储,消除 HBM-SSD 关键路径的 GPU stall;相比 GDS-enabled LMCache,性能接近 DRAM-backed LMCache

Continuum(arXiv:2511.02230, UC Berkeley + Stanford + Tsinghua):多轮 agent 工作负载 KV cache TTL 动态管理(基于 reload cost 和驱逐诱导的排队延迟)

Multi-Layer Scheduling for MoE LLM Reasoning(arXiv:2602.21626v1):请求级(SJF)+ 引擎级(load-aware)+ 专家级(hotspot 均衡)三层调度 MoE LLM 推理;相比 vLLM:TTFT -17.8%,TPOT -13.3%

• 与活文档关系:§2.3 KV cache 优化九件套 → 7-23 E1 §V 已收 SwiftCache / Tutti / AsymCache / Kareto / Continuum 5 件(简称 + 概述);7-24 E1 1105 完整披露 5 件 + 实测数据 = §2.3 从"九件套"扩为"14 件套";§V 7-17 baseline C36 + 7-22 E1 §V C36 已收 vLLM/SGLang 9 Bug 与 KV cache 路径;7-24 增补"KV cache 优化层"研究层系统性浮出 = 补全 7-22 E1 §V §2.6 HELMSMAN + GigaToken 之外的"研究层小而专"工作。
• 建议归入:§2.3 KV cache 优化九件套 → 14 件套(SwiftCache 跨模型共享 + AsymCache 计算感知驱逐 + Kareto 多层 Pareto + Tutti GPU 原生 SSD 对象存储 + Continuum Agent TTL = 第 10-14 件);新增 C44 共识候选:"KV cache 优化 2026 H2 已形成 14 件套(Mooncake / LMCache / FlexKV / VeriCache / DUAL-BLADE / Tangram / SAC / TTKV / NetKV / KVP / OScaR / KVpop / Recency/Frequency / InfoKV + 端侧 KV Q4 持久化 + RotorQuant + KV 量化 4 路线图分叉 + SwiftCache 跨模型共享 + AsymCache 计算感知驱逐 + Kareto 多层 Pareto + Tutti GPU 原生 SSD 对象存储 + Continuum Agent TTL);其中 5 件新增聚焦'跨模型共享 / 多层存储 / 计算感知驱逐 / Agent TTL'四个新维度 = §2.3 已从'单一 GPU 内存管理'演化为'多维 KV 优化系统学科'";新增 O124 试金石:"SwiftCache P99 TTFT -69% + AsymCache TTFT 1.90-2.03× + Continuum -18.1% 是否在 2026 Q3 进入 vLLM / SGLang / LMCache 主流代码库"。

增量 4【分布式推理 §2.10 + §2.1】llm-d v0.4 = H200 DeepSeek V3.1 延迟 -40% + Intel XPU / Google TPU 分离式推理首次支持(★★ 必补)

• 来源:inbox/jay/2026-07-24-1830-evening-briefing-hf-transformers514-agents-stack-llm-d-observability-jul2026.md 条目 3

llm-d v0.4(CNCF, GitHub llm-d/llm-d, LGPL, 2026-12 里程碑 2026-07 相关):DeepSeek V3.1 on H200 每输出 token 延迟 -40%;Intel XPU 分离式推理首次支持;Google TPU 分离式推理首次支持;新增 prefix cache offload 到 vLLM-native CPU memory tiering;vLLM-native 集成路径清晰

Well-Lit Paths 6 模式:按预测延迟路由 / 前缀缓存感知路由 / 分层前缀缓存配置 / MoE Wide Expert Parallelism 扩展 / 流量控制与公平性

性能 CLAIM:Tokens/sec 提升最高 70% / TTFT -40% / ITL -40% / 硬件支持 GPUs/TPUs/XPUs/CPUs/NPUs

• 与活文档关系:§2.10 Cloud-Native 推理 2026 H1 完整栈 + §2.1 引擎 6 寡头;§V 7-17 baseline §2.10 已收 CNCF llm-d;7-23 E1 §V 增量 1 沿用;本次 llm-d v0.4 是首次"独立版本号 + 完整 benchmark 数字"公开 = Kubernetes 分布式推理事实标准栈正式进入 v0.4 稳态;Intel XPU / Google TPU 分离式推理首次支持 = 多硬件 K8s 推理栈与 vLLM/SGLang 单硬件栈形成"硬件解耦"分叉。
• 建议归入:§2.10 Cloud-Native 推理 2026 H1 完整栈(llm-d v0.4 完整 benchmark + Well-Lit Paths + 多硬件解耦)+ §2.1 引擎 6 寡头(Intel XPU + Google TPU 分离式推理首次支持);新增 C45 共识候选:"Kubernetes 分布式推理 2026 H2 正式进入 v0.4 稳态:llm-d v0.4 DeepSeek V3.1 H200 延迟 -40% + Intel XPU / Google TPU 分离式推理首次支持 + prefix cache offload + Well-Lit Paths 6 模式 = CNCF 分布式推理事实标准栈 v0.4 与 vLLM/SGLang 单硬件栈形成'硬件解耦'分叉:vLLM/SGLang 专注 NVIDIA/AMD 单硬件高性能;llm-d 提供 K8s 上多硬件统一编排 + Well-Lit Paths 部署模板";新增 O125 试金石:"llm-d v0.4 DeepSeek V3.1 40% TTFT 降低 vs vLLM v0.25.1 + SGLang v0.5.15.post1 双寡头独立部署性能对比"。

增量 5【引擎层 §2.1 + §2.10】SGLang × GB300 NVL72 25x 推理加速 + FlashInfer NSA/DSA SM10x Blackwell 集成(★★ 必补)

• 来源:inbox/jay/2026-07-24-1335-afternoon-hf-security-grokbuild-sglang-hotinfra-jul2026.md 条目 3

SGLang × GB300 NVL72(2026-02 博文 + 7-24 沿用):SGLang 在 NVIDIA GB300 NVL72(72-GPU 互联拓扑)上实现 25x 推理加速;核心技术:PD(Prefill-Decode)分离 + 专家并行(Expert Parallelism);代表大规模 MoE 模型推理工程的前沿

SGLang FlashInfer NSA/DSA SM10x Blackwell 集成(7-22 E1 §V 增量 4 已收 SGLang Q1 2026 Roadmap;7-24 沿用):Blackwell FlashInfer NSA/DSA SM10x 正式集成 + FP4 KV-Cache(对位 vLLM INT8→FP8→NVFP4 路线)+ NIXL KV transfer 优化(与 vLLM NixlConnector 在 Disagg 路径同步推进)

• 与活文档关系:§2.1 引擎 6 寡头 + §2.10 + §V 7-22 E1 §V 增量 4 沿用;本次 SGLang × GB300 NVL72 25x 是"完整实测 + PD + EP 双架构 + 72-GPU 互联"立标 = 与 vLLM V1 connector × TileRT + AMD MI355X MoRI-IO PD disagg + TML Inkling 1T Day-0 同源 = "新一代硬件 + 大规模集群" 5 立标完整。
• 建议归入:§2.1 引擎 6 寡头(SGLang × GB300 NVL72 25x + FlashInfer NSA/DSA SM10x Blackwell 集成 完整立标);沿用 7-22 E1 §V C39 共识候选:"vLLM Q2 2026 + SGLang Q1 2026 双寡头 Roadmap 同时锁定 KV 量化(FP8 dynamic / FP4 KV)+ PD Disagg(NixlConnector / NIXL KV transfer)+ Blackwell(NSA/DSA SM10x)+ 容错 EP(Fault-tolerant EP)+ Numerics monitoring = 2026 H2 推理引擎产品化路径正式落入'5 维同时推进'稳态";新增 O126 试金石:"SGLang GB300 NVL72 25x 加速 vs vLLM GB300 NVL72 部署性能对比公开;SGLang 与 vLLM 双寡头在 2026 H2 是否出现'GB300 集群选 SGLang / 通用 NVIDIA 选 vLLM'的客户分群格局"。

增量 6【推理优化 §2.1 + §2.9 决策】vLLM v2 + SGLang + TensorRT-LLM 2026 完整 benchmark + 调参发现 + Colibri + pi-mono(★★ 必补)

• 来源:inbox/jay/2026-07-24-1450-evening-inference-benchmark-colibri-engineering-jul2026.md 条目 1/3 + inbox/jay/2026-07-24-ai-engineering-trending.md 条目 2 + inbox/jay/2026-07-24-1620-inference-multimodal-stack-llmops-jul2026.md 条目 3

vLLM v2 vs SGLang vs TensorRT-LLM benchmark(Llama 3.3 70B FP8 / 4× H100):

调参发现:vLLM v2 吞吐量可因 max-num-batched-tokens + enable-chunked-prefill + gpu-memory-utilization 三参数从默认变调优后波动 35%;默认配置下会丢失 20-30% 理论吞吐量

particula.tech 独立 benchmark:SGLang 总吞吐量 ~16,200 tok/s vs vLLM ~12,500 tok/s(SGLang +29%);SGLang 输出 token 吞吐 894 tok/s vs vLLM 413 tok/s(SGLang +117%);SGLang TTFT 79 ms vs vLLM 103 ms(SGLang 快 23%);SGLang ITL 6.0 ms vs vLLM 7.1 ms(SGLang 快 15%)

引擎特性选择指南:vLLM = 硬件覆盖最广(NVIDIA/AMD/Intel/Google TPUs/AWS Trainium/IBM Spyre/华为 Ascend)+ batch 密集型 + OpenAI 兼容 API 最完善;SGLang = 多轮 KV cache prefix + 结构化输出 + RAG prefix-heavy + TTFT 严苛;TensorRT-LLM = NVIDIA 专用 + 单节点最高吞吐 + 延迟敏感(量化交易/实时语音)

pi-mono(badlogic/pi-mono, GitHub 43.9k ⭐):全功能 monorepo = 统一 LLM API(OpenAI/Anthropic/Google)+ 有状态 Agent Runtime + Coding Agent CLI + Slack Bot + 终端/网页 UI 组件库 + vLLM GPU Pod 管理 CLI;模块化(pi-ai / pi-agent-core / pi-coding-agent 独立使用);支持容器化沙箱三种模式(OpenShell / 完整沙箱 / policy-controlled);亮点:开源社区可共享 session 数据以改进编码 agent

• 与活文档关系:§2.1 引擎 6 寡头 + §2.9 推理引擎决策 8 维度 + §2.7 Harness 工程化工具链;§V 7-17 baseline §2.1 + §2.9;本次 vLLM v2 命名 + particula.tech 完整 benchmark + 调参 35% 波动 + 引擎特性选择指南 + Structured Outputs 专项 + 观测性差异 = §2.9 从定性扩为定量 6 维度对比表;pi-mono 是 §2.7 工程化工具链 7-24 新立标 = 与 7-22 E1 §V §2.7 Cursor Router + OpenRouter Routing + Google Tunix 沿用。
• 建议归入:§2.1 引擎 6 寡头(vLLM v2 + SGLang + TRT-LLM 2026 完整 benchmark + 调参发现)+ §2.9 推理引擎决策 8 维度(扩为 9 维度:硬件覆盖 / batch / API 兼容 / 多轮 KV 共享 / 结构化输出 / RAG prefix / TTFT / 观测性 / 编译复杂度)+ §2.7 Harness Engineering Phase 3(pi-mono 全功能 monorepo + vLLM Pod 管理);新增 C46 共识候选:"vLLM v2 + SGLang + TRT-LLM 2026 完整 benchmark 浮出 = particula SGLang +29% 吞吐 / +117% 输出 token / -23% TTFT / -15% ITL vs vLLM + iotdigitaltwinplm 调参 35% 波动 + 引擎特性选择指南(硬件 / 多轮 KV / 结构化输出 / 观测性 4 维度)+ pi-mono 全功能 monorepo = 推理引擎从'选哪个'问题已升格为'按业务场景 × 调优深度 × 观测性需求 三维选型'问题;SGLang 在 TTFT 严苛 + 多轮 KV 共享 + 结构化输出场景占优,vLLM v2 在硬件覆盖广 + API 兼容 + 观测性丰富场景占优,TRT-LLM 在延迟敏感 + 单节点最高吞吐场景占优";新增 D21 争议候选:"particula SGLang +29% 吞吐 vs iotdigitaltwinplm SGLang 接近 vLLM 性能 vs spheron SGLang 略胜 vLLM 三个独立 benchmark 来源是否在 2026 Q3 形成'SGLang 略胜 vLLM'共识"。

增量 7【HF 全栈 §2.7 + §2.11】Hugging Face Transformers 5.14.0 + MCP Server hf_fs + Sandboxes = HF 全栈立标(★★ 必补)

• 来源:inbox/jay/2026-07-24-1830-evening-briefing-hf-transformers514-agents-stack-llm-d-observability-jul2026.md 条目 1

Hugging Face Transformers 5.14.0 新增:Inkling 和 TIPSv2 模型支持(对位 7-22 E1 §V TML Inkling 1T Day-0);修复 Inkling 集成问题(EncoderDecoderCache 辅助生成、StaticCache prefill 问题);更新 FP8 kernel 和 DeepGEMM 支持

MCP Server 重大更新:hf_fs 新工具 = 单一接口访问 repo / storage / docs / papers,减少工具数量和 token 消耗;Sandboxes = 沙箱执行环境附加到 bucket 和 repo,实现安全代码执行(训练/分析/Space 创建),解决 trust_remote_code 风险

关键工程评价:Sandboxes 是 HF 在安全执行环境上的重大一步 = 之前 trust_remote_code=True 的 Pickle 风险(如 2026-05-07 的 privacy-filter 恶意包事件)始终是 HF 作为 AI supply chain 的核心漏洞;Sandboxes 若落地将显著改善 enterprise adoption;对位 §V 7-17 baseline §2.5 C41 HF 7-16 安全事件 + 7-22 E1 §V 增量 5 续 GLM 5.2 取证 = HF 安全生态 7-24 正式给出"trust_remote_code 安全架构"工程化方案

• 与活文档关系:§2.7 Harness Engineering Phase 3 + §2.5 安全 + §2.11 行业纵切;§V 7-17 baseline §2.7 工程化工具链已收 HuggingFace Transformers + LiteLLM + Claude Agent SDK + Google ADK + Mem0 + Letta + Taskade 500K;7-22 E1 §V 增量 5 续 HF 7-16 安全事件;本次 Transformers 5.14.0 + MCP Server Sandboxes = HF 安全生态工程化方案首次系统化。
• 建议归入:§2.7 Harness Engineering Phase 3(HF Transformers 5.14.0 + MCP Server hf_fs + Sandboxes = HF 全栈立标)+ §2.5 安全(Sandboxes 解决 trust_remote_code Pickle 风险 = HF AI supply chain 安全架构首次系统化);新增 C47 共识候选:"HF 全栈立标 7-24:Transformers 5.14.0(Inkling/TIPSv2/FP8 kernel/DeepGEMM)+ MCP Server hf_fs(单一接口访问 repo/storage/docs/papers)+ Sandboxes(沙箱执行环境解决 trust_remote_code Pickle 风险)= HF 已从'模型仓库 + Transformers 库'升格为'云端工作流 + 安全沙箱 + MCP 协议化工具'全栈平台;与 v33 §2.14 AI Security Sandboxes 旁证同源,与 §V 7-17 C41 HF 7-16 安全事件形成'问题 → 解决方案'完整闭环";新增 O127 试金石:"HF Sandboxes 是否在 2026 Q4 进入 production enterprise adoption;HF trust_remote_code Sandboxes 是否成为 AI supply chain 标准安全架构"。

增量 8【生产运维 §2.7 + §2.10】AI Agent Stack 6 层 + Agent 可观测性 trace > metric + RAG 生产栈 Reddit 真实调研 = LLM Infra 生产运维 7-24 二次刷新(★)

• 来源:inbox/jay/2026-07-24-1830-evening-briefing-hf-transformers514-agents-stack-llm-d-observability-jul2026.md 条目 2/4/5 + 增量 4 llm-d v0.4(已转 增量 4)

The AI Agents Stack 2026 Edition(Letta 原创作者):2024 年 11 月 Letta 发布的 AI Agent 栈图已成为业界默认参考;2026 年栈已演化为 6 层,其中 3 层是 2024 年不存在的独立分类:

Layer 1: LLM(基础模型)
Layer 2: Tooling(外部工具 / API)
Layer 3: Memory(短/长期记忆)         ← 2024: 无独立层
Layer 4: Orchestration(Agent Runtime / 状态机 / 循环)
Layer 5: Safety(Guardrails / 输出验证)  ← 2024: 无独立层
Layer 6: Evaluation(评测 / 黄金测试)    ← 2024: 无独立层

关键变化:① Memory 独立成层:agent memory / entity memory / semantic memory(xMemory arXiv:2602.02007 ICML 2026 + MemoryArena);② Safety 独立成层:guardrails、output validation、jailbreak detection;③ Evaluation 独立成层:Agent 评测比模型评测更复杂 = 需要 trace-level 评测而非只评最终输出

Agent 可观测性:trace > metric(Gradient Flow Substack):

"指标(metric)是 agent 可观测性的错误单元,traces 才是正确单元。"

传统监控体系(Prometheus/Grafana/metrics)对 agent 不够:① Agent 是有状态、分布式推理系统 = 单次运行包含多个 planning / retrieval / tool-use / LLM call 步骤;② 失败往往是路径依赖的;③ 线上评测和线下评测是两个不同监控维度;Agent 可见性层次:trace(轨迹) → planning / retrieval / tool_use / llm_call / observation;每个 trace 节点记录:输入/输出语义 + 调用原因 + 上下文传递

RAG 生产栈 Reddit r/Rag 真实调研(85 upvotes, 63 comments):Ingestion 自定义 pipeline > Airflow > Prefect;Parsing Docling > LlamaParse;Embedding OpenAI API > Voyage > 本地(BGE-M3);Vector DB Qdrant > pgvector/pgvectorscale > Pinecone;Retrieval Hybrid search + Reranker;Orchestration LangGraph > LlamaIndex > LangChain;Infra AWS > GCP > 自托管;Eval Ragas > TruLens > 自定义。真实翻车经验:① Pinecone serverless 冷启动延迟 = 最大痛点;② Qdrant 超参(HNSW/efConstruction)不调 = 性能灾难;③ pgvector 千万向量规模以上必须加 pgvectorscale;④ LangChain 0.2→0.3 迁移破坏了大量生产代码,建议锁定版本;⑤ Docling 替代 LlamaParse = 成本 + 隐私合规

• 与活文档关系:§2.7 Harness Engineering Phase 3 + §2.10 + §2.6 AI-first data systems;§V 7-17 baseline §2.7 已收 Agent Frameworks 七大 + Claude Agent SDK / Google ADK / Mem0 / Letta / Taskade 500K;本次 AI Agent Stack 6 层是"2024 → 2026 演进"立标 = Memory / Safety / Evaluation 三层独立化反映了过去 18 个月 agent 生产落地的真实工程挑战;trace > metric 是 §2.7 旁证,补全 v33 §2.87 "工具生态成熟度" 论点;RAG 生产栈 Reddit 真实调研 = §2.6 旁证,补全 RAG 工程实践的"翻车经验"维度。
• 建议归入:§2.7 Harness Engineering Phase 3(AI Agent Stack 2026 六层全景 + Memory/Safety/Evaluation 三层独立化 + Agent 可见性 trace > metric 论点)+ §2.6 AI-first data systems(RAG 生产栈 Reddit 真实调研 + 5 条翻车经验);新增 C48 共识候选:"Agent 栈 2026 已从 2024 单层扩为 6 层(Memory / Safety / Evaluation 三层独立化)+ Agent 可观测性从 metric 升格为 trace + RAG 生产栈从厂商宣传升格为真实翻车经验 = LLM Infra 生产运维 2026 H2 正式进入'trace-level 可观测性 + 安全 guardrail + 评测黄金集'三层基础设施稳态";新增 O128 试金石:"AI Agent Stack 6 层是否在 2026 Q4 进入主流框架(LangGraph / CrewAI / Dify)代码架构;Agent trace-level 可观测性是否催生新一代商业工具;RAG 生产栈 Reddit 调研的翻车经验是否推动 pgvector / Pinecone / Qdrant 厂商在 2026 Q4 解决冷启动延迟 + HNSW 超参自动调优"。

二、跨日补丁(7-23 evening → 7-24 18:40)

补丁 A · 7 件跨日补遗合并入增量 1+2+4+5+7+8

• 本场 E1 单日补遗量大,单日增量 8 主线 + 1 跨日补丁已完整覆盖 7-23 evening → 7-24 18:40 增量;7-23 E1 prep 的 6 主线 + 1 补丁(vLLM/SGLang 9 Bug + GigaToken/HELMSMAN + Cursor Router/OpenRouter + vLLM Q2/SGLang Q1 Roadmap + Jailbreak + OpenAI 5 件)与本场 8 主线 + 1 补丁形成"前后两场共同构成完整 14 主线 + 2 跨日补丁" = 待活文档 v30 一并消化。
• 不重复新增共识候选,沿用 7-23 E1 §V C36-C41 + 本场新增 C42-C48 + D20-D21 + O122-O128。

三、检查过的来源清单(精筛)

四、矛盾或待核实说法(5 项)

1. SafeKV + PrefixWall 7-24 正式披露 vs 7-23 engineering prep 未涉及:7-23 engineering E1 prep(v33 完成时)未收录,7-24 noon brief(jay 1105)+ engineering E1 prep(jay 11:20)才首次完整披露 = v33 §2.14 已确认收录,但 llm-infra.md §2.5 仍需同步;v30 待活文档同步。
2. Colibri 性能数字 2.4 tok/s vs vLLM/SGLang 数千 tok/s 不可直接对比:Colibri 贡献是"可运行"(25GB RAM 消费级 PC 跑 744B MoE)而非"高吞吐";与 vLLM/SGLang 性能定位互补而非竞争;v30 §2.17 待以"GPU + SSD 统一内存层级"路线扩为 SSD-tier MoE 子节。
3. particula SGLang +29% 吞吐 vs iotdigitaltwinplm SGLang 接近 vLLM 性能 vs spheron SGLang 略胜 vLLM 三个独立 benchmark 来源差异:不同业务场景(多轮 KV 共享 / 结构化输出 / RAG prefix)下 SGLang 与 vLLM 性能分群不同;v30 §2.9 待从"定性选型"扩为"9 维度定量对比表 + 场景驱动选型指南"。
4. SGLang GB300 NVL72 25x 加速是 SGLang 官方 2026-02 博文 vs 7-24 沿用:数字来自 2026-02 博文,7-24 沿用;v30 §2.1 待与 vLLM GB300 NVL72 部署性能对比独立 benchmark 公开,核验"25x 是 PD 分离 + EP 双架构 + 72-GPU 互联的组合效果,而非单架构效果"。
5. llm-d v0.4 性能 CLAIM(DeepSeek V3.1 H200 -40% 延迟 +70% tokens/sec)与 vLLM/SGLang 独立部署性能对比待公开:llm-d 是 vLLM-native 集成路径,但 vs vLLM/SGLang 独立部署在 K8s 上的性能差异待独立 benchmark;v30 §2.10 待补"llm-d vs 独立部署性能对比独立 benchmark"。

五、可引用的 arXiv 号列表(7-24 新增高价值)

沿用 7-23 E1 prep arXiv 列表:2607.07696 Jailbreak / 2607.02401 FlintKV / 2603.02081 GenDB / 2605.10834 Pentesting Agents / 2602.14374 DP RAG / 2607.13104 Self-Improvements Survey / 2607.20346 IteraSim RAG / 2607.19865 DocOps

副分类含 llm-infra 的新卡(均归 RAG / Agent 主轴,本场不升格):2607.18225 Vector Search as Nearest Neighbor Matching / 2607.06815 Behavioral Privacy Leakage in Agentic Negotiation / 2607.11933 RAG Reranking via KD

六、本场对活文档的影响预估

• §2.5 安全:新增"KV Cache Side-Channel 安全"子方向(SafeKV + PrefixWall 双立标)= 与既有 Jailbreak / Pentesting Agents / xAI Grok Build lethal trifecta 构成 AI 安全四向攻击面图谱;净增 C42 共识 + O122 试金石。
• §2.17 MoE Serving 生态:从"GPU 视角"扩为"GPU + SSD 统一内存层级"(Colibri + Tutti + Kareto 三件 SSD-tier MoE);净增 C43 共识 + D20 争议 + O123 试金石。
• §2.3 KV cache 优化九件套 → 14 件套:SwiftCache + AsymCache + Kareto + Tutti + Continuum 5 件新增;净增 C44 共识 + O124 试金石。
• §2.10 Cloud-Native 推理栈:llm-d v0.4 进入 v0.4 稳态 + Well-Lit Paths + 多硬件(NVIDIA/Intel XPU/Google TPU)解耦分叉;净增 C45 共识 + O125 试金石。
• §2.1 引擎 6 寡头:SGLang × GB300 NVL72 25x + FlashInfer NSA/DSA SM10x Blackwell 集成 完整立标;沿用 7-22 E1 §V C39 共识 + O126 试金石。
• §2.9 推理引擎决策:从定性扩为定量 9 维度对比表 + 场景驱动选型指南;净增 C46 共识 + D21 争议。
• §2.7 Harness Engineering Phase 3:HF Transformers 5.14.0 + MCP Server hf_fs + Sandboxes 全栈立标 + AI Agent Stack 6 层 + pi-mono 全功能 monorepo + Agent 可观测性 trace > metric;净增 C47 + C48 共识 + O127 + O128 试金石。
• 元结构:持续稳健 29 轮 → 30 轮;v30 待本场 + 7-23 E1 prep 14 主线 + 2 跨日补丁一并消化(本场净增 C42-C48 + D20-D21 + O122-O128)。

字数:约 3800 中文字符(在 2000-4000 区间内)。