Jay 工程实践筛选 · Round 2 · 2026-08-22

角色：Jay · 工程文章二次筛选 · 判断是否包含真实环境、命令、错误、源码、性能数据、可复现步骤

候选条目总览

# 条目 来源 工程价值 保留/丢弃
1 K8s + LLM Inference 生产部署实操 GitHub (framsouza/inference-at-scale-on-kubernetes) ⭐⭐⭐ 极高 ✅ 保留
2 KV Cache 分析仪 CLI 工具 GitHub (bs258q/kv-cache-analyzer) ⭐⭐ 高 ✅ 保留
3 DefensiveKV: KV Cache 逐出防御 (ICLR 2026) GitHub (FFY0/DefensiveKV) ⭐⭐ 高 ✅ 保留
4 llm-d 分布式 KV Cache 路由 GitHub (llm-d/llm-d-kv-cache) ⭐⭐ 高 ✅ 保留
5 Microsoft Foundry Agent 可靠恢复模式 Tech Community (Microsoft) ⭐⭐ 高 ✅ 保留
6 AgentRx: Agent 失败诊断框架 GitHub (microsoft/AgentRx) ⭐⭐ 高 ✅ 保留
7 Alejandro Rioja: 生产 AI Agent 调试实操手册 个人博客 ⭐⭐ 高 ✅ 保留
8 PROBE: 调试调试器 (Microsoft Research) Microsoft Research ⭐⭐ 高 ✅ 保留（研究线索）
9 vLLM OOM 排障论坛帖 Reddit/RunLLM ⭐⭐ 高 ✅ 保留（已有 morning briefing 覆盖）
10 KServe vLLM CPU Offloading CRD GitHub PR (kserve/kserve) ⭐⭐ 中 ✅ 保留（k8s 生产集成）

详细筛选记录

✅ 条目 1：K8s + LLM Inference 生产级别部署实操（⭐⭐⭐ 极高）

来源：framsouza/inference-at-scale-on-kubernetes 可信度：高（生产经验分享，具体数字和命令） 保留理由： - 真实 KV Cache 数值计算：Mistral Large 123B，每个 token 0.344 MB BF16，128K 上下文单个请求 ~44 GB KV cache - GPU 内存拆分：246 GB 权重 + 30 GB activations/CUDA 开销 + 360 GB KV cache 预算 - 具体 K8s 模式：DRA（GPU 拓扑）、LeaderWorkerSet（多 Pod 副本）、Kueue/Volcano（gang scheduling）、KEDA（按 KV cache pressure 扩缩） - Prefix Routing 方案：K8s Gateway API Inference Extension + KV cache indexer，避免 round-robin 前缀重复计算 - Disaggregation Serving：Prefill/Decode 分离的条件判断，实际 HBM 带宽 vs 算力约束分析 - 具体指标：TTFT、ITL、p95 TTFT、p95 ITL、vllm:gpu_cache_usage_perc、vllm:num_requests_waiting

核心命令/配置模式： - 扩缩信号：vllm:gpu_cache_usage_perc > 80–85% 即应 scale-up - Queue depth > 0 持续出现 = 已在加延迟 - KEDA Prometheus scaler 指向 vLLM metrics endpoint - 不使用 round-robin，改用 GIE（Gateway API Inference Extension）

丢弃风险：无。该文是 K8s 推理部署领域当前最完整的实操指南之一。

✅ 条目 2：KV Cache 分析仪 CLI 工具（⭐⭐ 高）

来源：bs258q/kv-cache-analyzer 可信度：高（CLI 工具，有源码，MIT License） 保留理由： - 真实 CLI 命令：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 - 多种框架支持对比表：vLLM APC / SGLang RadixAttention / TensorRT-LLM Block reuse / TGI（不支持） - LRU Hit Rate 数值：| scenario | LRU Hit Rate | Within-Session | - 具体场景数据：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() 函数可用于回归测试

丢弃风险：无。工具化 + 具体命令，可直接复现。

✅ 条目 3：DefensiveKV (ICLR 2026)（⭐⭐ 高）

来源：FFY0/DefensiveKV 可信度：高（ICLR 2026 论文，有源码） 保留理由： - 源码级实现：基于 NVIDIA KVPRESS，只加两行代码实现 Defensive Aggregation - 完整 Benchmark 表：SnapKV / AdaKV / AdaCriticalKV / DefensiveKV / LayerDefensiveKV 在 RULER 上 20% cache size 的逐任务分数 - 关键发现：SnapKV 在修正 benchmark 后 20% compression 下只有 39.0 分（非"无损"），DefensiveKV 拉到 85.3，LayerDefensiveKV 91.4 - 快速验证命令：≤1 小时单 RTX 4090 可跑完 RULER 10% - 工程亮点：校正了之前 SnapKV "无损失" 的 benchmark 错误，工程严肃性高

丢弃风险：无。ICLR 2026 论文源码，KV cache 压缩方向最新 SOTA。

✅ 条目 4：llm-d 分布式 KV Cache 路由（⭐⭐ 高）

来源：llm-d/llm-d-kv-cache 可信度：高（生产级开源，vLLM upstreamed） 保留理由： - KVEvents 架构：vLLM pod → 事件流 → KV Block Index → Scheduler 打分 → 路由决策 - 跨 Pod 缓存共享：KV cache indexer 跟踪 fleet 级别的 block locality - 已 upstreamed 到 vLLM：llmd-fs-connector==0.23 = vLLM v0.23 的 FS tier，说明是生产验证过的 - 配置命令：KV cache indexer + router 集成文档完整

丢弃风险：无。与条目 1 互补，条目 1 是部署实操，条目 4 是分布式 KV 路由机制。

✅ 条目 5：Microsoft Foundry Agent 可靠恢复（⭐⭐ 高）

来源：Microsoft Community Hub 可信度：高（Microsoft 官方工程博客） 保留理由： - 10 类失败分类表：Transient timeout / Timeout after side effect / Duplicate action / Authorization failure / Stale data / Conflicting data / Partial completion / 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，而是状态转换图

丢弃风险：无。生产 Agent 可靠性工程的系统性框架，可直接落地。

✅ 条目 6：AgentRx 失败诊断框架（⭐⭐ 高）

来源：microsoft/AgentRx 可信度：高（Microsoft Research，Apache 2.0，有 CLI） 保留理由： - Pipeline 5 阶段：IR → Static invariants → Dynamic invariants → Check → Judge，每阶段有独立命令 - 完整 CLI：python run.py trajectory.json --stage ir --run-dir runs/my_run python run.py trajectory.json --stage check --run-dir runs/my_run python run.py trajectory.json --stage judge --run-dir runs/my_run - 10 类失败分类（比 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：DefaultAzureCredential local dev machine ~5-10s timeout 的 fix（AZURE_TOKEN_CREDENTIALS=dev）

丢弃风险：无。Agent 诊断领域最系统的开源工具链。

✅ 条目 7：Alejandro Rioja 生产 AI Agent 调试（⭐⭐ 高）

来源：alejandrorioja.com 可信度：中高（个人博客，工程经验，2026-06 更新） 保留理由： - 核心观点：~70% 的"AI bug"其实是 plumbing bug（malformed tool result / truncated input / silently swallowed exception） - 4 层调试 bisection：Input layer → Tool layer → Model layer → Orchestration layer - Replay harness 模式：从 trace 重放任意单步，temperature:0 + 50x loop 区分确定性 bug 和非确定性 - 行为指标：Tool-call success rate / Output schema validity / Loop length / Cost per run - 5 分钟检查清单：trace ID → 检查输入格式 → 检查工具错误伪装 → temperature:0 重放 → 循环测试

丢弃风险：低。Blog 质量高，工程经验可落地，建议精读原文。

✅ 条目 8：PROBE 调试调试器（⭐⭐ 高）

来源：Microsoft Research 可信度：高（Microsoft Research，2026-05） 保留理由： - 3 层架构：Telemetry Layer → Diagnosis Layer → Guidance Gate - 评估数字：257 案例，65.37% Top-1 诊断准确率，21.79% 恢复率，比非 PROBE baseline 高 43.58pp / 12.45pp - 关键发现：诊断-恢复 gap（accurate diagnosis is necessary but insufficient unless translated into bounded guidance） - 非侵入式：attach as side channel，不改 agent policy / toolset / execution budget - IcM 原型：已集成到微软内部 incident management

保留方式：研究线索 + 工程框架参考，非直接落地（已有 AgentRx 更可直接用）。

✅ 条目 9：vLLM OOM 排障（已有 morning briefing 覆盖，降级保留）

来源：RunLLM forum / vLLM troubleshooting 保留理由： - 具体命令：--enforce-eager（禁用 CUDA graphs 排查）、--gpu-memory-utilization 0.95 / 0.7 - 具体错误定位：self._allocate_kv_cache_tensors(kv_cache_config) → torch.zeros OOM - 诊断流程：OOM 在 KV cache allocation 而非 CUDA graph creation 阶段 - morning briefing 已覆盖，降低本次优先级

✅ 条目 10：KServe vLLM CPU Offloading CRD（⭐⭐ 中）

来源：kserve/kserve PR #5599 可信度：高（正式 PR，review 流程） 保留理由： - K8s CRD 模式：spec.kvCacheOffloading.cpu: 10Gi → 自动 render --kv-transfer-config JSON - Prefill/Decode 分离配置：spec.prefill.kvCacheOffloading - 自动检测逻辑：已在 VLLM_ADDITIONAL_ARGS 中设置则跳过自动注入 - 实际 render 示例：--kv-transfer-config '{"kv_connector":"OffloadingConnector","kv_role":"kv_both",...}'

丢弃风险：低。K8s 推理平台集成参考。

汇总：保留条目工程价值分布

价值等级 条目 核心贡献
⭐⭐⭐ 极高 #1 K8s+LLM inference KV cache 数值计算 + K8s 扩缩策略 + 路由方案
⭐⭐ 高 #2 kv-cache-analyzer CLI 工具 + LRU hit rate 实测数据
⭐⭐ 高 #3 DefensiveKV ICLR 2026 源码 + benchmark 修正
⭐⭐ 高 #4 llm-d KV routing 分布式 KV cache 跨 Pod 路由
⭐⭐ 高 #5 Foundry recovery 10 类失败分类 + Action Ledger + FRS
⭐⭐ 高 #6 AgentRx 5 阶段诊断 CLI + 10 类 taxonomy
⭐⭐ 高 #7 Rioja 调试手册 70% plumbing bug + replay harness + 5 分钟清单
⭐⭐ 高 #8 PROBE 诊断-恢复 gap 研究 + 3 层框架
⭐⭐ 中 #9 vLLM OOM 命令行参数排障
⭐⭐ 中 #10 KServe offloading K8s CRD 集成模式

分类标签

#K8s推理 #KV-Cache #Agent调试 #故障恢复 #vLLM #SGLang #生产工程 #LLM推理 #工具链

建议写入路径

  • 主题页：research-kb/published/k8s-llm-inference-production-runbook.md（条目 1）
  • 工具卡：research-kb/published/kv-cache-analyzer-cli.md（条目 2）
  • 论文笔记：research-kb/inbox/jay/2026-08-22-defensivekv-iclr2026.md（条目 3）
  • Agent 工程：research-kb/inbox/jay/2026-08-22-agent-failure-taxonomy-foundry-agentrx.md（条目 5+6）
  • 本次综合草稿：research-kb/inbox/jay/2026-08-22T1050-jay-engineering-filter.md

精读/审稿建议

  1. 必须精读：条目 1（K8s+LLM inference 全文），条目 7（Alejandro Rioja 调试手册）
  2. 建议核验：条目 3 的 DefensiveKV RULER benchmark 原始数据（纠正 SnapKV 幻觉的论文）
  3. 建议复现：条目 2 的 kv-cache-analyzer CLI，用真实日志跑一遍
  4. 建议关注：条目 5（Microsoft Foundry）和条目 6（AgentRx）的落地差异——前者偏架构设计，后者偏诊断工具

本筛选由 Jay 自动生成 · 仅作为工程线索和技术洞察来源 · 不复制原文