Nel resoconto pubblicato il 29 ottobre 2026, Tom’s Hardware ha descritto un prototipo di benchmark CPU per l’IA agentica: riproduce risposte del modello già registrate e misura quante attività degli agenti terminano ogni secondo mentre aumenta il numero di sessioni simultanee. L’articolo presenta il metodo e indica i primi risultati reali come passo successivo, senza pubblicare punteggi comparativi tra processori.
Indice
- Che cosa misura il test
- Come vengono registrate e riprodotte le sessioni
- Riproduzione congelata e inferenza dal vivo
- Carichi di lavoro e confini dei risultati
Che cosa misura il test
Una sessione corrisponde a un’attività completata dall’inizio alla fine. Il prototipo conta le sessioni concluse al secondo a diversi livelli di concorrenza, cioè con un numero crescente di agenti al lavoro insieme. La misura serve a osservare come cambia il lavoro della CPU quando le attività si sovrappongono: gli strumenti usati da un singolo agente possono impegnarla per poco tempo, mentre più sessioni simultanee possono contendersi le risorse.
Tom’s Hardware definisce il throughput di picco come il valore più alto di sessioni al secondo, insieme al livello di concorrenza a cui si verifica. Il throughput ideale aggiunge un criterio sui tempi di risposta: le sessioni più lente, pari al 5% del totale, devono durare non più di 1,5 volte il tempo richiesto da una sessione singola alla concorrenza di base. Il picco mette in evidenza la massima capacità osservata; il secondo criterio considera anche quanto rallentano le sessioni più lente.
Come vengono registrate e riprodotte le sessioni
Per preparare le tracce, un proxy inoltra le richieste dell’agente a un server llama.cpp e registra le richieste e le risposte del modello. Le chiamate agli strumenti e i relativi risultati vengono salvati a parte. Durante la riproduzione, il sistema confronta le richieste con le tracce usando l’etichetta della sessione e un hash; una discrepanza invalida l’esecuzione. Controlla anche le chiamate agli strumenti e restituisce i risultati registrati, così l’attività non devia dalla traccia.
La prova parte da un worker e aumenta il numero fino al massimo dei thread della CPU, ripetendo ogni livello tre volte. I worker entrano in punti diversi di una sequenza di 30 attività, che possono avere durate differenti e sovrapporsi. Il protocollo mira quindi a misurare il completamento di sessioni concorrenti, non la velocità di una singola operazione isolata.
Riproduzione congelata e inferenza dal vivo
Le due modalità descritte da Tom’s Hardware includono componenti diversi. Nella riproduzione congelata, le risposte registrate sostituiscono l’inferenza dal vivo; in una prova separata il modello genera i token previsti, ma il testo prodotto viene scartato e al flusso dell’agente viene restituita la risposta registrata.
| Modalità | Risposte del modello | Inferenza dal vivo | Effetti inclusi |
| Riproduzione congelata | Risposte registrate | Esclusa | Concorrenza degli agenti e lavoro degli strumenti eseguiti; i risultati degli strumenti sono riprodotti dalle tracce |
| Prova con inferenza dal vivo | Il modello genera un numero equivalente di token; la risposta viene scartata e sostituita con quella registrata | Inclusa | Prefill, decodifica, comportamento della cache e accodamento degli agenti |
La riproduzione congelata isola il lavoro della CPU legato agli agenti e agli strumenti dalla generazione dal vivo del modello. La prova separata include invece l’inferenza e l’accodamento, quindi descrive un carico di sistema diverso. Tom’s Hardware osserva che il carico della CPU può variare anche in base alla velocità della GPU, al modello, alla quantizzazione e alle impostazioni del server.
Zen van Riel mostra un’altra modalità di osservazione: usa hook di Claude Code e script Python per seguire l’attività della CPU durante sessioni di agenti. Nel video precisa che si tratta di una dimostrazione, non di un test rigoroso.
Carichi di lavoro e confini dei risultati
Il prototipo usa agenti personalizzati basati su LangGraph e sei profili: analisi, programmazione, documenti, ricerca, assistenza e attività web. Le attività sono attualmente a turno singolo, anche se una singola attività può comprendere più chiamate al modello e agli strumenti. Il profilo di ricerca usa un corpus locale in inglese di Wikipedia, con circa 50.000 articoli; quello di programmazione lavora su quattro piccoli progetti, due in C e due in Python.
Tom’s Hardware descrive due sistemi per il lavoro sul prototipo: un banco con Threadripper a 64 core e 128 GB di RDIMM DDR5-6000, e un NVIDIA DGX Spark con GB10, 128 GB di memoria unificata, GPU Blackwell e CPU Arm Grace. Per la configurazione attuale, la testata riporta un sovraccarico inferiore al 2% per l’isolamento Docker rispetto all’esecuzione bare metal.
Altri numeri sulle CPU per agenti riguardano prove e metriche differenti. In un’analisi commissionata da Arm e pubblicata il 12 ottobre 2026, Signal65 ha riportato una media modellata per rack di 1,99× per Arm AGI CPU rispetto ad AMD EPYC 9755 su sette carichi di lavoro. Il risultato deriva da prestazioni misurate per chip e potenza nominale dei server, non dal conteggio di sessioni al secondo descritto da Tom’s Hardware.
In un post tecnico del 1° giugno 2026, NVIDIA ha dichiarato prestazioni superiori di oltre 1,8× per Vera nei test di sandbox agentica a pieno carico rispetto alle architetture x86 tradizionali. AMD, in un articolo del 9 giugno 2026, ha riportato per EPYC 9965 un risultato modellato pari a 2,37× la media geometrica normalizzata per rack di NVIDIA Vera, usando un rack da 100 kW e carichi infrastrutturali; AMD ha precisato che la propria suite non modella un’intera pipeline end-to-end di agenti. Queste cifre descrivono rispettivamente un confronto modellato per rack, prestazioni di sandbox e carichi infrastrutturali: non sono risultati della prova di Tom’s Hardware, che misura sessioni completate al secondo.
