High Bandwidth Flash (HBF) probeert een nieuw segment te veroveren in de wereld van AI-accelerators: een geheugen met veel grotere capaciteit dan HBM en aanzienlijk breder bandbreedte dan conventioneel NAND-opslag. Een analyse gepresenteerd door OXMIQ Labs op Hot Chips 2026 laat echter zien dat deze combinatie zijn beperkingen kent. HBF kan erg aantrekkelijk zijn wanneer het doel is om een enorm model dicht bij de processor te plaatsen, maar verliest veel van zijn voordelen wanneer de lading voortdurend data op hoge snelheid moet verplaatsen.
De kernpunten van High Bandwidth Flash in 20 seconden
- HBF gebruikt gestapelde NAND om honderden gigabytes capaciteit dicht bij AI-accelerators te brengen.
- De specificatie voorziet in tot 512 GB per stapel en ongeveer 3 TB/s bandbreedte op het meest geavanceerde niveau.
- Volgens de makers kan het tussen 8 en 16 keer meer capaciteit bieden dan HBM, tegen vergelijkbare kosten.
- OXMIQ waarschuwt dat HBM nog steeds superieur blijft wanneer bandbreedte bepalend is voor prestaties.
- Veelbelovende toepassingen omvatten MoE-modellen en zeer lange contexten.
De technologie bevindt zich nog in de beginfase. Sandisk en SK hynix publiceerden begin augustus de eerste technische specificatie van HBF via het Open Compute Project (OCP), slechts zes maanden na de formele start van de standaardisatie. Google en Tenstorrent zijn ook lid van de groep en hebben bijgedragen aan de validatie van de technologie.
Het concept van HBF is eenvoudig: AI vereist steeds meer geheugen, en hoewel HBM extreem snel is, is het ook duur en beperkt in capaciteit. NAND biedt veel capaciteit tegen lagere kosten, maar was traditioneel te traag om direct samen met een GPU te werken.
HBF probeert een tussenoplossing te bouwen.
Tussen HBM en een SSD, maar met een andere architectuur
High Bandwidth Flash gebruikt 3D NAND-geheugen dat in stapels is georganiseerd en verbonden via grote bandbreedte-interfaces.
De eerste specificatie beschrijft drie prestatieniveaus.
Het zogenaamde Grade 1 begint met een stapel van 256 GB en levert ongeveer 384 GB/s. Grade 2 verhoogt de capaciteit tot 512 GB en de bandbreedte tot ongeveer 1.536 TB/s.
Grade 3 behoudt 512 GB maar bereikt ongeveer 3,072 TB/s door gebruik te maken van UCIe 2.0 op 32 GT/s.
| Technologie | Capaciteit | Bandbreedte | Sterke punt |
|---|---|---|---|
| HBM | Decennia van GB per stapel | Zeer hoog | Voortdurend GPU/AI voeden |
| HBF Grade 1 | 256 GB | 384 GB/s | Capaciteit |
| HBF Grade 2 | 512 GB | 1.536 TB/s | Balans capaciteit/bandbreedte |
| HBF Grade 3 | 512 GB | 3.072 TB/s | Benadert HBM-prestaties |
| SSD NVMe | Meerdere TB | Veel lager | Capaciteit en persistentie |
De cijfers maken duidelijk waarom HBF zoveel interesse krijgt.
Een accelerator kan meerdere terabytes aan lokaal geheugen hebben zonder dat er hetzelfde volume HBM nodig is.
Sandisk beweert dat HBF 8 tot 16 keer meer capaciteit kan bieden dan HBM tegen vergelijkbare kosten. Dit is een inschatting van het bedrijf, afhankelijk van hoe zich de commerciële producten ontwikkelen, maar geeft een goede samenvatting: HBF is vooral gericht op capaciteit, niet slechts op goedkoop HBM.
En dat verschil is cruciaal.
14 keer meer geheugen betekent niet 14 keer sneller verwerken
OXMIQ Labs heeft op Hot Chips onderzocht wat er gebeurt wanneer HBF geconfronteerd wordt met een reële AI-belasting.
Een van hun modellen simuleert een rack met 72 accelerators die Kimi K2 draaien, een MoE-model met ongeveer een biljoen parameters.
Bij gelijkaardige kosten en vermogen levert een configuratie met alleen HBM circa 20,7 TB capaciteit en 1.584 TB/s totale bandbreedte.
Vervangt men HBM door HBF, dan groeit de capaciteit tot ongeveer 294,9 TB, ongeveer 14 keer zo veel.
Het probleem is dat de totale bandbreedte afneemt tot ongeveer 922 TB/s.
Deze tegenstelling illustreert het dilemma perfect.
Als het belangrijkste is om een model in geheugen te passen, dan biedt HBF een enorme voordeel.
Wanneer het model al past en het doel is om de maximale tokens per seconde te genereren, dan kan HBM uiteindelijk efficiënter zijn.
In het voorbeeld van OXMIQ zou de enorme capaciteit van HBF toelaten dat elke accelerator een volledige kopie van het model houdt en tot 72 instanties per rack draait.
Een HBM-setup zou daarvoor acht accelerators nodig hebben om elke kopie te kunnen bevatten, wat het aantal gelijktijdige instanties beperkt.
Maar zodra het aantal gelijktijdige gebruikers toeneemt en elke GPU voortdurend toegang nodig heeft tot grote hoeveelheden data, wordt bandbreedte doorgaans leidend voor de prestaties.
In dat scenario wint HBM weer terrein.
Daarom de kost per gigabyte is niet noodzakelijk gelijk aan de kost per token.
MoE-modellen zijn een van de meest interessante toepassingen
HBF kan vooral relevant zijn voor MoE-modellen.
Deze modellen bevatten meerdere gespecialiseerde parameter-groepen, ‘experts’, maar niet voor elke token worden alle experts gebruikt.
Het systeem selecteert enkel bepaalde experts op basis van de input waar het mee werkt.
Dit creëert een interessante geheugenstructuur: het model kan een enorme hoeveelheid parameters bevatten, waarvan veel inactief blijven op elk moment.
OXMIQ gaf als voorbeeld een model met ongeveer 1,56 TB aan gewichten, waarvan circa 1,45 TB (93%) toebehoorde aan experts in MoE.
Het opslaan van al deze parameters in HBM zou kostbaar zijn.
HBF maakt het mogelijk om veel van die parameters dicht bij de accelerator te houden, terwijl HBM wordt gereserveerd voor data die snel toegang vereisen.
De architectuur kan conceptueel lijken op een hiërarchie:
HBM voor ‘hot’ data, HBF voor grote minder gebruikte sets, en SSD of remote storage voor nog koudere data.
Het verschil met een traditionele SSD is dat HBF veel dichter bij de processor ligt en veel meer bandbreedte kan leveren.
Minder verkeer tussen GPU’s kan een minder snel geheugen compenseren
Een ander voordeel kan er zijn.
Grote MoE-modellen verspreiden vaak experts over meerdere accelerators.
Wanneer een token extra expertise nodig heeft die op een andere GPU zit, moeten systemen data uitwisselen via de onderlinge verbindingen.
Op grote schaal kunnen all-to-all communicatieprocessen veel bandbreedte en energie verbruiken.
Met meerdere terabytes HBF dicht bij elk accelerator kan een veel groter deel van de experts lokaal worden opgeslagen.
Dit kan de noodzaak verminderen om experts over meerdere GPU’s te verdelen en de communicatiekening verlagen.
In dat geval wisselt HBF minder capaciteit uit, en is de uitwisseling tussen geheugen en netwerk minder belangrijk: minder geheugenbandbreedte wordt ingewisseld voor meer lokale capaciteit en minder afhankelijkheid van het netwerk.
Maar het is niet altijd zo simpel.
Wanneer de batchgrootte toeneemt en er veel verschillende aanvragen tegelijk binnenkomen, wordt de systematiek complexer.
Dan moeten systemen een groter deel van de experts gelijktijdig kunnen aanspreken, waardoor de ‘koude’ data weer ‘warm’ wordt.
Als de gegevens constant verplaatst worden van HBF naar HBM, begint de lagere snelheid van NAND een beperkende factor te worden voor de prestaties.
Gigantische contexten bieden een andere kans
Een tweede interessant scenario is inferentie met zeer lange contexten.
Taalmodellen gebruiken een structuur genaamd KV-cache om informatie van reeds verwerkte tokens te bewaren, zodat die niet opnieuw berekend hoeft te worden.
Wanneer de context honderdduizenden of miljoenen tokens omvat, kan deze cache enorme hoeveelheden geheugen vereisen.
Sommige attention-architecturen hoeven niet elk stuk inhoud te raadplegen bij elke generatie stap.
Een grote KV-cache kan dan in HBF blijven, terwijl alleen de benodigde blokken op dat moment worden overgebracht naar HBM.
De kern van de gedachte blijft hetzelfde: HBF werkt het best wanneer een applicatie extreeme nabijheid van grote hoeveelheden informatie vereist, maar slechts een kleine deel ervan tegelijkertijd gebruikt.
Als het grootste deel van de data constant gelezen moet worden, is HBM geschikter.
NAND brengt ook beperkingen die HBM niet kent
Daarnaast is er een fysieke beperking: het verhogen van bandbreedte helpt niet altijd.
HBF blijft gebruik maken van NAND Flash-geheugen.
Dat betekent dat de operaties niet hetzelfde are als bij DRAM.
De specificatie voorziet in lezen en schrijven in grote blokken, en voor maximale prestaties zijn grote overdrachten nodig. OXMIQ wijst er ook op dat data doorgaans via DMA worden overgedragen, niet via directe hiërarchieën zoals cache van CPU of GPU.
Ook de levensduur is een factor: NAND heeft een gelimiteerd aantal write-cycli.
Systemen moeten het gebruik van cellen monitoren om vroegtijdige slijtage te voorkomen.
HBF is vooral geschikt voor data die zelden wordt geschreven en herhaaldelijk wordt gelezen, zoals modelgewichten.
Voor toepassingen met frequente schrijfbelastingen is HBF minder aantrekkelijk.
De grootste uitdaging ligt mogelijk in de software
Het ontwerpen van hardware is slechts een deel van de uitdaging.
De huidige inferentierammen zijn vooral ontworpen met DRAM en HBM in gedachten.
Een hybride systeem moet continu bepalen welke data op HBM blijft, welke naar HBF kan gaan en wanneer het terug moet.
Het vereist bovendien anticipatie: wacht niet tot een GPU een data nodig heeft, maar prefetch die al voordat het wordt aangesproken.
OXMIQ benadrukt dat platformen zoals vLLM speciaal ondersteuning voor HBF nodig zullen hebben, inclusief geheugenallocators, plaatsingsbeleid, preload-mechanismen en monitoring van NAND-slijtage.
Ook hardware- en softwareleveranciers, zoals AMD en NVIDIA, zullen functies en drivers moeten ontwikkelen die efficiënt dataverkeer tussen HBM en HBF mogelijk maken.
Hoewel de technologische concepten nu bestaan, vereist het opzetten van een ecosysteem dat ze optimaal benut een grote inspanning.
HBF is niet bedoeld om HBM te vervangen
De eerste open specificatie van HBF helpt tevens misverstanden uit de wereld te helpen: het is niet bedoeld als complete vervanging van HBM.
Sandisk begon in 2025 openlijk te praten over High Bandwidth Flash, vooral als antwoord op de toenemende geheugenbehoefte van AI-systemen.
Sindsdien is de voorstellen geëvolueerd.
Sandisk en SK hynix richtten in februari 2026 een werkgroep binnen het Open Compute Project op en publiceerden in augustus de eerste technische specificatie. Google en Tenstorrent doen ook mee.
De voorlopige architectuur wijst erop dat HBF niet HBM volledig zal vervangen, maar eerder een nieuwe laag binnen de geheugenhiërarchie van accelerators wordt.
HBM blijft verantwoordelijk voor data die maximale bandbreedte vereisen.
HBF zou tientallen gigabytes tot meerdere terabytes kunnen opslaan die dicht bij de processor moeten blijven, maar niet voortdurend worden aangesproken.
En SSD’s blijven nog steeds het goedkoopst voor extreem grote opslag met hogere latentie.
De uiteindelijke toepassing hangt af van de modellen. Een compact model dat met grote batches draait ha benefit mogelijk niet van HBF. Een gigantisch MoE-model met veel inactieve parameters kan daarentegen wel baat bij hebben.
De conclusie van OXMIQ op Hot Chips is dus zeer passend: HBF is een gespecialiseerde tool, geen universele oplossing voor AI-geheugenproblemen.
Indien hardware, drivers en inferentieroutines zich ontwikkelen, kan High Bandwidth Flash een belangrijke plek innemen tussen HBM en SSD’s.
Maar het succes ervan hangt niet zozeer af van het kunnen vervangen van HBM, maar van het identificeren van workloads waarbij enorme capaciteit dicht bij de accelerator belangrijker is dan maximale data-snelheid.
Veelgestelde vragen
Wat is High Bandwidth Flash of HBF?
HBF is een technologie gebaseerd op NAND Flash, ontworpen om veel grotere capaciteit en bandbreedte te bieden dan conventionele flashopslag en dicht bij AI-accelerators te plaatsen.
Kan HBF HBM vervangen?
Niet in alle workloads. HBM blijft ideaal wanneer het draait om constante toegang tot grote hoeveelheden data. HBF wordt relevanter wanneer capaciteit het belangrijkste is.
Hoeveel capaciteit kan HBF bieden?
De eerste specificatie voorziet in stacks tot 512 GB. Door meerdere stacks te combineren, kunnen systemen met meerdere terabytes aan geheugencapaciteit dicht bij de processor worden gerealiseerd.
Wanneer zien we HBF in commerciële systemen?
De open specificatie werd in augustus 2026 gepubliceerd en de technologie wordt verder ontwikkeld. De adoptie hangt af van ondersteuning door hardwarefabrikanten en het software-ecosysteem wereldwijd.