計算資源の逼迫は迫っているのか？

この1年、AI関連の設備投資（CapEx）が大きな話題になってきた。ハイパースケーラーは競うように巨大なデータセンターを建設し、その過程で数千億ドルを投じている。セントルイス連邦準備銀行の推計では、2025年の最初の3四半期に、AI関連の投資は米国の実質GDP成長に約1パーセントポイント寄与した。これは成長全体の40%近くにあたり、ドットコム・バブル絶頂期のIT投資の寄与を上回る。現在のAIインフラの拡張がバブルかどうかは、建設中の計算インフラに見合うだけの需要が生まれるかどうかに大きく左右される。

トークンの将来の需要を推定するのは難しい。能力の向上と普及という、予測しにくい動向に大きく左右されるからだ。一方、供給側については、はるかに具体的な見通しを持てる。本稿では、今あるチップで、世界は毎秒何トークンを生み出せるのかという問いに、できるかぎり答えてみる。

そのために、推論実行（インファレンス）の技術的な詳細に踏み込む。プレフィルとデコードの所要時間をモデル化し、よく使われる二つの効率化手法（チャンク化プレフィルと投機的デコード）を考慮に入れ、実環境での推論実行の実験を集めたSemiAnalysisのInferenceXのデータで較正する。結果からは、2025年第4四半期時点で、これらのチップはKimi K2.6のようなモデルについて、リクエストのコンテキスト長に応じて毎秒5億〜200億の出力トークンを提供できるとみられる。また、計算インフラの配備が進み、チップの効率も上がるにつれて、世界の推論実行能力は毎年3倍を超えるペースで増えていることも分かった。

これらの供給の推定値を、トークン需要とその伸びを示すいくつかの（不完全な）代理指標と比べる。たとえば、Googleの各種プラットフォームで提供されたトークン数の伸びや、大手テック企業での現在のトークン使用の強度を世界中のソフトウェアエンジニア全員に当てはめた値である。これらの数字からは、現在の価格での需要は毎秒2億〜40億トークンで、年およそ10倍で伸びている可能性がある。すでにそうなっていないとしても、近い将来には供給の伸びを上回ってもおかしくない。ただし、これらの推定値は非常に不確かである。たとえば、現在の需要を支えているモデルの平均的な規模は分からない。また、トークン数の総計を見るだけでは、その背後にあるモデル効率の向上が見えにくくなる。効率の向上は、一定の品質のトークンを生み出すコストを下げると同時に、新たな用途を採算に乗せることで新しい需要も生む。

これらの動向が続くなら、計算資源の逼迫はおそらく目前に迫っている。とりわけ、エージェント型AIを動かす長いコンテキストの処理でそうである。その結果、お金を払う意思のある利用者にとっては最先端（フロンティア）の能力を使う価格が上がり、日常的な利用者はより安く小さなモデルへと移っていくだろう。AI企業が、より効率よくモデルを提供する方法の開発に力を入れるようになることも考えられる。効率が上がっているので、こうした変化は、日常的な利用者が使える能力の後退を必ずしも意味しない。推論実行と学習の効率はすでに十分速く向上しており、明日の小さく安いモデルはすぐに今日の最先端に追いつくからだ。

Epoch AI の最新情報を受け取る 購読する

前提とする設定

話を具体的にするため、Kimi K2.6を提供する場合を想定する。Kimi K2.6は現在、Epoch能力指数（ECI）で最も高性能なオープンモデルである¹。これを、世界中にあるNvidia GB200とGB300のすべてのチップで動かすと考える（2025年第4四半期時点で、GPU単体の数はそれぞれ190万基と150万基。両者を合わせると、FLOP/s換算で総供給のおよそ40%にあたる）。

すべてのチップは、1ラックに72基のチップを接続するNVL72構成にあると仮定する。リクエストは3種類を考える。「一般的」な利用（入力8,000トークン・出力1,000トークンのクエリとしてモデル化）と、エージェント的な利用パターンを表す、より長いコンテキストの二つの設定（それぞれ25,000:1,000と128,000:1,000）である。²³ 最後に、利用者は少なくとも毎秒35の出力トークンを期待すると仮定する。⁴

以下の計算では、簡潔さのため、クエリ長8,000:1,000のGB200システムに絞って説明する。最終的な数字は、同じ計算をGB300と各コンテキスト長にも当てはめて求めた。なお強調しておくと、私たちの推定値は、モデルの選択、数値形式、投機的デコードの設定をはじめ、多くの点で、選んだ設定に左右される。また、現在のクローズドな最先端モデルのアーキテクチャの詳細や、それがKimi K2.6とどう違いうるかについては、ほとんど分かっていない。

推論実行の設定

パラメータ	既定の設定
入力系列長（ISL）	8,000 / 25,000 / 128,000トークン
出力系列長（OSL）	1,000トークン
利用者あたりの最低スループット	毎秒35トークン 5
重みの精度	INT4
KVキャッシュの精度	FP8

ハードウェアの仕様

パラメータ	GB200 NVL72	GB300 NVL72
PFLOP/s（FP4）	720	1080
HBM容量（TB）	13.4	20.7
HBM帯域幅（TB/s）	576	576
これまでの販売ラック数	27,000	21,000
GPU単体の数	190万	150万

前置きはこれくらいにして、技術的な詳細に入ろう。

推論実行の間に何が起きているのか

AIの推論実行は、プレフィルとデコードの二つの段階に分けられる。プレフィルでは、すべての入力トークンを並列に処理して「KVキャッシュ」を埋める。KVキャッシュはキー（key）と値（value）の保存領域で、これがあるおかげで、各トークンは毎回ゼロから計算し直さずに、それまでのコンテキストに注意（アテンション）を向けられる。プレフィルが終わると、デコード段階で出力トークンを1つずつ生成する。新しいトークンはそれぞれ、キャッシュされたKVに注意を向ける（そして自分のキーと値をキャッシュに追加する）。二つの段階は計算上の性質がかなり違うので、順に見ていく。

どちらの段階でも、目標は、バッチサイズなどの重要な要因の関数として、その段階を終えるのにかかる時間を推定することである。そのために、単純化した仮定を置く。合計時間は、計算にかかる時間（計算資源）とデータの移動にかかる時間（帯域幅）のうち、長いほうだけで決まるとする。

$$t_{total}=\max \{t_{compute},t_{bw}\}$$

この仮定はたいてい妥当である。理由は二つある。

1. 多くの場合、一方の時間が他方を大きく上回るので、最大値と和はほぼ等しくなる。
2. 二つの時間が同程度でも、多くの場合は並行して進められる。たとえば、ある層の計算を処理している間に、次の層の重みの読み込みを始められる。

プレフィル

ここでの仮定では、プレフィル段階は、すべての入力トークンをモデルに通してKVキャッシュを構築する処理からなる。言語モデルは多数の系列を並列に処理する。各NVL72システムで同時に処理する利用者の数を$B$で表し、これをバッチサイズと呼ぶ。

プレフィルの計算時間（$t_{compute}$）を求めるには、1回の順伝播で必要な演算回数を精度ごとに数え、それぞれの精度でのハードウェアのFLOP/sで割る。精度を区別する必要があるのは、重み×活性化の計算が、アテンションの計算よりも低い精度で行われることが多いからである。

活性化される重みは、それぞれトークン1つにつき乗算1回と加算1回を担う。アテンションはさらに演算を加える。コンテキストの各トークンについて、各ヘッド・各層で、クエリとキーの内積と、アテンションで重み付けした値の和の、すべての次元について乗算と加算を1回ずつ行う。

$$\text{flops\_per\_token\_weights}=2N_{active}$$$$\text{flops\_per\_token\_attn}=2\cdot (d_k+d_v)\cdot \text{context\_len}\cdot \text{n\_heads}\cdot \text{n\_layers}$$

このトークンあたり演算回数のそれぞれを、対応する精度（重みは4ビット、アテンションは8ビット）でのハードウェアのFLOP/sで割り、足し合わせると、トークンあたりの秒数が得られる。これにプレフィルの総トークン数を掛ける（利用者は$B$人で、それぞれが$\text{input\_len}$個の入力トークンを持つ）。

$$t_{compute}=\text{input\_len}\cdot B\cdot \left(\frac{\text{flops\_per\_token\_weights}}{{\text{FLOP/s}}_{FP4}}+\frac{\text{flops\_per\_token\_attn}}{{\text{FLOP/s}}_{FP8}}\right)$$

Kimi K2.6とGB200 NVL72の数値を代入すると、ISL 8,000のリクエストでは計算に$1B$ミリ秒かかることが分かる。

帯域幅の分析はもっと単純である。上で述べた計算を実際に行うには、モデルの1兆個の重みをすべて広帯域メモリ（HBM）からテンソルコアへ移さなければならない。モデルはFP4の重み（重み1つあたり0.5バイト）で提供するので、重みは500 GBになる。⁶ 計算を終えたら、各層のKVキャッシュをHBMに書き戻す必要もある。そもそも、それこそがプレフィルの目的である。

$$\text{kv\_bytes}=d_{kv\_cache}\cdot \text{n\_layers}\cdot \text{kv\_precision}\cdot \text{input\_len}\cdot B$$

KVキャッシュはFP8（値1つあたり1バイト）で保存すると仮定したので、これは$280B$メガバイトになる。これを500 GBの重みに足してHBMの帯域幅で割ると、プレフィルでのデータ移動にかかる最終的な時間は、$0.9+0.0005B$ミリ秒程度になる。

デコード

デコードには、プレフィルと比べて主に四つの違いがある。第一に、トークンは逐次処理されるので、入力ごとに重みをすべて読み込まなければならない。第二に、トークンごとにKVキャッシュも読み込む必要がある。第三に、計算は、トークンの集合をまとめて並列に処理するのではなく、トークン1つ分だけになる。これらの要因はいずれも、デコードを帯域幅律速の方向へ押しやる。第四の要因（KV射影の吸収、後述）は計算律速の方向へ押すが、他の要因を打ち消すほどではない。

ここでの計算は、プレフィルで見たものとよく似ている。$\text{flops\_per\_token\_weights}$はプレフィルからほとんど変わらず、違うのは、平均コンテキスト長が$\text{input\_length}+\text{output\_length}/2$になる点だけである。

デコードには細かな違いが一つある。Kimi K2.6はマルチヘッド潜在アテンション（MLA）を使っているため、$\text{FLOP\_per\_token\_attn}$はプレフィルに比べてやや計算負荷が高くなる。MLAは、KVキャッシュを圧縮してHBMの帯域幅と容量への負担を和らげることを狙った手法で、トークンごとに完全なKV行列ではなく低ランクの潜在ベクトルを保存する。

素朴に考えると、モデルはアテンションの値を計算する前に、メモリに保存した潜在ベクトルを完全なKVキャッシュの表現へと上方射影しなければならない。プレフィルでは通常この方法で計算する。しかし、これをデコードのステップごとに行うと、上方射影を何度も計算し直すことになり無駄が多い。そこで、上方射影の行列を読み込み時に数学的にクエリと出力の射影へ「吸収」させ、アテンションの内積を潜在空間で直接計算する。実際上の効果として、アテンションの計算で使う実効的なヘッドあたりの次元は、名目上のヘッドあたりの次元（たとえば128）ではなく潜在次元（たとえば512）になる。MLAは、同じ形のマルチヘッドアテンション（MHA）のモデルに比べてトークンあたりのアテンションFLOPをおよそ4倍にするが、KVキャッシュの帯域幅を大幅に節約する。そして（後で見るように）KVキャッシュの帯域幅こそが、デコード中の主なボトルネックである。⁷

$(d_k+d_v)$を$d_{kv\_latent}$に置き換えると、デコードの各ステップでt_compute = $0.3B$ミリ秒となる。

帯域幅の考え方はプレフィルと同様だが、今度はKVキャッシュの読み込みを考慮しなければならない。トークンごとに読み込む必要のあるKVキャッシュの大きさは、次の式で与えられる。

$$d_{kv\_cache}\cdot \text{n\_layers}\cdot \text{kv\_precision}\cdot \text{context\_len}\cdot B$$

コンテキスト長は、デコード段階の始めの8,000から最後のデコードトークンでの8,999まで伸びるので、平均はおよそ8,500である。すると、KVキャッシュの読み込み量は、デコードの1ステップあたり平均265 MiB * $B$となる。デコード時のKVキャッシュの書き込みは無視する。読み込みでは平均8,500トークン分のKVキャッシュを扱うのに対し、書き込みでデータ移動に加わるのはトークン1つ分のKVキャッシュだけだからである。

こうして$t_{bw}$の最終的な値は$\left(500\text{ GB}+265\text{ MiB}\ast B/576\text{ TB/s}\right)\ast \text{output\_len}$、つまり$868+0.5B$ミリ秒となる。

プレフィルとデコードのそれぞれについて計算時間と帯域幅時間の式をグラフにすると、プレフィルはどのバッチサイズでも計算時間が支配的で、デコードは帯域幅時間が支配的であることが分かる。⁸

チャンク化プレフィル

ここまでで、8,000:1,000のリクエストでは、プレフィルは計算律速でバッチあたり$1B$ミリ秒かかり、デコードは帯域幅律速でバッチあたり$868+0.5B$ミリ秒かかることが分かった。

実は、帯域幅律速の間は計算資源が遊んでおり、計算律速の間は帯域幅が遊んでいる。この点を活用できる。この遊んでいる資源を使うためによく使われる工夫が、チャンク化プレフィルと呼ばれるものである。基本的な考え方は、デコード中に帯域幅律速になっている間、余った計算資源を使って次のバッチのプレフィルの計算を始めるというものだ。

この重ね合わせの結果、1つのバッチを処理し終えるまでの合計時間は、プレフィルとデコードを通じた合計計算時間と合計帯域幅時間のうち、大きいほうになる。⁹ 直観的に言えば、計算と帯域幅が同時に動けるなら、合計時間は総作業量の多いほうで決まる。

$$\begin{array}{rl}{t}_{\text{cycle}}& =\max \left(t_{\text{prefill compute}}+t_{\text{decode compute}},t_{\text{prefill bw}}+t_{\text{decode bw}}\right)\\ & =\max \left(B\cdot 1\mathrm{ms}+B\cdot 0.5\mathrm{ms},0.9\mathrm{ms}+B\cdot 0.0005\mathrm{ms}+868\mathrm{ms}+B\cdot 0.5\mathrm{ms}\right)\\ & \approx \max \left(1.5B\mathrm{ms},869\mathrm{ms}+0.5B\mathrm{ms}\right)\end{array}$$

同じことを次のようにも書ける。

$$t_{\text{cycle}}\approx \{\begin{array}{ll}869\mathrm{ms}+0.5B\mathrm{ms},& B\lesssim 869\\ 1.5B\mathrm{ms},& B\gtrsim 869\end{array}$$

最終的なスループットは、バッチサイズと出力長の積を、1サイクルを終えるのにかかる時間で割ったものになる。

$$\text{throughput}=\frac{output\_len\cdot B}{t_{\text{cycle}}}=\{\begin{array}{ll}\frac{output\_len\cdot B}{868\mathrm{ms}+0.5B\mathrm{ms}},& B\lesssim 869\\ \frac{output\_len}{1.5\mathrm{ms}},& B\gtrsim 869\end{array}$$

つまり、スループットは、重みの読み込みコストを分散させながら、GB200 NVL72あたり同時利用者数が約870人のバッチサイズに達するまで単調に増える。そこから先は推論実行が計算律速になり、バッチを大きくしてもスループットはもう上がらない。それどころか、バッチサイズを大きくすると、各利用者にトークンを提供する速度（「インタラクティビティ」）が下がる。バッチ全体を処理し終える時間は利用者の数に比例して増えるのに、各利用者がその間に受け取る出力は決まった1000トークンだけだからである。

コンテキスト長の影響も見てみよう。多くのアテンション機構と同様に、MLAの計算コストはコンテキスト長の2乗で増えるので、入力系列が長くなると、計算コストは帯域幅コストよりも速く増える傾向がある。そのため、スループットが計算律速に切り替わるバッチサイズは、コンテキスト長が長くなるほど小さくなる。たとえばコンテキスト長が25,000トークンなら、臨界となる$B$は869から130に下がる。

投機的デコード

推論実行にさらに勢いをつける工夫を、もう一つ見ておこう。投機的デコードは、小さな「ドラフト」モデルに数ステップ先までの候補トークンを提案させ¹⁰、それを本体のモデルが1回の順伝播で検証する手法である。本体モデルの並列の予測がドラフトモデルの自己回帰的な予測と一致すれば、そのトークンは採用される。

主要なAPI提供者の多くは、おそらく投機的デコードを使っている。最小限のコストで推論実行を速くできるからだ。ドラフトモデルは十分小さいので帯域幅と計算のオーバーヘッドは無視できる一方、トークンが1つ採用されるごとに、本体モデルに必要な順伝播が1回減る。唯一の追加コストは、本体モデルの各順伝播で複数トークン先まで並列に予測しなければならなくなり、デコードの演算強度が上がることである。そのため、投機的デコードがスループットを高めるのは、デコードが帯域幅律速のときだけである。最新の実装を使うと、一定のバッチサイズでのデコードのスループットは3倍になる。投機的デコードはプレフィルには効かないので、スループット全体への効果は1.6〜2倍程度にとどまる。

投機的デコードは、一定のバッチサイズでのスループットを高めるだけでなく、最適なバッチサイズにも影響しうる。デコードの演算強度を上げることで、投機的デコードは、デコードが計算律速になり始めるバッチサイズを小さくする（前節で述べたように、その点を超えるとバッチサイズをそれ以上増やす理由はない）。そのため、投機的デコードは最適なバッチサイズを小さくする傾向がある。

以上をすべて合わせると、8,000:1,000のプロファイルでKimi K2.6を提供するGB200 NVL72のスループットは毎秒約61万トークン（tok/s）で、全チップの合計スループットは毎秒360億トークンと推定される。

推論実行ベンチマークによる較正

かなり詳しい理論モデルを組み立ててきたが、いくつか単純化した仮定を置いており、通信の遅延、チップ間の帯域幅、ソフトウェアの非効率といったものを無視している。こうした単純化を補うため、三つの自由パラメータを導入する。

• 計算効率：大きな行列積を実行している間でさえ、GPUの公称最大FLOP/sを100%引き出せることはまれである。これは計算律速の段階にだけ影響する。
• 帯域幅効率：同様に、帯域幅がピーク仕様どおりに出ることもまれである。GPU間の通信は明示的にモデル化していないので、このパラメータには、GPU間で活性化を移す時間も含まれる。
• ステップあたりの遅延：通信遅延、カーネルのスケジューリング、ルーティングの偏りなど、さまざまなものをまとめて表す。バッチサイズにかかわらず固定のオーバーヘッドとしてモデル化しているので、スループットが小さいときほど影響が大きい。¹¹

SemiAnalysisのInferenceXダッシュボードは数千件の推論実行の実験のデータを提供しており、これを使ってこれらのパラメータを較正できる。InferenceXのデータには、使用したGPUの総数と種類、並列化の戦略、バッチサイズ、入力長と出力長、モデルの精度などのパラメータが記録されている。どの実験についても、理論モデルを使って最初のトークンまでの時間（TTFT）と出力トークンあたりの時間（TPOT）を予測し、実環境での性能と比べられる。私たちは、さまざまな設定でNvidiaのGPU上でKimi K2.5を動かした111件の実行を使って、推論実行モデルを較正した。¹²

導入した三つのパラメータは、バッチサイズや何がボトルネックになっているかによって効き方が違う。そのため、実験間のばらつきを利用してこれらを自由パラメータとしてフィットさせ、モデルと実データとの食い違いを最小にできる。¹³ その結果、計算効率65%、帯域幅効率30%、トークンあたりの遅延5ミリ秒という推定値が得られた。これらはおおむね妥当である。帯域幅効率は予想より低いが、モデル化していないGPU間通信の影響も含んでいる。¹⁴

これらの非効率を考慮すると、GB200 NVL72あたりのスループットは64万tok/sから40万tok/sに下がる。¹⁵ 同じ係数をGB300システムにも当てはめ、システムの総数を掛けて拡大すると、次の推定値が得られる。

リクエストの種類	毎秒の出力トークン数
	GB200 NVL72	GB300 NVL72	世界のBlackwell全体
8k:1k	40万	56万	200億
25k:1k	11万	15万	60億
128k:1k	9,000	1万3,000	5億

推論実行の現在と未来

最終的な推定によれば、世界のBlackwell GPUは現在、合わせて毎秒5億〜200億の出力トークンを提供できる可能性がある。地球上の1人あたりにすると、月15万〜700万トークンである。比較のために挙げると、Googleは、Google検索の要約を通じておそらく現在最も多くのトークンを生み出している企業だが、最近、全プラットフォームで12億tok/sを提供していると発表した（入力と出力の両方のトークンを含む可能性が非常に高い）。入力対出力のトークン比を8,000:1,000と仮定すると（これらのリクエストの多くは、おそらく入力の短い検索結果だろう）、出力トークンは毎秒約1億3,000万になる。このことから、Googleのリクエストすべてに、ぜいたくにも高価な1兆パラメータのモデルで応えると言い張ったとしても、利用者のあらゆる需要を満たすだけの推論実行能力は十分にあるといえる。

実際、Googleだけでなく、世界中のすべてのトークンを提供するのにも足りるだろう。Exponential Viewは、全提供者が処理するトークンの総数を四半期あたり4京トークン、つまり毎秒約50億トークンと推定している。これはGoogleの通信量の4倍である。それでも、少なくとも短いコンテキストと中程度のコンテキストの設定であれば、これらのトークンをすべてKimi K2.6のようなモデルで提供するだけの計算能力はある。

しかも、インフラの配備とチップの効率向上の組み合わせによって、推論実行能力は時とともに伸びている。追うべき動向は計算能力とメモリ帯域幅の伸びの二つで、それぞれ年3.4倍と年4.1倍で指数関数的に伸びている。長期的には、伸びの遅いほうの要因、つまりこの場合は計算能力が、推論実行能力全体の伸びを決める。短期的には、メモリ帯域幅が主なボトルネックである間は、伸びは年4.1倍に近くなりうる。これはとりわけ、ソフトウェア開発のような長いコンテキストのリクエストに影響する。そうしたリクエストのほうが、メモリ律速の度合いが強いからだ。実際に、短いコンテキスト（入出力8,000:1,000）と長いコンテキスト（128,000:1,000）の推論実行負荷について伸びをモデル化すると、違いはごくわずかだった。モデルの規模とコンテキスト長を固定した場合の世界の推論実行能力は、年3.4倍で伸びるとみなしてよく当てはまる。

これは、モデルの規模と価格を固定したときのトークン需要の伸びと比べてどうだろうか。残念ながら明確に比べるのは難しいが、手元の代理指標を見るかぎり、需要のほうがはるかに速く伸びているようだ。たとえば、この1年にGoogleが処理したトークンの量も、Exponential Viewによる全提供者のトークン量も、年およそ10倍で伸びている。

別の角度から、現在最もAIを集中的に使っている利用者、つまりソフトウェアエンジニアのトークン需要を見ることもできる。最近の報道によれば、Appleの一部のソフトウェアエンジニアは1日に最大300ドル分のトークンを使うことを認められている。これは、Claude Opus 4.7のAPI価格で1日約500万出力トークン、Kimi K2.6なら1日2,500万出力トークンにあたる。¹⁶ もう一つの比較材料はMetaで、従業員8万5,000人が組織全体で1か月に60兆トークンを使った。この数字は入力と出力の両方のトークンを含む。入力対出力のトークン比を25,000:1,000と仮定すると、従業員1人あたり1日約100万出力トークンになる。

2025年時点で、世界のソフトウェアエンジニアは約3,000万人いた（推定は2,000万人から5,000万人まで幅がある）。また、Stack OverflowのAI利用に関する2025年の調査によれば、2025年半ばの時点で、AIを毎日使っている開発者は約47%にとどまっていた。毎日AIを使うソフトウェアエンジニア全員がMetaやAppleと同じくらい集中的に使ったとすると、需要は合計で1日10兆〜350兆トークン、つまり毎秒2億〜40億トークンになる。最も長い128,000:1,000のコンテキストでは、今日のBlackwellチップで、Kimi K2.6ほどの大きさのモデルを使うコーディングエージェントのこの潜在需要すべてに応えるのは難しいだろう。また、AIを使う開発者の数も、その利用の強度も、今後も急速に伸び続ける可能性が高いと思われる。

以上の代理指標はどれも不完全である。それらのトークンの内訳も、伸びの大半が小さなモデルによるのか大きなモデルによるのかも、コンテキスト長がどれだけ伸びたのかも分からない。この期間に多くの提供者の価格は大きく変わっており、それが需要に影響している。¹⁷ さらにこの分析は、推論実行の効率の非常に速い向上をまったく考慮していない。効率の向上は、能力を高めることで一定規模のモデルへの需要を増やす一方、それらをより小さなモデルに置き換えることで需要を減らしもする。

いずれにせよ、これらの代理指標からは、モデルの規模と価格を固定したときの需要が非常に速く、おそらく供給の拡大より速く伸びていると考えられる。そこに、とりわけコーディングなどのエージェント的な用途による、より長いコンテキストでの利用へと向かう流れが重なる。

AIの需要が大規模モデルを提供する能力を上回っているなら、当然予想される結果として、大規模モデルのトークンの価格が上がる。つまり「計算資源の逼迫」は、すでに来ていないとしても、目前に迫っていると考えられる。実際、Anthropicは需要を管理するために、ピーク時間帯の利用枠を減らす、オフピーク時間帯の利用を促すといった措置をとっている。

「逼迫」のなかで、日常的な利用者は価格のせいでAIから締め出されるのだろうか。必ずしもそうではない。これまで推論実行の効率は非常に速く向上してきた。それが続けば、現在の用途は、より小さく、より効率よく提供できるモデルでまかなえるだろう。これまで見てきた提供トークン数の急速な伸びを支えてきたのも、まさにこれだと言えるかもしれない。最大規模のモデルは、コーディングのように、最新の能力を使えることがトークンあたりの高い価格に見合う、最も生産性の高い用途に回されることになるだろう。

詳しいフィードバックをくださったDavid Schneider-Josephに感謝する。また、Dwarkesh Patel、Jean-Stanislas Denain、Josh You、David Owen、Phil Trammel、Nick Merrill、Vassil Tashev、William Gildeaにも感謝する。