在2026年8月4日，DeepSeek的官方状态页面记录了两起API性能下降事件。
第一次事件持续了1小时18分钟，从02:02到03:20 UTC，影响了DeepSeek V4 Flash、V4 Pro和专家模式。第二次事件持续了36分钟，从03:43到04:20 UTC，影响了DeepSeek V4 Flash API。
这两起事件现已解决。OpenCode还报告称，由于前所未有的需求，DeepSeek Flash正面临容量问题。然而，DeepSeek的官方状态页面仅确认了性能下降，并未公布根本原因。
简而言之
- DeepSeek的官方状态页面记录了2026年8月4日影响V4 Flash的两起性能下降事件。
- 直接的提供商集成创建了单点故障，即使同一模型在其他地方可用。
- 当上游路由返回可重试错误时，AIHubMix可以在多个提供商通道之间重试相同的模型。
- 如果主要模型的所有提供商通道都失败，关键级模型回退可以将请求切换到配置的备份模型。
- 多提供商路由减少了对单个端点的依赖，但无法消除相关故障或网关级风险。
这样的事件突显了一个重要的基础设施原则：
如果通过单个提供商端点访问，可靠的模型是不够的。
一个模型不必意味着一个提供商
当应用程序直接连接到一个提供商时，该端点就成为单点故障。
如果提供商发生故障、达到速率限制或遭遇延迟峰值，应用程序就没有其他地方可以发送请求。即使同一模型通过其他基础设施提供商仍然可用，用户也会看到超时和错误。
AIHubMix将模型与提供它的提供商分开。
例如，DeepSeek V4 Flash可以通过AIHubMix的多个提供商获得，包括DeepSeek、百度、DeepInfra和阿里云。应用程序继续使用一个与OpenAI兼容的API端点，而AIHubMix管理可用的上游路由。
这创建了两个不同的可靠性层。
层1：提供商故障转移
提供商故障转移在切换后端基础设施提供商的同时保持请求的模型不变。
当对DeepSeek V4 Flash的请求到达AIHubMix时，网关选择一个合格的提供商通道。如果该通道在响应开始之前返回可重试错误，AIHubMix可以尝试另一个可用的同一模型通道。
请求路径可能如下所示：
- 通过提供商A尝试DeepSeek V4 Flash。
- 提供商A返回超时、5xx错误或可重试的容量错误。
- 通过提供商B尝试相同的DeepSeek V4 Flash模型。
- 继续直到请求成功或所有合格通道耗尽。
客户端无需集成多个提供商SDK、管理单独的API密钥或实现自己的重试逻辑。
这就是提供商级故障转移：提供商改变，但请求的模型保持不变。
层2：模型回退
如果主要模型的每个可用提供商都不可用，提供商故障转移将无济于事。
因此，AIHubMix支持第二个可靠性层：模型回退。
用户可以为每个API密钥配置一个备份模型的有序列表。在每个主要模型的合格通道返回可重试失败后，AIHubMix会转到回退列表中的下一个模型。
例如：
- 主要模型：
deepseek-v4-flash - 第一次回退：
gpt-5.4 - 第二次回退：
gemini-3.1-pro-preview
回退是在AIHubMix网关内部执行的。现有应用程序无需发送额外的路由参数或更改其客户端代码。
计费基于最终返回成功响应的模型。开发人员可以通过响应头验证回退行为：
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
完整的配置和触发规则已在AIHubMix模型映射和回退中记录。
自动故障转移可以处理什么
提供商故障转移旨在从上游基础设施问题中恢复，例如：
- 提供商超时
- 连接失败
- 可重试的5xx响应
- 提供商速率限制和容量错误
- 上游通道的临时不可用
当这些故障发生在响应开始之前，AIHubMix可以透明地尝试另一条路由。
故障转移无法解决什么
多提供商路由提高了可用性，但并不使网关无懈可击。
当以下情况发生时，回退不会被触发：
- 用户的AIHubMix API密钥无效、过期或超出配额
- 请求本身无效
- 客户端断开连接或达到自己的超时
- 流式响应已经开始
- 明确选择了特定的提供商通道
- 故障影响每个提供商或网关本身
提供商故障也可能是相关的。多个提供商可能依赖于相同的基础设施、模型发布或区域网络。因此，多提供商可用性应通过真实流量进行测量，而不是仅仅根据提供商的数量进行假设。
为什么聚合器比直接端点更可靠
直接调用官方API为应用程序提供了一条通往模型的路由。
多提供商网关为其提供了多条路由。
如果这些提供商路由独立失败，网关可以绕过性能下降的端点，而不将故障暴露给应用程序。这减少了对任何单一提供商的依赖，并且可以提供比直接单一提供商集成更高的可用性。
区别在于架构：
- 直接API：一个模型，一个提供商，一个故障域
- AIHubMix：一个模型，多个提供商，自动故障转移
- 带有模型回退的AIHubMix：多个提供商加备份模型
目标不是预测下一个将失败的提供商，而是使上游事件成为内部路由事件，而不是面向客户的故障。
为下一个提供商事件做好准备
DeepSeek V4 Flash已经恢复，但临时容量限制、速率限制和上游故障是生产AI基础设施的正常部分。
应用程序不应在每次提供商不稳定时都需要更改代码。
通过AIHubMix，开发人员可以通过一个API访问多个提供商，自动在可用通道之间重试相同的模型，并为额外的保护层配置备份模型。
在aihubmix.com/models上探索可用的模型和提供商。
常见问题
什么是多提供商故障转移？
当当前路由返回可重试失败时，它会自动通过另一个合格的提供商重试相同的模型。
模型回退有什么不同？
提供商故障转移保持模型不变。模型回退仅在所有主要模型的合格通道失败后切换到配置的备份模型。
哪些故障可以触发故障转移？
典型触发包括超时、连接失败、可重试的5xx响应、速率限制和在响应开始之前的临时容量错误。
故障转移是否保证零停机时间？
不。相关的提供商故障、网关级事件、不可重试的错误以及流式开始后的故障仍然可能到达客户端。
我需要更改我的应用程序代码吗？
不需要额外的路由逻辑。应用程序继续使用AIHubMix与OpenAI兼容的端点，而备份模型可以在API密钥级别配置。