'Eerste HBM3E-chips van Samsung doorstaan Nvidia-tests voor gebruik in AI-gpu's'

De eerste Samsungs HBM3E-chips zijn hebben de validatietests van Nvidia doorstaan, melden ingewijden aan Reuters. Die geheugenmodules mogen daarmee gebruikt worden in de AI-chips van Nvidia. Samsung zou vanaf eind dit jaar het geheugen gaan leveren aan de chipmaker.

Bronnen vertellen aan Reuters dat Nvidia specifiek de 8-laagse HBM3E-chips van Samsung heeft goedgekeurd voor algemeen gebruik. De varianten met twaalf lagen, die een hogere capaciteit en bandbreedte bieden, zijn nog niet door de tests heen. Samsung en Nvidia hebben nog geen leveringsovereenkomst gesloten, maar zullen dat volgens de bronnen binnenkort doen. Naar verwachting begint Samsung dan in het laatste kwartaal van dit jaar met het leveren van HBM3E aan Nvidia. De twee bedrijven hebben niet gereageerd.

Eerder meldde het persbureau al dat Nvidia de reguliere HBM3-chips van Samsung heeft goedgekeurd, hoewel dat alleen gold voor chips voor de Chinese markt, die door Amerikaanse exportrestricties minder krachtig zijn dan de geavanceerdste AI-chips van het bedrijf.

Samsung probeerde volgens Reuters al sinds vorig jaar aan de eisen van Nvidia te voldoen, maar had daar volgens het persbureau moeite mee vanwege problemen met hitte en stroomgebruik. De Zuid-Koreaanse geheugenfabrikant zei toen dat dat niet waar was en dat het testen 'voorspoedig' verliep. Samsung zou inmiddels wel zijn HBM3E-ontwerp hebben bijgewerkt om die problemen aan te pakken, stelt Reuters op basis van ingewijden.

HBM, ook wel High Bandwidth Memory, is een geheugentype dat vooral wordt gebruikt in videokaarten. Het geheugen heeft een relatief hoge bandbreedte en wordt tegenwoordig vooral ingezet in datacenters. Het 8-laagse HBM3E-geheugen van Samsung biedt bijvoorbeeld snelheden van 8Gbit/s per pin, wat neerkomt op ongeveer 1,02TB/s per module. De varianten met twaalf lagen halen bandbreedtes tot 1,28TB/s.

Door de opmars van AI is de hoge vraag naar HBM-geheugen sterk gestegen. SK hynix, de grootste fabrikant van dat geheugentype, zei in mei dat zijn productiecapaciteit voor de rest van dit jaar is uitverkocht. De capaciteit voor volgend jaar zou ook al bijna uitverkocht zijn.

Bron: Samsung

Reacties (20)

[Umbrah]

HBM is een van die gekke tech-dingen die aan de ene kant heel revolutionair zijn, maar aan de andere kant door de work arounds al ingehaald waren. Getuige het gebruik ervan in consumenten GPU's.

Het idee dat je met genoeg bandbreedte en lage latency een van de grootste compute bottlenecks (cache miss, waiting for cache) kan oplossen is geweldig. In consumenten GPU's (die, laten we eerlijk zijn, toch vaak voor gamen worden gebruikt) was het probleem echter aan de ene kant dat de cache te klein werd, maar ook dat de workarounds (compressie, streaming, pre-rendering) voor gamen niet zo nuttig meer waren.

Kijken we echter naar AI workloads, waar we praktisch neuronen proberen na te bootsen, die feitelijk geheugen en operatie in een combineren, dan is HBM geweldig.

Nog geweldiger zal zijn als we dat vervolgens ook nog eens met 3D XPoint konden combineren, waardoor het feitelijk ook persistent is, en dus power-loss bestendig, no loadtimes ever, etc... maar goed.

[DigitalExorcist]

Nu heb ik hier de ballen verstand van en ik ga ook niet claimen dat dat niet zo is, maar we spreken over caches nog steeds in kilobytes of slechts enkele megabytes (afhankelijk van L1, L2 of L3, toch?)

Is het niet "gewoon" een optie om een cache van 1GiB of 8GiB te gaan gebruiken voor specifieke toepassingen. Zo sla je toch véél meer op, of wordt het dan automatisch weer te traag?

[wiseger]

Cache zit op de CPU. Hoe meer je erop zet, hoe groter het CPU ontwerp wordt en ook hoe meer warmte de CPU zal produceren. De keuzes waar je dan voor komt te staan zijn: haal je dan computing units eraf om meer cache toe te voegen? Daarnaast is de winst op een gegeven moment minder, goede branche prediction zorgt dat de data uit het geheugen al klaar staat in de cache voordat de CPU erom vraagt.

[Reactie gewijzigd door wiseger op 7 augustus 2024 10:28]

[DigitalExorcist]

Dat snap ik; maar we zitten al decennia lang vast aan die paar KiB tot max een paar MiB op L3. Je zou toch verwachten dat dat inmiddels ook wel verder ontwikkeld is allemaal? Tuurlijk wordt je CPU package groter, maar daar heb je ook 3D-laagjes voor inmiddels toch?

[Blaat]

Eigenlijk is het heel simpel.

Hoe groter de cache, hoe meer oppervlak deze inneemt op je die. Hoe groter het oppervlak, hoe groter de access latency wordt. Dit is het hele bestaansrecht van cache levels (L1 t/m L4, waarbij L4 gezien kan worden als je DRAM). Elke stap in cache level vertegenwoordigt een stap in latency, maar ook in capaciteit.

Sommige data heb je nou eenmaal heel vaak nodig, en daar wil je snel op terug kunnen grijpen. Als je alle data in HBM modules zou proppen zou de performance van menig CPU en GPU inzakken als pudding, omdat de chip constant op data zit te wachten.

[wiseger]

De vraag is hoeveel performance win je bij nog grotere caches in vergelijking met andere investeringen zoals snellere of extra cores. En als je meer ruimte nodig hebt voor extra cache geheugen, wat laat je dan weg?

Het klopt dat er al fabrikanten die meerdere laagjes in de cache gebruiken en zo een grotere cache aanbieden. En daar betaal je dan wat extra's voor.

[lanarhoades]

is toch ook gewoon duur? Hoe groter de chip die is hoe minder je er op een wafer kan krijgen. En de falingspercentage bij het produceren gaat omhoog omdat de complexiteit hoger is maar ook simpelweg door het grotere oppervlakte.

[wiseger]

Uiteraard. En daarom zie je een verscheidenheid aan CPU's. Sommige die wat duurder zijn met 3D cache , andere zonder 3D cache die goedkoper zijn.

Het is maar waar je je PC voor gebruikt. In sommige scenario's leidt meer cache tot betere prestaties, in andere scenario's merk je er maar weinig van.

En dat is precies waar het met HBM geheugen over gaat. In het data center AI scenario is het de investering waard. Op je eigen PC, ik betwijfel het.

[Umbrah]

En dit is waarom stiekem wafer scale chips heel erg cool zijn. Ik zal ook graag wat ASIC of andere "Rube Goldberg"-esque CPU/algoritme-on-a-chip zaken willen zien die heel effectief bepaalde taken uit voeren.

Cache, maar ook de hele keten naar storage toe, is zo'n gigantisch "gevolg" van een meer dan een halve eeuw-oude beslissing om general purpose computing-on-a-chip de "standaard" te maken van onze "computers". De definitie van wát een computer is, veranderd echter al een behoorlijke tijd. Naast CPU's, hadden we al GPU's, NPU's, en zeker in de wereld van spatial computing hadden we al zaken als "HPU's" (feitelijk Microsoft met het algoritme om met camera's plaats te bepalen en gebaren te herkennen op een chip, zodat de arme Atom CPU in de hololens dat er niet bij hoefde te doen).

Heel onze storage architectuur komt uit een tijd dat persistent storage an-sich niet op een stukje silicon kon worden gebakken (immers, we hadden draaiende magnetische schijven of stukjes papier met gaten er in, of opgerold magnetisch materiaal op een grote spoel). Cache an-sich is een work-around om de brug tussen tragere niveaus van cache maar ook storage te overbruggen, zeker in general purpose CPU-gebaseerde systemen. Ik zeg niet dat we terug moeten gaan naar de mechanische typemachine, maar "use-case-on-a-chip" lijkt me stiekem ook wel cool!

[Umbrah]

Voor mij is het meest bepalende verschil tussen "cache" en "niet-cache" de persistentie en hoeveelheid ervan.

Alles tot en met RAM raakt namelijk de data kwijt als de stroom er vanaf wordt gehaald, en heel lullig gesteld: dit is waarom harddrives, floppydrives, SSD's, en andere storage al vanaf dag één een belangrijk onderdeel zijn van elk computer ontwerp. Zonder zou je elke keer weer vanaf het begin mogen beginnen met je OS, en alle zaken er omheen.

RAM zelf is dan eigenlijk ook gewoon cache, zei het een stuk sneller dan je SSD, nog steeds een stuk trager dan L3, L2, en L1 cache. Die cache niveaus hebben soms ook een heel ander "ontwerp", sowieso zijn filesystems daar niet echt aan de orde, maar laten we eerlijk zijn: er zijn genoeg applicaties waar een filesystem niet een kernfunctie is. L1 is een heel grappige, want die is soms verdeeld in "instructies" en "data". Instructies kun je zien als "x, +, -, >", etc; en data kun je zien als de getallen "1" en "2", die beide in een 'register' staan.. Feitelijk om dat uit te kunnen voeren worden zal een programma vaak van het niveau zijn: "lees register met 1, lees register met 2, doe instructie + op registers, schrijf resultaat functie naar register antwoord, waarbij dat dan vervolgens de waarde "3" wordt.

Omdat al die zaken met de hand doen lastig is, hebben we OS-en, cache managers, compilers, en hogere level talen dan assemblertaal. Maar de werkelijkheid is feitelijk dat er zelfs met supermoderne CPU's maar zo'n 80kilobyte aan cache is per core, want die cache is nogal groot op de CPU.

Zouden we L1 cache kunnen maken van gigabytes die tegelijkertijd nooit z'n inhoud kwijt raakt bij powerloss, dan zouden we vrij revolutionaire toepassingen kunnen bedenken, en het fundamentele ontwerp van veel OS-en en applicaties zal drastisch anders worden. Ik denk niet dat dat direct gaat gebeuren, sterker nog, "persistent RAM" (door 3D Xpoint in DIMM sloten te stoppen) kon men erg slecht mee omgaan ómdat het zo'n afwijking is van hoe we nu werken, maar gezien het feit dat de ASIC en GPU-revolutie waar o.a. dit HBM geheugen een rol in speelt tóch al een revolutie is, kan ik stiekem hopen dat ooit iemand op het idee komt om, als ze toch bezig zijn, gelijk een absurde lading 3D X-point te tilen op een GPU of ASIC met óók een absurd brede bus.

[geert1]

Dat zou in principe wel heel snel kunnen zijn, maar in elk geval de fysieke ruimte kan dan een probleem worden. L1-3 worden in de chip geplaatst met de rest van de architectuur. Het chipoppervlak van CPU's wordt niet heel veel groter door de tijd, en de rekenfuncties nemen ook flink wat ruimte in. Dus grote hoeveelheden geheugen zullen al vrij snel een losstaand component moeten zijn, zoals werkgeheugen.

Of gigabytes aan CPU-cache ook erg nuttig zijn in brede zin durf ik niet te zeggen; waarschijnlijk wel voor bepaalde doeleinden (als er ruimte zou zijn dus). Over het algemeen komen er heel kleine objecten in deze cache: uitkomsten van afzonderlijke processorinstructies die telkens opnieuw nodig blijken te zijn (bijvoorbeeld vele malen per seconde). Dus enkele megabytes kan al veel doen.

[Reactie gewijzigd door geert1 op 9 augustus 2024 00:58]

[beerse]

Hgh Bandwitdth Memory... Dat stel ik mij graag letterlijk voor: In plaats van 8, 16, 32 of 64 bits parallel een nog veel bredere bandbreedte door de 'bandkabel´ naar het geheugen nog breder te maken. En met dit gestapelde geheugen lijkt mij dat gewoon letterlijk te kunnen door 128, 256 of met nog bredere banden naar de geheugens te gaan. Dat die signalen dan bij verschillende lagen tegelijk uit komen is vooral een zaak van synchroniseren van signalen en de lagen zelf. Enneh, ja, dat komt overal terecht. We gebruiken nu thuis ook allemaal 64 bits systemen waar dat eind vorige eeuw nog vaak 16 bits was.

Als je het over het versnellen en/of vergroten van de cache hebt: Misschien wordt het geheugen zo snel dat er geen cache meer nodig is. Die cache is er alleen maar gekomen omdat het geheugen niet snel genoeg was. Nu dat geheugen sneller is, zou de cache geheeel ge-elimineerd kunnen worden.

[xorpd]

Cache zal nooit geëlimineerd worden, het verschil in snelheid is nog altijd 1 a 2 ordes van grootte.

[Pinkys Brain]

HBM vermindert ook het energieverbruik per bit.

Nu door chiplets MCMs met kleine pitch steeds normaler worden is er eigenlijk geen reden waarom HBM niet standaard zou kunnen worden. Zou me niet verbazen als Apple overstapt.

[Reactie gewijzigd door Pinkys Brain op 7 augustus 2024 12:10]

[Exirion]

HBM is een van die gekke tech-dingen die aan de ene kant heel revolutionair zijn, maar aan de andere kant door de work arounds al ingehaald waren. Getuige het gebruik ervan in consumenten GPU's.

Doet een beetje denken aan Rambus RDRAM destijds. Geweldige beloften, maar hoge kosten en o.a. een beperkende relatief hoge latency. Het moest met de komst van de P4 een doorbraak worden maar is hopeloos geflopt, ook door chipsetproblemen bij Intel (i820). De tijd zal het leren of dit echt iets wordt. Ook een grote speler zoals NVidia die z'n naam eraan verbindt is geen garantie voor succes.

[graey]

HBM is al langer op de markt en heeft toepassingen gevonden. Of het buiten die niche verder gaat komen is een tweede, maar het is al 'van de grond'.

[1Joshua5]

Je kan nog steeds een AMD RADEON PRO VII 16GB kopen met dit soort geheugen. Niet echt een success geweest destijds. Waarom hangen we nu de vlag uit voor een kaart die jij nog ik gaan kopen?

[Thekilldevilhil]

Ik moest je laatste zin 3 keer lezen, je bedoelt denk ik noch.

In dat geval, de vlag gaat uit omdat het hele artikel niet over consumenten GPU gaat. In datacenters is HBM echt een veelgebruikt type geheugen. Al jaren zijn alle big die GPUs van zowel AMD als NVIDIA voorzien van HBM. De consumenten GPUs gebruiken inderdaad GDDR

[Game-Tea]

Is ook niet bedoeld voor consumenten kaarten, HBM zou te luxe zijn voor consumenten en dat kan nvidia zich natuurlijk niet veroorloven . Met een aantal trucjes zoals een grote cache (AMD heeft dit geïntroduceerd met Infinity Cache op de rx 6000 serie, Nvidia heeft hetzelfde gedaan met de 40 series), zijn de zwakheden van GDDR redelijk te compenseren voor consumentenapplicaties. HBM is bedoeld voor echte number crunching applicaties waar een dataset die in VRAM zit ook constant gebruikt wordt. Denk aan uiteraard AI/inferenci g en wetenschappelijke modellen die gpu-accelerated zijn.

[dasiro]

HBM was oorspronkelijk voor videokaarten ontwikkeld ja, maar het is ondertussen zo duur dat het enkel nog maar in professionele en datacenter-producten wordt gebruikt. De afgeleide producten hebben vaak zelfs geen poorten meer aan boord voor video-output, dus de benaming dekt de lading al een tijdje niet meer.