工程筛选报告 · Jay · 2026-06-28 下午档

筛选主题： 推理引擎 Bug 分类 / Agent 排障工程 / 静默错误诊断 / 生产 OOM 根因 / CUDA 调试 / Coding Agent 优化能力评估

检索范围： - arXiv (cs.SE, cs.AI, cs.LG) — 2026 年 6 月新 - Substack — Addy Osmani / The AI Corner / Pragmatic Engineer / Charity Majors - ParallelIQ / DigitalApplied / Spheron — 生产排障指南 - GitHub — vLLM/SGLang 真实 issue 和 benchmark 命令

候选条目（共 15 条）

# 条目 来源 工程类型 决策
1 A First Look at Bugs in LLM Inference Engines arXiv:2506.09713v2 Bug 分类研究 ✅ 保留
2 Understanding Bugs in Modern Agentic Frameworks arXiv:2604.08906 Agent Bug 研究 ✅ 保留
3 Testing Web-Scale RCA Methods on GPU-Driven LLM Workloads arXiv:2603.02057v1 混沌工程 ✅ 保留
4 Ekka: Automated Diagnosis of Silent Errors in LLM Inference arXiv:2606.04594v1 静默错误诊断 ✅ 保留
5 Continuous Discovery of Vulnerabilities in LLM Serving with Fuzzing arXiv:2605.11202v1 安全测试 ✅ 保留
6 ISO-Bench: Coding Agents Optimize Real-World Inference arXiv:2602.19594v1 Coding Agent 评估 ✅ 保留
7 Agent Memory Below the Prompt: MLX KV Cache arXiv:2603.04428v1 边缘推理 ✅ 保留
8 A First Look at Bugs in LLM Inference Engines (旧文补充) arXiv:2506.09713 Bug 根因分析 ✅ 保留
9 vLLM OOM Errors: Root Cause Diagnosis Guide paralleliq.ai 生产排障 ✅ 保留
10 SGLang Production Deployment: RadixAttention spheron.network 部署指南 ✅ 保留
11 KV Cache Optimization Guide 2026 digitalapplied.com KV 优化 ✅ 保留
12 AI Inference Engineering Playbook 2026 the-ai-corner.com 推理工程 ✅ 保留
13 Addy Osmani: LLM Coding Workflow 2026 Substack 工程实践 ✅ 保留
14 What is Inference Engineering Pragmatic Engineer 工程定义 ✅ 保留
15 Why Does the LLM Stop Computing arXiv:2601.13655v1 失败归因 ✅ 保留

丢弃 0 条 — 本轮候选均含真实错误模式、命令、源码分析或量化性能数据

保留条目详情

✅ 条目 1：A First Look at Bugs in LLM Inference Engines — 六类 Bug 症状 + 阶段分布

来源： https://arxiv.org/html/2506.09713v2
发布时间： 2025 年 6 月（2026 年 6 月仍高度相关）
可信度： ★★★★★（arXiv 学术研究，929 个真实 bug 样本）
工程类型： Bug 分类 / 根因分析

核心工程数据（六类症状）：

ID 症状 描述
S1 Crash 引擎意外终止，无恢复能力（OOM、越界访问）
S2 Unexpected Output 参数错误、乱码、无关输出、逻辑丧失
S3 Feature Failure 引擎运行但特定功能失效
S4 Abnormal Performance 过度/不足资源使用、异常延迟
S5 System Hang 引擎运行但无响应
S6 Silent Error 内部异常，无错误检测

关键发现： - 97% 的 setup 阶段 bug 导致 crash - 跨平台兼容性（RD.1，138 cases）是最大挑战——Metal/CUDA/TPU 后端不一致 - 版本不兼容（RD.2，98 cases）——TVM API 更新导致破坏 - 35%+ 的问题呈现非 crash 症状（静默错误/Hang），更难诊断 - 数值问题（RC.7，17 cases）——除零、溢出、round 错误 - 典型 bug：Llama.cpp issue #10176（越界内存访问导致 crash）、Deepspeed #2090（微秒当秒导致指标膨胀）

Bug 根因分类（部分）： - RD.1 Incompatible Backend — Metal 后端 ggml_view_3d 不兼容 - RD.2 Incompatible Version — TVM API 版本更新导致调用错误 - RC.6 Incorrect Type — ABCMeta 类对象代替字符串传入 - RC.7 Numerical Issue — FLOPs 剖析中时间单位错误

保留理由： ✅ 大规模真实 bug 统计（929 bugs，5 个引擎），非小样本 ✅ 六类症状分类直接可用于生产告警规则设计 ✅ 跨平台兼容性问题是 2026 年 GPU 多后端部署的共性痛点 ✅ 35% 非 crash 症状——这是最难监控的静默失败，需专门告警策略

丢弃理由： 无

标签： #LLM-inference #bug-taxonomy #crash-analysis #silent-failure #cross-platform

✅ 条目 2：Understanding Bugs in Modern Agentic Frameworks — Agent Bug 症状 + 根因

来源： https://arxiv.org/html/2604.08906
发布时间： 2026 年 4 月
可信度： ★★★★☆（arXiv，2026 年最新研究）
工程类型： Agent 框架 Bug 研究

核心工程数据：

Model Request Incompatibility（25/48 cases）： - 框架构造的输入违反 LLM 特定约束（不支持的参数或消息格式） - 案例：AutoGen-6116，Gemini-2.0-Flash 只响应最后一个 system message（多个 system message 被分别发送）

LLM Response Misalignment（框架层面）： - 框架假设与模型实际输出格式不匹配 - 模型特定约束未在框架层处理

Root Cause Pattern： 框架（LangGraph/CrewAI/AutoGen/SmolAgents）与底层 LLM 服务链之间的 misalignments

保留理由： ✅ Agentic 框架在 2026 年生产大规模采用，框架层 bug 数量上升 ✅ Model Request Incompatibility 是实际集成痛点——多 system message 处理是常见坑 ✅ AutoGen-6116 的 Gemini 多 system message 案例有直接工程参考价值

丢弃理由： 无

标签： #agentic-frameworks #bug-research #AutoGen #LangGraph #model-compatibility

✅ 条目 3：Testing Web-Scale RCA Methods on GPU-Driven LLM Workloads — Chaos Engineering

来源： https://arxiv.org/html/2603.02057v1
发布时间： 2026 年 3 月
可信度： ★★★★☆（学术论文 + 真实 K8s + ChaosMesh 故障注入）
工程类型： 混沌工程 / SRE / 故障注入

核心工程数据（真实命令）：

故障注入场景（ChaosMesh CRD）：

CPU Hog: 16 threads at full load (StressChaos CRD)
Memory Leak: 8GB additional memory over time (StressChaos CRD)
Network Latency: 1 second delay on all incoming traffic (NetworkChaos CRD)
GPU Throttling: nvidia-smi power limit 300W → 150W

测试工具链： - Locust — 5 QPS，300 workers，360 秒，512 prompt tokens + 256 output tokens - Prometheus — PodMonitor + ServiceMonitor 采集 Ray/vLLM 指标 - Istio ambient — ztunnel + waypoint proxy，采集服务间流量遥测 - Grafana — TTFT + E2E latency 可视化

关键发现： - LLM 推理形成独特的基础设施类——连续批处理 + paged attention 引入新型故障模式 - 与传统微服务故障不同，GPU 驱动的工作负载在资源压力下表现不同 - Prior work（Kokolis et al., 2025; Cui et al., 2025）研究训练阶段 bug，本文首次聚焦推理阶段

保留理由： ✅ 完整故障注入命令可复现（非模糊描述） ✅ 真实 K8s + Prometheus + Istio 集成方案 ✅ nvidia-smi GPU throttle 命令是生产 GPU 故障排查常用手段 ✅ 为推理引擎 SLO 告警设计提供基准

丢弃理由： 无

标签： #chaos-engineering #K8s #GPU #fault-injection #SRE #nvidia-smi

✅ 条目 4：Ekka — 静默错误自动诊断（vLLM Gemma 3 准确率下降 30% 无报错）

来源： https://arxiv.org/html/2606.04594v1
发布时间： 2026 年 6 月
可信度： ★★★★★（arXiv 新论文，含真实静默错误案例）
工程类型： 静默错误 / 自动化诊断

核心静默错误案例（vLLM Gemma 3）： - Hellaswag benchmark 准确率下降近 30% - 无任何 runtime error 或 warning - 根因：sliding window attention 误用（深层模型栈中的细微 bug） - 开发者花了数月才定位——典型的静默失败

三类症状： 1. Accuracy regression — 标准 benchmark 性能下降但输出"正常" 2. Inconsistent output — 相同输入在不同框架/配置下结果不同 3. Bogus output — 无意义、重复循环、乱码

其他静默错误： Malformed JSON、broken tool calls（破坏下游解析）

保留理由： ✅ 真实生产静默错误——30% 准确率下降无报错，比 crash 更危险 ✅ 静默错误是 2026 年 LLM 推理最需监控的盲区 ✅ 三类症状分类可直接映射到监控规则 ✅ 强调 benchmark 监控（上线前基准 + 上线后持续测）是唯一发现路径

丢弃理由： 无

标签： #silent-error #vLLM #monitoring #benchmark-regression #Gemma3

✅ 条目 5：GRIEF — LLM Serving 系统模糊测试发现安全漏洞

来源： https://arxiv.org/html/2605.11202v1
发布时间： 2026 年 5 月
可信度： ★★★★☆（学术论文 + 真实漏洞发现）
工程类型： 安全测试 / 模糊测试

核心发现（真实漏洞案例）：

跨请求干扰（Cross-request interference）： - API-valid 并发负载使 victim 请求输出损坏 - 一个干扰请求使无关 victim 的 TTFT 膨胀 1,361×，随后完全 stall - 隔离边界被违反，但不产生 crash、malformed response 或显式 server error

Performance Pathologies（vLLM latency bug）： - 触发条件：文档化的、API-valid 请求参数组合 - 一个请求形状先使无关 victim TTFT 膨胀 1361 倍，然后使其完全 stall - 这个 bug 存在于多个 serving mode，表明隔离 bug 不是单一 cache 路径问题

保留理由： ✅ API-valid 并发请求即可触发性能病理——这是生产多租户场景的共性风险 ✅ 1361× TTFT 膨胀是可量化的生产 SLO 破坏案例 ✅ 隔离边界违反（无 crash）是最难检测的安全+可靠性复合问题 ✅ 对 vLLM 调度器和共享 cache 的理解有工程直接价值

丢弃理由： 无

标签： #fuzzing #security #vLLM #cross-tenant #performance-pathology

✅ 条目 6：ISO-Bench — Coding Agent 能否优化真实推理引擎？

来源： https://arxiv.org/html/2602.19594v1
发布时间： 2026 年 2 月（2026 年 6 月仍有参考价值）
可信度： ★★★★☆（arXiv，有 benchmark 命令和评估方法）
工程类型： Coding Agent 评估 / 推理引擎优化

核心数据集： - 54 个优化任务（39 来自 vLLM，15 来自 SGLang） - 每个任务含：repo snapshot + throughput/latency benchmark + correctness tests - 来自真实 commit 的 PR analysis

评估命令（原文提取）：

Stage 3: PR Analysis — 每个 commit 的 pull request 含：
- Benchmark model
- Evaluation commands
- Performance claims from PR discussion

双重评估框架： - Hard metrics — 真正的成功 vs lucky wins - 传统 metrics 可能高估 agent 能力

保留理由： ✅ 54 个真实 vLLM/SGLang 优化任务，有 benchmark 命令 ✅ Coding Agent 优化推理引擎能力的系统性评估 ✅ Dual evaluation framework（hard vs soft）是 Agent 代码质量评估的方法论参考

丢弃理由： 无

标签： #coding-agent #vLLM #SGLang #benchmark #agent-evaluation

✅ 条目 7：Agent Memory Below the Prompt — MLX KV Cache 工程笔记

来源： https://arxiv.org/html/2603.04428v1
发布时间： 2026 年 3 月
可信度： ★★★★☆（含 MLX 真实错误表）
工程类型： 边缘推理 / KV Cache / 错误模式

MLX 工程笔记（真实错误表）：

症状 根因 修复
Cache appears empty after prefill Missing mx.eval() after cache update Evaluate after update
OOM during batch Graph accumulates without clearing Evaluate per iteration
Zeros after disk reload loaded tensors not evaluated Evaluate after load
Quantization corruption Scales/biases lazy Evaluate quantize output
Attention NaNs Q4 tensors invalid post-load Validate dtype/shape
Batch hangs Merge built graph but not executed Evaluate before attention

保留理由： ✅ 6 个真实 MLX KV cache 错误模式 + 修复方案——可直接用于边缘推理调试 ✅ Lazy evaluation 的 failure modes 是 Apple Silicon MLX 部署的共性痛点 ✅ Q4 quantization + eval 的问题是生产量化部署的常见坑

丢弃理由： 无

标签： #MLX #KV-cache #Apple-Silicon #lazy-evaluation #quantization

✅ 条目 8：A First Look at Bugs in LLM Inference Engines（旧文补充根因分析）

来源： https://arxiv.org/pdf/2506.09713
发布时间： 2025 年 6 月
可信度： ★★★★★（完整 PDF，含错误消息示例）
工程类型： Bug 根因分析

真实错误消息示例（Llama.cpp issue #1737）：

Metal backend incompatibility — ggml_view_3d memory copy operation crash

错误分布（按阶段）： - Engine setup — 97% crash rate - Model conversion — 混合症状 - Inference/serving — 多种非 crash 症状

保留理由： ✅ 真实错误消息文本可直接用于错误匹配规则 ✅ 阶段分布数据是告警优先级设计的依据

丢弃理由： 无（作为条目 1 补充）

标签： #LLM-inference #bug-analysis #error-messages

✅ 条目 9：vLLM OOM Errors: Root Cause Diagnosis Guide — 四大根因 + 修复

来源： https://www.paralleliq.ai/blog/vllm-oom-errors-root-cause-diagnosis
发布时间： 2026 年 5 月
可信度： ★★★★☆（Sam Hosseini，GPU 工程作者）
工程类型： 生产排障 / OOM 诊断

四大根因 + Signature + Fix：

1. KV Cache Overflow - Signature: OOM 发生在长请求，短请求成功；内存随 context length 线性增长 - Fix: --swap-space（KV cache offloading）、--max-model-len 减少、sliding window attention

2. Batch Size Misconfiguration - Signature: OOM 在 startup 或 first batch；内存从开始就平坦且高 - Fix: 切换到 continuous batching（vLLM/TGI/SGLang 均支持）

3. Memory Fragmentation - 多次分配/释放后，总可用内存够但无连续块 - Fix: 调整 gpu_memory_utilization、定期重启

4. Tensor Parallelism Misconfiguration - TP 度大于可用 GPU 数 - Fix: 确保 TP ≤ GPU 数量

保留理由： ✅ 四大根因 + signature 对应关系——生产 OOM 排障的直接检查清单 ✅ 每个 fix 有具体参数名（--swap-space、--max-model-len）——可直接查文档 ✅ OOM 不是随机的，有可预测模式——这是工程师需要建立的mental model

丢弃理由： 无

标签： #vLLM #OOM #troubleshooting #KV-cache #production

✅ 条目 10：SGLang Production Deployment — RadixAttention + benchmark 代码

来源： https://www.spheron.network/blog/sglang-production-deployment-guide
发布时间： 2026 年
可信度： ★★★★☆（含真实 Python benchmark 代码）
工程类型： 部署指南 / 性能调优

核心 benchmark 代码：

async def benchmark():
    # First request builds KV cache
    response = await client.chat.completions.create(
        model="llama3",
        messages=[{"role": "system", "content": system_prompt},
                  {"role": "user", "content": user_turn}]
    )
    # Subsequent requests reuse cache
    asyncio.run(benchmark())

# Expected: first ~280-320ms TTFT, subsequent 80-120ms

Prefix Caching 杀死 cache hit rate 的三个杀手： 1. System prompt 不完全一致（空格、换行差异） 2. 动态内容注入导致 token 序列变化 3. chunked encoding 导致的边界不一致

保留理由： ✅ 真实 Python benchmark 代码可复现 ✅ TTFT 数字目标（280-320ms → 80-120ms）是可验证的 SLO ✅ Prefix caching 杀手是 RAG/Agent 多轮场景的常见 bug 根因

丢弃理由： 无

标签： #SGLang #RadixAttention #prefix-caching #benchmark #TTFT

✅ 条目 11：KV Cache Optimization Guide 2026 — 工程量化数据

来源： https://www.digitalapplied.com/blog/kv-cache-optimization-techniques-2026-engineering-guide
发布时间： 2026 年
可信度： ★★★★☆（量化数据 + 工程判断）
工程类型： KV 优化 / 成本工程

核心数据： - 32K tokens：KV memory 开始超过 parameter memory - 128K tokens：KV cache dominates - 1M tokens：KV cache 占 70-90% GPU VRAM，60-85% wall-clock per token

Prefix Caching 节省： - Cache hit 时 85-95% cost savings - Agent loops/multi-tenant SaaS 场景 60-85% hit rate 可达 - Per-call cost 降低 5-12×

MLA（DeepSeek V2/V3/V4）vs GQA： - MLA: 7-14× KV cache 压缩 - GQA: 4-8× 压缩 - MLA 是 2026 年 KV 效率的架构终极形态

保留理由： ✅ 量化数字（70-90% VRAM、5-12× cost 节省）是容量规划和成本估算的直接输入 ✅ MLA vs GQA 对比是 2026 年模型选型的重要参考 ✅ "Every production guide ships paged attention by default"——这句话本身是工程最佳实践的总结

丢弃理由： 无

标签： #KV-cache #cost-optimization #DeepSeek-MLA #paged-attention

✅ 条目 12：AI Inference Engineering Playbook 2026

来源： https://www.the-ai-corner.com/p/ai-inference-engineering-playbook-2026
发布时间： 2026 年
可信度： ★★★★☆（Substack 工程分析）
工程类型： 推理工程 / 成本分析

核心洞察： - 每次模型回答时，GPU 上运行两个独立操作：prompt burst（计算驱动）+ token-by-token decode（内存带宽驱动） - 这个 split 决定了 latency 和 bill——推理工程就是 bend 这个 split 的工艺 - 量化敏感性图：哪些层容忍压缩，哪些层会毒化质量

保留理由： ✅ Prompt burst vs decode 的两阶段模型是推理工程的核心 mental model ✅ 量化敏感性图概念对量化方案选择有直接指导价值

丢弃理由： 无

标签： #inference-engineering #latency #quantization #cost-optimization

✅ 条目 13：Addy Osmani LLM Coding Workflow 2026

来源： https://addyo.substack.com/p/my-llm-coding-workflow-going-into
发布时间： 2026 年
可信度： ★★★★☆（Google 工程师，工程实践）
工程类型： 工程实践 / 工具使用

核心工程实践： - Specs before code——定义问题和方案再让 LLM 生成 - Git history 作为 AI 协作的记忆——AI 能解析 diffs，用 git bisect 定位 bug - Commit history 整洁是 AI 调试有效的前提

保留理由： ✅ 工程 discipline 视角——"AI 写代码好了"不等于"process 可以放松" ✅ Git bisect + AI 的组合是实际调试工作流

丢弃理由： 无

标签： #LLM-workflow #engineering-practice #Addy-Osmani #git

✅ 条目 14：What is Inference Engineering — Pragmatic Engineer

来源： https://newsletter.pragmaticengineer.com/p/what-is-inference-engineering
发布时间： 2026 年 3 月
可信度： ★★★★☆（Gergely Orosz + Philip Kiely）
工程类型： 工程定义 / 角色分析

核心内容： - Inference engineer 拥有四件事：hardware selection、serving framework 配置、cost-per-token 优化、reliability SLA - 推理工程师横跨 CUDA 到 Kubernetes，在追求更快、更便宜、更可靠的生成式 AI 服务

保留理由： ✅ Inference engineering 角色的系统定义——适合作为团队内部角色职责文档参考

丢弃理由： 无

标签： #inference-engineering #role-definition #career

✅ 条目 15：Why Does the LLM Stop Computing — 用户报告失败研究

来源： https://arxiv.org/html/2601.13655v1
发布时间： 2026 年 1 月
可信度： ★★★★☆（arXiv，用户报告失败大规模研究）
工程类型： 失败归因 / 用户报告分析

核心数据： - Memory Issue [A.5]（79 instances）——第二大成因 - GPU OOM [A.5.1]（54 instances） - RAM OOM [A.5.2]（18 instances） - KV Cache Allocation Error [A.5.3]（7 instances）——LLM 特有，sequence length 超过 KV cache 容量 - Incorrect Configuration [B.1]（139 instances）——最大根因 - Inference Configuration Error [B.1.1]（91 instances）——max_model_len 配置错误导致 crash - Device/Cluster Error [A.9]（29 instances） - Unsupported Operation/Module [A.4]（41 instances）

保留理由： ✅ 大规模用户报告统计（数百个真实失败案例） ✅ KV Cache Allocation Error 是 LLM 特有的新 failure mode ✅ max_model_len 配置错误是生产部署的高频事故根因

丢弃理由： 无

标签： #failure-analysis #OOM #KV-cache #configuration-error #user-reports

分类标签

#LLM-inference #bug-taxonomy #OOM #silent-error #chaos-engineering #fuzzing #SRE #vLLM #SGLang #RadixAttention #KV-cache #prefix-caching #MLX #Apple-Silicon #agentic-frameworks #coding-agent #inference-engineering #monitoring #benchmark #GPU #K8s

建议写入路径

/shared/research-kb/inbox/jay/2026-06-28-1450-engineering-filter-inference-bugs-agent-debugging.md（本文件）

本次筛选决策摘要

决策 数量 理由
✅ 保留 15 均含真实错误/命令/bug数据/性能数字
❌ 丢弃 0 无

本轮高价值条目 TOP 5： 1. 条目 1（arXiv bug 分类） — 929 bugs 统计，35%+ 非 crash 症状——静默失败是 2026 年最大监控盲区 2. 条目 4（Ekka 静默错误） — vLLM Gemma 3 准确率下降 30% 无报错——benchmark 监控是唯一发现路径 3. 条目 5（GRIEF fuzzing） — API-valid 请求使 TTFT 膨胀 1361×——多租户隔离是生产红线 4. 条目 9（vLLM OOM 诊断） — 四大根因 + signature + fix——生产 OOM 排障检查清单 5. 条目 15（LLM 停止计算研究） — max_model_len 配置错误 + KV cache allocation error——高频生产事故根因

后续行动建议

  1. 精读条目 4（Ekka）——benchmark 监控是发现静默错误的唯一手段，建议在 KB 中建立专项 "LLM 推理静默错误监控" 主题页
  2. 精读条目 9（OOM Guide）——四大根因 + signature 可作为 vLLM 生产部署 checklist
  3. 关注条目 5（GRIEF）——vLLM 调度器和 cache 隔离问题的具体 bug 报告值得进一步追踪
  4. 条目 1 + 15 互补使用——条目 1 提供引擎层面 bug 分类，条目 15 提供用户视角失败根因，两者结合可覆盖 2026 年推理系统的主要故障模式