AMD zorganizowało największe jak dotąd wydarzenie Advancing AI, podkreślając skalę jako temat przewodni. Firma zaprezentowała procesor graficzny Instinct MI455X, stelaż Helios z 72 GPU oraz procesory EPYC Venice 6. generacji. MI455X oferuje 432 GB pamięci HBM4, co stanowi wzrost o 50% w porównaniu z procesorami B300 lub Rubin firmy NVIDIA, przy przepustowości pamięci 23.3 TB/s i do 40.26 PFLOPS obliczeń MXFP4. Kompletny stelaż Helios skaluje te wartości 72-krotnie, osiągając 2.9 eksaFLOPS FP4, 31 TB HBM4, 1.7 PB/s przepustowości pamięci, 260 TB/s skalowania w górę i 43 TB/s skalowania w poziomie do centrum danych. Pod względem wszystkich metryk AMD dąży do bycia liderem branży. W tym artykule omówiono procesory MI455X i Helios; premiera w Wenecji została omówiona w osobnej analizie.

Drugim motywem przewodnim jest otwartość, obejmująca każdą warstwę, począwszy od połączeń międzysystemowych. Wewnątrz szafy wszystkie 72 procesory graficzne współdzielą pamięć za pośrednictwem UALink, otwartej struktury konsorcjum, którą AMD obsługuje w sieci Ethernet jako UALink-over-Ethernet (UALoE). Gdy ruch opuszcza szafę, jest przesyłany przez Ultra Ethernet, otwarty standard skalowania poziomego od Ultra Ethernet Consortium. Ten sam Instinct obsługuje stos. Obliczenia o niskiej precyzji wykorzystują otwarte formaty danych MXFP4, MXFP6 i MXFP8 firmy OCP, a szafa, w której wszystko się mieści, została zbudowana zgodnie z projektem Open Rack Wide projektu Open Compute. Nawet oprogramowanie jest rozwijane w sposób otwarty, a kompilator, środowisko uruchomieniowe i biblioteki ROCm są dostępne w kodzie źródłowym.

Ponieważ każda specyfikacja w stosie jest dziś opublikowana i dostępna do pobrania, firma zajmująca się hiperskalerem może traktować Heliosa jako projekt i zbudować wersję na zamówienie, dostosowaną do własnych obiektów i obciążeń, dostosowując do nich funkcje sieciowe, zasilania i zarządzania. Oznacza to, że wszystko, co omawiamy w tym artykule, to projekt referencyjny przedstawiony przez AMD; jednostki wdrażane przez klientów mogą się znacznie różnić. Chętni już się zapisali: AMD twierdzi, że OpenAI, Meta, Anthropic, Microsoft , Oracle i inne firmy wdrażają Heliosa.

AMD Instinct MI455X: flagowy model CDNA 5

MI455X to pierwszy akcelerator CDNA 5, składający się z 320 miliardów tranzystorów. MI455X zawiera osiem układów scalonych Accelerator Complex Dies (XCD) zbudowanych na węźle N2 firmy TSMC, a także dwa układy I/O Dies oraz dwa układy Fabric and Cache Dies na węźle N3 oraz dwanaście stosów HBM4. Jest to największy układ scalony, jaki kiedykolwiek zbudowano w obudowie CoWoS-L firmy TSMC.

Pamięć to jeden z głównych tematów. Dwanaście stosów HBM4 ma łącznie 432 GB i przepustowość 23.3 TB/s, przy czym HBM4 podwaja interfejs na stos do 2,048 bitów, a dwie struktury Fabric i Cache dodają 192 MB pamięci L2 o przepustowości 54 TB/s.

MI455X nie ma też problemów z wejściem/wyjściem. Oferuje 72 linie UALoE, co zapewnia dwukierunkową przepustowość skalowania do 3.6 TB/s do reszty szafy, dwukierunkową przepustowość Infinity Fabric 256 GB/s do procesora hosta oraz możliwość wyboru dwóch łączy PCIe Gen6 x16 lub trzech kart sieciowych AMD AI-NIC do skalowania w poziomie.

W porównaniu z układem, który zastępuje, oraz z ofertą firmy NVIDIA, MI455X jest liderem pod każdym względem.

Specyfikacja	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
Architektura	CDNA5	Rubin	CDNA4	Blackwell Ultra
Tranzystory	320B	336B	185B	208B
Pojemność HBM	432GB HBM4	288GB HBM4	288 GB HBM3E	288 GB HBM3E
Szerokość pasma HBM	23.3 TB/s	22 TB/s	8 TB/s	8 TB/s
Skalowanie na procesor GPU	3.6 TB/s	3.6 TB/s	1.08 TB/s	1.8 TB/s
Skalowanie poziome na procesor GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
Łącze CPU-GPU	256 GB/s Infinity Fabric	1.8 TB/s C2C (1:2)	PCIe 5	900 GB/s C2C (1:2)

 

Zacznijmy od tego, gdzie AMD prowadzi. Z 432 GB, MI455X oferuje o 50% więcej pamięci HBM niż MI355X, B300 czy Rubin, z których wszystkie osiągają maksymalnie 288 GB. Jego przepustowość pamięci, wynosząca 23.3 TB/s, jest również najwyższa w tej grupie. Podobnie przedstawia się skalowalność: 2,400 Gb/s na GPU w porównaniu z 1,600 Gb/s dla Rubina i 800 Gb/s dla B300. Każdy MI455X opuszcza szafę rack z o 50% większą przepustowością sieciową niż jego najbliższy konkurent.

AMD w końcu nadrobiło zaległości w kwestii skalowania. NVLink od lat jest wiodącą technologią GPU i przez dwie generacje był jedynym sposobem na uzyskanie najwyższej wydajności w modelach MoE z WideEP. UALoE niweluje tę lukę w ciągu jednej generacji: z przepustowością 3.6 TB/s, MI455X dorównuje NVLink 6 Rubina. NVIDIA nadal utrzymuje wyraźną przewagę w zakresie łącza hosta. Jeden procesor Vera obsługuje dwa procesory GPU Rubina przez 1.8 TB/s C2C, podczas gdy każdy MI455X komunikuje się z hostem Venice przez łącze Infinity Fabric o przepustowości 256 GB/s. Ta różnica kształtuje różnice między tymi dwiema architekturami rack w dalszej części tego artykułu.

Pod względem surowych obliczeń MI455X prowadzi w klasyfikacji pod każdym względem, z jednym przypisem: formaty OCP MX firmy AMD i NVFP4 firmy NVIDIA skalują się inaczej, dlatego należy traktować je jako deklarowane wartości szczytowe; rzeczywista wydajność to osobna kwestia.

Format:	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
MXFP4 / NVFP4	40.26 PF	35 PF	10.1 PF	15 PF
MXFP6 / FP6	20.13 PF	17.5 PF	10.1 PF	5 PF
MXFP8 / FP8	20.13 PF	17.5 PF	5 PF	5 PF
FP16 / BF16	5.03 PF	4 PF	2.5 PF	2.5 PF
FP32	315TF	130TF	157.3TF	75TF

 

W porównaniu z MI355X, MI455X zapewnia czterokrotnie większą przepustowość MXFP4 i MXFP8 oraz dwukrotnie większą przepustowość FP16/BF16 i FP32. Porównanie z NVIDIA dzieli się na dwie części. W porównaniu z B300, MI455X zapewnia 2.7-krotnie większą przepustowość FP4 i czterokrotnie większą przepustowość FP6 i FP8. Rubin jest znaczącym punktem odniesienia, a w porównaniu z nim MI455X utrzymuje stałą przewagę: 15% przy FP4, 15% przy FP6 i FP8 oraz 26% przy FP16/BF16. Największa różnica występuje przy FP32, gdzie 315 TF MI455X jest około 2.4 razy większe niż 130 TF Rubina i ponad czterokrotnie większe niż 75 TF B300. Liczba ta pochodzi z linii produktów HPC firmy Instinct i nadal ma znaczenie w przypadku prac nad sztuczną inteligencją, ponieważ obciążenia główne, akumulacja o wysokiej precyzji i obciążenia naukowe nadal są realizowane z większą przewagą niż formaty niskobitowe.

Wewnątrz CDNA 5

Przyjrzyjmy się bliżej architekturze i zobaczmy, co tak naprawdę odpowiada za tę wiodącą w swojej klasie wydajność.

Od XCD do SIMD

Przechodząc hierarchię od pakietu w dół, widać, jak wiele zostało przebudowane, ponieważ CDNA 4 zorganizowało układ obliczeniowy zupełnie inaczej. W MI355X każdy XCD zawierał 32 aktywne jednostki obliczeniowe i prywatną pamięć podręczną L2 o pojemności 4 MB, która grupowała ruch układu przed dotarciem do Infinity Fabric. CDNA 5 zachowuje osiem XCD, ale odbudowuje to, co się w nich znajduje, zapożyczając strukturę i terminologię z linii graficznej RDNA firmy AMD. Każdy XCD MI455X jest teraz podzielony na dwa silniki cieniowania. Każdy silnik cieniowania fizycznie zawiera 17 procesorów grup roboczych, z czego 16 jest włączonych, a jeden jest zapasowy dla wydajności. Każdy z procesorów L2 dla XCD został całkowicie usunięty, oderwany od układu obliczeniowego i umieszczony poniżej, w podstawowych układach, do których powraca sekcja pamięci.

Liczy się arytmetyka, czyli to, co się nie zmieniło. XCD nadal generuje 32 aktywne jednostki, a GPU nadal ma ich łącznie 256, czyli tyle samo, ile MI355X w jednostkach obliczeniowych. Żaden z generacyjnych wzrostów przepustowości o 4× w niskiej precyzji nie wynika z dodawania jednostek wykonawczych; wszystko wynika z tego, że każdy WGP wykonuje więcej pracy w cyklu, a to właśnie WGP koncentruje się na przeprojektowaniu.

WGP jest zbudowany z czterech 32-torowych jednostek SIMD i czterech jednostek skalarnych współdzielących stałą pamięć podręczną. Największą zmianą jest sposób przepływu wątków przez niego: przejście z Wave64 na Wave32. Fala to zbiór wątków, które SIMD przetwarza w synchronizacji. CDNA 4 korzystała z Wave64, przepuszczając każdą 64-wątkową falę przez 16-torowy SIMD w ciągu czterech cykli zegara. CDNA 5 całkowicie rezygnuje z obsługi Wave64, jako pierwsza architektura Instinct, i uruchamia Wave32 natywnie. 32-wątkowa fala mapuje jeden do jednego na każdą z czterech 32-torowych jednostek SIMD WGP, generuje dane w jednym cyklu i pozwala każdemu SIMD na rozpoczęcie nowej instrukcji przy każdym takcie zegara.

Węższe, szybsze fale zmieniają sposób, w jaki praca przemieszcza się przez maszynę. Opóźnienie instrukcji spada, ponieważ fala kończy się wcześniej. Rozbieżność gałęzi kosztuje mniej, ponieważ podział typu „take-or-not” zatrzymuje teraz maksymalnie 32 wątki zamiast 64. Zmniejsza się presja na rejestry, więc więcej fal pozostaje rezydentnych, aż do 64 na WGP w porównaniu z połową tego, co było wcześniej. Daje to planiście więcej małych, niezależnych fragmentów pracy, za którymi można ukryć opóźnienie pamięci. Wave32 ułatwia również mapowanie różnych rozmiarów kafelków dla operacji tensorowych na sprzęcie, upraszczając rozwój jądra.

Single-cycle issue is only the start of the throughput story. The SIMDs co-execute, starting new instructions while earlier multi-cycle operations drain underneath, and packed vector instructions carry 64 threads' worth of work in a single issue, details AMD's architects confirmed in the post-briefing Q&A. The vector pipeline also gains native BF16 support and a set of new data-conversion instructions for moving tensors between formats. The transcendental units double their throughput over the MI355X and add a native tanh instruction, so the softmax and activation math inside attention keeps pace with the tensor hardware around it. That path is becoming a habit: CDNA 4 doubled the transcendental rates to accelerate attention, and CDNA 5 doubles them again.

Hierarchia pamięci

Za jednostkami wykonawczymi kryje się hierarchia odbudowana od góry do dołu. Najwyraźniej można ją zobaczyć, przeglądając poziom po poziomie MI355X.

Poziom	MI455X (CDNA 5)	MI355X (CDNA 4)
Rejestry wektorowe	128 KB na SIMD; 1,024 na wątek; 2× przepustowość	128 KB na SIMD; 256 na wątek
WGP / CU lokalny sklep	384 KB (320 KB LDS + 64 KB pamięci podręcznej wektorowej); przepustowość 2×	192 KB (160 KB LDS + 32 KB L1)
Instrukcja / stała pamięć podręczna	64 KB + 16 KB na WGP	64 KB współdzielone na dwie jednostki CU + 16 KB
L2	2 × 96 MB na dyskach FCD; 54 TB/s	8 × 4 MB, po jednym na XCD
Pamięć podręczna po stronie pamięci	Wyłączony	256 MB pamięci podręcznej nieskończoności
HBM	432 GB HBM4; stosy 12 × 2,048 bitów; 23.3 TB/s	288 GB HBM3E; 8 stosów 1,024-bitowych; 8 TB/s

 

Rzędy pamięci podręcznej to miejsce, w którym architektura zmieniła kształt. CDNA 4 uruchomił projekt trzypoziomowy: każdy prywatny 4MB L2 XCD scalał ruch tego układu, zanim dotarł on do Infinity Fabric, a współdzielona pamięć podręczna Infinity Cache o pojemności 256MB w układach I/O znajdowała się po stronie pamięci przed kontrolerami HBM. CDNA 5 usuwa obie warstwy i zastępuje je dwiema niezależnymi pamięciami podręcznymi L2 o pojemności 96MB, po jednej na układ Fabric i układ Cache, każda zbudowana jako 96 bloków o rozmiarze jednego megabajta. Układ jest pionowy: cztery XCD, czyli osiem silników shaderów, są połączone hybrydowo na górze każdego FCD, który zawiera również sześć z dwunastu lokalizacji HBM4, a dwa FCD spotykają się w centralnym układzie Infinity Fabric pośrodku obudowy, a układy I/O zamykają oba końce. Każdy z L2 może przechowywać dowolny adres w pamięci GPU, a Infinity Fabric utrzymuje spójność pary. AMD podaje powód w postaci przepustowości: jedna z tych pamięci podręcznych zapewnia 1.5-krotnie większą łączną przepustowość niż cała pamięć podręczna Infinity Cache układu MI355X, pozostałe dwie zapewniają ją trzykrotnie większą, a cały ten ruch nie musi przechodzić przez podział między układami, który ograniczał stary układ.

Pamięć podręczna również przejmuje nowe zadania. Atomy o zasięgu urządzenia, które wcześniej były wykonywane w strukturze, teraz działają w warstwie L2 z dużo większą częstotliwością, podczas gdy atomy o zasięgu systemu pozostają w strukturze Infinity, tak jak poprzednio. Całość uzupełnia nowy arbiter rozgłoszeniowy, który przesyła tensory do wszystkich WGP współpracujących na tej samej macierzy. W związku z tym waga pobrana raz obsługuje je wszystkie, co zwiększa efektywną przepustowość odczytu nawet czterokrotnie.

Powyższe poziomy skalują się odpowiednio. Lokalna pamięć na WGP podwaja się do 384 KB, podzielona na 320 KB pamięci LDS i 64 KB pamięci podręcznej danych wektorowych, z dwukrotnie większą przepustowością odczytu. To miejsce dla FlashAttention na przechowywanie zapytań, kluczy, wartości i częściowych redukcji na chipie zamiast zapisywania całej macierzy uwagi. Obsługuje również połączone jądra MoE, aby zachować stan routingu i akumulatory w stanie rezydentnym. Plik rejestrów wektorowych zachowuje swoją pojemność 128 KB na moduł SIMD, ale jest zreorganizowany na potrzeby Wave32. W rezultacie uzyskuje się dwukrotnie więcej fal, pojedynczy wątek może adresować 1,024 rejestry zamiast 256, a przepustowość rejestrów podwaja się, aby zasilać szersze moduły SIMD i ich jednostki współwykonawcze.

Strona skalarna została przebudowana, aby dopasować się do 128 rejestrów skalarnych na falę i 32 KB na WGP. U podstawy HBM4 przechodzi z ośmiu stosów 1,024-bitowych do dwunastu stosów 2,048-bitowych, zwiększając pojemność o 50% do 432 GB i przepustowość 2.9× do 23.3 TB/s w 192-kanałowym interfejsie.

Wszystko to obsługuje nowy Tensor Data Mover, jeden na WGP, który rozumie schematy kafelkowania tensorów do pięciu wymiarów i asynchronicznie przesyła kafelki między pamięcią DRAM a lokalnym magazynem, bez pośredniego przeładowywania rejestrów. Transfery są opisywane deskryptorami ładowanymi z rejestrów skalarnych i sprzętowo sprawdzane pod kątem bezpieczeństwa. Obsługiwane są obciążenia multicast, dzięki czemu jednostki SIMD nigdy nie zatrzymują się w oczekiwaniu na kopię ani nie wypalają rejestrów przeładowywanych. Jest to odpowiedź CDNA 5 na akceleratory pamięci tensorowej w najnowszych podzespołach NVIDIA. Zestaw funkcji użytkowych uzupełnia przód maszyny: klastry grup roboczych dają jądrom jawną kontrolę nad rozmieszczeniem i współbieżnością obciążeń współdzielących dane, bariery dzielone i nazwane pozwalają producentowi sygnalizować zakończenie i przejść dalej bez oczekiwania na odpowiedź konsumenta, moduły wstępnego pobierania na każdym poziomie hierarchii przeładowują dane w kierunku punktu ich konsumpcji, a przeprojektowany interfejs poleceń skraca opóźnienie uruchamiania i wysyłania jądra w przypadku krótkich jąder, które dominują we wnioskowaniu.

System DMA został przebudowany w oparciu o tę samą filozofię. Oprogramowanie planuje transfery dla front-endów DMA, podczas gdy fizycznie świadome back-endy, znajdujące się obok łączy UALoE, dzielą każdy element roboczy, równoważą obciążenie na każdym dostępnym łączu i pobierają bufory z pamięci bezpośrednio, zamiast przesyłać dane przez układ do odległego silnika. Back-endy reagują również na presję przeciążenia ze strony sieci skalowalnej i omijają obciążone ścieżki, dzięki czemu biblioteki komunikacyjne otrzymują zrównoważony ruch w strukturze, nie rozumiejąc ukrytej topologii.

Podział GPU: NPS i SR-IOV

Układ fizyczny z dwoma warstwami L2 przynosi korzyści w sposobie partycjonowania GPU. W NPS1 cały układ stanowi jedną domenę NUMA: adresy przeplatają się we wszystkich dwunastu stosach HBM i obu połówkach, zapewniając jednorodną przepustowość, łatwy tryb portowania i równomierne rozłożenie wzorców dostępu. NPS2 dzieli GPU na dwie domeny NUMA, z których każda posiada sześć stosów HBM, jeden układ Fabric i Cache oraz ułożone na nim układy XCD. Każde odniesienie do pamięci pozostaje w swojej własnej połowie, a każda domena otrzymuje w efekcie prywatny 96 MB L2. To nie tylko skraca ścieżkę fizyczną. Bez linii pamięci podręcznej współdzielonych przez połówki, ruch spójności Infinity Fabric między dwoma warstwami L2 w dużej mierze zanika, a AMD twierdzi, że rezultatem są mniejsze opóźnienia i lepsza wydajność w aplikacjach obsługujących NUMA. CDNA 4 oferowała tę samą szeroką gamę rozwiązań, przy czym NPS2 utrzymywał ruch w obrębie jednego układu wejścia/wyjścia, ale CDNA 5 wyostrza tę koncepcję, ponieważ lokalizowany jest teraz cały obszar pamięci podręcznej L2, a nie tylko fragment bufora po stronie pamięci.

Stosy partycjonowania obliczeniowego są umieszczone na wierzchu. Osiem dysków XCD pozwala GPU na uruchomienie jednej, dwóch, czterech lub ośmiu partycji przestrzennych, dzieląc 432 GB pamięci HBM na równe segmenty o pojemności 432, 216, 108 lub 54 GB, obsługiwane przez osiem dysków XCD, aż do jednego dysku XCD każdy. Parowanie partycji z domenami NUMA pozwala na pracę dyspozytora w czasie wykonywania i przestrzenne rozmieszczanie alokacji, dzięki czemu zadanie trafia na dyski XCD znajdujące się najbliżej jego pamięci. SR-IOV wirtualizuje następnie partycje do maksymalnie ośmiu maszyn wirtualnych izolowanych sprzętowo, a izolacja jest wymuszana w samym systemie pamięci, niezależnie od uruchomionego trybu NUMA. MI355X oferował te same opcje partycji od jednej do ośmiu, więc granularność nie jest nowa; to, co CDNA 5 dodaje poniżej, to zachowanie prywatnego poziomu 2, a powyżej wirtualne pody na poziomie szafy, które omówiono w sekcji Helios.

AMD Helios

Pojedynczy procesor MI455X jest szybki. Jednak wraz z premierą AMD dołącza do grona producentów rozwiązań rackowych i rozwiązań o dużej skali.

Fizycznie Helios rezygnuje z tradycyjnych 19- i 21-calowych szaf rackowych na rzecz Open Rack Wide, formatu, który AMD pomogło opracować z Meta w OCP: szafa o szerokości 1.2 metra i głębokości 1.3 metra z 44 jednostkami organizacyjnymi przestrzeni pionowej. Wewnątrz 72 procesory graficzne (GPU) umieszczono w dwóch rzędach po dziewięć tac obliczeniowych, a sześć tac przełącznikowych ułożono między nimi jedna na drugiej. Każde połączenie między procesorem graficznym a przełącznikiem jest miedziane i poprowadzone przez cztery kasety kablowe z tyłu, dzięki czemu tace wysuwają się do serwisu, bez konieczności ręcznego odłączania kabli.

Cała szafa pobiera od 225 do 245 kW, w zależności od obciążenia, moc dostarczaną przez chłodzoną cieczą szynę zbiorczą o napięciu 50 V, a tylne kolektory tłoczą około 385 litrów chłodziwa na minutę z pętli. Same półki to solidny sprzęt: każda waży około 170 funtów (77 kg), a osadzenie 1,728 połączeń par różnicowych w półce przełącznika wymaga użycia siły około 690 funtów (300 kg), dlatego uchwyty krzywkowe biegną niemal przez całą szerokość półki.

Bloki konstrukcyjne

Taca obliczeniowa

W projekcie referencyjnym każda tacka obliczeniowa to samodzielny węzeł zbudowany z 4 modułów MI455X i 96-rdzeniowego procesora Venice SP7 o wysokiej częstotliwości taktowania 5 GHz. 16 gniazd DIMM mieści 1 TB pamięci DRAM w postaci 16 modułów DDR5 ECC RDIMM o pojemności 64 GB, z 5 gniazdami E1.S NVMe umieszczonymi na zewnątrz procesora. Platforma oferuje znacznie więcej: 16 kanałów pamięci Venice obsługuje przepustowość do 1.6 TB/s, a dzięki modułom RDIMM o pojemności 256 GB, które są obecnie najmocniejszymi modułami DDR5, 16-kanałowe gniazdo z 1 modułem DIMM na kanał osiąga pojemność 4 TB.

Podążając śladem NVIDII, procesor dołącza do spójnej domeny pamięci w technologii Infinity Fabric, zamiast kryć się za GPU jako zwykły host PCIe. AMD argumentuje, że stosunek CPU do GPU wynoszący 1:4 jest celowy: sam rdzeń przewyższa konkurencję, a szacunki AMD wskazują, że 5-gigahercowy rdzeń Zen 6 przewyższa o około 20% wydajność na rdzeń procesora Vera firmy NVIDIA. Ponieważ gniazdo jest standardowe SP7, klienci potrzebujący większej mocy obliczeniowej hosta mogą zainstalować dowolny model Venice, nawet flagowy z 256 rdzeniami. Jedno gniazdo Venice obsługuje również znacznie większą pojemność DDR5 niż konstrukcja hosta LPDDR, a jego przepustowość pamięci jest nasycona dla wszystkich 4 GPU poprzez łącza Infinity Fabric.

Warto przyjrzeć się bliżej połączeniu Infinity Fabric. Rozmawiając o połączeniu Venice-do-MI455X z George'em Cozmą z Chips and Cheese , zasugerował on, że spójne łącze opiera się na liniach PCIe procesora, tak jak EPYC od lat przenosi łącza gniazd xGMI przez PCIe PHY. Liczby potwierdzają tę teorię. Sygnały PCIe Gen 6 wynoszą 64 Gb/s na linię, a łącze x16 przy tej szybkości wynosi 128 GB/s w każdą stronę, czyli dokładnie tyle, ile dwukierunkowa wartość 256 GB/s podawana przez AMD na GPU. Własny schemat blokowy białej księgi CDNA 5 opisuje interfejs hosta Infinity Fabric z szybkością 64 Gb/s na linię, czyli dokładną szybkością sygnalizacji Gen 6. Teoria wyjaśnia również, dlaczego każdy SKU Venice spada: 4 GPU zużywają 64 z 128 linii procesora Gen 6, pozostawiając resztę wolną dla DPU, pamięci masowej i innych potrzeb systemu.

Przez każdą tackę obliczeniową przechodzą trzy oddzielne sieci, z których każda służy do innego zadania. Najbardziej konwencjonalnym rozwiązaniem jest front-end: pojedyncza jednostka DPU Pensando Salina 400G łączy węzeł ze standardową siecią centrum danych, którą omówimy bardziej szczegółowo później.

Drugim jest skalowanie poziome, czyli sieć łącząca szafy w klastry. Najprostszym sposobem na jego zrozumienie jest policzenie SerDess. Skalowanie poziome MI455X może wykorzystywać albo PCIe Gen 6 z przepustowością 64 Gb/s na linię, albo UALink128 z przepustowością 128 Gb/s, a karta sieciowa Vulcano 800 potrzebuje około 128 Gb/s w każdą stronę, aby utrzymać zasilanie portu 800 GbE. Przy prędkościach Gen 6 wymaga to pełnego łącza x16 na kartę sieciową, więc karta graficzna obsługuje 2 karty sieciowe; przy podwojonej przepustowości sygnału UALink128, łącze x8 wykonuje to samo zadanie na połowie SerDes, więc karta graficzna obsługuje 3, co jest konfiguracją oferowaną przez Helios. Tak czy inaczej, przeskok UALink128 to nic innego jak prywatny przewód między kartą graficzną a kartą sieciową; sama sieć zaczyna się w Vulcano. Każda karta sieciowa obsługuje port 800 GbE obsługujący transporty zgodne ze standardem UEC, w tym MRC, wielościeżkowy protokół OpenAI opracowany we współpracy z AMD i innymi partnerami. Fizycznie karty sieciowe znajdują się na 2 niestandardowych płytach głównych na tackę, z których każda zawiera 4 lub 6 układów ASIC Vulcano, co odpowiada konfiguracjom 2 na kartę graficzną i 3 na kartę graficzną. W pełnym rozmieszczeniu oznacza to 12 kart sieciowych na tackę i 2,400 Gb/s skalowalnej przepustowości na kartę graficzną. Ponieważ karty sieciowe są podłączone do kart graficznych, a procesor nie znajduje się na ścieżce, ruch między szafami nigdy nie trafia do łącza hosta.

Trzecim elementem jest skalowalność, czyli struktura, która sprawia, że ​​Helios jest systemem o prawdziwej skali rackowej. Każdy procesor graficzny (GPU) obsługuje 36 łączy UALoE, które obsługują semantykę pamięci UALink przez sieć Ethernet ESUN. Każde łącze zapewnia przepustowość 400 Gb/s, co daje łącznie 3.6 TB/s przepustowości dwukierunkowej na procesor graficzny. Łącza te wychodzą z tyłu tacy w kierunku tac przełączników, przenosząc ruch pamięciowy, który łączy 72 procesory graficzne w jeden pod z pamięcią współdzieloną.

Tacka przełączników

Następnie, tacki przełączników, a najbardziej uderzającą cechą jest to, jak bardzo przeciętny jest ich krzem. Każda z 6 tacek mieści 2 układy ASIC Broadcom Tomahawk 6, te same układy przełączników Ethernet, które firmy hyperscaler wdrażają w swoich sieciach Leaf-Spine, z których każdy obsługuje 512 linii 200G.

Każdy procesor graficzny (GPU) wysyła 3 łącza UALoE (każde łącze UALoE to 2 linie 200G) do każdego z 12 przełączników, a 144 łącza opuszczają każdą tackę obliczeniową przez tylne kasety kablowe. Każdy Tomahawk kończy zatem 216 łączy z prędkością 400 Gb/s, przesyłając 21.6 TB/s przepustowości dwukierunkowej, podczas gdy każdy procesor graficzny zachowuje pełne 36 łączy (72 linie 200G) i 3.6 TB/s. Przełączniki nie potrzebują niczego nadzwyczajnego, aby to osiągnąć: enkapsulacja UALoE to prosty protokół warstwy 2, przekazywanie opiera się na statycznym programowaniu adresów MAC, które układy Ethernet oferują od dwóch dekad, a kontrola przepływu to standardowe, priorytetowe sterowanie przepływem.

Dzięki pojedynczej warstwie nigdy nie występują problemy z przeciążeniem centrów danych: nie ma wielowarstwowego incastingu, a każdy GPU znajduje się dokładnie o jeden przeskok od każdego innego, o stałym opóźnieniu. W porównaniu z siecią mesh, podejście przełączane pozwala również pojedynczemu przepływowi przejąć przepustowość całej ścieżki, gdy obciążenie jej potrzebuje, i utrzymuje wszystkie GPU w równej odległości. Dzięki temu harmonogramowanie nie musi uwzględniać lokalizacji i zapewnia każdemu łączu taką samą ochronę przed awariami.

Odporność na awarie

Helios traktuje awarię sprzętu jako czynnik wpływający na projekt. W tej skali zawsze coś się psuje: niestabilny kabel, utracony pakiet, przełącznik wyłączony w celu aktualizacji oprogramowania sprzętowego, awaria modułu obliczeniowego. Struktura jest zbudowana tak, aby żadne z tych zdarzeń nie przerywało pracy. Utracone pakiety są odzyskiwane poprzez retransmisję, a gdy łącze, kabel lub przełącznik ulegnie awarii, ruch automatycznie przekierowuje go po krótkiej przerwie, a obciążenie jest kontynuowane na pozostałym paśmie, zamiast restartować się od punktu kontrolnego.

Topologia 12-płaszczyznowa sprawia, że ​​degradacja jest płynna, a 3-kierunkowe paskowanie ustala rozmiar kroku. Utrata 1 z 3 połączeń, którymi GPU łączy się z przełącznikiem, powoduje, że ta płaszczyzna zachowuje dwie trzecie swojej przepustowości. Utrata całego Tomahawka powoduje, że każdy GPU traci 1/12 swojej przepustowości skalowania, podczas gdy układ all-to-all nadal działa na pozostałych 11 płaszczyznach. Nawet utrata całej tacy przełączników, 2 z 12 przełączników, kosztuje każdy GPU szóstą część swojej przepustowości bez zerwania łączności, ponieważ żaden GPU nie jest zależny od pojedynczego przełącznika, aby dotrzeć do innego. Dla porównania, Vera Rubin NVL72 rozkłada każdy GPU na 36 układów ASIC NVSwitch 6 w 9 tackach, więc awaria tacy przełącznika kosztuje tam bliżej dziewiątej części. NVIDIA kupuje mniejsze kroki degradacji z 3 razy większą liczbą układów ASIC przełączników; AMD odpowiada, że ​​12 przełączników o wyższej podstawie oznacza mniej komponentów, kabli i złączy, które mogą ulec awarii. W przypadku cyklu szkoleniowego mierzonego w tygodniach różnica między utratą jednej szóstej przepustowości sieci a utratą zadania stanowi całkowitą ekonomikę stojaka.

Wirtualne kapsuły

Ta sama maszyneria, która partycjonuje strukturę wokół awarii, może partycjonować ją celowo. AMD nazywa tę konstrukcję Virtual Pods lub vPods, a jednostką jest węzeł obliczeniowy: dowolna kombinacja 18 węzłów 4-GPU w szafie może być odgrodzona w izolowanym podcie, od 1 węzła dla małego dzierżawcy do większości szafy dla dużego zadania szkoleniowego. Izolacja jest egzekwowana w sprzęcie struktury, poniżej tego, co zdecyduje harmonogram. vPod jest powiązany ze swoim dzierżawcą; inne pody nie mają dostępu do jego pamięci ani ruchu, a szyfrowanie AES-256-GCM z prędkością łącza na każdym łączu UALoE, z obsługą kluczy klastra należących do klienta, sprawia, że ​​tensory jednego dzierżawcy są nieprzejrzyste dla następnego. Gościnna maszyna wirtualna obejmująca kilka GPU ma swoją domenę bezpieczeństwa rozszerzoną transparentnie na wszystkie z nich, bez konieczności zaufania systemowi operacyjnemu hosta. Firma NVIDIA rozwiązała ten sam problem w swoich szafach NVL72, dzieląc domenę NVLink na partycje za pomocą usługi pośredniczącej IMEX, dzięki której węzły mogą eksportować i importować pamięć do siebie nawzajem; vPody są odpowiednikiem rozwiązań UALoE, więc operatorzy korzystający z flot GB200 lub GB300 uznają tę koncepcję za znajomą.

W przypadku awarii zasobnika obliczeniowego promień rażenia zatrzymuje się na jego vPodzie: obciążenie uruchamia się ponownie od punktu kontrolnego, podczas gdy wszystkie inne pody działają bez zmian, a granica dzierżawcy pełni również funkcję granicy awarii. Problem partycjonowania jest również zagnieżdżony w całym systemie, ponieważ pojedynczy MI455X może podzielić się na nawet 8 maszyn wirtualnych SR-IOV, dzięki czemu ta sama szafa może obsługiwać jednego klienta obsługującego wszystkie 72 procesory GPU jako jeden pod lub nawet 576 dzierżawców z segmentami GPU, z izolacją sprzętową na każdym poziomie tej hierarchii.

Samolot zarządzający

Za obsługę tego wszystkiego odpowiada dedykowany stos oprogramowania, który kieruje się tą samą teorią otwartości co sprzęt. AMD Fabric Manager (AFM) to płaszczyzna sterowania: wykrywa i konfiguruje strukturę 72 GPU z bezdotykowym uruchamianiem, dzięki czemu samo włączenie szafy wystarczy do uruchomienia wszystkich 72 GPU, a następnie weryfikuje okablowanie kasety kablowej pod kątem błędów montażowych, dzieli szafę na vPody i koordynuje przekierowywanie i odzyskiwanie danych opisane powyżej. Nie ma dedykowanej tacy zarządzania. AFM działa na procesorach zarządzających poszczególnych szaf przełączników jako 3 redundantne instancje rozproszone na 6 szafach z rozproszoną bazą danych między nimi, więc utrata jednej z szaf przełączników nie wpływa na płaszczyznę sterowania, a interfejs API REST skierowany na północ udostępnia strukturę kontrolerom klastra zarządzającym wieloma szafami.

Pod maską AFM zapożycza swoją infrastrukturę ze świata chmury natywnej, zbudowanego na standardowych kontrolerach w stylu Kubernetes z agentami na każdej tacy, i obsługuje szczegóły struktury, których użytkownicy nigdy nie chcą widzieć, aż do przypisywania identyfikatorów akceleratorów, których UALink używa do adresowania każdego GPU. Jest to również warstwa obserwacji szafy. Pojedynczy pulpit śledzi wykorzystanie GPU i struktury, stan łącza i zdarzenia awarii; gdy coś ulegnie awarii, pokazuje trwające prace naprawcze i generuje alerty, które operatorzy mogą podłączyć do własnych narzędzi. Powyższy zrzut ekranu przedstawia AFM obserwujący klaster Helios w laboratoriach AMD. Zarządzanie działa w paśmie lub poza pasmem, więc diagnostyka i konfiguracja nigdy nie zakłócają działających obciążeń. Przełączniki pod AFM działają pod kontrolą sieciowego systemu operacyjnego zbudowanego na SONiC, otwartym systemie operacyjnym (NOS), a AMD twierdzi, że dodatki UALoE będą przesyłane strumieniowo i udostępniane za pośrednictwem standardowych interfejsów API gNMI. Nad szafą znajduje się Rack Infrastructure Manager, który odpowiada za cykl życia węzłów i przełączników, zasilanie i wykrywanie wycieków, a Cluster Controller łączy Helios z Kubernetes i Slurm w celu planowania.

Helios kontra NVIDIA Vera Rubin NVL72

Przyjrzyjmy się zatem, jak wypada to na tle oferty firmy NVIDIA, którą Helios faktycznie wprowadzi na rynek: Vera Rubin NVL72.

Metryka stojaka	AMD Helios	Vera Rubin NVL72
GPU	72 MI455X	72 Rubin
procesory	18 Wenecja	36 Vera
Pojemność HBM	31TB	20.7TB
Szerokość pasma HBM	1.7 PB/s	1.58 PB/s
Skalowanie na procesor GPU	3.6 TB/s	3.6 TB/s
Skalowanie stojaka	260 TB/s	260 TB/s
Skalowanie poziome na procesor GPU	2,400 Gb / s	1,600 Gb / s
Przełączniki skalowania	12 Tomahawków 6	36 NVSwitch 6
Format stojaka	ORW o podwójnej szerokości	MGX jednoszeroki

Na papierze wyniki przechylają się na korzyść AMD: o 50% więcej HBM, ten sam współczynnik skalowania 3.6 TB/s na GPU z o jedną trzecią mniej układów ASIC przełączających oraz o 50% większa przepustowość skalowania poziomego na GPU. Wewnętrzne testy AMD przekładają te specyfikacje na wydajność, osiągając od 10 do 15% więcej tokenów na sekundę na GPU w systemie Kimi K2 Thinking i do 30% więcej tokenów na dolara. Są to wyniki AMD w porównaniu z opublikowanymi danymi NVIDII, a nie niezależnymi pomiarami, ale wyznaczają one poprzeczkę, według której AMD oczekuje oceny. Bardziej interesujące różnice kryją się w sposobie, w jaki każdy projekt łączy swoje GPU ze światem zewnętrznym.

Zacznij od skalowania poziomego. Karty sieciowe MI455X są bezpośrednio podłączone do karty graficznej (GPU). Według SemiAnalysis, Rubin tego nie robi: według SemiAnalysis, pakiet nie posiada PCIe do obsługi obu kart sieciowych ConnectX-9, więc są one podłączone do procesora Vera, a ruch z GPU odbywa się okrężną drogą: z Rubin do NVLink-C2C, Vera, PCIe do ConnectX-9. To obejście generuje opóźnienie i podwaja obciążenie łącza C2C. Dzięki jednoczesnemu obciążeniu obliczeniowemu, ruchowi hosta i sieci, część przepustowości łącza C2C Vera jest przeznaczana na przesyłanie danych z kart sieciowych, a efektywna przepustowość hosta, jaką otrzymuje GPU, spada poniżej 1.8 TB/s.

Matematyka przepustowości dodatkowo to komplikuje. Każdy MI455X oferuje skalowalność 2,400 Gb/s, podczas gdy Rubin oferuje 1,600 Gb/s, więc Helios obsługuje więcej sieci na jeden flop. Symulacje AMD dotyczące treningu z 8,000 GPU przypisują trzeciej karcie sieciowej około 13% szybsze wykonywanie zadań.

Rubin atakuje w kwestii pamięci masowej, a powodem jest ponownie lokalizacja karty sieciowej. ConnectX-9 ma wbudowany przełącznik PCIe, dzięki czemu NVMe może być bezpośrednio połączony z kartą sieciową, a karta graficzna może pobierać dane przez pamięć masową GPUDirect bez ingerencji w procesor. MI455X nie ma sobie równych: jego pamięć masowa jest połączona z hostem Venice, więc wszystko, co jest związane z GPUDirect, musi przejść przez procesor i wrócić przez łącze Infinity Fabric. AMD zoptymalizowało ścieżkę sieciową i zapłaciło za to w kwestii pamięci masowej; NVIDIA poszła w przeciwnym kierunku. To, co ma większe znaczenie, zależy od tego, czy obciążenie ma przenosić aktywacje między kartami graficznymi, czy też przesyłać strumieniowo dane z dysku.

Co klienci mogą zmienić

Krótko mówiąc, wszystko powyżej opisuje projekt referencyjny AMD, a kilka z podanych liczb to wartości minimalne, powyżej których klienci mogą przejść. Najbardziej oczywistym przypadkiem jest procesor hosta. Vera Rubina jest dostępna w jednej, ustalonej konfiguracji; Venice w obudowie Helios to standardowy moduł z gniazdem SP7, a AMD potwierdziło, że każdy model Venice będzie dostępny bez modyfikacji specyficznych dla Helios. Obudowa referencyjna wykorzystuje 96-rdzeniowy moduł 5 GHz, ponieważ jednowątkowa prędkość zapewnia zasilanie procesorów graficznych. Mimo to nic nie stoi na przeszkodzie, aby klient skonfigurował swoją wersję z 256-rdzeniowym modelem flagowym lub Venice-X z 1,152 MB pamięci L3 w stosie, co pozwala na przetwarzanie wstępne wymagające dużej ilości pamięci podręcznej.

Pamięć i sieć działają na tej samej zasadzie gniazd i gniazd. Referencyjny 1 TB pamięci DRAM to 16 skromnych modułów RDIMM o pojemności 64 GB; gęstsze moduły DIMM zajmują tackę o pojemności 4 TB, a moduł MRDIMM-12800 odblokowuje pełną przepustowość 1.6 TB/s w Venice. Po stronie sieci, konfiguracja może zmniejszyć liczbę kart sieciowych z 3 na GPU do 2 w przypadku zwykłego PCIe Gen 6; każdy port Vulcano może działać jako 1x800G, 2x400G, 4x200G lub 8x100G w sieciach Tomahawk 5 lub Tomahawk 6, a potok P4 opuszcza transport, RoCEv2, MRC lub coś zastrzeżonego, zgodnie z wyborem operatora. Nawet płaszczyzna zarządzania jest wymienna, ponieważ przełącznik NOS to SONiC z otwartym kodem źródłowym, a AFM udostępnia całą sieć poprzez swoje północne API.

Budżet mocy również zależy od gniazda. Superchipy NVIDII mają jedną wspólną obudowę: Vera to jednostka o mocy 450 W z limitowanym segmentem, a najnowsze generacje pod obciążeniem kierują moc w stronę procesorów graficznych. AMD nie podało, czy referencyjny projekt ogranicza, czy przesuwa moc hosta, ale w przypadku projektu AMD, to klient może dostosować system do wyższego poboru mocy bez nadmiernego jej poboru.

Podstawy PCIe łącza hosta, rozpakowane z powrotem w sekcji tacki obliczeniowej, otwierają ostatnie drzwi, tym razem otwarcie spekulacyjne. Venice obsługuje konfiguracje 2P, a wybrane platformy hostów AI mogą obsługiwać 2P z maksymalnie 160 użytecznymi liniami PCIe, zamieniając szerokość między gniazdami xGMI na wejścia/wyjścia. Klient mógłby teoretycznie zbudować tackę dwugniazdową, aby dopasować stosunek CPU do GPU 1:2 w NVIDII, lub przestroić łącza xGMI, aby zwiększyć efektywną przepustowość CPU do GPU. Nic nie wskazuje na to, że ktokolwiek buduje coś takiego już dziś, i żadne z tych rozwiązań nie zniweluje przepaści do NVLink-C2C z przepustowością 1.8 TB/s. Prawdziwym problemem jest to, kto trzyma ster: w Heliosie to klient decyduje o hoście, jego pamięci, mocy i potencjalnie o topologii, a superukład NVIDII nie przekazuje klientowi steru w ogóle.

Salina DPU

Wracając do sieci front-end, którą wcześniej odłożyliśmy na później. Salina, Pensando DPU trzeciej generacji firmy AMD, to karta 400G z w pełni programowalną ścieżką danych P4, co oznacza, że ​​nowa enkapsulacja, hak telemetryczny lub transport to aktualizacja oprogramowania sprzętowego, wdrażana na żywo bez utraty ruchu. Usługi dostawcze obejmują już listę kontrolną front-end: SDN z VXLAN lub NVGRE, zapora sieciowa z obsługą stanu skalowalna do milionów reguł, IPsec z prędkością łącza, PSP, DTLS lub niestandardowe szyfrowanie, NAT i równoważenie obciążenia. Jest to również najbardziej przetestowany w boju układ krzemowy w szafie. Pensando DPU obsługują hiperskalery od 2019 roku; Salina jest obecnie liderem wdrożeń w firmach Microsoft, Oracle i IBM; Oracle przypisuje linii 5-krotny wzrost SDN, a jeden hiperskaler odzyskał 22 rdzenie procesora na serwer, przenosząc na niego operacje wejścia/wyjścia.

Pamięć masowa to drugi etap. Salina udostępnia hostowi urządzenia NVMe-over-Fabrics, wirtualizując zdalne pule dysków SSD przez TCP lub RDMA z szyfrowaniem, digestami i kompresją wykonywanymi na karcie. W systemie Helios dodaje sztuczkę z ery agentów: silnik pamięci kontekstowej prezentuje emulowane urządzenie KV, więc przepełniona pamięć podręczna KV jest przepełniana pamięcią DRAM procesora, lokalnym dyskiem SSD lub zdalną pamięcią masową i przesyłana strumieniowo z powrotem do HBM z prędkością łącza, zamiast być ponownie obliczana. Jak zauważono w porównaniu z Rubinem, w systemie MI455X brakuje pamięci masowej GPUDirect; to odciążenie KV to częściowa odpowiedź AMD na potrzeby obsługi ruchu, na którym najbardziej zależy.

To właśnie tutaj tkwią nasze zastrzeżenia. Różnica w przepustowości jest oczywista: Salina to karta 400G, a BlueField-4 dostarczany do szaf Vera Rubin podwaja ją do 800G z 64-rdzeniowym procesorem Grace i współdzielonym ConnectX-9. Różnica w oprogramowaniu jest bardziej dyskusyjna, ale realna. DOCA firmy NVIDIA oferuje programistom skonteneryzowane, predefiniowane usługi programowalne w zwykłych językach C i C++; P4 to specjalistyczny język dataplane, którego większość zespołów nigdy nie dotykała. Porównanie nie polega na porównaniu „katalogu DOCA kontra gołego P4”, ponieważ Salina dostarcza swoje główne usługi w całości, a wdrażający ją hiperskalerzy wybrali ją częściowo dlatego, że P4 pozwala nowym protokołom, takim jak MRC, trafić do oprogramowania układowego przed cyklem krzemowym kogokolwiek. Prawdziwą różnicą jest to, komu służy programowalność. Elastyczność Saliny to broń dla zespołów hiperskalowalnych biegle posługujących się AMD i P4; DOCA to zestaw narzędzi, z których może skorzystać przeciętny programista korporacyjny. Dla szerszego rynku wdrożenie oprogramowania firmy NVIDIA jest prostsze i AMD o tym wie.

ROCm.AI

Skoro mowa o oprogramowaniu, AMD zarezerwowało jedną z ważniejszych zapowiedzi dla samego stosu. ROCm.AI, który pojawi się w sierpniu, to próba AMD, aby platforma GPU była od podstaw oparta na agentach. AI Skills integruje ROCm z agentami kodowania, z których korzystają już programiści: Claude, Codex, Cursor i Gemini, dzięki czemu instalacja, obsługa i debugowanie w Instinct odbywa się w prosty sposób. Hyperloom to odważniejszy element: optymalizator bez ingerencji człowieka, który profiluje obciążenie, dostraja konfigurację obsługi, przepisuje jądra GPU i weryfikuje wyniki, podczas gdy operator śpi. AMD twierdzi, że stale optymalizuje obecnie około 14 000 modeli, a demonstracja na żywo wycisnęła z MiniMax M3 o 38% więcej przepustowości. Pod agentami, FlyDSL wprowadza do Pythona niemalże asemblerową kontrolę, ROCm przechodzi na stały, 6-tygodniowy cykl wydawniczy, a AMD twierdzi, że ROCm.AI zapewnia średnio 3.3-krotny wzrost inferencji i 2.4-krotny wzrost wydajności treningowej w porównaniu z ROCm 7 na identycznym sprzęcie. ROCm 7 już odnotował realną poprawę; teraz AMD stawia na sztuczną inteligencję, aby przyspieszyć tempo.

Można śmiało powiedzieć, że najważniejszym slajdem sesji poświęconej oprogramowaniu był ten dotyczący sprzętu. AMD stanowczo podkreśliło, że każda wartość została zmierzona, a podtekstem było stwierdzenie, że układ MI455X jest dziś sprawny, działa i szybki w granicach ROCm. Dane: 20 TB/s w dekodowaniu MLA FP8, 20 PFLOPS w obliczeniach FP4, 3.2 TB/s w przepustowości skalowania w górę i 190 GB/s w skalowaniu w poziomie. Podczas sesji pytań i odpowiedzi AMD przyznało, że wynik FP4 to pomiar MAMF (max-achievable-matmul-FLOPS), wykonywany przy kształcie macierzy, który najbardziej pasuje do urządzenia, co jest standardową praktyką w tej klasie benchmarków. Jest to również odważne wyznanie: AMD otwarcie przyznaje, że MI455X utrzymuje około 50% swojego szczytowego wyniku MXFP4 wynoszącego 40.26 PFLOPS, co jest wartością, którą większość dostawców by zataiła.

AMD nazywa to najwyższą zademonstrowaną mocą obliczeniową spośród wszystkich akceleratorów dostępnych na rynku, i tu pojawia się ziarno niepewności. FP4 AMD to OCP MXFP4, a NVIDII to NVFP4. To różne receptury: NVFP4 stosuje ułamkową skalę FP8 do każdego 16-elementowego bloku plus skalę tensorową na wierzchu, podczas gdy bazowy MXFP4 używa bardziej zgrubnej skali potęgi dwójki na 32 elementy, więc NVFP4 FLOP wymaga więcej pracy niż MXFP4 FLOP. CDNA 5 może również stosować skalowanie ułamkowe do MXFP4, ale AMD nie ujawniło, której receptury użyto do pomiaru. Przebiegi Rubin MAMF i MI455X MAMF nie mierzą tej samej matematyki, więc porównania FP4 różnych dostawców ustalają się dopiero na poziomie aplikacji: tokenów na sekundę z równą dokładnością. Przedstawiono prognozy dotyczące zmierzonych prędkości, ale liczby te są najbardziej uczciwe w porównaniu z poprzednią generacją procesorów AMD, gdzie wzrosty od 3x do 4x są jednoznaczne.

AMD ma też pewną przeciwwagę. To wstępne wyniki ROCm.AI na zupełnie nowym krzemie, więc jeśli już, to zaniżają one poziom, jaki osiągnie ręcznie dostrojone wdrożenie produkcyjne. Prawdziwy werdykt zapadnie, gdy te szafy osiągną poziom hiperskalowalny.

Myśli końcowe

Helios to najbardziej kompletny system, jaki AMD kiedykolwiek wprowadziło na rynek, i pierwszy, który spotyka się z NVIDIA bezpośrednio w skali rack, a nie chip po chipie. Wyniki wskazują na przewagę AMD w obszarach, które decydują dziś o wydajności AI: o 50% więcej HBM na GPU, parzystość skalowania w górę z Rubinem, o 50% większa przepustowość skalowania poziomego i, według własnego modelowania AMD, nawet o 30% więcej tokenów na dolara. Równie ważne jest to, jak to się stało: przełączniki Tomahawk od producenta, otwarte standardy od formatów liczbowych po szafę oraz host z gniazdem, który pozostawia ostateczną konfigurację w rękach klienta. NVIDIA zachowuje rzeczywiste zalety w łączu hosta C2C, DPU i jego oprogramowaniu, ale po raz pierwszy ogólny argument sprzętowy na papierze przemawia na korzyść AMD.

Kupujący się z tym zgadzają. OpenAI, Meta, Anthropic, Microsoft i Oracle to niektóre z firm, które według AMD wdrażają Helios, a AMD podkreśla, że ​​szafy rack są już w produkcji. Podążając śladami NVIDII, plan rozwoju jest teraz realizowany corocznie: seria MI500 oparta na CDNA 6 pojawi się w 2027 roku z nową generacją HBM oraz miedzianymi i optycznymi połączeniami, a seria MI600 jest już w fazie rozwoju na 2028 rok.

Pozostaje oprogramowanie i po raz pierwszy od lat nie kończymy historii procesorów graficznych AMD tym zastrzeżeniem. ROCm 7 zniwelował realne braki, ROCm.AI pojawi się w sierpniu z wymiernymi zyskami, a termin premiery wynosi teraz stałe sześć tygodni. Ważne jest również, kto kupuje. Laboratoria i hiperskalery podpisujące te umowy współpracują z AMD w zakresie projektowania i zatrudniają wystarczającą liczbę inżynierów, aby rozwiązać wszelkie napotkane problemy. Przedsiębiorstwa potrzebujące gotowego zestawu rozwiązań to zupełnie inna historia i ten rynek na razie pozostaje w rękach NVIDII. Ale Helios został stworzony dla hiperskalerów i laboratoriów AI, a dla nich sprzęt jest gotowy, oprogramowanie dotrzymuje kroku, a serwery są już w sprzedaży. AMD nigdy nie było w silniejszej pozycji.