バックエンドやアルゴリズムを担当する皆さんなら、こんな直感に反する出来事に遭遇したことがあるかもしれません。オンラインの業務量はそれほど増えていないのに、月末に請求書を見ると、いきなり倍になっている。私のチームは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%です。ここに落とし穴が1つあります。要約自体にもtokenがかかるため、要約のトリガー閾値を正しく設定する必要があります。私たちの実測では、6ターンを超えてから圧縮をトリガーすると総合コストが最も低くなります。
ブラックホール3：フラッグシップモデルが軽量モデルの仕事をこなす
これが最も隠れた項目です。システム内のすべてのリクエストが同じフラッグシップモデルを通っており、「こんにちは」「はい、おります」「少々お待ちください」といった挨拶も含まれていました。一度呼び出しログを取得して分類したところ、62%のリクエストは意図認識と簡単なQ&Aであり、フラッグシップモデルは全く不要であることがわかりました。これらをフラッグシップモデルで実行すると、1回あたりのコストは軽量モデルの8〜12倍です。
解決策はタスク別の階層ルーティングです。私たちはモデルゲートウェイに1層のルールを追加しました。意図分類、挨拶、FAQヒットは軽量モデルを通し、返金計算、コース推薦、クレームエスカレーションといった複雑なタスクのみフラッグシップモデルにルーティングします。ここで私たちのプロジェクトではtoken8341を使ってマルチモデルの統合接続を行っており、1つのKeyでGPT-4o、Claude、DeepSeek、Qwenといった主流モデルを呼び出せ、タスクに応じて最適なモデルを自動選択するため、複数セットのSDKや認証を自分で維持する必要がありません。階層化後、フラッグシップモデルの呼び出し割合は100%から34%に減少し、全体コストは52%削減されました。
ついでに大規模モデルAPIの選定について言及すると、公式直結とアグリゲーションプラットフォームではコスト構造が確かに異なります。公式直結は単価が透明ですが大量割引の交渉が難しく、アグリゲーションプラットフォームは一括調達とグリーンエネルギーによるコスト削減を行い、従量課金ではコストがより優れています。私たちは同一バッチのタスクで月間支出を比較したところ、アグリゲーション方案は公式直購入より一截低くなりました。具体的な数字は商務に関わるため展開は控えます。
ブラックホール4：ストリーミング出力中断後の重複課金
ストリーミング出力（SSE）はカスタマーサポートのシナリオでよく見られ、ユーザーが文字が1つずつ出てくるのを見ると体験が良いです。しかしネットワークが切れてクライアントが再接続すると、サーバー側がレジュームを行っていなければ、すでに生成した内容を再度生成してしまいます。私たちの統計では、ストリーミングの中断率は約3.7%で、1回の中断あたり平均1200tokenを重複生成していました。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日