AIコンピューティングにおけるHBF：HBFはHBMのより安価な版ではない：低帯域幅・容量重視ワークロードには機会がある一方、高密度・高バッチ推論はコストの罠になり得る

概要

このHot Chips 2026チュートリアルは、システムアーキテクチャの観点からAI推論におけるHBFの適用境界を検討する。中心的な結論は、HBFの価値は高帯域幅ではなく大容量に由来するという点である。HBFは小バッチMoE、スパースな長コンテキストKV、ローカルエキスパートストレージを改善できるが、高密度モデル、大規模バッチ、またはラックスループットを重視する導入では、HBMの方が依然として経済的な選択肢である。

主要見解

本レポートはまず、βとαで記述されるメモリ技術の全体像の中にHBFを位置付ける。βはGB当たりコスト、αは容量単位当たりで利用可能な帯域幅を表す。HBFは低β・低αの容量重視の位置を占め、同一コストでHBMの約8—16倍の容量を提供できるが、HBMのより安価な版とみなすべきではない。本レポートはメモリコストを判定するために「$mem = β·max(C, I·b/α)」という式を用いる。ここでCは収容すべきデータ量、I·bは帯域幅要件である。経済性を真に左右するのは、安価なGBをどれだけ購入するかではなく、容量制約とデータ供給帯域幅制約のうち大きい方である。従って、低い$/GBが自動的に低い$/tokenを意味するわけではない。 ワークロード特性が、HBFが有効範囲に入るかどうかを決定する。MoEモデルは膨大なエキスパート重みをすべて保存できる一方、各トークンが活性化するエキスパートは少数に限られる。そのため、小さいバッチサイズBと低いアクセス強度Iでは、モデルは帯域幅より主に容量によって制約され、低帯域幅でも十分な場合がある。高密度モデルはより広範な重み読み出しを必要とする。バッチサイズ、アクセス強度、またはI·bが上昇すると、HBFの不足する帯域幅により、システムはデータ供給要件を満たすためにより多くの容量をプロビジョニングせざるを得ず、クロスオーバー点を超えるとHBMの方が安価になる。したがって本レポートは、HBFの優位性を「小B・低I」のMoEサブリージョンに限定し、高密度および高BのワークロードはHBMに委ねる。 導入比較には、オールHBM、オールHBF、ハイブリッドの「2×HBF＋6×HBM」構成が含まれる。3構成はいずれも同一コストを達成できるが、提供する容量と帯域幅は異なる。短コンテキスト・低バッチのシミュレーションでは、HBFはコスト面で優位になり得るが、その容量の約85%はアイドル状態のままである。一方、HBMは容量の壁を超える性能に対してコストを課す可能性がある。長コンテキストの場合も、より大きな容量が必ずしも良いとは限らない。追加容量が経済的価値を持つのは、I·bが低いままの場合に限られる。ハイブリッド構成はHBMをホットエキスパートキャッシュとして使用しようとするが、混合クエリではエキスパート人気度が平坦化する傾向があるため、キャッシュが有効なのは低バッチサイズの場合、または類似クエリをグループ化して処理する場合に限られる。 本レポートはさらに、FP4のKimi-K2 1Tモデルを用い、デコード中心の72-GPUラックレベルのシミュレーションを実施する。主なコンテキストは入力トークン100万、出力トークン1,000であり、32k/8kおよび1k/8kシナリオを補足する。データ並列インスタンス当たりのバッチサイズは1—512である。容量要件を満たすためにテンソル並列を使用し、ラックを満たすためにデータ並列を用い、コストは設備投資と運用支出を3年間で償却した後の比率として表す。オールHBM構成はTP8·DP9、オールHBF構成はTP1·DP72、ハイブリッド構成はTP2·DP36である。オールHBM、オールHBF、ハイブリッド構成におけるデータ並列インスタンス当たり容量はそれぞれ2.3 TB、4.1 TB、2.5 TBであり、ラック総容量はそれぞれ20.7 TB、294.9 TB、89.3 TB、すなわち1倍、約14倍、4.3倍に相当する。 容量拡張には帯域幅のコストが伴う。ラック総帯域幅は、オールHBMで1,584 TB/s、オールHBFで922 TB/s、すなわち約0.6倍であり、ハイブリッド構成では1,418→279 TB/sとなる。対応するGPU当たり帯域幅は、それぞれ22.0 TB/s、12.8 TB/s、19.7→3.9 TB/sである。ラックコストと消費電力が比較可能な条件下で、本レポートはHBMが常により多くのトークンを処理できると結論付ける。HBFは、複数GPUを必要とするモデルを単一GPUに収められるため、単一マシンまたは単一インスタンスの容量に制約される導入により適している。言い換えれば、「ラックレベルのトークン当たりコスト」と「モデルが1台のマシンに収まるか」は、異なるメモリ選択につながる。 HBFのハードウェア特性も、その利用方法を制約する。本レポートに記載された3つのグレードは、それぞれ最大ユーザー帯域幅0.384、1.536、3.072 TB/sを提供し、インターコネクト速度は8、16、32 GT/sである。容量構成には8層256 GiBおよび16層512 GiBが含まれる。インターフェースは64 B—4 KiBの読み出し、4 KiBの書き込み、4 KiBページをサポートする一方、最大帯域幅を実現するには、64 KBにアラインされた64 KB読み出しと1 MB書き込みが必要である。HBFはDMAを通じて読み書きを実行し、GPUキャッシュ階層の一部ではない。HBMと併用する場合、独立したメモリ管理が必要となる。85°Cでの通電時データ保持時間は約24時間であり、ライフサイクルはホストが管理しなければならない。また、約10年の寿命を実現する、または耐久性の100%消耗を回避するには、書き込みを慎重に制御する必要がある。総じて、これは読み出し最適化、書き込み制約、ホスト管理型の媒体であり、データ配置は主としてソフトウェア上の問題となる。 ソフトウェアエコシステムについて、本レポートは本番導入における現在のデフォルトの焦点としてvLLMを扱う一方、SGLang、LMDeploy、Modular MAXなどの汎用推論エンジン、ならびにTensorRT-LLM、OpenVINO、AWS Neuron、Google JetStreamなどのベンダー最適化スタックも挙げている。既存のvLLMパスは主にCPUまたはLMCacheを対象としており、HBFを直接サポートしていない。HBFの使用には、新しいアロケータまたはバックエンド、ホット／コールドデータ配置ポリシー、非同期プリフェッチ、耐久性テレメトリが必要であり、これらがなければハードウェアの容量上の優位性を本番推論の利益に変換できない。 Kimi K3の例は、比較的明確なデータ配置スキームを示す。2.8Tモデルの総重みは1.56 TBであり、そのうちバイト数の93%、約1.45 TBはMoEエキスパート重みである。これらは書き込み一回・コールドリードの特性を持ち、本レポートはHBFエキスパートプールに適するとみなしている。残り7%、約110 GBの重みはHBMにより適している。100万トークンの各シーケンスのKV Cacheは約30 GBである。HBFは、ピン留めされたホストDRAMをより大容量のものに置き換えるKVオフロードプールおよびプレフィックスキャッシュとしても機能し得る。これにより階層型アーキテクチャが形成される。すなわち、HBFは膨大だが比較的コールドなエキスパート重みとオフロードKVを保存し、HBMはアクティブな重みと高帯域幅データを保存する。 スパースアテンションはHBFの適用可能性をさらに拡大する。長コンテキストまたはマルチターンKVでは、システムはコンテキスト全体を低コストで保持しつつ、top-k部分のみを読み出せる。本レポートは、読み出し比率φ＝top-k/contextを約1%—2%と示しており、これは閾値φ*=α/lを下回る。この条件下では、HBF容量が全KVを保持でき、より小さい読み出し量により帯域幅の壁に達することを回避できる。ただし、この優位性はDSA、CSA、Kimi-Linearなどのスパースアテンションモデルに明示的に依存しており、コンテキスト全体の高密度な読み出しを必要とするアーキテクチャには適用されない。 HBF容量はエキスパート並列通信も削減し得る。従来の例では、8 GPUにエキスパートをシャーディングし、各層でall-to-allを実行する。2つのノードが各々HBFにエキスパートをローカル保存できる場合、エキスパート並列のシャーディングを縮小でき、all-to-all通信を大幅に削減、または排除できる。従って容量は、モデルが収まるかという問題に対応するだけでなく、通信オーバーヘッドの一部を取り戻す可能性もある。ただし、その利益は依然としてエキスパートアクセスの局所性とプリフェッチ帯域幅に依存する。 最終的な結論は、HBFは汎用的な代替品ではなく精密なツールであるということだ。低帯域幅需要、小バッチ／低アクセス強度のMoE、および長コンテキストを持つスパースKVシナリオでのみコスト優位性を提供し、この範囲を外れると罠になり得る。その価値を拡大するには、読み出し帯域幅αの向上、HBMに対するGB当たりコスト差βの十分な維持、書き込み耐久性、書き込み帯域幅、レイテンシ、ソフトウェアサポートの問題解決も必要である。

分析フレームワーク

本レポートはまず、β、α、容量C、帯域幅要件I·bを用いてメモリコスト方程式を確立し、次にMoE対Dense、バッチサイズ、コンテキスト長、アクセスのスパース性によってワークロードを分類する。その後、オールHBM、オールHBF、ハイブリッド構成を比較し、Kimi-K2の72-GPUラックシミュレーションを用いて容量、帯域幅、3年償却コストを評価する。最後に、Kimi K3のデータレイアウト、vLLMソフトウェアパス、スパースアテンション、エキスパート並列通信を組み合わせ、HBFの導入条件と境界を判断する。

手法メモ

• (Out-of-Vocabulary Method)

  β—αメモリコスト方程式

  本レポートは、βをGB当たりコスト、αを容量単位当たり帯域幅として用い、$mem = β·max(C, I·b/α)によって容量およびデータ供給帯域幅のニーズを満たすために必要なメモリコストを比較し、GB当たり価格が低くても必ずしもトークン当たりコストが下がらない理由を説明する。

• (Out-of-Vocabulary Method)

  ラックレベル・トークン当たりコストシミュレーション

  同じ72-GPUラック、コスト、消費電力の仮定の下で、本レポートはテンソル並列およびデータ並列構成を調整し、オールHBM、オールHBF、ハイブリッドメモリの容量と帯域幅を比較する。また、3年間で償却した設備投資および運用支出に基づいて推論の経済性を評価する。

• Industry/Sector Analysis FrameworkSubstitution Effect Analysis

  HBF代替のワークロードベース境界

  本レポートはHBFをHBMの包括的な代替品として扱うのではなく、MoE対Dense、バッチサイズ、コンテキストのスパース性、導入規模に基づき、HBMまたはホストDRAMを置き換えられる具体的なデータプールを判断する。

資産マッピングと比較

投資テーゼから固有資産への構造化マッピング（強み、弱み、同業、リスク）。

• HBF

  AI推論における高容量・低帯域幅のメモリ層として機能し、MoEエキスパートプール、オフロードKV、プレフィックスキャッシュを収容できる。

  強み

  同一コストで容量はHBMの約8—16倍に達し得る。書き込み一回・コールドリードのデータに適し、エキスパートシャーディングおよびall-to-all通信を削減できる。

  弱み

  帯域幅が低く、書き込みに制約があり、DMAおよび独立したメモリ管理を必要とする。本番ソフトウェアのサポートもなお不十分である。

  比較

  72-GPUシミュレーションでは、容量はオールHBMの約14倍である一方、総帯域幅は約0.6倍であり、ラックレベルのトークンスループットはHBMを下回る。

  リスク

  バッチサイズまたはアクセス強度が上昇する場合、あるいはアテンション読み出しがスパースでない場合、帯域幅の壁によって低コスト容量ソリューションからコストの罠へと変わる。

• HBM

  高帯域幅のアクティブな重み、および高密度または高バッチ推論に使用され、本レポートにおけるベンチマークのメモリソリューションとなる。

  強み

  より高いラックレベルの帯域幅とトークンスループットを提供し、Dense、高B、頻繁にアクセスされるデータに適する。

  弱み

  GB当たりコストは高く、容量が制約される場合、モデルを収容するには追加のテンソル並列またはGPUが必要となる。

  比較

  オールHBMラックの容量は20.7 TB、総帯域幅は1,584 TB/sである。オールHBFラックはそれぞれ294.9 TB、922 TB/sである。

  リスク

  主に単一マシン容量に制約される低帯域幅ワークロードでは、ユーザーは実際の要件を超える帯域幅に対して費用を支払う可能性がある。

主要データ

• HBFの相対的容量ポジショニング同一コストでHBM容量の約8—16倍HBFはより低い帯域幅と引き換えに容量上の優位性を得るものであり、HBMのより安価な版ではない。
• 3つのHBFグレードの最大ユーザー帯域幅0.384 / 1.536 / 3.072 TB/sグレード1、グレード2、グレード3に対応する。
• HBFインターコネクト速度8 / 16 / 32 GT/s3つのハードウェアグレードに対応する。
• HBF容量構成8層256 GiB、16層512 GiB高容量のポジショニングを反映する。
• 72-GPUラック容量HBM 20.7 TB、HBF 294.9 TB、ハイブリッド89.3 TBそれぞれ1×、約14×、4.3×に相当する。
• データ並列インスタンス当たり容量HBM 2.3 TB、HBF 4.1 TB、ハイブリッド2.5 TBシミュレーション構成はそれぞれTP8·DP9、TP1·DP72、TP2·DP36である。
• ラック総帯域幅HBM 1,584 TB/s、HBF 922 TB/s、ハイブリッド1,418→279 TB/sオールHBFはオールHBMの約0.6×である。
• GPU当たり帯域幅HBM 22.0 TB/s、HBF 12.8 TB/s、ハイブリッド19.7→3.9 TB/s高容量構成に伴う帯域幅コストを反映する。
• ラックシミュレーションモデルKimi-K2 1T @ FP4主なコンテキストは入力トークン100万／出力トークン1,000で、DP当たりのバッチサイズは1—512である。
• コスト基準3年償却設備投資および運用支出を含み、比率として提示される。
• 低バッチ時のHBF容量利用率約85%のアイドル容量HBFは低Bでコスト優位性を持つものの、大量の容量が未使用のままとなる。
• Kimi K3総重み1.56 TBモデルサイズは2.8Tである。
• MoEエキスパート重み1.45 TB、バイト数の93%を占める書き込み一回・コールドリードの特性を持ち、本レポートはHBFに適するとみなしている。
• 残りの重み110 GB、7%を占める本レポートはこれらがHBMにより適しているとみなしている。
• 長シーケンス当たりKV Cache30 GB／100万トークンシーケンスHBFはKVオフロードプールおよびプレフィックスキャッシュに使用できる。
• スパースアテンションの読み出し比率φ 約1%—2%本レポートは、これが閾値φ*=α/lを下回るため、top-kのみを読み出しながら完全なKVをHBFに保存できると述べている。
• 通電時データ保持85°Cで約24時間ホストがデータライフサイクルを管理する必要がある。
• 目標耐用年数約10年書き込みは慎重に管理しなければならず、さもなければ耐久性の100%が消耗する可能性がある。

影響と示唆

本レポートは、AIメモリ構成はGB当たり価格だけを比較するのではなく、ワークロードと導入規模を合わせて決定すべきだと論じる。HBFは、より少ないGPU、単一マシン、またはローカルノードに非常に大きなモデルやKVプールを収容でき、エキスパート並列通信を削減する可能性もある。しかし、高いラックスループットを追求する場合、高密度モデルを使用する場合、またはバッチサイズを増やす場合、その低帯域幅はトークン当たりコストを押し上げる。実際の導入では、HBFが膨大なコールドデータを担い、HBMがアクティブかつ帯域幅に敏感なデータを保持する階層型アプローチがより有力である。

リスク

• バッチサイズ、アクセス強度、またはI·bが上昇すると、HBFは帯域幅の壁に達し、HBMがより低コストな選択肢となる可能性がある。
• 混合クエリではエキスパート人気度が平坦化する傾向があるため、ホットエキスパートキャッシュは機能しない可能性がある。
• HBFの書き込み耐久性、書き込み帯域幅、レイテンシには厳格なホスト側管理が必要であり、そうでなければ耐用年数と可用性に影響する可能性がある。
• 既存のvLLMパスは主にCPUまたはLMCacheを対象としており、HBFアロケータ、配置ポリシー、非同期プリフェッチ、耐久性テレメトリを欠いている。
• スパースKVシナリオにおける優位性はスパースアテンションモデルに依存しており、コンテキストを高密度に読み出す場合には適用されない。

注目点

• HBFの読み出し帯域幅αが向上できるか、またHBMに対するGB当たりコスト差βを維持できるかを注視する。
• 書き込み耐久性、書き込み帯域幅、レイテンシの問題に対処できるかを注視する。
• vLLMなどの推論エンジンが、HBFバックエンド、専用アロケータ、配置ポリシー、非同期プリフェッチ、耐久性テレメトリを追加するかを注視する。
• マルチエージェントアクセスの局所性、プリフェッチ帯域幅制限、メモリ構成とワークロードの適合を注視する。
• スパースアテンションモデルおよび類似クエリのバッチ化により、実際のアクセス比率をHBFの有効範囲内に維持できるかを注視する。