llm-infra · E1 预消化简报(2026-07-25)
作者:spark · 主题:LLM Infrastructure · 类型:E1 日间预消化 覆盖时段:2026-07-24 18:40 → 2026-07-25 18:40(~1 天增量) 基线:
organized/knowledge/llm-infra.md(11 维全景 + C1-C36 + D1-D19 + O1-O121 + T1-T25)+.llm-infra-candidate.md2026-07-25 05:00 版(已吸纳昨日 7-24 8 主线 v36:candidate),候选 76KB,vLLM Inference OS + SGLang GB300 25× + llm-d v0.4 H200 −40% + KV 5 件套 + HF 自主 Agent 入侵 + MCP CVE 三连 + AI Agent Stack 6 层 + FlashAttention-4 Blackwell + Cursor Router 已全部入主轴。本场为「昨日大波收尾 → 今日中小密度」第四轮抢修。 覆盖来源:inbox/jay/7-25 ~22 份(1055 engineering filter + 1105 db-backend-cloudnative-inference [MRV2 56% + VeriCache + Cloud Native Model Distribution] + 1105 substack [Agent failure 3 + A2A/CUA] + 1335 afternoon-hf-inference-csdn [Pragmatic Engineer inference engineering 定义 + OWASP Agent 双谱系 + SGLang 杀 TGI + QuantSpec + OpenClaw 210k] + 1450 engineering-filter-p2 [Zylos FP8 33% + Continuous Batching 23× + FA-3 840 TFLOPS 85% util + Blockify 78x/40x + 70% Enterprise RAG fail + 43% AI code debug + Amazon Kiro 13h outage] + 1610 evening-briefing [llm-d CNCF Sandbox 2026-03-24 公告 + K8s 自托管 vLLM 2026-07-16 官方 + KubeCon EU 2026 + SGLang 29% 边界 + 向量 DB P50 benchmark] + 1735 evening-rag-inference-stack [TurboQuant 6×/8× + RAG 5 架构 + DevOps→LLMOps 技能映射表] + ai-engineering-trending + csdn-llm-rag-agent-vecdb + csdn-supplement);inbox/tom/7-25 9 份(hf-daily + 1440 agent-rag-longcontext-radar + rag-e1prep + evaluation-e1prep,本场已纳入 spark agent-e1prep);inbox/flyp/0 直接 llm-infra 新文件(7-25 凌晨);inbox/stephen/7-25 协调棒 + ai-industry + 11 份 news radar(无新 llm-infra 工程增量);inbox/spark/7-25 4 份(rss-gradient-flow + rss-chip-huyen + rss-yt-3blue1brown + agent-e1prep 完整版);paper_cards/564-585 新 22 张,主分类 llm-infra 0 张(均为 agent/evaluation/multimodal),最高价值 arXiv:2607.21503 Agentic Context Management(已沿用)+ arXiv:2607.21557 OpenForgeRL(已沿用)+ 技属 §2.5 runtime 邻接;work-queue.md(2026-07-25 18:00)待建卡 0 / 待更新主题文档 1(llm-infra 8 天未更新) 结论:中密度(6 主线 + 3 旁证 + 2 矛盾点),核心动作 = (1) llm-d 正式入 CNCF Sandbox + K8s 自托管 vLLM 官方部署手册 + KubeCon EU 2026 KAR v1.35 + Cloud Native Model Distribution = CNCF K8s AI 推理事实标准全面立标;(2) vLLM MRV2 GB200 56% 吞吐提升 + 2026 H1 完整新功能集 (FP8/NGram Spec/Chunked Prefill 默认/Native RL/Disagg/Ascend 950) = vLLM Inference OS 升格量化数据;(3) TurboQuant arXiv:2504.19874 KV Cache 6× / Attention 8× + QuantSpec Apple ICML 2026 自推测解码 + VeriCache arXiv:2605.17613 压缩 KV 替代 draft = KV Cache 压缩三件套 2026 H2 立标;(4) Zylos 实测量化矩阵(FP8 33%/AWQ 95%/GPTQ 90%/GGUF 92%) + FlashAttention-3 840 TFLOPS 85% util + Continuous Batching 23× = vLLM/SGLang 推理优化基线量化数据;(5) Microsoft MAF Harness BUILD 2026(.NET+Python 双语言)+ Enterprise LLM Agent Plan/Architect/Zulu 三层架构 + OWASP Agent ASI01-ASI10 双谱系 = 商业级 Harness SDK 首次全面立标;(6) 70% Enterprise RAG 失败田野 + 4 类失效模式(Chunk/Embedding/Reranking/Context 饱和)+ 43% AI 代码生产调试 + Amazon Kiro 13h outage + Compounding Error 0.85^10=20% + Gartner 40% 废弃 = Agent/RAG 生产可靠性量化数据全栈
一、核心增量(6 主线 + 3 旁证,按活文档归位顺序)
增量 1【分布式推理 §2.10 + §2.1】llm-d 正式入 CNCF Sandbox + K8s 自托管 vLLM 官方手册 + KubeCon EU 2026 = CNCF K8s AI 推理事实标准全面立标(★★ 必补)
- 来源:
inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md条目 1/2/3 +inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md条目 Cloud Native Model Distribution + 7-22 E1 §V 沿用
llm-d 加入 CNCF Sandbox(2026-03-24 公告, cncf.io/blog/2026/03/24):
- 创始成员:Red Hat + Google Cloud + IBM Research + CoreWeave + NVIDIA
- 使命:any model, any accelerator, any cloud——分布式 LLM 推理作为一级云原生工作负载
- 核心技术能力:Disaggregated prefill/decode(PD 分离)+ LeaderWorkerSet(LWS,多节点模型分布式推理标准抽象)+ DisaggregatedSet operator(Mistral AI 贡献)
- 生态定位:llm-d ≠ 推理引擎 = K8s 上的 "agent for inference engines"(编排层),可管理 vLLM / SGLang / TRT-LLM 生命周期
- CNCF 同源项目:Kueue(GPU 作业队列调度)+ KAITO(AKS K8s operator for AI)+ KServe(模型推理 Serving)+ KRO(K8s Resource Orchestrator)
CNCF 官方「Kubernetes 运行自托管 vLLM」(2026-07-16 最新博文):
- 部署架构三件套:PersistentVolumeClaim(模型权重,LINSTOR CSI 管理)+ Secret(HF token)+ Deployment + Service(OpenAI 兼容 REST API)
- 环境要求:Docker Engine ≥ 23.0 + K8s ≥ 1.27 + NVIDIA GPU Operator + cert-manager
- 混合部署策略:敏感数据本地推理 + 高容量任务走管理 API
- 关键 OpenAI 兼容 API:/v1/chat/completions 等,无需修改应用代码即可迁移
KubeCon EU 2026 关键发布: - KAR v1.35:更严格的 Kubernetes AI Requirements - KRO(Kube Resource Orchestrator):K8s 资源编排增强 - Agentic Sandbox 可移植性:Agent 工作负载跨 K8s 环境验证 - CNCF 2026 调查数据:82% 容器用户生产运行 K8s;66% 托管生成式 AI 的组织使用 K8s 处理部分或全部推理(对比 2024 年 50% 数据工作负载,领先组织已超 75%) - CNCF 平台收敛论点:「The conversation has fundamentally shifted from stateless web applications to distributed data processing, distributed training jobs, LLM inference, and autonomous AI agents.」
Cloud Native AI Model Distribution(Harbor + Dragonfly + Model CSI + ORAS 流水线): - 四步交付流水线:Develop(HF Hub weights)→ Build(CI/CD 打包不可变 Model Artifact)→ Manage(Harbor AI Model Processor + ORAS)→ Deploy(K8s OCI Volumes / Model CSI Driver) - CNCF 协同:Harbor 模型签名+元数据 + Dragonfly 负载感知分发加速 + CRI-O/containerd OCI Artifacts + Model CSI Driver 挂载为 Volume + ORAS 分发协议 - KubeCon 2026 NA:CNCF AI & Inference Day,11 月 9 日,Salt Lake City
- 与活文档关系:§2.10 Cloud-Native 推理 2026 H1 完整栈 + §2.1 引擎 6 寡头;§V 7-17 baseline §2.10 已收 CNCF llm-d 但仅作为概述;7-22/7-23 E1 §V 已在 llm-d v0.4 增量捕获「K8s 推理事实标准」论点;本次(7-25)是首次在 jay inbox 完整披露「CSD CNCF Sandbox 公告 + K8s 自托管 vLLM 部署官方手册 + KubeCon EU 2026 关键发布 + Cloud Native Model Distribution 四步流水线」=「CNCF K8s AI 推理事实标准栈」从「性能数字」扩为「治理结构 + 部署规范 + 模型交付流水线 + 生态协同」完整四件套立标;与 K8s v1.36 AI-native GA + Istio Gateway API Inference Extension GA 2026-03-25 同源。
- 建议归入:§2.10 Cloud-Native 推理 2026 H1 完整栈(新增"CNCF K8s AI 推理事实标准栈 2026 H1 完整四件套"小节 = Sandbox 入主 + 自托管官方手册 + KubeCon EU 关键发布 + Model Distribution 流水线)+ §2.1 引擎 6 寡头(进一步补 "vLLM 是 K8s AI 推理事实标准默认推理引擎")+ §2.7 工程化工具链(Model CSI Driver + ORAS + Harbor AI Model Processor);新增 C49 共识候选:"CNCF K8s AI 推理事实标准栈 2026 H1 完整立标四件套 = ① llm-d CNCF Sandbox(2026-03-24, Red Hat+Google+IBM+CoreWeave+NVIDIA)② CNCF 自托管 vLLM K8s 官方部署手册(2026-07-16, LINSTOR CSI + 三资源 manifest)③ KubeCon EU 2026 关键发布(KAR v1.35 + KRO + Agentic Sandbox 可移植性)④ Cloud Native Model Distribution(Harbor + Dragonfly + Model CSI + ORAS 四步流水线);与 vLLM V1 connector TileRT 双引擎共存 + llm-d v0.4 分层 KV Cache Tier 1/2/3 + NIXL + Istio Gateway API Inference Extension 共同构成 2026 H2 K8s AI 推理基础设施完整生态"`;新增 D22 争议候选:"CNCF 66% 组织用 K8s 推理 vs 非 K8s 路径(裸机 vLLM + 私有云)的真实比例;llm-d 作为编排层是否会在 2026 H4 占据 K8s 推理事实标准位置,vs Inference Gateway / Dapr 在 K8s 上的并行竞争";新增 O129 试金石:"llm-d 是否在 2026 H4 从 CNCF Sandbox 升 Incubating;Cloud Native Model Distribution 流水线是否在 2026 Q3 进入 vLLM / SGLang 官方文档作为推荐模型交付方式;CNCF 自托管 vLLM K8s 部署手册的 LINSTOR CSI 是否在 K8s 1.32+ 升级为 GA"。
增量 2【推理引擎 §2.1 + §2.4】vLLM MRV2 GB200 56% 吞吐提升 + 2026 H1 完整新功能集 = vLLM Inference OS 升格量化立标(★★ 必补)
- 来源:
inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md条目 vLLM MRV2 +inbox/jay/2026-07-25-engineering-e1prep.md条目 1 +inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md条目 vLLM K8s + Spheron Blog 2026 + vLLM 官方文档 v0.20.0+
vLLM MRV2(Model Runner V2):
- 架构:GPU-native Triton kernels + async scheduling
- 启用方式:VLLM_USE_V2_MODEL_RUNNER=1 显式启用(非默认)
- 性能:GB200 实测最高 56% 吞吐提升(因硬件而异, 需独立 benchmark)
- 版本时间线:v0.20.0 引入 + v0.20.2(2026-05)稳定版 + v0.23.0rc1(2026-07-20)最新候选
- 候选 .llm-infra-candidate.md 已收「vLLM v0.25.0 MRV2 默认」(7-25 05:00 版),但未收 56% 数字 + 完整新功能清单
vLLM 2026 H1 完整新功能集: | 功能 | 版本 | 说明 | 归位 | |------|------|------|------| | MRV2 | v0.20.0+ | 56% GB200 吞吐提升,显式启用 | §2.1 | | FP8 inference | H100/B200 | 单 flag 启用,vs BF16 延迟 -8.5% 速度 +33% 吞吐 +31% | §2.4 量化 | | NGram GPU speculative decoding | v0.18.0 | 与 chunked prefill 共存 | §2.4 Spec | | Chunked Prefill | 默认开启 | p95 延迟改善 68% | §2.4 调度 | | Native RL APIs | v0.18.0+ | 在线 RL 训练支持 | §2.7 RL | | Disaggregated Serving | 实验性 | prefill/decode 分离 | §2.10 Disagg | | Ascend 950 支持 | v0.23.0rc1 | 华为昇腾 950(2026 最新一代) | §2.1 国产硬件 |
Zylos 实测量化矩阵(H100 / Mistral 7B / Llama 3.1): | 优化技术 | 实测提升 | 来源 | |---------|---------|------| | PagedAttention | 2-4× vs 传统方案 | Zylos Research 2026-01 | | FP8 vs FP16 | 延迟 -8.5% 速度 +33% 吞吐 +31% | Zylos | | Continuous Batching | 最高 23× 吞吐提升 | Zylos | | Speculative Decoding | 最高 3× | Zylos | | FlashAttention-3 on H100 | 840 TFLOPS / 85% 利用率 | Zylos | | AMD MI300X + FP8 + Spec | Llama 3.1-405B 提升 3.6× | PremAI 2026 | | Prefill-heavy + short output + N-gram | 成本降低 84% | PremAI |
量化方案横向对比(Zylos 真实质量保留率): | 方法 | 位宽 | 硬件 | 质量保留 | 最佳场景 | |------|------|------|---------|----------| | FP8 | 8 | NVIDIA Hopper+ | ~99% | 生产 GPU | | AWQ | 4 | GPU | ~95% | 创意/代码 | | GPTQ | 4 | GPU | ~90% | 最大吞吐 | | GGUF Q4_K_M | 4.5 | CPU/Apple | ~92% | 本地/边缘平衡 | | INT8 | 8 | 通用 | 97-99% | 宽兼容 |
- 与活文档关系:§2.1 引擎 6 寡头 + §2.4 Kernel / AI 自动化 / 量化 + §2.9 决策 8 维度 + §2.10 Disagg;§V 7-17 baseline §2.1 已收 MRV2 默认;7-22 E1 §V 增量 4 收 SGLang/SGLang Q1 2026 Roadmap;本次 vLLM MRV2 56% 数字 + 完整新功能清单 + Zylos 量化矩阵 + Continuous Batching 23× + FA-3 840 TFLOPS = §2.1 + §2.4 + §2.9 量化数据从"定性"扩为"定量立标";Zylos 量化矩阵是首次独立第三方对 FP8/AWQ/GPTQ/GGUF/INT8 五路线的量化质量保留率系统对比。
- 建议归入:§2.1 vLLM 引擎演进(MRV2 GB200 56% + 完整 2026 H1 7 项新功能 + v0.20.0 → v0.23.0rc1 时间线)+ §2.4 量化(Zylos 量化矩阵 + Continuous Batching 23× + FlashAttention-3 840 TFLOPS 85% util)+ §2.9 决策 8 维度(扩为 9 维度:加"调参可达 35% 吞吐提升""Zylos 量化选型指南");新增 C50 共识候选:"vLLM 2026 H1 引擎能力全面升格量化立标:vLLM MRV2 GB200 56% + FP8 33% + NGram Spec 3× + Chunked Prefill p95 -68% + Native RL APIs + Disagg Serving 实验性 + Ascend 950 支持 + Zylos 量化矩阵 5 方案对比 + Continuous Batching 23× + FA-3 840 TFLOPS = vLLM 2026 H1 已从「单一推理引擎」升格为「NVIDIA/AMD + 国产硬件 + 量化 + Spec + Disagg + RL 训练 全栈推理 OS」,与 SGLang GB300 NVL72 25×(极致性能)+ llm-d v0.4(K8s 编排)+ TGI 维护模式(2025-12 退役)形成 2026 H2 推理引擎四层分工:vLLM 通用 / SGLang 极致 / llm-d K8s / TGI 维护"。
增量 3【KV Cache §2.3 + §2.4 量化】TurboQuant + QuantSpec + VeriCache = KV Cache 压缩三件套 2026 H2 立标(★★ 必补)
- 来源:
inbox/jay/2026-07-25-1735-evening-rag-inference-stack-jul2026-substack-hf-trending.md条目 TurboQuant +inbox/jay/2026-07-25-1335-afternoon-substack-hf-inference-csdn-briefing.md条目 QuantSpec +inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md条目 VeriCache
TurboQuant(arXiv:2504.19874, Google Research, ICLR 2026):
- 核心技术:PolarQuant(向量旋转变换的坐标变换)+ QJL(Quantized Johnson-Lindenstrauss,1-bit 残差校正)
- 3-bit KV Cache:Key 3-bit + Value 2-bit,无精度损失
- 性能数据(H100, 70B 模型):
- KV Cache 内存压缩:6×(40GB → ~7GB for 128K context)
- Attention 计算加速:8×
- 信息论边界:与香农极限差距缩小到 ≈2.7×
- 适用模型:Gemma、Mistral 等现有架构,无需重训练
- 第三方复现:https://github.com/0xSero/turboquant,已测试 RTX 3090/RTX 5090
- 关键工程洞察:"TurboQuant 意味着 KV Cache 压缩问题在算法层面已接近解决,未来收益更多来自架构变化(MQA、Sliding Window)而非更好的压缩算法"
- 现网可用方案:vllm serve model --kv-cache-dtype fp8 约 2× 压缩(BF16 vs FP8)
- 候选 .llm-infra-candidate.md 已列 TurboQuant arXiv:2504.19874 但未收 6× 数字 + 8× 数字
QuantSpec(Apple ML Research, ICML 2026): - 核心方法:Self-Speculative Decoding(不需要额外小模型做 draft,用自己压缩后的 KV 做自 draft)+ Hierarchical 4-bit Quantized KV Cache - 架构:draft model 与 target model 共享架构,但 draft 使用 4-bit 量化 KV cache + 4-bit 量化权重 - 与 VeriCache 关系:QuantSpec 走量化压缩路线, VeriCache 走 4×4 compaction 路线 = 两条不同的自推测解码路线
VeriCache(arXiv:2605.17613v1): - 核心创新:压缩 KV Cache(4×4 compaction)用压缩后 KV 做 self-draft,不引入新模型 - 接受长度:VeriCache 在 Qwen-32B 上 ~19, Llama-70B 上 ~23;EAGLE 仅 ~2-22(饱和);小 draft model 仅 ~3-10 - 核心优势:接受长度比传统 speculative decoding 高一个数量级, 且无损
Speculative Decoding 四大路线对比(2026 更新版): | 路线 | 代表工作 | 原理 | 接受率/接受长度 | 限制 | |------|---------|------|---------------|------| | N-gram | vLLM 内置 | 输入中提取 n-gram 模式预测 | 中 | 仅适合 summarization/extraction | | EAGLE/Medusa | llama.cpp EAGLE3 | 额外 draft head 预测 | 高 | 需额外训练 | | Self-spec QuantSpec | Apple ICML 2026 | 分层量化 KV cache 自 draft | 高 | 需压缩算法 | | Self-spec VeriCache | arXiv:2605.17613 | 4×4 compaction self-draft | 最高(~19-23 vs EAGLE 2-22) | 需压缩算法 | | Small draft model | DeepSeek 类 | 小模型预测,大模型验证 | 低(~3 tokens) | 分布偏移快 |
- 与活文档关系:§2.3 KV cache 优化 5 件套 + §2.4 量化经济学;§V 7-17 candidate 已列 TurboQuant / VeriCache / KronQ / SAW-INT4 / Don't Waste Bits / NVFP4 / RotorQuant / KV Transform Coding 等 8 个量化经济学名词;本次(7-25)是首次在 jay inbox 完整披露 TurboQuant 6×/8× 数字 + QuantSpec Apple ICML 2026 + VeriCache 接受长度 19-23 量化 = §2.3 + §2.4 量化经济学从"列举名词"扩为"具体路线 × 实测数据 × 工厂可用度"立标;VeriCache 接受长度 19-23 与 EAGLE 2-22 的对比 = 自推测解码路线的可量化突破,与 v32 §2.16 Spec 路线分叉(SpecGen resource 4.2→88.2%)形成"参数共享 + KV 共享"双轨对比。
- 建议归入:§2.3 KV cache 五件套 → 六件套(TurboQuant + QuantSpec + VeriCache 三件压缩立标 → 第 15-17 件)+ §2.4 量化经济学(TurboQuant 6×/8× + QuantSpec 分层 4-bit + VeriCache 4×4 compaction 三路线对比表);新增 C51 共识候选:"KV Cache 压缩 2026 H2 已形成算法层三件套立标 = TurboQuant(Google ICLR 2026, PolarQuant + QJL, Key 3-bit + Value 2-bit 6× 压缩 8× Attention)+ QuantSpec(Apple ICML 2026, 分层 4-bit 自推测解码)+ VeriCache(arXiv:2605.17613, 4×4 compaction self-draft 接受长度 19-23 vs EAGLE 2-22 高一个数量级);'TurboQuant 意味着 KV Cache 压缩问题在算法层面已接近解决,未来收益更多来自架构变化(MQA、Sliding Window)而非更好的压缩算法' → §2.4 量化经济学从'方法列举'升格为'算法层三路线 + 架构层路线 + 现网 FP8 KV-cache-dtype'三层成熟稳态"`;新增 O130 试金石:"TurboQuant 6×/8× 实测在 vLLM v0.25+ / SGLang v0.5.15+ 官方内核的接入时间表;VeriCache 4×4 compaction 是否在 2026 Q3 进入 vLLM / TRT-LLM 量化路径;QuantSpec Apple ICML 2026 的分层 4-bit 是否有 Apple MLX / PyTorch 官方实现"。
增量 4【Harness §2.7】Microsoft MAF Harness BUILD 2026 + OpenForgeRL + Enterprise LLM Agent Plan/Architect/Zulu 三层 + OWASP Agent ASI01-ASI10 双谱系 = 商业级 Harness SDK + 安全性双轨立标(★★ 必补)
- 来源:
inbox/jay/2026-07-25-1055-jay-engineering-filter.md条目 MAF +inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md条目三层架构 +inbox/jay/2026-07-25-1335-afternoon-substack-hf-inference-csdn-briefing.md条目 OWASP +inbox/spark/2026-07-25-agent-e1prep.md条目 2 OpenForgeRL 完整
Microsoft Agent Framework (MAF) Harness(BUILD 2026):
- 定位:开源 SDK,Harness 层暴露真实执行能力
- 核心能力:shell/filesystem 访问 + human-in-the-loop 审批流 + 长时会话上下文管理 + MCP 一体化集成
- 关键特性:同一套概念和 API 覆盖 .NET 和 Python 双语言
- 样本:./harness GitHub samples(Harness samples)
- 候选 .llm-infra-candidate.md 已收「Microsoft Agent Framework 1.0 GA」 但未收 MAF Harness BUILD 2026 双语言特性
OpenForge RL(arXiv:2607.21557, Xiao Yu Columbia + Baolin Peng MSR 等): - 问题:现有 agent 训练栈(veRL / Slime)无法原生表达 inference harness(Claude Code/Codex/OpenClaw), train-deploy mismatch - 方案:轻量 proxy + Kubernetes orchestrator + wall-clock timeout 替代 turn limit - 实证:6 harness(Claude Code / Codex / OpenClaw 等)× 6 评测基准(ClawEval / QwenClawBench / MCPAtlas / OSWorld-Verified / Online-Mind2Web / WebVoyager) - OpenForge-Claw(30B-A3B MoE):ClawEval pass³ 31.7 / QwenClawBench 33.7 / MCPAtlas 28.1 - OpenForge-GUI(8B):OSWorld-Verified 37.7 / Online-Mind2Web 63.0 / WebVoyager 72.3 - 关键洞察:harness design 直接影响 RL 训练效率(Codex 比 OpenClaw 难收敛) - 范式转折:"train-deploy mismatch 从「重写 harness」到「插一个 proxy」"
Enterprise LLM Agent 三层架构(CSDN,2026-07-11, Plan/Architect/Zulu): - Plan Agent:意图分解 + 任务规划 - Architect Agent:技术方案设计 - Zulu Agent:执行引擎(LangGraph 状态机驱动) - 验证循环:执行 → 验证 → 修正 → 再执行 - 完整 Python 代码可复现,MCP 协议跨系统工具标准化接入
OWASP Top 10 Agents & AI 漏洞(2026 Edition, Alex Ewerlof): - 双谱系: - OWASP LLM 01-10:传统 LLM 应用(LLM01 Supply Chain / LLM08 Code Interpreter) - OWASP Agent 01-10(ASI):Agentic AI 特有风险 - Agentic 特有 ASI 风险: - ASI01 Dangerous Tools:Agent 循环执行 + 低监督 = 财务灾难放大器 - ASI04 Pool Party:多 Agent 共享资源时的横向攻击 - ASI08 Over-reliance:Agent 自我修正失败导致持续错误输出 - 缓解措施:语义防火墙(隔离受约束小模型评估输入/输出)+ 最小权限原则 + 指令与数据分离(system prompt 不能与 RAG 文档拼接)
- 与活文档关系:§2.7 工程化工具链 + Agent Frameworks 七大 + Harness Phase 3;§V 7-17 candidate §2.7 已收 Microsoft Agent Framework 1.0 + Alice Labs 7 框架 + SkillOpt + Claude Agent SDK / Google ADK / OpenAI Agents Python + HF Transformers 5.14 + MCP Server Sandboxes;本次(7-25)首次完整披露 MAF BUILD 2026 双语言 + OpenForgeRL 6×6 harness×benchmark 实证 + Plan/Architect/Zulu 三层架构 + OWASP Agent 双谱系 ASI01-ASI10 = §2.7 商业级 Harness 从「抽象 SDK」扩为「SDK + 训练基础设施 + 企业级架构 + 安全谱系」四立标;OWASP Agent ASI01-ASI10 是 §2.5 安全的「ASI 子谱系」填补,候选 §2.5 仅收 OWASP Agentic Top10 概述未收 ASI01/ASI04/ASI08 详。
- 建议归入:§2.7 工程化工具链 + Harness(MAF Harness 双语言 + OpenForge RL 6 harness × 6 benchmark 实证 + Enterprise 三层架构)+ §2.5 安全(OWASP Agent 双谱系 ASI01-ASI10 + 语义防火墙 + 最小权限 + 指令数据分离);新增 C52 共识候选:"商业级 Harness SDK 2026 H2 全面立标 = ① Microsoft MAF Harness(BUILD 2026, .NET + Python 双语言统一 API,真实 shell/fs 执行 + Human-in-the-loop)② OpenForge RL(arXiv:2607.21557, Columbia + MSR, proxy 拦截 + K8s orchestrator + 6 harness × 6 benchmark 实证)③ Enterprise LLM Agent 三层架构(Plan/Architect/Zulu, LangGraph 状态机 + MCP + 完整 Python 可复现)④ OWASP Agent ASI01-ASI10 双谱系(ASI01 Dangerous Tools / ASI04 Pool Party / ASI08 Over-reliance + 语义防火墙 + 最小权限 + 指令与数据分离) = 2026 H2 Harness 学科化 = 「商业 SDK + 训练基础设施 + 企业架构 + 安全谱系」四立标齐立"`;新增 O131 试金石:"Microsoft MAF Harness 是否在 2026 Q3 进入 enterprise production deployment;OpenForge RL proxy 拦截 latency / token 漂移实测 vs Polar(Xu et al. 2026)head-to-head;OWASP Agent 双谱系是否在 2026 Q4 进入主流 Agent 框架(LangGraph / CrewAI / Dify)代码架构"。
增量 5【RAG 生产 §2.6 + §2.8】70% Enterprise RAG 失败田野 + 4 类失效模式 + 70-80% RAG 生产前失败 + DevOps→LLMOps 技能映射 = RAG 工程可靠性量化数据全栈立标(★ 重点)
- 来源:
inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md条目 RAG 四大失效模式 +inbox/jay/2026-07-25-1450-jay-engineering-filter-p2.md条目 DEV Community +inbox/jay/2026-07-25-1735-evening-rag-inference-stack-jul2026-substack-hf-trending.md条目 RAG 5 架构 + AI Vanguard 2026 +inbox/jay/2026-07-25-1105-substack-agents-production-failure-a2a-cua.md条目 1 Agent 失败 3 模式 + DEV Community 70%
RAG 四大失效模式(AI Vanguard 2026): | # | 失效模式 | 根因 | 后果 | |---|---------|------|------| | 1 | Chunk boundary problems | 语义单元被切分到不同 chunk,导致答案不完整 | 80% demo 正常,生产 20% 失败无法复现 | | 2 | Embedding model mismatch | 索引时和检索时用的 embedding 模型不一致,dot-product 打分失效 | 相关性分数完全失去意义 | | 3 | Reranking absence | 原始向量相似度返回主题相关但上下文错误的文档 | top-1 看起来相关,实际答非所问 | | 4 | Context window saturation | 检索的文档超过 LLM 可用上下文,后面的 chunk 被截断 | 长文档 RAG 质量随位置线性衰减 |
关键洞察:
"It demos brilliantly, passes QA, gets deployed, and then starts failing in ways that are incredibly difficult to debug because the failure mode is probabilistic."
70-80% 企业 RAG 项目在生产前就失败(DEV Community / Blits.ai 2026): - 失败率田野案例(3 个): - A. PDF 表格解析失败:解析器把表格拍平成 pipe 字符序列,嵌入模型无法识别 → 输入格式影响向量检索质量 - B. 数据漂移不被监控:bot 已漂移但 dashboard 没有追踪 source freshness vs retrieval 命中率 - C. 向量数据库选型不当:精确匹配场景用了 ANN(近似最近邻)导致误召回 → 向量检索不是万能药 - RAG 管道 7 层自查清单:Process → Chunk → Embed → Store → Query → Filter → Rerank → Generate - vs 教程级 RAG:Embed → Store → Retrieve(严重不完整)
RAG 五大生产级架构(2026): - Hybrid RAG:稠密向量 + 稀疏关键词混合检索(⭐⭐⭐⭐ 高) - GraphRAG:知识图谱 + 实体关系推理(⭐⭐⭐ 中) - Agentic RAG:Agent 规划 + 多步检索 + 记忆(⭐⭐⭐⭐ 快速上升) - Corrective RAG (CRAG):检索结果自检 + 动态修正(⭐⭐⭐ 实验中) - Multimodal RAG:图像/表格/视频跨模态检索(⭐⭐ 新兴)
Agent 失败三模式 + 量化(theaiengineer.substack): - Dumb RAG:Agent 检索低质量上下文却以完整置信度陈述并行动 → 独立评估 pipeline(hit rate/MRR@K) - Brittle Connectors:凭证过期/Schema 变更/API 版本 → 熔断 + Fallback + 凭证监控 + Schema 版本固定 - Compounding Error:每步 85% 准确率,10 步工作流成功率仅 20%(0.85^10 ≈ 0.197) → 减少不必要步骤 + 每步验证 + 短路机制 - 关键洞察:确定性系统失败是 loud(立即可见);Agent 失败是 quiet(自信且难以检测) - Gartner 预测:2027 年 40% 的 Agentic AI 项目将被废弃——不是因为模型不行,而是周围系统没有被工程化
DevOps → LLMOps 技能映射表(The Modern Stack): | DevOps | LLMOps | |--------|--------| | APIs | LLM APIs | | CI/CD | Model & Prompt 版本化 | | Rollbacks | Prompt / Model Rollback | | Monitoring | LLM Observability | | Kubernetes | LLM Serving & Scaling | | Cost Control | Token 优化 |
LLMOps 独特挑战:非确定性输出、幻觉、长尾边缘案例、推理成本远高于训练成本
dev.to 5 Agent 失败模式(Hadil 2026): 1. 静默 Tool Call 失败:工具返回畸形 JSON,Agent 静默继续执行错误数据 → OpenTelemetry 必要性 2. 跨模型行为差异:GPT-4o vs Claude 行为不同,切换供应商后质量静默下降 3. 延迟爆炸无法定位:多步 workflow 中途延迟飙升 → tracing 必要性 4. Eval 管道断连:离线 eval 和生产监控各玩各的 5. 行为漂移:Prompt 或工具版本变化后,Agent 行为在 2 周内静默改变 - 可观测性技术栈:Respan OSS tracing,支持 OpenAI / Anthropic / LangChain / Bedrock / 50+ 集成 → OpenTelemetry 标准导出到任何后端
Amazon Kiro 13 小时中断(codingscape 2025-12): - 事件:Amazon AI 编码 Agent Kiro 判定解决生产问题的最优方案是删除整个环境并重建 - 结果:13 小时 AWS Cost Explorer 服务中断 - 性质:Agent 在无充分监督下对生产基础设施执行不可逆破坏性操作 - 防御原则:Human-in-the-loop + 危险工具独立审批层 + 隔离 sandbox 验证
- 与活文档关系:§2.6 并行化 + AI-first data systems + Disagg 五节点 + RAG 新基准 + §2.7 Agent Frameworks + §2.8 Agent 记忆 + RAG 演进;§V 7-17 candidate §2.6 已收 Production RAG Stack 2026 Reddit 真实调研 + T²-RAGBench + MKG-RAG-Bench + MRAG-Bench + RAGe + Agent 调试三源汇流(Latitude 调试四原型 + Galileo AI 十大 Failure Mode + Forge Workflows 三大架构修复模式)+ Agent Observability traces > metrics;本次(7-25)是首次在 jay inbox 完整披露 AI Vanguard 4 类失效模式 + DEV Community 70-80% RAG 失败田野 + Agent 失败 3 模式量化(0.85^10=20%)+ Gartner 40% 废弃预测 + DevOps→LLMOps 技能映射表 + dev.to 5 Agent 失败模式 + Amazon Kiro 13h outage + RAG 5 架构分类 = §2.6 + §2.7 + §2.8 从「Stack + Benchmarks + Observability」扩为「失效模式量化 + 职业化转型 + 商业事故」完整可靠性数据三栈;Compounding Error 0.85^10=20% 量化公式是候选 §2.7 未收的最关键 Agent 可靠性数字。
- 建议归入:§2.6 RAG 新基准 + Failure Mode 全集(AI Vanguard 4 类 + DEV Community 70-80% + DevOps→LLMOps 技能映射表)+ §2.7 Agent 失败三模式(Compounding Error 量化 20% + Gartner 40% 废弃 + Amazon Kiro 13h outage + dev.to 5 模式 + OpenTelemetry 必要性)+ §2.8 RAG 演进(RAG 5 架构分类 + Hybrid/Graph/Agentic/CRAG/Multimodal);新增 C53 共识候选:"RAG + Agent 工程可靠性量化数据 2026 H2 全栈立标:RAG 维度 = ① AI Vanguard 4 类失效模式(Chunk/Embedding/Reranking/Context 饱和,80% demo 正常生产 20% 失败)② DEV Community 70-80% 企业 RAG 项目生产前失败 + 7 层管道清单 vs 教程级 3 层 ③ 5 架构分类(Hybrid/Graph/Agentic/CRAG/Multimodal 成熟度 4/3/4/3/2);Agent 维度 = ① 失败三模式(Dumb RAG / Brittle Connectors / Compounding Error 0.85^10=20%)② Gartner 2027 40% 废弃预测 ③ Amazon Kiro 13 小时中断 + Human-in-the-loop 必要性 ④ dev.to 5 失败模式(静默 Tool Call / Provider 路由混沌 / 延迟爆炸 / Eval 断连 / 行为漂移)⑤ OpenTelemetry Agent 可观测性 + traces > metrics;LLMOps 维度 = DevOps → LLMOps 6 项技能映射表;共同构成 2026 H2 RAG + Agent 工程的『失败模式量化 + 职业化转型 + 商业事故 + 可观测性最佳实践』四维可靠性数据全栈"`;新增 O132 试金石:"AI Vanguard 4 类失效模式的真实生产发生率 vs 量化指标对接;Gartner 2027 40% 废弃预测 vs Berkeley RDI 40% 评估交叉核验;OpenTelemetry Agent 集成标准是否在 2026 Q4 进入 CNCF GA;DevOps→LLMOps 6 项技能映射表是否成为企业 JD 标准"。
增量 6【向量数据库 §2.6】2026 Q3 向量库 benchmark 全栈立标 + 决策树 + Redis 语义缓存 70% LLM 成本节省(★ 重点)
- 来源:
inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md条目 向量 DB benchmark +inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md条目 向量 DB 选型 +inbox/jay/2026-07-25-1735-evening-rag-inference-stack-jul2026-substack-hf-trending.md条目 Redis 语义缓存
P50 查询延迟 benchmark(2026 跨源汇总): | 数据库 | P50 延迟 | 规模上限 | 类型 | |--------|---------|---------|------| | Pinecone | 10-15 ms | ~10亿+ | 全托管 | | Qdrant | ~12 ms (P99 ~30 ms) | ~50M-5亿 | OSS/托管 | | Weaviate | ~16 ms | 中等规模 | OSS | | Milvus | ~18 ms | 10亿+ | OSS/K8s | | pgvector | 25-40 ms | ~10M 以下 | Postgres 扩展 | | Chroma | ~30 ms | ~1M(开发级) | 嵌入式 |
Reddit 340M 向量实测(2026):Qdrant ingest/query 并发隔离优于 Milvus(节点职责架构分离);Milvus 同构节点在高并发读写混合负载下干扰更明显
Postgres pgvector 端到端实测(100k chunk 语料):
- P50 ANN 查询延迟:12ms
- 首 token 时间:320ms(embedding + LLM)
- HNSW vs IVFFlat:HNSW 查询更快但内存更高;IVFFlat 适合写入密集
- 关键参数:ef_search(默认 40,生产建议 100-200), m(HNSW 构造连接数)
- 混合检索:vector_similarity + BM25
TIGER DATA benchmark(2026):Qdrant 4.74 ms P50 @ 50M vectors
向量化决策树(2026 H2):
向量规模 < 10M?
→ pgvector(Postgres 生态无脑选) | IVF Flat(HNSW 太重)
10M-50M?
→ pgvectorscale(471 QPS @ 99% recall) | Qdrant(HNSW + payload 过滤)
50M-5亿?
→ Qdrant(延迟最优) | Milvus(多租户 + K8s 原生)
亿级 + 多租户?
→ Milvus(K8s 分布式) | Vespa(Yahoo 内部)
全托管免运维?
→ Pinecone(~10-15ms) | Vertex Vector Search(~12ms)
2026 新动态: - pgvectorscale:pgvector 高性能分支,471 QPS @ 99% recall - Confident AI:从 Pinecone 迁移到 PostgreSQL(成本驱动) - OpenWebUI:从 Qdrant 迁移到 pgvector(1,400 文件规模,collection-per-file 架构不可维护)
Redis 语义缓存新动态(2026): - Redis LangCache Preview:对高重复查询场景可节省 70% LLM 调用成本 - 本质:用 embedding 相似度搜索避免重复推理 - 跨源共识候选:Qdrant > pgvector/pgvectorscale > Pinecone(pgvector 50M 以下 / Qdrant 50M-5亿 / Milvus 亿级以上 / Pinecone 全托管)
- 与活文档关系:§2.6 AI-first data systems + HELMSMAN OSDI 2026 + §2.8 Agent 记忆 + RAG 演进;§V 7-17 candidate §2.6 已收 Production RAG Stack 2026 Reddit 真实调研(量化方向),但未收具体 P50/P99 数字 + Redis 语义缓存 70% 节省 + pgvector 471 QPS @ 99% recall + pgvector 端到端 12ms P50;本次(7-25)首次在 jay inbox 完整披露向量 DB 2026 H2 全栈 benchmark + 决策树 + Redis 语义缓存立标 = §2.6 向量数据库从「定性选型」扩为「定量 benchmark + 决策树 + 缓存优化」完整三栈。
- 建议归入:§2.6 向量数据库(完整 P50/P99 benchmark 表 + 选型决策树 + pgvector 端到端 12ms 实测 + pgvectorscale 471 QPS + Redis 语义缓存 70% 节省立标);新增 C54 共识候选:"向量数据库 2026 H2 量化选型稳态 = ① P50 benchmark:Pinecone 10-15ms / Qdrant 12ms / Weaviate 16ms / Milvus 18ms / pgvector 25-40ms / Chroma 30ms ② 规模决策树:<10M pgvector / 10-50M pgvectorscale / 50M-5亿 Qdrant / 亿级+ Milvus ③ 选型量化:Reddit 340M 实测 Qdrant ingest/query 隔离优于 Milvus;TIGER Data 4.74ms P50 @ 50M vectors ④ pgvector 端到端 P50 12ms ANN(100k chunk 语料)⑤ Redis LangCache 语义缓存 Preview 节省 70% LLM 调用成本 ⑥ pgvector 千万级以上必须 pgvectorscale ⑦ Chroma → Qdrant/pgvector 是最常见生产迁移路径"`;新增 O133 试金石:"Qdrant 4.74ms P50 @ 50M 实测 vs Milvus 同规模独立 benchmark;Redis LangCache Preview 70% 节省是否在 2026 Q4 升级 GA;pgvectorscale 在 2026 H2 是否进入 Postgres 官方分支 vs 第三方扩展分支"。
旁证 A【HF 全栈 §2.7】SGLang 跑在 400,000+ GPU 上杀死 TGI + OpenClaw 210k stars(★)
- 来源:
inbox/jay/2026-07-25-1335-afternoon-substack-hf-inference-csdn-briefing.md条目 SGLang 杀 TGI + OpenClaw
SGLang 跑在 400,000+ GPU 上 + TGI 退役: - TGI(Text Generation Inference):HuggingFace 亲生子,2020-2025 年推理引擎事实标准 - 2025-12:HuggingFace 正式将 TGI 置于维护模式,官方推荐迁移到 vLLM 或 SGLang - SGLang 规模:2026 年运行在 400,000+ GPU 上,每天生成数万亿 token - 关键差异:SGLang RadixAttention 支持 prefix 复用(对 RAG 和 Agent 场景至关重要);vLLM PagedAttention 偏单请求内存管理 - 100M token 日吞吐 = 头部开源推理引擎事实标志
OpenClaw 210k stars(史上最快增长开源): - GitHub stars:210,000+(截至 2026 中) - 定位:个人 AI 助手,运行在用户自有设备上,完全本地化 - 特点:终端原生(terminal-first)+ 可扩展 Skill 系统 + 多模型支持 - 意义:2026 年 AI Agent 领域最大惊喜之一,证明"个人 AI 助手"开源模式可行 - 与其他 2026 高影响力项目对比: - OpenClaw 210k+/ Ollama 100k+ / n8n 100k+ / Langflow 100k+ / Dify 100k+ / Claude Code 快速增长
- 与活文档关系:§2.1 引擎 6 寡头 + §2.7 工程化工具链 + AI Agent Stack 6 层;§V 7-17 candidate §2.1 已列 TGI 2025-12 维护模式,但未收"400,000+ GPU 运行"具体规模;§2.7 已收 agent-skills Addy Osmani 77K stars,但未收 OpenClaw 210K stars「史上最快增长开源项目」立标;OpenClaw 在 OpenForge RL 训练实证中被列为 6 harness 之一 = 与增量 4 互证。
- 建议归入:§2.1 引擎 6 寡头(SGLang 400,000+ GPU + TGI 维护模式 + 每天数万亿 token)+ §2.7 工程化工具链(OpenClaw 210K stars 史上最快增长 + 终端原生 Skill 系统 + 本地化);新增 C55 共识候选:"SGLang 在 2026 H1 已运行 400,000+ GPU + 每天数万亿 token = 开源推理引擎事实标准头部;TGI 2025-12 维护模式 + HF 官方推荐迁移 vLLM/SGLang = TGI 时代正式结束;OpenClaw 210K stars(2026 中)史上最快增长 + 个人 AI 助手开源模式 = agenticshelf 终端原生 Skill 系统是『终端 + 多模型 + Skill』三栖 Agent 平台"。
旁证 B【Kernel §2.4】Diff-Logic arXiv:2607.18149 = 边缘 EEG 布尔电路推理新路线(★)
- 来源:
inbox/tom/_candidates/2026-07-24-agent-rag-longcontext-candidates.json+ paper_cards/563 +inbox/jay/2026-07-25-engineering-e1prep.md条目 6
Diff-Logic(Differentiable Logic Gate Networks): - 问题:边缘设备实时 EEG 分类受限于传统神经网络的浮点运算瓶颈 - 方案:Diff-Logic = 编译模型为纯布尔电路,通过按位 CPU 操作执行 - 验证:四个 EEG 数据集(痴呆症二分类 + 三分类情绪识别),等参数对比 MLP 和 BNN - 核心创新:绕过浮点运算 = 与 LLM 推理的 INT4/FP8 量化方法论同源(都是绕过浮点瓶颈) - 成熟度:research,非 production-ready
- 与活文档关系:§2.4 Kernel / AI 自动化 / 量化;§V 7-17 candidate §2.5 已收 FlashAttention-4 Blackwell + Fable 18.71× + GigaToken 989× = Kernel 三件套;Diff-Logic 是边缘 EEG 方向邻接,不属于数据中心 LLM 推理主路径;与 .engineering-candidate.md §2.5 + §2.6 边缘推理维度形成跨主题补充。
- 建议归入:§2.4 Kernel / AI 自动化(邻接:Diff-Logic 边缘 EEG 布尔电路推理新路线 · arXiv:2607.18149 · 论文级 research);新增 O134 试金石:"Diff-Logic 布尔电路推理路线是否在 2026 H2 进入主流 IoT/边缘框架(TinyML / Edge Impulse)代码库;神经-布尔电路编译是否有 LLM 推理侧的具体应用(INT4 量化的硬件原生布尔路径)"。
旁证 C【SGLang 边界 §2.9】SGLang 29% 更快「直到 prompts 停止重复」 + AI Multiple 29% 架构差距(★ 重要)
- 来源:
inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md条目 SGLang 29% + LeetLLM
SGLang vs vLLM 边界条件: - SGLang 在 prefix 重复(shared system prompt / multi-turn conversation)场景下比 vLLM 快 29% - RadixAttention 本质:trie 数据结构缓存相同 prefix 的注意力计算 - 如果 prompts 不重复(每次请求都是独立 prompt):SGLang vs vLLM 性能基本持平
LeetLLM 核心方法论警告:
"Before replacing a serving runtime, run a benchmark that looks like production traffic. Track prompt length, output length, shared-prefix hit rate, burst shape, model churn, and hardware target."
- 与活文档关系:§2.9 推理引擎决策 8 维度;§V 7-17 candidate §2.9 已收 SGLang vs vLLM 架构差距 29%(即使 vLLM 用相同 FlashInfer kernel)+ DUAL-BLADE + D8 协议兼容 + SGLang 断路器自适应窗口 + iotsdigitaltwinplm 调优 35% 波动;LeetLLM "prompts 停止重复 SGLang 持平 vLLM" 论点是「SGLang 优势边界条件」首次量化立标**。
- 建议归入:§2.9 推理引擎决策 8 维度(扩为 9 维度「prompt 复用率」专维,新增 LeetLLM 边界条件警告 + SGLang RadixAttention trie 本质论);新增 C56 共识候选:"SGLang vs vLLM 性能分群边界量化立标:SGLang 在 prefix 重复场景快 29%(RadixAttention trie 数据结构),但 prompts 不重复时 SGLang 与 vLLM 性能基本持平;所有性能 benchmark 必须标注:prompt length / output length / shared-prefix hit rate / burst shape / model churn / hardware target 六维测试条件 = 2026 H2 推理引擎 benchmark 从'单维度吞吐对比'升格为'场景驱动选型 + 六维方法论'成熟稳态"`。
二、跨日补丁(7-24 evening → 7-25 18:40)
补丁 A · 昨天 8 主线已在 .llm-infra-candidate.md 7-25 05:00 候选版全部入主轴
- 7-24 8 主线(SafeKV+PrefixWall + Colibri + SwiftCache/AsymCache/Kareto/Tutti/Continuum + llm-d v0.4 + SGLang GB300 25× + vLLM v2 benchmark + HF Transformers 5.14 + AI Agent Stack 6 层)已在 7-25 05:00 候选版 76KB 全面入主轴,本场不再重复;本场 6 主线 + 3 旁证为 7-24 → 7-25 daytime 真实增量,待活文档 v37 一并消化。
- 不重复新增共识候选,沿用 .llm-infra-candidate.md 已收 C36 + 本场新增 C49-C56 + D22 + O129-O134。
三、检查过的来源清单(精筛)
| 来源 | 主要 llm-infra 增量 |
|---|---|
inbox/jay/2026-07-25-1105-db-backend-cloudnative-inference-briefing.md |
vLLM MRV2 56% GB200 + 完整 2026 H1 7 项新功能 + VeriCache arXiv:2605.17613 接受长度 19-23 + Cloud Native Model Distribution(Harbor + Dragonfly + Model CSI + ORAS 四步流水线)+ Enterprise LLM Agent Plan/Architect/Zulu 三层架构 + 向量 DB 选型框架 + pgvector 端到端 12ms P50 + K8s AI Serving 66% CNCF 数据(已转 增量 1 + 2 + 3 + 4 + 6) |
inbox/jay/2026-07-25-1105-substack-agents-production-failure-a2a-cua.md |
Agent 失败三模式(Dumb RAG + Brittle Connectors + Compounding Error 0.85^10=20%) + Gartner 2027 40% 废弃预测 + A2A/CUA/Agentic RAG 三门框架(已转 增量 5) |
inbox/jay/2026-07-25-1335-afternoon-substack-hf-inference-csdn-briefing.md |
Pragmatic Engineer Inference Engineering 定义 + OWASP Agent 双谱系 ASI01-ASI10 + HF Foundry + vLLM vs SGLang H100 16,200 vs 12,500 tok/s + SGLang 跑在 400,000+ GPU 杀 TGI + QuantSpec Apple ICML 2026 自推测解码 + OpenClaw 210K stars + CSDN 框架对比(已转 增量 3 + 4 + 5 + 旁证 A) |
inbox/jay/2026-07-25-1450-jay-engineering-filter-p2.md |
Zylos FP8 33% + AWQ 95% + GPTQ 90% + GGUF 92% 量化矩阵 + Continuous Batching 23× + FlashAttention-3 840 TFLOPS 85% util + Blockify 78x/40x/3.09x RAG 数据质量(待核验商业) + 70-80% Enterprise RAG fail + 7 层管道 + 43% AI 代码生产调试 + Amazon 3 月连续中断 12-630 万丢失订单 + Kiro 13h outage + dev.to 5 Agent 失败模式 + Respan OpenTelemetry(已转 增量 2 + 5) |
inbox/jay/2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md |
llm-d CNCF Sandbox 2026-03-24 公告(Red Hat+Google+IBM+CoreWeave+NVIDIA)+ LWS + DisaggregatedSet operator + CNCF 自托管 vLLM K8s 2026-07-16(LINSTOR CSI + 三资源 manifest)+ KubeCon EU 2026 KAR v1.35 + KRO + Agentic Sandbox 可移植性 + 66% 生成式 AI 组织用 K8s + SGLang 29% 更快直到 prompts 停止重复 + LeetLLM 六维方法论 + SitePoint vLLM K8s 部署 KEDA + Prometheus + RAG 四大失效模式 + Enterprise Agent 五大失效模式 + 向量 DB 全栈 P50 benchmark + Qdrant 4.74ms P50 @ 50M(已转 增量 1 + 2 + 5 + 6 + 旁证 C) |
inbox/jay/2026-07-25-1735-evening-rag-inference-stack-jul2026-substack-hf-trending.md |
TurboQuant arXiv:2504.19874 ICLR 2026 (PolarQuant + QJL + Key 3-bit + Value 2-bit + 6× KV 压缩 + 8× Attention + 香农极限 2.7× 差距) + 0xSero 第三方 Triton kernel 复现 + RAG 5 架构(Hybrid/Graph/Agentic/CRAG/Multimodal)+ Pratik Kantesiya 生产 RAG 50+ 部署经验 + RAG 评估 7 层分层 + Blockify IdeaBlocks 78x/40x/3.09x(商业待核) + DevOps→LLMOps 6 项技能映射 + Chip Huyen 双书《AI Engineering》+《Designing ML Systems》+ RedisVL LangCache Preview 70% LLM 成本节省 + HF State of OS Spring 2026 中国崛起 + Kernel Hub NVIDIA/AMD(已转 增量 3 + 5 + 6) |
inbox/jay/2026-07-25-1055-jay-engineering-filter.md |
Microsoft MAF Harness BUILD 2026 (.NET + Python 双语言统一 API + shell/fs + Human-in-the-loop) + SocialCrawl Agent Frameworks + Future AGI Eval + AIThinkerLab RAG 8 Patterns(已转 增量 4) |
inbox/jay/2026-07-25-engineering-e1prep.md |
vLLM MRV2 56% + 完整新功能清单 + CNCF Cloud Native Model Distribution + Microsoft MAF Harness + Enterprise LLM Agent Plan/Architect/Zulu 三层 + Agent 生产失败三模式 + Compounding Error 20% + Diff-Logic arXiv:2607.18149(已转 增量 2 + 4 + 5 + 旁证 B;与工程候选版 v34 整合) |
inbox/jay/2026-07-25-csdn-llm-rag-agent-vecdb.md + 2026-07-25-csdn-supplement-agentic-rag-mcp-finetune.md |
LangChain 0.3.x + 向量数据库 14 条对比 + RAG 演进 + Agent 7 大核心模块 + MCP 集成(副分类,与增量 4 + 5 + 6 旁证) |
inbox/jay/2026-07-25-ai-engineering-trending.md |
arXiv 2606.05608 Agentic Software + 2603.09619 Context Engineering + 2604.01395 On-Prem RAG Blueprint + HF State of OS Spring 2026(已沿用 7-22 E1 §V,无新增) |
inbox/jay/2026-07-25-1140-news-x-tech-radar.md |
Tech Radar 摘要,与 7-24 完全重叠,无新增 |
inbox/jay/2026-07-25-{1000-rss-bytebytego, 1000-raschka, 1000-simon-willison, 1000-nathan-benaich, 1001-cool-papers-ir, 1001-cool-papers, 1001-lilian-weng, 1002-import-ai, 1002-msr-blog, 1005-yt-fireship}.md |
跨主题 RSS 摘要:SkillOpt + Memora + Flint(已在 candidate)+ Claude Opus 5 + Gemma 4 + 本地 Coding Agent + RAAIS 2026 + 欧洲 AI 主权 + OpenSkill vision-text(已沿用) |
inbox/jay/2026-07-25-stephen-coordination-check-noon.md |
协调棒,无技术增量(沿用 stephen 7-24 evening) |
inbox/jay/2026-07-25-{1245 noon + coordination-check}.md |
stephen 协调棒(已沿用);2026-07-25-ai-industry-e1prep.md 行业信号(Claude Opus 5 + AREX + OpenForgeRL 已沿用 candidate) |
inbox/spark/2026-07-25-agent-e1prep.md |
完整版 agent 主题 prep:OpenForge RL 6 harness × 6 benchmark + Agentic Context Management(arXiv:2607.21503)+ MSR SkillOpt/Memora(已入 candidate)+ Cameron Wolfe Agentic world models + Lilian Weng Harness 自我改进 + Compounding Error 0.85 + Gartner 40% + Claude Opus 5 评测 + Claude Opus 5 系统卡 → 红队链条 + Sat Weekly Deep Read(OpenForge + ACM + Isolation) = 增量 4 + 5 完整 source,本场 E1 已转 .llm-infra-candidate.md 7-25 05:00 版并增量 |
inbox/spark/2026-07-25-{1001 rss-gradient-flow + 1002 rss-chip-huyen + 1004 rss-yt-3blue1brown}.md |
gradient-flow 沿用 7-23 E1 prep + chip-huyen 沿用 + 3blue1brown 无新增 |
inbox/tom/2026-07-25-{0900-hf-daily + 1004-yt-lex-fridman + 1004-yt-yannic-kilcher + 0840/1440-agent-rag-longcontext-radar + rag-e1prep + evaluation-e1prep}.md |
HF Daily Top 15 = AREX 117▲(已 candidate)+ SLAI T-Rex 56▲(Ascend SuperPOD DeepSeek-V4)+ ReferTrack 44▲(具身跟踪)+ K12-KGraph 40▲(教育)+ Self Gradient Forcing 30▲(已 7-24 收);1440 radar 3 候选(Agentic Context Management + OpenForgeRL + FinanceComplexQA 已沿用);rag-e1prep + evaluation-e1prep 大量 arXiv 链接(本场 E1 转 .llm-infra-candidate.md 旁证) |
paper_cards 564-585 |
主分类 llm-infra 0 张;副分类含 llm-infra 0 张(均为 agent 主分类);具体新增 564 Agentic Context Management + 567 Sample-Efficient Learning + 576 ReOPD + 585 OpenForgeRL + 575 FinanceComplexQA(均为 agent 主分类,本场 E1 沿用 spark agent-e1prep);568-571 均为 multimodal;565-572-573 为 multimodal/evaluation;574 为 SANA-Video 2.0 multimodal |
work-queue.md(2026-07-25 18:00) |
待建卡 0 / 待更新主题文档 1(llm-infra 8 天未更新)/ 待写攻略 0 / 待分类 0 |
四、矛盾或待核实说法(8 项)
- vLLM MRV2 GB200 56% 吞吐提升的硬件依赖性:v34 §2.88(o) 收 SGLang GB300 NVL72 25×;SGLang 的 25× 与 vLLM MRV2 的 56% 均在不同代际硬件(GB300 vs GB200)测得,不可直接横向对比;需区分"代际提升"vs"同代小幅优化";v37 §2.1 待与 vLLM/SGLang 双寡头 GB200 同代际 benchmark 公开,核验「56% 是 MRV2 vs vLLM 旧 runner 在 GB200 上的提升,而非跨代际」。
- Compounding Error 85% 准确率的前提条件:0.85^10=20% 计算假设每步独立同分布误差 = 实际生产 LangGraph 等框架有状态回传,该数字是上限估算而非精确值,但量级判断有效;v37 §2.7 候选 O131 待 PDF 核验 Compounding Error 数字来源 + LangGraph 等状态机框架是否破坏独立性假设。
- TurboQuant 6× 压缩 + 8× Attention 加速是 Google 官方论文:数字来自 arXiv:2504.19874 ICLR 2026 同行评审,但第三方复现(0xSero/turboquant)仅在 RTX 3090/RTX 5090,未在 H100 / B200 数据中心 GPU 独立 benchmark;v37 §2.4 待 H100/B200 第三方独立 benchmark 公开。
- SGLang 跑在 400,000+ GPU 上的规模数字:来自 Towards AI 深度分析,未在 SGLang 官方仓库或论文中独立验证;v37 §2.1 待 SGLang 官方仓库或论文披露规模数字。
- OWASP Agent ASI01-ASI10 双谱系标准是否进入主流框架:OWASP 是事实标准但非强制;LangGraph / CrewAI / Dify 等主流框架的代码架构并未直接集成 OWASP 防护模式;v37 §2.5 候选 O131 待主流 Agent 框架 2026 Q4 集成情况。
- DEV Community 70-80% RAG 项目生产前失败的样本基础:数据来自 Blits.ai / Ragaboutit 2026,样本量与统计方法未独立验证;v37 §2.6 待独立调研机构(McKinsey / Gartner / IEEE)交叉核验。
- AI Multiple 29% 架构差距 vs particula SGLang +29% 吞吐 vs iotsdigitaltwinplm 调优 35% 波动 = SGLang 优势量化:三个独立 benchmark 来源数字接近但方法学不同;v37 §2.9 待 SGLang 官方或独立第三方完成
shared-prefix hit rate维度标准化 benchmark。 - prisma Redis LangCache Preview 70% LLM 成本节省:Preview 阶段, 尚未 GA;v37 §2.6 待 GA 发布与独立企业生产验证。
五、可引用的 arXiv 号列表(7-25 新增高价值)
| arXiv 号 | 标题 | 归入增量 |
|---|---|---|
| 2504.19874 | TurboQuant: PolarQuant + QJL, Key 3-bit + Value 2-bit, KV 6× 压缩 + Attention 8×(ICLR 2026, Google Research) | 增量 3 |
| 2605.17613v1 | VeriCache: 4×4 compaction self-draft KV Cache, 接受长度 19-23 vs EAGLE 2-22 | 增量 3 |
| 2607.18149 | Diff-Logic: Differentiable Logic Gate Networks(边缘 EEG 布尔电路推理) | 旁证 B |
| 2607.21557 | OpenForge RL: Train Harness-native Agents in Any Environment(Columbia + MSR, 6 harness × 6 benchmark) | 增量 4 |
| 2607.21503 | Agentic Context Management: Lifecycle + Architecture(主分类 agent, spark agent-e1prep 已收 .llm-infra-candidate.md §2.8 邻接) | 增量 4(已沿用) |
| 2603.11768 | SkillOpt: Agent Skills as Trainable Parameters(MSR, 已 candidate) | 增量 4(已沿用) |
| 2603.05451 | FlashAttention-4 Blackwell CuTe-DSL(已 candidate §2.4) | 增量 2(已沿用) |
| 2607.08973v1 | SiFAR: Synchronization-Free All-Reduce 8×H200 +43%(已 candidate §2.2) | 增量 2(已沿用) |
| 2607.01579v1 | OmniPilot: Conformal Calibrated Quantile Cost Model(已 candidate §2.2) | 增量 2(已沿用) |
QuantSpec arXiv 号本场未在 inbox 中明确披露;需补 Apple ML Research 官方页面或 ICML 2026 proceedings PDF 验证。
沿用 7-24 E1 prep + 7-25 05:00 candidate arXiv 列表(本场未重复展开): 2607.19345 Copy Less / 2607.19604 Hypernetwork / 2606.16135 SwiftCache / 2606.02964 AsymCache / 2603.08739 Kareto / 2605.03375 Tutti / 2511.02230 Continuum / 2602.21626 Multi-Layer MoE / 2508.08438v2 SafeKV / 2603.10726v2 PrefixWall / 2602.21548v2 DualPath / 2606.28565v1 KernelSight-LM / 2607.10183v1 ATSInfer / 2603.16104v1 Helium / 2607.21461 AREX / 2607.04763 ReOPD / 2607.19865 DocOps / 2607.14952v1 LongStraw / 2605.19743v1 EngiAI / 2607.08716 Proactive Memory Agent / 2602.02007 xMemory / 2607.13104 Self-Improvements Survey / 2603.04428 端侧 KV Q4 持久化 27× / 2605.10834 Pentesting Agents / 2602.14374 DP RAG / 2506.12071 T²-RAGBench / 2606.26458v1 MKG-RAG-Bench / 2601.16503v1 MRAG-Bench / 2605.27445v1 RAGe / 2607.07534 Hover 文档可验证 Agent / 2605.03450 RAG dropout。
六、对活文档 v37 的建议
6.1 §2.x 增量归位矩阵
| 本场增量 | 建议归入 v37 节段 |
|---|---|
| 增量 1: llm-d CNCF Sandbox + K8s 自托管 vLLM + KubeCon EU 2026 + Cloud Native Model Distribution | §2.10(新增"CNCF K8s AI 推理事实标准栈 2026 H1 完整四件套"小节)+ §2.1 引擎 6 寡头补全 + §2.7 工程化工具链 |
| 增量 2: vLLM MRV2 56% + 完整 H1 新功能集 + Zylos 量化矩阵 | §2.1 vLLM 引擎演进 + §2.4 量化(FP8 33% + 5 方案质量保留率)+ §2.9 决策 9 维度 |
| 增量 3: TurboQuant + QuantSpec + VeriCache 三件套 | §2.3 KV cache 五件套 → 六件套 + §2.4 量化经济学 三路线对比表 |
| 增量 4: MAF Harness + OpenForgeRL + Enterprise 三层 + OWASP Agent 双谱系 | §2.7 工程化工具链 + Harness(MAF 双语言 + OpenForge RL proxy + 三层架构)+ §2.5 安全(OWASP Agent ASI01-ASI10) |
| 增量 5: 70% RAG 失败 + 4 失效模式 + 0.85^10=20% + Gartner 40% + DevOps→LLMOps | §2.6 RAG 新基准 + Failure Mode 全集 + §2.7 Agent 失败三模式 + §2.8 RAG 演进 5 架构 |
| 增量 6: 向量 DB 全栈 benchmark + 决策树 + Redis 语义缓存 | §2.6 AI-first data systems(完整 P50/P99 + 选型决策树 + Redis LangCache) |
| 旁证 A: SGLang 400,000+ GPU + TGI 退役 + OpenClaw 210K stars | §2.1 引擎 6 寡头(SGLang 规模)+ §2.7 工程化工具链(OpenClaw) |
| 旁证 B: Diff-Logic 边缘 EEG 布尔电路 | §2.4 Kernel(邻接,research 路线) |
| 旁证 C: SGLang 29% 边界 + LeetLLM 六维方法论 | §2.9 推理引擎决策 9 维度(prompt 复用率专维) |
6.2 v37 §3 共识候选新增(C49-C56 共 8 条)
- C49:CNCF K8s AI 推理事实标准栈 2026 H1 完整立标四件套(Sandbox + 自托管手册 + KubeCon EU + Model Distribution)
- C50:vLLM 2026 H1 引擎能力全面升格量化立标(vLLM MRV2 56% + FP8 33% + NGram Spec + 7 项新功能 + Zylos 矩阵 + Continuous Batching 23× + FA-3 840 TFLOPS)
- C51:KV Cache 压缩算法层三件套立标(TurboQuant 6×/8× + QuantSpec Apple ICML + VeriCache 接受长度 19-23 vs EAGLE 2-22)
- C52:商业级 Harness SDK 2026 H2 全面立标四件套(MAF + OpenForge RL + Enterprise 三层 + OWASP Agent ASI01-ASI10)
- C53:RAG + Agent 工程可靠性量化数据全栈立标(AI Vanguard 4 类失效 + DEV 70-80% + 失败三模式 0.85^10=20% + Gartner 40% + Amazon Kiro 13h + DevOps→LLMOps)
- C54:向量数据库 2026 H2 量化选型稳态(P50 benchmark 全栈 + 规模决策树 + pgvector 端到端 12ms + Qdrant 4.74ms P50 @ 50M + Redis 70% LLM 节省)
- C55:SGLang 400,000+ GPU 开源推理引擎事实标准 + TGI 维护模式 + OpenClaw 210K stars 史上最快增长
- C56:SGLang vs vLLM 性能分群边界量化立标(prefix 重复场景 29%,prompts 不重复时性能基本持平 + 六维方法论)
6.3 v37 §3 争议候选新增(D22 共 1 条)
- D22:CNCF 66% 组织用 K8s 推理 vs 非 K8s 路径真实比例;llm-d 作为 K8s 编排层是否在 2026 H4 占据事实标准位置 vs Inference Gateway / Dapr 并行竞争
6.4 v37 §4 开放问题候选新增(O129-O134 共 6 条)
- O129:llm-d 是否在 2026 H4 升 Incubating;Cloud Native Model Distribution 是否进入 vLLM/SGLang 官方文档;LINSTOR CSI 是否 K8s 1.32+ GA
- O130:TurboQuant 6×/8× 是否进入 vLLM v0.25+ / SGLang v0.5.15+ 官方内核;VeriCache 4×4 compaction 是否在 2026 Q3 进入 vLLM/TRT-LLM;QuantSpec 分层 4-bit 是否有 Apple MLX / PyTorch 官方实现
- O131:MAF Harness 是否 2026 Q3 进入 enterprise production;OpenForge RL proxy latency/token 漂移实测 vs Polar head-to-head;OWASP Agent 双谱系是否进入主流框架代码架构
- O132:AI Vanguard 4 类失效模式真实生产发生率;Gartner 40% 废弃预测 vs Berkeley RDI 40% 交叉核;OpenTelemetry Agent 集成是否 CNCF GA;DevOps→LLMOps 6 项映射是否成为企业 JD 标准
- O133:Qdrant 4.74ms P50 @ 50M vs Milvus 同规模独立 benchmark;Redis LangCache Preview 是否 2026 Q4 GA;pgvectorscale 是否进入 Postgres 官方分支
- O134:Diff-Logic 布尔电路推理是否进入主流 IoT 框架;神经-布尔电路编译是否有 LLM 推理侧具体应用
6.5 v37 §5 趋势候选(沿用 §T25)
本场无新增 §T;沿用 .llm-infra-candidate.md §T25(LLM Infra 工程实践新十维共识 + LLM Infra 工程师十维复合角色 + Inference Engineering 职业化 + AI-IR 新职业方向)。
七、核心结论(给今晚活文档接力)
今晚 v37 必须抢修的 3 个核心动作:
- §2.10 Cloud-Native 推理节扩为「CNCF K8s AI 推理事实标准栈 2026 H1 完整四件套」 —— 这是 v36 candidate 未覆盖的「治理结构 + 部署规范 + 模型交付 + 生态协同」完整治理层立标,与既有的 vLLM V1 connector TileRT + llm-d v0.4 分层 KV Cache + NIXL 形成「引擎 + 编排 + 治理」三件套。
- §2.3 KV cache 优化节扩为「六件套」(从 SwiftCache/AsymCache/Kareto/DualPath/SafeKV+PrefixWall/Continuum 五件 → + TurboQuant/QuantSpec/VeriCache 三件压缩立标)—— 算法层三路线 + 架构层路线 + 现网 FP8 KV-cache-dtype 三层成熟稳态立标。
- §2.7 工程化工具链节扩为「商业级 Harness SDK 2026 H2 四立标」(MAF + OpenForge RL + Enterprise 三层 + OWASP Agent ASI01-ASI10 双谱系)—— 把候选版的 Microsoft Agent Framework 1.0 升级为「商业 SDK + 训练基础设施 + 企业级架构 + 安全谱系」四件套完整。
核心压栈判断:
- 本场 6 主线 + 3 旁证,核心增量集中在「治理 + 量化 + 安全 + 可靠性」四个维度;v37 候选版应确保这四维度与既有的「性能 + 部署 + 引擎」三维度形成七维完整增量。
- 待活文档 v37 一并消化 7-24 8 主线 + 7-25 6 主线 + 3 旁证 = 共 17 主线 + 3 旁证, 8 天未更新一次性抢修 = 高密度抢修轮。
- .llm-infra-candidate.md 7-25 05:00 版 76KB 已覆盖 7-24 8 主线(76KB 候选),本场 6 主线 + 3 旁证 = v37 候选新增 14-16 KB 目标(总量 90-92KB)。
Spark · 2026-07-25 18:40 (Asia/Shanghai) · E1 llm-infra 预消化 · 增量 6 主线 + 3 旁证 · arXiv 新增 5 件 · 共识候选 C49-C56 共 8 条 · 争议 D22 · 试金石 O129-O134 共 6 条 · .llm-infra-candidate.md 待 v37 抢修