Hirdetés

Mit rejteget az NVIDIA Hopper architektúra?

Ha az A100-ra azt írtuk, hogy gépi tanuláshoz készült, akkor ez az új H100-ra hatványozottan igaz.

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 4 nm-es 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
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.

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények

Hirdetés