Hot Chips 2026: ハイバンド幅フラッシュ（HBF）の応用

機械学習ワークロードはDRAM容量に飽くなき食欲を持っています。フラッシュメモリはDRAMよりもギガバイトあたりの容量が安価です。それは解決策を提供できるでしょうか？ HBF、またはハイバンド幅フラッシュは、SSDで現在見られるのと同じフラッシュメモリ技術を使用しています。SSDとは異なり、HBFはHBM（ハイバンド幅メモリ）と非常によく似た方法で実装されています。HBFキューブは、コンピューティングチップと同じパッケージ上に、あるいはHBMの隣に配置されることもあります。HBFのアイデアは、HBMよりもはるかに高い容量を提供しつつ、妥当なメモリバンド幅も提供することです。Hot Chips 2026のチュートリアルデーで、Anurag AgarwalとRadhakrishna Giduthuriの講演では、HBFが機械学習ワークロードにどのように応用できるかが探求されました。HBF製品はまだ存在しないため、講演はシミュレーション、予測、そしてソフトウェアがHBFを活用するためにどのように適応できるかに焦点を当てています。 HBFは「キューブ」あたり非常に高い容量と、巨大なアクセス粒度を提供します。 HBFはHBMライクなフォームファクタを使用していますが、内部は全く異なります。IntelのOptaneのように、別のメモリプールとして機能するものではありません。代わりに、HBFはプロセッサに統合されたSSDにほぼ似ています。ソフトウェアはDMAを使用してHBFとDRAM間でデータを移動します。HBFアクセスは、システムメモリではなく、大容量ストレージデバイスのように、大きくアラインされたチャンクで行う必要があります。ホストソフトウェアは、ライトレベリングの管理やデータ保持の確保といったSSDコントローラー機能も引き受ける必要があります。つまり、HBFはプラグアンドプレイのソリューションにはなれません。 代わりに、HBFを活用するには、特別な戦略を策定し、それをランタイムに実装する必要があります。GiduthuriはvLLMを例に挙げています。vLLMは通常、モデルの重みをGPUメモリに保持しており、VRAM使用量を削減するオプションをすでに模索しています。例えば、vLLMはホストに十分な空きメモリがある場合、モデルの重みをピン留めされたCPUメモリに配置することを検討しています。HBFは細かいランダムアクセスをサポートしていないため、これはHBFでは機能しませんが、他のオプションは有望かもしれません。例えば、MoEエキスパートはHBFに格納できます。ソフトウェアは必要に応じてアクティブなエキスパートをHBMにDMA転送できます。 vLLMのKVキャッシュもHBFに配置できます。ただし、これは各ステップでKVキャッシュのサブセットのみを読み取るスパースアテンション実装でのみうまく機能する可能性があります。これにより、KVキャッシュの大部分をフラッシュに「コールド」状態のままにしておくことができ、HBFの容量を活用しつつ、HBFの低いバンド幅への圧力を軽減します。潜在的な注意点として、トップk読み取りは散らばっていますが、HBFはシーケンシャル読み取りを好みます。おそらくソフトウェアは、必要に応じてトップk行をDRAMにDMA転送することで、これを回避できるでしょう。 別の機会は、HBF容量を使用してクロスデバイス通信を削減することです。大規模モデルはしばしば複数のGPUにシャーディングされ、その結果、パフォーマンスはクロスデバイスの散布および収集操作によって制限されます。クロスデバイス通信は、コンピューティングスループットやメモリバンド幅よりもパフォーマンスの障壁となる可能性があります。HBFは、モデルの重みのより多くを異なるGPUにレプリケートすることで、これを緩和できます。フラッシュからDMAでデータを転送するのは安価ではありませんが、デバイス外に行くよりは安価です。 Agarwalは、コストの観点からHBFがいつ意味をなすかについて説明しました。基本的に、HBFはワークロードがバンド幅の制限に達しない場合に適しています。これは、より小さなモデルや/またはより小さなバッチサイズに適用されます。ワークロードがバンド幅に制約される場合、HBFのコスト方程式にとっては悪いです。なぜなら、容量あたりのコストとバンド幅あたりのコストの両方が最終的なコストに影響するからです。HBFは容量あたりのコストとしては優れていますが、HBMと比較するとバンド幅あたりのコストは劣ります。 彼はまた、HBMを使用してホットエキスパートをキャッシュすることについても議論しましたが、これも難しい解決策のように思えます。キャッシュはうまく機能する必要があります。さもないと、HBFのバンド幅がトークンあたりのコスト方程式に問題を引き起こす可能性があります。 最終的な言葉 HBFはDRAM容量の問題をある程度緩和するかもしれませんが、ソフトウェアの課題は計り知れないように感じられます。HBFの処理は、WindowsのFILE_FLAG_NO_BUFFERINGやLinuxのO_DIRECTのような、低レベルのディスクアクセスAPIを扱うのと非常によく似ています。ソフトウェアは、バイトレベルの粒度でストレージに自由にアクセスするのではなく、大きなアラインされたチャンクでアクセスを実行する必要があります。単一のバイトを変更するには、大きな64KBブロックをDRAMに読み込み、そのブロックを変更し、ブロック全体をフラッシュに書き戻す必要があります。これは、メモリを扱うというよりは、ブロックストレージデバイスを扱うのに似ています。通常のDRAMベースのシステムで動作するように設計されたソフトウェアフレームワークは、HBFを活用するために大幅な変更が必要になります。異なるフレームワークに移行することは、HBFを活用するために必要な作業をやり直すことを意味します。 HBFを活用するために必要な労力は、SSDからモデルの重みをストリーミングしてDRAM使用量を削減するために必要な労力と大差ないと言うまでもなく、SSDからモデルの重みをストリーミングする方が簡単に見えます。OSカーネルは、FILE_FLAG_NO_BUFFERINGやO_DIRECTを使用しない場合、ブロックアラインされたアクセスを行うことの難しさを抽象化できます。カーネル内のバッファリングにより、ソフトウェアは任意にシークし、バイトレベルの読み書き操作を実行できます。また、キャッシュとして機能し、フラッシュメモリの非効率性からソフトウェアを自然に絶縁します。講演では言及されていませんでしたが、SSDからモデルの重みをストリーミングする既存の試みがHBFに適用できるかどうか疑問に思います。あるいは、HBFを使用することに伴うソフトウェアの課題が厳しすぎて、その採用を妨げるかどうかです。HBF製品が市場に出るかどうか見てみましょう。現在のDRAM不足を緩和する何かを見たいですが、HBFがそれであるかどうかはわかりません。