SandiskとSK hynixによるHBF標準の主張には、なお証明が必要

SandiskとSK hynixは、注目を集める主張とともにGoogle Newsに登場した。両社は、High Bandwidth Flash向けとして初のOpen Compute Project仕様を公開したという。

この見出しは、業界標準に向けた決定的な一歩のように聞こえる。だが、両社が公開している発表文は、完成済みの仕様ではなく、OCPのワークストリームと標準化の開始を説明している。

この違いは重要だ。High Bandwidth Flash、すなわちHBFは、広く検証された商用製品ではなく、なお提案段階にあるメモリ分類だからである。HBFは積層NANDフラッシュをAIプロセッサの近くに配置し、高帯域幅メモリを上回る容量と、従来型ストレージを上回る帯域幅の両立を目指す。

中心となる競争は、単にSandiskと別のメモリメーカーの対決ではない。HBFが掲げる豊富な推論メモリという可能性と、既存のHBMシステムが持つレイテンシ、耐久性、ソフトウェア、製造面での優位性との競争である。

SandiskはNANDとウェハー接合に関する深い経験を持つ。SK hynixはHBMの設計、パッケージング、大量生産の専門性をもたらす。両社の協業はHBFの信頼性を高めるが、パートナーシップの発表だけで相互運用可能なハードウェアや承認済みの公開標準に代わることはできない。

この話は、通常の仕様更新よりも重大な意味を持つ。AIインフラが、高価なHBMと比較的遠いSSDストレージの間に、実用的なメモリ階層を追加できるかを試すものだからだ。

Google Newsが確認すること、確認しないこと

確認されているのは組織的な標準化の取り組みであり、完成したOCP仕様が公開されたという主張は、依然として公に検証しにくい。

2026年2月25日、SandiskとSK hynixは、カリフォルニア州ミルピタスにあるSandisk本社でHBF標準化のキックオフを開催した。両社は、Open Compute Projectの下に専用ワークストリームを設けると述べた。

両社が掲げる目標は、AI推論インフラ向けの業界標準としてHBFを開発することだ。このワークストリームは、技術要件を定義し、設立した2社を超える参加を促すための場となる。

これは意味のある進展だ。OCPのワークストリームは、製品仕様が固定される前に、システム構築企業、チップ設計企業、クラウド事業者、その他のメモリサプライヤーに提案を開くことができる。

しかし、このプロセスを始めることと、承認済みの技術仕様を公開することは異なる。SK hynixのHBF標準化に関する発表は、両社がワークストリームを立ち上げ、標準化作業を始めると述べている。

Sandiskの対応するOCP initiativeも、このイベントを始まりとして位置付けている。最終仕様のバージョン、承認日、公開文書番号、準拠プログラムはいずれも示していない。

こうした不足情報は、Google Newsを通じて広がる見出しをめぐる検証上の空白を生む。集約サービスへの掲載は、出版社がその主張を報じたことを確認するだけであり、OCPが技術レビューを完了したことを意味しない。

公開された仕様は通常、より明確な痕跡を残す。読者が期待すべきなのは、文書タイトル、バージョン番号、改訂履歴、ガバナンス上の状態、ダウンロード可能な技術内容である。

成熟した標準は、独立ベンダーが実装すべき内容も定義する。そこには、電気的インターフェース、コマンド動作、パッケージ寸法、熱制限、信頼性目標、相互運用ルールなどが含まれ得る。

これは、報じられた仕様が必ずしも架空だという意味ではない。初期の寄稿、ドラフト、あるいは新たに提出された文書が、容易に検索できないまま存在している可能性はある。

慎重な結論はより限定的だ。公開されている一次資料はワークストリームを確認できるが、完成済みのOCP仕様を独立して裏付けるものではない。

この空白は記事の解釈に反映されるべきだ。重要な変化は、主要なメモリ企業2社が、認知されたオープンインフラのプロセスにHBFを持ち込んだことである。

未解決なのは、そのプロセスがどこまで進んでいるかだ。OCPが識別可能な文書を公開するまでは、「初の仕様」という表現は、確定した節目ではなく報じられた主張として扱うべきである。

AI推論がもう1つのメモリ階層を必要とする理由

HBFは、高速だが容量に制約のあるHBMと、アクセラレータから遠すぎる大容量SSDの間に広がる領域を狙う。

AI推論では、応答を生成する間にモデル重みと一時的なアテンションデータが繰り返し読み出される。そのため大規模モデルでは、大容量とプロセッサへの持続的なデータ供給の両方が求められる。

HBMは、垂直積層DRAMをアクセラレータの近くに配置するため、この役割をうまく果たす。広いインターフェースにより、従来のサーバーメモリを超える速度でデータを移動できる。

その代償は、容量、製造の複雑さ、限られたパッケージ空間にある。HBMスタックを増やすほどシステムコストは上がり、プロセッサ周辺の貴重な面積を消費する。

エンタープライズSSDははるかに大きな容量を提供するが、ブロック指向のインターフェースとストレージ経路がレイテンシを加える。GPUの隣でHBMのように振る舞うことはできない。

HBFは中間層を提案する。HBMに関連するパッケージングの概念を用いてNANDフラッシュを積層し、その容量を広帯域・高帯域幅の経路で接続する。

Sandiskが公開したHBF fact sheetでは、第1世代の目標として毎秒1.6テラバイトが示されている。また、ダイ当たり256ギガビット、16ダイスタックで512ギガバイトとしている。

これらの数値は独立したベンチマーク結果ではなく、企業側の目標値である。それでも、インフラ設計者が関心を寄せる理由を説明している。

512ギガバイトのHBFスタックは、一般的なHBMパッケージよりも大幅に多くのデータを保持できる。複数のスタックを使えば、より大きなモデル構成要素をアクセラレータの近くに置き、SSDから繰り返し取得する必要を減らせる。

この設計は、多くの展開環境で書き込みよりも読み出しがはるかに多い推論にとり、特に関連性が高い。NANDの書き込み・消去サイクルには限界があるが、読み出し中心のモデル提供ワークロードなら、この弱点を軽減できる。

有望な用途には、モデル重み、検索インデックス、キー・バリューキャッシュの一部の保存が含まれる。キー・バリューキャッシュは、モデルがシーケンスを処理・生成する際に作られるアテンションデータを格納する。

こうした用途のいずれも、HBFをHBMと同等にするものではない。NANDはDRAMよりアクセスレイテンシが高いため、ソフトウェアはワークロードの挙動に応じてデータを配置しなければならない。

頻繁にアクセスされる情報はHBMに残る。より大きい、またはレイテンシへの感度が低いデータはHBFに移し、SSDはより低温のデータセットと永続ストレージを保持する。

この階層型の構成は、複雑さをなくすのではなく移し替える。アクセラレータ、コンパイラ、オペレーティングシステム、サービングフレームワークは、データをどこに置き、いつ移動させるべきかを理解する必要がある。

この仕組みは、直接的な置き換えというよりメモリ階層に近い。単一の技術ですべての要件を最適化できないため、プロセッサはすでにレジスタ、キャッシュ、システムメモリ、ストレージを使い分けている。

HBFはこの階層をアクセラレータのさらに近くまで拡張する。その価値は、重要な実行局面でNANDのレイテンシを露呈させずに、十分な有用データを近くに保持できるかにかかっている。

このタイミングは、AIインフラにおける優先事項の変化も反映している。アクセラレータ投資の第1波ではトレーニングが主導したが、推論はより大きな運用負荷になりつつある。

トレーニングでは、予定されたジョブに対して最大帯域幅が報われることが多い。推論では、繰り返されるリクエスト全体でレイテンシ、容量、利用率、消費電力の均衡を取る必要がある。

より長いコンテキストウィンドウは、この圧力を高める。選択したモデル構成要素だけを有効化する一方で、大量の重みを保存・取得する必要があるmixture-of-expertsモデルも同様だ。

Sandiskは2025年にHBFを公に発表し始めた。同社の2025年8月のcollaboration agreementでは、最初のメモリサンプルを2026年後半に提供する目標が示された。

同じ発表では、初期のHBF搭載推論デバイスのサンプルを2027年初頭に提供することも目標としていた。これらの日程は、顧客が動作するハードウェアを受け取り、検証するまでは目標にとどまる。

このスケジュールは標準化を急務にする。ベンダーは、未知のメモリ階層に対応するアクセラレータインターフェース、パッケージ、コントローラ、冷却システム、ソフトウェアに取り組む前に、安定した前提を必要とする。

HBFの真の競合相手は既存のHBMシステムだ

SandiskとSK hynixは、追加されるレイテンシ、ソフトウェアの複雑さ、もう1つのパッケージ技術というコストを、NAND容量の増加が相殺できることを証明しなければならない。

HBFはHBMの代替として語られることが多いが、その枠組みは競争上の位置付けを単純化しすぎている。初期のHBFシステムは、HBMを排除するより補完する可能性が高い。

HBMはアクセラレータ向けに、低レイテンシかつ高スループットの作業メモリを提供する。HBFは、同じコンピューティング資源の近くで、より大きな読み出し中心のデータセットを保持しようとする。

これにより、評価基準は厳しいものになる。HBFは単にSSDを上回るだけでは不十分であり、再設計を正当化するほど推論システム全体を改善しなければならない。

重要な指標はピーク帯域幅だけではない。運用事業者が重視するのは、毎秒トークン数、最初のトークンまでの時間、同時利用者数、消費電力、アクセラレータ利用率、システム総コストである。

高い公称帯域幅と、低いアプリケーション性能は両立し得る。ランダムアクセス、コントローラのオーバーヘッド、データ移動、キャッシュミスが実際の結果を左右する可能性がある。

Sandiskは、CMOS directly Bonded to Array技術によって、制御回路をNANDアレイに直接接続すると説明している。この手法は、従来のSSDコントローラが提供するものより短いデータ経路と高い並列性を目指す。

SK hynixは、シリコン貫通ビア、スタック組み立て、熱管理、HBM生産の経験を提供する。このパッケージングの知識は、問題の別の側面に対応する。

したがって、この提携は補完的である。Sandiskは高密度フラッシュを理解し、SK hynixは現在のHBM市場の中心で事業を展開している。

同時に、そこには珍しい戦略的緊張も生まれる。SK hynixは旺盛なHBM需要の恩恵を受けながら、メモリ階層でHBMの下に位置付けられる技術の開発を支援している。

HBFが市場全体を拡大するならば、この一見した矛盾にも理がある。SK hynixはHBMでの役割を守りつつ、そうでなければ自社抜きで発展するかもしれない第2階層にも参加できる。

これは必ずしもゼロサムの競争ではない。推論アクセラレータは、アクティブな計算にはHBMを、モデル容量にはHBFを使用でき、両方の需要を増やし得る。

より厳しい競争はシステムアーキテクチャに関わる。現在のAIサーバーはすでに、アクセラレータをHBM、ホストDRAM、NVMeストレージ、ネットワークストレージに接続している。

HBFはこの階層の中で居場所を獲得しなければならない。新しい階層が増えるたびに、コントローラ、スケジューリング判断、障害モード、検証要件、調達上の依存関係も増える。

ソフトウェアサポートが決定的になる。サービングフレームワークは、どのテンソルやキャッシュセグメントがHBFのレイテンシを許容できるかを把握しなければならない。

不適切な配置は、フラッシュを待つ間に高価なアクセラレータを停止させかねない。適切な配置なら、同じアクセラレータでより大きなモデルや、より多くの同時リクエストを処理できる可能性がある。

開発者には、こうした影響を可視化できるプロファイリングツールが必要になる。自動配置によって将来的には一部の複雑さを隠せる可能性があるが、初期のシステムではワークロードに応じたチューニングが必要になるだろう。

標準は、ソフトウェアチームに安定した目標を与えることで役立つ。また、アクセラレータベンダー各社が互換性のないインターフェースをそれぞれ実装するリスクも抑えられる。

OCPが重要なのは、その会員にクラウドおよびデータセンター分野の参加者が含まれ、システム全体のトレードオフを評価できるためだ。こうした関与があれば、2社のサプライヤーだけによる取り組みよりもHBFの検証は強固になる。

ただし、オープンなワークストリームが広範な採用を保証するわけではない。Samsung、Micron、Kioxia、アクセラレータ設計企業、ハイパースケール事業者は、提案されたインターフェースが自社の利益にかなうかを判断しなければならない。

一部のベンダーは、CXL接続メモリ、より大容量のHBM構成、圧縮されたモデル形式、あるいは高速なSSDアーキテクチャを選好するかもしれない。CXLは、プロセッサとデバイス間でメモリの拡張および共有を可能にするインターコネクトである。

これらの選択肢はHBFと重なり得る。また、NANDをHBMに似たパッケージに搭載する必要性を減らす可能性もある。

したがってHBFが対峙するのは単一企業ではなく、既存のシステム群である。既存のHBM中心アーキテクチャには、すでに生産ツール、顧客関係、ソフトウェアサポートが備わっている。

SandiskとSK hynixがこの地位に挑めるのは、完全なシステムによる証拠を示せる場合に限られる。仕様は有用だが、新しい階層が存続できるかを決めるのは、再現可能なワークロードの結果だ。

HBF仕様の主張がなお答えられないこと

最大の不確実性は、積層NANDが高速にデータを移動できるかではなく、商用システムがそれを予測可能かつ経済的に利用できるかどうかにある。

最初の未解決の問題はレイテンシだ。Sandiskは大幅なシーケンシャル帯域幅目標を掲げているが、帯域幅だけではすべてのアクセスパターンを説明できない。

推論ワークロードでは、小さく分散したデータ片を取得することがある。HBFは、長時間のプロセッサ停止を発生させずに、コントローラとソフトウェアがこうした要求をどう処理するかを示す必要がある。

2つ目の問題は書き込み耐久性だ。NANDセルはDRAMよりも書き込み可能回数が少なく、推論システムは一部の一時的な状態を継続的に更新する。

読み取り中心のモデル重みはHBFの強みに適している。一方、書き込み集約的なキャッシュ動作は、システムが書き込みを迂回させるか、摩耗を効果的に管理しない限り、その限界を露呈させる可能性がある。

3つ目の問題は熱特性だ。ロジックと多数のNANDダイを積層すると、すでに相当な熱を発生させるアクセラレータの近傍で密度が高まる。

保存ビット当たりの消費電力が低ければ有利だが、パッケージレベルの冷却は依然としてシステムの課題である。ベンダーは、持続的なワークロード下での動作限界を公表しなければならない。

製造歩留まりも別のリスクを生む。多数の接合済みダイを含むパッケージでは、欠陥によって使用可能なスタック数が減ると経済的価値を失いかねない。

Sandiskの接合プロセスとSK hynixのパッケージング経験は、この課題に対応するものだ。とはいえ、両社は商用HBFについて、公に利用可能で独立して検証された歩留まりまたは信頼性データをまだ提供していない。

相互運用性も同様に不確実である。真の標準であれば、異なるサプライヤーのコンポーネントを共通のコントローラとソフトウェアで動作させられるはずだ。

主に1社の技術を中心に策定された文書は、名目上はオープンでも、競合他社にとって実装が難しい可能性がある。参加が広がれば、OCPによるレビューはそのリスクを抑えられる。

知的財産に関する条件も重要だ。システム構築企業は、インターフェースのどの要素がオープンで、どの要素がライセンスを要する製造プロセスに依存するのかを理解する必要がある。

電気的な仕様が、物理的な製造方法まで自動的に標準化するわけではない。企業は接合、コントローラ、NAND設計を保護しながら、インターフェースを共有できる。

スケジュールは慎重に検証すべきだ。Sandiskは以前、初期HBFサンプルを2026年後半、HBF搭載デバイスのサンプルを2027年初頭に提供する目標を示していた。

これらの目標は、シリコン検証、仕様策定、顧客統合が並行して進んでいることを意味する。並行開発は時間を節約する一方、設計変更が後期に発生した場合のコストを増大させる。

OCPで正式に承認された文書があれば、不確実性の一部は減るだろう。それでも、製造準備、ソフトウェアの成熟度、ワークロード性能に関する疑問は残る。

業界報道でも、商用化までの時期について相反する見通しが示されている。一部の報道は2026年と2027年ごろのサンプル提供を指す一方、より広いロードマップでは成熟したHBF導入はさらに後とされている。

この違いは、直接的な矛盾ではなく、異なるマイルストーンを反映している可能性がある。エンジニアリングサンプルは、大量生産され広く相互運用可能な製品の何年も前に登場し得る。

Google Newsや別のアグリゲーターが短縮された見出しを拡散する場合でも、この区別は明確に保つべきだ。「仕様公開」は「製品出荷」を意味しない。

「製品サンプリング」であっても、限定的な評価用ユニットを指す場合がある。顧客は導入を確約せずに、これらのデバイスをテストできる。

信頼できる採用の根拠には、社内デモ以上のものが必要だ。独立したシステム構築企業は、HBF、HBM、ホストメモリ、SSD構成を比較するワークロードを公表すべきである。

こうした比較では、アクセラレータの種類、モデルサイズ、バッチサイズ、コンテキスト長、電力、レイテンシ目標を統制すべきだ。そうでなければ、容量上の利点が性能面の不利益を覆い隠す可能性がある。

両社は障害時の挙動も明確にすべきだ。運用者は、システムが不良ダイをどう隔離し、サービス可用性を維持し、HBFデバイスの障害からどう復旧するのかを知る必要がある。

HBFは不揮発性メディアを使用するため、残存するモデルデータに関するセキュリティ上の問題を生じる可能性がある。仕様では、消去、アクセス制御、ライフサイクル管理を定義すべきだ。

これらの問題はいずれも、この概念を無効にするものではない。ワークストリームと完成した標準の違いが重要である理由を示している。

ワークストリームは議論を始める。公開仕様は、その議論をベンダー、顧客、独立したエンジニアが検証できる要件へと変えるべきだ。

HBFが現実になりつつあるかを示す3つのシグナル

次の段階は、公開されたOCP文書、検証済みサンプル、そしてSandiskとSK hynix以外の企業からの支持によって判断すべきだ。

最初のシグナルは、特定可能なOCP仕様である。そこにはバージョン、技術的な範囲、ガバナンス上のステータス、改訂履歴が含まれるべきだ。

公開されれば、現在の標準化に関する主張は強まる。公開が引き続きなければ、見出しだけが正式なプロセスより先行したことを示唆する。

文書の内容は、その存在自体と同じくらい重要だ。狭い機械的な提案よりも、インターフェース、コマンド、信頼性、相互運用性を扱う仕様のほうが重みを持つ。

2つ目のシグナルはSandiskのサンプリングに関するマイルストーンだ。同社は、初期HBFメモリサンプルを2026年後半に提供する目標を掲げていた。

実動するサンプルは、ランダムアクセスレイテンシ、持続帯域幅、耐久性、消費電力、熱特性、エラー時の挙動を含む詳細な証拠をもたらすはずだ。

独立したテストは、ベンダーによるデモよりも強い根拠となる。遅延がHBFを終わらせるわけではないが、2027年初頭のデバイスサンプルに向けた示された道筋は弱まる。

3つ目のシグナルは、創設パートナー以外の参加だ。アクセラレータベンダー、ハイパースケーラー、サーバーメーカー、ソフトウェアプロジェクト、追加のメモリサプライヤーが取り組みに加わるかを注視すべきである。

幅広い参加は、HBFが共有アーキテクチャになりつつあることを示す。参加が限定的なら、二者間の製品戦略に近い状態にとどまる。

Samsung、Micron、Kioxiaは、関連するメモリまたはフラッシュの専門知識を持つため、特に重要な比較対象である。各社の支持、対抗提案、あるいは沈黙が、市場の方向性を明らかにするだろう。

アクセラレータ側の支援はさらに重要だ。プロセッサに適切なコントローラ、パッケージ接続、メモリ管理ソフトウェアがなければ、HBFは有用なインフラになれない。

クラウド事業者は最も強い需要シグナルを提供できる。容量とエネルギー利用の改善がアーキテクチャ変更を正当化するほど大規模な推論フリートを運用しているからだ。

ソフトウェアでの取り組みにも注目すべきだ。推論エンジン、コンパイラ、オーケストレーションシステムにおけるメモリ配置のサポートは、ハードウェア計画がプレゼンテーションの段階を超えたことを示すだろう。

Google Newsでこの話題を追う読者は、これらのシグナルと繰り返される発表を区別すべきだ。配信された見出しは、1件の提携を複数の独立した確認のように見せることが多い。

基礎となる経緯は単純である。SandiskとSK hynixは2025年8月に協業で合意し、2026年2月にOCPワークストリームを開始、将来のサンプリング目標を示した。

新たに公開された仕様は次の明確なマイルストーンになるが、検証可能な文書が必要だ。その後には、製品検証とエコシステムの参加が続かなければならない。

開発者にとって、HBFはモデル、キャッシュ、検索データをアクセラレータ周辺にどう配置するかを変える可能性がある。同時に、慎重なプロファイリングを要する新たな性能境界をもたらす可能性もある。

エンタープライズの購買担当者は、提案された容量増加が実際のサービス提供ワークロードを改善するかを問うべきだ。コンポーネントの帯域幅に依存せず、システム全体の測定を求める必要がある。

ナレッジワーカーやAIユーザーがHBFを直接購入することはない。それでも、より長いコンテキスト、より大きなモデル、あるいは低い推論コストを通じて、その影響を感じる可能性がある。

こうした利点は、依然として潜在的な結果であり、確認済みの成果ではない。最も有用な対応は、熱心な宣伝も早すぎる否定も受け入れず、証拠を追跡することだ。

この標準化の取り組みは、実在するメモリのボトルネックに対処するため、注目に値する。その成功は現在、パートナー各社がオープンなワークストリームを検証可能なインフラへと変えられるかにかかっている。

まずOCP文書、次に顧客テスト済みのシリコン、そして3番目に外部からの参加を注視すべきだ。これらのシグナルを合わせることで、HBFが標準になりつつあるのか、それとも有望な提案のままなのかが明らかになる。