推論コストの経済学 — 費用の重心はどこへ移るか

推論コストはモデル選定の付随項目として扱われがちだ。本番運用に入ると立場が逆転する。支配的になるのはモデルの質ではなく、選んだ提供形態と負荷パターンが決める総所有コストのほうだった、という話は珍しくない。ここでは API 課金と自己ホスト、レイテンシとスループット、プロンプトキャッシュの実効率という三つの軸で、公開比較記事があまり踏み込まない部分を整理する。

単価表に載らない変数

公開 API の単価と自己ホスト時の GPU 償却費用を並べた比較記事は多い。その比較は、負荷の予測可能性と運用人件費という二つを外すと成立しない。

API 課金は使用量に応じた変動費であり、負荷が読めない段階では合理的だ。本番運用で負荷が安定してくると、変動費モデルは固定費モデルに対して割高になる。ここで損益分岐点を単純にトークン単価で計算すると外す。GPU 稼働率が半分程度を下回る場合、自己ホストの実効単価は API を上回ることが多い。稼働率を上げるには負荷平準化の設計と、それを維持する SRE 工数がいる。この工数が比較記事から抜け落ちているのが常だった。

レイテンシとスループットは両立しない

vLLM や TensorRT-LLM の性能表は、多くの場合スループットを軸に構築されている。数値はバッチサイズを大きく取った状態での計測であり、個別リクエストのレイテンシとは逆相関する。

この非可換性は SLO 設計に直接効く。対話型 UI が p95 で1秒以内の初回トークン応答を求めるなら、バッチサイズは実質的に制限される。逆に要約バッチや埋め込み生成のような非同期処理では大きなバッチが許される。同じハードウェアで両方の負荷を捌こうとすると、レイテンシ側がスループット側の効率を壊す。プラットフォームの分離設計と密接に関係する話で、単一の推論クラスタで両方の SLO を満たそうとする構成は、たいていコスト効率で最悪の選択になる。

キャッシュの損益はミス側で決まる

Anthropic や OpenAI が提供するプロンプトキャッシュは、ヒット時のトークン単価を大きく下げる。システムプロンプトが数千トークンに達するユースケースでは、名目上のコスト削減率が半分を超えることも珍しくない。

実効削減率を決めるのはミス時の処罰のほうだ。プロバイダによってはキャッシュミス時にプレミアム単価を課す。この場合ヒット率が想定を下回るとコストは逆に増える。ヒット率を上げるにはシステムプロンプトの変更頻度を抑える必要があるが、プロンプト改善のイテレーションが速い開発初期には、キャッシュを有効にしないほうが安い。判断が開発フェーズと運用フェーズで逆転する。API 契約の設計と同じく、キャッシュ挙動も提供者との契約項目として明示されているかを確認すべき対象である。

待てば安くなる、は誰にとって正しいか

ここまでの分析には「モデル API 価格は下がり続けている。細かい最適化を議論する前に待てばいい」という反論が付く。2023年から2025年にかけて公開単価が継続的に下がってきたのは事実で、傾向も当面続くと見られている。

ただし価格低下が最適化として効くのは、負荷を持たない組織に限られる。年間で数十億トークンを処理する組織にとって、同じ割合の低下でも絶対額は大きい。単価が下がってもレイテンシ SLO やキャッシュ設計の物理制約は下がらない。待つ戦略が現実的かどうかは、負荷規模と SLO 要件の組み合わせ次第で変わる。

順序を間違えない

推論コストを「モデル選定の付随項目」から「運用設計の中核」へ格上げすること。これが実務的な結論になる。公開比較記事の単価表を根拠に判断するのではなく、自組織の負荷パターン、SLO、開発イテレーション速度を先に定義し、そこから提供形態を選ぶ。スケーリング則の解釈と同じ話で、外部の数字をそのまま自組織の判断に持ち込むと外す。順序を守った組織と逆順で判断した組織のあいだで、AI 基盤の運用コストが数倍のオーダーで開いた事例が公開技術ブログに散見される。