Kimi K3 trafił na Hacker News po tym, jak MI355X pokonał B300 pod względem wydajności na dolara

Kimi K3 trafił na Hacker News po tym, jak Wafer poinformował, że osiem GPU AMD MI355X obsługiwało model z szybkością około 952 tokenów wyjściowych na sekundę. System ustępował ośmiogpuowemu węzłowi Nvidia B300 pod względem łącznej przepustowości. Założenia Wafer dotyczące wynajmu dały jednak AMD lepszy wynik wydajności na dolara.

To rozróżnienie ma znaczenie, ponieważ Kimi K3 jest wyjątkowo wymagający. Model Moonshot AI o otwartych wagach zawiera około 2,8 biliona parametrów, z czego dla każdego tokena aktywowanych jest około 104 miliardów. Jego checkpoint zajmuje ponad 1,5 terabajta, zanim system obsługujący zarezerwuje pamięć na stan wykonawczy i długie prompty.

Standardowy ośmiogpuowy węzeł B200 nie jest w stanie komfortowo pomieścić takiej konfiguracji wdrożeniowej. Wafer porównał więc jeden węzeł MI355X z węzłem B300 i konfiguracją B200 złożoną z dwóch węzłów. Wynik podważa przewagę Nvidia w wąskim, lecz komercyjnie istotnym pytaniu: która platforma zapewnia akceptowalną inferencję Kimi K3 przy najniższym koszcie infrastruktury?

Twierdzenie z Hacker News dotyczy ekonomii, a nie bezwzględnego zwycięstwa pod względem szybkości

Wafer nie podał, że MI355X był szybszy od B300. Podał, że MI355X zapewniał większą przepustowość na każdą jednostkę godzinowych wydatków na infrastrukturę.

To rozróżnienie łatwo zgubić w nagłówku. Według wpisu benchmarkowego Wafer, jego ośmiogpuowy węzeł MI355X osiągnął 952 łączne tokeny wyjściowe na sekundę. W tym samym teście konfiguracja B300 z ośmioma GPU osiągnęła 1 568 tokenów na sekundę.

Daje to Nvidia znaczącą przewagę w surowej przepustowości. Węzeł B300 dostarczył także 172 tokeny na sekundę w pojedynczym strumieniu, wobec 118 na MI355X. Nabywca optymalizujący wyłącznie pod kątem maksymalnej liczby tokenów z jednego węzła nadal wybrałby B300 przy tych wynikach.

Wafer doszedł do innego wniosku po zastosowaniu szacunków godzinowego wynajmu. Jego wyliczenie stawiało MI355X na czele pod względem łącznej przepustowości na jednostkę wydatków. Firma określiła akcelerator AMD mianem zwycięzcy w kategorii wydajności na dolara, a nie ogólnej wydajności.

W benchmarku użyto promptów zawierających 1 024 tokeny wejściowe i żądano 400 tokenów wyjściowych. To przydatne obciążenie, ponieważ oddaje typowe zachowanie podczas generowania tekstu, nie stając się testem obciążeniowym długiego kontekstu. Nie reprezentuje ono jednak każdego obciążenia produkcyjnego.

Porównanie z B200 dodaje kolejną warstwę. Kimi K3 wymagał w konfiguracji Wafer 16 GPU B200 rozłożonych na dwa węzły. To wdrożenie osiągnęło 498 łącznych tokenów na sekundę, czyli około 249 na węzeł.

Komunikacja między węzłami narzuciła karę wydajnościową, ponieważ GPU musiały koordynować wykonanie modelu przez sieć. Wafer podał, że połączenie działało przez RoCE v2, oparty na Ethernet protokół przesyłania danych bezpośrednio między systemami przy niewielkim udziale CPU.

Niekorzystny wynik B200 odzwierciedla więc zarówno topologię, jak i sam krzem. Model nie mieścił się w jednym ośmiogpuowym węźle B200 przy wymaganej przez Wafer alokacji pamięci. Podzielenie go na dwa węzły wprowadziło komunikację do ścieżki dekodowania.

To ograniczenie jest kluczowe dla tej historii. Kimi K3 zamienia pojemność pamięci w przewagę architektoniczną jeszcze przed rozpoczęciem strojenia oprogramowania. Zarówno MI355X, jak i B300 zapewniają 288 GB pamięci o wysokiej przepustowości na GPU, dzięki czemu pojedynczy ośmiogpuowy węzeł staje się realną opcją.

Dyskusja na Hacker News koncentrowała się na tym, czy wynik osłabia programistyczną fosę Nvidia. Benchmark jednego dostawcy nie może rozstrzygnąć tego szerszego pytania. Pokazuje jednak, że pojemność pamięci i ekonomika wynajmu mogą przeważyć nad konwencjonalnymi rankingami GPU w przypadku konkretnego modelu.

Zmienia także sposób, w jaki nabywcy powinni czytać porównania akceleratorów. Szczytowa wydajność obliczeniowa ma znaczenie, ale jest tylko jednym z czynników. Rozmiar modelu, kwantyzacja, rozmieszczenie pamięci, wsparcie frameworków, współbieżność, opóźnienia, sieć i wykorzystanie zasobów mogą determinować rzeczywisty rachunek.

W przypadku Kimi K3 pierwsze zwycięstwo przypada platformie, która potrafi pomieścić model bez niezręcznego podziału na wiele węzłów. AMD przekracza ten próg jednym węzłem MI355X. Nvidia przekracza go z B300, podczas gdy B200 staje się mniej atrakcyjny dla tej konkretnej konfiguracji.

Wynik jest więc węższy i bardziej użyteczny niż szerokie stwierdzenie, że AMD dogoniło Nvidia. Wskazuje jedno obciążenie, w którym wybory projektowe AMD nabierają finansowego znaczenia.

Kimi K3 zamienia pojemność pamięci w decydujące ograniczenie

Kimi K3 sprawia, że pamięć akceleratora staje się wymogiem wdrożeniowym, a nie specyfikacją, którą nabywcy mogą traktować jako drugorzędną.

Moonshot AI opisuje Kimi K3 jako model mixture-of-experts z 2,8 biliona parametrów. Model mixture-of-experts kieruje każdy token przez jedynie część swojej sieci, ograniczając aktywne obliczenia przy zachowaniu znacznie większej puli wyuczonych parametrów.

Artykuł techniczny K3 podaje, że model aktywuje około 104 miliardów parametrów na token. Wybiera 16 kierowanych ekspertów z puli 896. Ta rzadkość ogranicza obliczenia, ale nie eliminuje konieczności przechowywania pełnych wag ekspertów.

Każde żądanie może kierować tokeny do różnych ekspertów. System obsługujący musi zatem utrzymywać szerszy checkpoint dostępny w całej grupie GPU. To właśnie checkpoint tworzy wymóg pamięciowy kształtujący porównanie Wafer.

Własny przewodnik wdrożeniowy AMD szacuje rozmiar checkpointu uwzględniający loader na około 1,56 TB. Przy ośmiokierunkowym parallelizmie tensorowym każdy MI355X przechowuje około 191 GiB wag modelu.

Parallelizm tensorowy dzieli duże operacje modelu między kilka GPU. Każdy akcelerator oblicza jedną część, a następnie wymienia wyniki pośrednie z pozostałymi. Utrzymywanie wszystkich ośmiu GPU w jednym serwerze zazwyczaj zmniejsza karę komunikacyjną w porównaniu z rozpięciem ich na wiele maszyn.

AMD szacuje, że znany stan wykonawczy dla jednej sekwencji przy maksymalnym kontekście modelu dodaje około 14,4 GiB na GPU. Łączna znana alokacja osiąga około 205,4 GiB, pozostawiając około 82,6 GiB na każdym MI355X przed uwzględnieniem innych narzutów.

Pozostała pamięć musi pomieścić bufory komunikacyjne, tymczasowe przestrzenie robocze, fragmentację alokatora, stan frameworka i inne koszty produkcyjne. Może również obsługiwać batching, który grupuje żądania, aby GPU wykonywały jednocześnie więcej użytecznej pracy.

Moonshot podaje dla Kimi K3 okno kontekstowe wynoszące milion tokenów. Okno kontekstowe to maksymalna ilość tekstu i innych tokenizowanych danych wejściowych, które model może uwzględnić podczas jednej interakcji. Obsługa tego teoretycznego maksimum wymaga więcej pamięci niż obsługa krótkich promptów.

Kimi Delta Attention pomaga ograniczyć ten wzrost. Wykorzystuje stan rekurencyjny o stałym rozmiarze dla wielu warstw zamiast utrzymywać wszędzie konwencjonalny cache klucz-wartość. Cache klucz-wartość przechowuje wcześniejsze dane uwagi, aby model nie przeliczał całej sekwencji dla każdego generowanego tokena.

Kimi K3 nadal zawiera warstwy utrzymujące stan cache zależny od tokenów. Długie prompty nadal zużywają więc istotną ilość pamięci. Architektura zmniejsza to obciążenie, ale nie czyni długiego kontekstu darmowym.

AMD MI355X i Nvidia B300 oferują po 288 GB HBM na GPU w swoich standardowych ośmiogpuowych platformach. Architektura B300 firmy Nvidia wymienia 2,3 TB pamięci w całym węźle, co odpowiada ogólnej klasie pojemności platformy AMD.

B200 oferuje mniej pamięci na GPU. Osiem urządzeń może wystarczyć dla wielu modeli, ale Wafer twierdzi, że taka konfiguracja nie była w stanie pomieścić Kimi K3 z planowaną pulą pamięci dla długiego kontekstu. Przejście na 16 GPU rozwiązuje problem pojemności, ale dodaje koszty sieciowe i złożoność operacyjną.

To głębsze odwrócenie stojące za zainteresowaniem Hacker News. B200 Nvidia pozostaje akceleratorem z najwyższej półki, ale Kimi K3 może sprawić, że topologia otaczającego systemu będzie ważniejsza niż znana pozycja rynkowa układu.

Ta sama zasada wykracza poza ten model. Modele o otwartych wagach pozwalają operatorom wybierać własny sprzęt, framework obsługujący, kwantyzację i harmonogram żądań. Większe checkpointy sprawiają, że wybory te są coraz silniej zależne od pojemności pamięci.

Firma planująca wewnętrznych agentów programistycznych, analizę dokumentów lub automatyzację badań może oczekiwać długich promptów i ciągłego generowania. Takie zespoły powinny modelować zapotrzebowanie na pamięć przed porównaniem przepustowości akceleratorów.

Utrzymywanie przeszukiwalnej bazy wiedzy inżynieryjnej może również ułatwić odtwarzanie takich ocen. Notatki konfiguracyjne, wyniki profilowania, zmiany wdrożeniowe i raporty awarii w przeciwnym razie rozpraszają się po lokalnych dokumentach i wątkach czatu.

Kimi K3 nie dowodzi, że pamięć jest jedyną fosą. Pokazuje, że pamięć może przesądzić o tym, które platformy w ogóle przystępują do rywalizacji.

Dekodowanie spekulatywne zmniejszyło lukę programistyczną AMD

Wynik MI355X zależał od napraw oprogramowania i optymalizacji obsługi, choć Wafer nie musiał pisać nowego kernela GPU dla swojego głównego usprawnienia dekodowania.

Wafer rozpoczął od wsparcia Kimi K3 przez AMD dostępnego od pierwszego dnia. Ta baza już ładowała model na ośmiu GPU MI355X i udostępniała go przez kompatybilny serwer inferencyjny. Przejście od działającego wdrożenia do konkurencyjnej przepustowości nadal wymagało prac inżynieryjnych.

Największe usprawnienie dekodowania zapewniło dekodowanie spekulatywne. Technika ta wykorzystuje mniejszy model roboczy do przewidywania kilku przyszłych tokenów. Główny model weryfikuje następnie te kandydaty razem, ograniczając liczbę kosztownych sekwencyjnych kroków dekodowania.

Kimi K3 nie został dostarczony z własnymi tensorami roboczymi dla metod spekulatywnych powszechnie integrowanych z modelami z czołówki. Wafer użył zamiast tego Kimi-K3-DSpark, zewnętrznego modelu roboczego block-diffusion opublikowanego przez RadixArk.

Wersja CUDA podobno działała bez takiej przerwy. W ROCm, platformie AMD do obliczeń GPU, pierwsze żądanie produkcyjne wywołało błąd brakującej funkcji w ścieżce weryfikacji tokenów SGLang.

SGLang to framework obsługujący open source, który harmonogramuje żądania modeli, zarządza pamięcią i uruchamia zoptymalizowane kernele. Jego wersja CUDA importowała funkcję renormalizacji prawdopodobieństw top-k. Gałąź ROCm nie zapewniała równoważnej definicji dla testowanej ścieżki.

Próbkowanie top-k zachowuje jedynie najbardziej prawdopodobnych kandydatów tokenów przed wybraniem kolejnego wyniku. Renormalizacja przeskalowuje ich pozostałe prawdopodobieństwa tak, aby sumowały się do jedności. Brakująca operacja była matematycznie prosta, ale jej brak powodował awarię harmonogramu żądań.

Wafer zaimplementował tę operację przy użyciu standardowych prymitywów PyTorch. Funkcja sortowała prawdopodobieństwa, zachowywała kandydatów o najwyższej pozycji, maskowała pozostałe i przeskalowywała zachowane wartości.

Naprawa ta podobno zwiększyła wydajność pojedynczego strumienia około 2,2 raza. Przy umiarkowanym obciążeniu wydajność na strumień poprawiła się o około 1,7 raza. Szczytowa łączna przepustowość wzrosła o 18 procent.

Te zyski pokazują, dlaczego specyfikacje sprzętowe nie przewidują bezpośrednio inferencji produkcyjnej. Akcelerator wykonuje operacje, ale stos obsługujący decyduje, czy żądania trafiają na wydajne ścieżki kodu.

Platforma CUDA Nvidia korzysta z lat integracji frameworków i uwagi deweloperów. Nowe techniki inferencyjne często pojawiają się tam najpierw. Błędy są szerzej wykrywane, a biblioteki zwykle zakładają zachowanie CUDA, zanim dodadzą inne backendy.

AMD intensywnie inwestował w ROCm i wspierające go biblioteki. Wdrożenie Kimi K3 pokazuje postęp, ponieważ brakująca funkcja wymagała niewielkiej poprawki w oprogramowaniu, a nie miesięcy pracy nad niskopoziomowymi kernelami.

Mimo to błąd nadal ma znaczenie. Ścieżka żądania, która ulega awarii przy rzeczywistym ruchu, nie jest jedynie kosmetyczną niedogodnością. Oznacza ryzyko związane z testowaniem, utrzymaniem i eksploatacją, które zespoły infrastruktury muszą uwzględnić w decyzjach wdrożeniowych.

Wynik Wafer zależał również od osiągnięcia wysokiej współbieżności. Współbieżność określa, ile sekwencji serwer przetwarza jednocześnie. Więcej równoległych żądań może zwiększyć całkowitą przepustowość, wypełniając akcelerator użyteczną pracą.

Dekodowanie spekulacyjne przesunęło szczytową przepustowość systemu w kierunku wyższego ustawienia współbieżności. Taki rezultat sprzyja współdzielonej usłudze obsługującej wiele żądań. Może mieć mniejsze znaczenie dla aplikacji, która potrzebuje natychmiast jednej odpowiedzi.

Ta różnica oddziela łączną przepustowość od interaktywności. Łączna przepustowość mierzy całkowitą liczbę tokenów wygenerowanych dla wszystkich użytkowników. Interaktywność mierzy, jak szybko postępuje każdy indywidualny strumień.

Łączny wynik 952 tokenów dla węzła MI355X jest wartościowy dla obciążonej usługi. Jego wynik 118 tokenów dla pojedynczego strumienia mówi jednak coś innego. B300 pozostawał szybszy zarówno dla jednego strumienia, jak i dla całego węzła.

Mechanizm ten prowadzi więc do praktycznego, a nie uniwersalnego wniosku. Sprzęt AMD oferował korzystną ekonomikę po tym, jak Wafer naprawił lukę we frameworku i skonfigurował dekodowanie spekulacyjne wokół zewnętrznego modelu draftowego.

Inne zespoły muszą ustalić, czy potrafią odtworzyć ten stos. Potrzebują kompatybilnych wersji frameworków, tej samej reprezentacji modelu, stabilnego zachowania próbkowania oraz wystarczającej liczby żądań.

Potrzebują też inżynierów zdolnych diagnozować błędy specyficzne dla danego backendu. Brakującą funkcję może być łatwo naprawić, gdy ktoś ją zidentyfikuje. Znalezienie precyzyjnej przyczyny awarii pod obciążeniem produkcyjnym może trwać znacznie dłużej.

Dlatego twierdzenia z Hacker News nie należy sprowadzać do wyniku sprzętowego. Jest to dowód, że niekorzystna pozycja AMD w oprogramowaniu może czasem zostać ograniczona i naprawiona. Nie pokazuje jednak, że ta słabość zniknęła.

B300 Nadal Prowadzi Tam, Gdzie Najbardziej Liczą Się Opóźnienia i Gęstość

Nvidia B300 pozostał mocniejszym wyborem, gdy cel przesunął się z efektywności infrastruktury na maksymalną przepustowość lub minimalny czas oczekiwania.

Wafer zmierzył 1 568 łącznych tokenów wyjściowych na sekundę z węzła B300. Było to około 65 procent więcej niż 952 tokeny uzyskane przez węzeł MI355X w testowanej konfiguracji.

B300 osiągnął również 172 tokeny na sekundę w pojedynczym strumieniu. MI355X osiągnął 118. W interaktywnym programowaniu, agentach działających na żywo lub czacie skierowanym do klientów różnica ta może wpływać na odczuwaną responsywność produktu.

Porównanie staje się trudniejsze podczas prefill. Prefill to faza, w której model przetwarza istniejący prompt użytkownika przed wygenerowaniem pierwszego tokenu wyjściowego. Długie dokumenty i duże repozytoria kodu czynią ten etap szczególnie ważnym.

Wafer przetestował identyczny zimny prompt zawierający około 172 000 tokenów. Konfiguracja MI355X początkowo potrzebowała około 51 sekund na jego przetworzenie, wobec około 23 sekund na B300.

Ta różnica przewyższa tę obserwowaną podczas zwykłego dekodowania. Użytkownik może zaakceptować nieco wolniejszy strumień, gdy tekst już zacznie się pojawiać. Znacznie dłuższe oczekiwanie na pierwszy token może sprawić, że aplikacja wydaje się zawieszona.

Wafer przypisał większość luki AMD w prefill awaryjnemu użyciu kernela attention. Kimi K3 przypisywał 12 głów attention do każdego GPU przy ośmiokrotnym równolegleniu tensorowym. Szybszy kernel AITER od AMD obsługiwał inne kształty liczby głów, dlatego framework wybierał wolniejszy, ogólny kod Triton.

AITER to biblioteka zoptymalizowanych operatorów AI firmy AMD. Triton jest językiem i kompilatorem używanym do tworzenia przenośnych kernelów GPU. Ogólna ścieżka Triton może upraszczać kompatybilność, ale może nie dorównywać implementacji assembly specyficznej dla danego sprzętu.

Wafer dopełnił wejście z 12 głowami do 16 głów, uruchomił zoptymalizowany kernel, a następnie usunął sztuczne wyjścia. Ta korekta kształtu miała podobno zwiększyć przepustowość prefill w stanie ustalonym do około 13 000 tokenów na sekundę.

Wcześniejsza ścieżka awaryjna osiągała od około 4 000 do 7 000 tokenów na sekundę. Wafer opisał naprawę jako dwu- do trzykrotną poprawę prefill.

Co ważne, optymalizacja ta nie podniosła głównego wyniku dekodowania. Dotyczyła czasu do pierwszego tokenu, czyli TTFT, który mierzy, jak długo użytkownicy czekają przed rozpoczęciem generowania.

Ten przypadek pokazuje obie strony pozycji AMD. Sprzęt dysponował wydajnym kernelem zdolnym do znacznie lepszej wydajności. Framework nie wybrał go, ponieważ Kimi K3 tworzył nieobsługiwany kształt.

Nvidia korzysta, gdy takie niedopasowania zostały już przewidziane w bibliotekach CUDA. AMD korzysta, gdy deweloperzy mogą dostosować istniejące kernele bez projektowania nowych. Kupujący muszą zdecydować, ile pracy integracyjnej są w stanie zaakceptować.

B300 oferuje również wyższą łączną wydajność na GPU w teście Wafer. Taka gęstość może mieć znaczenie tam, gdzie wdrożenie ograniczają przestrzeń w szafach rack, dostarczanie energii, porty sieciowe lub dostępność centrum danych.

Tańszy GPU nie jest automatycznie tańszy na poziomie usługi. Operatorzy muszą uwzględnić wykorzystanie serwera, energię, sieć, czas inżynierów, zapasową pojemność, odzyskiwanie po awarii i utrzymanie oprogramowania.

Jeśli jeden węzeł B300 może obsłużyć ruch wymagający większej liczby węzłów AMD, otaczająca infrastruktura może zmniejszyć początkową przewagę wydajności na dolara. Z kolei aplikacja o umiarkowanych wymaganiach dotyczących opóźnień może zaoszczędzić więcej, akceptując niższy szczyt AMD.

Właściwym porównaniem jest cel na poziomie usługi, a nie slogan na poziomie chipa. Cel na poziomie usługi definiuje opóźnienie, dostępność i przepustowość, które system musi konsekwentnie zapewniać.

Zespoły powinny porównywać obie platformy przy tym samym docelowym poziomie interaktywności. Powinny także mierzyć identyczne długości promptów, długości wyjść, zachowanie cache, współbieżność, kwantyzację i oczekiwania dotyczące czasu działania.

Benchmark optymalizowany niezależnie na każdej platformie może odpowiedzieć, który system działa najlepiej po eksperckim dostrojeniu. Benchmark wykorzystujący identyczne oprogramowanie może odpowiedzieć, jak przenośny jest stos. To różne pytania.

Test Wafer skłania się ku pierwszemu podejściu. Firma dostroiła ścieżkę MI355X i porównała wynikową usługę ze swoimi wdrożeniami Nvidia. Odzwierciedla to sposób, w jaki operator może dążyć do najlepszej dostępnej ekonomiki, ale utrudnia ścisłe przypisanie wyniku architekturze.

B300 pozostaje szybszą platformą w opublikowanych liczbach. MI355X zwraca uwagę, ponieważ niższe założenie dotyczące kosztu wynajmu z nawiązką kompensuje tę różnicę w obciążeniu wybranym przez Wafer.

To znaczący wynik konkurencyjny. Nie oznacza jednak przejęcia korony wydajności od Nvidia.

Czego Benchmark Nie Ustala

Opublikowane wyniki pozostają migawką przygotowaną przez firmę, z ograniczonymi szczegółami metodologicznymi i bez niezależnego odtworzenia dołączonego do głównego twierdzenia.

Wafer tworzy produkty do optymalizacji GPU i inferencji. Oferuje również hostowany dostęp do modeli. Firma ma wyraźne kompetencje, ale także interes komercyjny w wykazywaniu, że praca nad oprogramowaniem może otworzyć alternatywy wobec Nvidia.

Nie unieważnia to benchmarku. Oznacza jednak, że czytelnicy powinni traktować pomiary jako wyniki raportowane przez operatora, a nie neutralną certyfikację branżową.

Wpis o benchmarku wskazuje długość promptu, żądane wyjście, konfiguracje sprzętowe, przepustowość i wybrane prace optymalizacyjne. Nie zawiera jednak w artykule kompletnego pakietu umożliwiającego odtworzenie wyników.

Ważne szczegóły pozostają niejasne. Wpis nie określa w pełni każdej rewizji oprogramowania, procedury rozgrzewki, rozkładu żądań, czasu pomiaru, etapu weryfikacji wyjścia ani pomiaru zużycia energii.

Konfiguracja B300 wykorzystywała również rozdzielone przetwarzanie kontekstu, zgodnie z etykietą porównania Wafer. Rozdzielenie oddziela przetwarzanie promptu od generowania tokenów, aby każdy etap mógł korzystać z odpowiednich zasobów. Może to wpływać zarówno na wydajność, jak i projekt systemu.

Wpis MI355X wykorzystywał ośmiokrotne równoleglenie tensorowe. Wdrożenie B200 używało 16 GPU w dwóch węzłach. Wpis B300 łączył ośmiokrotne równoleglenie tensorowe z rozdzielonym przetwarzaniem.

Są to praktyczne wdrożenia, ale nie są to idealnie symetryczne konfiguracje. Każda platforma napotkała inne ograniczenia pamięci i topologii. Ta asymetria częściowo stanowi sedno sprawy, lecz ogranicza wnioski dotyczące wyłącznie architektury chipa.

Wynik wydajności na dolara zależy również od założeń dotyczących wynajmu. Rynki GPU różnią się między dostawcami chmury, długością kontraktów, regionami, dostępnością i modelami rezerwacji. Kupujący z rabatową pojemnością Nvidia może dojść do innego wniosku.

Wspólne zasady redakcyjne uniemożliwiają podanie tutaj konkretnych cen komercyjnych. Ważne jest to, że Wafer założył, iż pojemność MI355X kosztuje znacząco mniej za GPU-godzinę niż B300. Z tego założenia bezpośrednio wynika jego werdykt ekonomiczny.

Znaczenie ma również dostępność. Teoretycznie atrakcyjny akcelerator nie zapewnia oszczędności, jeśli zespół nie może zarezerwować wystarczającej liczby węzłów w wymaganym regionie. Szersza obecność Nvidia w chmurze może zmniejszać trudności zakupowe.

Zachowanie modelu stwarza kolejną niepewność. Dekodowanie spekulacyjne przyspiesza generowanie tylko wtedy, gdy model draftowy przewiduje tokeny akceptowane przez model główny. Wskaźniki akceptacji mogą zmieniać się w zależności od programowania, prozy, matematyki, języków i ustawień próbkowania.

Krótki benchmark wejściowy Wafer może zatem zapewniać inne zyski niż agent przetwarzający duże repozytorium. Badania z długim kontekstem, obsługa klienta i ekstrakcja wsadowa mogą każdorazowo przesuwać równowagę między prefill a dekodowaniem.

Sam model jest również nowy. Moonshot opublikował wagi Kimi K3 27 lipca 2026 roku, zaledwie kilka dni przed opublikowaniem przez Wafer pomiarów z 31 lipca. Frameworki, kwantyzacje i zoptymalizowane kernele są nadal na wczesnym etapie.

Początkowy przewodnik AMD był celowo ostrożny. Potwierdził ładowanie i podstawową poprawność na ośmiu GPU MI355X, ale nie deklarował szczytowej przepustowości, opóźnienia tokenów ani wydajności kernelów.

Wafer dostarczył tę kolejną warstwę pracy nad wydajnością. Niezależne zespoły powinny teraz odtworzyć wynik za pomocą otwartych skryptów i jasno zdefiniowanych celów usługi.

Porównanie powinno również wykraczać poza B300. Nowsze systemy Nvidia, przyszłe akceleratory AMD i wyspecjalizowany sprzęt do inferencji zmienią dostępne opcje. Wydania oprogramowania mogą zmienić dzisiejszy ranking bez wymiany jakichkolwiek chipów.

Istnieje także kwestia jakości. Formatów niskiej precyzji i metod spekulacyjnych należy używać tak, aby zachować zachowanie wyjściowe w określonych tolerancjach. Wynik szybkości wymaga kontroli poprawności, zwłaszcza gdy zmiany próbkowania mogą ukrywać subtelne różnice.

Model Moonshot używa mieszanych reprezentacji niskiej precyzji, aby ograniczyć wymagania dotyczące pamięci i mocy obliczeniowej. Wybory te są częścią jego zamierzonej architektury. Implementacje nadal muszą potwierdzać, że każdy backend zapewnia akceptowalne wyniki w reprezentatywnych zadaniach.

Najbardziej uzasadniona interpretacja jest warunkowa: przy obciążeniu, stosie oprogramowania i założeniach dotyczących wynajmu Wafer, MI355X zapewnił lepszy wynik wydajności na dolara.

Najmniej uzasadniona interpretacja brzmi, że AMD szeroko pokonało Nvidia w inferencji AI. Opublikowane dowody nie wspierają takiego wniosku.

Trzy Sygnały Zadecydują, Czy AMD Może Powtórzyć Zwycięstwo

Wynik AMD z Kimi K3 zyskuje znaczenie strategiczne tylko wtedy, gdy przetrwa niezależne testy, szersze obciążenia i rutynowe wydania frameworków.

Pierwszym sygnałem jest odtwarzalność. Niezależni operatorzy powinni uruchomić Kimi K3 na MI355X i B300 przy opublikowanych konfiguracjach, identycznych promptach, zweryfikowanych wyjściach i dopasowanych celach opóźnień.

Powtarzalna przewaga wydajności na dolara wzmocniłaby twierdzenie Wafer. Duże różnice między zespołami sugerowałyby, że wynik silnie zależy od specjalistycznego dostrajania lub korzystnych warunków infrastrukturalnych.

Reprodukcja wyników powinna obejmować więcej niż tylko szczytową łączną przepustowość. Testy muszą uwzględniać czas do pierwszego tokena, szybkość dekodowania na użytkownika, utrzymywaną współbieżność, wskaźniki błędów, wykorzystanie pamięci, zużycie energii oraz stabilność podczas długotrwałej pracy.

Powinny również przedstawiać pełny model kosztowy, bez założenia, że pojedynczy publiczny snapshot cen wynajmu reprezentuje każdego nabywcę. Kontraktowana przepustowość i własna infrastruktura mogą zmienić kalkulację.

Drugim sygnałem będzie to, czy usprawnienia ROCm trafią do standardowych frameworków obsługujących inferencję. Naprawa top-k firmy Wafer i ścieżka padded prefill rozwiązały konkretne problemy, lecz prywatne poprawki tworzą zobowiązania utrzymaniowe.

Jeśli SGLang, AITER, vLLM i powiązane projekty wchłoną porównywalne poprawki, więcej zespołów będzie mogło odtworzyć wynik bez utrzymywania własnych gałęzi kodu. Przełożyłoby to wiedzę jednego operatora na korzyść dla szerszego ekosystemu.

Szybkie wsparcie upstream zmniejszyłoby również ryzyko, że aktualizacja frameworka uszkodzi zoptymalizowaną ścieżkę. Nabywcy infrastruktury cenią powtarzalność, ponieważ systemy produkcyjne działają znacznie dłużej niż testy porównawcze.

Jeśli poprawki pozostaną rozproszone, przewaga Nvidii w oprogramowaniu utrzyma się nawet wtedy, gdy sprzęt AMD będzie wyglądał korzystnie. Fosa CUDA obejmuje dokumentację, narzędzia do debugowania, pokrycie bibliotekami, doświadczonych programistów i przewidywalne działanie frameworków.

Trzecim sygnałem będzie wydajność przy obciążeniach przypominających produkcyjne. Milionowy kontekst tokenów Kimi K3 zachęca do zadań obejmujących duże repozytoria, zbiory dokumentów, historię badań i wydłużone sesje agentów.

Takie obciążenia zwiększają znaczenie prefill, zarządzania cache, harmonogramowania żądań i fragmentacji pamięci. Wafer już pokazał, że początkowy wynik AMD w cold-prefill pozostawał w tyle za B300, zanim włączono zoptymalizowaną ścieżkę kernela.

Szerszy sukces wymagałby, aby MI355X pozostał konkurencyjny przy krótkich promptach czatowych, długich dokumentach, agentach kodowych, wejściach multimodalnych i mieszanym ruchu. Musi też utrzymywać akceptowalne opóźnienia, gdy węzeł obsługuje wielu użytkowników.

Jeśli AMD będzie dobrze działać w tych warunkach, nabywcy sprzętu zyskają istotną siłę negocjacyjną. Będą mogli negocjować wobec wiarygodnej drugiej platformy i wdrażać duże modele o otwartych wagach bez akceptowania automatycznej premii Nvidii.

Jeśli przewaga znika poza testami przepustowości dla krótkich wejść, MI355X pozostanie opcją specyficzną dla określonych obciążeń. Nadal może to prowadzić do wartościowych wdrożeń, ale nie osłabi zasadniczo pozycji Nvidii.

Szersza lekcja z hacker news jest taka, że modele o otwartych wagach przekształcają inferencję w rywalizację systemową. Twórcy modeli definiują architekturę, producenci chipów dostarczają pamięć i moc obliczeniową, a zespoły frameworków decydują, jaka część tej pojemności staje się użyteczna.

Kimi K3 zaostrza tę rywalizację, ponieważ jego checkpoint zmusza nabywców do natychmiastowego zmierzenia się z ograniczeniami pamięci. Nagradza również platformy, które potrafią obsłużyć obliczenia niskiej precyzji, efektywne kierowanie ekspertami i stan dużego kontekstu.

Programiści powinni śledzić repozytoria benchmarków i informacje o wydaniach frameworków. Zespoły infrastruktury powinny uruchamiać własne ślady ruchu, zamiast polegać na pojedynczej wartości tokenów na sekundę.

Nabywcy korporacyjni powinni wymagać porównań przy opóźnieniach, których potrzebują ich aplikacje. Powinni uwzględniać nakład pracy inżynieryjnej i ryzyko operacyjne obok założeń dotyczących wynajmu akceleratorów.

Obecne dowody dają AMD wiarygodny wynik, a Nvidii wyraźne ostrzeżenie. B300 pozostaje szybszy, podczas gdy MI355X podobno oferuje lepszą ekonomię dla wdrożenia Kimi K3 firmy Wafer.

Kolejne pytanie brzmi, czy ta przewaga stanie się czymś zwyczajnym. Śledź niezależne benchmarki, wsparcie oprogramowania upstream i produkcyjne testy długiego kontekstu, zanim uznasz jeden wynik z hacker news za trwałą zmianę.