你通过一个订票平台同时查询多家航空公司：页面显示“预订成功”，行程单却悄悄少了一段。多模型 AI 应用也会遇到类似问题。它向模型发出的请求返回了 HTTP 200——意思是通信成功——但对话记录可能已经丢失，工具调用也可能被拼坏。服务器不报警，用户只觉得 AI 忽然变笨。
论文 FailureAtlas 研究的正是这类故障。它关注 LLM Gateway（大模型网关）——应用与多家模型服务之间的统一入口。网关负责选择供应商、转发请求、限制流量和记录用量，类似一个同时连接多家航空公司的订票平台。它让应用更容易切换模型，也把网络、并发、流式传输和对话状态等问题集中到了一层。
作者 Vishal Pandey 和 Gopal Singh 整理了 5 个故障条目，其中两个来自第一手压力测试，三个来自公开 bug 报告；每个条目都附有机制层面的根因分析，三个提供独立复现脚本。不过，目前材料只有论文这一条信源，相关复现条件和影响范围仍需结合脚本与原始记录核验。
先问两件事：坏在哪里，能不能看见
FailureAtlas 没有按“页面打不开”“结果错误”这类表面症状分类。作者认为，同样一个 HTTP 429 限流错误，背后可能是重试过多，也可能是计数器没有释放，修法完全不同。
它因此画了两条轴。第一条按故障来源分成五层：
- Network/Transport：网络与传输，例如同步操作堵住异步事件循环。所谓事件循环，可以理解为一个不断轮流处理任务的调度员；某项工作迟迟不交还控制权，其他请求也会一起排队。
- Streaming/Protocol：流式传输与协议。模型往往一小段一小段地返回内容，网关必须记住这些片段分别属于哪个工具调用。
- State/Session：状态与会话，包括对话历史的丢失、串线或覆盖。
- Model Behavior：模型行为，例如输出格式或指令遵循发生变化。
- Governance/Cost：治理与成本，包括限流、重试、资源计数和费用控制。
第二条轴更直观：故障是 Loud，还是 Silent。Loud 是“响亮故障”，会产生 5xx、429、崩溃或超时，现有监控通常能看到。Silent 是静默故障：请求表面成功，实际内容或状态已经损坏。
这个二维框架的价值不只在整理名词。来源层提示工程师去哪里找根因；可检测性则提醒团队，它现有的报警系统是否根本看不见问题。
最麻烦的故障，长得像一次成功
论文重点讨论了两个 Silent 条目。
第一个发生在并发对话中。两个协程——可交替运行的轻量任务——几乎同时读取同一段会话历史，各自加入新消息，再把结果写回。后完成的任务覆盖先完成的任务，于是一轮对话无声消失。模型拿到的上下文不完整，回答质量随之下降，但每个请求仍返回 HTTP 200，延迟、错误率和容器健康状态也没有异常。
作者是在 ContinuityBench（论文中简称 CB，用于衡量多轮对话连续性的评测）压力测试中发现它的：高并发运行时，角色一致性等语义指标出现无法解释的下降。进一步检查才定位到会话状态的并发竞态。论文给出的修复思路是按会话隔离状态，在发生异步等待前复制各自的消息数组，并对每个会话实施读写保护。
第二个 Silent 条目出现在流式工具调用中。模型可以在一次回答里并行要求多个工具执行任务，每个工具调用本应带有不同索引。某个代理却在处理每个流式片段时都把计数器重置，导致所有片段都被标为 index=0。客户端于是把两个独立工具的参数拼成一串损坏的 JSON——一种结构化数据格式。
更误导人的是，错误可能到下一轮对话才显现。损坏的内容先被存进历史记录，随后重新发送时才触发 JSONDecodeError。表面症状像网络或解析问题，真正根因却在上一轮的流式协议处理。论文称，该问题是在开发者手工检查原始 SSE 数据块后才被识别；SSE 是服务器持续向客户端推送事件的一种流式传输方式。
响亮故障也会被网关放大
另外三个条目属于 Loud，但同样展示了网关如何把小故障放大。
一次压力测试中，上游供应商短暂返回 502，100 个并发代理按照相同固定间隔重试。它们很快同步成“惊群”：所有请求同时涌回，再次撞上供应商的限流窗口。论文报告，尽管最初只是短暂波动，最终仍有 25% 的请求永久失败。作者的复现实验把固定间隔重试与“指数退避加随机抖动”并排比较；后者的思路是逐次延长等待时间，并让各请求稍微错开，避免再次集体冲击上游。
另一个问题来自 Redis 信号量。Redis 是常被用来共享计数状态的存储系统；信号量在这里记录正在处理的请求数。如果上游超时或返回 5xx，而异常路径漏掉了计数递减，系统就会以为请求一直没有结束。错误积累后，计数器达到上限，网关开始持续返回 429，即使实际上已经没有请求在运行。论文建议为计数设置生存期限，或用 try/finally 保证任何退出路径都会释放资源。
还有一种故障来自健康检查本身。异步 Python 网关如果在 /health 接口中执行同步数据库查询，这次查询就可能堵住整个事件循环；探针频繁调用健康接口，反而制造连续的短时中断。作者建议改用异步驱动，或把同步操作移到单独的线程池。
为什么这张地图值得关注
网关原本是为了降低复杂度：统一不同供应商的接口，在一处完成负载均衡、故障切换与限流。FailureAtlas 提醒我们，它并非透明管道，而是一个会产生自身故障的新系统层。经典的竞态、资源泄漏和惊群，在这里会表现为对话丢失、工具参数损坏、费用失控或 API key 被永久限流。
论文最重要的判断是，监控不能只问“请求成功了吗”，还要问“语义是否完好”。所谓语义级可观测性，就是持续检查对话历史是否完整、工具调用参数是否正确，以及输出质量是否异常。否则，一个绿灯满屏的控制台，可能正掩盖用户真正遇到的问题。
不过，作者把 Silent 概括为运营影响最严重的故障，目前证据仍偏薄：目录总共只有 5 个条目，其中两个属于 Silent。更稳妥的说法是，这项工作证明了静默故障可能非常严重，也指出了传统监控的一处盲区；它还不足以确定整个行业中哪类故障最常见或损失最大。
局限与未知
- 全部结果目前来自同一篇论文。虽然作者称条目经过验证，正文也说明了筛选过程，但原始 bug 记录、脚本和具体环境没有在供稿中分别核验。
- 目录只有 5 个条目，尚不能代表不同网关、版本和部署方式的总体故障分布；
Model Behavior一层目前甚至没有符合作者证据标准的条目。 - 论文没有为这些故障统一报告发生概率、受影响版本和数据损坏范围。“通过所有标准健康检查”也取决于团队究竟部署了哪些检查。FailureAtlas 更像一张可扩展的起始地图，而不是已经完成的行业事故统计。