HBF (High Bandwidth Flash) is een technologie die flashgeheugen integreert nabij de compute-chip, vergelijkbaar met de vormfactor van HBM, om de enorme capaciteitsvraag van machine learning-workloads tegen lagere kosten op te vangen.
De belangrijkste punten uit het artikel zijn:
- Werking: HBF functioneert niet als traditioneel systeemgeheugen, maar als een geïntegreerde SSD. Gegevens moeten via DMA in grote, uitgelijnde blokken worden verplaatst, waarbij de software ook controllerfuncties zoals write leveling moet beheren.
- Toepassingen: Potentiële use-cases zijn het opslaan van Mixture-of-Experts (MoE) experts, het plaatsen van de KV-cache bij sparse attention, en het verminderen van cross-device communicatie door modelgewichten vaker te repliceren over GPU's.
- Kosten: HBF is zeer kostenefficiënt per gigabyte capaciteit, maar presteert slechter op kosten per bandbreedte in vergelijking met HBM. Het is vooral zinvol bij workloads die niet bandbreedtebeperkt zijn.
- Software-uitdagingen: De overstap naar HBF vereist fundamentele wijzigingen in softwareframeworks, omdat toegang op byte-niveau onmogelijk is en men moet werken met low-level block storage API's.
Hot Chips 2026: Toepassing van High Bandwidth Flash (HBF)
Wat is High Bandwidth Flash (HBF)?
HBF, of High Bandwidth Flash, maakt gebruik van dezelfde flashgeheugentechnologie die we vandaag de dag in SSD's zien. In tegenstelling tot SSD's is HBF echter geïmplementeerd op een manier die sterk lijkt op HBM (High Bandwidth Memory). HBF-cubes bevinden zich op hetzelfde pakket als de compute-chip, mogelijk zelfs direct naast het HBM.
Het idee achter HBF is om een veel hogere capaciteit te bieden dan HBM, terwijl er nog steeds een redelijke geheugenbandbreedte behouden blijft. Tijdens de tutorials-dag van Hot Chips 2026 verkenden Anurag Agarwal en Radhakrishna Giduthuri hoe HBF toegepast zou kunnen worden op machine learning-workloads. Omdat er momenteel nog geen HBF-producten bestaan, richtte de presentatie zich op simulaties, projecties en de manier waarop software kan worden aangepast om gebruik te maken van HBF.
Hoge capaciteit en grove toegangseenheden
Hoewel HBF een vormfactor heeft die lijkt op HBM, is de interne werking volledig anders. Het is niet vergelijkbaar met Intel's Optane, dat kon functioneren als een extra pool van geheugen. In plaats daarvan is HBF bijna als een SSD die is geïntegreerd in een processor.
Software gebruikt DMA (Direct Memory Access) om gegevens tussen HBF en DRAM te verplaatsen. Toegang tot HBF moet gebeuren in grote, uitgelijnde blokken (aligned chunks), alsof het een massageheugentoestel is en niet het systeemgeheugen. Hostsoftware moet bovendien SSD-controllerfuncties overnemen, zoals het beheren van write leveling en het garanderen van dataretentie. Dit betekent dat HBF geen plug-and-play-oplossing is.
Implementatiestrategieën en vLLM
Om gebruik te maken van HBF is een specifieke strategie nodig die in de runtime moet worden geïmplementeerd. Giduthuri noemt vLLM als voorbeeld. vLLM bewaart modelgewichten doorgaans in het GPU-geheugen en onderzoekt al opties om het VRAM-gebruik te verminderen. Zo kijkt vLLM naar het plaatsen van modelgewichten in 'pinned' CPU-geheugen, mits de host voldoende vrij geheugen heeft. Voor HBF zou dit echter niet werken, omdat HBF geen fijnmazige willekeurige toegang (fine-grained random access) ondersteunt.
Andere opties zijn wel veelbelovend:
- MoE-experts: Experts van Mixture-of-Experts (MoE) kunnen in HBF worden opgeslagen. Software kan vervolgens de actieve experts via DMA naar het HBM verplaatsen wanneer dat nodig is.
- KV-cache: De KV-cache van vLLM kan ook in HBF worden geplaatst. Dit werkt echter waarschijnlijk alleen bij een sparse attention-implementatie die per stap slechts een subset van tokens van de KV-cache leest. Hierdoor kan het grootste deel van de KV-cache "koud" in het flashgeheugen blijven staan, wat profiteert van de capaciteit van HBF zonder de lagere bandbreedte te zwaar te belasten. Een mogelijk knelpunt is dat de top-k leesacties verspreid zijn, terwijl HBF de voorkeur geeft aan sequentiële leesacties. Software zou dit kunnen oplossen door de top-k rijen via DMA naar het DRAM te verplaatsen.
Vermindering van cross-device communicatie
Een andere mogelijkheid is om de capaciteit van HBF te gebruiken om communicatie tussen verschillende apparaten te verminderen. Grote modellen worden vaak verdeeld (sharded) over meerdere GPU's, waardoor de prestaties beperkt worden door scatter en gather-operaties tussen deze apparaten. Deze communicatie kan een grotere prestatiebarrière vormen dan de rekenkracht of de geheugenbandbreedte.
HBF kan dit verzachten door meer van de modelgewichten te repliceren over verschillende GPU's. Hoewel het via DMA ophalen van gegevens uit flashgeheugen niet goedkoop is, is het goedkoper dan communicatie tussen verschillende apparaten.
Kostenoverwegingen
Agarwal besprak wanneer HBF vanuit een kostenperspectief zinvol is. In essentie is HBF gunstig als een workload zijn bandbreedtelimieten niet bereikt. Dit is het geval bij kleinere modellen en/of kleinere batchgroottes. Als een workload bandbreedtebeperkt wordt, verslechtert de kostenberekening, omdat zowel de kosten per capaciteit als de kosten per bandbreedte meetellen in de uiteindelijke prijs. HBF is uitstekend wat betreft kosten per capaciteit, maar scoort slechter op kosten per bandbreedte in vergelijking met HBM.
Er werd ook gesproken over het gebruik van HBM om "hot experts" te cachen, maar dat lijkt een lastige oplossing. Caching moet zeer efficiënt werken, anders kan de bandbreedte van HBF de kosten per token negatief beïnvloeden.
Software-uitdagingen en conclusie
HBF kan het probleem van de DRAM-capaciteit tot op zekere hoogte verlichten, maar de softwarematige uitdagingen lijken enorm. Werken met HBF lijkt sterk op het gebruik van een low-level disk access API, zoals FILEFLAGNOBUFFERING in Windows of ODIRECT in Linux. Software moet toegang krijgen via grote, uitgelijnde blokken in plaats van het geheugen vrij aan te spreken op byte-niveau.
Het wijzigen van een enkele byte kan betekenen dat er een groot blok van 64 KB naar het DRAM moet worden gelezen, dat blok moet worden gewijzigd, en het volledige blok vervolgens weer naar het flashgeheugen moet worden geschreven. Dit lijkt meer op werken met een block storage device dan met geheugen. Een softwareframework dat is ontworpen voor een regulier DRAM-gebaseerd systeem zal ingrijpende wijzigingen nodig hebben om HBF effectief te kunnen gebruiken.
Men zou kunnen stellen dat de inspanning die nodig is om HBF te benutten, niet veel verschilt van wat nodig zou zijn om het DRAM-gebruik direct te verminderen door modelgewichten vanaf een SSD te streamen. Het gebruik van een SSD lijkt zelfs eenvoudiger; de OS-kernel kan de complexiteit van blok-uitgelijnde toegangen abstraheren als men geen gebruik maakt van FILEFLAGNOBUFFERING of ODIRECT. Buffering in de kernel stelt software in staat om willekeurig te zoeken en lees/schrijfoperaties op byte-niveau uit te voeren, terwijl het tegelijkertijd fungeert als een cache die software isoleert van de inefficiënties van flashgeheugen.
Hoewel dit niet in de presentatie werd genoemd, is het de vraag of bestaande pogingen om modelgewichten vanaf SSD's te streamen kunnen worden toegepast op HBF, of dat de software-uitdagingen zo groot zijn dat adoptie wordt tegengehouden.
Hot Chips 2026: Toepassing van High Bandwidth Flash (HBF)
Wat is High Bandwidth Flash (HBF)?
HBF, of High Bandwidth Flash, maakt gebruik van dezelfde flashgeheugentechnologie die we vandaag de dag in SSD's zien. In tegenstelling tot SSD's is HBF echter geïmplementeerd op een manier die sterk lijkt op HBM (High Bandwidth Memory). HBF-cubes bevinden zich op hetzelfde pakket als de compute-chip, mogelijk zelfs direct naast het HBM.
Het idee achter HBF is om een veel hogere capaciteit te bieden dan HBM, terwijl er nog steeds een redelijke geheugenbandbreedte behouden blijft. Tijdens de tutorials-dag van Hot Chips 2026 verkenden Anurag Agarwal en Radhakrishna Giduthuri hoe HBF toegepast zou kunnen worden op machine learning-workloads. Omdat er momenteel nog geen HBF-producten bestaan, richtte de presentatie zich op simulaties, projecties en de manier waarop software kan worden aangepast om gebruik te maken van HBF.
Hoge capaciteit en grove toegangseenheden
Hoewel HBF een vormfactor heeft die lijkt op HBM, is de interne werking volledig anders. Het is niet vergelijkbaar met Intel's Optane, dat kon functioneren als een extra pool van geheugen. In plaats daarvan is HBF bijna als een SSD die is geïntegreerd in een processor.
Software gebruikt DMA (Direct Memory Access) om gegevens tussen HBF en DRAM te verplaatsen. Toegang tot HBF moet gebeuren in grote, uitgelijnde blokken (aligned chunks), alsof het een massageheugentoestel is en niet het systeemgeheugen. Hostsoftware moet bovendien SSD-controllerfuncties overnemen, zoals het beheren van write leveling en het garanderen van dataretentie. Dit betekent dat HBF geen plug-and-play-oplossing is.
Implementatiestrategieën en vLLM
Om gebruik te maken van HBF is een specifieke strategie nodig die in de runtime moet worden geïmplementeerd. Giduthuri noemt vLLM als voorbeeld. vLLM bewaart modelgewichten doorgaans in het GPU-geheugen en onderzoekt al opties om het VRAM-gebruik te verminderen. Zo kijkt vLLM naar het plaatsen van modelgewichten in 'pinned' CPU-geheugen, mits de host voldoende vrij geheugen heeft. Voor HBF zou dit echter niet werken, omdat HBF geen fijnmazige willekeurige toegang (fine-grained random access) ondersteunt.
Andere opties zijn wel veelbelovend:
- MoE-experts: Experts van Mixture-of-Experts (MoE) kunnen in HBF worden opgeslagen. Software kan vervolgens de actieve experts via DMA naar het HBM verplaatsen wanneer dat nodig is.
- KV-cache: De KV-cache van vLLM kan ook in HBF worden geplaatst. Dit werkt echter waarschijnlijk alleen bij een sparse attention-implementatie die per stap slechts een subset van tokens van de KV-cache leest. Hierdoor kan het grootste deel van de KV-cache "koud" in het flashgeheugen blijven staan, wat profiteert van de capaciteit van HBF zonder de lagere bandbreedte te zwaar te belasten. Een mogelijk knelpunt is dat de top-k leesacties verspreid zijn, terwijl HBF de voorkeur geeft aan sequentiële leesacties. Software zou dit kunnen oplossen door de top-k rijen via DMA naar het DRAM te verplaatsen.
Vermindering van cross-device communicatie
Een andere mogelijkheid is om de capaciteit van HBF te gebruiken om communicatie tussen verschillende apparaten te verminderen. Grote modellen worden vaak verdeeld (sharded) over meerdere GPU's, waardoor de prestaties beperkt worden door scatter en gather-operaties tussen deze apparaten. Deze communicatie kan een grotere prestatiebarrière vormen dan de rekenkracht of de geheugenbandbreedte.
HBF kan dit verzachten door meer van de modelgewichten te repliceren over verschillende GPU's. Hoewel het via DMA ophalen van gegevens uit flashgeheugen niet goedkoop is, is het goedkoper dan communicatie tussen verschillende apparaten.
Kostenoverwegingen
Agarwal besprak wanneer HBF vanuit een kostenperspectief zinvol is. In essentie is HBF gunstig als een workload zijn bandbreedtelimieten niet bereikt. Dit is het geval bij kleinere modellen en/of kleinere batchgroottes. Als een workload bandbreedtebeperkt wordt, verslechtert de kostenberekening, omdat zowel de kosten per capaciteit als de kosten per bandbreedte meetellen in de uiteindelijke prijs. HBF is uitstekend wat betreft kosten per capaciteit, maar scoort slechter op kosten per bandbreedte in vergelijking met HBM.
Er werd ook gesproken over het gebruik van HBM om "hot experts" te cachen, maar dat lijkt een lastige oplossing. Caching moet zeer efficiënt werken, anders kan de bandbreedte van HBF de kosten per token negatief beïnvloeden.
Software-uitdagingen en conclusie
HBF kan het probleem van de DRAM-capaciteit tot op zekere hoogte verlichten, maar de softwarematige uitdagingen lijken enorm. Werken met HBF lijkt sterk op het gebruik van een low-level disk access API, zoals FILEFLAGNOBUFFERING in Windows of ODIRECT in Linux. Software moet toegang krijgen via grote, uitgelijnde blokken in plaats van het geheugen vrij aan te spreken op byte-niveau.
Het wijzigen van een enkele byte kan betekenen dat er een groot blok van 64 KB naar het DRAM moet worden gelezen, dat blok moet worden gewijzigd, en het volledige blok vervolgens weer naar het flashgeheugen moet worden geschreven. Dit lijkt meer op werken met een block storage device dan met geheugen. Een softwareframework dat is ontworpen voor een regulier DRAM-gebaseerd systeem zal ingrijpende wijzigingen nodig hebben om HBF effectief te kunnen gebruiken.
Men zou kunnen stellen dat de inspanning die nodig is om HBF te benutten, niet veel verschilt van wat nodig zou zijn om het DRAM-gebruik direct te verminderen door modelgewichten vanaf een SSD te streamen. Het gebruik van een SSD lijkt zelfs eenvoudiger; de OS-kernel kan de complexiteit van blok-uitgelijnde toegangen abstraheren als men geen gebruik maakt van FILEFLAGNOBUFFERING of ODIRECT. Buffering in de kernel stelt software in staat om willekeurig te zoeken en lees/schrijfoperaties op byte-niveau uit te voeren, terwijl het tegelijkertijd fungeert als een cache die software isoleert van de inefficiënties van flashgeheugen.
Hoewel dit niet in de presentatie werd genoemd, is het de vraag of bestaande pogingen om modelgewichten vanaf SSD's te streamen kunnen worden toegepast op HBF, of dat de software-uitdagingen zo groot zijn dat adoptie wordt tegengehouden.
Groetjes,