2026年8月4日、DeepSeekの公式ステータスページは2件のAPI性能劣化インシデントを記録しました。
最初のインシデントは1時間18分続き、UTCの02:02から03:20までの間に発生し、DeepSeek V4 Flash、V4 Pro、およびExpert Modeに影響を与えました。2件目のインシデントは36分続き、UTCの03:43から04:20までの間に発生し、DeepSeek V4 Flash APIに影響を与えました。
両方のインシデントはその後解決されました。OpenCodeはまた、DeepSeek Flashが前例のない需要によりキャパシティの問題を抱えていると報告しました。しかし、DeepSeekの公式ステータスページは劣化した性能のみを確認し、根本原因は公表しませんでした。
要約
- DeepSeekの公式ステータスページは、2026年8月4日にV4 Flashに影響を与える2件の性能劣化インシデントを記録しました。
- 直接プロバイダー統合は、同じモデルが他の場所で利用可能であっても、単一の障害点を作成します。
- AIHubMixは、上流ルートが再試行可能なエラーを返した場合、複数のプロバイダー チャンネルで同じモデルを再試行できます。
- 主要モデルのすべてのプロバイダーチャンネルが失敗した場合、キー レベルのモデルフォールバックがリクエストを構成されたバックアップモデルに切り替えることができます。
- マルチプロバイダー ルーティングは、1 つのエンドポイントへの依存を減らしますが、相関した障害やゲートウェイ レベルのリスクを排除することはできません。
このようなインシデントは、重要なインフラストラクチャの原則を浮き彫りにします:
信頼できるモデルは、単一のプロバイダーエンドポイントを介してアクセスされる場合、十分ではありません。
1つのモデルが1つのプロバイダーを意味する必要はありません
アプリケーションが1つのプロバイダーに直接接続すると、そのエンドポイントは単一の障害点になります。
プロバイダーが障害を経験したり、レート制限に達したり、レイテンシのスパイクが発生した場合、アプリケーションはリクエストを送信する他の場所がありません。ユーザーは、同じモデルが他のインフラストラクチャプロバイダーを介して利用可能であっても、タイムアウトやエラーを目にします。
AIHubMixは、モデルをそれを提供するプロバイダーから分離します。
たとえば、DeepSeek V4 Flashは、DeepSeek、Baidu、DeepInfra、Alibaba Cloudなど、AIHubMixの複数のプロバイダーを介して利用可能です。アプリケーションは、AIHubMixが利用可能な上流ルートを管理する間、1つのOpenAI互換APIエンドポイントを使用し続けます。
これにより、2つの異なる信頼性レイヤーが作成されます。
レイヤー 1: プロバイダー フェイルオーバー
プロバイダー フェイルオーバーは、背後にあるインフラストラクチャ プロバイダーを切り替えながら、要求されたモデルを変更しません。
DeepSeek V4 FlashへのリクエストがAIHubMixに到達すると、ゲートウェイは適格なプロバイダーチャンネルを選択します。そのチャンネルが応答が始まる前に再試行可能なエラーを返した場合、AIHubMixは同じモデルの別の利用可能なチャンネルを試すことができます。
リクエストパスは次のようになります:
- プロバイダーAを介してDeepSeek V4 Flashを試す。
- プロバイダーAがタイムアウト、5xxエラー、または再試行可能なキャパシティエラーを返します。
- プロバイダーBを介して同じDeepSeek V4 Flashモデルを試す。
- リクエストが成功するか、すべての適格なチャンネルが尽きるまで続けます。
クライアントは、複数のプロバイダーSDKを統合したり、別々のAPIキーを管理したり、自分自身の再試行ロジックを実装したりする必要はありません。
これがプロバイダー レベルのフェイルオーバーです: プロバイダーが変更されますが、要求されたモデルはそのままです。
レイヤー 2: モデル フォールバック
プロバイダー フェイルオーバーは、主要モデルのすべての利用可能なプロバイダーが利用できない場合には役立ちません。
したがって、AIHubMixは2番目の信頼性レイヤー、モデルフォールバックをサポートしています。
ユーザーは、各APIキーのバックアップモデルの順序付きリストを構成できます。主要モデルのすべての適格なチャンネルが再試行可能な失敗を返した後、AIHubMixはフォールバックリストの次のモデルに移動します。
たとえば:
- 主要:
deepseek-v4-flash - 最初のフォールバック:
gpt-5.4 - 2番目のフォールバック:
gemini-3.1-pro-preview
フォールバックはAIHubMixゲートウェイ内で実行されます。既存のアプリケーションは、追加のルーティングパラメータを送信したり、クライアントコードを変更したりする必要はありません。
請求は、最終的に成功した応答を返したモデルに基づいて行われます。開発者は、応答ヘッダーを通じてフォールバックの動作を確認できます:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
完全な構成とトリガールールは、AIHubMixモデルマッピングとフォールバックに文書化されています。
自動フェイルオーバーが処理できること
プロバイダー フェイルオーバーは、次のような上流インフラストラクチャの問題から回復するように設計されています:
- プロバイダーのタイムアウト
- 接続の失敗
- 再試行可能な5xx応答
- プロバイダーのレート制限とキャパシティエラー
- 上流チャネルの一時的な利用不可
これらの障害が応答が始まる前に発生した場合、AIHubMixは透過的に別のルートを試すことができます。
フェイルオーバーが解決できないこと
マルチプロバイダー ルーティングは可用性を向上させますが、ゲートウェイを無敵にするわけではありません。
フォールバックは次の場合にはトリガーされません:
- ユーザーのAIHubMix APIキーが無効、期限切れ、またはクォータを超えている
- リクエスト自体が無効
- クライアントが切断されるか、自身のタイムアウトに達する
- ストリーミング応答がすでに開始されている
- 特定のプロバイダーチャンネルが明示的に選択されている
- 障害がすべてのプロバイダーまたはゲートウェイ自体に影響を与える
プロバイダーの障害は相関している場合もあります。複数のプロバイダーが同じ基盤となるインフラストラクチャ、モデルリリース、または地域ネットワークに依存している可能性があります。このため、マルチプロバイダーの可用性は、単にプロバイダーの数から推測するのではなく、実際のトラフィックで測定する必要があります。
なぜアグリゲーターは直接エンドポイントよりも信頼性が高いのか
公式APIを直接呼び出すと、アプリケーションにはモデルへの1つのルートが与えられます。
マルチプロバイダーゲートウェイは、いくつかのルートを提供します。
これらのプロバイダーのルートが独立して失敗した場合、ゲートウェイは劣化したエンドポイントを回避して、アプリケーションに障害を露出させることなくルーティングできます。これにより、単一のプロバイダーへの依存が減少し、直接の単一プロバイダー統合よりも高い可用性を提供できます。
違いはアーキテクチャにあります:
- 直接API: 1つのモデル、1つのプロバイダー、1つの障害ドメイン
- AIHubMix: 1つのモデル、複数のプロバイダー、自動フェイルオーバー
- モデルフォールバックを持つAIHubMix: 複数のプロバイダーとバックアップモデル
目標は、次にどのプロバイダーが失敗するかを予測することではありません。上流のインシデントを内部のルーティングイベントにし、顧客に対する障害を回避することです。
次のプロバイダーインシデントに備える
DeepSeek V4 Flashは回復しましたが、一時的なキャパシティ制約、レート制限、上流の障害は、プロダクションAIインフラストラクチャの通常の部分です。
プロバイダーが不安定になるたびに、アプリケーションがコードを変更する必要はありません。
AIHubMixを使用すると、開発者は1つのAPIを介して複数のプロバイダーにアクセスし、利用可能なチャネルで同じモデルを自動的に再試行し、追加の保護レイヤーとしてバックアップモデルを構成できます。
利用可能なモデルとプロバイダーを探るには、aihubmix.com/modelsをご覧ください。
よくある質問
マルチプロバイダーフェイルオーバーとは何ですか？
現在のルートが再試行可能な失敗を返した場合、別の適格なプロバイダーを介して同じモデルを自動的に再試行します。
モデルフォールバックはどのように異なりますか？
プロバイダーフェイルオーバーはモデルを変更しません。モデルフォールバックは、主要モデルのすべての適格なチャンネルが失敗した後にのみ、構成されたバックアップモデルに切り替えます。
どのような障害がフェイルオーバーをトリガーできますか？
一般的なトリガーには、タイムアウト、接続の失敗、再試行可能な5xx応答、レート制限、一時的なキャパシティエラーが含まれます。
フェイルオーバーはゼロダウンタイムを保証しますか？
いいえ。相関するプロバイダーの障害、ゲートウェイレベルのインシデント、再試行不可能なエラー、ストリーミングが開始された後の障害は、クライアントに到達する可能性があります。
アプリケーションコードを変更する必要がありますか？
追加のルーティングロジックは必要ありません。アプリケーションはAIHubMixのOpenAI互換エンドポイントを使用し続け、バックアップモデルはAPIキーのレベルで構成できます。