応答時間が不安定だった問題を修正しました
推論ゲートウェイの負荷分散に不具合があり、時間帯によって応答時間が大きくばらつく問題がありました。2026 年 9 月 2 日に修正済みで、現在は均等に分散しています。ご不便をおかけし申し訳ありません。
HAI では 1 つのモデル ID の裏側に複数の GPU や経路を用意して、負荷を分散しています。その振り分けが正しく動かず、空いている側が余っているのに一部へ処理が集中していました。
影響
処理が集中した側に当たったリクエストだけが遅くなります。偏る先は時間帯によって変わるため、「昼は速いが夜は遅い」「日によって体感が違う」という形で現れます。
複数の分散先を持つモデルはすべて影響を受けていました。修正前 7 日間の実測で、最も多く使われた 1 つが占めた割合です。
| モデル | 分散先 | 最多の 1 つが占めた割合 | 均等なら |
|---|---|---|---|
glm-5.3-flash |
2 | 80.6% | 50.0% |
deepseek-v4-flash |
9 | 57.1% | 11.1% |
gemma-4-31b-it |
6 | 48.3% | 16.7% |
qwen3.8-27b-uncensored |
6 | 42.4% | 16.7% |
HAI Go(定額サブスク)の対象モデルも同様に影響を受けていました。
もっとも影響が大きかったのは qwen3.8-27b-uncensored です。GPU 3 台構成で 1 台に偏り、当たった台によって応答時間が倍以上変わっていました。
| GPU | リクエスト数 | 平均応答 | p95 応答 |
|---|---|---|---|
| 1 台目 | 2,147 | 44.3 秒 | 168.0 秒 |
| 2 台目 | 1,786 | 19.5 秒 | 81.6 秒 |
| 3 台目 | 280 | 19.7 秒 | 86.3 秒 |
3 台目はほとんど使われておらず、空いている GPU が余っている状態でした。
エラーや課金への影響はありません。リクエストが失敗していたわけではなく、遅延だけが発生していました。課金は完了したリクエストの usage のみが対象で、遅延によって余分に課金されることはありません。
原因
推論ゲートウェイが「最も空いている分散先に割り振る」方式を使っており、その実装に 3 つの不具合が重なっていました。いずれも当社が利用している OSS の問題で、最新版でも修正されていません。
1 つ目は、応答キャッシュのヒットが分散用のカウンタを壊すことです。キャッシュから返したリクエストは GPU を使わないのに「処理が 1 件終わった」とだけ記録されるため、カウンタが実際より小さくなり、最後はマイナスまで沈みます。
2 つ目は、マイナスまで沈んだ分散先が「最も空いている」と判定され続けることです。一度偏るとそこに集まり続け、キャッシュヒットのたびに更に沈むため、自力では戻りません。
3 つ目は、負荷が同じときの選び方が固定されていたことです。全部が空いているときは必ず同じ 1 つが選ばれるため、空いている分散先が均等に使われませんでした。
対応
3 点すべてを修正したパッチを推論ゲートウェイに適用しました。併せて、ゲートウェイのワーカー間でカウンタが共有されていなかった設定上の不備も直しています。
qwen3.8-27b-uncensored の修正前後の実測値です。
| 修正前 | 修正後 | |
|---|---|---|
| 平均応答 | 39.3 秒 | 19.3 秒 |
| p95 応答 | 145.4 秒 | 70.0 秒 |
平均・p95 ともにおよそ半分になりました。他のモデルも同じ仕組みで分散しているため同様に改善しますが、リクエスト数が少なく統計的に有意な比較ができないため、確認できた数値のみを掲載しています。
この不具合は OSS プロジェクト側にも報告済みです。本体に修正が取り込まれ次第、当社のパッチは取り下げます。
お客様側の対応
必要な変更はありません。
モデル ID・エンドポイント・API キー・単価はいずれも変更していません。