バックエンドやアルゴリズムを担当する皆さんなら、こんな直感に反する出来事に遭遇したことがあるかもしれません。オンラインの業務量はほとんど増えていないのに、月末に請求書を見ると、いきなり倍になっている。私が率いるチームは2年前、あるオンライン教育企業のインテリジェントカスタマーサービスシステムを手がけました。ローンチから2ヶ月で、呼び出し量は1日平均12万回から16.8万回へと40%しか増えていないのに、月間API請求は8000元から23000元へと187%も急騰しました。この差額は、単価が上がったからではなく、4つの隠れたコストブラックホールが静かに予算を食いつぶしているからです。
まず問題を明確に定義しましょう。大規模モデルAPIのコスト暴走の本質は、呼び出し量と有効な产出の間の比率の失衡です。あなたが支払っているのはtokenのお金ですが、実際にビジネス価値を生み出すtokenは3割程度に過ぎないかもしれません。以下、層ごとに分解していきます。
ブラックホール1：リトライストーム、無効呼び出しが直接倍増
私たちの当初の呼び出しコードは非常に素朴で、ネットワークの揺らぎやタイムアウトが発生するとすぐにcatchして再度呼び出すだけでした。バックオフもなく、冪等性もありませんでした。ローンチ2週目に上流のレート制限に遭遇し、QPSは20から突然5に抑えられ、クライアントは3秒以内に同じユーザーリクエストを7回リトライしました。その一晩で、無効呼び出しの割合は41%にまで達しました。請求書のこの部分のお金は、1円のビジネス価値も取り戻せていません。
解決策は2層です。指数バックオフ：1回目の失敗で500ms待機、2回目は1s、3回目は2s、最大3回までリトライし、それを超えたらフォールバックの定型文に降格します。冪等キー：各リクエストにrequest_idを持たせ、サーバー側とクライアント側の両方で重複排除を行い、同じidは60秒以内に1回だけ実際の呼び出しを許可します。修正後、リトライによる無効呼び出しは41%から6%以下に抑えられました。この項目で毎月約4200元を節約できました。
ブラックホール2：長いコンテキストをトリミングせず、履歴対話を繰り返し詰め込む
カスタマーサービスのシナリオでは、対話が十数ターンに及ぶことがよくあります。私たちは当初、手間を省くために毎回の呼び出しに完全な履歴を詰め込んでいました。1ターンあたりの平均入力tokenは、第3ターンの800から第12ターンには3400に増加しました。さらに悪いことに、ユーザーが「さっき言ったあの返金ポリシーは何だった？」と尋ねると、モデルは実際には直近3ターンと要約1つだけで十分なのに、私たちは12ターン全部を詰め込んでいました。
スライディングウィンドウと要約圧縮で解決します。直近4ターンの原文を保持し、それより前の対話は軽量モデルの呼び出し1回で150字以内の要約に圧縮し、要約をsystemコンテキストの一部とします。これにより第12ターンの入力tokenは3400から約1100に減少し、削減率は67%です。ここに落とし穴があります。要約自体もtokenを消費するため、要約のトリガー閾値を正しく設定する必要があります。私たちの実測では6ターンを超えたら圧縮をトリガーするのが、総合コストが最も低くなります。
ブラックホール3：フラッグシップモデルが軽量モデルの仕事をこなす
これが最も隠蔽されやすい項目です。システム内のすべてのリクエストが同じフラッグシップモデルを通り、「こんにちは」「はい、おります」「少々お待ちください」といった挨拶まで含まれていました。私は一度呼び出しログを取得して分類したところ、62%のリクエストが意図認識と簡単な質疑応答であり、フラッグシップモデルは全く必要ないことがわかりました。これらをフラッグシップモデルで実行すると、1回あたりのコストは軽量モデルの8〜12倍です。
解決策はタスク別の階層ルーティングです。私たちはモデルゲートウェイに1層のルールを追加しました。意図分類、挨拶、FAQヒットは軽量モデルを通し、返金計算、コース推薦、苦情エスカレーションといった複雑なタスクのみフラッグシップモデルにルーティングします。ここで私たちのプロジェクトではtoken8341をマルチモデル統合接続に使用しており、1つのKeyでGPT-4o、Claude、DeepSeek、Qwenといった主要モデルを呼び出せ、タスクに応じて最適なモデルを自動選択するため、複数のSDKや認証を自分で維持する必要がありません。階層化後、フラッグシップモデルの呼び出し割合は100%から34%に減少し、全体コストは52%削減されました。
ついでに大規模モデルAPIの選定について言及すると、公式直結とアグリゲーションプラットフォームではコスト構造が確かに異なります。公式直結は単価が透明ですが一括割引を交渉するのが難しく、アグリゲーションプラットフォームは一括調達とグリーンエネルギーによるコスト削減により、従量課金でのコストがより優れています。私たちは同一バッチのタスクで月間支出を比較したところ、アグリゲーション方案は公式直購入より低かったです。具体的な数字は商務上の理由で展開できません。
ブラックホール4：ストリーミング出力中断後の重複課金
ストリーミング出力（SSE）はカスタマーサービスのシナリオでよく見られ、ユーザーが文字が1つずつ出てくるのを見る体験は良いです。しかしネットワークが切れてクライアントが再接続すると、サーバー側がブレークポイント継続を行っていなければ、すでに生成した内容を再度生成してしまいます。私たちの統計では、ストリーミング中断率は約3.7%、中断ごとに平均1200個のtokenを重複生成していました。1ヶ月下来ると、この部分の重複課金は請求書の9%を占めていました。
解決策は断流補償です。サーバー側は各ストリーミングリクエストで生成済みのtokenオフセットを記録し、クライアントが再接続する際にoffsetを持参すると、サーバーは最初からではなくブレークポイントから続行します。冪等キーと組み合わせることで、重複課金は直接ゼロになります。この項目で毎月約2000元を節約できました。
コスト監視チェックリスト
これら4つのブラックホールを振り返った後、私は日常的に監視すべき指標のチェックリストをまとめました。自分のシステムと照らし合わせて確認できます。
1.無効呼び出しの割合、10%を超えたらリトライと冪等性を確認する。
2.平均入力tokenと平均出力tokenの比率、カスタマーサービスのシナリオで3:1を超えたらコンテキストがトリミングされていないことを示す。
3.フラッグシップモデルの呼び出し割合、40%を超えたら階層ルーティングを検討する。
4.ストリーミング中断率、2%を超えたらブレークポイント継続を実装する。
5.1回あたりの有効対話コスト、API基準ではなくビジネス基準で計算する。
6.モデルゲートウェイのタスク別ルーティングヒット率、60%未満ならルールが調整されていないことを示す。
コスト暴走は決して単価の問題ではなく、エンジニアリングの問題です。これら4つのブラックホールを塞げば、同じ業務量でも請求書は合理的な範囲に戻ります。
著者：周明哲
公開日：2026年10月23日