AMD SemiAnalysis: wyzwanie AMD rzucone CUDA zderza się z rzeczywistością skali szafy serwerowej

AMD zaprezentowało swoje najsilniejsze dotąd wyzwanie dla CUDA podczas Advancing AI 2026, mimo dwóch problemów operacyjnych, które nadal odróżniają wiarygodną konkurencję od niezawodnego wdrożenia. Najnowsza ocena AMD SemiAnalysis wskazuje na duże postępy w oprogramowaniu, ulepszenia jąder generowanych przez agentów oraz znacznie bardziej konkurencyjną architekturę MI455X. Wskazuje również na niestabilne wewnętrzne klastry deweloperskie i trudne zwiększanie produkcji Helios.

To połączenie tworzy właściwą historię. AMD nie wygląda już na firmę blokowaną przez z natury bezużyteczny stos oprogramowania. Obecnie ograniczają ją raczej realizacja, zdolność testowania oraz trudność przekształcenia 72 zaawansowanych akceleratorów w niezawodny system produkcyjny.

Nvidia pozostaje głównym rywalem, ponieważ CUDA to więcej niż interfejs programistyczny. Obejmuje dojrzałe biblioteki, sprawdzone frameworki, recepty wdrożeniowe, sieci oraz lata zgromadzonej wiedzy deweloperów. AMD musi osłabić znaczenie tych przewag, jednocześnie dostarczając sprzęt działający w skali szafy serwerowej.

AMD Advancing AI 2026 zmieniło zasady rywalizacji

AMD przeszło od obiecywania ulepszeń pojedynczych akceleratorów do prezentowania kompletnej alternatywy dla infrastruktury AI klasy frontier.

Podczas wydarzenia w San Francisco, które odbyło się 22 i 23 lipca, AMD skoncentrowało swoją argumentację na Instinct MI455X, projekcie szafy Helios oraz ROCm.AI. Firma podkreśliła również partnerstwa z Anthropic, Microsoftem, OpenAI, Cerebras i innymi dużymi nabywcami infrastruktury AI.

Wydarzenie Advancing AI pozycjonowało MI455X jako akcelerator AMD o najwyższej wydajności, a ROCm.AI jako platformę programistyczną wspieraną przez AI. AMD poinformowało, że Anthropic planuje wdrożyć do dwóch gigawatów GPU serii MI450. Microsoft również planuje wdrożyć infrastrukturę opartą na Helios.

Te zobowiązania klientów są ważne, ponieważ wyprowadzają AMD poza odizolowane demonstracje benchmarków. Laboratoria frontier i dostawcy chmurowi muszą obsługiwać tysiące akceleratorów w zmieniających się modelach, frameworkach i konfiguracjach sieciowych. Układ osiągający dobre wyniki w jednym kontrolowanym teście nie staje się automatycznie realnym rozwiązaniem dla całej floty.

Helios jest odpowiedzią AMD na ten wymóg na poziomie floty. Projekt łączy 72 GPU MI455X, 18 CPU EPYC „Venice”, sieć Pensando oraz przełączaną strukturę scale-up. Sieć scale-up łączy akceleratory wewnątrz szafy, aby mogły współpracować przy jednym dużym obciążeniu.

AMD twierdzi, że pełna szafa zapewnia 31 TB pamięci HBM4 i 260 TB/s łącznej przepustowości scale-up. Podaje 2,9 eksaFLOPS mocy obliczeniowej FP4 i 1,4 eksaFLOPS FP8. Są to szczytowe specyfikacje firmy, a nie niezależne pomiary trwałej wydajności aplikacyjnej.

Fizyczny projekt oznacza również istotną zmianę architektoniczną. MI300X do MI355X wykorzystywały topologię point-to-point z ośmioma GPU. Helios łączy 72 GPU za pośrednictwem 12 przełączników Broadcom Tomahawk 6 w jednopoziomowej sieci all-to-all.

Czyni to MI455X pierwszą poważną odpowiedzią AMD na 72-GPU systemy Nvidii w skali szafy serwerowej. Jednocześnie naraża AMD na inną klasę problemów inżynieryjnych. Integralność sygnału, okablowanie, chłodzenie, integracja przełączników, uzysk produkcyjny i łatwość serwisowania wpływają teraz na wydajność równie mocno jak sam akcelerator.

Wydarzenie zmieniło więc główne pytanie. Nabywcy nie muszą już pytać, czy AMD potrafi wyprodukować szybki układ AI. Muszą zapytać, czy AMD potrafi dostarczyć kompletny system z przewidywalnym zachowaniem oprogramowania.

To rozróżnienie wyjaśnia, dlaczego nowe spojrzenie AMD SemiAnalysis jest bardziej przychylne, ale nie bezkrytyczne. Analiza przypisuje AMD znacznie większą szansę na zdobycie udziałów niż wcześniej. Wskazuje też dwa ryzyka, które nadal mogą wykoleić ten postęp.

Jedno ryzyko kryje się pod demonstracjami oprogramowania: wewnętrzna infrastruktura testowa AMD pozostaje niestabilna. Drugie znajduje się wewnątrz fizycznej szafy: Helios ma podobno mierzyć się z powolnym i skomplikowanym zwiększaniem produkcji.

Ryzyka te są bezpośrednio powiązane. AMD potrzebuje niezawodnych klastrów sprzętowych do ciągłego testowania oprogramowania, podczas gdy klienci potrzebują niezawodnego oprogramowania, zanim zaakceptują nowy sprzęt na dużą skalę. Słabość po którejkolwiek stronie spowalnia całą platformę.

Dlaczego fosa CUDA Nvidii wreszcie znajduje się pod presją

Rozwój agentowy zmniejsza przewagę pracy stojącą za CUDA, ale nie niweluje przewagi Nvidii w zweryfikowanych systemach.

CUDA stała się fosą, ponieważ deweloperzy mogli osiągnąć działającą wydajność bez przebudowywania każdej warstwy. Nvidia inwestowała w kompilatory, zoptymalizowane biblioteki, narzędzia do debugowania, oprogramowanie komunikacyjne i integracje z powszechnie używanymi frameworkami. Każde udane wdrożenie dodawało dokumentację, przykłady i wyszkolonych inżynierów.

Ta kumulacja stworzyła pętlę sprzężenia zwrotnego. Więcej klientów przyciągało więcej inwestycji w oprogramowanie, co czyniło sprzęt Nvidii bezpieczniejszym wyborem dla kolejnego klienta. Nawet gdy konkurencyjny krzem oferował atrakcyjne specyfikacje, migracja wiązała się z kosztami technicznymi i organizacyjnymi.

Nowy argument AMD atakuje pracochłonny element tej pętli. Agenci programistyczni mogą przeszukiwać repozytoria, identyfikować błędy, proponować poprawki, uruchamiać testy i powtarzać eksperymenty wydajnościowe. Mogą równolegle realizować wiele wąskich zadań, zmniejszając znaczenie samej liczby inżynierów.

SemiAnalysis opisuje wykorzystywanie małych zespołów z agentami programistycznymi do uruchamiania nowych modeli w vLLM i SGLang. Agenci pobierają recepty wdrożeniowe, tworzą infrastrukturę testową, monitorują fizyczne maszyny wykonawcze, diagnozują błędy silników i zgłaszają poprawki upstream. Według raportu taki przepływ pracy nie był możliwy z tą samą szybkością kilka miesięcy wcześniej.

Ma to szczególne znaczenie dla jąder. Jądro GPU to niskopoziomowy kod, który odwzorowuje operację matematyczną na jednostki wykonawcze procesora i hierarchię pamięci. Jakość jądra może przesądzić o tym, czy mocne specyfikacje sprzętowe przełożą się na użyteczną wydajność aplikacji.

AMD wprowadziło GEAK, czyli Generating Efficient AI-Centric Kernels, aby zautomatyzować część tej pracy. System profiluje obciążenie, proponuje implementacje, mierzy je na rzeczywistym sprzęcie, sprawdza poprawność i zachowuje udane zmiany.

Framework GEAK firmy AMD może być ukierunkowany na backendy Triton, TileLang, FlyDSL, HIP i Composable Kernel. Jego czwarta wersja rozszerza proces z pojedynczych jąder na kompletne obciążenia obsługowe vLLM lub SGLang.

To rozróżnienie ma znaczenie. Przyspieszenie jednej operacji daje niewielką wartość, gdy aplikacja po prostu staje się ograniczona w innym miejscu. Optymalizacja end-to-end pozwala agentowi znaleźć kolejne wąskie gardło i ustalić, czy lokalne przyspieszenie poprawia całkowitą przepustowość obsługi.

Hyperloom dodaje orkiestrację wokół tego procesu. Profiluje usługę inferencyjną, wybiera wąskie gardła, uruchamia agentów optymalizacyjnych i waliduje kandydatów przez porównania end-to-end. AMD przedstawia go jako część szerszego przepływu pracy ROCm.AI.

SemiAnalysis znalazło dowody, że to podejście może przynosić mierzalne zyski. Raport przytacza około 21,8% poprawy end-to-end po jednej przeróbce gęstej warstwy liniowej MI355X. Wskazuje również obciążenia, w których poprawa zatrzymała się blisko znacznie niższego pułapu.

Te zastrzeżenia są ważne, ponieważ wygenerowany kod może wykorzystywać słabości benchmarku. Agent może zmienić test, wywołać niedozwoloną zoptymalizowaną bibliotekę lub przypadkowo zmierzyć niezmieniony poziom bazowy. Szybszy wynik nic nie znaczy, gdy porównanie jest nieważne.

AMD dodało zabezpieczenia przed tymi zachowaniami. GEAK może zapobiegać edycji chronionych plików testowych, natomiast powiązane narzędzia ewaluacyjne wykrywają zakodowane na sztywno sygnały sukcesu i wywołania zakazanych bibliotek. Mechanizmy te przekształcają optymalizację agentową w system inżynieryjny, a nie demonstrację generowania kodu.

To najsilniejszy mechanizm osłabiający fosę CUDA. Otwarty kod daje agentom więcej materiału do analizowania, modyfikowania i testowania. Komponenty kompilatora AMD, jądra i wkład w frameworki zapewniają dostępną powierzchnię dla automatycznych ulepszeń.

Jednak sam otwarty dostęp nie gwarantuje jakości produkcyjnej. Agenci przyspieszają zarówno użyteczne zmiany, jak i wiarygodnie wyglądające błędy. Platforma, która weryfikuje wygenerowaną pracę, staje się ważniejsza wraz ze wzrostem liczby zmian.

Nvidia odczuwa więc presję w jednej części swojej przewagi — przepustowości prac inżynieryjnych. Nadal chroni ją inna część: głębokość walidacji i doświadczenie z wdrożonymi systemami.

Werdykt AMD SemiAnalysis dotyczący oprogramowania jest lepszy, ale niepełny

ROCm dokonał mierzalnych postępów, ale AMD nadal brakuje dyscypliny ciągłego testowania wymaganej do domyślnego zaufania.

Najwyraźniejszą poprawą jest bliższe dostosowanie AMD do frameworków upstream. Wsparcie upstream oznacza, że zmiany trafiają do głównych projektów vLLM lub SGLang, zamiast pozostawać w forkach specyficznych dla AMD. Zmniejsza to nakład pracy na utrzymanie i zapewnia użytkownikom bardziej znajomą ścieżkę wdrożenia.

SemiAnalysis zauważa, że stabilne wsparcie ROCm weszło do wydań upstream vLLM w styczniu 2026 roku, a następnie do kompilacji nightly. Zmiany z czerwca dodały mirrory AMD i bramki dla ośmiu ważnych grup testów. Obejmowały one uwagę, silnik, poprawność API, multimodalność i obsługę speculative decoding.

SGLang również dodał testy nightly dla rozproszonej inferencji MI355X. Testy obejmowały rozdzieloną obsługę dla nowych modeli, a później uwzględniły kombinacje uwagi, równoległości ekspertów i speculative decoding. Przeniosło to część konfiguracji AMD z jednorazowych recept do powtarzalnej walidacji.

Rozdzielona inferencja oddziela etapy obsługi modelu między różne zasoby. Prefill przetwarza prompt wejściowy, a decode generuje kolejne tokeny. Operatorzy mogą niezależnie dostrajać te etapy, lecz muszą niezawodnie przenosić dane pamięci podręcznej klucz-wartość między węzłami.

Oprogramowanie MoRI AMD obsługuje część tego transportu i komunikacji ekspertów. ATOMesh dodaje routowanie, równoważenie obciążenia uwzględniające cache i orkiestrację. Łącznie komponenty te pokazują, że AMD rozumie kierunek rozwoju inferencji produkcyjnej.

Wydajność również się poprawiła. Przegląd SemiAnalysis wskazuje 18-krotną poprawę interaktywności dla jednej konfiguracji Kimi K2.5 po poprawkach upstream AITER i vLLM. AMD osobno raportuje skromniejsze wzrosty przepustowości w kilku konfiguracjach bazowych.

Istotą nie jest największa wybrana liczba. Znacząca zmiana polega na tym, że optymalizacje coraz częściej pojawiają się w publicznych frameworkach, receptach i ciągłej integracji. Klienci mogą sprawdzić tę ścieżkę, zamiast polegać na prywatnej demonstracji.

Mimo to ciągła integracja, czyli CI, pozostaje najbardziej widoczną słabością oprogramowania AMD. CI automatycznie buduje i testuje zmiany, aby regresje zostały wykryte przed scaleniem kodu. Testy blokujące scalenie zapewniają silniejszą ochronę, ponieważ błąd zatrzymuje zmianę.

SemiAnalysis informuje, że AMD nie osiągnęło celu, jakim było objęcie co najmniej 90% zakresu bramek vLLM CUDA do Advancing AI 2026. Przypisuje to częściowo niestabilnym klastrom wewnętrznym oraz przeniesieniu przez kierownictwo zasobów z zespołu vLLM.

Raport stwierdza również, że testowanie przez AMD inferencji Kubernetes z interfejsem sieciowym Pollara pozostawało daleko za zakresem ConnectX Nvidii. Kubernetes ma znaczenie, ponieważ wiele produkcyjnych usług inferencyjnych korzysta z niego do planowania i zarządzania rozproszonymi obciążeniami.

Twierdzenia te pochodzą z szczegółowej analizy, a nie od AMD. AMD nie potwierdziło publicznie zgłaszanych realokacji klastrów ani stojących za nimi wewnętrznych decyzji dotyczących mocy obliczeniowej.

Mimo to zewnętrzne symptomy wspierają szersze obawy. Publiczne dashboardy nie wykazują jeszcze pełnej zgodności z CUDA. Na niektórych kluczowych ścieżkach AMD brakuje automatycznych bramek wydajnościowych, testów dokładności lub runnerów sprzętowych.

Słabość ta staje się poważniejsza, gdy agenci generują więcej kodu. Szybsze tworzenie poprawek zwiększa liczbę kombinacji wymagających testowania. Modele, formaty numeryczne, rozmiary batchy, topologie sieci i strategie równoległości mogą wchodzić ze sobą w nieoczekiwane interakcje.

Konfiguracja może generować płynne odpowiedzi, a mimo to zwracać błędne wyniki. SemiAnalysis zidentyfikowało wcześniejsze problemy z dokładnością dotyczące rozproszonego attention i ścieżek expert-parallel. Kilka z nich naprawiono, lecz co najmniej jeden spadek dokładności zależny od batcha pozostawał otwarty w chwili publikacji.

Ten przykład pokazuje różnicę między dostępnością funkcji a dojrzałością platformy. Optymalizacja może działać w wybranej konfiguracji, nie działając niezawodnie w warunkach produkcyjnych. Fosa CUDA częściowo kryje się właśnie w tych nieefektownych przypadkach brzegowych.

AMD poprawiło swoje podejście do oprogramowania, tempo wydań, dokumentację i udział w projektach upstream. Kolejny krok ma charakter organizacyjny. Klastry testowe muszą stać się stabilną infrastrukturą, a nie tymczasową mocą obliczeniową, którą zespoły tracą podczas wewnętrznych skoków zapotrzebowania.

Helios MI455X zamienia wyzwanie chipowe w wyzwanie produkcyjne

Helios jest technicznie wiarygodny, lecz jego skomplikowana konstrukcja szafy rack tworzy test produkcyjny, z którym AMD nie mierzyło się dotąd na taką skalę.

Konstrukcja szafy Helios wykorzystuje otwarte standardy w całym racku, sieci scale-up i sieci scale-out. Daje to klientom większy wybór komponentów niż ściśle własnościowy system.

Otwartość generuje również koszty koordynacji. Nvidia projektuje swoje GPU, sieć NVLink, komponenty NVSwitch, produkty sieciowe i systemy referencyjne jako jedną pionowo zintegrowaną platformę. AMD w większym stopniu polega na komponentach dostępnych na rynku oraz zewnętrznych partnerach produkcyjnych.

Helios wykorzystuje przełączniki Broadcom Tomahawk 6 w sieci scale-up. Według SemiAnalysis każdy GPU łączy się przez 72 linie 200-gigabitowego Ethernetu, zapewniając 1,8 TB/s jednokierunkowej przepustowości scale-up. Dwanaście chipów przełączników łączy 72 akceleratory w racku.

Topologia stanowi istotne ulepszenie w porównaniu z wcześniejszymi systemami AMD z ośmioma GPU. Powinna umożliwić pracę większych obciążeń w jednej domenie scale-up. Pozostawia jednak część pojemności przełączników niewykorzystaną, ponieważ komponent dostępny na rynku nie został zaprojektowany specjalnie wokół 72 GPU.

Większe obawy dotyczą fizycznej transmisji sygnałów. SemiAnalysis podaje, że wiele połączeń scale-up wymaga retimerów, które przywracają jakość zdegradowanych sygnałów elektrycznych na długich ścieżkach miedzianych. Jego analiza łańcucha dostaw szacuje, że na jeden rack przypada ponad 550 ethernetowych retimerów Broadcom.

Raport stwierdza ponadto, że około 85% istotnych połączeń w jednej planowanej instalacji wymaga retimingu. Dodaje to komponenty, zużycie energii, ciepło, pracę walidacyjną i potencjalne punkty awarii. AMD nie potwierdziło niezależnie tych szacunków.

Helios wykorzystuje również złożoną miedzianą płytę połączeniową i kable flyover. Kable flyover mogą poprawiać integralność sygnału, unikając dłuższych ścieżek na płytce drukowanej. Mogą jednak komplikować montaż, przepływ powietrza, dostęp serwisowy i produkcję wielkoseryjną.

SemiAnalysis szacuje, że jeden rack zawiera 10 368 różnicowych par miedzianych w połączeniach scale-up. Nawet gdy każde pojedyncze połączenie jest zrozumiałe, wielokrotne składanie i walidowanie tego systemu stanowi poważny problem produkcyjny.

Na tym polega ujęcie „piekła rampy produkcyjnej” w briefie. Sformułowanie to nie dowodzi, że Helios poniósł porażkę. Opisuje trudne przejście od działającego systemu referencyjnego do powtarzalnych systemów produkowanych na dużą skalę przez wielu partnerów.

AMD opisuje Helios jako projekt referencyjny, a nie gotowy produkt sprzedawany bezpośrednio przez AMD. Partnerzy OEM i ODM będą budować markowe systemy wokół tego projektu. Model ten poszerza bazę dostawców, lecz rozdziela odpowiedzialność między większą liczbę organizacji.

Spółka oczekuje wdrożeń wolumenowych w drugiej połowie 2026 roku. Zaangażowanie Microsoftu daje platformie istotną okazję do walidacji. Anthropic i inni ogłoszeni partnerzy dodają sygnały popytu, choć ogłoszona moc nie jest tym samym co zainstalowana i odebrana moc.

Sam MI455X ma mocne specyfikacje. AMD wymienia 432 GB pamięci HBM4 na akcelerator, architekturę CDNA 5 oraz natywne wsparcie dla kilku formatów niskiej precyzji. Architektura przyjmuje również rozmiar wave wynoszący 32 wątki, zbliżając część swojego modelu wykonawczego do rozwiązań Nvidia.

Ta konwergencja może zmniejszyć tarcia dla twórców kerneli. Uproszczona hierarchia pamięci i znajoma szerokość wykonania mogą ułatwić przenoszenie istniejącej wiedzy o optymalizacji. Natywne wsparcie NVFP4 pomaga też AMD uruchamiać checkpointy modeli opracowane wokół formatu Nvidia.

Żadna z tych funkcji nie eliminuje problemu racka. Konkurencyjny akcelerator staje się wartościowy komercyjnie dopiero wtedy, gdy klienci mogą odbierać, instalować, chłodzić, sieciować i obsługiwać systemy przy akceptowalnych uzyskach.

Warunki finansowe związane z dużymi zobowiązaniami dodają kolejną warstwę. SemiAnalysis charakteryzuje jedno porozumienie z OpenAI jako oferujące rabaty oparte na kapitale własnym, sięgające 105% przy określonych wynikach. Takie zachęty mogą stymulować adopcję, nie dowodząc zwykłego popytu rynkowego.

Ekonomia powiązana z kapitałem własnym różni się od bezpośredniego rabatu na sprzęt. Jej wartość zależy od zapisów umownych, przyszłej wartości akcji, kamieni milowych wdrożenia i sposobu księgowania. Publiczne raportowanie nie zapewnia wystarczających szczegółów, by traktować maksymalną wartość z nagłówków jako zrealizowaną korzyść.

Taka struktura komplikuje też porównania konkurencyjne. Efektywna ekonomika klienta może odzwierciedlać strategiczne finansowanie, a nie wyłącznie koszt akceleratora lub efektywność operacyjną. Kupujący powinni oddzielać zachęty umowne od mierzonej wydajności w przeliczeniu na dolara.

Właściwy test jest zatem fizyczny i operacyjny. Helios musi opuszczać fabryki partnerów, przechodzić testy odbiorcze, trafiać do klastrów produkcyjnych i utrzymywać dostępność przy ciągłych obciążeniach. Do tego czasu jego specyfikacje opisują potencjał, a nie zainstalowane możliwości.

AMD musi wygrać w rozproszonym inferencing, a nie w benchmarkach z przeszłości

Kolejną fosą jest zdolność łączenia sieci, harmonogramowania, przemieszczania pamięci i kerneli bez kruchych przypadków specjalnych.

Wydajność pojedynczego węzła była kiedyś użytecznym skrótem w porównywaniu akceleratorów. Obecnie takie porównanie obejmuje coraz mniejszą część obciążenia produkcyjnego. Inference na granicy możliwości coraz częściej rozkłada komponenty modelu i etapy obsługi na wiele węzłów.

Rzadkie modele mixture-of-experts wzmacniają tę zmianę. Modele te zawierają wiele wyspecjalizowanych sieci ekspertów, lecz aktywują tylko ich podzbiór dla każdego tokenu. Efektywna obsługa wymaga kierowania tokenów, wymiany danych, równoważenia ekspertów i zachowania wystarczającej pamięci na cache.

Szeroka równoległość ekspertów rozdziela tych ekspertów między większą liczbę GPU. Rozdzielone prefill i decode umieszczają różne fazy obsługi na wyspecjalizowanych zasobach. Cache offload przenosi zapisany kontekst między HBM, pamięcią systemową i magazynem danych.

Każda z tych technik może zapewnić atrakcyjny wynik w izolacji. Prawdziwym wyzwaniem jest ich kompozycja. Kwantyzacja, kernele attention, speculative decoding, routing ekspertów, transfer cache i zachowanie sieci muszą współpracować między modelami.

SemiAnalysis twierdzi, że ta kompozycyjność jest nowszą fosą Nvidia. CUDA pozostaje istotna, lecz jednostka konkurencji rozszerzyła się ze środowiska programistycznego do systemu rozproszonego inferencingu.

AMD ma wiarygodne komponenty. MoRI wspiera zdalny dostęp do pamięci na potrzeby komunikacji ekspertów i przemieszczania cache. AITER dostarcza zoptymalizowane kernele inferencyjne. ATOM i ATOMesh zapewniają funkcje wykonawcze oraz routingu. SGLang i vLLM oferują główne środowiska obsługi, których oczekują klienci.

Problemem jest nierówna integracja. Niektóre konfiguracje AMD łączą dezagregację, rozproszony attention, równoległość ekspertów i speculative decoding. Inne wymagają wyłączonego graph capture, poprawek specyficznych dla modelu lub wybranych rozmiarów batcha.

Oprogramowanie Helios pozostaje szczególnie wczesne. SemiAnalysis stwierdziło początkowe wsparcie architektury w PyTorch, ale ograniczone testowanie najcenniejszych ścieżek. Niektóre obrazy frameworków mogły budować się dla MI455X bez uruchamiania pełnych bramek dokładności lub wydajności na fizycznych runnerach MI455X.

Raport wykazał również wczesne wsparcie transferu cache klucz-wartość bez kompletnej integracji WideEP. Oznacza to, że AMD ma części rozproszonego stosu, ale nie ma jeszcze niezawodnej domyślnej konfiguracji obejmującej cały rack.

Nie czyni to ROCm nieistotnym. Precyzyjniej definiuje pozostałą pracę. AMD nie musi już udowadniać, że każdy pojedynczy komponent istnieje. Musi udowodnić, że komponenty te pozostają poprawne, gdy klienci je łączą.

Nvidia również odczuwa tu presję. Otwarte frameworki zmniejszają wartość utrzymywania ważnych możliwości w oprogramowaniu własnościowym. Projekty upstream mogą wchłaniać wsparcie dla wielu akceleratorów, interfejsów sieciowych i systemów transferu cache.

SemiAnalysis opisuje pomoc w połączeniu wkładów AMD z NIXL, biblioteką związaną z pracami Nvidia nad rozproszonym inferencingiem. Wsparcie AMD weszło później do projektu upstream, co pokazuje, że część granicy oprogramowania może stać się wspólną infrastrukturą.

Rozwój ten osłabia prostą narrację o uzależnieniu od dostawcy. Klienci korzystają, gdy warstwy transportu i orkiestracji obsługują kilka backendów sprzętowych. AMD zyskuje, ponieważ może poświęcać mniej godzin inżynieryjnych na utrzymywanie równoległych forków.

Nvidia nadal kontroluje tempo swojej zintegrowanej platformy. Jej zespoły sprzętowe i programistyczne mogą koordynować działania wokół określonej architektury racka. AMD musi sprawić, by otwartość przynosiła szybsze zbiorowe ulepszenia niż integracja Nvidia przynosi wewnętrznie.

Agentowe generowanie kerneli pomaga w lokalnej optymalizacji. Może również pomagać diagnozować awarie frameworków i tworzyć poprawki upstream. Nie może ustalać priorytetów organizacyjnych, gwarantować stabilnej pojemności testowej ani produkować złożonego racka.

Równowaga konkurencyjna zależy zatem od dwóch różnych form realizacji. AMD musi automatyzować ulepszanie oprogramowania, jednocześnie uprzemysławiając produkcję sprzętu. Nvidia musi bronić swojej zintegrowanej przewagi, nie pozwalając, by procesy i wielkość organizacji spowolniły jej reakcję.

Trzy sygnały pokażą, czy AMD może osłabić fosę CUDA

Ogłoszenia AMD nabierają strategicznego znaczenia dopiero wtedy, gdy równocześnie poprawiają się testowanie, dostawy i rozproszone obciążenia.

Pierwszym sygnałem jest publiczne pokrycie CI. AMD potrzebuje stabilnych runnerów MI455X i testów blokujących merge w vLLM, SGLang, PyTorch, sieciach oraz rozproszonym inferencingu. Widoczna równość bramek bezpośrednio odpowiedziałaby na obawy dotyczące niestabilnych wewnętrznych klastrów.

Silniejszy wynik obejmowałby bramki dokładności i wydajności dla kilku modeli, rozmiarów batchy, formatów numerycznych i topologii sieci. Przechodzenie skryptów demonstracyjnych nie wystarcza. Regresje muszą zatrzymywać zmiany, zanim dotrą one do użytkowników.

Jeśli AMD ustanowi takie pokrycie, teza o oprogramowaniu agentowym stanie się znacznie silniejsza. Agenci mogą szybko generować i optymalizować kod, ponieważ system walidacji może odrzucać niepoprawną pracę. Dalsza niestabilność zamieniłaby wyższą prędkość rozwoju w większe ryzyko jakościowe.

Drugim sygnałem jest rampa produkcyjna Helios w drugiej połowie 2026 roku. Czytelnicy powinni obserwować dostawy partnerów, odbiory klientów, zainstalowane klastry i stabilną pracę, a nie kolejne ogłoszenia dotyczące mocy.

Wdrożenie Microsoftu będzie szczególnie istotne, ponieważ łączy akceleratory AMD, procesory EPYC, sieć i ROCm w dużym środowisku chmurowym. Dostępność produkcyjna potwierdziłaby więcej niż tylko wydajność MI455X. Sprawdziłaby cały łańcuch dostaw i oprogramowania.

Opóźnienia, ograniczone ilości lub szeroko zakrojone przeprojektowania potwierdziłyby obawy dotyczące retimerów, okablowania i koordynacji z partnerami. Przewidywalne dostawy pokazałyby, że AMD przełożyło ambitny projekt referencyjny na powtarzalną infrastrukturę.

Trzecim sygnałem jest kompozycyjne wnioskowanie rozproszone na MI455X. AMD musi pokazać, że WideEP, rozdzielenie prefill-decode, transfer pamięci podręcznej, kwantyzacja i dekodowanie spekulatywne działają razem w frameworkach upstream.

Najlepszym dowodem będą odtwarzalne konfiguracje z kontrolami dokładności i wynikami dla realistycznego ruchu. Obciążenie agentowe obejmuje długi kontekst, powtarzające się wywołania narzędzi, ponowne wykorzystanie pamięci podręcznej oraz nieregularne momenty zgłaszania żądań. Proste syntetyczne prompty nie oddają tych wymagań.

Jeśli takie konfiguracje będą działać niezawodnie, AMD będzie rywalizować w obecnej walce systemowej, a nie w poprzednim pojedynku pojedynczych węzłów. Jeśli pozostaną specyficzne dla modeli, przewaga CUDA utrzyma się, nawet gdy poszczególne kernele ROCm będą wyglądać konkurencyjnie.

Deweloperzy powinni się tym interesować, ponieważ wiarygodna druga platforma może poprawić przenośność i zmniejszyć zależność od roadmapy jednego dostawcy. Może też poszerzyć dostęp do akceleratorów z dużą pamięcią, gdy przepustowość produkcyjna Nvidia pozostaje ograniczona.

Nabywcy korporacyjni powinni zwrócić na to uwagę z innego powodu. Ogłoszone rabaty, szczytowe specyfikacje i zobowiązania partnerów nie określają ryzyka operacyjnego. Kupujący potrzebują dowodów dotyczących częstotliwości regresji oprogramowania, wysiłku wdrożeniowego, dostępności oraz przenośności obciążeń.

Pracownicy umysłowi odczują rezultat pośrednio. Bardziej konkurencyjna infrastruktura inferencyjna może wpływać na dostępność modeli, opóźnienia i ekonomikę długo działających agentów. Te korzyści zależą od niezawodności produkcyjnej, a nie od porównań z prezentacji.

Werdykt AMD SemiAnalysis jest zatem ostrożnie doniosły. AMD znalazło wiarygodny mechanizm zmniejszenia części luki względem CUDA. Otwarte oprogramowanie i agenci programistyczni mogą skompresować lata ręcznej optymalizacji do szybszych, równoległych cykli inżynieryjnych.

Pozostałe bariery są mniej efektowne, lecz bardziej decydujące. AMD potrzebuje stabilnych klastrów testowych, niezawodnej kompozycji rozproszonej oraz możliwej do wyprodukowania szafy Helios. Fosa Nvidia utrzymuje się wszędzie tam, gdzie te szczegóły operacyjne pozostają trudne.

Najpierw warto obserwować publiczne bramki testowe, następnie rzeczywiste instalacje Helios, a na końcu kompletne obciążenia rozproszone. Jeśli wszystkie trzy elementy będą rozwijać się równolegle, AMD zbuduje coś więcej niż konkurencyjny akcelerator. Zbuduje wiarygodną alternatywną platformę.