Sandisk und SK hynix veröffentlichen eine offene HBF-Spezifikation, doch der Hardwaretest steht noch aus

Sandisk und SK hynix haben am 4. August die erste offene High Bandwidth Flash-Spezifikation veröffentlicht – nur sechs Monate nach dem Start ihrer Standardisierungsgruppe. Die Ankündigung schaffte es mit einem ungewöhnlich konkreten Versprechen für eine aufkommende Speichertechnologie in Google News: Kapazitäten von bis zu 512GB und Bandbreiten von bis zu 3TB/s.

Diese Kombination zielt auf eine wachsende Lücke in KI-Systemen. High Bandwidth Memory, kurz HBM, liefert hohe Geschwindigkeiten nahe am Prozessor, bleibt jedoch in der Kapazität begrenzt. Solid-State-Drives bieten deutlich mehr Speicherplatz, sind für viele latenzsensible Inferenzaufgaben jedoch zu weit vom Prozessor entfernt.

High Bandwidth Flash, bekannt als HBF, soll die Schicht zwischen beiden Technologien besetzen. Sandisk und SK hynix schlagen nicht vor, dass NAND-Flash jeden HBM-Stack ersetzt. Systeme sollen HBM für die am häufigsten benötigten Daten und HBF für größere Arbeitssätze nutzen, die weiterhin schnellen Zugriff erfordern.

Die Spezifikation erleichtert Prozessorentwicklern die Bewertung dieser Architektur. Sie belegt jedoch nicht, dass HBF seine beworbene Leistung in Produktionshardware liefern kann. Der eigentliche Wettbewerb lautet daher nicht Sandisk gegen SK hynix. Er lautet offene Spezifikation gegen die noch notwendige Entwicklungs- und Einführungsarbeit.

Die HBF-Spezifikation macht aus einer Speicheridee ein gemeinsames Ziel

Die Veröffentlichung gibt Prozessor-, Packaging- und Softwareteams ein gemeinsames HBF-Entwicklungsziel, liefert jedoch kein fertiges Produkt.

SK hynix kündigte die Spezifikation gemeinsam mit Sandisk auf der FMS 2026 in Santa Clara, Kalifornien, an. Die Veranstaltung findet vom 4. bis 6. August statt und konzentriert sich auf Speicher- und Storage-Technologie.

Die Unternehmen veröffentlichten ihre Arbeit über das Open Compute Project, kurz OCP, eine Branchenorganisation für offene Rechenzentrumsinfrastruktur. Diese Entscheidung ist wichtig, weil HBF die Beteiligung von mehr als zwei Speicherlieferanten benötigt.

Laut der Ankündigung der HBF-Spezifikation unterstützt das ursprüngliche Design zwei physische Konfigurationen. Ein Stack mit acht Dies bietet eine Option, während ein 16-Die-Stack die höchste angekündigte Kapazität ermöglicht.

Die Spezifikation deckt Kapazitäten bis zu 512GB ab. Zudem definiert sie drei Leistungsklassen mit Bandbreiten von ungefähr 0,4TB/s bis 3TB/s.

Diese Klassen ermöglichen Systementwicklern, HBF-Implementierungen auf unterschiedliche Workload- und Kostenanforderungen abzustimmen. Eine niedrigere Klasse könnte weniger anspruchsvolle Inferenzaufgaben unterstützen, ohne jedes Design zum komplexesten Package zu zwingen.

Die Veröffentlichung behandelt außerdem elektrische Eigenschaften, Packaging-Zuverlässigkeit, Prozessoranbindungen sowie Richtlinien für Software-Ein- und Ausgabe. Diese Details führen HBF über ein Präsentationskonzept hinaus und hin zu etwas, das Engineering-Teams prüfen können.

Die Prozessoranbindung nutzt Universal Chiplet Interconnect Express, kurz UCIe. UCIe ist eine offene Schnittstelle auf Package-Ebene, die separate Halbleiter-Dies innerhalb eines Systems verbindet.

Die offiziellen UCIe-Spezifikationen decken physische Verbindungen, Protokolle, Softwareverhalten und Konformitätstests ab. Die Verwendung dieser Schnittstelle verringert die Abhängigkeit von HBF von einer proprietären Verbindung eines einzelnen Prozessoranbieters.

Sie schafft zudem einen Weg, HBF mit CPUs, GPUs und anderen Beschleunigern zu verbinden. Diese Flexibilität ist zentral für das Argument eines offenen Standards, da KI-Infrastruktur mehr als eine Prozessorarchitektur umfasst.

Eine Schnittstellenspezifikation schafft jedoch nicht automatisch Interoperabilität. Anbieter benötigen weiterhin Controller, Packaging-Methoden, Firmware, Treiber, Speicherverwaltungsrichtlinien und Konformitätstests, die zusammenarbeiten.

Diese Unterscheidung geht in einer kurzen Google-News-Schlagzeile leicht verloren. Sandisk und SK hynix haben eine Spezifikation veröffentlicht, nicht allgemein verfügbare HBF-Module oder KI-Server für den Produktionseinsatz.

Ihr Tempo bleibt dennoch bemerkenswert. Sandisk und SK hynix kündigten ihre ursprüngliche Standardisierungspartnerschaft im August 2025 an. Sie starteten den OCP-Arbeitsstrang im Februar 2026 und legten diese erste Spezifikation rund sechs Monate später vor.

Google und der KI-Prozessorentwickler Tenstorrent beteiligen sich laut SK hynix inzwischen am Konsortium. Ihre Präsenz gibt dem Projekt wertvollen Input sowohl von der Workload- als auch von der Prozessorseite.

Keines der Unternehmen hat ein qualifiziertes Produktionssystem angekündigt, das die Spezifikation nutzt. Noch kein unabhängiger Benchmark hat Bandbreite, Latenz, Ausdauer oder Energieeffizienz eines konformen kommerziellen Geräts bestätigt.

Das offene Dokument verändert daher, worüber die Branche sprechen kann. Statt über eine undefinierte Speicherkategorie zu diskutieren, können Ingenieure Stack-Größen, Bandbreitenklassen, Schnittstellen, Packaging-Erwartungen und Softwareanforderungen prüfen.

Das ist das unmittelbare Ereignis. Die größere Frage lautet, warum KI-Inferenz überhaupt eine weitere Speicherschicht benötigt.

Warum KI-Inferenz HBM und SSDs zunehmend unter Druck setzt

HBF existiert, weil Inferenz zunehmend HBM-ähnlichen Zugriff auf Datensätze benötigt, die zu groß sind, um vollständig in HBM zu verbleiben.

KI-Training erhält einen Großteil der Infrastrukturaufmerksamkeit, doch Inferenz schafft ein anderes Speicherproblem. Training erstellt ein Modell. Inferenz führt dieses Modell wiederholt aus, um Anfragen zu beantworten, Medien zu generieren, Tools zu verwenden oder einen Agenten zu betreiben.

Ein bereitgestellter Dienst kann Modellgewichte, Attention-Daten, zwischengespeicherte Tokens, Retrieval-Indizes und Anwendungskontext benötigen. Alle aktiven Datensätze im schnellsten Speicher vorzuhalten, wird schwieriger, wenn Modelle und parallele Workloads wachsen.

HBM platziert DRAM-Stacks nahe an einem Prozessor und verbindet sie über eine breite Schnittstelle. Dieses Design bietet Beschleunigern, die große Datenmengen schnell bewegen müssen, hohe Bandbreiten.

Seine Stärken beseitigen keine physischen Einschränkungen. Package-Fläche, Fertigungskomplexität, Stromverbrauch, Kapazität und Versorgung beeinflussen alle, wie viel HBM neben jedem Prozessor Platz findet.

Enterprise-SSDs lösen ein anderes Problem. Sie speichern weit mehr Informationen zu geringeren Kosten pro Bit, und NAND-Flash behält Daten ohne kontinuierliche Stromversorgung. Ihr konventioneller Storage-Pfad fügt jedoch Latenz und Software-Overhead hinzu.

Dadurch entsteht eine architektonische Lücke. Einige Inferenzdaten benötigen nicht die geringstmögliche HBM-Latenz, brauchen aber schnelleren und direkteren Zugriff als ein herkömmlicher SSD-Pfad bietet.

SK hynix beschreibt HBF als unterstützende Schicht, während HBM weiterhin die Aufgaben mit dem höchsten Bandbreitenbedarf übernimmt. Dieses Modell gestaffelter Speicher weist Daten je nach Zugriffshäufigkeit und Leistungsanforderungen unterschiedlichen Technologien zu.

Ein großes Modell liefert ein nützliches Szenario. Häufig verwendete Teile könnten in HBM verbleiben, während weniger aktive Gewichte in HBF liegen. Eine SSD könnte Daten speichern, die das System seltener benötigt.

Das System würde Informationen dann zwischen den Ebenen bewegen, wenn sich die Workload-Bedingungen ändern. Dieser Ansatz ähnelt etablierten Cache-Hierarchien, doch Kapazitäten, Bandbreitenanforderungen und Packaging-Herausforderungen sind erheblich größer.

Der Nutzen hängt von Platzierungsentscheidungen ab. Wenn Software wiederholt die falschen Daten aus einer langsameren Ebene abruft, können Prozessorkerne warten und die Gesamtleistung sinken.

HBF muss daher mehr werden als dichter Flash neben einem Beschleuniger. Das umgebende System benötigt Controller und Software, die vorhersagen, welche Daten in jede Speicherschicht gehören.

Agentische KI verstärkt diesen Druck. Ein Agent kann längere Verläufe vorhalten, externes Wissen konsultieren, Software-Tools aufrufen und mehrere Modelloperationen für eine Nutzeranfrage koordinieren.

Diese Workflows schaffen größere und weniger vorhersehbare Arbeitssätze. Sie können die Inferenzinfrastruktur auch länger auslasten als ein einzelner Prompt und eine Antwort.

Für Entwickler lautet die Frage nicht, ob jede Anwendung HBF benötigt. Sie lautet, ob künftige Inferenzsysteme eine mittlere Ebene brauchen, die teure HBM-Kapazität reduziert, ohne auf gewöhnlichen Storage zurückzufallen.

Für Unternehmenskäufer kann die Speicherarchitektur die Serverauslastung, Reaktionszeit, den Stromverbrauch und die Anzahl der Modelle beeinflussen, die in ein System passen. Diese Faktoren prägen die Betriebskosten, selbst wenn Nutzer die zugrunde liegenden Komponenten nie sehen.

Auch Wissensarbeiter haben ein indirektes Interesse. Größerer lokaler Kontext und beständigere Agenten benötigen Infrastruktur, die Arbeitsdaten effizient speichern und abrufen kann.

Eine durchsuchbare Wissensdatenbank steht auf Anwendungsebene vor einem ähnlichen Platzierungsproblem. Relevante Inhalte müssen das Modell schnell erreichen, ohne jedes Dokument in die schnellste Kontextebene zu laden.

HBF adressiert die Hardwareseite dieser umfassenderen Herausforderung. Es versucht, mehr modellbezogene Daten nah genug an der Rechenleistung zu halten, um praktische Inferenz zu ermöglichen, ohne jedes Bit als hochwertige HBM-Daten zu behandeln.

Das setzt Prozessoranbieter, Cloud-Betreiber und Speicherlieferanten unter Druck. Jede Gruppe muss entscheiden, ob eine weitere Ebene das System ausreichend verbessert, um die zusätzliche Packaging- und Softwarekomplexität zu rechtfertigen.

Die Aufmerksamkeit von Google News verbirgt den eigentlichen Wettbewerb: Spezifikation gegen Silizium

Die Spezifikation ist glaubwürdig genug, um Partner anzuziehen, doch nur funktionierendes Silizium kann beweisen, dass HBF neben KI-Prozessoren gehört.

Sandisk stellte HBF zunächst als NAND-basierte Speicherarchitektur für Inferenz vor. Der ursprüngliche Plan sah erste HBF-Samples in der zweiten Hälfte des Jahres 2026 vor.

Das Unternehmen erwartete zudem Anfang 2027 Samples der ersten Inferenzgeräte mit HBF. Diese Ziele waren in seiner Partnerschaftsmitteilung von 2025 enthalten.

Die Spezifikation vom August 2026 bestätigt nicht, dass diese Sample-Meilensteine erreicht wurden. Sie schafft den technischen Rahmen, an dem sich potenzielle Produkte orientieren sollten.

Sandisks Konzept der ersten Generation zielt auf 1,6TB/s Lesebandbreite und 512GB in einem 16-Die-Stack. Für spätere Generationen werden mehr als 2TB/s und schließlich 3,2TB/s prognostiziert.

Diese Zahlen stammen aus Sandisks eigenem technischen HBF-Briefing. Sie bleiben Unternehmensziele und keine unabhängigen Messungen aus kommerziellen Systemen.

Das Briefing besagt außerdem, dass eine simulierte HBF-Konfiguration bei einem spezifischen Test innerhalb von 2,2 Prozent eines HBM-Modells mit unbegrenzter Kapazität lag. Der Workload nutzte Acht-Bit-Gewichte des Modells Llama 3.1 405B.

Dieses Ergebnis erfordert eine sorgfältige Einordnung. Sandisk stützte es auf interne Tests und Simulationen, und der Vergleich setzte unbegrenzte HBM-Kapazität voraus. Reale Produkte werden auf endliche Kapazitäten, thermische Grenzen, Softwareverhalten und konkurrierenden Datenverkehr treffen.

NAND verhält sich zudem anders als DRAM. Es bietet Dichte und Nichtflüchtigkeit, bringt jedoch im Allgemeinen höhere Zugriffslatenzen und strengere Anforderungen an die Ausdauer mit sich.

Die größere Seitengröße von HBF kann Workloads erschweren, die kleine, verstreute Datenstücke anfordern. Das Verschieben unnötiger Bytes verbraucht Bandbreite und Energie, selbst wenn die beworbene Transferrate hoch aussieht.

Leseintensive Modellinferenz ist ein plausibler Ausgangspunkt, da sich trainierte Gewichte seltener ändern als viele andere Datenstrukturen. Schreibintensivere Einsatzbereiche würden das Ausdauermanagement stärker belasten.

Auch das Packaging stellt einen weiteren Test dar. Ein 16-Die-Stack erfordert konsistente Fertigung, thermische Kontrolle, Signalintegrität und eine akzeptable Produktionsausbeute.

Ein Design kann in der Simulation funktionieren und dennoch teuer werden, wenn es in großen Stückzahlen gefertigt wird. Fehler in einer Komponente können die Wirtschaftlichkeit eines gesamten Advanced Packages beeinträchtigen.

Die Angabe von 512 GB ist daher wichtig, doch die nutzbare Kapazität ist nur ein Teil des Produkts. Käufer werden Latenzverteilung, dauerhafte Bandbreite, Fehlerbehandlung, Temperatur, Lebensdauer und Verhalten bei gemischten Workloads prüfen.

Die drei Bandbreitenklassen werfen zudem Fragen zur Umsetzung auf. Die Spezifikation definiert Ziele, doch Anbieter müssen zeigen, welche Prozessoren und Packages jede Klasse dauerhaft unterstützen können.

UCIe bietet eine offene Schnittstellenbasis, jedoch keine Garantie dafür, dass sich jeder HBF-Stack mit jedem Beschleuniger verbinden lässt. Compliance-Programme und Referenzdesigns werden bestimmen, wie viel Interoperabilität der Markt tatsächlich erhält.

Hier kommen Google und Tenstorrent ins Spiel. Google bringt Erfahrung im Betrieb großer KI-Dienste und beim Entwurf kundenspezifischer Beschleuniger mit. Tenstorrent kann prüfen, ob die Schnittstelle über das dominante GPU-Modell hinaus funktioniert.

Ihre Mitgliedschaft im Konsortium ist ein positives Signal für die Akzeptanz. Sie ist nicht gleichbedeutend mit einer Kaufzusage, Produktankündigung oder Bereitstellung.

Das Fehlen eines namentlich genannten, ausgelieferten Prozessors bleibt die zentrale Lücke bei der Verifizierung. HBF benötigt mindestens eine Beschleunigerplattform mit Controller, Package-Design, Software-Stack und dokumentiertem Workload-Vorteil.

Ohne diese Integration droht der Standard technisch interessant, aber kommerziell randständig zu bleiben. Die Halbleiterindustrie kennt viele Spezifikationen, die nie breite Produktionsnutzung erreichten.

Sandisk und SK hynix verbessern die Erfolgsaussichten, weil sich ihre Fähigkeiten ergänzen. Sandisk steuert NAND-Design und Flash-Architektur bei, während SK hynix NAND, DRAM, HBM, Packaging und Massenproduktion abdeckt.

Ihre Partnerschaft verringert zudem den Eindruck, HBF sei lediglich ein proprietärer Versuch, einen einzelnen Anbieter zu schützen. Die Veröffentlichung über OCP lädt zu breiterer Prüfung und potenzieller Beteiligung ein.

Dennoch kann Offenheit Entscheidungen verlangsamen, wenn Unternehmen über Umsetzungsdetails uneins sind. Ein Ökosystem gewinnt Reichweite durch mehr Teilnehmer, doch Konsens und Compliance-Arbeit benötigen Zeit.

Die Spezifikation hat die erste institutionelle Hürde genommen. Als Nächstes folgen die Siliziumvalidierung, dann Systemvalidierung, Softwareunterstützung, Kundenqualifizierung und Produktionsökonomie.

Eine Schlagzeile kann die Veröffentlichung als Abschluss darstellen. Hardwaremärkte betrachten sie als Beginn eines längeren Tests.

HBF ergänzt HBM, und dieser Kompromiss definiert seinen Markt

HBF gewinnt nur, wenn zusätzliche Kapazität seine Latenz- und Integrationskosten ausgleicht, ohne die Workloads zu schwächen, die es unterstützen soll.

HBF als HBM-Ersatz zu bezeichnen, eröffnet den falschen Wettbewerb. SK hynix positioniert es ausdrücklich zwischen HBM und SSDs, wobei HBM weiterhin für die anspruchsvollste Bandbreitenklasse zuständig bleibt.

Diese Unterscheidung schützt die Architektur vor einem unrealistischen Maßstab. NAND-basiertes HBF muss DRAM nicht bei jeder Operation übertreffen. Es muss einen größeren Speicherpool bei akzeptabler Leistung nutzbar machen.

Sandisk erklärte zuvor, HBF könne bei vergleichbaren Kosten die acht- bis 16-fache Kapazität von HBM bieten. Die aktuelle offene Spezifikation ist zurückhaltender und definiert Konfigurationen sowie Leistungsklassen, statt diese wirtschaftliche Behauptung zu belegen.

Auch der Kapazitätsvergleich wird sich im Laufe der Zeit verändern. HBM-Anbieter erhöhen Stack-Kapazität und Bandbreite kontinuierlich, sodass HBF gegen eine sich wandelnde Ausgangsbasis antritt.

HBM profitiert von etablierter Beschleunigerunterstützung und Produktionsnachfrage. Prozessor-Roadmaps, Packaging-Investitionen, Speichercontroller und Softwaretools drehen sich bereits darum.

HBF startet ohne diese installierte Basis. Sein vorgeschlagener Vorteil ist die Dichte, nicht die Reife.

SSDs erzeugen Druck von der anderen Seite. Sie können eine On-Package-Speicherschicht nicht erreichen, doch Verbesserungen bei Software und Interconnects können Speicher für KI-Workloads nützlicher machen.

Systemdesigner könnten entscheiden, dass verbessertes SSD-Caching bei geringerem Integrationsrisiko ausreichende Leistung bietet. Andere könnten größere HBM-Pools für Premium-Workloads reservieren, statt eine dritte Schicht hinzuzufügen.

HBF muss diese Alternativen auf Ebene des Gesamtsystems übertreffen. Ein günstiger Preis pro Bit hilft nicht, wenn zusätzliche Controller, Package-Fläche, Kühlung oder Software die Einsparungen zunichtemachen.

Auch Energieangaben erfordern ähnliche Vorsicht. NAND speichert Informationen ohne Refresh-Leistung und besitzt damit einen strukturellen Vorteil für gespeicherte Daten.

Zum Energieverbrauch gehören jedoch auch Datenbewegung, Fehlerkorrektur, Controller und Wärmemanagement. Die relevante Kennzahl ist Energie pro abgeschlossener Inferenz, nicht die isolierte Leistungscharakteristik einer Komponente.

Die Speicherverwaltungsschicht wird entscheidend. Software muss häufig genutzte Daten erkennen, passend platzieren und verschieben, bevor der Prozessor ins Stocken gerät.

Diese Anforderung schafft Chancen für Beschleunigeranbieter und Cloud-Betreiber. Sie kontrollieren Scheduling, Compiler-Verhalten, Model Serving und Telemetrie, die die Platzierung steuern können.

Sie schafft jedoch auch Risiken einer Bindung an Anbieter. Eine offene physische Schnittstelle stellt nicht sicher, dass übergeordnete Software zwischen Prozessoren und Speicherlieferanten portabel bleibt.

Entwickler benötigen Tools, die das HBF-Verhalten sichtbar machen, ohne jedes Modellteam zur manuellen Verwaltung von Pages zu zwingen. Andernfalls könnten nur die größten Infrastrukturbetreiber konsistente Vorteile erzielen.

Die ersten attraktiven Workloads werden voraussichtlich mehrere Merkmale teilen. Sie werden leseintensiv, kapazitätsbeschränkt, gegenüber etwas zusätzlicher Latenz tolerant und wichtig genug sein, um spezialisierte Hardware zu rechtfertigen.

Das Serving großer Modelle passt zu diesem Profil. Retrieval-Systeme, Empfehlungsmodelle und einige multimodale Anwendungen könnten ebenfalls profitieren, wenn aktive Daten die praktische HBM-Kapazität übersteigen.

Nicht jede KI-Aufgabe tut das. Kleine Modelle, die problemlos in bestehenden Speicher passen, gewinnen durch eine weitere Schicht wenig. Latenzsensitive Anwendungen mit unregelmäßigen Zugriffsmustern könnten HBM trotz seiner Kapazitätsgrenzen bevorzugen.

Training ist ein schwierigerer Fall, da dabei große Datenstrukturen wiederholt gelesen und geschrieben werden. Die anfängliche HBF-Erzählung konzentriert sich aus gutem Grund auf Inferenz.

Dieser Kompromiss hält die Ankündigung auf dem Boden der Tatsachen. HBF beseitigt die Speicherhierarchie nicht. Es fügt eine weitere Ebene hinzu und verlangt von Systemdesignern, diese Hierarchie intelligenter zu verwalten.

Die breitere Strategie von SK hynix unterstreicht diese Sichtweise. Das Unternehmen bewirbt ein Portfolio, das HBM, herkömmliches DRAM, NAND, Enterprise-SSDs und neue Speicherschichten umfasst.

Dieses Portfolio kann den internen Wettbewerb zwischen HBM und HBF verringern. SK hynix kann jede von Kunden gewählte Kombination unterstützen, auch wenn die Wirtschaftlichkeit einzelner Produkte seine Prioritäten weiterhin beeinflussen wird.

Sandisk hat einen anderen Anreiz. Seine Konzentration auf Flash macht KI-Inferenz zu einer Chance, NAND näher an hochwertige Rechenleistung zu bringen.

Die Partnerschaft richtet diese Anreize auf einen gemeinsamen Standard aus. Sie beseitigt jedoch nicht den Wettbewerb durch Samsung, Micron, Kioxia, Prozessoranbieter oder alternative Speicherarchitekturen.

Die Beteiligung von Wettbewerbern würde HBF als Branchenkategorie stärken. Sie könnte jedoch auch die Fähigkeit von Sandisk und SK hynix schwächen, ihre Produkte zu differenzieren.

Das ist eine gesunde Spannung für einen offenen Standard. Breite Akzeptanz verlangt gewöhnlich, dass Anbieter etwas Kontrolle gegen einen größeren Markt eintauschen.

Drei Signale werden zeigen, ob HBF über die Schlagzeile hinauskommt

Die nächsten Belege müssen aus Samples, Prozessorzusagen und gemessenen Workloads stammen, nicht aus einer weiteren Spezifikationspräsentation.

Das erste Signal ist funktionierendes HBF-Silizium, das an die neue Spezifikation gebunden ist. Sandisks frühere Roadmap sah erste Samples für die zweite Hälfte des Jahres 2026 vor, wodurch nur ein begrenztes Zeitfenster für die Umsetzung bleibt.

Eine aussagekräftige Sample-Ankündigung sollte Kapazität, Bandbreitenklasse, Package-Konfiguration und Teststatus nennen. Sie sollte zudem zwischen internen Engineering-Samples und für Kunden verfügbarer Hardware unterscheiden.

Unabhängige Tests oder Kundentests würden den Fall weiter stärken. Gemessene Latenz, dauerhafte Bandbreite, Leistungsaufnahme, Ausdauer und Temperatur sind wichtiger als eine Spitzenübertragungsrate.

Erscheinen konforme Samples planmäßig, gewinnt die Spezifikation als Produktbasis an Glaubwürdigkeit. Eine Verzögerung würde darauf hindeuten, dass Packaging, NAND-Verhalten, Controller oder Fertigung noch ungelöst sind.

Das zweite Signal ist ein namentlich genannter Prozessor oder eine Cloud-Plattform. Google und Tenstorrent nehmen am Konsortium teil, doch weder Teilnahme noch Auftritte in Diskussionsrunden bestätigen eine kommerzielle Einführung.

Eine ernsthafte Zusage würde HBF mit einer Prozessor-Roadmap, einem Referenz-Package, Entwicklungsboard oder einer Cloud-Bereitstellung verbinden. Sie würde zudem aufzeigen, wie Software Daten zwischen HBM und HBF zuweist.

Achten Sie neben der Hardware auf Controller-Unterstützung und Entwicklertools. Ein Speichergerät ohne Software für Scheduling, Profiling und Platzierung kann seinen vollen Systemvorteil nicht liefern.

Eine fest zugesagte Plattform würde keinen Industriestandard garantieren. Sie würde belegen, dass ein Prozessordesigner genügend Wert erkennt, um die Integrationskosten zu tragen.

Mehrere Prozessor- oder Cloud-Teilnehmer würden die These des offenen Ökosystems stützen. Eine einzelne proprietäre Implementierung würde die Rolle von HBF einengen und die Abhängigkeit von einem Kunden erhöhen.

Das dritte Signal sind Workload-Belege unter realistischen Einschränkungen. Sandisks Simulation bietet eine Ausgangshypothese, doch Produktionssysteme müssen mit endlichem HBM, gemischten Anfragen, thermischen Grenzen und wechselnden Zugriffsmustern umgehen.

Benchmarks sollten vollständige Konfigurationen vergleichen, nicht isolierte Komponenten. Ein HBF-System muss Durchsatz, Latenz, Energie und Kosten gegenüber größeren HBM-Pools oder SSD-gestützten Alternativen nachweisen.

Die aussagekräftigsten Tests werden die Inferenz großer Modelle mit mehreren gleichzeitigen Nutzern abdecken. Sie sollten außerdem Modellpräzision, Batch-Größe, Kontextlänge, Caching-Richtlinie und Prozessorauslastung erläutern.

Ein vorteilhaftes Ergebnis würde zeigen, dass HBF teure Recheneinheiten ausgelastet hält und gleichzeitig größere aktive Modelle unterstützt. Es würde das Argument für gestuften Speicher stärken, wenn die Inferenz skaliert.

Schwache Ergebnisse würden die Kosten von NAND-Latenz oder Datenbewegung offenlegen. Sie könnten HBF auf engere Anwendungsfälle beschränken, bei denen Kapazität wichtiger ist als Reaktionszeit.

Die Veröffentlichung der Spezifikation über OCP gibt Forschern und potenziellen Anwendern eine gemeinsame Grundlage für diese Bewertungen. Der Start des offenen Workstreams zeigt zudem, dass die Unternehmen ein Ökosystem gewinnen wollen, statt HBF geschlossen zu halten.

Leser, die die Geschichte über Google News verfolgen, sollten jeden künftigen Meilenstein voneinander trennen. Ein Konsortiumsmitglied, ein Sample, ein integriertes Gerät und eine Produktionsbereitstellung stellen sehr unterschiedliche Evidenzniveaus dar.

Sandisk und SK hynix haben die erste dieser Stufen abgeschlossen. Sie haben eine offene Architektur mit klaren Zielen für Kapazität, Bandbreite, Schnittstelle, Packaging und Software definiert.

Nun verlagert sich die Last vom Standarddokument auf die Engineering-Teams. Sie müssen zeigen, dass HBF zuverlässig gefertigt, prozessorübergreifend angebunden und verwaltet werden kann, ohne einen teuren neuen Engpass zu schaffen.

Dieses Ergebnis ist über zwei Speicherunternehmen hinaus wichtig. Erfolgreiche HBF-Hardware würde KI-Systemdesignern eine weitere Möglichkeit geben, Kapazität, Bandbreite, Energie und Kosten auszubalancieren.

Auch ein Scheitern würde eine nützliche Lehre bieten. Es würde zeigen, dass die Lücke zwischen HBM und SSDs nicht allein dadurch geschlossen werden kann, dass dichtes NAND näher an die Rechenleistung gepackt wird.

Die nächste Google News-Schlagzeile, die sich zu öffnen lohnt, sollte daher mehr als eine weitere Partnerschaft enthalten. Achten Sie auf messbares Silizium, einen namentlich genannten Prozessor und ein Workload-Ergebnis, das eine andere Organisation prüfen kann.

Bis diese Signale eintreffen, ist HBF ein ungewöhnlich detaillierter Vorschlag mit glaubwürdigen Unterstützern. Es ist noch keine bewährte Schicht in produktiver KI-Infrastruktur.

Verfolgen Sie Samples, Integrationen und Benchmarks statt der Zahl der Ankündigungen. Welcher Prozessoranbieter wird als Erster zeigen, dass offenes HBF ein reales Inferenzsystem verbessern kann?