Mit rejteget az NVIDIA Hopper architektúra?

A gépi tanulásnak alárendelve

Az NVIDIA a múlt héten bemutatta a H100 jelzésű gyorsítót, amelyről az alábbi hírben írtunk, de akkor még számos információt nem ismertünk a fejlesztésről, így sok kérdésre nem is volt válasz. Azóta viszont számos adatott közzétett a vállalat, így mostmár van lehetőség bővebben is írni a fejlesztésről.

A friss lapka a TSMC 5 nm-es, 4N nevű node-ján készül, és 80 milliárd tranzisztorból épül fel, miközben a kiterjedése 814 mm². Ez elég combosnak hangzik, de a lényeg úgyis a rendszer működése, így rá is térünk erre.

Az alapokat az új Hopper architektúra adja, ami továbbfejlesztésnek számít az Ampere-hez képest, viszont a felépítés nem változott, a multiprocesszorokon belül marad a jól megszokott, négy compute blokk. Ezekben található egy L0 utasítás gyorsítótár, egy feladatirányító (dispatch), illetve egy warp ütemező, amelyek többféle futószalagot etetnek. Az NVIDIA természetesen továbbra is használja a CUDA mag kifejezést, de ahogy korábban, úgy ennek a Hopper esetében sincs értelme, mivel már nem komplex feldolgozók találhatók a blokkokon belül. Ennek megfelelően a Hopper architektúrában az utasításszavak végrehajtása a nekik megfelelő futószalagon történik. Ha 64 bites lebegőpontos operációról, azaz FP64-ről van szó, akkor egy darab 16 utas; 32 bites lebegőpontos operáció, azaz FP32 esetében egy darab 32 utas; 32 bites integer, azaz INT32 mellett egy darab 16 utas; míg a Tensor műveleteknél egy darab 512 utas, structural sparsity támogatással dolgozó tömb áll rendelkezésre.

A H100 multiprocesszora [+]

Az NVIDIA papíron most is az FP32-es ALU-kat tartja CUDA magoknak, és ezek a részegységek megfelelnek az IEEE754-2008-as szabványnak, vagyis támogatják a MAD (Multiply-Add), illetve az FMA (Fused Multiply-Add) instrukciókat. A load/store egységek bekötése gyakorlatilag az Ampere dizájnját másolja, ahogy a speciális funkciókat biztosító egység (SFU) kialakítása is. A textúrázási képességek területén sincs igazán újítás. Az egyes streaming multiprocesszorok egy darab, négy csatornát biztosító textúrázó blokkot tartalmaznak, amelyet négy compute blokk használ egyszerre.

A compute blokkokon belüli regiszterterület marad 64 kB, vagyis annyi, amennyi a Voltában, a Turingban és az Ampere-ben volt. Ez abból a szempontból nem túl szerencsés, hogy az FP32 feldolgozók ismét megduplázódtak a compute blokkon belül, miközben az adatokat annyi helyen kell tárolni, mint amennyit az előző generáció architektúrája kínált. Ugyanakkor az NVIDIA ezt a dizájnt már nagyon erőteljesen a gépi tanulásra szánja, ahol ez a gond nem annyira jelentős, mivel a futtatott feladatok regiszternyomása nem túl magas, ellenben mondjuk egy szimulációs feladattal, amire nem tűnik túl optimálisnak a Hopper architektúra kialakítása. A komplex munkafolyamatok esetében talán javíthat ezen a 192-ről 256 kB-ra nőtt L1 gyorsítótár, amely compute feladatok mellett igen szabadon particionálható, mivel ez a tárterület egyszerre látja el az általános gyorsítótár és helyi adatmegosztás feladatát. Utóbbi szerepkörre maximum 228 kB dedikálható, és lényeges újítás, hogy mostantól a szálblokkok a fedélzeti memória igénybevétele nélkül is megoszthatnak egymással adatokat.

Tensor magokon táplálkozva

Ha már a H100-at ennyire a gépi tanulásra hegyezték ki, érdemes többet szentelni az úgynevezett Tensor magoknak, már csak azért is, mert ebből megérhető, hogy miképpen kalkulálja az NVIDIA a megadott számítási teljesítményt.

A negyedik generációs Tensor egységek sokban különböznek elődeiktől. Egyrészt új adattípust támogatnak, így a korábban bevezetett Int8, FP16, BF16 (bfloat16), TF32 és FP64 mellett elérhetővé vált az FP8, azaz a 8 bites lebegőpontos opció. Ráadásul E4M3 és E5M2 formában is elérhető, ahol mindkét esetben 1 jelbit van, de amíg előbbi 4 bites exponenst és 3 bites mantisszát használ, addig utóbbinál rendre 5 és 2 bitre lehet számítani.

[+]

A Tensor magok része lesz mostantól az úgynevezett Transformer Engine, amellyel a cél az, hogy transformer modell esetén az adattípusok kevert alkalmazása mellett menedzselhető legyen a precizitás, miközben a pontosságot nem éri csorba. És nem szabad ugye megfeledkezni a már említett structural sparsity lehetőségről sem, ami esetenként megduplázhatja az elérhető teljesítményt a sztenderd tensor operációkhoz viszonyítva.

A fentieket egészíti még ki a TMA, vagyis a Tensor Memory Accelerator, ami nem a Tensor magok, hanem a multiprocesszorok része. Erre azért van szükség, mert a maga a Tensor mag annyira meghízott az elmúlt évek alatt, hogy már könnyen limitációt jelenthet az adatok mozgatása. Elemek szintjén történő címzés helyett a TMA lehetővé teszi a nagy adatblokkok kezelését úgy, hogy nem terheli az ütemezőt, ami így csinálhat más feladatokat. Lényeges persze, hogy az adatblokk nem lehet nagyobb a helyi adatmegosztásra fenntartott gyorsítótár partíció kapacitásánál, de ez a korábbi módszerrel is limitáció volt, csak ott nagyobb többletterheléssel kellett számolni az adatok kezelése kapcsán.

A számítási tempóra rátérve az NVIDIA által FP8, FP16/BF16 és TF32 adattípusok esetében közölt rendre 4000, 2000 és 1000 TFLOPS a structural sparsity-t használva jön ki. A valós teljesítmény az előbbi paraméterek fele, azaz 2000, 1000 és 500 TFLOPS.

Az IEEE754-2008-as szabványnak megfelelő adattípusok kapcsán a 32 bites lebegőpontos sebesség trükkök nélkül 60 TFLOPS, míg a dupla pontosságra két érték is van. Egyrészt az FP64-et végrehajthatják az erre kialakított dedikált feldolgozók vagy a Tensor magok. Előbbi esetben 30, míg utóbbiban 60 TFLOPS-szal lehet számolni. Ezt azért lényeges kiemelni, mert nem ugyanarról az operációról van szó a számítások elvégzésekor, ugyanis amíg a dedikált feldolgozók FMA-t (Fused Multiply-Add), addig a Tensor magok MMA-t (Matrix-Multiply Assist) használnak.

A Hopper nagyvonalakban

A H100 a memóriaalrendszer tekintetében sokban hasonlít az előző generációs A100-ra. Megmaradt a méretes interposer, amelyre hat darab, egyenként 16 GB-os, azaz összesen 96 GB HBM3 vagy HBM2e memória kerül. Ebből kitalálható, hogy 6144 bites a memóriabusz, mivel a hat darab memóriatömb egyenként 1024 bites buszon keresztül kapcsolódik a GPU-hoz. Persze a tényleges hardverekben egy darab 1024 bites csatorna le lesz tiltva, így végül 5120 bites buszon fog 80 GB-nyi fedélzeti tár működni, és a HBM3 szabványra építve ez így is biztosít majd 3 TB/s-os memória-sávszélességet. Ez még nem végleges adat, mert a memóriák órakeléről még nem döntött az NVIDIA, de nagy változás nem valószínű.

NVIDIA H100 [+]

A Hopper architektúra a strukturális felépítést tekintve sokban hasonlít az elődjeire. A legfontosabb feldolgozótömb a GPC, ami a Graphics Processing Clusternek rövidítése. Ebből nyolc darab található az új dizájnban, és egy GPC-ben kilenc darab TPC, azaz Texture Processor Cluster található, és ezeken belül bújuk meg két-két darab, SM nevű multiprocesszor, amelyekről az első oldalon értekeztünk, így ezek részletes felépítését már kifejtettük.

Van azonban egy változás az előző generációs dizájnokhoz képest, ugyanis az NVIDIA két részre strukturálja a teljes lapkát, vagyis a beépített nyolc darab GPC két darab, négy GPC-vel rendelkező logikai blokként működik. Ennek az oka valószínűleg az, hogy a Hopper architektúra már annyira sok feldolgozót tartalmaz, hogy a rendkívül sok futtatható konkurens szál mellett skálázási limitekbe ütközne a régóta használt memóriamodellel. Ezt az NVIDIA úgy kezeli, hogy két logikai blokkra osztja a teljes lapkát, ezzel kettévágva az összesen amúgy 50 MB-os L2 gyorsítótárat, illetve az ahhoz kapcsolódó memóriacsatornákat. A grafikus képességeket figyelembe véve az NVIDIA szerint a H100 nem rendelkezik kijelzőmotorral, NVENC kódolómotorral, illetve sugárkövetést gyorsító feldolgozókkal sem, de grafikai feladatokra nagyon korlátozott mértékben azért képes, mert az egyik GPC-ben található setup motor, amelyhez papíron két TPC van hozzákötve. Ezek közül azonban az egyik TPC grafikai képessége le lesz tiltva, ami valószínűleg egy kihozatal növelését célzó döntés.

A H100 az A100-hoz hasonló dizájnban érkezik, így fontos az NVLINK interfész, illetve az SXM formátum, ennek is az ötödik generációs verziója. A friss lapkában 18 darab, kétirányú kommunikációra képes NVLINK található, így összesen 900 GB/s biztosított. A lapkák összeköttetése szempontjából több lehetőség van. Négy GPU-ig elég szimplán az NVLINK-et használni, míg nyolc GPU-nál már NVSwitch is kell. A host processzor felé x16-os PCI Express 5.0-s interfész áll rendelkezésre, de opcionálisan itt is lehet élni az NVLINK-kel, ha az adott CPU képes natívan támogatni. A fogyasztás terén egyébként a H100 új szintet üt meg, ugyanis 700 wattos energiaigénnyel rendelkezik, de a hagyományos, PCI Express 5.0-s kiépítéssel már 350 watt mellett üzemel, de persze ez jóval kisebb teljesítményt is jelent.

NVIDIA H100 SXM5 [+]

A várható H100-as modellek biztosan nem változó paramétereit az alábbi táblázat részletezi:

Hopper-féle virtualizáció

A nyers hardveres alapok mellett van még egy fontosabb fejlesztés, amely az adatközpontokban lehet hasznos. Egy ideje már alapvető funkcionalitás a virtualizáció, és az NVIDIA az előző generációs Ampere architektúrában be is vezette a saját hardveres megvalósítását, amely a PCI-SIG SR-IOV (single root I/O virtualization) szabványával is használható. Valószínűleg nem ér senkit sem meglepetésként, ha azt írjuk, hogy ezt a Hopper architektúra is támogatja, de a zöldek tekertek egy kicsit a képességeken, hogy biztonságosabb legyen.

A Hopper virtualizációs dizájnja általánosságban nagyon hasonló az Ampere-hez, így az adott lapka több partícióra osztható, és ezek hardveresen el vannak egymástól szigetelve. Összesen maximum hét partíció hozható létre, annak függvényében, hogy az adott feladatnak mi az optimális. Ha például erősen számításintenzív egy munkafolyamat, akkor nem feltétlenül jó ötlet azt hét partícióra osztott gyorsítón futtatni, de ez részletkérdés, nyilván alkalmazkodni kell a tervezett körülményekhez.

Amiben a Hopper újít, az a biztonság erősítése, amivel az NVIDIA nyit az úgynevezett confidential computing szolgáltatások felé. Ez a modell azt garantálja, hogy a szerveren tárolt adatokhoz még a felhőszolgáltató se férhessen hozzá, vagyis az ügyfél gyakorlatilag teljes felügyelettel rendelkezik a bérelt rendszer fölött.

Ezt a Hopper egy meghajtóprogramon keresztül éri el, ami a kialakított megbízható végrehajtási környezeteken belüli munkafolyamatot felügyeli. Ilyen formában maximum négy darab biztonságos partíció hozható létre, ugyanis ebben a környezetben kritikus tényező, hogy milyen virtuális gép dedikált NVDEC (videó dekódoló) és NVJPG (JPG dekódoló) egységet kapjon.

Az NVIDIA nem csak particionált megbízható végrehajtási környezeteket támogat, hanem egy vagy akár két teljes gyorsító is hozzárendelhető egy ilyen környezethez. Utóbbi lehetőségnek is megvan a maga előnye, de fontos figyelembe venni, hogy ilyenkor az adott hardverpárosítás dedikáltan egy biztonságos virtuális géphez lesz rendelve, vagyis az erőforrásokat akkor sem érheti el egy másik virtuális gép, ha a befogott gyorsítók kihasználása nem túl erőteljes.

A H100 a fentieken túlmenően saját teljesítménymonitorozókat is kap, hogy az egyes felhasználók által a partíciók optimális kihasználása ellenőrizhető legyen.

Az NVIDIA szerint a H100 SXM verzióját már az idei esztendő harmadik negyedévében szállítani fogják a kiemelt partnereknek, és valószínűleg ekkortájt már az órajeleket is véglegesítik, így a pontos specifikációkat is be tudják majd jelenteni.

Abu85