SK Hynix、GoogleとともにHBFをオープン化し、AIメモリ競合への圧力を強める
SK HynixはSandiskとともに初のオープンHBF仕様を公開し、512GBのメモリスタックと3 TB/sという目標値をGoogleニュースの報道に載せた。この発表により、AIチップ設計企業には、高価な高帯域幅メモリと低速なソリッドステートストレージの間を埋める具体的な選択肢が提示された。
この仕様は、アクセラレータを最高速度で動かすうえで不可欠なHBMを置き換えるものではない。むしろ、High Bandwidth Flash（HBF）は、プロセッサの近傍にNANDベースの大容量階層を追加する。これにより、モデル重みや推論データを演算資源の近くに保持し、従来のSSDからの繰り返し転送を削減できる可能性がある。
争点は現在、技術提案から採用を巡る競争へ移っている。各社によると、GoogleとAIチップ設計企業Tenstorrentは標準化活動に参加した。一方で、Nvidia、AMD、Samsung、Micronなどの主要半導体サプライヤーは、HBFへのコミットメントを公表していない。
HBF仕様がメモリ提案をオープンな競争へ変える
SK HynixとSandiskは、共有された構想にとどまっていたHBFを、他社が評価・実装できる仕様へと移行させた。
両社は2026年8月4日、カリフォルニア州で開かれたFuture of Memory and Storage conferenceに合わせて、初のHBF標準仕様を発表した。この取り組みは、クラウド事業者やハードウェアサプライヤーとともにオープンなインフラ設計を開発する組織、Open Compute Projectを通じて公開された。
この選択は重要だ。HBFには、2社のメモリベンダーを超えた参加が必要だからである。プロプライエタリなインターフェースでは、プロセッサ企業に1社のサプライヤーへの依存を受け入れるよう求めることになる。オープン仕様は、チップ設計企業、パッケージング企業、ソフトウェア開発者、競合するメモリメーカーに共通の技術的出発点を与える。
初期設計は、8ダイおよび16ダイのNAND構成に対応する。上位構成では、1パッケージあたり512GBの容量を提供できる。発表後に報じられた技術詳細によると、性能クラスは約400 GB/sから3 TB/sに及ぶ。
これらの数値は、HBFをこれまでにない領域へ位置付ける。一般的なエンタープライズSSDは非常に大きな容量を提供できるが、ブロックストレージ向けに設計されたインターフェースで接続される。HBMはアクセラレータの隣に配置され、はるかに高い帯域幅を実現するが、容量は小さく、パッケージングも依然として高価だ。
HBFはその中間を占めようとしている。SK Hynixはこれを、HBMとSSDの間に位置する、推論ワークロード向けに特化した新しいメモリ階層と説明する。NANDが高密度と不揮発性を提供し、積層パッケージングと並列アクセス経路が帯域幅を高める。
両社は、これらの仕様を公開する前から正式な標準化活動を始めていた。2月には、SandiskのMilpitas本社で開かれたコンソーシアム会議を受け、OCPの下に専用ワークストリームを設置した。標準化計画では、HBFを拡張可能でエネルギー効率を意識したAI推論向けインフラとして位置付けた。
したがって、8月の公開は突然の発明ではなく、進展を意味する。先行する枠組みを、容量、帯域幅、インターフェース、電気特性、パッケージング、信頼性、ソフトウェア要件へと具体化したものだ。
報道によると、この仕様ではUCIe（Universal Chiplet Interconnect Express）を使い、HBFパッケージをホストプロセッサに接続する。UCIeは、1つのパッケージに組み込まれたチップレット間の共通ダイ・ツー・ダイ接続を定義する。
このインターフェースは、オープン戦略の中核にある。共通リンクにより、すべての組み合わせに完全に独自の接続を必要とせず、異なるプロセッサが互換性のあるHBFデバイスと通信できるようになる可能性がある。
ただし、オープンな文書はオープンな市場と同義ではない。サプライヤーには、製造可能なダイ、ベースロジック、パッケージング能力、コントローラ対応、ファームウェア、OS統合、そして完全なシステムを検証する意思を持つ顧客が依然として必要だ。
SK HynixとSandiskはスタートラインを作った。しかし、勝者を決めたわけではない。
AI推論にHBMとSSDの間の階層が必要な理由
HBFが最も力を発揮するのは、有用なデータがアクセラレータのHBM容量に収まりきらなくなった推論ワークロードである。
トレーニングと推論では、メモリへの負荷のかかり方が異なる。トレーニングではモデルパラメータを繰り返し更新し、多数のアクセラレータにわたって高いスループットが求められる。推論では、すでに学習済みのモデルからリクエストに応答する。その際、モデル重み、アテンションデータ、拡大するキャッシュを管理することが多い。
重要なワークロードの一つが、一般にKV cacheと略されるキー・バリューキャッシュだ。これはモデルがプロンプトを処理する際に生成したアテンション情報を保存し、その後のトークン生成で以前の計算を再利用できるようにする。
より長いコンテキストや同時利用者数の増加は、このキャッシュを大きくする。検索システムでも、大規模なインデックスや埋め込みベクトルをアクセラレータの近くに置く場合がある。大規模なレコメンデーションモデルも、演算資源近傍の大容量から恩恵を受ける別種のデータを加える。
HBMはこれらのプロセッサが求める帯域幅を提供するが、容量を無制限に拡張することはできない。スタックを1つ追加するごとに、パッケージ面積、電力、信号配線、歩留まり、コストに影響する。あふれたデータをSSDに移すと、レイテンシが増し、ストレージ向けのアクセス経路を通ることになる。
HBFは妥協案を提示する。最速クラスは現行HBM製品に関連する帯域幅の領域に近づき、最大規定容量は一般的なHBMスタックを数倍上回る。
仕様のある分析によれば、512GBのHBFスタックは、HBM4スタックのおよそ48GBから64GBと比較される。この比較は、両技術が置き換え可能であることを意味しない。NANDとDRAMでは、レイテンシ、耐久性、書き込み挙動、性能特性が異なる。
それでも容量はシステム設計を変える。より多くのモデルデータをアクセラレータパッケージ内に保持できるサーバーは、外部ストレージやホストメモリを経由するトラフィックを減らせる。データ移動を減らすことで、応答の一貫性を改善し、データ転送に費やすエネルギーを抑えられる可能性がある。
この違いが、発表が通常のGoogleニュース集約を超えて注目を集めた理由を説明する。この提案は、プロセッサの演算能力だけでなく、メモリ配置によってますます左右されるボトルネックを狙っている。
Sandiskは2025年からこの主張を展開している。同社のHBF technical briefでは、第1世代の構想として、1.6 TB/sの読み取り帯域幅、16ダイで512GB、HBM4に匹敵する物理プロファイルを示していた。
これらの数値はベンダー目標であり、独立した性能結果ではない。新仕様は上限を3 TB/sへ引き上げたが、購入者には現実的なワークロードにおけるシリコン測定値が依然として必要となる。
最ももっともらしい初期用途は、汎用コンピューティングではない。HBFは、モデルまたは関連する推論データが利用可能なHBMを超える一方、SSDが提供するよりも大幅に高速なアクセスを必要とするシステムに適している。
1つのアクセラレータプラットフォームで複数の大規模モデルを動かすサービスを考えてみよう。従来のストレージはすべてのモデルを保持でき、HBMはアクティブな計算を処理できる。HBFはより大きなワーキングセットをプロセッサ近傍に保持し、モデル切り替えの頻度と所要時間を減らせる可能性がある。
もう一つの例は、多数の同時ユーザーに長いコンテキストのアプリケーションを提供する場合だ。そのKV cacheは、HBM容量を巡ってモデル重みと競合する可能性がある。選択したデータをHBFに配置すれば、最もレイテンシに敏感な処理のために貴重なHBMを確保できる。
ベクトル検索は3つ目の可能性を提供する。研究者は、大規模なインデックスに相当な帯域幅が必要な大規模近似最近傍探索向けに、HBF支援型アクセラレータを検討してきた。この種の取り組みは依然として実験段階だが、HBFの容量が対応できるワークロードを示している。
これらのシナリオが機能するかどうかは、ソフトウェアが決める。開発者には、何をHBMに残し、何をHBFに移し、何をSSDへフォールバックさせるかを判断するための予測可能なルールが必要だ。不適切な配置は、不要な転送によって利点を失わせかねない。
このため、HBFは階層の一部として理解すべきである。HBMは最速の作業階層であり、HBFはより大きな演算近傍プールを提供する。SSDはパッケージ外で経済的な永続容量を提供する。
仕組みは単純に聞こえるが、協調したメモリ管理は難しい。ハードウェアは各階層を明確に公開する必要があり、コンパイラとランタイムシステムはそのレイテンシ、帯域幅、耐久性、容量を理解しなければならない。
インフラ購入者にとって実務的な問いは、512GBが印象的に見えるかどうかではない。すべてのシステムコストを考慮した後に、HBFが毎秒トークン数を増やし、より多くの同時リクエストを支え、またはトークン当たりのエネルギーを下げるかどうかである。
Googleニュースでの関心がAIメモリ業界への圧力を高める
Googleの参加はHBFに影響力のある評価者を与えるが、幅広いサプライヤーの支持は依然として標準にとって最も重要な欠落要素である。
SK HynixとSandiskがHBFを支持するのは自然なことだ。両社はメモリ製造、パッケージング、データセンターストレージを理解している。商業的な利害も明確である。推論の成長は、より価値の高いNANDベース製品を販売する機会を生み出す。
Googleは異なる視点をもたらす。同社はtensor processing unitsを設計し、巨大なAIサービスを運営し、ごく少数の組織しか匹敵できない規模でインフラを管理している。その関与は、少なくとも1社のハイパースケーラーが、仕様策定を支援するだけの価値を見出していることを示す。
それは、GoogleがHBFの導入を約束したことを意味しない。参加には、商業発注を保証せずとも、技術評価、ワークロードに関する指針、インターフェース開発が含まれ得る。
Tenstorrentも有用な視点を加える。同社はチップレットとオープンアーキテクチャの考え方を軸にAIプロセッサを開発しており、オープンな演算近傍メモリ階層はその設計戦略に関連する。また、市場支配力はNvidiaよりはるかに小さい。
GoogleとTenstorrentは、コンソーシアムに潜在的な購入者とプロセッサ設計者の両方の視点を与える。それでも、目に見える参加者が2社だけでは、完全な供給エコシステムにはならない。
欠けている名前は重要だ。Nvidiaはアクセラレータ市場の大部分を支配している。AMDは競合するGPUとCPUを販売する。BroadcomとMarvellはクラウド顧客向けのカスタムシリコンを構築する。SamsungとMicronはメモリで競合し、IntelとQualcommはプロセッサ、アクセラレータ、プラットフォームにまたがる。
最初の仕様が登場した時点で、これらの企業はいずれもHBFの取り組みを公に支持していなかった。その不在は反対を証明するものではない。企業は、製品スケジュール、顧客要件、技術的トレードオフがより明確になるまで、初期段階の標準を支持することを避ける場合が多い。
しかし、沈黙は開発者にリスクを生む。HBFをサポートするプロセッサが少数にとどまれば、ソフトウェア投資を正当化しにくくなる。HBFを製造するメモリサプライヤーが2社だけなら、購入者は供給の多様性に懸念を持ち続ける可能性がある。
オープン標準は、参加者が互換性によってプロプライエタリな支配よりも大きな市場が生まれると信じるときに成功する。主要ベンダーが社内インターフェースや既存の製品ロードマップによってより良い経済性を実現できる場合、標準は苦戦する。
たとえばNvidiaは、アクセラレータ、インターコネクト、システム、ソフトウェアを連携させられる。同社は、HBFを採用せずとも、より大容量のHBM、改善されたメモリプーリング、または緊密に統合されたストレージによって顧客のニーズに応えられると判断するかもしれない。
メモリベンダーも別の計算に直面する。SamsungとMicronはすでにHBMに大きく投資している。HBFを支援すれば高性能NANDの対象市場は拡大するが、同時に別の複雑な製品とパッケージング要件を導入することにもなり得る。
SK Hynixは、すでに主要なHBMサプライヤーであるため、やや特異な立場にある。HBFを推進しても、必ずしも既存事業を損なうわけではない。階層型システムでは両製品を併用できるため、同社は価値の高い2つのメモリ階層に関与できる。
Sandiskの関心は、より直接的にNANDと結び付いている。同社はフラッシュをプロセッサに近づけ、AIインフラへの支出でより大きな割合を獲得したい考えだ。以前のHBFロードマップでは、2026年後半にメモリサンプル、2027年初頭にHBF搭載推論デバイスのサンプルを目標としていた。
このスケジュールは、コンソーシアムに対し、文書作成を迅速にハードウェアへ移行させる圧力となる。遅延するたびに、競合各社にはHBM容量、CXLベースのメモリ拡張、SSDオフロード、ソフトウェアキャッシュを改善する時間が与えられる。
CXL（Compute Express Link）は、プロセッサとメモリ拡張デバイスをコヒーレントに接続する仕組みを提供する。スタック型HBFパッケージをプロセッサの隣に配置する場合とはトポロジーや性能が異なるものの、関連する容量問題に対応する。
DirectStorage型のデータパス、コンピュテーショナルストレージ、高度なNVMeデバイスも、同じワークロードの一部をめぐって競合する。これらの手法では大規模データセットをアクセラレータからより離れた場所に置く一方、転送効率を改善できる。
したがって主な競争は、SK Hynixと単独の競合企業との対決ではない。オープンなHBFと、HBM、ホストメモリ、CXL、SSDから構成される既存のメモリ階層との競争である。
Googleニュースでの露出は、この競争への注目を集める助けになる。見出しよりも、エンジニアリング上の取り組みのほうがはるかに重要だ。
3 TB/sという目標は、実際のハードウェアでなお検証される必要がある
HBFの容量はNANDの利点として説得力があるが、帯域幅、レイテンシ、耐久性、電力、ソフトウェアに関する主張は、量産規模ではまだ実証されていない。
この仕様は、互換製品がどのように動作すべきかを定義するものである。SK HynixやSandiskが、それらの製品を経済的に量産し、一貫した性能を実現できることを示すものではない。
16ダイのスタックは、パッケージングの複雑さを増す。各ダイには大規模な並列アクセスが必要であり、同時にパッケージにはホストプロセッサとのトラフィックを調整できるベースダイが求められる。システムの電力枠を超えずに熱を逃がさなければならない。
3 TB/sを達成するには、高速なインターフェースだけでは足りない。NANDダイが十分な内部並列性を提供し、コントローラがリクエストを効率よくスケジューリングし、ソフトウェアが高い読み出しスループットに適したワークロードを維持する必要がある。
NANDには重要な強みがある。電源なしでデータを保持でき、DRAMよりはるかに高密度である。一方で、DRAMと比べてアクセスレイテンシは長く、書き込み耐久性も限られる。
これらの違いは、どのデータをHBFに置くべきかに影響する。読み出し中心のモデル重みは、頻繁に更新される作業データより適しているように見える。推論中にシステムがキャッシュエントリを継続的に作成・更新するため、KVキャッシュの挙動についてはさらに詳しい検討が必要だ。
性能はアクセスパターンによって変動し得る。ベンダーは印象的なシーケンシャル帯域幅を達成できても、小規模で不規則な読み出しでは弱い結果にとどまる可能性がある。AIワークロードには、予測可能なストリームと散在するルックアップの両方が含まれ得る。
したがって、最初の独立テストでは最大スループット以上の内容を報告すべきである。購入者には、レイテンシ分布、ランダムリード時の挙動、書き込み性能、サーマルスロットリング、エラー率、耐久性、転送バイト当たりのエネルギーが必要だ。
システムレベルの測定も必要である。毎秒トークン数、最初のトークンまでの時間、同時ユーザー容量、トークン当たりのエネルギーは、メモリの挙動を事業上の成果に結び付ける。
ある技術仕様の分析は、この設計に電気仕様、インターフェース、パッケージング、信頼性、ソフトウェアI/Oの要件が含まれると指摘した。また、単一の512GBパッケージから400 GB/sすら引き出すことの難しさも強調している。
この低い数値は重要である。標準には複数の性能クラスがあるため、3 TB/sという上限を、将来のすべてのHBFデバイスの略称として扱うべきではない。
容量構成についても慎重な扱いが必要だ。512GBパッケージは仕様の上限を示すものであり、初期サンプルのすべてが最大帯域幅でその容量を提供するという約束ではない。
商用化のスケジュールも依然として不確実である。Sandiskは以前、2026年中のHBFメモリサンプルと、2027年初頭のHBF利用デバイスを目標としていた。仕様発表では、このタイムラインが公に更新されたわけではない。
慎重な商用化評価では、サプライヤーがサンプルを準備する段階にある現状のソリューションは、まだ文書上の存在だと説明されている。この区別を踏まえて期待を調整すべきである。
サンプリングは初期段階のマイルストーンにすぎない。顧客は機能をテストし、コントローラとランタイムを統合し、パッケージングを認定し、信頼性を検証したうえで、性能が新たなシステム設計を正当化するか判断しなければならない。
最終的な決定要因は量産経済性になる可能性がある。HBFはNANDを使用するが、標準的なコモディティフラッシュパッケージではない。専用ダイ、ロジック、高密度接続、高度な組み立て工程がコストを上乗せする。
完成品の価格がHBMに近づきながらHBMと同等の挙動を実現できなければ、容量上の利点だけでは不十分かもしれない。魅力的なシステムコストで数倍の容量を提供できれば、アクセラレータ設計者は有意義な新たな選択肢を得る。
電力も同様のトレードオフを生む。データをコンピュートの近くに置くことで、SSDから移動するためのエネルギーを削減できる可能性がある。一方、広帯域インターフェース、並列NANDアクセス、複雑なコントローラ自体も電力を消費する。
コンソーシアムは、実際の推論トラフィック下での正味の省電力を実証しなければならない。ベンダーの推定だけでは、この計算に決着はつかない。
ソフトウェアの成熟度は、目立ちにくいリスクである。プロセッサは技術的にはHBFに接続できても、アプリケーションがそれを効果的に活用できない可能性がある。メモリ割り当て、キャッシュ、退避、データ移動、可観測性のすべてに、新しいサポートが必要だ。
クラウド事業者は複雑なストレージ階層を管理した経験を持つが、パッケージレベルの異種メモリは最適化の問題を変える。開発者には、各アプリケーションチームが個別のメモリ領域を手動で管理せずとも、その利点を引き出せるツールが必要になる。
オープンソースのランタイムは、この負担を軽減できる可能性がある。共有ツールは、カスタムソフトウェアを構築できるハイパースケーラー以外にも、この標準の採用を広げる助けとなる。
こうした要素がそろうまで、HBFは製品ストーリーが未完成の、もっともらしいアーキテクチャにとどまる。この違いは、発表に関するGoogleニュースを追う投資家、購入者、開発者にとって重要だ。
オープンHBF発表後に注目すべきこと
HBFがAIメモリ階層となるのか、それとも広範な市場を持たない魅力的な仕様にとどまるのかは、3つのシグナルで決まる。
第1のシグナルは、動作するシリコンである。SK HynixとSandiskは、容量、帯域幅、レイテンシ、電力、耐久性、熱特性を開示したHBFサンプルを提供する必要がある。
現実的なワークロードにわたり、公表された目標に近い性能を示すサンプルなら、HBFの有力な根拠となる。好条件のシーケンシャルリードに限ったデモでは、中心的な性能上の疑問は解消されない。
タイミングも重要だ。Sandiskが以前に示したロードマップでは、初期サンプルは2026年後半とされていた。この期間を守れれば、標準化と製品エンジニアリングが並行して前進したことを示す。
第2のシグナルは、プロセッサ側の採用である。GoogleとTenstorrentはこの取り組みの形成に関与したが、観測者はHBFを使うアクセラレータのロードマップ、プロトタイプボード、または公表された推論テストに注目すべきだ。
Googleによる導入は特に重みを持つ。同社はAIモデルとカスタムプロセッサの両方を管理しているためである。限定的なテストであっても、メモリベンダーのラボでは得られない信頼できるワークロードデータを提供できる可能性がある。
Tenstorrentは異なる実証例を示せるかもしれない。同社のチップレット指向アーキテクチャは、閉じたサプライヤースタックに依存せず、独立系プロセッサ企業がUCIe経由でHBFを統合する方法を示し得る。
最も強力な検証は、別の主要プロセッサ企業またはクラウド企業が仕様に加わることだろう。AMD、Broadcom、Marvell、Microsoft、Meta、Amazonによる支援があれば、HBFが小規模なグループに結び付くリスクは低下する。
第3のシグナルは、ソフトウェアと経済性である。購入者には、HBFを手動制御のストレージデバイスではなく、管理可能な階層の一部として扱うランタイムサポートが必要だ。
コンパイラ機能、メモリ配置ポリシー、オペレーティングシステムの変更、推論フレームワークとの統合、監視ツールに注目したい。こうしたリリースは、エコシステムが単なる仕様レビューではなく、導入に向けた準備を進めているかを示す。
経済面の証拠も続く必要がある。関連する指標には、サーバー当たりの毎秒トークン数、同時セッション数、トークン当たりのエネルギー、定義されたサービスレベルでモデルをホスティングするコストが含まれる。
生の帯域幅だけでは、これらの問いには答えられない。容量だけでも同様だ。
比較には、より大容量のHBM構成、ホストメモリ、CXL拡張、最適化されたSSDオフロードを使用する既存システムを含めるべきである。HBFが地位を得るのは、性能と容量の組み合わせが推論プラットフォーム全体を改善する場合に限られる。
開発者にとって、この発表はメモリ使用量をより詳しく検討する理由となる。モデル最適化は、重み、キャッシュ、検索インデックス、中間データをどこに置くかに、ますます依存している。
将来のAIインフラを評価するチームは、今からこうしたワークロード特性を記録しておくべきだ。検索可能な技術ナレッジベースは、HBF製品が登場する中で、エンジニアが仕様、ベンチマークの記録、アーキテクチャ上の意思決定、ベンダーの主張を比較する助けとなる。
エンタープライズ購入者にとって、直近の対応はより控えめでよい。サプライヤーに対し、推論メモリ容量にどう対処する予定か、どのオープンインターフェースをサポートするか、ロードマップを裏付けるワークロードの証拠は何かを尋ねるべきである。
HBFというラベルを性能の証明と見なしてはならない。自社のモデルサイズ、コンテキスト長、同時実行目標、サービスレベル要件を反映した測定値を求めるべきだ。
SK HynixとSandiskの仕様は、この議論を具体的なものにした。HBFには今や、定義済みの容量クラス、性能目標、オープン標準の場、そして注目すべき2つの外部参加者がある。
しかし、量産デバイス、独立したベンチマーク、幅広いプロセッサのサポートは依然として欠けている。こうした隔たりが、興味深い標準と持続的な市場を分ける。
次のGoogleニュースの見出しは、最初の完全なHBFベンチマークほど重要ではない。実働システムが応答時間を犠牲にせず推論コストを下げられるかを注視し、その証拠を急速に改善するHBMやメモリ拡張の代替手段と比較すべきである。
