Ekka：自动定位 LLM 推理框架中的「静默错误」

在大模型推理框架迭代越来越快的今天，一类难以察觉的「静默错误」正在成为开发者最头疼的问题：框架照常运行、返回格式正常的回答，但输出质量已经悄悄下降甚至完全错误。近日被 ICML 2026 接收的论文《Ekka: Automated Diagnosis of Silent Errors in LLM Inference》提出了一套自动化诊断系统 Ekka，把定位这类 bug 的过程从「数月手动排查」压缩到「小时级自动报告」。

什么是静默错误

静默错误（silent error）是指 LLM 推理框架在运行中产生的、不会触发任何报错或断言失败的错误。它不会让服务崩溃，也不会返回异常状态码——只会吐出一段看似合理、实际上已经偏得很远的文本。论文作者将这类 bug 比作「语义鸿沟」：表面症状（某个 benchmark 分数掉了）和根因（注意力窗口配错、kernel 数值精度漂移）之间隔着巨大的距离，导致定位过程异常漫长。

以论文给出的一个真实案例为例：vLLM 在服务 Gemma 3 时，HellaSwag 基准成绩相对 HuggingFace 参考实现下降了约 30%，但运行过程没有任何告警。对于一道简单的外卖费用计算题，参考实现给出正确答案 $29，而 vLLM 输出的中间步骤突然变成「15 + 15 + 15 = 45」，最终给出 $100 的错误答案。开发者花了三个月才定位到根因——某项配置错误地把滑窗注意力（sliding-window attention）应用到了模型的全部层，而非原本设计的「每 6 层中 5 层」。

对 90 个真实 bug 的实证研究

为支撑系统设计，论文团队对 vLLM 和 SGLang 的 GitHub issue 中收集到的 90 个真实静默错误进行了系统分析，其中 70 个已关闭、20 个未关闭（留作评估）。三个关键发现直接塑造了 Ekka 的设计：

症状几乎无法指向根因：43.8% 的症状是「准确率回归」，即输出文本表面正常但 benchmark 分数下降；其余多为乱码、重复循环、输出不一致等。
根因遍布整个技术栈：框架实现占 30.6%、模型实现占 25.5%、kernel 后端占 24.5%，另有约 19.4% 属于纯数值精度问题（浮点不稳定但无逻辑缺陷）。值得注意的是，约一半的静默错误起源于「模型栈」内部，因此诊断工具必须 model-aware，不能把模型当成黑盒。
开发者本质上已经在「手工差分调试」：超过 60% 的 issue 中，开发者会通过切换配置、最小化复现来排查；约一半会跨框架对比输出，并伴随大量手工 dump 和检查 activation。Ekka 的目标就是把这条工作流自动化。

Ekka 的工作方式

给定模型、样例 prompt、两个框架的配置文件，以及「目标框架（疑似有 bug）」与「参考框架（可信）」的指定，Ekka 输出一个按嫌疑度排序的组件报告。其流程分三步：

收集上下文：解析两个代码库为代码索引（code index），将每个模型的结构压缩为 Model Tree，并用 PyTorch forward hook 在复现 bug 的同时记录 activation 与调用序列。
自动对齐：处理两个框架在模块命名、内存布局、算子融合上的差异，把不同框架的中间状态映射到同一棵 Model Tree 上，使后续比较成为可能。
智能体诊断：以 agentic 方式遍历组件，根据差异定位最可能的发散点，生成可读的嫌疑报告。

之所以需要这一整套自动对齐，是因为手工对比 tensor 极度痛苦——优化过的推理引擎在内部模块结构、命名、内存布局、融合算子上都和参考实现差异巨大，直接逐张量比对几乎不可能。

实验结果与社区影响

论文在 17 个来自 vLLM 和 SGLang 的真实 bug 上评估 Ekka，达到 80% 的 pass@1 诊断准确率，单个用例成本约 $30。更值得关注的是，Ekka 已经在实际运行中发现了 4 个新 bug，并获得了对应开发者的确认。这意味着它不只是「事后复盘工具」，而是能直接为推理框架贡献上游修复。

对使用 vLLM、SGLang 等主流 LLM 推理框架的工程团队而言，Ekka 的思路——把诊断建模为跨框架的差分调试，并通过自动对齐弥补参考实现与优化引擎之间的语义鸿沟——具有直接借鉴价值。论文和相关信息将在 ICML 2026 Poster Session 5（Hall A, #2405，7 月 8 日 17:00–18:45 KST）公开交流。