MoE 模型 API 变慢却不报错：Microsoft FaultSense 如何定位灰色故障

MoE 模型 API 变慢却不报错：Microsoft FaultSense 如何定位灰色故障

大模型 API 有一类难排查故障：请求仍然成功，延迟却突然拉长。Microsoft Research 在 9 月公布 FaultSense，研究对象是大规模 Mixture-of-Experts 服务中的灰色故障：GPU 或通信路径性能退化，没有完全宕机，却让整条推理链变慢。

MoE 模型每次只激活部分专家，可以把模型扩展到大量 GPU，但专家并行依赖频繁的 all-to-all 通信。一个 GPU straggler 或一段异常链路会拖住同一步骤中的其他参与者。传统健康检查看到设备仍在线、请求也能完成，定位就会落入“网络、GPU、调度还是模型”的长时间排查。

FaultSense 用模型请求覆盖 GPU 通信图

FaultSense 是应用层诊断方法，不要求修改主机监控。研究团队设计了轻量 MoE 探针模型，把集群抽象成 GPU 通信图，再用少量探针覆盖所有 GPU 与通信路径。第一阶段做全局覆盖，快速找出可疑组件；第二阶段只对可疑区域深入测试，定位具体 GPU 或路径。

论文摘要称，这种两阶段算法在保持低内存开销的同时，相比逐个测试全部组件最多可减少 20 倍诊断测试。这里的“20 倍”是测试数量减少，不是模型吞吐提升，也不代表所有集群都能缩短同样比例的故障恢复时间。研究页面没有说明它已作为商业云服务正式部署。

应用层探针的优势是更接近用户请求经过的真实数据面。主机指标正常，不代表专家路由、集合通信和模型执行组合正常；探针可以沿相同路径触发问题。代价是诊断请求也会占用资源，探针模型、频率和隔离方式需要避免影响生产流量。

模型网关看到的通常只是尾延迟异常

统一模型网关或 AI 中转站首先感知到的可能是首 token 时间、完整响应时间和超时率上升，同一 provider 的部分请求慢，状态码仍是 200。盲目重试会把一份慢请求复制成多份负载，进一步压垮异常集群。路由策略应区分明确失败、持续变慢和单次抖动。

网关可以按模型、供应商、区域和请求类型记录 p50、p95、p99，并把排队时间、连接时间、首 token 与生成阶段拆开。只有完整响应时间时，很难判断问题发生在网络、上游排队、prefill 还是 decode。长上下文和高输出请求本来就慢，还需要按输入输出 token 分桶，避免把正常工作量变化误判为基础设施故障。

如果上游公开的健康状态正常，而单一模型的尾延迟持续恶化，可以先降并发、切备用供应商或限制超长任务，同时保留请求 ID 和时间窗口交给上游定位。涉及自动切换时，应用还要验证替代模型的工具调用、JSON 输出和安全策略；可用性恢复不能以业务语义悄然变化为代价。

企业自建 MoE 服务要把灰色故障写进演练

自建服务应分别演练 GPU 完全掉线、单卡降速、链路带宽下降和部分专家热点。告警既看错误率，也看分位延迟、GPU 步骤时间、通信集合与专家负载。一次诊断能定位组件还不够，隔离、流量迁移、恢复验证和重新纳入集群都要有自动化步骤。

FaultSense 提供的是一种诊断思路，不会替代容量规划、驱动与网络监控。企业可用小型探针覆盖关键路径，并与真实业务 SLO 关联；探针正常但用户请求变慢时，再检查队列、缓存、token 分布和应用重试。关键结论最好通过独立监控或第二组探针交叉确认。

如果业务通过 [AnyAIS](/) 调用多个模型，可以用统一入口记录模型、延迟与失败，并为关键任务准备可验证的备用路由。上游 GPU 灰色故障无法由网关直接修复，但良好的观测和切换策略能减少它对用户的影响。

资料来源：[Microsoft Research：FaultSense](https://www.microsoft.com/en-us/research/publication/faultsense-fault-localization-in-large-scale-mixture-of-experts-model-serving-infrastructure/)。