I benchmark delle CPU AGI di Arm mettono AMD sotto pressione, ma il vantaggio di 1,99x è modellato

Arm afferma che il suo nuovo processore completa quasi il doppio del lavoro per rack rispetto a EPYC 9755 di AMD in sette carichi di lavoro selezionati. I benchmark delle CPU AGI di Arm riportano un vantaggio medio di 1,99x dopo aver scalato i risultati misurati sui chip usando ipotesi relative al consumo dei server.

Quel titolo suona come una sconfitta netta per AMD. I risultati sottostanti raccontano una storia più sfumata. Arm ha registrato in media un vantaggio di 1,20x per chip, mentre il suo vantaggio molto più ampio a livello di rack derivava principalmente dalla possibilità di collocare più server entro un budget energetico fisso.

Signal65 ha esaminato i test attraverso un’analisi commissionata da Arm. Tuttavia, non ha rieseguito in modo indipendente l’intero confronto su hardware separato. Il benchmark valuta inoltre il lavoro della CPU attorno agli agenti AI, non l’intelligenza dei modelli né l’inferenza degli acceleratori.

Il risultato è quindi importante per una ragione specifica. Arm chiede agli acquirenti di infrastrutture di valutare le CPU per AI agentica in base al lavoro completato per rack, anziché considerare le prestazioni per socket come la risposta definitiva.

I benchmark delle CPU AGI di Arm spostano la sfida sul rack

L’affermazione centrale di Arm non è che ogni CPU AGI superi ogni processore AMD di quasi due volte a livello di socket.

L’analisi su scala rack ha confrontato il processore di Arm con EPYC 9755 di AMD di quinta generazione. Ha coperto sette carichi di lavoro relativi all’esecuzione di strumenti, al recupero delle informazioni, al web serving, all’ingegneria del software e al supporto al model serving.

Signal65 ha riportato un rapporto medio di prestazioni per rack modellate di 1,99x a favore di Arm. I singoli risultati per rack andavano da 1,43x a 3,19x, a seconda del carico di lavoro.

I sette test erano MySQL, NGINX, Milvus, Terminal-Bench 2, una riproduzione di SWE-bench, fastText e l’overhead CPU di vLLM. Rappresentano diverse parti del percorso software che circonda un modello AI.

MySQL misura il throughput dei database transazionali. NGINX copre la gestione delle richieste web e API, mentre Milvus rappresenta il recupero vettoriale per la memoria e la ricerca degli agenti.

Terminal-Bench 2 esamina il lavoro svolto in ambienti a riga di comando isolati. Il test ha usato 72 tipi di attività ed eseguito contemporaneamente 128 copie.

La riproduzione di SWE-bench ha coperto 259 attività di ingegneria del software. Anziché chiedere a un modello di scegliere azioni diverse durante ogni esecuzione, il benchmark ha riprodotto un flusso di lavoro fisso.

Questo approccio di riproduzione è importante perché gli agenti AI sono non deterministici. Due esecuzioni possono comportare comandi diversi, ritardi di servizi remoti o piani generati dal modello, anche quando l’attività richiesta è identica.

fastText ha misurato l’addestramento CPU delle rappresentazioni delle parole. Il test vLLM ha misurato l’overhead del processore attorno al model serving, escludendo il lavoro computazionale principale del modello.

Quest’ultima distinzione evita un’interpretazione errata comune. Il risultato vLLM non mostra quanto rapidamente la CPU AGI esegua l’inferenza di modelli linguistici di grandi dimensioni rispetto a una GPU.

Il chip di Arm ha vinto cinque dei sette confronti per chip. Ha superato AMD del 9% in Terminal-Bench, del 13% nella riproduzione di SWE-bench e del 97% in fastText.

AMD ha mantenuto il vantaggio in due carichi di lavoro infrastrutturali consolidati. EPYC 9755 era più veloce del 12% in MySQL e del 5% in Milvus a livello di chip misurato.

NGINX ha prodotto un rapporto di 1,20x per Arm. Il carico di lavoro relativo all’overhead CPU di vLLM ha dato ad Arm un risultato di 1,16x.

Considerando tutti e sette i rapporti normalizzati, Arm ha registrato in media un vantaggio di 1,20x per chip. Il risultato è significativo, ma molto inferiore alla cifra di 1,99x associata all’affermazione a livello di rack.

Il modello del rack ha trasformato il confronto tenendo conto della potenza nominale dei server. Ha ipotizzato tra 950 e 1.050 watt per un server Arm a due socket, a seconda della configurazione della CPU AGI.

Al sistema AMD è stata attribuita una stima di potenza nominale di 1.700 watt. Entrambi i calcoli includevano memoria e altri componenti del server, non solo la potenza di progetto termico del processore.

Dopo aver riservato circa l’8% di un budget rack di 24 kilowatt per rete e distribuzione dell’alimentazione, il modello collocava 21 o 23 server Arm. Nello stesso budget collocava 13 server AMD.

Ciò ha prodotto tra 5.712 e 5.888 core fisici Arm per rack modellato. Il rack AMD conteneva 3.328 core fisici.

Il moltiplicatore di densità risultante ha portato ogni carico di lavoro Arm sopra AMD a livello di rack. Persino MySQL, che favoriva AMD per chip, è diventato un risultato modellato di 1,43x per Arm per rack.

Milvus è passato da 0,95x per chip a 1,54x per rack. La riproduzione di SWE-bench è salita da 1,13x a esattamente 2,00x nel modello del rack.

fastText ha generato il rapporto più elevato. Il suo risultato misurato sul chip di 1,97x è diventato un risultato modellato di 3,19x per rack.

Queste cifre supportano l’argomentazione di Arm secondo cui i data center vincolati dalla potenza dovrebbero valutare il lavoro utile totale. Non mostrano due rack operativi che completano tali carichi di lavoro con una potenza alla presa misurata direttamente.

Perché l’AI agentica rende più visibile il lavoro della CPU

Gli agenti AI spostano una quantità sostanziale di lavoro fuori dall’acceleratore, rendendo la capacità della CPU parte dell’esperienza visibile all’utente.

Una richiesta convenzionale di AI generativa può sembrare incentrata sull’inferenza del modello. Un agente di produzione esegue una sequenza più lunga che include pianificazione, recupero delle informazioni, chiamate a strumenti, convalida e gestione dello stato.

La GPU o un altro acceleratore continua a eseguire i calcoli densi della rete neurale. La CPU coordina gran parte del percorso di esecuzione circostante ed esegue molti strumenti selezionati dall’agente.

Un agente di coding offre un esempio pratico. Può ispezionare un repository, avviare una sandbox, installare dipendenze, compilare codice, eseguire test e analizzare i fallimenti.

Ogni chiamata al modello può attivare un altro ciclo di lavoro della CPU. L’esecuzione simultanea di migliaia di agenti moltiplica la domanda su container, database, API, storage e sistemi di pianificazione.

Gli agenti aziendali creano un profilo diverso. Possono interrogare record, chiamare servizi interni, applicare politiche di accesso, serializzare risposte, aggiornare lo stato dei flussi di lavoro e scrivere registri di audit.

Il recupero delle informazioni aggiunge operazioni di indicizzazione e ricerca vettoriale. Il model serving aggiunge tokenizzazione, pianificazione delle richieste, batching, streaming e gestione dei metadati della cache attorno all’acceleratore.

Il framework di valutazione di Arm separa questo lavoro in funzioni del framework degli agenti e strumenti specifici per il caso d’uso. Separa inoltre i benchmark dei componenti dalle misurazioni delle attività end-to-end.

I test dei componenti aiutano a isolare il comportamento del processore. I test end-to-end mostrano se un componente più veloce produce un’attività completata più rapida o più affidabile.

Nessuno dei due approcci è sufficiente da solo. Un processore può primeggiare in un benchmark di database senza accorciare il flusso di lavoro complessivo di un agente, in particolare quando domina la latenza del modello.

Un risultato end-to-end può anche nascondere la causa di un divario prestazionale. Modelli, reti, strumenti o decisioni degli agenti diversi possono prevalere sulla differenza tra i processori sottostanti.

Arm propone traiettorie di agenti riproducibili come ponte tra questi approcci. Una traiettoria registra le operazioni prodotte durante una sessione di un agente ed esegue la stessa sequenza su ciascun sistema.

La tecnica riduce la variazione dovuta alle decisioni del modello. Rende inoltre il confronto più ripetibile perché entrambi i processori ricevono un flusso di lavoro equivalente.

Tuttavia, la riproduzione rimuove una parte del sistema live. Misura la rapidità con cui l’infrastruttura esegue un percorso predeterminato, non se uno stack completo di agenti individua un percorso migliore.

Questo confine spiega perché l’etichetta di ragionamento e pianificazione richiede cautela. I test rilevanti misurano il supporto della CPU per tali flussi di lavoro, anziché la qualità del ragionamento automatico.

La stessa cautela si applica alla concorrenza. Un server che avvia più ambienti per agenti non è automaticamente migliore se i tempi di risposta collassano sotto un utilizzo sostenuto.

La metodologia di Arm enfatizza il lavoro utile completato mantenendo la reattività. Questa impostazione collega il throughput ai limiti fisici che i data center devono affrontare.

La distribuzione dell’alimentazione è diventata uno di questi limiti. Anche la capacità di raffreddamento e lo spazio rack limitano il numero di processori che un operatore può distribuire, indipendentemente dalla disponibilità dei chip.

In tali condizioni, la leadership per socket non produce sempre il miglior risultato a livello di struttura. Un processore moderatamente più veloce può perdere su scala rack se il server che lo supporta consuma molta più energia.

Viceversa, un server più efficiente può creare una capacità totale maggiore anche quando perde in test selezionati a livello di chip. I risultati di Arm in MySQL e Milvus illustrano questa possibilità all’interno del suo modello.

Arm ha sviluppato la metodologia con il supporto di Fujitsu, Meta e OpenAI. Il loro supporto segnala interesse per misurazioni della CPU più rappresentative, ma non rende il framework uno standard del settore.

Meta ha affermato che gli agenti di produzione richiedono maggiore visibilità su come i carichi di lavoro sfruttano l’infrastruttura sottostante. OpenAI ha evidenziato l’orchestrazione e l’esecuzione degli strumenti come aree che necessitano di benchmark rappresentativi.

Fujitsu ha collegato l’iniziativa allo sviluppo di un processore Arm ad alte prestazioni. Tutte e tre le prospettive sostengono misurazioni migliori, sebbene ciascuna organizzazione abbia anche un interesse nell’infrastruttura basata su Arm.

Il framework stesso riconosce di non essere una suite di benchmark definitiva. Definisce categorie di carico di lavoro e confini di misurazione, lasciando irrisolti il punteggio e un accordo più ampio.

Questa distinzione è essenziale. Arm ha proposto un modo per strutturare il dibattito, quindi ha pubblicato risultati favorevoli usando test allineati a quella proposta.

Il risultato di 1,99x deriva dalla densità, non da una vittoria del chip di 2x

La storia delle prestazioni delle CPU AGI di Arm dipende più dalla densità di distribuzione modellata che da prestazioni schiaccianti a livello di socket.

Arm ha testato due configurazioni di CPU AGI perché lo stesso hardware non era disponibile per ogni carico di lavoro. Terminal-Bench 2 e SWE-bench hanno usato un chip a 128 core funzionante a 2,8 GHz con memoria DDR5-7200.

Gli altri cinque carichi di lavoro hanno usato una CPU AGI a 136 core funzionante a 3,2 GHz con DDR5-8000. Il sistema di confronto AMD usava un socket EPYC 9755 a 128 core con DDR5-6400.

Entrambe le piattaforme hanno eseguito gli stessi script di benchmark. Non hanno eseguito ambienti software identici.

La maggior parte dei test Arm usava Ubuntu 24.04 con una build personalizzata di Linux 7.1.3. Il test SWE-bench usava Ubuntu 26.04.

La principale configurazione registrata di AMD usava Ubuntu 24.04 e Linux 6.8. Anche alcune impostazioni variavano in base al test.

Le differenze software possono influire sul comportamento del compilatore, sulla pianificazione, sui driver e sulle prestazioni delle applicazioni. Rendono più difficile attribuire ogni divario esclusivamente all’architettura del processore.

Il modello della potenza del server crea un’altra distinzione importante. Signal65 e Arm hanno usato valori nominali anziché misurare rack di produzione completi sotto carico.

La potenza nominale resta utile per la pianificazione della capacità. Gli operatori non possono installare apparecchiature che superano il progetto elettrico e di raffreddamento di un rack, anche se il consumo tipico è inferiore.

Tuttavia, la potenza nominale può divergere dal consumo specifico del carico di lavoro. Un sistema potrebbe assorbire meno del massimo nominale durante un’applicazione e avvicinarsi a esso durante un’altra.

La potenza effettiva dipende anche dalla configurazione della memoria, dallo storage, dalla rete, dal raffreddamento, dagli alimentatori, dal firmware e dalle politiche di gestione del sistema. Queste variabili diventano rilevanti quando il numero di server determina il titolo principale.

Le ipotesi sulla memoria hanno modificato il vantaggio riportato. Il modello principale di Arm assegnava 4 GB per thread hardware.

Il multithreading simultaneo di AMD espone due thread hardware per core fisico. Il design Arm testato usa un thread per core.

Questa scelta ha assegnato ai server AMD modellati circa 2 TB di memoria e ai server Arm circa 1 TB. Ha allocato 336 watt alla memoria AMD e 192 watt a quella Arm.

Signal65 ha calcolato anche uno scenario che assegnava memoria per core fisico. In tale alternativa, AMD richiedeva meno potenza per la memoria e il vantaggio medio per rack di Arm scendeva da 1,99x a circa 1,81x.

Arm conservava comunque un sostanziale vantaggio modellato. La diminuzione mostra come una scelta ragionevole nella pianificazione della capacità possa modificare materialmente il valore finale.

La capacità di memoria non è soltanto un dettaglio di benchmarking. Alcune implementazioni di agenti mantengono indici di grandi dimensioni, cache, archivi di stato o ambienti di esecuzione concorrenti.

Un server con più memoria può supportare carichi di lavoro che una configurazione più densa ma con minore capacità non riesce a ospitare in modo efficiente. Gli acquirenti devono quindi confrontare la capacità di sistema utilizzabile, non solo il throughput normalizzato.

L'EPYC 9755 di AMD supporta 128 core fisici e 256 thread. Fa inoltre parte di un'ampia piattaforma server utilizzata per carichi di lavoro general-purpose, database, virtualizzazione e hosting AI.

La CPU AGI di Arm punta a una proposta più specifica. Combina core Arm densi con una notevole larghezza di banda della memoria e I/O per l'infrastruttura AI.

Questa specializzazione non rende nessuna delle due architetture universalmente superiore. Cambia i vincoli che determinano la scelta migliore.

Un operatore cloud con un limite di potenza fisso potrebbe dare priorità ai job completati per rack. Un acquirente di database potrebbe privilegiare le prestazioni per socket, la maturità del software, la capacità di memoria o il comportamento delle licenze.

Un operatore di cluster AI può preoccuparsi di mantenere occupati acceleratori costosi. Una preparazione e un'orchestrazione più rapide lato CPU possono ridurre il tempo di inattività degli acceleratori, ma questi test non hanno misurato un flusso di lavoro completo supportato da acceleratori.

Questo rende il confronto tra CPU Arm AGI e AMD più circoscritto di quanto suggerisca il titolo. Si tratta di un confronto tra attività selezionate visibili alla CPU e uno scenario di implementazione modellato.

Non è uno studio sul costo totale. I risultati pubblicati non forniscono un confronto completo tra costi di acquisizione, migrazione software, supporto operativo, rete o modifiche alle strutture.

Inoltre, non confrontano Arm con tutti i processori x86 rilevanti. AMD dispone di altre configurazioni EPYC, mentre Intel compete con piattaforme Xeon nelle implementazioni enterprise e cloud.

Il processore Vera di Nvidia aggiunge una seconda strada basata su Arm. Uno studio separato sui carichi di lavoro Vera ha riportato solidi risultati per core rispetto all'EPYC 9755 nelle attività simili a quelle degli agenti.

Quello studio non ha misurato la potenza né il throughput dell'intero server. Il suo risultato più circoscritto rafforza la necessità di separare le affermazioni per core, per socket, per rack e end-to-end.

Anche AMD promuove le CPU come componenti critici dei sistemi di AI agentica. Il suo caso d'uso sulle CPU agentiche enfatizza orchestrazione, elaborazione dei dati, sicurezza e supporto agli acceleratori.

Il vero disaccordo non riguarda quindi l'importanza delle CPU. Riguarda il modo in cui gli acquirenti dovrebbero definire il carico di lavoro, normalizzare i sistemi e trasformare le misurazioni dei componenti in decisioni di implementazione.

Cosa non dimostra l'affermazione sulle prestazioni della CPU Arm AGI

Signal65 ha convalidato i record e i calcoli di Arm, ma tale processo non equivaleva a una ripetizione indipendente in laboratorio.

Signal65 ha osservato da remoto le esecuzioni dei test di Arm. Ha esaminato log originali, file dei risultati, script e registri di configurazione.

Un team di revisione separato ha ricostruito i calcoli usando il proprio codice. Secondo l'analisi, ha riprodotto tutti e sette i risultati con uno scostamento entro lo 0,5%.

Questo lavoro offre un controllo più approfondito rispetto a un grafico di un fornitore non sottoposto a revisione. Verifica se i rapporti riportati derivano dai risultati acquisiti e dal modello di rack.

Tuttavia, Arm ha commissionato l'analisi e fornito i sistemi testati. Signal65 non ha acquisito hardware equivalente né ripetuto in modo indipendente l'intero esperimento nel proprio laboratorio.

La revisione ha inoltre dovuto affrontare lacune di configurazione. Signal65 ha potuto confermare in modo indipendente le impostazioni BIOS e della memoria solo per un sistema EPYC 9965 utilizzato in un confronto sandbox separato.

Non ha potuto verificare in modo indipendente ogni impostazione BIOS e della memoria per i sistemi con CPU AGI ed EPYC 9755. Ciò limita la certezza sull'origine delle differenze di prestazioni minori.

La distinzione conta soprattutto per i risultati ravvicinati. Un vantaggio del 97% in fastText difficilmente scomparirà a causa di una modifica minore delle impostazioni, ma un divario del 5% o del 9% merita un esame più attento.

La media aritmetica crea un'altra limitazione. La media dei rapporti normalizzati attribuisce a ogni carico di lavoro la stessa influenza, indipendentemente dalla frequenza con cui un'implementazione reale esegue tale operazione.

Un'azienda potrebbe eseguire continuamente transazioni di database e addestrare raramente modelli fastText. Un'altra potrebbe gestire migliaia di sandbox per la scrittura di codice e poca infrastruttura transazionale.

La media pubblicata di 1,99x non prevede quindi il guadagno di capacità di ogni acquirente. Ogni operatore necessita di un risultato ponderato per carico di lavoro basato sul proprio profilo di esecuzione.

La suite di test mescola inoltre applicazioni consolidate con proxy di agenti emergenti. MySQL e NGINX hanno una lunga storia, mentre i benchmark degli agenti basati su replay restano relativamente giovani.

Questa combinazione è utile perché gli agenti richiamano infrastrutture familiari. È anche discutibile perché il mix selezionato determina ciò che riceve lo stesso peso.

Il reporting originale ha osservato che il risultato non stabilisce una leadership complessiva nell'AI agentica. I processori, i carichi di lavoro, le configurazioni e la metodologia sviluppata da Arm ne definiscono l'ambito.

Nel risultato vLLM non è stata inclusa alcuna inferenza GPU completa. La categoria di ragionamento e pianificazione non ha testato se un modello ragionasse con maggiore accuratezza.

Il calcolo del rack non includeva un'implementazione da 24 kilowatt misurata direttamente. Ha modellato il numero di server in base alla potenza nominale del sistema dopo aver riservato capacità per l'infrastruttura del rack.

Il prezzo non faceva parte del confronto pubblico. Nemmeno le licenze applicative, il lavoro di migrazione, la formazione del personale o la compatibilità con gli strumenti di implementazione esistenti.

Queste omissioni non invalidano il benchmark. Definiscono ciò che il risultato può sostenere.

Arm può ragionevolmente affermare che i suoi sistemi testati hanno prodotto un throughput per rack modellato più elevato secondo le ipotesi documentate. Non può trasformare questa affermazione in una leadership universale nell'AI agentica.

AMD può ragionevolmente indicare le due vittorie per chip e l'effetto delle ipotesi sulla memoria. Questi aspetti non eliminano il vantaggio di densità di Arm all'interno del modello pubblicato.

L'interpretazione più produttiva si colloca tra queste posizioni. Arm ha presentato un'ipotesi credibile che giustifica test più ampi e indipendenti su hardware di produzione.

L'ipotesi è che la potenza del rack e il throughput sostenuto degli strumenti degli agenti debbano avere più peso rispetto ai tradizionali confronti per socket. Il risultato di 1,99x è un primo caso di studio a sostegno di questa tesi.

Per gli acquirenti, il metodo potrebbe rivelarsi influente quanto il vincitore attuale. Una suite comune e trasparente consentirebbe agli operatori di confrontare Arm, AMD, Intel e Nvidia entro confini identici.

Una simile suite richiederebbe potenza di sistema misurata, software equivalente, firmware documentato, ponderazione a livello di carico di lavoro e convalida end-to-end ripetibile.

Dovrebbe inoltre riportare diverse prospettive anziché comprimere tutto in un unico rapporto. I risultati per core, per socket, per watt, per rack e per dollaro rispondono a domande operative diverse.

Il successo dell'attività e la latenza dovrebbero rimanere distinti dal throughput dell'infrastruttura. Un sistema che completa più azioni riprodotte potrebbe non offrire risultati migliori degli agenti se dominano i ritardi del modello o della rete.

Tre segnali decideranno se l'affermazione di Arm sul rack regge

L'hardware di produzione, test più ampi sui concorrenti e le implementazioni dei clienti determineranno se il vantaggio modellato di Arm diventerà operativo.

Il primo segnale è costituito da test indipendenti sui sistemi CPU AGI finali di produzione. Signal65 ha dichiarato che i risultati attuali riflettono sistemi iniziali e che sono pianificati lavori di follow-up più ampi.

Un follow-up convincente dovrebbe misurare la potenza completa del server durante ciascun carico di lavoro. Dovrebbe utilizzare sistemi operativi comparabili, impostazioni del compilatore, capacità di memoria, firmware e condizioni di raffreddamento.

Il test più solido popolerebbe più server e convaliderebbe sperimentalmente il calcolo del rack. Mostrerebbe se densità, rete, aspetti termici e utilizzo sostenuto si comportano come previsto dal modello.

Se i test di produzione restassero vicini alla media di 1,99x, la posizione di Arm diventerebbe molto più forte. Un forte calo mostrerebbe che la modellazione della potenza nominale ha sovrastimato la capacità implementabile.

Il secondo segnale è il confronto con un campo più ampio di processori. L'AMD EPYC 9755 è importante, ma un solo processore x86 non può rappresentare l'intero mercato.

Le opzioni AMD più recenti e con un numero maggiore di core potrebbero modificare il calcolo della densità. Intel potrebbe comportarsi diversamente tra web serving, database, recupero delle informazioni ed esecuzione di strumenti.

Anche Nvidia Vera merita un confronto diretto perché utilizza core compatibili con Arm, ma punta all'infrastruttura AI attraverso un diverso design di sistema. La sua connettività con gli acceleratori crea un ulteriore percorso di implementazione.

Test più ampi dovrebbero utilizzare gli stessi carichi di lavoro e una valutazione trasparente. Selezioni di benchmark specifiche per ciascun fornitore lascerebbero gli acquirenti a confrontare affermazioni incompatibili.

Se Arm mantiene un vantaggio per rack su più concorrenti, la sua metodologia acquista credibilità oltre un singolo confronto favorevole. Se la leadership varia nettamente, la selezione dei carichi di lavoro diventa l'aspetto più importante.

Il terzo segnale è l'adozione reale da parte dei clienti con dati operativi divulgati. Arm ha posizionato la CPU AGI per hyperscaler e altri grandi operatori di infrastrutture AI.

Un'implementazione pubblica dovrebbe riportare lavoro completato, latenza, potenza e utilizzo prima e dopo la migrazione. Dovrebbe inoltre spiegare eventuali modifiche software necessarie per l'architettura Arm.

Le prove operative possono rivelare problemi che i benchmark non rilevano. Tra questi vi sono compatibilità delle dipendenze, osservabilità, disponibilità delle immagini container, collocamento dei carichi di lavoro, recupero dagli errori e impegno degli amministratori.

I risultati dei clienti saranno più importanti quando copriranno traffico di produzione sostenuto. Brevi dimostrazioni non possono riprodurre il modello di domanda di migliaia di agenti persistenti.

L'annuncio dei benchmark Arm dell'ottobre 2026 presenta un chiaro argomento a favore della valutazione dell'infrastruttura su scala rack. Afferma inoltre che la metodologia deve evolversi con il cambiamento delle architetture degli agenti.

Questa ammissione è appropriata. Il software agentico rimane fluido e la sequenza di strumenti rappresentativa di oggi può diventare il proxy obsoleto di domani.

I team infrastrutturali dovrebbero usare i benchmark della CPU Arm AGI come motivo per esaminare i propri colli di bottiglia, non come un verdetto universale sugli acquisti.

Iniziate tracciando dove un agente trascorre il proprio tempo. Separate l'inferenza del modello da recupero delle informazioni, avvio della sandbox, esecuzione degli strumenti, accesso al database, orchestrazione e convalida.

Quindi mappate queste fasi sul vincolo effettivo. Un cluster può trovarsi di fronte a un limite di potenza, un limite di capacità di memoria, fame degli acceleratori o una latenza dell'attività inaccettabile.

Questo processo può trasformare un'ampia affermazione di un fornitore in una domanda locale verificabile. Impedisce inoltre che una media di benchmark sostituisca la pianificazione della capacità specifica per il carico di lavoro.

I team di ingegneria che valutano l'infrastruttura per agenti possono conservare note sui benchmark, registri di configurazione e risultati delle implementazioni in una base di conoscenza ricercabile. Questo archivio diventa prezioso quando modifiche software o hardware invalidano un confronto precedente.

Arm ha stabilito la posizione iniziale: il suo processore ha registrato una media di 1,20x per chip e 1,99x per rack modellato in sette carichi di lavoro selezionati. AMD ha comunque vinto due test a livello di chip e diverse ipotesi hanno influenzato il rapporto più elevato.

La prossima decisione spetta ai tester indipendenti e agli acquirenti di infrastrutture. I rack di produzione misurati confermeranno il vantaggio di densità di Arm, oppure i carichi di lavoro reali ridurranno il divario?