トークン1個の原価

🚧メモリに縛られるデコード#

待っているのは演算ではなく帯域幅

モデルはトークンを1つ作るたびに、重みのほぼすべてをメモリから読み直す。70Bのモデルを16ビットで載せると重みだけで約140GBになり、リクエストを1件ずつ処理する場合は、演算コアよりも先にメモリ帯域幅が限界に達する。そのため推論コストを下げる方法の多くは、1回の読み込みでより多くのトークンを得るか、読むべきバイト数を減らす方向に集まる。

プリフィルとデコード#

2つの段階はボトルネックが違う

プロンプトを読むプリフィルは入力トークンを一度に処理するため、演算量がボトルネックになる。答えを書くデコードはトークンを1つずつ作り、そのたびに重みとKVキャッシュを読むため、メモリがボトルネックになる。最初のトークンが出るまでの時間は主にプリフィルが、その後のトークン間隔はデコードが決める。DistServeやSplitwiseといった研究が、2つの段階を別々のGPUで動かす方式を提案したのはこのためだ。

🛠️サービング技術#

同じボトルネックを迂回する3つの道

モデルを変えずにサービング側でトークンあたりのコストを下げる方法は、大きく3つある。バッチングは1回読んだ重みで複数リクエストのトークンをまとめて作り、量子化は読むバイト数そのものを減らし、投機的デコーディングは1回の検証で複数のトークンを確定させる。バッチングと投機的デコーディングはモデルの出力分布を変えない。量子化は品質を少し手放す代わりにメモリを確保する。

連続バッチングとKVキャッシュ#

1回の読み込みを複数リクエストで分け合う

連続バッチングは、リクエストが終わるのを待たずにデコードの各ステップで空いた枠に新しいリクエストを入れ、1回の重みの読み込みで複数人のトークンをまとめて作る。このときバッチサイズを制限するのは、リクエストごとにたまるKVキャッシュだ。2023年のvLLM論文は、既存システムがKVキャッシュ用メモリの60~80%を無駄にしていると報告し、キャッシュをページ単位で管理することで、同じレイテンシでスループットを2~4倍に高めた。

量子化#

8ビットなら読むバイトは半分

重みを16ビットから8ビットに減らすと、トークンごとにメモリから読む量は半分になり、4ビットなら4分の1になる。GPTQやAWQのように重みだけを減らす方式は、メモリがボトルネックのデコードにすぐ効き、活性値まで8ビットに下げるW8A8は、演算がボトルネックのプリフィルも速くする。ビット数を減らすほど品質が落ちることがあるため、ビット数は実際のサービスの課題で評価し直して決める。

投機的デコーディング#

小さなモデルが書き、大きなモデルが一度に検証する

小さな下書きモデルがトークンをいくつか先に提案すると、本体モデルはそれらを1回の順伝播でまとめて検証する。受け入れたトークンだけを残すため、出力分布は本体モデルが単独で作った場合と同じになる。2023年にGoogleの研究者はT5-XXLで出力を変えずに2~3倍の高速化を報告しており、実際の効果は下書きトークンが受け入れられる割合によって決まる。

💸トークン原価の計算#

スループットは2倍、原価は半分

自前でサービングするなら、トークン1個の原価はGPUの1時間あたりのコストを、その1時間に作ったトークン数で割った値だ。サービング技術とモデル構造は、GPUの値段ではなくスループットを上げることで原価を下げる。ただしトークン単価が下がっても、エージェントのように1件の作業でモデルを何度も呼ぶ製品では呼び出し回数がより速く増え、請求額の総額が膨らむことがある。

トークン税#

推論コストは売上原価に入る

従来のSaaSはユーザーを1人増やすコストが小さいが、LLM製品はリクエストのたびにGPU時間がかかる。そのため推論コストは売上原価に入り、定額プランでは最もよく使うユーザーが最も高くつくユーザーになる。リクエスト1件の入力トークン、出力トークン、キャッシュヒット率がわからなければ、料金プランが利益を生むかどうかは計算できない。

キャッシュヒット割引#

読み直さないプロンプトは安い

同じシステムプロンプトや長い文書をリクエストのたびに先頭に付けるなら、先頭部分のKVキャッシュを再利用して、その分のプリフィルを省ける。主要なモデルAPIが、キャッシュにヒットした入力トークンを通常の入力より安く請求するのはこのためだ。キャッシュは先頭から完全に一致する部分にしかヒットしないので、固定の内容を前に、変わる内容を後ろに置くだけでもヒット率が変わる。

📐モデル構造#

読む量を設計段階で減らす

サービング技術が与えられたモデルを安く動かす方法だとすれば、モデル構造はトークンごとに読んで計算する量をはじめから減らす方法だ。専門家混合(MoE)はトークンごとに使うパラメータを減らし、MLAはリクエストごとにたまるKVキャッシュを減らす。DeepSeek-V3は両方を採用し、FP8混合精度で学習したうえで、重みもFP8で公開した。

専門家混合(MoE)#

671Bのうちトークンごとに37B

DeepSeek-V3は全パラメータ671Bのうち、トークン1つを処理するときに37Bだけを活性化する。トークンあたりの演算量と読むべき重みは活性パラメータ分に減るが、どの専門家が呼ばれるかを事前に知ることはできないため、671B全体をメモリに載せておく必要がある。MoEは演算を節約する代わりにより多くのメモリ容量を求め、専門家を複数のGPUに分けて載せる設計が伴う。

MLA#

KVキャッシュを圧縮してバッチを大きくする

マルチヘッド潜在アテンション(MLA)は、キーとバリューをそのまま保存せず、小さな潜在ベクトルに圧縮してキャッシュする。DeepSeek-V2の技術レポートは、MLAを使ったこのモデルのKVキャッシュがDeepSeek 67Bより93.3%小さいと記している。リクエスト1件が占めるメモリが減れば、同じGPUにより多くのリクエストとより長いコンテキストを載せられる。

🧑‍💻サービングエンジニア#

トークン原価を削る役割

推論コストが製品マージンを直接左右するようになり、モデルを作る仕事とは別に、モデルを安く速く動かす仕事が重要になった。vLLM、SGLang、TensorRT-LLMといったサービングエンジンを選んで調整し、同じGPUからより多くのトークンを引き出すことがこの役割の成果だ。このマップの枝の多くは、この職種が毎日触る設定値である。

サービングエンジニアの仕事#

ワークロードの計測からデコード設定まで

まずワークロードを計測し、プリフィルとデコードのどちらがボトルネックか、守るべきレイテンシが最初のトークンまでの時間かトークン間隔かを見極める。次にバッチサイズ、KVキャッシュのメモリ割り当て、量子化のビット数、投機的デコーディングを使うかどうかを調整し、品質が保たれているかを確認する。設定を1つ変えるたびに、スループット、レイテンシ、品質をまとめて測り直す。