SK hynix setzt den ersten HBF-Standard, und die Google-Hynix-Verbindung erhöht den Einsatz

SK hynix hat die erste Spezifikation für High Bandwidth Flash veröffentlicht – nur sechs Monate nach dem Start seines Standardisierungskonsortiums mit Sandisk. Die Verbindung zwischen Google und Hynix bringt eine wichtige Stimme von Kundenseite ein, denn Google beteiligt sich nun neben dem KI-Prozessorentwickler Tenstorrent.

Die Spezifikation definiert HBF-Kapazitäten von bis zu 512GB und Bandbreitenklassen von etwa 0,4TB/s bis 3,0TB/s. HBF ist Flash-Speicher, der für einen deutlich schnelleren Prozessorzugriff als eine herkömmliche Solid-State-Drive verpackt wird. Er soll High-Bandwidth-Memory ergänzen, nicht es bei jeder Arbeitslast ersetzen.

Genau diese Unterscheidung schafft die eigentliche Spannung. HBM liefert die Geschwindigkeit, die moderne Beschleuniger benötigen, doch Kapazitäts-, Energie-, Packaging- und Lieferengpässe prägen ganze KI-Systeme. SK hynix und Sandisk schlagen eine weitere Ebene für Daten vor, die hohe Bandbreite benötigen, ohne knappe HBM-Kapazität zu belegen.

Googles Präsenz verleiht diesem Vorschlag mehr Glaubwürdigkeit, doch Beteiligung ist kein Einsatz in der Praxis. Das Konsortium benötigt weiterhin funktionierendes Silizium, zuverlässige Software und Belege dafür, dass NAND-Latenz und -Haltbarkeit für produktive Inferenz geeignet sind. Diese Tests werden entscheiden, ob HBF zur Infrastruktur wird oder eine attraktive Spezifikation bleibt.

SK hynix macht aus HBF einen offenen Standard

Die erste Spezifikation gibt Prozessordesignern ein gemeinsames technisches Ziel, etabliert jedoch noch kein kommerzielles Produkt.

SK hynix kündigte die Spezifikation am 4. August zur Eröffnung der FMS 2026 in Santa Clara, Kalifornien, an. Die Konferenz läuft bis zum 6. August und bringt Unternehmen aus Speicher-, Storage-, Prozessor- und Rechenzentrumsbranche zusammen.

Die Veröffentlichung folgt auf einen Standardisierungsprozess, der im Februar 2026 gemeinsam mit Sandisk begonnen wurde. Diese Initiative selbst folgte auf eine erste Partnerschaft der Unternehmen im August 2025. Der Übergang von einer Partnerschaft zu einer veröffentlichten Spezifikation innerhalb von sechs Monaten ist für eine neue Speicherkategorie ungewöhnlich schnell.

Laut den HBF specifications unterstützt das Design NAND-Die-Stacks mit 8 und 16 Lagen. Die Kapazitätsobergrenze liegt bei 512GB, während drei Leistungsklassen ungefähr 0,4TB/s bis 3,0TB/s abdecken.

Diese Bereiche sind wichtig, weil HBF nicht als ein einziges festes Produkt präsentiert wird. Die Klassen ermöglichen es Designern, Bandbreite, Kapazität, Packaging-Komplexität und Systemanforderungen auszubalancieren. Eine für Modellgewichte optimierte Bereitstellung könnte eine andere Konfiguration benötigen als ein System für Retrieval-Daten.

Der Standard setzt zudem auf UCIe, Universal Chiplet Interconnect Express. UCIe ist eine offene Schnittstelle, um verschiedene Halbleiter-Chiplets innerhalb eines Packages oder Systems zu verbinden.

Die Nutzung von UCIe dürfte die Abhängigkeit von einer proprietären Prozessorschnittstelle verringern. Grundsätzlich könnte HBF mit unterschiedlichen CPUs, GPUs und KI-Beschleunigern verbunden werden, die kompatible Implementierungen unterstützen. Diese Flexibilität ist entscheidend, wenn HBF zu einer Branchenebene werden soll.

Das Dokument behandelt zudem elektrische Eigenschaften, Zuverlässigkeit der Die-Stacks, Packaging und Hinweise zu Software-Ein- und Ausgabe. Diese Details führen das Projekt über ein Konzeptdiagramm hinaus. Sie geben Speicherlieferanten, Prozessorunternehmen und Softwareentwicklern gemeinsame technische Grenzen.

SK hynix und Sandisk veröffentlichten die Spezifikation über das Open Compute Project. Der standardization launch schuf einen eigenen OCP-Arbeitsstrang statt eines geschlossenen bilateralen Formats.

Diese Entscheidung ist für die Akzeptanz wichtig. Ein Prozessorunternehmen wird kaum ein Speichersystem entwickeln wollen, das von einem einzigen Lieferanten kontrolliert wird. Eine offene Spezifikation bietet einen klareren Weg zu mehreren Implementierungen, breiteren Toolchains und gemeinsamer Softwareunterstützung.

Offenheit garantiert jedoch keine Interoperabilität. Anbieter müssen Spezifikationen weiterhin in kompatible Controller, Packages, Firmware und Laufzeitverhalten umsetzen. Zertifizierung und Referenzimplementierungen werden ebenso wichtig sein wie das Dokument selbst.

Der erste HBF-Standard verändert daher die Diskussion, ohne sie zu entscheiden. Die Branche verfügt nun über eine definierte Architektur zur Bewertung. Produktionsnachweise dafür, dass diese Architektur die versprochene Wirtschaftlichkeit liefert, gibt es noch nicht.

Warum die Verbindung zwischen Google und Hynix für KI-Inferenz wichtig ist

Googles Beteiligung signalisiert, dass HBF mit Blick auf Hyperscale-Arbeitslasten gestaltet wird – nicht nur von Unternehmen, die einen weiteren NAND-Markt erschließen wollen.

SK hynix zufolge beteiligen sich Google und Tenstorrent am Konsortium. Der Google-DeepMind-Senior-Staff-Engineer Xiaoyu Ma soll zudem an einer Podiumsdiskussion am 6. August mit Führungskräften von SK hynix und Sandisk teilnehmen.

Der Titel der Diskussion, „Breaking the Memory Wall with High Bandwidth Flash“, benennt das Zielproblem. KI-Prozessoren können Berechnungen schnell ausführen, doch die Leistung leidet, wenn nützliche Daten sie nicht mit entsprechender Geschwindigkeit erreichen.

Bei der Inferenz verschärft sich dieses Problem. Training erstellt ein Modell, während Inferenz das Modell ausführt, um Anfragen zu beantworten. Produktionssysteme bewegen Modellgewichte, Attention-Daten, Embeddings und zwischengespeicherten Kontext wiederholt durch eingeschränkte Speicherhierarchien.

Längere Kontextfenster erhöhen den Druck über den Key-Value-Cache. Ein KV-Cache speichert Zwischendaten der Attention, damit ein Modell während der Generierung frühere Token nicht neu berechnen muss. Seine Größe wächst, wenn Anfragen länger oder zahlreicher werden.

Agentische Systeme können das Problem verstärken. Ein KI-Agent kann planen, Tools aufrufen, Dateien prüfen, Datensätze abrufen und über viele Schritte hinweg Zustände bewahren. Jede Aktivität erhöht die Datenbewegung und kann eine Anfrage länger aktiv halten.

SK-hynix-Executive-Vice-President Kim Chun-sung und Vice President Kang Uk-song präsentieren gestuften Speicher als Antwort. Gestufter Speicher verteilt Daten gemäß Geschwindigkeit, Kapazität, Kosten und Zugriffsmustern auf mehrere Speichertypen.

In diesem Modell bleibt HBM für die heißesten Daten am nächsten am Beschleuniger. HBF hält größere, überwiegend leseorientierte Datensätze, die dennoch erhebliche Bandbreite erfordern. Herkömmliche SSDs bilden eine weitere, langsamere Ebene mit größerer Distanz und Kapazität.

Die Beziehung zwischen Google und Hynix ist wichtig, weil Google KI-Dienste betreibt und eigene Tensor Processing Units entwickelt. Seine Ingenieure können den Vorschlag anhand realer Anforderungen an Beschleuniger, Compiler, Modelle und Rechenzentren bewerten.

Das bedeutet nicht, dass Google sich zum Kauf von SK hynix HBF verpflichtet hat. Die offizielle Ankündigung nennt eine Konsortiumsbeteiligung, keinen Liefervertrag oder Bereitstellungszeitplan. Sie benennt auch keine Google-Systeme, die diese Technologie einsetzen könnten.

Dennoch kann die Beteiligung von Kundenseite verhindern, dass ein Standard nur die Prioritäten eines Speicherlieferanten widerspiegelt. Hyperscaler achten auf Fehlerbehandlung, Flottenmanagement, Softwareportabilität, Reparierbarkeit und die Gesamtauslastung des Systems.

Tenstorrent bringt eine andere Perspektive ein. Das Unternehmen entwickelt KI-Prozessoren und RISC-V-Technologie außerhalb der dominierenden GPU-Architektur. Seine Beteiligung stützt die Behauptung des Konsortiums, dass HBF über verschiedene Prozessortypen hinweg funktionieren sollte.

Zusammen erweitern Google und Tenstorrent das Projekt über SK hynix und Sandisk hinaus. Das eine Unternehmen steht für KI-Betrieb im Hyperscale-Maßstab, das andere für alternatives Beschleunigerdesign. Beide können Annahmen offenlegen, die Speicheranbieter sonst übersehen könnten.

Das wichtige Signal ist architektonisches Interesse, nicht die Befürwortung fertiger Hardware. HBF hat nun Teilnehmer, die prüfen können, ob seine Schnittstelle zu realen Inferenzsystemen passt. Ihre fortgesetzte Beteiligung wird aussagekräftiger sein als ihre Namen in der Ankündigung zum Start.

HBF schafft eine neue Ebene, statt HBM zu ersetzen

Der zentrale Mechanismus ist die Datenplatzierung: HBF funktioniert nur, wenn Systeme latenzempfindliche Daten in HBM halten und geeignete Daten in Flash verschieben.

HBM nutzt gestapelte DRAM-Dies und breite Schnittstellen, um nahe am Prozessor sehr hohe Bandbreiten bereitzustellen. HBF übernimmt die Idee gestapelter, breiter Schnittstellen, verwendet jedoch NAND-Flash für höhere Kapazität und persistenten Speicher.

NAND bewahrt Daten ohne Strom und bietet eine deutlich höhere Dichte als DRAM. Es weist jedoch höhere Leselatenzen, langsamere Schreibvorgänge und eine begrenzte Program-Erase-Haltbarkeit auf. Diese Unterschiede verhindern, dass HBF als einfacher HBM-Ersatz fungiert.

Die obere Klasse von 3,0TB/s ist daher nur ein Teil der Leistungsbewertung. Spitzenbandbreite beschreibt, wie viele Daten sich unter günstigen Bedingungen bewegen lassen. Sie erfasst nicht die Verzögerung, bevor kleine oder unregelmäßige Lesevorgänge zurückkehren.

Diese Lücke ist für KI-Arbeitslasten wichtig. Modellgewichte werden während der Inferenz im Allgemeinen wiederholt gelesen und selten verändert, was besser zu Flash passt. KV-Caches erhalten fortlaufend Schreibvorgänge und sind daher schwieriger geeignet.

Eine Forschungsarbeit vom Juni 2026 fragte, ob High-Bandwidth-Flash als zweite Speicherebene ausreicht. Die Autoren modellierten in ihrer memory-tier analysis HBF gegenüber On-Package-LPDDR und kohärent angebundenem Speicher.

Ihr Modell ergab, dass unterschiedliche Eigenschaften verschiedene Arbeitslasten dominierten. Kapazität verringerte die Anzahl der Modellreplikate, Bandbreite beeinflusste die Datenbereitstellung, und Schreibunterstützung bestimmte, ob eine Ebene KV-Cache-Verkehr aufnehmen konnte.

Die Arbeit modellierte zudem eine NAND-Leselatenz von etwa 20 Mikrosekunden. Diese Verzögerung verringerte die effektive Bandbreite bei verstreuten, kleinen Zugriffen, selbst wenn die nominelle HBF-Bandbreite hoch war.

Die Forschung war analytisch und keine Messung kommerziellen HBF-Siliziums. Ihre Annahmen sollten nicht als Urteil über SK-hynix-Hardware betrachtet werden. Dennoch identifiziert sie einen glaubwürdigen Belastungstest für die Architektur.

Eine weitere Arbeit vom Juli schlug FlashAccel vor, eine Architektur für den Einsatz von HBF bei der Inferenz großer Modelle. Die FlashAccel study konzentrierte sich auf Flash mit höherer Kapazität und befasste sich zugleich mit niedriger Bandbreitenauslastung und Schreibbeschränkungen.

Diese Studien deuten auf Software als versteckte Voraussetzung hin. Eine Laufzeitumgebung muss heiße und kalte Daten identifizieren, Zugriffsmuster vorhersagen und Informationen bewegen, ohne den Beschleuniger anzuhalten.

Dieser Prozess darf keine übermäßigen Kopiervorgänge hinzufügen. Würden dieselben Daten wiederholt zwischen SSD, HBF und HBM verschoben, verbrauchte dies Bandbreite und Energie. Eine schlechte Platzierung könnte den Kapazitätsvorteil zunichtemachen.

Auch die Prozessorschnittstelle muss unter realistischen Zugriffsmustern einen nutzbaren Durchsatz erhalten. UCIe bietet eine gemeinsame Interconnect-Grundlage, doch Controller und Software bestimmen, wie Anwendungen diese Ebene erleben.

Der stärkste frühe Einsatz von HBF könnte Modellgewichte, Retrieval-Indizes oder relativ stabile Expertenparameter umfassen. Diese Datensätze können groß sein, intensiv gelesen werden und weniger schreibintensiv als aktive KV-Caches sein.

Mixture-of-Experts-Modelle liefern ein klares Beispiel. Solche Modelle aktivieren für jedes Token ausgewählte Expertenkomponenten, statt jeden Parameter zu verwenden. Seltener genutzte Experten könnten in HBF liegen, bis die Laufzeitumgebung sie benötigt.

Diese Anordnung könnte es einem System ermöglichen, ein größeres Modell nahe an jedem Beschleuniger zu halten. Sie könnte Übertragungen aus Remote-Storage verringern oder die Anzahl der Geräte reduzieren, die Modellgewichte vorhalten müssen.

Ein zu unvorhersehbaren Zeitpunkten ausgewählter Experte erzeugt jedoch unregelmäßige Lesevorgänge. Dann wird NAND-Latenz wichtig, selbst wenn die aggregierte Bandbreite ausreichend erscheint. Prefetching kann nur helfen, wenn die Software den Bedarf präzise vorhersagt.

HBF wirft zudem Fragen zur Gehäusetechnik und Thermik auf. Gestapelter NAND, Controller-Logik, Verbindungen und nahegelegene Beschleuniger erzeugen allesamt Wärme. Der Standard enthält Leitlinien zu Packaging und Zuverlässigkeit, doch Implementierungen müssen diese Grenzen validieren.

SK hynix beschreibt HBF als Brücke zwischen HBM und SSDs. Das ist der richtige konzeptionelle Rahmen. Sein Wert hängt davon ab, ob es die Lücke schließen kann, ohne zu viele Schwächen beider Seiten zu übernehmen.

Der erste Standard muss sich noch der Realität des Siliziums stellen

Die größte Unsicherheit bei HBF besteht darin, ob reale Systeme beeindruckende Kapazitäts- und Bandbreitenspezifikationen in vorhersehbare Anwendungsleistung umsetzen können.

Die FMS-Ankündigung enthält keinen unabhängig gemessenen HBF-Benchmark. Sie nennt weder Latenz, Ausdauer, Anwendungsdurchsatz, Fehlerraten, thermische Grenzen noch Stromverbrauch für kommerzielle Hardware.

Sie nennt auch keinen Produktionstermin für HBF von SK hynix. Sandisk hatte zuvor angegeben, dass erste HBF-Muster für 2026 geplant seien, gefolgt von Geräten mit integriertem HBF für KI-Inferenz Anfang 2027.

Roadmaps können sich ändern. Die Fertigung von gestapeltem NAND mit einer Hochgeschwindigkeits-Logikschnittstelle erfordert Arbeit an Ausbeute, Packaging, Controllern und Thermik. Ein Standard kann Schnittstellen abstimmen, ohne diese Produktionsherausforderungen zu lösen.

Auch die Eignung für Workloads birgt ein Risiko. Flash eignet sich für Lesevorgänge und persistente Daten, während Inferenzsysteme zunehmend große dynamische Caches erzeugen. Wenn HBF nicht genügend Schreibvorgänge bewältigen kann, benötigen Architekten für diesen Datenverkehr eine weitere Ebene.

Das macht HBF nicht irrelevant. Es begrenzt die Aufgaben, die es effizient erfüllen kann. Das Design könnte bei Gewichten und Indizes überzeugen, aber bei sich schnell ändernden Zuständen schwach abschneiden.

Die Reife der Software ist ein weiterer limitierender Faktor. Beschleuniger sind bereits auf komplexe Laufzeitumgebungen für Speicherzuweisung, Batching, Caching, Quantisierung und Scheduling angewiesen. HBF ergänzt diesen Stack um eine weitere Platzierungsentscheidung.

Entwickler benötigen Transparenz darüber, wo sich Daten befinden und warum sie verschoben werden. Andernfalls kann ein Modell im Labor seine Durchsatzziele erreichen, in der Produktion jedoch instabile Tail-Latenzen erzeugen.

Tail-Latenz misst den langsamsten Anteil von Anfragen statt des Durchschnitts. Sie ist wichtig, weil einige verzögerte Speicherabrufe das Reaktionsziel eines interaktiven Dienstes verfehlen lassen können.

Die drei Bandbreitenklassen des Standards könnten zudem die Leistungserwartungen fragmentieren. Ein System, das auf dem Verhalten von Klasse 3 basiert, lässt sich möglicherweise nicht nahtlos auf eine niedrigere Klasse übertragen. Software benötigt verlässliche Fähigkeitserkennung und Fallback-Verhalten.

Auch die Interoperabilität ist noch unbewiesen. Eine offene Schnittstelle sollte mehrere Prozessor- und Speicherkombinationen ermöglichen. Die tatsächliche Kompatibilität wird von elektrischen Eigenschaften, Firmware, Packaging und Details des Fehlermanagements abhängen.

Googles Beteiligung beseitigt diese Risiken nicht. Die Verbindung zwischen Google und SK hynix stärkt das Vertrauen, dass relevante Fragen in den Entwicklungsprozess einfließen. Sie liefert weder einen öffentlichen Benchmark noch eine verbindliche Zusage für den Einsatz.

Der Wettbewerb wird den HBF-Ansatz aus mehreren Richtungen unter Druck setzen. Samsung, Micron und andere Speicherhersteller können die HBM-Kapazität ausbauen oder alternative Designs mit gestapeltem Flash entwickeln. Über CXL angebundener Speicher kann eine weitere Kapazitätsebene bieten.

In der Nähe eines Beschleunigers platzierter LPDDR bietet geringere Latenzen und volle Beschreibbarkeit, allerdings mit anderen Kompromissen bei Dichte und Energieverbrauch. Direkte GPU-zu-Storage-Technologien können zudem den Zugriff auf herkömmliche SSDs verbessern, ohne HBF zu schaffen.

Diese Ansätze schließen sich nicht gegenseitig aus. Ein künftiger Server könnte HBM, LPDDR, HBF, CXL-Speicher und SSDs gemeinsam einsetzen. Diese Flexibilität erhöht jedoch auch die Komplexität und verlangt von jeder zusätzlichen Ebene eine Rechtfertigung ihrer Kosten.

Der überzeugendste Anwendungsfall für HBF wird nicht allein aus einer Spitzen-Spezifikation entstehen. Er wird sich durch niedrigere Systemkosten, bessere Energieeffizienz oder höheren Durchsatz bei einem klar definierten Produktions-Workload beweisen.

Unabhängige Ergebnisse sollten vollständige Systeme vergleichen, nicht isolierte Speichergeräte. Nützliche Messgrößen sind Tokens pro Sekunde, Zeit bis zum ersten Token, Tail-Latenz, Energie pro Token und Beschleunigerauslastung.

Auch Zuverlässigkeitsergebnisse werden entscheidend sein. Rechenzentren benötigen vorhersehbare Fehlerkorrektur, Komponentenlebensdauer, Serviceverfahren und Fehlerisolation. Eine persistente Speicherebene in der Nähe teurer Prozessoren darf nicht zu einem operativen Schwachpunkt werden.

SK hynix sagt, HBF werde die Grenze zwischen Speicher und Storage erweitern. Diese Einordnung ist nachvollziehbar, doch die Grenze existiert, weil sich die Technologien unterschiedlich verhalten. Diese Unterschiede lassen sich nicht durch Benennung wegentwickeln.

SK hynix kombiniert HBF mit 375-Layer-NAND

Die FMS-Präsentation verknüpft den HBF-Standard mit einem umfassenderen Vorhaben, NAND innerhalb energiebegrenzter KI-Infrastruktur nützlicher zu machen.

SK hynix zeigt außerdem erstmals seinen NAND-Wafer der zehnten Generation mit 375 Layern sowie zugehörige Produkte. Die Technologie befindet sich weiterhin in Entwicklung.

Das Unternehmen sagt, der neue NAND verbessere die Leistung pro Watt im Vergleich zur vorherigen Generation um das 2,5-Fache. Diese Angabe stammt vom Unternehmen und wurde in der Ankündigung nicht unabhängig validiert.

SK hynix plant, Anfang 2027 mit der Massenproduktion von Enterprise-SSDs zu beginnen, die diesen NAND verwenden. Das Unternehmen positioniert diese Laufwerke für leistungsstarke, kapazitätsintensive Rechenzentrums-Workloads.

Die NAND-Ankündigung stützt die HBF-Erzählung, ohne die Leistung von HBF zu belegen. Beide Produkte reagieren auf denselben Infrastrukturdruck: KI-Systeme benötigen mehr zugängliche Daten, aber nicht unbegrenzt Strom.

NAND mit höherer Dichte kann die Kapazität bei unveränderter physischer Grundfläche erhöhen. Bessere Leistung pro Watt kann zudem den Energieaufwand für das Verschieben von Daten durch Speichersysteme senken.

Diese Verbesserungen sind wichtig, weil KI-Infrastruktur zunehmend auf Systemebene begrenzt wird. Ein schnellerer Beschleuniger bietet wenig Nutzen, wenn Speicher, Storage, Netzwerk, Kühlung oder Stromversorgung seine vollständige Auslastung verhindern.

SK hynix präsentiert daher ein Portfolio statt eines universellen Speichers. Die Botschaft eines abgestuften Speichersystems umfasst schnelles DRAM, gestapeltes HBM, HBF und Enterprise-SSDs.

Diese Strategie spiegelt eine praktische Wahrheit wider. Kein einzelnes Medium bietet gleichzeitig die niedrigste Latenz, die höchste Kapazität, die beste Ausdauer, den geringsten Energieverbrauch und die niedrigsten Kosten.

Die technische Aufgabe besteht darin, jeden Datensatz in der günstigsten Ebene zu platzieren, die sein Leistungsziel noch erfüllt. Dieses Prinzip klingt einfach, doch Workloads ändern sich von Anfrage zu Anfrage.

Ein Retrieval-System könnte beispielsweise Milliarden von Vektoren speichern, die Dokumente oder Bilder repräsentieren. Häufig abgerufene Indexsegmente könnten im schnelleren Speicher bleiben, während weniger häufig genutzte Segmente in HBF oder SSDs verschoben werden.

Ein großer Inferenzdienst könnte aktive Modellschichten in HBM halten. Weniger häufig ausgewählte Expert-Gewichte könnten in HBF liegen, während herkömmlicher Storage vollständige Checkpoints und historische Versionen speichert.

Ein Agent, der mit Unternehmensdokumenten arbeitet, schafft einen weiteren möglichen Workload. Das System benötigt Modellgewichte, Retrieval-Indizes, Tool-Zustand und Nutzerkontext, doch diese Datensätze weisen unterschiedliche Zugriffsmuster auf.

Wissensarbeiter werden nicht direkt mit HBF interagieren. Sie werden seine Wirkung nur bemerken, wenn Dienste längeren Kontext, größere lokale Indizes, stabilere Antwortzeiten oder einen geringeren Ressourcenverbrauch unterstützen.

Engineering-Teams werden die Integrationslast tragen. Sie müssen das Speicherverhalten nachvollziehen, Platzierungsrichtlinien abstimmen und Dokumentation über Änderungen an Hardware und Software hinweg bewahren. Eine durchsuchbare Engineering-Wissensdatenbank kann Teams dabei helfen, diese Entscheidungen festzuhalten.

Das breitere Portfolio schützt SK hynix zudem vor einem binären HBF-Ausgang. Wenn sich die HBF-Einführung verzögert, kann die Nachfrage nach HBM und Enterprise-SSDs mit der KI-Infrastruktur dennoch wachsen.

Dieses Portfolio schafft jedoch einen strategischen Balanceakt. HBF muss genügend Mehrwert bieten, um Kunden zu gewinnen, ohne lediglich Umsätze von bestehenden Speicherprodukten zu verlagern.

Sandisk steht auf der NAND-Seite vor einer ähnlichen Herausforderung. HBF kann für Flash eine höherwertige Verwendung schaffen, doch Erfolg erfordert Prozessor- und Softwarepartner, die Storage-Anbieter allein nicht bestimmen können.

Deshalb sind der offene Standard und die Beteiligung am Konsortium gemeinsam wichtig. Die Speicherlieferanten definieren produzierbare Geräte, während Prozessor- und Cloud-Teilnehmer ein System gestalten, das diese nutzen kann.

Drei Signale werden zeigen, ob HBF zu echter Infrastruktur wird

Die nächste Phase muss die Dynamik des Konsortiums durch Hardware-Nachweise, Software-Unterstützung und reproduzierbare Implementierungen ersetzen.

Das erste Signal ist funktionierendes HBF-Silizium, gemessen unter produktionsnahen Inferenz-Workloads. Muster sollten mehr als Spitzenbandbreite offenlegen. Latenz, Ausdauer, Energieverbrauch, Thermik und effektiver Durchsatz verdienen gleiche Aufmerksamkeit.

Ein Muster, das für leselastige Modellgewichte eine nutzbare Leistung aufrechterhält, würde den Anwendungsfall stärken. Große Abstände zwischen nominaler und effektiver Bandbreite würden ihn schwächen, insbesondere bei unregelmäßigen Zugriffen.

Das zweite Signal ist die Softwareintegration. Große Inferenz-Laufzeitumgebungen benötigen Richtlinien für die Platzierung von Gewichten, Caches, Indizes und Zwischendaten über HBM, HBF und Storage hinweg.

Eine nützliche Integration sollte Metriken und Steuerungsmöglichkeiten bereitstellen, statt jede Platzierungsentscheidung zu verbergen. Betreiber müssen Seitenbewegungen, Stillstände, Schreibdruck und Kapazitätsnutzung diagnostizieren können.

Unterstützung durch Software von Google oder Tenstorrent würde die Beziehung zwischen Google und SK hynix konkreter machen. Öffentlicher Code, Referenzdesigns, Konferenzergebnisse oder dokumentierte Kompatibilität hätten mehr Gewicht als die bloße Mitgliedschaft im Konsortium.

Das dritte Signal ist eine breitere Implementierung des offenen Standards. Zusätzliche Speicherlieferanten, Prozessoranbieter oder Cloud-Betreiber würden die Abhängigkeit von den beiden Gründungsunternehmen verringern.

Mehrere interoperable Produkte würden zeigen, dass die Offenlegung durch OCP eine echte Branchenschnittstelle geschaffen hat. Inkompatible Varianten einzelner Anbieter würden dagegen nahelegen, dass dem Standard genügend Präzision oder kommerzielle Abstimmung fehlt.

FMS 2026 markiert den Beginn dieser Validierungsphase, nicht ihren Abschluss. SK hynix und Sandisk haben eine plausible neue Speicherebene definiert und relevante Teilnehmer gewonnen.

Sie haben jedoch noch nicht gezeigt, dass HBF realen Inferenzdatenverkehr besser bewältigt als konkurrierende Kombinationen aus HBM, LPDDR, CXL-Speicher und SSDs. Dieser Nachweis muss aus Systemen kommen, nicht aus Spezifikationen.

Für Entwickler und Unternehmenskäufer besteht die unmittelbare Maßnahme darin, Workload-Nachweise genau zu beobachten. Fragen Sie bei jedem Benchmark, wo Modellgewichte, KV-Caches und Retrieval-Indizes liegen.

Fragen Sie außerdem, ob die berichteten Gewinne den Energie-, Software- und Hardwareaufwand des gesamten Systems einschließen. Eine schnellere Speicherkomponente garantiert keinen effizienteren Dienst.

Der erste HBF-Standard macht diese Tests möglich. Die kommenden Muster werden entscheiden, ob die Bemühungen von Google, Sandisk und SK hynix zu einer neuen Infrastrukturebene oder zu einer ambitionierten Spezifikation werden.