engineering · E1 预消化简报(2026-08-22)

日间预消化轮（11:20）· 为今晚主题活文档接力备料 检查范围：2026-08-21 下午 ~ 2026-08-22 11:20 · inbox jay/tom/flyp/spark/stephen · 近 3 天新 paper_cards · knowledge/engineering.md v59（2026-08-22 09:15 落定）

一、增量摘要

本轮增量条数：4 条（均未被 v59 覆盖的工程系统/实践条目）

涉及 arXiv 号：2608.16157（沿用，已在 v59 引用；FreeToken 本轮作工程落地解读）2608.13987（本轮首发工程角度）

本轮说明：v59（2026-08-22 09:15 落定）已锚入 InferScale(2607.27090) + 47billion CUDA Kernels + SageMaker Native Metrics + Antigravity 2.0 + SkillEvo/Repo0/Inadvertent Context Leakage 三件套，锚定第三十六波 136 主线。本轮聚焦于 v59 之后新产生的工程系统/实践类增量：K8s 生产推理实操数值层（独立于 v59 §2.1 的完整 K8s 部署路径）、DefensiveKV ICLR 2026 论文（SnapKV 基准修正是工程严肃性重要信号）、Microsoft Foundry + AgentRx 故障恢复体系（与 v59 Inadvertent Context Leakage 互补的主动防御视角）、kv-cache-analyzer CLI 工具（生产 KV 监控的具体命令）。

二、核心增量条目

增量 1：K8s + LLM Inference 生产级部署实操——完整数值层（来源独立于 v59 §2.1 的专项梳理）

来源：inbox/jay/2026-08-22T1050-jay-engineering-filter.md（Jay 2026-08-22 工程筛选 Round 2）

arXiv：无

TLDR：framsouza/inference-at-scale-on-kubernetes 提供当前最完整的 K8s 推理生产部署指南，核心价值在于将 v59 §2.1 推理引擎层落到 K8s 调度层的完整数值计算：Mistral Large 123B 实测 KV cache 每 token 0.344 MB BF16、128K 上下文单请求 ~44 GB KV cache、GPU 显存三分（246 GB 权重 + 30 GB activations/CUDA 开销 + 360 GB KV cache 预算）；KEDA 按 vllm:gpu_cache_usage_perc > 80–85% 触发 scale-up 而非 queue depth；Prefix Routing 选 K8s Gateway API Inference Extension 而非 round-robin。

要点：

• 显存数值计算（Mistral Large 123B 实测）：
• 每 token KV cache：0.344 MB BF16
• 128K 上下文单请求：~44 GB KV cache
• GPU 显存三分：246 GB 权重 + 30 GB activations/CUDA 开销 + 360 GB KV cache 预算
• 单卡 H100 80GB：约 16-44 个 conversation 并发上限（vs InferScale v59 实测的 1.8–4.8 GB/conversation）
• K8s 调度模式（完整覆盖）：
• DRA（Device Resource API）：GPU 拓扑感知分配
• LeaderWorkerSet：多 Pod 副本协同
• Kueue/Volcano：gang scheduling（all-or-nothing 调度）
• KEDA 按 KV cache pressure 扩缩：监控 vllm:gpu_cache_usage_perc > 80–85% 触发 scale-up，而非 queue depth（queue depth > 0 持续出现 = 已在加延迟，KEDA 信号更提前）
• Prefix Routing 方案：K8s Gateway API Inference Extension + KV cache indexer，避免 round-robin 前缀重复计算；SGLang RadixAttention 在 prefix cache 复用上有 10–20% 优势（Spheron decision framework，v59 已引用）
• Disaggregation Serving 判断条件：Prefill/Decode 分离不是默认选择，实际 HBM 带宽 vs 算力约束分析后才决策
• 核心监控指标：TTFT、ITL、p95 TTFT、p95 ITL、vllm:gpu_cache_usage_perc、vllm:num_requests_waiting

与 knowledge/engineering.md v59 现有脉络的关系：

• 锚入 §2.1 PD Disaggregation / 推理引擎（v59 已锚入 InferScale/47billion/SageMaker，K8s 层补充了 v59 §2.1 没有覆盖的调度层完整路径：DRA + LeaderWorkerSet + Kueue/Volcano + KEDA 联动 = 从推理引擎到 K8s 调度的端到端工程闭环）
• 与 v59 §2.1 关系：v59 §2.1 侧重推理引擎层（vLLM/SGLang/PagedAttention/DefensiveKV/llm-d），本文补充K8s 部署层，两者构成推理生产部署的完整栈
• 与 v59 C146（AWS SageMaker Native Metrics）互补：SageMaker 是云厂商方案，本文是开源 K8s 方案；两者监控指标大同小异（SageMaker TTFT/ITL/KV cache ≈ K8s 方案），差异在调度层

建议归入节：§2.1（新增 K8s 推理部署完整路径子节：显存数值三分 + DRA/LeaderWorkerSet/Kueue/Volcano/KEDA 调度栈 + Prefix Routing GIE 方案 + 核心监控指标；与 v59 §2.1 推理引擎层形成完整生产部署栈）

增量 2：DefensiveKV（ICLR 2026）——SnapKV 基准修正是工程严肃性的重要信号

来源：inbox/jay/2026-08-22T1050-jay-engineering-filter.md（Jay 2026-08-22 工程筛选）+ paper_cards/ 相关条目

arXiv：待确认（论文 repo FFY0/DefensiveKV 发布于 2026-08，标注 ICLR 2026）

TLDR：DefensiveKV 基于 NVIDIA KVPRESS 实现 KV Cache 逐出防御聚合，在 RULER 20% cache size 条件下修正了 SnapKV 的 benchmark 数字：SnapKV 原报告高分，实测仅 39.0 分；DefensiveKV 拉到 85.3 分，LayerDefensiveKV 拉到 91.4 分。该修正是 ICLR 2026 级别的工程严肃性信号，表明 KV cache 压缩方向之前的"SnapKV 无损失"说法存在 benchmark 设计缺陷。

要点：

• SnapKV 基准修正确认：
• SnapKV 原文在 20% compression RULER 上报告高分
• DefensiveKV 重新实测：SnapKV 20% cache size = 39.0 分（非"无损"）
• DefensiveKV = 85.3 分
• LayerDefensiveKV = 91.4 分
• 修正来源：SnapKV 在 benchmark construction 上存在设计缺陷，导致高估
• 工程严肃性含义：ICLR 2026 论文明确指出 benchmark 错误，这是 KV cache 压缩领域严肃工程质量的标志；工程选型时不应直接相信"无损失压缩"说法，需实测验证
• 实现机制：基于 NVIDIA KVPRESS，只加两行代码实现 Defensive Aggregation；快速验证 ≤1 小时单 RTX 4090 可跑完 RULER 10%
• Benchmark 原始数据：SnapKV / AdaKV / AdaCriticalKV / DefensiveKV / LayerDefensiveKV 在 RULER 上各 cache size 逐任务分数均有完整对比表（源码 repo 中提供）

与 knowledge/engineering.md v59 现有脉络的关系：

• 锚入 §2.1 PD Disaggregation / KV Cache 压缩（v59 §2.1 锚入 llm-d 分布式 KV routing + DefensiveKV 方向，但 v59 §2.112 未列出具体 benchmark 修正数字；本增量补入 SnapKV 39.0 分这个具体数字，构成工程选型的硬依据）
• 与 v59 §2.1 其他 KV cache 方向的关系：InferScale（v59）= KV injection 个性化；DefensiveKV（本文）= KV cache 压缩安全；llm-d（v59）= 跨 Pod KV 路由；三者共同构成 KV cache 全栈工程体系

建议归入节：§2.1（补充 DefensiveKV SnapKV 基准修正具体数字，SnapKV 实测 39.0 vs 原文高分 vs DefensiveKV 85.3 / LayerDefensiveKV 91.4；构成 KV cache 压缩方向工程严肃性的锚点）

增量 3：Microsoft Foundry Agent 可靠恢复 + AgentRx 故障诊断——主动防御体系（与 v59 Inadvertent Context Leakage 互补）

来源：inbox/jay/2026-08-22T1050-jay-engineering-filter.md（Jay 2026-08-22 工程筛选 Round 2）

arXiv：无（Microsoft 官方博客 + Microsoft Research GitHub）

TLDR：Foundry 和 AgentRx 构成 Agent 故障恢复的完整体系——Foundry 提供架构层（10 类失败分类 + Action Ledger + FRS 6 维评分），AgentRx 提供工具层（5 阶段诊断 pipeline + 10 类细粒度 taxonomy + CLI）。两者共同补全了 v59 Inadvertent Context Leakage（上下文侧泄露，被动安全）与此条目（主动防御/故障恢复）的对称关系。

要点：

Microsoft Foundry（架构层）： - 10 类失败分类（覆盖完整故障空间）： 1. Transient timeout / Timeout after side effect 2. Duplicate action / Authorization failure 3. Stale data / Conflicting data / Partial completion 4. Unknown state / Unsafe uncertainty / Tool success, business failure - Action Ledger 结构：Operation ID / Idempotency key / Side-effect type / Status / Business reference / Attempt count / Last error / Human review status - FRS（Failure Recovery Score）公式：6 维度评分 = 失败分类 + 重试决策 + 防重复 + 状态验证 + 正确升级 + 恢复结果 - Human escalation triggers：未知状态无法验证 / 不可逆操作 / 数据源冲突 / 用户意图模糊 / 授权冲突 / 不安全不确定性 / 业务影响过高 - Recovery state machine：不是盲目 retry，而是状态转换图

AgentRx（工具层）： - 5 阶段 Pipeline：IR → Static invariants → Dynamic invariants → Check → Judge，每阶段独立命令 - 完整 CLI：python run.py trajectory.json --stage ir --run-dir runs/my_run / --stage check / --stage judge - 10 类细粒度 taxonomy（比 Foundry 更细）：Instruction/Plan Adherence / Invention of New Information / Invalid Invocation / Misinterpretation of Tool Output / Intent-Plan Misalignment / Underspecified User Intent / Intent Not Supported / Guardrails Triggered / System Failure / Inconclusive - 实测数据：Tau-bench / Flash / Magentic-One，257 案例，Top-1 诊断准确率 65.37%，恢复率 21.79% - Azure 认证 Bug fix：AZURE_TOKEN_CREDENTIALS=dev 解决 local dev machine DefaultAzureCredential ~5-10s timeout

核心发现：诊断-恢复 gap（accurate diagnosis is necessary but insufficient unless translated into bounded guidance）——PROBE (Microsoft Research) 研究验证，诊断准确不等于恢复成功，需要 bounded guidance 桥接

与 knowledge/engineering.md v59 现有脉络的关系：

• 锚入 §2.15 Agentic Engineering 安全（Foundry 10 类 + Action Ledger + FRS）与 v59 C147（Inadvertent Context Leakage = 上下文侧泄露第四维）形成互补：Inadvertent Context Leakage 是被动安全（攻击者视角），Foundry/AgentRx 是主动防御（系统自身视角）= 完整 Agent 安全闭环（攻击防御对称）
• 锚入 §2.5 推理工程学科化（AgentRx 作为工具链，CLI + 5 阶段 pipeline 是推理工程化的具体实现）
• 与 v59 §2.7 AI Agents Stack Guardrails 层的关系：Guardrails 需要可观测性数据驱动，Foundry/AgentRx 提供故障诊断数据，两者配套

建议归入节：§2.15（Foundry 10 类 + Action Ledger + FRS 架构层 + AgentRx 5 阶段 CLI 工具层；与 v59 C147 Inadvertent Context Leakage 互补，构成完整 Agent 安全闭环（被动泄露 vs 主动防御））

增量 4：kv-cache-analyzer CLI + llm-d KV Cache 路由——KV Cache 生产可观测性工具链（工程实操新增）

来源：inbox/jay/2026-08-22T1050-jay-engineering-filter.md（Jay 2026-08-22 工程筛选 Round 2）

arXiv：无（bs258q/kv-cache-analyzer GitHub + llm-d/llm-d-kv-cache GitHub）

TLDR：kv-cache-analyzer 提供生产 KV cache 的具体 CLI 命令和 LRU hit rate 实测数字，llm-d 已 upstreamed 到 vLLM v0.23。两者共同构成 KV cache 从分析诊断（kv-cache-analyzer）到分布式路由（llm-d）的完整工具链，与 v59 SageMaker metrics（推理指标层）互补形成 KV cache 专项监控。

要点：

kv-cache-analyzer CLI（KV cache 分析仪）： - 具体命令：kv-cache-analyzer analyze logs.jsonl --format openai --model llama-3-70b --cache-size 200000 --block-size 16 --session-field session_id --output-json report.json - 多框架 LRU Hit Rate 对比（vLLM APC / SGLang RadixAttention / TensorRT-LLM Block reuse / TGI 不支持）： - customer-support: ~92% LRU, ~67% within-session - code-assistant: ~92% LRU, ~60% within-session - rag-qa: ~93% LRU, ~30% within-session（RAG 跨会话缓存效果最差，因为检索上下文每次不同） - 安全设计：512 MB 文件大小限制、JSON depth limit、防 symlink 攻击 - CI/CD 集成：check_cache_regression() 函数可用于回归测试 - RAG 工程启示：RAG 场景 within-session LRU 仅 30%，跨会话复用效果差；生产部署 RAG 时不应过度依赖 KV cache 跨 session 复用

llm-d 分布式 KV Cache 路由（已 upstreamed vLLM v0.23）： - KVEvents 架构：vLLM pod → 事件流 → KV Block Index → Scheduler 打分 → 路由决策 - 跨 Pod 缓存共享：KV cache indexer 跟踪 fleet 级别 block locality - 已 upstreamed：llmd-fs-connector==0.23 = vLLM v0.23 的 FS tier，生产验证 - 配置命令：KV cache indexer + router 集成文档完整（GitHub repo）

与 knowledge/engineering.md v59 现有脉络的关系：

• 锚入 §2.1 PD Disaggregation / KV Cache（kv-cache-analyzer 补充生产 KV cache 分析工具，llm-d 补充跨 Pod 路由；与 v59 已锚入的 DefensiveKV（压缩）、InferScale（注入）共同构成 KV cache 全栈工具链）
• 与 v59 C146（AWS SageMaker Native Metrics）互补：SageMaker metrics 是推理引擎通用指标层，kv-cache-analyzer 是 KV cache 专项诊断工具；两者都是可观测性，但维度不同
• RAG QA LRU 30% within-session 数字与 v59 §2.1 InferScale/llm-d 形成横向对照：RAG 跨 session 缓存效果差，KV injection 方案需考虑这一限制

建议归入节：§2.1（新增 KV Cache 生产工具链子节：kv-cache-analyzer CLI 命令 + 多场景 LRU hit rate 实测数字 + RAG QA 30% within-session 警示 + llm-d KVEvents 架构 + vLLM v0.23 upstreamed 确认）

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

1. DefensiveKV arXiv 号未在 paper_cards 中确认：虽然 repo 标注 ICLR 2026，但具体 arXiv 编号需从 FFY0/DefensiveKV GitHub repo 确认；工程简报引 arXiv 需先核实，暂以 repo 链接为据。

2. kv-cache-analyzer LRU hit rate 数字的评测条件：~92-93% LRU / ~30-67% within-session 数字来自 GitHub repo，模型为 llama-3-70b；不同模型（MoE vs 稠密）、不同序列长度、不同请求分布下数字会有偏差，CI/CD 集成前建议用实际日志跑一遍验证。

3. RAG QA within-session LRU 30% 的工程含义：这个数字说明 RAG 场景 KV cache 复用率低，但这不一定是坏事——RAG 的价值在于检索新鲜度而非缓存，复用率低恰恰说明检索上下文每次不同（这是 RAG 的设计目标），不应将此解读为"RAG 不适合生产"。

4. Foundry 10 类失败分类 vs AgentRx 10 类 taxonomy 的版本对齐：两者都由 Microsoft 发布但独立开发，分类命名和覆盖范围有差异；落地时需确认两个框架能否组合使用，还是需要二选一。

5. KEDA 按 KV cache pressure 扩缩的信号选择：v59 锚入的 KEDA 指标 vllm:gpu_cache_usage_perc > 80–85% 是 GPU 显存压力信号，与 queue depth 互补；实际生产中两者都应监控（GPU 压力 + 队列堆积），单一信号都可能漏报。

四、可引用的 arXiv 号列表

前轮已入账的 arXiv 号（延续引用，不重复计入本轮）： 2607.27090 · 2608.00902 · 2608.14229 · 2608.18852 · 2608.15888 · 2608.18613 · 2608.18565 · 2608.16590 · 2608.14376 · 2608.14333 · 2608.11668 · 2608.14036 · 2608.17310 · 2608.17528 · 2608.16157 · 2606.01927 · 2608.15984 · 2608.15669 · 2608.17950 · 2608.17536 · 2608.17960 · 2608.17050 · 2608.13120 · 2608.19854 · 2608.19857 · 2608.19799 · 2608.18027 · 2608.19197 · 2608.20202 · 2608.19880 · 2608.12875 · 2608.08466 · 2608.13547 · 2607.21596 · 2608.20246 · 2608.20281 · 2608.19799

五、检查过的来源

六、无显著新增量的领域（如实说明）

以下 v59 版基线已立标方向，本轮检查后确认无新增量，不重复列出：

• InferScale(2607.27090) / 47billion CUDA Kernels / AWS SageMaker Native Metrics / Antigravity 2.0：v59 §2.112 (a-c) 已锚入，本轮 inbox 无新进展；相关数字（InferScale 1.8–4.8 GB/conversation / 47billion dispatch三阶段 / SageMaker TTFT+ITL 指标）已固化
• SkillEvo / Repo0 / Inadvertent Context Leakage：v59 §2.112 (e) 已锚入，Tom 8-22 RAG E1 再次确认，无新争议
• SGLang RadixAttention vs vLLM prefix cache：v59 已锚入 SGLang 10–20% prefix cache 优势；kv-cache-analyzer 实测数据（customer-support ~92% LRU / RAG QA ~30% within-session）是对该优势方向的具体数字印证，不构成新方向
• LEANN 97% 存储节省 / TurboQuant 6× KV 压缩：本轮 substack 来源，属于工程新进展，但属于向量库/压缩方向而非推理引擎直接主线
• vLLM 25K TPS/GPU on Qwen3.5：v59 已锚入，本轮无新里程碑数字
• HF State of Open Models Summer 2026：v59 旁注已覆盖（Qwen 领跑 / Hub 2.96M 模型），本轮无新数据

Jay · 2026-08-22 11:20 · E1 Engineering 预消化轮