Benchmarki CPU Arm AGI wywierają presję na AMD, ale przewaga 1,99x jest modelowana
Arm twierdzi, że jego nowy procesor wykonuje w przeliczeniu na szafę niemal dwa razy więcej pracy niż EPYC 9755 firmy AMD w siedmiu wybranych obciążeniach. Benchmarki CPU Arm AGI wskazują na średnią przewagę 1,99x po przeskalowaniu zmierzonych wyników układów z użyciem założeń dotyczących poboru mocy serwerów.
Ten nagłówek brzmi jak zdecydowana porażka AMD. Wyniki źródłowe przedstawiają jednak bardziej zniuansowany obraz. Arm osiągnął średnią przewagę 1,20x na układ, podczas gdy jego znacznie większa przewaga na szafę wynikała głównie z możliwości umieszczenia większej liczby serwerów w stałym limicie mocy.
Signal65 przeanalizował testy w ramach analizy zleconej przez Arm. Nie przeprowadził jednak niezależnie całego porównania ponownie na osobnym sprzęcie. Benchmark ocenia też pracę CPU związaną z agentami AI, a nie inteligencję modeli ani inferencję na akceleratorach.
Wynik ma więc znaczenie z konkretnego powodu. Arm zachęca nabywców infrastruktury, by oceniali procesory dla agentowej AI według ukończonej pracy na szafę, zamiast traktować wydajność gniazda jako ostateczną odpowiedź.
Benchmarki CPU Arm AGI przenoszą rywalizację na poziom szafy
Główne twierdzenie Arm nie polega na tym, że każdy CPU AGI przewyższa każdy procesor AMD niemal dwukrotnie na poziomie gniazda.
Analiza w skali szafy porównała procesor Arm z EPYC 9755 piątej generacji firmy AMD. Objęła siedem obciążeń związanych z wykonywaniem narzędzi, wyszukiwaniem, obsługą stron internetowych, inżynierią oprogramowania i wsparciem obsługi modeli.
Signal65 podał średni modelowany współczynnik wydajności na szafę wynoszący 1,99x dla Arm. Poszczególne wyniki na szafę mieściły się w przedziale od 1,43x do 3,19x, zależnie od obciążenia.
Siedem testów obejmowało MySQL, NGINX, Milvus, Terminal-Bench 2, odtworzenie SWE-bench, fastText oraz narzut CPU vLLM. Reprezentują one różne elementy ścieżki oprogramowania otaczającej model AI.
MySQL mierzy przepustowość transakcyjnej bazy danych. NGINX obejmuje obsługę żądań internetowych i API, a Milvus reprezentuje wyszukiwanie wektorowe dla pamięci i wyszukiwania agentów.
Terminal-Bench 2 bada pracę wykonywaną w izolowanych środowiskach wiersza poleceń. Test wykorzystał 72 typy zadań i uruchamiał jednocześnie 128 kopii.
Odtworzenie SWE-bench objęło 259 zadań z zakresu inżynierii oprogramowania. Zamiast prosić model o wybieranie innych działań podczas każdego uruchomienia, benchmark odtwarzał stały przepływ pracy.
Takie podejście oparte na odtwarzaniu ma znaczenie, ponieważ agenci AI są niedeterministyczni. Dwa uruchomienia mogą obejmować różne polecenia, opóźnienia usług zdalnych lub plany wygenerowane przez model, nawet gdy żądane zadanie jest identyczne.
fastText mierzył trenowanie reprezentacji słów na CPU. Test vLLM mierzył narzut procesora związany z obsługą modelu, z pominięciem głównej pracy obliczeniowej modelu.
To ostatnie rozróżnienie zapobiega częstej błędnej interpretacji. Wynik vLLM nie pokazuje, jak szybko CPU AGI wykonuje inferencję dużych modeli językowych w porównaniu z GPU.
Układ Arm wygrał pięć z siedmiu porównań na układ. Przewyższył AMD o 9% w Terminal-Bench, o 13% w odtworzeniu SWE-bench i o 97% w fastText.
AMD utrzymało przewagę w dwóch ugruntowanych obciążeniach infrastrukturalnych. EPYC 9755 był o 12% szybszy w MySQL i o 5% szybszy w Milvus na zmierzonym poziomie układu.
NGINX dał współczynnik 1,20x dla Arm. Obciążenie dotyczące narzutu CPU vLLM przyniosło Arm wynik 1,16x.
We wszystkich siedmiu znormalizowanych współczynnikach Arm osiągnął średnią przewagę 1,20x na układ. Wynik ten jest istotny, ale znacznie mniejszy niż wartość 1,99x przypisana twierdzeniu na poziomie szafy.
Model szafy przekształcił porównanie, uwzględniając znamionową moc serwerów. Przyjął od 950 do 1 050 watów dla dwugniazdowego serwera Arm, zależnie od konfiguracji CPU AGI.
Systemowi AMD przypisano szacowaną moc znamionową 1 700 watów. Oba obliczenia obejmowały pamięć i inne komponenty serwera, nie tylko moc projektową procesora.
Po zarezerwowaniu około 8% budżetu 24-kilowatowej szafy na sieć i dystrybucję zasilania model mieścił 21 lub 23 serwery Arm. W tym samym budżecie mieścił 13 serwerów AMD.
Dało to od 5 712 do 5 888 fizycznych rdzeni Arm na modelowaną szafę. Szafa AMD zawierała 3 328 fizycznych rdzeni.
Wynikający z tego mnożnik gęstości podniósł każde obciążenie Arm ponad AMD na poziomie szafy. Nawet MySQL, który faworyzował AMD na układ, stał się dla Arm modelowanym wynikiem 1,43x na szafę.
Milvus wzrósł z 0,95x na układ do 1,54x na szafę. Odtworzenie SWE-bench podniosło się z 1,13x do dokładnie 2,00x w modelu szafy.
fastText wygenerował największy współczynnik. Jego zmierzony wynik na układ 1,97x stał się modelowanym wynikiem 3,19x na szafę.
Dane te wspierają argument Arm, że centra danych ograniczone mocą powinny oceniać całkowitą użyteczną pracę. Nie pokazują dwóch działających szaf realizujących te obciążenia przy bezpośrednio zmierzonej mocy pobieranej z sieci.
Dlaczego agentowa AI czyni pracę CPU bardziej widoczną
Agenci AI przenoszą znaczną część pracy poza akcelerator, przez co pojemność CPU staje się częścią doświadczenia widocznego dla użytkownika.
Tradycyjne żądanie generatywnej AI może sprawiać wrażenie skupionego na inferencji modelu. Agent produkcyjny realizuje dłuższą sekwencję obejmującą planowanie, wyszukiwanie, wywołania narzędzi, walidację i zarządzanie stanem.
GPU lub inny akcelerator nadal wykonuje intensywne obliczenia sieci neuronowej. CPU koordynuje znaczną część otaczającej ścieżki wykonania i uruchamia wiele narzędzi wybieranych przez agenta.
Praktycznym przykładem jest agent programistyczny. Może on sprawdzić repozytorium, uruchomić sandbox, zainstalować zależności, skompilować kod, uruchomić testy i przeanalizować błędy.
Każde wywołanie modelu może uruchomić kolejną rundę pracy CPU. Jednoczesne działanie tysięcy agentów zwielokrotnia zapotrzebowanie stawiane kontenerom, bazom danych, API, pamięci masowej i systemom planowania.
Agenci korporacyjni tworzą inny profil. Mogą odpytywać rekordy, wywoływać usługi wewnętrzne, stosować zasady dostępu, serializować odpowiedzi, aktualizować stan przepływu pracy i zapisywać dzienniki audytowe.
Wyszukiwanie rozszerza obciążenie o indeksowanie i operacje wyszukiwania wektorowego. Obsługa modeli dodaje tokenizację, planowanie żądań, grupowanie wsadowe, strumieniowanie i zarządzanie metadanymi pamięci podręcznej wokół akceleratora.
Framework oceny Arm rozdziela tę pracę na funkcje frameworka agentów i narzędzia specyficzne dla danego zastosowania. Rozdziela też benchmarki komponentów od pomiarów zadań realizowanych end-to-end.
Testy komponentów pomagają wyizolować zachowanie procesora. Testy end-to-end pokazują, czy szybszy komponent przekłada się na szybsze lub bardziej niezawodne ukończenie zadania.
Żadne z tych podejść nie jest wystarczające samo w sobie. Procesor może prowadzić w benchmarku bazy danych, nie skracając całego przepływu pracy agenta, szczególnie gdy dominuje opóźnienie modelu.
Wynik end-to-end może również ukrywać przyczynę luki wydajnościowej. Różne modele, sieci, narzędzia lub decyzje agentów mogą przeważyć nad podstawową różnicą procesorów.
Arm proponuje odtwarzalne trajektorie agentów jako pomost między tymi podejściami. Trajektoria rejestruje operacje powstające podczas sesji agenta i wykonuje tę samą sekwencję na każdym systemie.
Technika ogranicza zmienność wynikającą z decyzji modelu. Czyni też porównanie bardziej powtarzalnym, ponieważ oba procesory otrzymują równoważny strumień pracy.
Odtwarzanie usuwa jednak część działania systemu na żywo. Mierzy, jak szybko infrastruktura wykonuje z góry ustaloną ścieżkę, a nie to, czy pełny stos jednego agenta znajduje lepszą ścieżkę.
Ta granica wyjaśnia, dlaczego określenie dotyczące rozumowania i planowania wymaga ostrożności. Odpowiednie testy mierzą wsparcie CPU dla tych przepływów pracy, a nie jakość maszynowego rozumowania.
Ta sama ostrożność dotyczy współbieżności. Serwer, który uruchamia więcej środowisk agentów, nie jest automatycznie lepszy, jeśli czasy odpowiedzi załamują się przy trwałym wykorzystaniu.
Metodologia Arm kładzie nacisk na ukończoną, użyteczną pracę przy zachowaniu responsywności. Takie ujęcie łączy przepustowość z fizycznymi ograniczeniami centrów danych.
Dostarczanie energii stało się jednym z takich ograniczeń. Wydajność chłodzenia i przestrzeń w szafie również ograniczają liczbę procesorów, które operator może wdrożyć, niezależnie od dostępności układów.
W takich warunkach przewaga na gniazdo nie zawsze zapewnia najlepszy wynik na poziomie całego obiektu. Umiarkowanie szybszy procesor może przegrać w skali szafy, jeśli obsługujący go serwer zużywa znacznie więcej energii.
Odwrotnie, bardziej wydajny serwer może zapewnić większą całkowitą pojemność, nawet gdy przegrywa w wybranych testach na poziomie układu. Wyniki Arm w MySQL i Milvus ilustrują tę możliwość w jego modelu.
Arm opracował metodologię przy wsparciu Fujitsu, Meta i OpenAI. Ich wsparcie sygnalizuje zainteresowanie bardziej reprezentatywnymi pomiarami CPU, ale nie czyni frameworka standardem branżowym.
Meta stwierdziła, że agenci produkcyjni wymagają większej widoczności tego, jak obciążenia wykorzystują leżącą pod nimi infrastrukturę. OpenAI wskazało orkiestrację i wykonywanie narzędzi jako obszary wymagające reprezentatywnego benchmarkingu.
Fujitsu powiązało ten wysiłek z rozwojem wysokowydajnego procesora opartego na Arm. Wszystkie trzy perspektywy wspierają lepszy pomiar, choć każda z organizacji ma również interes w infrastrukturze opartej na Arm.
Sam framework przyznaje, że nie jest ukończonym zestawem benchmarków. Definiuje kategorie obciążeń i granice pomiaru, pozostawiając nierozstrzygnięte punktację i szersze porozumienie.
To rozróżnienie jest kluczowe. Arm zaproponował sposób uporządkowania debaty, a następnie opublikował korzystne wyniki z testów zgodnych z tą propozycją.
Wynik 1,99x wynika z gęstości, a nie z dwukrotnego zwycięstwa układu
Historia wydajności CPU Arm AGI zależy bardziej od modelowanej gęstości wdrożenia niż od przytłaczającej wydajności na poziomie gniazda.
Arm testował dwie konfiguracje CPU AGI, ponieważ ten sam sprzęt nie był dostępny dla każdego obciążenia. Terminal-Bench 2 i SWE-bench używały 128-rdzeniowego układu pracującego z częstotliwością 2,8 GHz oraz pamięci DDR5-7200.
Pozostałe pięć obciążeń używało 136-rdzeniowego CPU AGI pracującego z częstotliwością 3,2 GHz i DDR5-8000. System porównawczy AMD wykorzystywał jedno 128-rdzeniowe gniazdo EPYC 9755 z DDR5-6400.
Obie platformy uruchamiały te same skrypty benchmarków. Nie działały w identycznych środowiskach programowych.
Większość testów Arm używała Ubuntu 24.04 z niestandardową kompilacją Linux 7.1.3. Test SWE-bench używał Ubuntu 26.04.
Główna zarejestrowana konfiguracja AMD używała Ubuntu 24.04 i Linux 6.8. Niektóre ustawienia również różniły się zależnie od testu.
Różnice programowe mogą wpływać na zachowanie kompilatorów, planowanie, sterowniki i wydajność aplikacji. Utrudniają przypisanie każdej różnicy wyłącznie architekturze procesora.
Model mocy serwera tworzy kolejne ważne rozróżnienie. Signal65 i Arm użyli wartości znamionowych zamiast mierzyć kompletne szafy produkcyjne pod obciążeniem.
Moc znamionowa pozostaje użyteczna w planowaniu pojemności. Operatorzy nie mogą instalować sprzętu przekraczającego projekt elektryczny i chłodzenia szafy, nawet jeśli typowe zużycie jest niższe.
Moc znamionowa może jednak odbiegać od zużycia zależnego od konkretnego obciążenia. System może pobierać mniej niż jego znamionowe maksimum podczas jednej aplikacji i zbliżać się do niego podczas innej.
Rzeczywisty pobór mocy zależy również od obsadzenia pamięci, pamięci masowej, sieci, chłodzenia, zasilaczy, firmware'u i zasad zarządzania systemem. Zmienne te stają się istotne, gdy liczba serwerów napędza główny przekaz.
Założenia dotyczące pamięci zmieniły raportowaną przewagę. Główny model Arm przypisał 4 GB na wątek sprzętowy.
Wielowątkowość współbieżna AMD udostępnia dwa wątki sprzętowe na rdzeń fizyczny. Testowana konstrukcja Arm używa jednego wątku na rdzeń.
Wybór ten zapewnił modelowanym serwerom AMD około 2 TB pamięci, a serwerom Arm około 1 TB. Przypisano 336 watów dla pamięci AMD i 192 waty dla pamięci Arm.
Signal65 obliczył również scenariusz, w którym pamięć przypisano do każdego fizycznego rdzenia. W tym wariancie AMD wymagało mniej energii na pamięć, a średnia przewaga Arm na szafę rack spadła z 1,99x do około 1,81x.
Arm nadal zachował znaczącą modelowaną przewagę. Spadek pokazuje, jak rozsądny wybór w planowaniu pojemności może istotnie zmienić końcowy wynik.
Pojemność pamięci to nie tylko szczegół benchmarku. Niektóre wdrożenia agentów utrzymują duże indeksy, cache'e, magazyny stanu lub środowiska współbieżnego wykonywania zadań.
Serwer z większą ilością pamięci może obsługiwać obciążenia, których gęstsza, lecz mniej pojemna konfiguracja nie jest w stanie efektywnie hostować. Kupujący muszą więc porównywać użyteczną pojemność systemu, a nie wyłącznie znormalizowaną przepustowość.
AMD EPYC 9755 obsługuje 128 fizycznych rdzeni i 256 wątków. Należy też do szerokiej platformy serwerowej wykorzystywanej w obciążeniach ogólnego przeznaczenia, bazach danych, wirtualizacji i hostingu AI.
Arm AGI CPU jest skierowany do bardziej wyspecjalizowanego zastosowania. Łączy gęste rdzenie Arm ze znaczną przepustowością pamięci i I/O dla infrastruktury AI.
Ta specjalizacja nie czyni żadnej z architektur uniwersalnie lepszą. Zmienia natomiast ograniczenia decydujące o lepszym wyborze.
Operator chmury działający przy stałym limicie mocy może priorytetowo traktować liczbę ukończonych zadań na szafę rack. Nabywca systemu bazodanowego może kłaść nacisk na wydajność na gniazdo, dojrzałość oprogramowania, pojemność pamięci lub sposób licencjonowania.
Operator klastra AI może dbać o utrzymanie kosztownych akceleratorów w ciągłej pracy. Szybsze przygotowanie i orkiestracja po stronie CPU mogą skrócić czas bezczynności akceleratorów, lecz testy te nie mierzyły kompletnego przepływu pracy wspieranego przez akceleratory.
To sprawia, że porównanie Arm AGI CPU z AMD jest węższe, niż sugeruje nagłówek. Jest to porównanie wybranych zadań widocznych dla CPU oraz modelowanego scenariusza wdrożenia.
Nie jest to analiza całkowitego kosztu posiadania. Opublikowane wyniki nie przedstawiają pełnego porównania kosztów zakupu, migracji oprogramowania, wsparcia operacyjnego, sieci ani zmian w infrastrukturze obiektowej.
Nie porównują też Arm z każdym istotnym procesorem x86. AMD oferuje inne konfiguracje EPYC, podczas gdy Intel konkuruje platformami Xeon w środowiskach przedsiębiorstw i wdrożeniach chmurowych.
Procesor Vera firmy Nvidia oferuje drugą ścieżkę opartą na Arm. Oddzielne badanie obciążeń Vera wykazało mocne wyniki na rdzeń wobec EPYC 9755 w zadaniach przypominających pracę agentów.
Badanie to nie mierzyło mocy ani przepustowości całego serwera. Jego węższy wynik podkreśla potrzebę rozróżniania twierdzeń dotyczących wydajności na rdzeń, na gniazdo, na szafę rack i w całym procesie end-to-end.
AMD również promuje CPU jako kluczowe elementy systemów agentic AI. Własny przykład zastosowania agentic CPU firmy podkreśla orkiestrację, przetwarzanie danych, bezpieczeństwo i wsparcie dla akceleratorów.
Rzeczywisty spór nie dotyczy więc tego, czy CPU mają znaczenie. Chodzi o to, jak kupujący powinni definiować obciążenie, normalizować systemy i przekształcać pomiary komponentów w decyzje wdrożeniowe.
Czego twierdzenie o wydajności Arm AGI CPU nie dowodzi
Signal65 zweryfikował rekordy i obliczenia Arm, ale proces ten nie był równoznaczny z niezależnym powtórzeniem testów w laboratorium.
Signal65 zdalnie obserwował przebieg testów Arm. Przeanalizował oryginalne logi, pliki wyników, skrypty i zapisy konfiguracji.
Oddzielny zespół recenzujący odtworzył obliczenia przy użyciu własnego kodu. Według analizy odtworzył wszystkie siedem wyników z dokładnością do 0,5%.
Ta praca zapewnia większą kontrolę niż niezweryfikowany wykres dostawcy. Sprawdza, czy zgłoszone współczynniki wynikają z zarejestrowanych rezultatów i modelu szafy rack.
Mimo to analiza została zlecona przez Arm, które dostarczyło testowane systemy. Signal65 nie pozyskał równoważnego sprzętu i nie powtórzył niezależnie pełnego eksperymentu we własnym laboratorium.
Przegląd napotkał również luki konfiguracji. Signal65 mógł niezależnie potwierdzić ustawienia BIOS i pamięci wyłącznie dla systemu EPYC 9965 użytego w osobnym porównaniu sandboxowym.
Nie mógł niezależnie zweryfikować wszystkich ustawień BIOS i pamięci systemów AGI CPU oraz EPYC 9755. Ogranicza to pewność co do źródła mniejszych różnic wydajności.
Rozróżnienie to ma największe znaczenie przy zbliżonych wynikach. Przewaga fastText wynosząca 97% prawdopodobnie nie zniknie przez niewielką zmianę ustawień, ale różnica 5% lub 9% zasługuje na dokładniejszą analizę.
Średnia arytmetyczna tworzy kolejne ograniczenie. Uśrednianie znormalizowanych współczynników daje każdemu obciążeniu taki sam wpływ, niezależnie od tego, jak często rzeczywiste wdrożenie wykonuje daną operację.
Jedna firma może stale wykonywać transakcje bazodanowe i rzadko trenować modele fastText. Inna może obsługiwać tysiące sandboxów do programowania i niewielką infrastrukturę transakcyjną.
Opublikowana średnia 1,99x nie prognozuje zatem przyrostu pojemności dla każdego nabywcy. Każdy operator potrzebuje wyniku ważonego obciążeniem, opartego na własnym profilu wykonywania zadań.
Pakiet testowy łączy również ustalone aplikacje z nowymi proxy dla agentów. MySQL i NGINX mają długą historię, podczas gdy benchmarki agentów oparte na odtwarzaniu pozostają relatywnie młode.
To połączenie jest użyteczne, ponieważ agenci wywołują znaną infrastrukturę. Jest także dyskusyjne, ponieważ wybrana mieszanka określa, co otrzymuje równą wagę.
Oryginalne omówienie zauważyło, że wynik nie potwierdza ogólnego przywództwa w agentic AI. Procesory, obciążenia, konfiguracje i opracowana przez Arm metodologia wyznaczają jego zakres.
W wyniku vLLM nie uwzględniono pełnego wnioskowania GPU. Kategoria rozumowania i planowania nie testowała, czy model rozumował dokładniej.
Obliczenie dla szafy rack nie obejmowało bezpośrednio zmierzonego wdrożenia o mocy 24 kilowatów. Modelowało liczbę serwerów na podstawie znamionowej mocy systemu po zarezerwowaniu pojemności dla infrastruktury rackowej.
Cena nie była częścią publicznego porównania. Nie uwzględniono też licencjonowania aplikacji, prac migracyjnych, szkolenia personelu ani kompatybilności z istniejącymi narzędziami wdrożeniowymi.
Te pominięcia nie unieważniają benchmarku. Definiują, co wynik może potwierdzać.
Arm może zasadnie stwierdzić, że jego testowane systemy zapewniły wyższą modelowaną przepustowość na szafę rack przy udokumentowanych założeniach. Nie może jednak przekształcić tego stwierdzenia w uniwersalne przywództwo w agentic AI.
AMD może zasadnie wskazywać na dwa zwycięstwa na poziomie pojedynczego układu oraz wpływ założeń dotyczących pamięci. Punkty te nie niwelują przewagi gęstości Arm w ramach opublikowanego modelu.
Najbardziej produktywna interpretacja leży między tymi stanowiskami. Arm przedstawił wiarygodną hipotezę, która uzasadnia szersze, niezależne testy na sprzęcie produkcyjnym.
Hipoteza zakłada, że moc szafy rack i trwała przepustowość narzędzi agentów powinny mieć większą wagę niż tradycyjne porównania gniazd. Wynik 1,99x jest wczesnym studium przypadku na rzecz tego argumentu.
Dla nabywców metoda może okazać się równie wpływowa jak obecny zwycięzca. Wspólny, przejrzysty pakiet pozwoliłby operatorom porównywać Arm, AMD, Intel i Nvidia w identycznych granicach.
Taki pakiet musiałby obejmować mierzoną moc systemu, równoważne oprogramowanie, udokumentowane firmware, ważenie na poziomie obciążenia oraz powtarzalną walidację end-to-end.
Powinien także przedstawiać kilka perspektyw zamiast kompresować wszystko do jednego współczynnika. Wyniki na rdzeń, na gniazdo, na wat, na szafę rack i na dolara odpowiadają na różne pytania operacyjne.
Sukces zadania i opóźnienie powinny pozostawać oddzielone od przepustowości infrastruktury. System, który kończy więcej odtwarzanych działań, może nie zapewniać lepszych rezultatów agentów, jeśli dominują opóźnienia modelu lub sieci.
Trzy sygnały zdecydują, czy twierdzenie Arm dotyczące szafy rack się utrzyma
Sprzęt produkcyjny, szersze testy konkurentów i wdrożenia klientów zdecydują, czy modelowana przewaga Arm stanie się przewagą operacyjną.
Pierwszym sygnałem są niezależne testy na końcowych produkcyjnych systemach AGI CPU. Signal65 podał, że obecne wyniki odzwierciedlają wczesne systemy i że planowane są szersze prace następcze.
Przekonujące badanie uzupełniające powinno mierzyć pełną moc serwera podczas każdego obciążenia. Powinno wykorzystywać porównywalne systemy operacyjne, ustawienia kompilatora, pojemność pamięci, firmware i warunki chłodzenia.
Najmocniejszy test obejmowałby wiele serwerów i eksperymentalną walidację obliczenia dla szafy rack. Pokazałoby to, czy gęstość, sieć, warunki termiczne i trwałe wykorzystanie zachowują się zgodnie z modelem.
Jeśli testy produkcyjne pozostaną blisko średniej 1,99x, pozycja Arm znacznie się wzmocni. Duży spadek pokazałby, że modelowanie oparte na mocy znamionowej zawyżyło możliwą do wdrożenia pojemność.
Drugim sygnałem jest porównanie z szerszą grupą procesorów. AMD EPYC 9755 jest ważny, ale jeden procesor x86 nie może reprezentować całego rynku.
Nowsze opcje AMD o większej liczbie rdzeni mogłyby zmienić obliczenie gęstości. Intel może działać inaczej w obsłudze webowej, bazach danych, wyszukiwaniu i wykonywaniu narzędzi.
Nvidia Vera również zasługuje na bezpośrednie porównanie, ponieważ wykorzystuje rdzenie kompatybilne z Arm, ale celuje w infrastrukturę AI poprzez inną konstrukcję systemu. Łączność z akceleratorami tworzy kolejną ścieżkę wdrożeniową.
Szersze testy powinny używać tych samych obciążeń i przejrzystego punktowania. Wybory benchmarków specyficzne dla dostawcy pozostawiłyby nabywców porównujących niekompatybilne twierdzenia.
Jeśli Arm utrzyma przewagę na szafę rack wobec wielu konkurentów, jego metodologia zyska wiarygodność wykraczającą poza jedno korzystne zestawienie. Jeśli przewaga będzie gwałtownie się zmieniać, dobór obciążeń stanie się ważniejszą historią.
Trzecim sygnałem jest rzeczywiste wdrożenie u klientów z ujawnionymi danymi operacyjnymi. Arm pozycjonuje AGI CPU dla hyperscalerów i innych dużych operatorów infrastruktury AI.
Publiczne wdrożenie powinno raportować wykonaną pracę, opóźnienie, moc i wykorzystanie przed migracją oraz po niej. Powinno także wyjaśniać wszelkie zmiany oprogramowania wymagane dla architektury Arm.
Dowody operacyjne mogą ujawnić problemy pomijane przez benchmarki. Obejmują one kompatybilność zależności, obserwowalność, dostępność obrazów kontenerów, rozmieszczanie obciążeń, odzyskiwanie po awariach i nakład pracy administratorów.
Wyniki klientów będą miały największe znaczenie, gdy obejmą trwały ruch produkcyjny. Krótkie demonstracje nie mogą odtworzyć wzorca zapotrzebowania tysięcy trwałych agentów.
Październikowe ogłoszenie Arm dotyczące benchmarków z 2026 r. Arm benchmark announcement przedstawia jasny argument za oceną infrastruktury w skali szafy rack. Stwierdza również, że metodologia musi ewoluować wraz ze zmianami architektur agentów.
To przyznanie jest właściwe. Oprogramowanie agentic pozostaje płynne, a dzisiejsza reprezentatywna sekwencja narzędzi może jutro stać się przestarzałym proxy.
Zespoły infrastruktury powinny traktować benchmarki Arm AGI CPU jako powód do zbadania własnych wąskich gardeł, a nie jako uniwersalny werdykt zakupowy.
Zacznij od prześledzenia, gdzie agent spędza czas. Oddziel wnioskowanie modelu od wyszukiwania, uruchamiania sandboxów, wykonywania narzędzi, dostępu do baz danych, orkiestracji i walidacji.
Następnie przypisz te etapy do rzeczywistego ograniczenia. Klaster może mierzyć się z limitem mocy, ograniczeniem pojemności pamięci, niedożywieniem akceleratorów lub niedopuszczalnym opóźnieniem zadań.
Proces ten może przekształcić szerokie twierdzenie dostawcy w sprawdzalne lokalne pytanie. Zapobiega też zastąpieniu planowania pojemności specyficznego dla obciążenia jedną średnią benchmarku.
Zespoły inżynieryjne oceniające infrastrukturę agentów mogą przechowywać notatki benchmarkowe, zapisy konfiguracji i ustalenia wdrożeniowe w przeszukiwalnej bazie wiedzy. Taki zapis staje się wartościowy, gdy zmiany w oprogramowaniu lub sprzęcie unieważniają wcześniejsze porównanie.
Arm ustanowił pozycję wyjściową: jego procesor osiągnął średnio 1,20x na układ i 1,99x na modelowaną szafę rack w siedmiu wybranych obciążeniach. AMD nadal wygrało dwa testy na poziomie układu, a kilka założeń wpłynęło na większy współczynnik.
Kolejna decyzja należy do niezależnych testerów i nabywców infrastruktury. Czy zmierzone szafy produkcyjne potwierdzą przewagę Arm pod względem gęstości, czy rzeczywiste obciążenia zmniejszą tę różnicę?
