Stawka AMD na standardy Google mierzy się z Nvidią w teście sieci AI Vulcano
AMD zaprezentowało kartę sieciową Pensando Vulcano AI NIC o przepustowości 800 Gb/s, mimo że Nvidia pozostaje liderem w ściśle zintegrowanych rozwiązaniach sieciowych dla dużych klastrów GPU. Powiązanie amd google ma znaczenie, ponieważ obie firmy wspierają otwarte standardy połączeń, które mają zapewnić nabywcom infrastruktury większy wybór sprzętu. Google nie ogłosiło jednak planów wdrożenia Vulcano.
Vulcano rozwiązuje kosztowny problem w centrach danych AI. Akceleratory mogą pozostawać bezczynne, gdy przeciążenia sieci, utrata pakietów lub powolne przywracanie działania opóźniają komunikację między serwerami. AMD twierdzi, że trzy karty Vulcano mogą zapewnić 2,4 terabita na sekundę przepustowości scale-out dla każdego GPU.
Ta wartość daje AMD wyraźny nagłówek, ale nie automatyczne zwycięstwo. Nvidia już sprzedaje sprawdzone połączenie GPU, Spectrum-X Ethernet, InfiniBand, NVLink, przełączników i oprogramowania sieciowego. Vulcano musi pokazać, że otwarte, programowalne podejście oparte na Ethernecie może zapewnić porównywalną spójność operacyjną bez konieczności korzystania z kompletnego stosu jednego dostawcy.
Co zmieniło AMD Pensando Vulcano 800
Vulcano czyni sieć centralnym elementem platformy AI AMD na skalę szafy rackowej, zamiast dodatkiem podłączanym po wyborze GPU.
AMD publicznie przedstawiło kartę Pensando Vulcano 800 AI NIC 23 lipca 2026 r. Adapter zaprojektowano do sieci scale-out, która łączy akceleratory między serwerami i szafami rackowymi, gdy ich lokalne połączenia scale-up osiągają praktyczne ograniczenia.
Każda karta zapewnia połączenie sieciowe o przepustowości 800 Gb/s. AMD obsługuje konfiguracje z maksymalnie trzema kartami NIC przypisanymi do jednego GPU, co pozwala osiągnąć reklamowaną łączną przepustowość 2,4 Tb/s.
Układ ten różni się od traktowania jednego adaptera sieciowego jako współdzielonego punktu końcowego dla kilku akceleratorów. Wiele niezależnych połączeń może zwiększyć dostępną przepustowość, jednocześnie zapewniając ruchowi więcej niż jedną trasę w klastrze.
AMD nazywa to architekturą wielopłaszczyznową. Płaszczyzna sieciowa to niezależna ścieżka danych zawierająca własne połączenia i zasoby przełączające. Podział ruchu między płaszczyzny może ograniczyć wpływ uszkodzonego łącza lub przeciążonej trasy.
Firma twierdzi również, że Vulcano może obniżyć koszty przełączania nawet o 33 procent. AMD przypisuje ten szacunek mniejszej liczbie kabli i transceiverów w swojej konfiguracji referencyjnej, a nie uniwersalnej redukcji w każdym wdrożeniu.
Jej deklaracja wydajności również wymaga takiego zastrzeżenia. AMD twierdzi, że Vulcano może skrócić czas realizacji zadań AI nawet o 13 procent. Wynik ten jest firmowym benchmarkiem powiązanym z określonymi obciążeniami i założeniami systemowymi.
Żadnego z tych odsetków nie należy traktować jako niezależnie zweryfikowanej wydajności dla każdego klastra. Nabywcy potrzebują testów na poziomie obciążeń, obejmujących przełączniki, optykę, topologię, wersje oprogramowania, zachowanie przy awariach i wykorzystanie akceleratorów.
Podstawowy mechanizm pozostaje jednak wiarygodny. Trening rozproszony wielokrotnie wymienia parametry modeli i wyniki pośrednie między akceleratorami. Jedna opóźniona ścieżka może wstrzymać operację kolektywną, pozostawiając drogie GPU w oczekiwaniu na pozostałe.
Wnioskowanie rozproszone tworzy inny wzorzec ruchu. Może przenosić żądania, stany modeli i dane z pamięci podręcznej między systemami wraz ze zmianami zapotrzebowania użytkowników. Przewidywalne opóźnienia mogą być równie ważne jak szczytowa przepustowość.
Vulcano odpowiada na te wzorce za pomocą programowalnej logiki transportowej, kontroli przeciążeń, izolacji usterek i diagnostyki podczas działania. AMD twierdzi, że operatorzy mogą aktualizować część tego zachowania za pomocą oprogramowania zamiast wymieniać krzem sieciowy.
Karta NIC wykorzystuje programowalne silniki P4 trzeciej generacji. P4 to język i architektura służące do definiowania sposobu przetwarzania pakietów przez urządzenia sieciowe. Pozwala dostawcom zmieniać wybrane zachowania przekazywania i transportu w granicach obsługiwanych przez sprzęt.
Projekt AMD Vulcano obejmuje również opcje łączności PCIe i UALink. Ta elastyczność pozwala adapterowi łączyć się z CPU lub akceleratorami w różnych projektach szaf rackowych.
Produkt reprezentuje zatem coś więcej niż szybszy port Ethernet. AMD próbuje skoordynować GPU, CPU, krzem sieciowy, otwarte transporty i oprogramowanie zarządzające jako jeden system na skalę szafy rackowej.
Dlaczego powiązanie standardów AMD i Google ma znaczenie
Relacja amd google to sojusz na rzecz standardów, a nie dowód, że Google Cloud wybrał Vulcano do produkcji.
AMD i Google należały w 2024 r. do pierwotnych firm stojących za grupą promującą Ultra Accelerator Link. Uczestniczyły w niej również Broadcom, Cisco, Hewlett Packard Enterprise, Intel, Meta i Microsoft.
UALink jest ukierunkowany na komunikację scale-up między akceleratorami wewnątrz modułu obliczeniowego. Sieć scale-up tworzy ściśle połączoną domenę akceleratorów, podczas gdy sieć scale-out łączy wiele serwerów lub domen w większej strukturze.
Role te nakładają się na granicy systemu, ale nie są wymienne. Vulcano obsługuje przede wszystkim ruch scale-out i scale-across. Jego interfejs UALink pomaga mu łączyć się bezpośrednio z akceleratorami w powstających otwartych architekturach rackowych.
Słowo kluczowe amd google może więc tworzyć mylne wrażenie. Żadne zweryfikowane ogłoszenie nie mówi, że Google współprojektowało Vulcano, kupiło tę kartę NIC ani zobowiązało się udostępnić dla niej zasoby Google Cloud.
Znaczenie Google wynika z jego pozycji jako operatora hiperskalowego i uczestnika prac nad standardami. Zaangażowanie firmy nadaje pracom nad otwartymi połączeniami większą wagę, ponieważ Google rozumie wymagania dotyczące ruchu, niezawodności i zarządzania flotą w dużych systemach AI.
Konsorcjum UALink opublikowało pierwszą specyfikację służącą do łączenia nawet 1 024 akceleratorów w ramach jednego modułu. Wsparcie kilku operatorów chmurowych i dostawców układów może zmniejszyć ryzyko, że standard będzie zależny od jednego producenta.
Vulcano obsługuje również Ultra Ethernet do komunikacji między systemami. Specyfikacja UEC definiuje stos komunikacyjny oparty na Ethernecie dla AI i obliczeń wysokiej wydajności.
Ultra Ethernet zmienia więcej niż tylko surową prędkość łącza. Obejmuje dostarczanie pakietów, zarządzanie przeciążeniami, wielościeżkowość, bezpieczeństwo i semantykę komunikacji wymaganą przez ściśle zsynchronizowane obciążenia.
AMD rozwija również Multipath Reliable Connection, czyli MRC. Ten transport może rozdzielać dane między kilka ścieżek, zachowując niezawodne dostarczanie i reagując na przeciążenia lub awarie.
AMD twierdzi, że współtworzyło MRC z OpenAI dla dużych środowisk treningowych. Firma wdrożyła ten transport w swojej wcześniejszej karcie Pollara 400 NIC i twierdzi, że Vulcano będzie go obsługiwać, gdy nowsza platforma stanie się powszechnie dostępna.
Według wdrożenia MRC firmy AMD, Pollara została zweryfikowana w laboratoriach firmy z klastrami Instinct MI350 i MI355. AMD twierdzi, że OpenAI uczestniczyło w tej walidacji.
MRC może działać z routingiem segmentowym przez IPv6, który daje operatorom bezpośrednią kontrolę nad ścieżkami pakietów. Może także współpracować z routingiem wielościeżkowym o równym koszcie i dynamicznym równoważeniem obciążenia.
Ta elastyczność wspiera szerszy argument AMD. Operatorzy powinni mieć możliwość wdrażania nowego zachowania transportowego bez wymiany każdego przełącznika, kabla i procesu zarządzania wokół klastra akceleratorów.
Udział Google w pracach nad standardami wzmacnia ten argument, lecz nie potwierdza deklaracji produktowych AMD. Specyfikacje definiują wspólne zachowanie, natomiast wdrożenia produkcyjne ujawniają jakość implementacji.
Pisemny standard nie może zagwarantować stabilnych czasów realizacji zadań podczas przeciążeń. Nie dowodzi też, że narzędzia diagnostyczne szybko identyfikują usterki ani że różni dostawcy interpretują każdą opcjonalną funkcję identycznie.
Dla nabywców historia amd google dotyczy zatem strategicznego dostosowania. Obie firmy wspierały alternatywy dla zamkniętych struktur akceleratorowych, lecz Vulcano musi zdobyć adopcję dzięki mierzalnej wydajności klastrów.
To rozróżnienie ma znaczenie dla zespołów zakupowych. Powinny one oceniać Vulcano jako produkt AMD w powstającym środowisku wielu dostawców, a nie jako kartę sieciową rekomendowaną przez Google.
Mechanizm Vulcano to przepustowość plus programowalność
Najmocniejszym argumentem technicznym Vulcano nie jest samo 800 Gb/s, lecz połączenie wielu ścieżek, programowalnego transportu i szybkiego odzyskiwania sprawności po awarii.
Sieci AI obejmują zsynchronizowaną komunikację między wieloma punktami końcowymi. Podczas treningu operacje kolektywne łączą lub redystrybuują dane wytworzone przez każdy uczestniczący akcelerator.
Jeśli jeden przepływ napotka przeciążenie, cały krok treningowy może ulec spowolnieniu. Pozostałe GPU mogą zakończyć pracę lokalną, ale nie mogą przejść dalej, dopóki komunikacja kolektywna się nie zakończy.
Konwencjonalny Ethernet często rozdziela przepływy między ścieżki poprzez haszowanie ich informacji identyfikacyjnych. Duży przepływ może pozostać uwięziony na przeciążonej trasie, nawet gdy inna trasa ma niewykorzystaną przepustowość.
MRC zaprojektowano z myślą o bardziej celowym wykorzystaniu kilku ścieżek. Może dzielić ruch na części, reagować na warunki na ścieżkach i odzyskiwać sprawność bez zmuszania aplikacji do ponownego uruchamiania całej komunikacji.
Programowalne silniki przetwarzania pakietów Vulcano umieszczają część tej kontroli blisko krawędzi sieci. To położenie ma znaczenie, ponieważ karta NIC obserwuje ruch wchodzący do każdego serwera i go opuszczający.
Karta może także izolować usterki i przeprowadzać diagnostykę, gdy klaster pozostaje aktywny. AMD twierdzi, że funkcje te skracają czas napraw i pozwalają uniknąć części ogólnoklastrowych okien serwisowych.
Takie możliwości stają się cenne wraz ze wzrostem wielkości klastra. System z tysiącami komponentów doświadcza rutynowych awarii łączy, optyki, oprogramowania sprzętowego i przełączników, nawet gdy każdy komponent charakteryzuje się wysoką indywidualną niezawodnością.
Sieć musi degradować się w przewidywalny sposób, zamiast zamieniać pojedynczą awarię w zatrzymane zadanie. Wiele płaszczyzn zapewnia alternatywne ścieżki, podczas gdy logika transportowa decyduje, jak ruch powinien się między nimi przemieszczać.
Trzy karty NIC o przepustowości 800 Gb/s na GPU tworzą znaczną fizyczną pojemność. Łączna przepustowość nie oznacza jednak, że każde obciążenie będzie nieprzerwanie przesyłać 2,4 Tb/s użytecznych danych.
GPU, interfejs hosta, biblioteka kolektywna, topologia i zdalne punkty końcowe muszą wszystkie efektywnie dostarczać ruch. Narzut protokołu i synchronizacja obciążenia również ograniczają przepustowość na poziomie aplikacji.
Architektura AMD obsługuje zarówno połączenia hosta PCIe, jak i UALink. PCIe pozostaje znanym interfejsem dla CPU i urządzeń peryferyjnych. UALink jest ukierunkowany na bezpośrednią łączność akceleratorów z mniejszą zależnością od jednego dostawcy GPU.
Vulcano jest również powiązane z AMD Helios, projektem firmy na skalę szafy rackowej wykorzystującym akceleratory Instinct serii MI400 i procesory EPYC Venice. AMD pozycjonuje kartę NIC jako domyślny komponent sieci scale-out dla Helios.
Ta integracja daje AMD większą kontrolę nad walidacją. Firma może testować firmware, biblioteki komunikacyjne ROCm, zachowanie akceleratorów i telemetrię sieciową jako skoordynowaną platformę.
Programowalność wiąże się jednak z kosztami operacyjnymi. Modyfikowalny potok przetwarzania pakietów wymaga zdyscyplinowanej kontroli wersji, testowania, obserwowalności i procesów wycofywania zmian.
Zespoły sieciowe muszą wiedzieć, które ustawienia firmware i transportu były aktywne podczas nieudanego zadania. Potrzebują także narzędzi, które korelują zdarzenia przeciążeniowe z wydajnością aplikacji.
Etykieta P4 nie eliminuje tych wymagań. Daje jedynie AMD i zatwierdzonym operatorom większą swobodę w zmienianiu sposobu działania obsługiwanych funkcji przetwarzania pakietów.
Otwarte standardy tworzą kolejne wyzwanie implementacyjne. Dwa produkty mogą deklarować obsługę tej samej specyfikacji, a jednocześnie różnić się opcjonalnymi funkcjami, limitami wydajności lub interfejsami zarządzania.
Testy interoperacyjności będą więc decydujące. Kupujący potrzebują dowodów, że Vulcano działa niezawodnie z przełącznikami innych firm, modułami optycznymi, oprogramowaniem do routingu i systemami monitorowania.
Strona AMD AI NIC podkreśla znaczenie hiperskalerów i dostawców usług chmurowych. Tacy klienci dysponują zespołami inżynierskimi potrzebnymi do testowania złożonego zachowania sieci na dużą skalę.
Wdrożenia w przedsiębiorstwach mogą postępować wolniej. Wiele firm kupuje kompletne systemy, ponieważ nie ma personelu zdolnego samodzielnie integrować akceleratorów, NIC-ów, przełączników, oprogramowania układowego i ustawień transportu.
Vulcano nadal może pomóc takim organizacjom za pośrednictwem zweryfikowanych systemów Helios lub usług chmurowych. Stopień otwartości będzie zależeć od tego, ilu dostawców zaoferuje obsługiwane konfiguracje.
To jest praktyczny sprawdzian stojący za tym produktem. Programowalność musi obniżać koszt dostosowania sieci bez przerzucania nadmiernej pracy integracyjnej na klienta.
Zintegrowany stos Nvidia pozostaje głównym rywalem
AMD rzuca wyzwanie kontroli Nvidia nad architekturą systemów AI, a nie jedynie konkuruje z kolejnym adapterem Ethernet 800 Gb/s.
Nvidia może łączyć swoje akceleratory przez NVLink w domenie scale-up. Następnie oferuje Quantum InfiniBand lub Spectrum-X Ethernet do komunikacji między serwerami i szafami rack.
Spectrum-X łączy przełączniki Nvidia, SuperNICs, kontrolę przeciążeń, telemetrię i oprogramowanie. Nvidia testuje te komponenty jako kompleksowy system ściśle powiązany z jej platformą GPU.
Taka integracja może uprościć rozliczalność. Gdy zadanie AI osiąga słabsze wyniki, klient może poprosić jednego dostawcę o zbadanie akceleratora, karty sieciowej, przełącznika, oprogramowania układowego i bibliotek komunikacyjnych.
Nvidia twierdzi, że Spectrum-X Ethernet może poprawić wydajność sieci 1,6 raza względem konwencjonalnego Ethernetu. Podobnie jak dane AMD, jest to deklaracja dostawcy oparta na określonych konfiguracjach.
Spectrum-X obsługuje również otwarte sieciowe systemy operacyjne, w tym SONiC. Konkurencja nie jest zatem prostym starciem otwartego Ethernetu z całkowicie zamkniętą alternatywą.
Rzeczywista różnica dotyczy kontroli i wyboru komponentów. Nvidia optymalizuje zdefiniowane połączenie własnego krzemu i oprogramowania, podczas gdy AMD podkreśla programowalne urządzenia i specyfikacje branżowe działające między dostawcami.
Ścisła integracja może zapewniać spójne działanie, ale może też zwiększać zależność od harmonogramu wydań jednego dostawcy. Konstrukcja wielodostawcowa może oferować większy wybór, lecz prace kwalifikacyjne stają się trudniejsze.
Vulcano musi udowodnić, że jego otwarte podejście nie poświęca przewidywalnej wydajności. Sama szczytowa przepustowość nie rozstrzygnie tej kwestii.
Operatorzy klastrów AI analizują czas ukończenia zadań, opóźnienia ogonowe, odzyskiwanie po awariach, efektywne wykorzystanie GPU i izolację wydajności między dzierżawcami. Śledzą również zużycie energii i liczbę wymaganych modułów optycznych.
Deklaracja AMD o 13-procentowym skróceniu czasu ukończenia jest istotna, ponieważ mierzy wynik aplikacji. Jednak publicznie dostępne materiały nie potwierdzają uniwersalnej przewagi nad Spectrum-X ani InfiniBand.
Deklaracja o 33-procentowym obniżeniu kosztów przełączania także wymaga ostrożnej interpretacji. Mniejsza liczba kabli i transceiverów może zmniejszyć wydatki na sprzęt, nakład pracy instalacyjnej i liczbę punktów awarii.
Jednak konfiguracja trzech NIC-ów na GPU może w innym miejscu zwiększać liczbę adapterów, interfejsów hosta i złożoność zarządzania. Całkowity wynik zależy od topologii i punktu odniesienia porównania.
Nvidia ma kolejną przewagę dzięki wdrożonym systemom. Jej produkty sieciowe już działają w dużych klastrach AI, zapewniając klientom referencje implementacyjne i ugruntowane praktyki wsparcia.
AMD nie wchodzi na rynek bez doświadczenia. Pensando wcześniej dostarczało DPU i Pollara AI NICs, a AMD współpracowało z dostawcami chmurowymi i producentami systemów w zakresie sieci dla centrów danych.
Vulcano pojawia się jednak wraz z kilkoma innymi zmieniającymi się elementami. Helios wprowadza nowe akceleratory Instinct, procesory EPYC, połączenia UALink i rozwijający się otwarty stos oprogramowania.
Problem w dowolnej warstwie może opóźnić kwalifikację. Klienci mogą wybrać dojrzałą konfigurację, nawet gdy inna konstrukcja obiecuje lepszą elastyczność doboru komponentów.
Ryzyko jest największe dla organizacji poszukujących krótkoterminowej mocy do trenowania. Ich priorytetem często jest szybkie uruchomienie klastra, a nie maksymalizacja przyszłego wyboru dostawców.
Kupujący o dłuższym horyzoncie mogą bardziej cenić otwarte podejście. Infrastruktura działa przez kilka generacji akceleratorów, podczas gdy modele i wzorce komunikacji zmieniają się znacznie szybciej.
Programowalność P4 Vulcano może pomóc AMD reagować na te zmiany. Nowe mechanizmy kontroli przeciążeń lub zachowanie transportu mogłyby być dostarczane przez oprogramowanie w granicach możliwości sprzętu.
Nvidia również może aktualizować swój stos. Korzysta także z kontrolowania większej liczby komponentów, co może przyspieszać skoordynowane zmiany w całym systemie.
Główna rywalizacja ma więc charakter operacyjny. AMD musi pokazać, że wybór oparty na standardach może dorównać niezawodnością, narzędziami i walidacją zintegrowanej platformie Nvidia.
Obecność Google w grupach zajmujących się otwartymi interkonektami zwiększa zaufanie, że alternatywa ma poważne wsparcie branży. Nie niweluje to jednak zainstalowanej bazy Nvidia ani jej przewagi wykonawczej.
Co AMD nadal musi udowodnić
Największą niewiadomą jest to, czy opublikowane przez Vulcano zyski przetrwają niezależne testy w realistycznych klastrach wielodostawcowych.
Publiczne dane AMD opisują maksymalne możliwości i wybrane porównania. Nie przedstawiają jeszcze szerokiego zestawu wyników firm trzecich dotyczących trenowania, rozproszonego wnioskowania i mieszanych obciążeń.
Wartość 2,4 Tb/s oznacza łączną przepustowość scale-out z trzech NIC-ów 800 Gb/s. Nie stanowi gwarancji, że jedna aplikacja GPU będzie stale otrzymywać taką szybkość transmisji danych.
Niezależne recenzje powinny mierzyć użyteczną przepustowość przy przeciążeniach. Powinny również raportować rozkłady opóźnień, zachowanie odzyskiwania pakietów i czas bezczynności akceleratorów.
Testowanie awarii ma równie duże znaczenie jak prędkość w stanie ustalonym. Recenzenci powinni wyłączać łącza, wprowadzać utratę pakietów, restartować przełączniki i zmieniać opóźnienie ścieżek, gdy rozproszone zadanie pozostaje aktywne.
MRC potrzebuje następnie dowodów interoperacyjności. AMD twierdzi, że transport obsługuje kilka podejść do przekazywania ruchu, ale klienci będą oczekiwać zweryfikowanych kombinacji NIC-ów, przełączników, oprogramowania układowego i oprogramowania routingu.
Kolejnym nierozstrzygniętym szczegółem jest powszechna dostępność. AMD podało, że Vulcano jest kwalifikowane dla klastrów Instinct serii MI400, podczas gdy dostępność Helios jest oczekiwana w 2026 roku.
Kwalifikacja nie jest tym samym co szerokie wdrożenie. Produkt może spełniać cele projektowe, podczas gdy dostawcy systemów, dostawcy chmurowi i przedsiębiorstwa nadal potrzebują miesięcy walidacji.
Kwestia Google pozostaje szczególnie ważna, ponieważ główne słowo kluczowe sugeruje bezpośrednią relację. Google wspierało UALink, ale żadne publiczne dowody nie potwierdzają, że Google Cloud zaoferuje instancje oparte na Vulcano.
Wdrożenie przez Google byłoby istotnym sygnałem adopcji. Pokazałoby, że hiperskaler dysponujący wewnętrzną wiedzą z zakresu sieci uznał Vulcano za odpowiednie do użycia produkcyjnego.
Brak takiego ogłoszenia nie stanowi dowodu przeciwko produktowi. Hiperskalerzy często oceniają kilka architektur i ujawniają tylko wybrane wdrożenia.
Gotowość oprogramowania również wymaga analizy. ROCm musi koordynować komunikację zbiorową z siecią, jednocześnie udostępniając użyteczną telemetrię harmonogramom i zespołom operacyjnym.
Szybki NIC nie zrekompensuje niewydajnych bibliotek komunikacji zbiorowej ani słabego rozmieszczania obciążeń. Świadomość sieci musi dotrzeć do warstwy orkiestracji, jeśli operatorzy chcą uzyskiwać spójne czasy realizacji zadań.
Na uwagę zasługuje także bezpieczeństwo. Programowalne urządzenia rozszerzają możliwości konfiguracji, a każda ścieżka oprogramowania układowego wymaga kontroli podpisywania, aktualizacji, dostępu i wycofywania zmian.
Otwarte specyfikacje nie tworzą automatycznie otwartego zarządzania. Klienci powinni sprawdzić, które funkcje wymagają narzędzi AMD i czy produkty obserwowalności innych firm mogą uzyskać dostęp do niezbędnej telemetrii.
Deklaracja kosztowa wymaga pełnego rozliczenia systemowego. Uczciwe porównanie powinno obejmować adaptery, przełączniki, kable, moduły optyczne, przestrzeń w szafach rack, energię, wsparcie i pracę inżynierów.
Zespoły oceniające Vulcano powinny zachowywać zapisy benchmarków w przeszukiwalnej bazie wiedzy inżynierskiej. Wersje oprogramowania układowego i szczegóły topologii mogą decydować o tym, czy późniejsze porównania pozostaną użyteczne.
Zespoły zakupowe powinny także oddzielić wymagania scale-up od scale-out. UALink, Ultra Ethernet, MRC i PCIe dotyczą różnych części ścieżki danych.
Mylenie tych warstw może tworzyć imponujące specyfikacje bez spójnego wdrożenia. Kupujący potrzebują architektury pokazującej, jak ruch przemieszcza się od jednego akceleratora do każdego istotnego punktu końcowego.
Kierunek techniczny AMD jest wiarygodny. Jej wyzwaniem jest przełożenie go na powtarzalne systemy, które klienci mogą zamawiać, wdrażać, monitorować i naprawiać.
Trzy sygnały rozstrzygną sprawę sieci AI Vulcano
Pozycja Vulcano stanie się jaśniejsza dzięki niezależnym wynikom klastrów, wskazanym klientom produkcyjnym i zweryfikowanej interoperacyjności wielodostawcowej.
Pierwszym sygnałem są niezależne testy kompletnych systemów Helios. Wyniki powinny porównywać czasy ukończenia zadań, wykorzystanie GPU, opóźnienia ogonowe i odzyskiwanie działania w kilku warunkach sieciowych.
Użyteczny test wskaże każdy komponent i wersję oprogramowania. Powinien rozróżniać przepustowość zmierzoną na łączu od przepustowości dostarczonej aplikacji AI.
Silne wyniki w kilku obciążeniach wsparłyby twierdzenie AMD, że Vulcano usuwa wąskie gardła komunikacyjne. Słabe lub niespójne wyniki zmniejszyłyby wartość jego nagłówkowej przepustowości.
Drugim sygnałem jest wskazane wdrożenie u hiperskalera lub w chmurze. Oracle omawiało infrastrukturę AMD w skali rack, podczas gdy OpenAI współpracowało z AMD nad walidacją MRC.
Google byłoby szczególnie istotne ze względu na zainteresowanie wyszukiwaniem amd google oraz swoją rolę w działaniach na rzecz otwartych interkonektów. Czytelnicy powinni jednak poczekać na bezpośrednie ogłoszenie wdrożenia.
Klient musi opisać coś więcej niż ocenę rozwiązania. Dostępność produkcyjna, wielkość klastra, obsługiwane obciążenia i oczekiwania dotyczące poziomu usług stanowiłyby mocniejsze dowody.
Trzecim sygnałem jest interoperacyjność wykraczająca poza referencyjny projekt oparty wyłącznie na AMD. Vulcano powinno działać z wieloma dostawcami przełączników, sieciowych systemów operacyjnych, modułów optycznych i platform zarządzania.
Udana interoperacyjność wzmocniłaby argument ekonomiczny za otwartą siecią AI. Pozwoliłaby klientom zmieniać wybrane komponenty bez przeprojektowywania całego klastra.
Ograniczona kompatybilność osłabiłaby ten argument, nawet jeśli Helios działałby dobrze jako zamknięta konfiguracja referencyjna. System mógłby stać się w praktyce zintegrowany mimo oparcia na otwartych specyfikacjach.
Nvidia nie będzie stać w miejscu, podczas gdy AMD ukończy tę walidację. Spectrum-X już łączy Ethernet oparty na standardach z kontrolą Nvidia nad otaczającą platformą.
Przyszłe porównania muszą więc wykorzystywać aktualne produkty obu firm. Zwycięstwo nad starszym Ethernetem nie dowodzi przewagi nad najnowszą siecią Nvidia.
Dla programistów bezpośredni efekt pozostanie na razie pośredni. Większość zetknie się z Vulcano poprzez instancje chmurowe, zarządzane klastry lub systemy wybrane przez zespoły infrastruktury.
Mimo to sieć wpływa na czas trenowania, opóźnienia wnioskowania, dostępność mocy i koszt usług. Ulepszenia w warstwie sieci mogą zmienić to, które obciążenia AI pozostają ekonomicznie praktyczne.
Kupujący z przedsiębiorstw powinni prosić dostawców o dowody na poziomie obciążeń, a nie podsumowania prędkości portów. Powinni również zażądać testów awarii i jasnego zakresu wsparcia między dostawcami.
Kluczowe pytanie nie brzmi już, czy Ethernet jest w stanie obsłużyć ruch AI. Chodzi o to, czy otwarty system Ethernet może zapewniać powtarzalne wyniki w skali, w której jedno opóźnione połączenie marnuje tysiące akceleratorów.
AMD przedstawiło teraz konkretną odpowiedź w postaci Vulcano, MRC, Ultra Ethernet i Helios. Google oraz inni partnerzy standaryzacyjni zwiększają wiarygodność otwartego podejścia, ale nie gwarantują skutecznej realizacji planu przez AMD.
Warto śledzić pierwsze niezależne benchmarki Helios, pierwsze wskazane z nazwy wdrożenie Vulcano w chmurze oraz pierwsze szeroko zakrojone raporty dotyczące interoperacyjności. Te trzy sygnały rozstrzygną, czy zakład AMD na standardy stanie się alternatywą produkcyjną, czy pozostanie atrakcyjną specyfikacją.
