100万トークンのコスト、2つの方式で比較

要点

この二つを比較する記事のほとんどは、単一の数字に行き着きます—「セルフホスティングの方が10倍安い」「規模が巨大になるまではAPIの方が安い」—どちらも同じ誤りを犯しています。それは、トークン単位で課金されないマシンについて、トークンあたりのコストを引き合いに出していることです。レンタルしたGPUの価格はただ一つで、変動しません。今月10億トークン生成しても、まったく生成しなくても、請求額は同じです。したがって正しい問いは「ここでのトークン単価はいくらか」ではなく、「固定価格がメーターに勝つには、何トークン生成する必要があるか」です。

その数値は割り算であり、以下では当社独自の価格と当社独自のスループットモデル—コンフィギュレーターが使っているのと同じモデル—を使って計算しています。それ以降の内容はすべて、その処理量に到達できるかどうかを左右する2つの要素、すなわちバッチ処理と、マシンをアイドル状態にしておく時間についてです。

計算

4行です。3行目はホワイトボードに書き留める価値のあるものです。4行目は見落とされがちですが、それを見落とすことこそが、健全な見積もりを誤ったものに変えてしまいます。

# 1. What the API charges. Linear in what you use, zero when you stop.
api_cost_per_month = output_tokens_per_month / 1e6 × api_price_per_million

# 2. What the machine charges. A constant. Tokens are free once you own the hours.
machine_cost_per_month = monthly_price

# 3. Set them equal. This is the break-even VOLUME, in output tokens per month.
break_even_tokens = monthly_price / api_price_per_million × 1e6

# 4. And the only question that matters: can the machine produce that many?
#    730 hours is the month we bill, so 2,628,000 seconds of it.
sustained_tokens_per_second = break_even_tokens / 2,628,000

4行目は持続レートであり、ピークではありません。1日1時間だけ毎秒600トークンに達し、残りの23時間はアイドル状態のマシンの持続レートは25であり、請求書はどちらの数字について話しているかを気にしません。

1ストリームのコスト

まず最悪のケースから始めます。前提条件なしに提示できる唯一の数値だからです。1度に1件のリクエスト、バッチ処理なし、それ以外の時間はマシンがアイドル状態、という条件です。以下の各ノードはすべて4-bit (AWQ, GPTQ)でLlama 3.3 70Bを実行しており、スループットは当社独自の保守的な見積もりです—好条件下で測定した値ではなく、メモリ帯域幅によって制限される値です。

これは上限として読んでください。見積もりとしてではありません。これは、マシンに一度に1つの質問だけを処理させ、月の残りはそのまま放置した場合にトークンにかかるコストです—GPUを所有する方法としては最も非効率なものです。実際の推論スタックはどれもこれより優れており、次の2つのセクションではどれだけ優れているかを扱います。

損益分岐点（価格帯別）

上の表で最も安い行—月額$692の2 × NVIDIA RTX 5090—を取り上げ、API市場の各価格帯を上回るにはどれだけの仕事量が必要かを考えます。

最後の列がこの記事のすべてです。「すでに安い」と書かれている場合、$692マシン上の1つの非バッチストリームがAPIに勝ち、それ以上考えることは何もありません。倍率が示されている場合でも、マシンが勝つことは可能です—ただし実際に十分な処理量を流し込んだ場合に限られ、それが次のセクションの内容です。

バッチ処理がすべてを左右する

1つのトークンを生成するには、アクティブな重みをメモリから1回読み出す必要があります。100件の異なるリクエストに対して100個のトークンを生成する場合も、読み出しは同じく1回で済みます—同じ重みがバッチ内のすべてのリクエストに使われるからです。連続バッチ処理を備えた推論スタックが、同一のハードウェアでシングルストリームの何倍ものトークン数を毎秒生成できるのはこのためであり、あの表の最後の列にある倍率がそもそも到達可能である理由でもあります。

実務上の帰結はこうです。損益分岐点の表にある倍率は、ユーザー数ではなくスループット目標として捉えてください。シングルストリームの10倍という目標は「ユーザー10人」を意味するのではなく、サーバーが非バッチレートの平均10倍を出す必要があるという意味であり、それには通常、同時リクエスト10件よりかなり多く、100件よりはかなり少ない数が必要になります。数値を確定させる前に、実機で測定してください—それはたった1回のベンチマークであり、議論に決着をつけます。

支払い続けるアイドル時間

ここまでの計算はすべて、負荷が月内に均等に分散されている前提でした。しかし実際にはそうなりません。月単位でレンタルしたマシンは日曜の午前4時であっても料金が発生しており、その時間に生成しなかったトークンは繰り越されません。実際に稼働させている週を、実際に支払っている週で割ってください:

3行目は社内ツールの大半が該当する領域であり、そこでは損益分岐点が気づかぬうちに4倍以上に膨らみます。セルフホスティングの見積もりが外れる最も多い理由は、トークン価格でもハードウェアでもなく、勤務週を1週間全体だと思い込むことです。

プロンプトがほぼ無料に近い理由

マシンを所有する側に強く有利に働く非対称性が1つあり、トークン単価の比較ではそれが見えません。APIは入力トークンにも課金します—1トークンあたり、通常は出力価格の4分の1から3分の1程度です。自前のGPUでは、入力トークンはプリフィル処理で扱われます。これはプロンプト全体を並列に処理するもので、メモリ帯域幅ではなく演算能力によって制限されます。プリフィルは生成時よりも一桁多いトークン数を毎秒処理します。

この計算が見落としているもの

トークン単価の表には決して現れないものの、数字と同じくらいの頻度で結論を左右する4つの要素です。

自分がどちら側にいるか

順番に見ていき、自分に当てはまる最初の項目で止まってください。

1. フロンティア級のクローズドモデルの品質が必要である。それならこの記事は当てはまりません。その重みを貸してくれる相手はいません。APIを使い、オープンモデルがお客様の具体的なタスクでその差を縮めた時点で見直してください。
2. 処理量が少ない、またはまだ把握できていない。APIを使ってください。実際のトラフィックがどのようなものかを知るには最も安い方法であり、メーターは測定器として十分に優れています。
3. トラフィックが急増しやすく、待ち行列を許容できる。APIを使うか、分割してください: 安定したベース負荷にはご自身のマシンを、ピーク時にはホスト型エンドポイントを使います。どちらか一方に決めなければならない理由はありません。
4. オープンウェイトモデルに対して、実際にバッチ処理された継続的な量をさばいている。これはハードウェアが勝つケースであり、しかも大差で勝ちます—メーターが回り続ける一方で、固定価格は動きを止めるからです。鵜呑みにする前に、上の表でご自身の数字を確認してください。
5. プロンプトが機密性を要する、モデルを変更されては困る、あるいは請求額を事前に把握しておく必要がある。それなら、計算はもはや形式的なものです。ご自身のモデルを保持できるマシンをレンタルし、誰にも身元を明かすことなく支払ってください。

どの行で止まったとしても、確認すべき数値は、損益分岐点の表におけるあなたのモデルとあなたの処理量に対応する数値です。コンフィギュレーターは、当社が貸し出すすべてのノードについて、あなたのモデルが1枚のカードに収まるか、分割が必要か、そしてスループットの見積もりがどうなるかを示します—これがこの計算に必要なすべての入力です。月単位の契約と時間単位の従量課金のどちらにするかまだ決めかねている場合、それは別の損益分岐点の話であり、それも別途解説しています。