OpenAI SemiAnalysis: Vera Rubin NVL72 pokonuje GB200, ale argument TCO jest węższy

NVIDIA Vera Rubin NVL72 uzyskał pierwsze zmierzone wyniki na krzemie, deklarując dziesięciokrotnie większą przepustowość na megawat niż GB200 NVL72 przy porównywalnej interaktywności. Związek z OpenAI SemiAnalysis prowadzi przez Triton, którego obsługa Rubin pomaga udostępnić tę architekturę szeroko stosowanemu oprogramowaniu AI.

Nagłówek brzmi przekonująco, ale porównuje Rubin z bazą oprogramowania GB200 z początku 2025 roku. SemiAnalysis wykazało mniejszą przewagę względem wyników Blackwell z lipca 2026 roku, choć Rubin nadal prowadził w całym testowanym zakresie interaktywności.

To rozróżnienie definiuje rzeczywistą rywalizację. Rubin nie jest po prostu szybszym GPU zastępującym starszy GPU. To system w skali szafy rack, zaprojektowany tak, by utrzymywać responsywną inferencję, gdy jednocześnie rosną rozmiar modelu, ruch pamięci i zapotrzebowanie na tokeny.

Wynik wywiera presję na operatorów GB200, dostawców konkurencyjnych akceleratorów oraz deweloperów utrzymujących własne kernele. Pozostawia też istotną lukę weryfikacyjną. Pierwszy test wykorzystał szafę z próbką inżynieryjną, starszy model rozumowania oraz obciążenie jednosesyjne.

Pierwszy wynik Rubin zmienia porównanie NVL72

Wczesna przewaga Rubin wydaje się realna, lecz dziesięciokrotny wynik stanowi porównanie najlepszego przypadku, a nie uniwersalny współczynnik wydajności.

CoreWeave opublikowało pierwszy zmierzony benchmark krzemowy Vera Rubin NVL72 21 lipca 2026 roku. Jego inżynierowie uruchomili DeepSeek R1 na Rubin i GB200 NVL72 z włączonymi tymi samymi głównymi optymalizacjami inferencji.

Test mierzył przepustowość tokenów wyjściowych na megawat względem interaktywności, wyrażonej jako tokeny na sekundę dla każdego użytkownika. To ważne, ponieważ usługa inferencyjna musi równoważyć całkowitą pojemność z akceptowalną szybkością odpowiedzi.

Przy porównywalnej interaktywności zmierzone wyniki na krzemie wykazały nawet dziesięciokrotnie większą przepustowość tokenów wyjściowych na megawat. Porównanie wykorzystało bazę GB200 NVL72 z 2025 roku.

CoreWeave podaje, że oba systemy wykorzystywały precyzję NVFP4, dekodowanie spekulatywne, szeroką równoległość ekspertów oraz rozdzielone prefill i decode. Oprogramowanie serwujące zapewniały TensorRT-LLM i NVIDIA Dynamo.

NVFP4 to czterobitowy format numeryczny NVIDIA, służący do ograniczania rozmiaru modelu i obliczeń. Dekodowanie spekulatywne generuje kandydackie tokeny przed ostateczną weryfikacją, zwiększając szybkość generowania, gdy jego przewidywania są trafne.

Rozdzielone serwowanie oddziela prefill i decode między różne grupy GPU. Prefill przetwarza prompt, natomiast decode generuje odpowiedź po jednym tokenie.

Te optymalizacje mają znaczenie, ponieważ wyniki benchmarków często mierzą jakość oprogramowania w takim samym stopniu jak krzemu. Starszy kernel, scheduler lub schemat równoległości może pozostawić niewykorzystaną dużą część mocy GPU.

SemiAnalysis dostosowało własne dane InferenceX do metodologii rozliczania CoreWeave. Oryginalny benchmark uwzględniał pobór energii zarówno GPU prefill, jak i decode, raportując tylko tokeny wyjściowe.

W porównaniu z wynikami GB300 NVL72 z lipca 2026 roku Rubin zapewniał niemal dwukrotnie większą przepustowość do poziomu 100 tokenów na sekundę na użytkownika. Jego przewaga rosła do około czterokrotnej przy 200 tokenach na sekundę.

Przy 300 tokenach na sekundę raportowany współczynnik osiągnął 5,4 raza. SemiAnalysis zaznaczyło jednak, że GB300 pracował na granicy swojej użytecznej krzywej wydajności.

GB200 nie był w stanie osiągnąć tego poziomu interaktywności w testowanej konfiguracji. Rubin kontynuował do 350 tokenów na sekundę, gdzie generował 70 703 tokeny wyjściowe na sekundę na megawat.

Nie podważa to deklaracji CoreWeave. Wczesny Rubin wyraźnie utrzymuje wyższą interaktywność niż zmierzone systemy Blackwell. Zmienia jednak to, co nabywcy powinni wnioskować z nagłówka.

Wynik dziesięciokrotny opisuje jedno obciążenie, punkt pracy, bazę oprogramowania i metodę rozliczania. Nie oznacza, że każde wdrożenie Rubin od razu zastępuje dziesięć szaf GB200.

Mocniejszy wniosek jest węższy i bardziej użyteczny. Rubin utrzymuje efektywność, gdy serwowanie przesuwa się w stronę mniejszych batchy i szybszych indywidualnych odpowiedzi, gdzie przepustowość Blackwell gwałtownie spada.

To zachowanie bezpośrednio wpływa na agentów programistycznych, systemy wyszukiwania i aplikacje bezpieczeństwa. Usługi te tworzą wiele sekwencyjnych wywołań modelu, przez co opóźnienia trudno ukryć za pomocą dużych batchy.

Dlaczego wydajność na megawat ma dziś większe znaczenie niż szczytowe FLOPS

Pojemność energetyczna stała się praktycznym limitem, dlatego użyteczne tokeny na megawat mogą mieć większe znaczenie niż teoretyczna przepustowość obliczeniowa.

Liczba szczytowych FLOPS akceleratora mierzy maksymalną liczbę operacji zmiennoprzecinkowych w określonych warunkach. Nie opisuje, jak efektywnie kompletna szafa obsługuje model rozumowania.

Inferencja przenosi wagi, aktywacje i dane KV-cache między pamięcią a jednostkami obliczeniowymi. KV cache przechowuje informacje o uwadze z wcześniejszych tokenów, zapobiegając ponownemu przeliczaniu przez model całej sekwencji.

Dłuższe konteksty powiększają ten cache. Modele mixture-of-experts przekazują również tokeny między wyspecjalizowanymi podsieciami, tworząc ruch komunikacyjny między GPU.

Rubin odpowiada na te ograniczenia jako kompletny system NVL72. Szafa łączy 72 GPU Rubin, 36 CPU Vera, sieć ConnectX-9, procesory BlueField-4 i przełączniki NVLink 6.

NVIDIA podaje 20,7 terabajta pamięci HBM4 w całej szafie. Określa też 260 terabajtów na sekundę łącznej przepustowości przełączników NVLink 6.

Każdy GPU otrzymuje 3,6 terabajta na sekundę przepustowości all-to-all scale-up. Sieć scale-up łączy akceleratory w jednej dużej domenie obliczeniowej, pozwalając im działać jak zunifikowane urządzenie.

Rubin atakuje więc problem efektywności inferencji na kilku poziomach. Szybsze operacje tensorowe obsługują matematykę macierzy, HBM4 dostarcza wagi, a NVLink przenosi tokeny między ekspertami.

CPU Vera zarządzają ruchem danych i zadaniami agentowymi wymagającymi CPU. Mogą one obejmować wywołania narzędzi, kompilację kodu, orkiestrację i wykonywanie w piaskownicy.

Specyfikacje NVL72 NVIDIA deklarują 3600 petaflopsów wydajności inferencyjnej NVFP4 na poziomie szafy. Firma deklaruje również jedną dziesiątą kosztu tokena w porównaniu z GB200 NVL72.

Wartości te nadal pozostają zależnymi od obciążenia deklaracjami firmy. Mimo to architektura szafy wyjaśnia, dlaczego przewaga Rubin rośnie wraz z interaktywnością.

Duże batche pomagają GPU pozostać zajętym, ponieważ wielu użytkowników współdzieli każde ładowanie wag. Szybka usługa interaktywna ogranicza możliwości batchowania, zwiększając presję na przepustowość pamięci i harmonogramowanie.

Przepustowość HBM4 Rubin wynosząca 22 terabajty na sekundę na GPU daje mu więcej swobody w tych warunkach. SemiAnalysis szacuje ją na 2,8 raza większą od globalnej przepustowości pamięci Blackwell Ultra.

Wyższa przepustowość nie obniża automatycznie opóźnienia pamięci. Przenosi więcej danych na sekundę, ale pojedynczy dostęp może nadal trwać podobnie długo.

Szersza przewaga Rubin przy wysokiej interaktywności odzwierciedla zatem kilka mechanizmów działających razem. Żadna pojedyncza specyfikacja szczytowa nie wyjaśnia jej w pełni.

Metryka mocy uwzględnia też wybory infrastrukturalne. Urządzenia chłodzące, sieć, procesory hosta, pamięć masowa i straty konwersji zużywają energię elektryczną poza samym pakietem GPU.

NVIDIA zaprojektowała Rubin dla ciekłego chłodziwa o temperaturze wejściowej 45 stopni Celsjusza. W kompatybilnych obiektach temperatura ta wspiera chłodzenie suche bez tradycyjnych agregatów chłodniczych.

Firma twierdzi, że jej podejście o zamkniętym obiegu może ograniczać zużycie wody i narzut chłodzenia. Zyski te zależą od projektu obiektu i nie powinny być zakładane dla każdego istniejącego centrum danych.

SemiAnalysis zastosowało to samo założenie dotyczące efektywności wykorzystania energii dla systemów chłodzonych cieczą. Ten konserwatywny wybór zapobiega zawyżeniu porównania krzemu przez projekt obiektowy Rubin.

Wynik nadal faworyzuje Rubin. Co ważniejsze, pokazuje, dlaczego architektura szafy stała się nieodłączna od ekonomiki akceleratorów.

Nabywca nie może oceniać Rubin, porównując wyłącznie FLOPS GPU. Właściwą jednostką jest system serwujący, który zapewnia wymaganą szybkość odpowiedzi w ramach ustalonego limitu mocy.

Obsługa oprogramowania OpenAI SemiAnalysis daje Rubin wcześniejszą linię startu

Rubin może ponownie wykorzystywać istotne kernele Blackwell, skracając prace wdrożeniowe, zanim deweloperzy rozpoczną strojenie specyficzne dla architektury.

Perspektywa OpenAI SemiAnalysis nie oznacza partnerstwa sprzętowego z OpenAI. Odnosi się do pojawienia się obsługi Rubin w OpenAI Triton obok PyTorch, vLLM, CUDA i innych publicznych projektów.

Triton to otwartoźródłowy język i kompilator do pisania kerneli GPU ze składnią podobną do Pythona. Kernel to wyspecjalizowany program wykonujący operację obliczeniową na GPU.

OpenAI wprowadziło programowanie Triton, aby uczynić rozwój wysokowydajnych kerneli bardziej dostępnym niż niskopoziomowy kod CUDA. Kompilatory PyTorch i projekty inferencyjne opierają obecnie wiele operacji na kernelach generowanych przez Triton.

NVIDIA wydała deweloperską wersję zapoznawczą CUDA 13.4 z obsługą Rubin i zaktualizowanymi instrukcjami PTX. PTX to pośredni język instrukcji NVIDIA służący do opisywania operacji GPU.

Wersja zapoznawcza CUDA pozwala deweloperom analizować nowe możliwości Rubin i rozpocząć przenoszenie oprogramowania. NVIDIA ostrzega, że ta wersja zapoznawcza jest oprogramowaniem przedpremierowym i nie nadaje się do benchmarków produkcyjnych.

SemiAnalysis informuje, że zmiany związane z Rubin dotarły również do repozytoriów PyTorch, vLLM i OpenAI Triton. Ta publiczna dostępność daje twórcom frameworków czas na adaptację przed szeroką dostępnością w chmurze.

Multiprocesor strumieniowy Rubin korzysta z celu SM107. Co ważniejsze, może uruchamiać główne kernele rodziny Blackwell SM100 w bibliotekach takich jak CUTLASS, DeepGEMM i FlashMLA.

Blackwell nie odziedziczył tej samej wygody po Hopper. Jego model programowania rdzeni tensorowych wymagał istotnego przepisania kerneli, zanim deweloperzy mogli zbliżyć się do potencjału sprzętu.

Rubin zachowuje większą część tej inwestycji. Zespoły mogą zacząć od działających kerneli Blackwell, wdrażać wcześniej, a następnie optymalizować najcenniejsze operacje.

Kompatybilności nie należy mylić z maksymalną wydajnością. SemiAnalysis twierdzi, że strojenie specyficzne dla architektury nadal jest konieczne, aby osiągnąć praktyczny limit szybkości.

Rubin zwiększa pamięć współdzieloną z 228 KiB w Blackwell do opcjonalnego trybu 328 KiB. Tensor Memory rośnie również do 256 KiB, dając kernelom więcej miejsca na akumulatory i informacje o skalowaniu.

Architektura dodaje wbudowane aktualizacje deskryptorów Tensor Memory Accelerator. TMA to mechanizm sprzętowy przenoszący dane wielowymiarowe bez konieczności zarządzania każdym transferem przez zwykłe jednostki wykonawcze.

W warstwie mixture-of-experts każdy ekspert posiada oddzielną macierz wag. Blackwell może wymagać przepisania i zsynchronizowania deskryptora, gdy zmienia się aktywny ekspert.

Rubin może przekazać nowy adres wraz z instrukcją transferu. Jeden deskryptor może wtedy obsługiwać kilku ekspertów bez pośredniego zapisu do pamięci.

Zmniejsza to narzut dyspozycji podczas dekodowania z małym batchem. Ilustruje też, dlaczego rzeczywiste zyski inferencyjne wynikają z drobnych usprawnień transferu danych, a nie tylko z większych silników macierzowych.

Według ujawnień architektonicznych NVIDIA Rubin podwaja przepustowość FP8 i FP4 Tensor Core w porównaniu z Blackwell. Dodaje też bardziej precyzyjną synchronizację między zależnymi blokami wątków.

Funkcje te pomagają deweloperom budować większe połączone kernele. Fuzja łączy wiele operacji, ograniczając powtarzające się uruchomienia i zbędne przenoszenie danych przez pamięć.

Przewaga programowa wykracza poza gotowość do wdrożenia. Zgodne narzędzia pozwalają większej liczbie deweloperów badać zachowanie Rubina, zgłaszać defekty i optymalizować popularne architektury modeli.

Jednak publiczne wsparcie wciąż jest na wczesnym etapie. Ograniczenia wersji zapoznawczej CUDA pokazują, że dostępny kod nie jest równoznaczny z dojrzałym stosem produkcyjnym.

Integracja z PyTorch i vLLM może zapewnić funkcjonalność, pozostawiając jednocześnie znaczną część optymalizacji niedokończoną. Operatorzy powinni odróżniać „działa na Rubin” od „efektywnie wykorzystuje Rubin”.

Historyczny wzorzec uzasadnia tę ostrożność. Wydajność inferencji GB200 poprawiała się w pierwszym roku, gdy dojrzewały kernele, harmonogramy i receptury rozproszonego serwowania.

Rubin zaczyna z silniejszą pozycją pod względem kompatybilności. Jego ostateczna przewaga nadal będzie zależeć od tego, czy opiekunowie frameworków przełożą nowe instrukcje na niezawodne korzyści na poziomie modeli.

3-bitowy LUT Tensor Core celuje w wąskie gardło pamięci

Najciekawsza funkcja inferencyjna Rubina kompresuje wagi wewnątrz Tensor Core, ograniczając ruch pamięci bez osobnego etapu dekwantyzacji.

Rubin dodaje do instrukcji mnożenia macierzy z akumulacją tryb operandu B oparty na tabeli wyszukiwania. SemiAnalysis opisuje go jako pierwszy format Tensor Core firmy NVIDIA wykorzystujący wewnętrzny, niejednorodny słownik kodowy.

W tym trybie każda przechowywana waga staje się trzybitowym indeksem. Indeks wybiera jedną z ośmiu ośmiobitowych wartości E4M3 z tabeli wyszukiwania współdzielonej przez blok wag.

Tensor Core odtwarza wybraną wartość wewnątrz operacji macierzowej. Oprogramowanie nie musi generować osobnej zdekompresowanej macierzy wag przed mnożeniem.

Uwzględniając współdzielony słownik kodowy, SemiAnalysis wylicza rozmiar zapisu na 3,125 bita na wagę. Słownik kodowy zawiera 64 bity współdzielone przez 512 wag.

Projekt różni się od formatów NVFP4 i MXFP. Formaty te wykorzystują skalowanie blokowe, stosując jednolitą skalę do grupy wartości o niskiej precyzji.

Tabela wyszukiwania może rozmieszczać osiem wartości nierównomiernie. Może koncentrować wpisy w pobliżu gęstych skupisk wag lub reprezentować asymetryczne rozkłady wartości dodatnich i ujemnych.

Ta elastyczność może zachować więcej informacji niż jednolite zaokrąglanie przy podobnej liczbie bitów. Nie gwarantuje jednak lepszej jakości modelu.

Jeden słownik kodowy obejmuje 512 wag, podczas gdy NVFP4 może dostosowywać skalę dla znacznie mniejszych grup. Wyniki będą zależeć od danych kalibracyjnych, dopasowania słownika kodowego i wrażliwości modelu.

Niektóre warstwy mogą też wymagać wyższej precyzji. Agresywna receptura kwantyzacji może oszczędzać pamięć, ale pogarszać dokładność rozumowania lub destabilizować wyniki.

Mechanizm sprzętowy nadal rozwiązuje kluczowe ograniczenie inferencji. Podczas dekodowania przy małych batchach GPU często czekają, aż wagi modelu dotrą z HBM.

Zmniejszenie rozmiaru każdej przechowywanej wagi pozwala pamięci dostarczać więcej wag na sekundę. Obniża też energię zużywaną na przesyłanie tych bitów przez system.

SemiAnalysis wykorzystało hipotetyczny model o 2,8 biliona parametrów, aby zilustrować efekt pojemnościowy. Według ich obliczeń surowy ładunek wag zajmowałby około 1,09 terabajta w formacie Rubina.

Porównanie wykluczało cache KV, aktywacje, replikację i narzut obsługi. Pokazuje zatem przechowywanie wag, a nie całkowitą pamięć potrzebną do wdrożenia.

Przy 288 gigabajtach HBM4 na GPU Rubin skompresowane wagi wymagałyby około czterech pakietów. Alternatywna reprezentacja o niskiej precyzji wymagała w przykładzie około sześciu.

Mniejsza liczba uczestniczących GPU może ograniczyć komunikację i replikację. Może również pozostawić więcej pamięci na dłuższe konteksty, większe batche lub cache KV.

Tryb LUT ma jednak ograniczenia implementacyjne. SemiAnalysis zauważa, że nie może transponować macierzy B, co ogranicza operacje, które mogą go bezpośrednio wykorzystywać.

Publiczny benchmark najwyraźniej również nie wykorzystuje tej funkcji. Początkowej przewagi Rubina nie można zatem przypisywać trzybitowej inferencji opartej na tabeli wyszukiwania.

Jest to zarazem zachęcające i niepewne. Rubin ma dodatkowe możliwości krzemowe, które przyszłe oprogramowanie może wykorzystać, ale ich dokładność i wartość produkcyjna pozostają niezweryfikowane.

NVIDIA dodała również wykonywaną w czasie rzeczywistym rzadkość aktywacji 2:4. Metoda ta zachowuje dwie wartości w każdej grupie czterech i pomija pozostałe dwie podczas obsługiwanych operacji.

W przeciwieństwie do wcześniejszej rzadkości wag, rzadkość aktywacji w czasie działania nie wymaga trwałego przycinania i ponownego trenowania modelu. Sprzęt może kompresować wartości pośrednie podczas działania modelu.

NVIDIA nie opublikowała jednak dowodów dotyczących dokładności odrzucania połowy wybranych wartości aktywacji przed kolejnymi operacjami. Wynik CoreWeave również nie wydaje się wykorzystywać tej funkcji.

Te niewykorzystane możliwości stanowią przestrzeń Rubina do dalszej optymalizacji. Nie powinny trafiać do obecnych kalkulacji TCO jako gwarantowane przyszłe zyski.

Nabywcy powinni wymagać testów jakości na poziomie modelu obok przepustowości. Format o mniejszej liczbie bitów obniża koszty obsługi tylko wtedy, gdy wynikowy model spełnia ten sam cel dokładności i niezawodności.

Rubin wygrywa test TCO, ale punkt odniesienia zmienia skalę przewagi

Rubin wydaje się tańszy w przeliczeniu na dostarczony token mimo wyższych kosztów posiadania, choć jego przewaga maleje w zestawieniu z w pełni dostrojonymi systemami Blackwell.

Całkowity koszt posiadania obejmuje sprzęt, energię elektryczną, obiekty, sieć, utrzymanie i wydatki operacyjne. Daje szerszy obraz niż sama wydajność na wat.

SemiAnalysis zastosowało swój model kosztów posiadania przez operatora do znormalizowanej przepustowości wyjściowej. Analiza nie uwzględniała stawek wynajmu w chmurze, które mogą zawierać premię za niedobór, warunki kontraktowe i marże dostawców.

Analiza wykazała, że Rubin był tańszy na token wyjściowy przy każdym zmierzonym poziomie interaktywności w porównaniu z wynikami GB200 i GB300 z lipca 2026 roku. Przewaga rosła wraz ze wzrostem szybkości odpowiedzi.

Względem obecnego punktu odniesienia GB200 Rubin był około 1,5 raza tańszy do 100 tokenów na sekundę na użytkownika. Względna przewaga sięgała około trzykrotności przy 200–250 tokenach.

Porównanie Rubina z programowym punktem odniesienia GB200 z 2025 roku dało większą różnicę. Rubin osiągnął szczytową wartość blisko ośmiokrotnie niższego kosztu przy około 150 tokenach na sekundę na użytkownika.

Ten stary punkt odniesienia wyjaśnia znaczną część różnicy między marketingowym nagłówkiem NVIDIA a praktycznym porównaniem zakupowym. Dopracowany GB200 z 2026 roku jest wydajniejszy niż we wczesnym stanie wdrożenia.

SemiAnalysis szacuje również, że Rubin ma wyższy koszt posiadania na GPU niż GB200 lub GB300. Jego wzrost przepustowości musi zrekompensować większe obciążenie systemowe.

W badanym obciążeniu tak się dzieje, zwłaszcza przy wymagających celach interaktywności. Ekonomia jest mniej rozstrzygająca przy wolniejszych odpowiedziach, gdzie Blackwell może skutecznie wykorzystywać większe batche.

Tworzy to decyzję zakupową zależną od konkretnego obciążenia.

Dla inferencji wymagającej wysokiej interaktywności

• Rubin utrzymuje szybkości odpowiedzi, których GB200 nie osiąga w testowanej konfiguracji.

• Jego przepustowość pamięci i struktura sieciowa szafy zyskują na wartości wraz ze spadkiem rozmiaru batcha.

• Agenci programistyczni i usługi wyszukiwania w czasie rzeczywistym pasują do tego profilu.

Dla inferencji ukierunkowanej na przepustowość

• Dojrzałe oprogramowanie Blackwell może zmniejszyć względną przewagę Rubina.

• Istniejąca infrastruktura i zarezerwowana pojemność mogą przeważyć nad teoretyczną przewagą efektywności.

• Koszty migracji należy uwzględnić w modelu TCO operatora.

Dla modeli o długim kontekście

• Większa pula pamięci Rubina daje operatorom więcej miejsca na wagi i cache KV.

• Początkowy benchmark pojedynczej tury nie mierzy bezpośrednio tej przewagi.

• Testy agentów działających w wielu turach dostarczą bardziej reprezentatywnego sygnału.

Benchmark wykorzystywał DeepSeek R1 671B z wejściem o długości 8 000 tokenów i wyjściem o długości 1 000 tokenów. Ten model i taki kształt sekwencji nie reprezentują każdego produkcyjnego obciążenia z 2026 roku.

SemiAnalysis argumentuje, że nowsze modele wielobilionowe powinny faworyzować pojemność i przepustowość Rubina. Twierdzenie to pozostaje technicznym oczekiwaniem do czasu uzyskania wyników porównawczych.

CoreWeave przeprowadziło test również na szafie Dell będącej próbką inżynieryjną, bez sieci scale-out. Scale-out łączy wiele szaf, podczas gdy wewnętrzna magistrala NVLink zapewnia łączność scale-up.

Udany test potwierdza wewnętrzne działanie szafy w trybie równoległości ekspertów. Nie dowodzi wydajności, niezawodności ani efektywności w dużym wdrożeniu obejmującym wiele szaf.

Konkurencja dodaje kolejne ograniczenie. AMD MI455X oferuje 432 gigabajty HBM4 na akcelerator, wobec 288 gigabajtów w Rubinie.

W 72 akceleratorach projekt Helios firmy AMD zapewnia 31,1 terabajta pamięci. Rubin dostarcza 20,7 terabajta w swojej szafie NVL72.

Przewaga AMD pod względem pojemności może mieć znaczenie dla dużych modeli i długich kontekstów. NVIDIA odpowiada swoim ugruntowanym ekosystemem oprogramowania, strukturą NVLink i wcześniejszym doświadczeniem w eksploatacji na skalę całych szaf.

Systemy TPU Google oferują inną zintegrowaną ścieżkę. Łączą niestandardowe akceleratory, interkonekty, kompilatory i usługi chmurowe pod kontrolą jednego operatora.

Rywalizacja TCO nie ogranicza się więc do Rubina i GB200. Nabywcy muszą porównywać całe receptury obsługi, używając tego samego modelu, celu dokładności, opóźnień, długości kontekstu i rozliczania energii.

Rubin ma obecnie najsilniejszy wczesny wynik publiczny. Dowody nie ustalają jeszcze jednego stałego współczynnika kosztów dla produkcyjnej inferencji.

Co muszą udowodnić kolejne benchmarki

Trzy sygnały zdecydują o tym, czy wczesny wynik inżynieryjny Rubina stanie się trwałą przewagą produkcyjną.

Pierwszym sygnałem jest zapowiedziane przez NVIDIA zgłoszenie do InferenceX w trzecim kwartale 2026 roku. SemiAnalysis twierdzi, że NVIDIA zobowiązała się dostarczyć niezależnie weryfikowalne wyniki Rubina za pośrednictwem tego benchmarku.

Wiarygodne zgłoszenie powinno testować aktualne modele w udokumentowanych konfiguracjach obsługi. Powinno wspólnie raportować interaktywność, przepustowość wyjściową, granice pomiaru energii i ustawienia optymalizacji.

Wyniki w porównaniu z systemami GB200 i GB300 z lipca 2026 roku wzmocniłyby obecne zestawienie. Powtórzenie starszego punktu odniesienia GB200 pozostawiłoby nierozwiązaną kluczową wątpliwość metodologiczną.

Drugim sygnałem jest obciążenie agentowe działające w wielu turach. Inferencja pojedynczej tury nie potrafi odtworzyć powtarzanych wywołań narzędzi, rosnących cache’ów KV i zmieniających się długości promptów w trakcie sesji agenta.

SemiAnalysis rozwija scenariusz AgentX wraz ze współtwórcami infrastruktury i obsługi open source. Jego analiza Rubina wskazuje długokontekstową pracę agentową jako prawdopodobną mocną stronę architektoniczną.

Rubin powinien powiększyć przewagę, gdy dominującymi ograniczeniami są pojemność pamięci i przepustowość. Jeśli przewaga pozostanie niezmieniona lub się skurczy, argument za szafą w zastosowaniach długokontekstowych stanie się mniej przekonujący.

Trzecim sygnałem jest dojrzałe publiczne oprogramowanie. Deweloperzy powinni obserwować wydania produkcyjne CUDA, PyTorch, vLLM, Triton, TensorRT-LLM i Dynamo.

Kompatybilność funkcjonalna pojawi się przed zoptymalizowaną wydajnością. Rozstrzygające dowody nadejdą wraz ze stabilnymi kernelami wykorzystującymi specyficzne dla Rubina funkcje przenoszenia pamięci, synchronizacji i niskiej precyzji.

Trzybitowa inferencja LUT zasługuje na szczególnie uważną kontrolę. Opublikowane testy muszą raportować dokładność, metody kalibracji, objęte warstwy oraz przepustowość end-to-end w porównaniu z NVFP4.

Rzadkość aktywacji wymaga takiego samego podejścia. Wyższa szybkość operacji arytmetycznych ma niewielkie znaczenie, jeśli utrata jakości zmusza operatorów do użycia większego modelu lub powtarzania nieudanych żądań.

Feynman stwarza również długoterminowe pytanie programowe. NVIDIA wskazała swoją następną architekturę jako SM140, podczas gdy Rubin używa SM107.

SemiAnalysis oczekuje, że Feynman będzie wymagał szerszego przepisywania kernelów, przypominającego trudne przejście z Hopper do Blackwell. Przewaga kompatybilności Rubina może zatem przetrwać tylko jedną generację.

Dla nabywców infrastruktury natychmiastowe pytanie nie brzmi, czy Rubin ma lepsze specyfikacje. Ma.

Trudniejsze pytanie dotyczy tego, czy dane obciążenie zyskuje wystarczająco dużo, by uzasadnić zmiany wdrożeniowe. Operatorzy potrzebują testów opartych na ich modelu, rozkładzie długości kontekstu, celu czasu odpowiedzi i istniejącej mocy zasilania.

Dla deweloperów użytecznym działaniem jest już teraz śledzenie wsparcia dla kernelów i receptur benchmarkowych. Wczesne profilowanie może ujawnić, czy aplikację ograniczają obliczenia, ruch HBM, sieć czy harmonogramowanie.

W przypadku zespołów tworzących produkty AI należy obserwować rezultaty na poziomie użytkownika. Szybsze tokeny mają znaczenie tylko wtedy, gdy skracają czas realizacji zadań, zwiększają niezawodność agentów lub pozwalają obsługiwać więcej klientów jednocześnie.

Wątek OpenAI SemiAnalysis ostatecznie łączy trzy warstwy: otwarte narzędzia kernelowe, niezależną analizę wydajności oraz sprzęt NVIDIA w skali całych szaf serwerowych. Żadna z tych warstw nie jest w stanie samodzielnie zweryfikować Rubina.

Czy Rubin utrzyma przewagę w przypadku nowoczesnych modeli, agentów prowadzących wieloturowe interakcje oraz niezależnie odtwarzalnych testów? To właśnie te dowody — a nie jeden nagłówek czy mnożnik — powinny przesądzić o kolejnym zobowiązaniu dotyczącym infrastruktury inferencyjnej.