Hot Chips 2026：高帯域フラッシュはメモリの救世主ではない

Hot Chips 2026のチュートリアルセッションでは、High Bandwidth Flash（HBF）の約束と苦痛が示された。その売り文句は単純だ。機械学習ワークロードはDRAM容量に飢えており、フラッシュは1ギガバイトあたりのコストがはるかに安い。ならば、HBMのようにフラッシュをパッケージに載せ、広く高速なインターフェースを与えればいいではないか？

HBFはHBMではない。メモリですらない。たまたまコンピュートダイの隣にあるブロックデバイスだ。ソフトウェアはDMAを使ってHBFとDRAMの間でデータを移動させなければならず、大きな整列されたチャンクで行い、ホストはウェアレベリングやデータ保持といったSSDコントローラの役割を引き受ける必要がある。つまり、プラグアンドプレイではない。アドレス空間にマッピングしてバイトを読み始めることはできない。

講演では、vLLMのようなランタイムがどう適応するかが説明された。一つのアイデアは、Mixture-of-Experts（MoE）のエキスパートをHBFに格納し、アクティブなものをオンデマンドでHBMにDMAするというもの。もう一つは、KVキャッシュをHBFに置くが、それはステップごとにトークンの小さなサブセットを読むスパースアテンションを使っている場合に限る。問題は、それらの読み取りが散在している一方で、HBFはシーケンシャルアクセスを好むことだ。そのため、まずトップkの行をDRAMにDMAする必要がある。

ネットワーキングの側面もある。GPU間でシャード化された大規模モデルは、デバイス間のスキャッター/ギャザーに多くの時間を費やす。HBFを使えば、より多くの重みをローカルに複製でき、フラッシュ帯域をオフパッケージのトラフィックと交換できる。フラッシュからのDMAは無料ではないが、デバイス外に出るよりは安い。

コスト面では、HBFは帯域に制約されていない場合にのみ勝つ。小規模モデル、小バッチなら問題ない。HBFの帯域を飽和させた瞬間、HBMに対する帯域あたりのコストの不利が取引を台無しにする。ホットなエキスパートをHBMにキャッシュするのは役立つが、それはキャッシュヒット率が十分に高い場合に限る。

ソフトウェアの負担が本当の話だ。HBFを扱うのは、O_DIRECTやFILE_FLAG_NO_BUFFERINGを使うような感覚だ。1バイトの書き込みは、64KBブロックの読み取り、変更、書き戻しを意味する。これはブロックストレージの規律であり、メモリのセマンティクスではない。DRAM用に構築されたフレームワークは大幅な書き直しが必要になり、フレームワークを切り替えるたびにその作業をやり直すことになる。

正直なところ、HBFを活用するための労力は、SSDから重みをストリーミングするのと大差ない。ただし、OSカーネルはバッファリングとキャッシュでSSDのブロック整列を隠すことができる。HBFにはそのような保護はない。製品が存在するまで、容量の利点がエンジニアリングコストを正当化するかどうかは未解決の問題だ。