LLM APIの出力トークンが入力トークンより4〜8倍高い本当の理由

主要なLLM APIの料金ページを見てみてほしい——OpenAIでもAnthropicでもGoogleでも、どこでも構わない——毎回同じパターンに気づくはずだ。出力トークンは入力トークンより数倍高い。それも小さな上乗せではない。現行モデル全体で見ると、この比率はおおむね4倍から8倍の間に収まっている。これは特定のベンダー固有の価格設定の癖ではなく、これらのモデルが実際にどう動作しているかの直接的な帰結だ。

本当の理由：入力は並列、出力は逐次

入力トークン——プロンプト、システムメッセージ、会話履歴——の処理は、1回のフォワードパスで完結する。モデルは入力全体を一度に読み込み、そのすべてに対する注意（アテンション）を並列に計算する。現代のGPUはこの種のバッチ化された並列計算が非常に得意なので、3000トークンのプロンプトと300トークンのプロンプトでは、トークン数から想像されるほど計算時間が比例して増えるわけではない——モデルを1回動かすこと自体のオーバーヘッドが支配的なコストであり、読み込む内容の長さそのものではない。

出力トークンの生成はこれとは根本的に異なる。新しいトークンはそれぞれ、それより前のすべてのトークン——モデルがたった今生成したばかりのトークンも含めて——に依存する。つまり応答の500番目のトークンは、499番目のトークンが存在しない限り計算できない。これによって逐次ループが強制される：出力トークン1つにつきフォワードパスを1回、それを次々に実行していくしかなく、系列全体を並列化する方法はない。500個の出力トークンを生成するということは、モデルを1回ではなく500回連続して動かすということだ。

この計算量の非対称性——入力は1回の並列パス、N個の出力トークンにはN回の逐次パスが必要——こそが、企業やモデルアーキテクチャ、地域を問わず、どの主要プロバイダーの料金設定も同じような形になる理由だ。これはビジネス上の判断というより、根底にある計算コストがそのまま価格に転嫁されているにすぎない。

これがプロンプトにとって意味すること

実務上の結論ははっきりしている。総トークン数が同じくらいに見えても、冗長なモデルの応答は、長いプロンプトに短い回答を組み合わせた場合よりも不釣り合いにコストがかかる。API利用料を削減しようとしているなら、入力を削るより出力を短くするほうが、トークンあたりの節約効果は通常大きい。

具体的な手立てをいくつか挙げる。

応答の長さを明示的に制限する。 システムプロンプトに「一段落で答えて」と指示したり、max_tokens の上限を設定したりするほうが、自分のプロンプトを短くするよりコストへの効果が大きい。
散文ではなく構造化された出力を求める。 3つのフィールドを持つJSONオブジェクトは、文章で説明した場合の同等の内容よりずっと短く、後続処理でも同じくらい使いやすいことが多い。
出力を節約するためにシステムプロンプトで説明しすぎない。 より長く精密なシステムプロンプト（入力、安い）が、確実に短く正しい答え（出力、高い）を導けるなら、それは短くあいまいなプロンプトのせいでモデルが長い回答で予防線を張るよりも、たいてい良い取引になる。
大量かつ単純な出力には安価なモデルを使う。 分類、抽出、短い返信のようにフロンティアモデル級の推論を必要としないタスクなら、廉価モデルの出力単価は桁違いに低いことが多い。

実際の金額を計算する

この比率は出力がなぜ高くなるのかを説明してくれるが、正確な金額はどのモデルを使うか、そしてリクエストの各側が実際に何トークン消費するかによって決まる。入力と出力の配分——そして両者の間の倍率——はモデルごとに本当にばらつくため（廉価モデルとフラッグシップモデルでは同じ比率にならない）、実際のコストを知る唯一の確実な方法は、モデルごとに実数値を当てはめてみることだ。

CodeKitHubのLLM API 料金計算ツールはまさにそれを行う。モデルを選び、入力・出力のトークン数を入力すれば、入力コスト、出力コスト、合計を表示してくれる——おおよそのリクエスト数がわかっていれば、月間の見積もりも出せる。実際のプロンプトが何トークン消費するか分からない場合は、AIトークンカウンターツールを使えば、文字数ベースの大まかな推測ではなく、実際のトークナイザーを使った正確な数値がわかる。

どちらも完全にブラウザ内で動作する——APIキーもアカウントも不要で、データはどこにも送信されない。