Skip to content
Published on

メモリウォールとHBM — AI性能を分ける本当のボトルネック

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに

AIハードウェアを語るとき、私たちはよくTFLOPS、つまり毎秒の浮動小数点演算回数を見ます。「このチップは何ペタフロップだ」という具合です。しかし現場でモデルを動かしたことのある人なら誰もが同じ挫折を味わいます。スペックシート上の演算能力は途方もないのに、実際にモデルを動かすとその能力の一部しか使えません。GPU使用率が30%を超えないこともよくあります。なぜでしょうか。

答えはほとんど常に同じです。演算ユニットがデータを待っているからです。 計算する掛け算器は十分あるのに、その掛け算に入れる数値(重み、活性値)をメモリから十分速く取ってこられないのです。これがメモリウォール(memory wall)であり、2026年のAI性能を実質的に分ける本当のボトルネックです。本記事ではメモリウォールの正体と、開発者がそれを理解し扱う方法を整理します。

このテーマが特に重要な理由は、メモリウォールがチップ設計者だけの問題ではないからです。モデルを学習も、チップを作りもしない普通のアプリケーション開発者でさえ、この原理を理解すれば同じハードウェアで推論を何倍も速く安く回せます。逆にこの原理を知らなければ、高価なチップを買ってもその潜在能力の一部しか使えずコストを浪費しがちです。メモリウォールは抽象的なハードウェア理論ではなく、いま自分の推論請求書を左右する実践的な知識です。

本記事の目標はシンプルです。皆さんが次の一つの問いを本能的に投げかけられるようにすることです。「このワークロードの本当のボトルネックは演算か、メモリか?」この問い一つが推論コストを半分に減らし、見当違いのチップを買う失敗を防いでくれます。華やかなTFLOPSの数字に隠れた本当のボトルネックを見抜く目、それが本記事が伝えようとする核心的な能力です。

全体の流れはこうです。まず「演算は安く、データ移動は高い」という根本的な非対称性を押さえ、メモリウォールの正体と、それに立ち向かう武器であるHBMを見ていきます。続いて演算バウンドかメモリバウンドかを判断する道具(rooflineモデル)とKVキャッシュ、量子化、メモリ階層を扱い、次世代メモリの動向と開発者のための実践的なまとめで締めくくります。

1. 演算は安く、データ移動は高い

チップ設計の一つの不都合な真実は、数十年にわたり演算能力がメモリ能力よりはるかに速く発展してきたことです。トランジスタを増やして掛け算器を増やすことは比較的簡単でしたが、データをチップの中へ速く運び込むことはそれほど速く良くなりませんでした。

エネルギーの観点から見るとさらに劇的です。2つの数を掛ける演算が消費するエネルギーより、その数を遠くのメモリから取ってくるのにかかるエネルギーのほうがはるかに大きいのです。データが遠いほどコストが大きくなります。

データ移動エネルギー(相対的、概念)

 チップ内部演算(掛け算)   .              最も安い
 オンチップSRAMアクセス     ...
 HBM(パッケージ内)アクセス ..........
 チップ外(別ノード)       ...................... 最も高い

 -> 遠くからデータを取ってくるほどエネルギー・時間コストが急増する。

この非対称性がすべてを説明します。良いAIハードウェアと良いAIコードの大部分は「演算を減らすこと」ではなく「データ移動を減らすこと」に関するものです。

なぜこの非対称性が生じたのか

この非対称性は偶然ではなく、物理とプロセスの結果です。トランジスタをより小さく作りチップにより多く詰め込むことは、数十年にわたり比較的着実に進歩してきました。だから演算器を増やすことは相対的に簡単でした。一方、データをチップの内外へ速く運ぶことは、ピンの数、配線の物理的限界、電力と発熱といった制約に縛られ、それほど速く良くなりませんでした。

その結果、演算能力とメモリ供給能力の間の隔たりが世代を重ねるごとに広がりました。チップはますます多く計算できるようになりましたが、その計算機にデータを供給する能力は追いつきませんでした。この累積した隔たりこそがメモリウォールです。そしてモデルが巨大になるほど(重みが多くなるほど)読むべきデータが増えるため、この問題は時間が経つほど深刻になります。

2. メモリウォールとは何か

メモリウォールは、演算速度とメモリの供給速度の間で広がり続ける乖離を指します。チップの演算能力は速く伸びましたが、その演算器を養うデータ供給能力(メモリ帯域幅)はそれほど速く伸びませんでした。その結果、強力な演算器がデータを待って遊ぶ時間が長くなります。

たとえるとこうです。厨房に料理人が100人いるのに(演算器)、食材を運ぶ通路が一つしかなく(メモリ帯域幅)、ほとんどの料理人が材料を待って立っている状況です。料理人を200人に増やしても、通路がそのままなら料理は速く出てきません。増やすべきは通路です。

これが2026年のチップ設計が演算器の増設よりメモリ帯域幅とインターコネクト、パッケージングに集中する理由です。

使用率30%の秘密

冒頭で述べた「GPU使用率30%」現象を、メモリウォールで改めて説明してみます。使用率が低いということは、演算器が遊ぶ時間が多いという意味です。ところが演算器が遊ぶ理由は、仕事がないからではなく、仕事に必要なデータがまだ到着していないからです。

使用率が低い理由(概念)

 時間軸 ->
 演算器:  [計算][      待機      ][計算][   待機   ][計算]
 メモリ:  [   データ運搬中       ][  運搬中     ]

 演算器はデータを待ってしばしば止まる。
 -> 「より速い演算器」ではなく「より速いデータ供給」が必要だ。

したがって「GPU使用率をどう上げるか?」という問いの答えは、たいてい「演算器をもっと忙しく」ではなく「データをより速く供給するか、読むデータを減らすか、一度読んだデータをもっと再利用する」ことです。この視点の転換がメモリウォールを理解する第一歩です。

3. HBM — メモリウォールに立ち向かう武器

この通路を広げるための最も重要な武器がHBM(High Bandwidth Memory)です。一般のメモリ(DRAM)をチップの横に平面で置く代わりに、HBMはメモリチップを垂直に積み(3Dスタック)、それを演算チップのすぐ横にパッケージで貼り付けます(例: CoWoSパッケージング)。その結果、データの往来する距離が短くなり、非常に広い幅の接続を置けるため帯域幅が爆発的に大きくなります。

HBM世代

HBM世代の流れ(概念)

 HBM2 -> HBM2e -> HBM3 -> HBM3e -> HBM4

 世代が上がるほど:
   - 積層段数の増加 -> 容量の増加
   - ピンあたり速度の増加 -> 帯域幅の増加
   - パッケージングの精緻化 -> 効率の増加

2026年の核心はHBM3eからHBM4への移行です。HBM4はインターフェース幅を広げ積層をさらに高くして、帯域幅と容量を同時に引き上げます。前の記事で扱った次世代プラットフォーム(Vera Rubinなど)がHBM4を採用する理由がまさにメモリウォールの緩和です。

なぜHBMは高く希少なのか

HBMは強力ですがタダではありません。メモリを垂直に積み、演算チップの横に精密に貼り付けるプロセスは、一般のメモリよりはるかに難しく高価です。積層の過程で一つでも不良が出れば、スタック全体を捨てなければならないため歩留まり管理も困難です。さらにHBMと演算ダイを一つにまとめる高度なパッケージング(例: CoWoS)の生産能力そのものが限られています。

HBMが希少な理由(概念)

 - 3D積層: 垂直に積む精密プロセス、不良時にスタック全体を損失
 - 高度パッケージング: 演算ダイと一つのパッケージにまとめる能力が希少
 - 需要急増: すべてのAIアクセラレータがHBMを欲しがる

 -> HBMとパッケージングの生産能力がAIアクセラレータ供給の実質的なボトルネック。

だから2026年のAIアクセラレータ不足の話の大部分は、実は「チップそのもの」より「HBMとパッケージング」の不足です。演算ダイを刷れても、そこに貼り付けるHBMとパッケージング能力が足りなければ完成品を作れません。メモリウォールは性能の問題であるだけでなく、サプライチェーンの問題でもあるのです。

帯域幅 vs 容量

HBMには2つの異なる資源があり、この2つを混同してはいけません。

  • 容量(GB): モデルの重みと活性値、KVキャッシュが入る空間。足りなければモデルがチップに載らないか、複数チップに分割する必要があります。
  • 帯域幅(TB/s): その空間からデータをどれだけ速く読み書きするか。推論速度を直接決める場合が多いです。

推論でよくある誤解は「容量さえ大きければよい」というものです。モデルが入っても、帯域幅が不足すればトークン生成が遅くなります。2つの資源を併せて見る必要があります。

容量 vs 帯域幅(たとえ)

 容量   = 倉庫の大きさ      (どれだけ多く保管するか)
 帯域幅 = 出入口の幅        (どれだけ速く取り出すか)

 大きい倉庫に狭い扉だと、物はたくさん入れても速く取り出せない。
 推論速度はしばしば「倉庫の大きさ」ではなく「扉の幅」が決める。

このたとえの教訓は、チップのスペックを見るとき「メモリ何GB」という容量の数字だけに惑わされるな、ということです。その隣の「帯域幅何TB/s」が推論速度にはより直接的な影響を与える場合が多いです。モデルが入るかは容量の問題であり、十分に速いかは帯域幅の問題です。この2つは別の問いであり、両方を満たして初めて良い推論体験が生まれます。

4. 算術強度とrooflineモデル

演算バウンドかメモリバウンドかを判断する道具がrooflineモデルで、その核心概念が算術強度(arithmetic intensity)です。算術強度は「メモリから取ってきたバイト一つあたり何回の演算をするか」です。

算術強度の定義

 I = (実行した演算数) / (移動したバイト数)
   = FLOPs / Bytes

 I が大きい  -> 取ってきたデータを多く再利用 -> 演算バウンド
 I が小さい  -> データを取ってきてすぐ一度使って捨てる -> メモリバウンド

rooflineモデルはこの算術強度に応じて達成可能な性能の上限を描きます。

rooflineモデル(概念)

 達成可能性能
   ^
   |              ______________  演算上限(peak FLOPS)
   |             /
   |            /  <- この斜面の傾き = メモリ帯域幅
   |           /
   |          /
   +---------+------------------> 算術強度 (FLOPs/Byte)
            転換点

 算術強度が転換点より小さければ(斜面領域)メモリ帯域幅が性能を制限する。
 大きければ(平坦領域)演算能力が性能を制限する。

LLM推論、特にトークンを一つずつ生成するデコード段階は算術強度が非常に低いです。巨大な重みを一度読み込んで小さな入力と掛け、捨てるからです。だからLLM推論はほぼ常にrooflineの左の斜面、つまりメモリバウンド領域に位置します。この一つの事実が推論最適化のほぼすべてを説明します。

rooflineで見る最適化の方向

rooflineモデルの本当の価値は「どこを直すべきか」を教えてくれることにあります。自分のワークロードが斜面領域(メモリバウンド)にあるなら、演算器をもっと増やしても無駄です。斜面の傾き、つまりメモリ帯域幅を高めるか、算術強度を引き上げて右へ移動しなければなりません。

メモリバウンドのとき効果があること / ないこと

 効果なし:  演算器の追加、peak FLOPSを誇るより高価なチップ
            (すでに演算器は遊んでいる)

 効果あり:  - メモリ帯域幅の高いチップ
            - 量子化で読むバイトを減らす
            - データ再利用を高めて算術強度を上げる(SRAM活用)
            - 不要なメモリアクセスの除去

このシンプルな洞察が推論最適化の羅針盤になります。高価なチップを買う前に、自分のワークロードがrooflineのどこにあるかをまず確認するのが順序です。大半のLLM推論は左の斜面にあるので、答えはほぼ常に「演算を増やすな、データ移動を減らせ」です。

5. KVキャッシュ — 推論メモリの隠れた主役

LLM推論でメモリを語るとき欠かせないのがKVキャッシュです。トランスフォーマーはトークンを生成するとき、以前のトークンに対するkeyとvalueを保存して再利用します。毎回最初から計算し直さないためです。

問題はこのキャッシュが文脈長に比例して大きくなることです。

KVキャッシュサイズ(概念)

 キャッシュサイズ おおよそ ∝ (バッチサイズ) x (文脈長) x (レイヤー数)
                  x (ヘッド次元) x (2: keyとvalue) x (精度バイト)

 長い文脈 + 多い同時ユーザー -> KVキャッシュが重みと同じくらい、
 ときにはそれ以上に大きくなる。

長い文脈と多くの同時ユーザーを扱う2026年のサービスでは、KVキャッシュがメモリ容量と帯域幅の両方を食いつぶす元凶になります。だからKVキャッシュを圧縮したり、精度を下げたり(例: INT8キャッシュ)、ページ単位で効率的に管理する技法が推論最適化の核心として浮上しました。

KVキャッシュが帯域幅を食う仕組み

KVキャッシュは容量だけを食うのではなく帯域幅も食います。トークンを一つ生成するたびに、これまで積み上げたすべてのkeyとvalueを再び読まなければならないからです。文脈が長いほど毎トークンごとに読むべきキャッシュが大きくなり、これがそのまま帯域幅の負担につながります。

KVキャッシュと帯域幅(概念)

 短い文脈:  トークン生成時に小さなキャッシュ読み込み -> 軽い
 長い文脈:  トークン生成時に巨大なキャッシュ読み込み -> 毎トークン重い

 -> 長い文脈は「容量」だけでなく「毎トークンの帯域幅」を併せて消費する。
   生成が長くなるほどトークンあたりのコストが次第に増える理由。

このため長い文脈のサービスでは、生成の後半になるほどトークン生成が遅くなる現象が現れます。キャッシュが増え続けるからです。KVキャッシュ最適化が単なるメモリ節約ではなく速度とコストの問題である理由がここにあります。精度を下げたキャッシュや圧縮は容量と帯域幅を同時に減らし、長い文脈推論のコスト曲線をなだらかにします。

6. 量子化で帯域幅を削減する

メモリバウンドな世界では、量子化は単なるメモリ節約技法ではなく速度向上技法です。この点は直感に反するため重要です。

重みをFP16からINT8に下げるとメモリ使用量が半分になります。ところが推論がメモリバウンドなら、半分のバイトを読むということはすなわち2倍速く読むということです。つまり量子化はメモリバウンド区間でスループットを直接引き上げます。

量子化の二重効果(メモリバウンド推論)

 FP16重み:  [##] 8バイト読み込み -> 1単位時間
 INT8重み:  [#]  4バイト読み込み -> 0.5単位時間 (2倍速い)
 FP4重み:   [|]  2バイト読み込み -> 0.25単位時間 (4倍速い)

 メモリがボトルネックのとき、精度を下げると容量も節約され速度も上がる。

もちろん精度を下げると精度損失のリスクがあります。だから2026年の推論スタックは、精度損失を最小化する精緻な量子化技法(重みごと・チャネルごとのスケーリングなど)と、ハードウェアが直接支援する低精度形式(FP8/FP4)を組み合わせて使います。前の記事で見たBlackwellの第2世代Transformer Engineがまさにこの流れのハードウェア的な答えです。

トークン生成速度を帯域幅から推定する

メモリバウンドの威力を体感するために、トークン生成速度を帯域幅だけで大まかに推定する思考実験をしてみます。核心となる直感はこうです。decode段階でトークンを一つ生成するには、モデルのすべての重みを一度ずつ読まなければなりません。

帯域幅でトークン生成速度を推定(概念)

 トークン一つあたり読むべきバイト ~= モデル全体の重みサイズ
 毎秒生成可能なトークン数 ~= (メモリ帯域幅) / (モデル重みサイズ)

 例) 重みを半分のサイズに量子化すると
     -> トークンあたり読むバイトが半分
     -> 同じ帯域幅で約2倍のトークンを生成

このシンプルな推定は、なぜ量子化がそのまま速度なのかを明確に示します。トークンあたり読むバイトを半分に減らせば、帯域幅が同じでも毎秒生成トークンが約2倍になります。もちろん実際にはKVキャッシュ、活性値、オーバーヘッドなど他の要素が絡みますが、「トークン生成速度は帯域幅に比例し重みサイズに反比例する」という大きな絵は変わりません。より速いトークン生成を望むなら、より高価な演算器よりも、より広い帯域幅やより小さな重みが答えである場合が多いのです。

7. メモリ階層とオンチップSRAM

メモリは一つではなく階層です。速く小さいものから遅く大きいものまで層をなして積まれています。

メモリ階層(速く小さい -> 遅く大きい)

 レジスタ        最も速い、極小容量
 オンチップSRAM   非常に速い、小さい容量(数MB 〜 数十MB)
 HBM             速い、大きい容量(数十 〜 数百GB)
 ホストメモリ     遅い、非常に大きい容量
 別ノード         最も遅い、事実上無制限

良い推論カーネルの秘訣は、データをできる限り速い階層に長くとどめることです。一度HBMからオンチップSRAMへ取ってきたデータを、再びHBMへ往復せずに最大限再利用するのです。これがアテンション演算をメモリ効率的に再構成する技法(データを小さなブロックに分けてSRAM内で処理)の核心アイデアです。算術強度を人為的に引き上げてrooflineの右へ移すわけです。

このアイデアが強力なのは、まったく同じ数学的結果を出しながらも、メモリアクセスのやり方だけを変えて速度を引き上げるからです。演算の量はそのままなのに、データをどう運び再利用するかを賢く変えるだけで大きな差が出ます。メモリウォール時代の良いカーネル設計が「数学」より「データ移動の振り付け」に近い理由がここにあります。

極端な事例として、一部のウェハースケールチップ(例: Cerebras WSE-3)は、いっそ巨大なオンチップSRAM(約44GB)と途方もないオンチップ帯域幅(約21 PB/s)を置いて、HBMを往復するコスト自体をなくそうとするアプローチを取ります。メモリウォールに対する別の種類の答えです。

このアプローチの発想は根本的です。一般のチップは小さなSRAMと大きなHBMの間を絶えずデータが往来しなければなりませんが、ウェハースケールチップはチップ全体が極めて巨大なため(ウェハー1枚まるごと)、モデルをまるごとオンチップSRAMに載せる余地を作ります。すると最も高価なデータ移動である「チップ外メモリの往復」が消えます。

一般チップ vs ウェハースケール(メモリアクセスの観点)

 一般チップ:      演算 <-> 小さなSRAM <-> HBM(チップ外)  <- HBM往復コスト大
 ウェハースケール: 演算 <-> 巨大なオンチップSRAM          <- チップ外往復を最小化

 -> データをチップ内に閉じ込め、メモリウォールの最も高価な部分を回避する。

もちろんこの方式にも代償があります。巨大な単一チップは製造が難しく高価で、すべてのワークロードと予算に合うわけではありません。しかし「メモリウォールを回避する最も直接的な方法は、データをそもそもチップの外へ出さないことだ」という発想は、メモリ中心の思考がどこまで行けるかを示す良い事例です。

8. 次世代メモリの動向

メモリウォールを越えるための研究はHBM世代の更新を超え、より根本的な方向へも向かいます。

  • インメモリコンピューティング: データを演算器へ持ってくる代わりに、メモリの中で直接演算しようとするアプローチです。データ移動そのものを減らす最も急進的な方法です。「データを移して計算する」というフォン・ノイマン構造の前提そのものを覆そうとする試みであり、成功すればメモリウォールを根本から崩す潜在力があります。
  • フォトニックインターコネクト: 電気の代わりに光でデータを運び、チップ間通信の帯域幅とエネルギー効率を引き上げようとする研究です(Lightmatterなど、DARPA関連プロジェクトを含む)。
  • 光/フォトニックテンソルコア: 光で行列演算そのものを行おうとするより遠い未来の研究です。
  • チップレット・高度パッケージング: 複数の小さなチップ(chiplet)を一つのパッケージに密に貼り付け、チップ間距離を縮め帯域幅を高めます。

これらの研究はまだ大半が商用化初期か研究段階ですが、方向は一貫しています。結局メモリウォールの本質、すなわちデータ移動コストを減らすことです。

三つのアプローチの全体像

次世代メモリ研究を全体像でまとめると、メモリウォールに立ち向かう戦略は結局三つの方向に分かれます。

メモリウォールに立ち向かう三つの戦略(概念)

 1. より速く運ぶ:  HBM世代の更新、フォトニックインターコネクト
                   (データ移動をより速く効率的に)

 2. より少なく運ぶ: 量子化、スパース性、データ再利用、オンチップSRAM
                   (そもそも移動するデータを減らす)

 3. 運ばない:      インメモリコンピューティング、ウェハースケール
                   (データを移す代わりにその場で処理)

興味深いのは、この三つの戦略が互いに排他的ではないことです。実際のシステムは三つを組み合わせます。速いHBMを使いながら(1番)、量子化で読むバイトを減らし(2番)、オンチップSRAMにデータを閉じ込めて再利用します(3番に近い)。開発者が直接コントロールできるのは主に2番です。ハードウェアが1番と3番を提供しても、量子化・キャッシュ管理・データ局所性といったソフトウェアの選択で「より少なく運ぶ」を実践するのは私たちの役目です。だからメモリウォールはチップ設計者だけの問題ではなく、すべてのAI開発者の問題なのです。

9. 開発者が理解すべき示唆

チップを設計しない開発者にとっても、メモリウォールの理解は実質的な武器になります。

  • 推論は通常メモリバウンドです。 だから速いチップを買う前に、量子化・KVキャッシュ管理・バッチングでまず帯域幅を節約するほうが費用対効果が大きいです。
  • 量子化はメモリを減らすと同時に速度を上げます。 FP8/INT8サービングを真剣に検討してください。これはメモリバウンドな世界でのみ成り立つ、やや反直観的な事実なので、一度きちんと理解しておけば一生使えます。
  • 文脈長はタダではありません。 長い文脈はKVキャッシュを通じてメモリと帯域幅を直接消費します。本当に必要な長さか考えてください。
  • 容量と帯域幅を区別してください。 「モデルが入るか」と「十分に速いか」は別の問いです。
  • データ局所性を意識してください。 同じデータを繰り返し使うようコードを構成すれば、高価なメモリ往復を減らせます。

メモリ最適化チェックリスト

推論コストが悩みのとき、チップを替える前に次を順に点検すると効果が大きいです。

  • このワークロードはメモリバウンドか演算バウンドか?(プロファイリングで確認)
  • 低精度(FP8/INT8)サービングを適用したか? 精度は検証したか?
  • KVキャッシュを圧縮するか精度を下げる余地があるか?
  • 本当に必要な文脈長だけを使っているか? 過剰な文脈はないか?
  • バッチングで重みの読み込みを複数のリクエストで共有させたか?
  • 同じデータを繰り返し読む非効率はないか?

このチェックリストの項目の大半は、より高価なハードウェアなしに、ソフトウェアだけで適用できます。メモリウォールを理解するということは、すなわちこれらの項目を本能的に点検するようになるということです。そしてこの点検を習慣化したチームは、同じ予算で競合より速く安いAIサービスを運用できるようになります。ハードウェアは誰でも同じものを買えますが、それをメモリウォールの観点から賢く使う能力は、簡単には複製されない本物の競争力です。

10. よくある質問

Q. ただメモリ容量の大きいチップを買えばメモリ問題は解決しますか? A. いいえ。容量と帯域幅は別の資源です。容量が大きくてモデルが入っても、帯域幅が不足すればトークン生成は遅くなります。メモリバウンドな推論では帯域幅が速度を直接決める場合が多いです。

Q. 量子化すると精度が落ちませんか? A. 精度を下げると損失のリスクはありますが、2026年の精緻な量子化技法はその損失を非常に小さく保ちます。多くの場合ユーザーが体感しにくいレベルであり、その代償として得られる速度・コストの利得のほうがはるかに大きいです。ただし自分のタスクで品質を検証することは必須です。

Q. メモリバウンドか演算バウンドかをどう見分けますか? A. プロファイリングツールでメモリ帯域幅の使用率と演算器の使用率を見ればわかります。帯域幅がほぼ飽和なのに演算器が遊んでいればメモリバウンドです。一般にLLMのトークン生成段階はメモリバウンド、長いプロンプトのprefill段階は演算バウンドに近いです。

Q. 文脈を長く使うのがなぜ高いのですか? A. 長い文脈はKVキャッシュを大きくし、そのキャッシュは容量と帯域幅を同時に消費します。さらに毎トークン生成のたびに大きくなったキャッシュを再び読まなければならないため、生成が長くなるほどトークンあたりのコストが増えます。本当に必要な文脈長かを考えることがコスト削減の出発点です。

Q. ウェハースケールチップがメモリウォールの正解ですか? A. 一つの興味深いアプローチですが唯一の答えではありません。巨大なオンチップSRAMでHBMの往復をなくすのは強力ですが、すべてのワークロード・予算に合うわけではありません。HBM世代の更新、量子化、インメモリ・フォトニック研究など複数の方向が同じ問題に向かって同時に進んでいます。

Q. では結局、何から始めればよいですか? A. 順序があります。第一に、プロファイリングで自分のワークロードがメモリバウンドかを確認します。第二に、メモリバウンドなら低精度サービングとKVキャッシュ最適化で読むバイトを減らします。第三に、バッチングで重み読み込みを共有します。この3つをすべてやってもまだ足りないとき、初めてより高い帯域幅のチップを検討します。ハードウェアの交換はたいてい最後の切り札です。

Q. この内容は学習にも当てはまりますか? A. 部分的にはそうです。学習は大きなバッチで算術強度が高く、推論より演算バウンドな場合が多いです。しかし学習でも活性値・勾配のメモリ移動、チップ間通信は依然として大きなコストであり、「データ移動を減らせ」という原理は学習と推論の両方に通じます。ただし推論ではその効果がより直接的で劇的です。

おわりに

AI性能を分ける本当のボトルネックは、よく思われる演算能力ではなくメモリです。演算が安くなりデータ移動が高くなった時代に、良いハードウェアと良いコードはどちらもデータ移動を減らす方向へ進化します。HBM4のような新しいメモリ、量子化のようなソフトウェア技法、オンチップSRAM活用のようなカーネル設計、そしてインメモリ・フォトニックのような未来の研究が、すべてこの一つの問題に向かいます。

開発者として私たちがすべきことは、華やかなTFLOPSの数字に惑わされず、「このワークロードの本当のボトルネックは演算かメモリか」を問うことです。その問い一つが推論コストを半分に減らすこともあります。メモリウォールを理解することは、2026年のAIシステムを扱うすべての開発者の基本です。

記憶すべき一文で記事を締めくくります。演算は安く、データ移動は高い。 この一行を心に刻めば、新しいチップが出ようと新しいモデルが出ようと、その下で働く原理を見抜くことができます。チップの名前は毎年変わりますが、この原理は変わりません。そしてこの原理を知る開発者は、同じ予算でより速くより安いAIシステムを作ることができます。

参考資料

Discuss on Twitter • View on GitHub