原文は中国語のメモを日本語に翻訳・編集したもの。主要な数字は WebSearch で 2026 年 6 月時点の公開ソース（NVIDIA 公式、TrendForce、Bernstein、SemiAnalysis 等）に照合した。原文のまま転記した部分には「概算」「執筆時点」と注記している。

「HBM の需要がなぜ必ず指数で増えるのか、そしてその指数増加がなぜ止まらないのか」を、GPU アーキテクチャ進化の本筋から導く。結論を先に置くと、現代の推論 GPU の最高 KPI（トークン throughput）は HBM size × HBM 帯域 の積で天井が決まるため、HBM の代々 2 倍が止まると GPU の代々 2 倍も止まる。

HBM の周期性をめぐる論争には、以前から大きな温度差がある。楽観派は「AI 需要の規模が違う」と言う。一方、市場の主流は「過去の上昇周期にも年 20% 超の需要増はあった。今回も結局は commodity 性に引き戻され、需要ピークで増産した分が需要下降と重なって地獄を見るだろう」と懐疑的だ。

ここでは、計算チップのアーキテクチャ視点から第一原理に降りて、「今回は本当に違う」と言える根拠を解きほぐす。

歴史：CPU が算力を主導していた時代

長らく我々は CPU 主導の算力時代を生きてきた。CPU の最高 KPI は performance、つまり「より速く回る」ことで、世代ごとに様々な手段で速度を上げてきた。最初は周波数、そのあとは superscaler などのアーキテクチャ進化。

なぜこの時代、DDR は技術進化のスピードを上げる必要がなかったのか。DDR3 から DDR5 まで実に 15 年もかかった。

DDR の役割が「補助」、しかも「補助としても弱い」存在だったからだ。業界経験則として、DDR の速度を 2 倍にしても CPU performance はせいぜい 20% 未満しか伸びない。

帯域を上げてもなぜ効かないか、理由は 2 つ。

1. CPU は DDR レイテンシを隠す設計を積み上げてきた。superscaler、issue width 拡大、巨大な ROB と register renaming で並列度を稼ぎレイテンシを隠す、L1/L2 cache。これらが DDR 帯域への依存を削いだ
2. CPU の workload は DDR 帯域をそこまで要求しない。Web ブラウジングのような日常負荷、さらにはクラウドの一般負荷でも、DDR 帯域は深刻に過剰

要するに CPU 時代、DDR の帯域速度はあまり意味がなく、DDR4 と DDR5 はゲームを除けば違いが見えにくかった。JEDEC 標準の進歩自体もゆっくりだった。

容量も同様で、ほとんどのアプリは常時 DDR に居座る必要がなく、必要なときにディスクから持ってくれば事足りる。アプリのサイズも急増しないため、容量需要も穏やかだった。直近 10 年で平均 PC の DDR 容量は 7〜8GB → 23GB、わずか 3 倍。

そして容量も速度も伸び悩んだ事実は、そのまま売上に直撃する。サイズ課金が収益の主軸で、速度向上は「容量の単価を上げる技術アップグレード」程度の意味しかない。両方とも伸びないので、需要は PC／スマホの出荷台数増に従う「景気変動つき commodity」になった。

つまり DRAM は「帯域」「容量」の両軸で半導体産業の従属品にすぎず、DDR の世代交代の限界効用は低く、CPU 時代の最高 KPI とは直接ほぼ無関係だった。

genAI 大規模モデル時代：計算範式の転換で最高 KPI が根本から変わる

GPU が AI 推論時代に入ると、もはや「跑分（ベンチ）」を見るのではなくなった。最高 KPI は算力 TOPS／FLOPS ではなく、トークンのコスト、特に「単位コスト・単位電力あたりの overall token throughput」になる。

次点に来るのが トークン throughput 速度。agent 時代は多くのタスクが直列化され、トークン速度はユーザー体験の重大なボトルネックになる。

これがジェンスン・フアンが「AI Factory」概念を打ち出した理由だ。最低コストで最大のトークンを吐き、かつトークン速度を可能な限り上げる。

AI トレーニング時代の老黄の経済学は TCO（total cost of ownership）：GPU を買うほど節約できる。

推論時代の彼のトークン経済学は別物だ。AI 推論の粗利は十分大きく、論理は反転する。NVIDIA GPU は「世界でトークン単価が最も安くなる GPU」なので、買うほど儲かる。

最高 KPI は Pareto frontier 曲線そのものになり、トークン throughput とトークン速度の両軸で最適化する（図1）。NVIDIA の token factory の代際進歩とは、要するに Pareto frontier 全体を右上に押し上げることだ。これが推論時代の最重要 KPI。

トークン throughput 指数増加の本質を、HBM の天井に分解する

ここからが本稿で最も重要なロジックチェーン。トークン throughput の指数増加という本質から、HBM size と HBM 帯域の指数増加へと天井を分解していく。

シングルカード GPU で batch size = 1 の時代、トークン throughput の次元は 1 つしかなかった ── HBM の帯域速度。帯域が高いほど throughput が大きくなる、それだけ。

しかし NVL72 の年代に入ると、推論はシングルカードの世界ではなくなる。72 個の GPU と 36 個の CPU から成るシステム全体が、HBM 帯域と算力をすべて使い切る「トークン工場」になる。

トークン throughput の増加は、2 つの軸に依存する。同時にバッチ処理するリクエスト数 × 各ユーザーリクエストの平均トークン速度。すなわち：

batch size × per-user トークン速度

Rubin NVL72 を例に取ろう。per-user トークン速度を 100 token/s と仮定し、同時に 1,920 リクエストを処理した場合、throughput は 19.2 万 token/s。1 ラックの定格電力は約 120 kW（NVIDIA 公式値で 120.8 kW）、つまり 1 MW あたり約 1.6M token/s が処理できる計算になる（数値は架空ユーザー想定の計算例）。

つまり追求すべきは、batch size と per-user 平均トークン速度の 2 パラメータ。両者の積が最高 KPI、トークン throughput になる。

第 1 パラメータ：batch size の天井は HBM size

バッチに乗る各リクエストは、それぞれ KV cache を抱える。この KV cache は HBM 上に置く必要があり、サイズは数 GB〜数十 GB に達する。hot KV cache は常時高頻度・高速に読まれるので、HBM 以外には置けない。たとえばモデルが 80 層なら、トークン 1 個の生成ごとに 80 回 HBM 上の KV cache を読みに行く。

バッチサイズが増えれば、hot KV cache はそれに線形比例して増えていく。

そして、そのバッチに乗っている全リクエストの hot KV cache を HBM に載せきる必要がある以上、HBM size は batch size の増加に線形比例して伸びていかなければならない。

空港のシャトルバスで言えば、できるだけ速く搭乗口まで乗客を運びたい。HBM size が小さい＝シャトルバスが小さいということで、何往復もすることになる。

結論：batch size の天井は HBM size に依存する。

第 2 パラメータ：per-user トークン速度の天井は HBM 帯域

大規模モデルの decode 段階の速度は、HBM 帯域がボトルネック。トークン 1 個を出すたびに、活性化した重みと KV cache を何度も読みに行くからだ。

LPU（Language Processing Unit）の登場で、batch がそれほど大きくない場合は活性化重みを SRAM に載せ替えられるようになったが、それでも 1 トークン生成ごとに KV cache は HBM から何度も読む必要がある。HBM 帯域が高いほど、1 トークン生成速度はほぼ線形に速くなる。

シャトルバスのドア幅と同じだ。ドアが広いほど乗客（トークン）が一気に乗降できる。

GPU の他の構成（compute や interconnect）は、batch 増加への適合と、token compute 速度を HBM 増加にバランスさせるために配置されている。余った算力で帯域を稼ぐ技術（帯域圧縮系）すら使われる。

空港シャトルバスのアナロジーで整理

• 車内サイズ＝HBM size（容量）：1 回で乗せられる乗客（同時に格納できるリクエストの KV cache）数を決める。車内が大きいほど一度に運べる batch size が大きい。車が小さいと 100 人運ぶのに 2 往復が必要で、システム全体の throughput が上がらない
• ドア幅＝HBM 帯域：乗客の乗降速度を決める。ドアが広ければ皆が一気に乗り込める（decode／generate 速度が極めて速い）。ドアが狭いと、たとえ車内が 200 人乗りでも、1 人ずつ並んで乗降することになり時間を全部食う

乗客 throughput ＝ 車内サイズ × ドア幅

トークン経済学の第一原理を、形式的に書く

ここまでのロジックから、トークン経済学のハードウェア需要の第一原理が導かれる：

Token throughput = HBM size × HBM Bandwidth

AI 推論時代の最高 KPI は、実質的に HBM の 2 つの軸の進化に深く依存する。

トークン throughput を代々 2 倍にし続けたいなら、各世代の単一 GPU 上で HBM size × HBM 帯域 の積を代々 2 倍にしなければならない。

これは歴史上初めて、HBM の size が最高 KPI（トークン throughput）に直接効くようになった瞬間でもある。

この理論を検証するには、NVIDIA の A100 から Rubin Ultra までの数世代のトークン throughput と HBM size × HBM 帯域を同じ図に並べればいい（図2）。

対数軸上で見ると、2 本のカーブの動きが驚くほど一致する。

実は HBM size × 帯域の方が、トークン throughput よりも少し速く伸びている。HBM は天井を決めているので、実際の利用率（utilization）は 100% には届かない。HBM size × 帯域が 1000 倍になったとしても、他の算力やアーキテクチャの適合次第で、その 1000 倍の天井をすべて使い切るのは難しい。

このカーブは偶然ではなく、システム最適化の必然解だ。throughput = batch × bandwidth、これがトークン factory 経済学を貫く第一原理であり、避けようがない。

ソフトウェア最適化で帯域・HBM の需要は減らないのか

これはハードウェアとは独立の次元だ。「CPU 上のソフトが最適化されて速くなれば、CPU はもう 10 年進化しなくていいのか？」と問うのと同じ。

ソフトが速くなって CPU 屋が儲からなくなる、それを避けるために CPU が生き残る道は 1 つしかない。標準ベンチでソフト最適化を考慮せず、代々のスコアを上げ続けること。さもなければ売れない。

GPU も同じ。ソフト最適化と「自分のトークン throughput KPI を毎年大きく進化させる」のは別の話。

トークン需要が増え続ける限り、トークン throughput の追求は止まらず、HBM size × HBM 帯域の追求も止まらない。

もし HBM size や HBM 帯域の進化が鈍れば、ジェンスン・フアン自身が御三家（Samsung／SK hynix／Micron）に乗り込んで技術アップグレードを督促するだろう。なぜなら、これが彼の GPU の天井だからだ。天井が止まれば、彼の GPU は売れなくなる。

もちろん NVIDIA は HBM の天井の外側からも throughput をひねり出すべく、異種計算アーキテクチャを総動員している。LPU の試みや、Rubin CPX（GDDR7 128GB を載せた prefill 専用アクセラレータ）は、Pareto frontier の右側（高 per-user 速度域）を別アプローチで持ち上げた好例。

まとめ

HBM はもう「成り行きで動く DRAM の脇役」を卒業した。指数級需要が敷いた一方通行のレーンの上で、ほとんど運命じみた形で、この産業叙事詩の本舞台へと押し上げられた。

推論パラダイムの第一原理がここまで来てしまった以上、ジェンスン・フアンが GPU を売り続ける限り、HBM は代々 2 倍を続けねばならない。これは供給側の内生的な圧力で、AI 需要の波とは無関係、マクロ景気とも無関係、ハイパースケーラーの気分とも無関係。

残された問いは 1 つだけだ：

需要が物理的に指数増加に固定されているとき、供給側のプレイヤー 3 社は、過去 30 年と同じように自らの手でまた周期の泥沼に転落するのか？

これは パート II：HBM／DRAM／SSD は伝統的周期性から逃れられるか に続く。

ファクトチェックメモ（2026-06-26 時点）

シャトルバスのアナロジーや「HBM size × HBM 帯域 = throughput 天井」の式は、業界で広く語られる定性的整理を著者が定式化したもの。NVIDIA／SemiAnalysis 等の公開資料と一貫した方向性で、数式そのものは公式値ではなく概念モデルとして扱う。