Le richieste di CPU per l'AI agentica di Google mettono sotto esame il calcolo inutilizzato

Google afferma che gli agenti AI creeranno nuove richieste di CPU, anche se i loro ambienti di esecuzione trascorrono lunghi periodi in attesa. Le richieste di CPU per l'AI agentica di Google comportano quindi un problema più complesso della semplice aggiunta di processori: mantenere disponibili lavoratori software persistenti senza riservare hardware inattivo. Le CPU, processori generici che eseguono codice applicativo, diventano centrali quando gli agenti vanno oltre la generazione di risposte e iniziano a operare sul software.

In un'intervista a EE Times del 30 ottobre, il dirigente di Google Cloud Mark Lohmeyer ha descritto agenti che chiamano servizi, navigano siti web ed eseguono codice. Queste attività ampliano il lavoro computazionale attorno al modello. Le GPU, processori ottimizzati per calcoli paralleli, e le TPU di Google, chip specializzati per il machine learning, gestiscono ancora gran parte del calcolo del modello. L'applicazione circostante necessita della propria capacità di esecuzione.

Questo mette sotto pressione le piattaforme cloud e i team infrastrutturali aziendali. Un sistema progettato attorno alla velocità di serving del modello può comunque deludere quando gli agenti attendono gli spazi di lavoro, perdono lo stato della sessione o riservano risorse inutilmente. AWS sta perseguendo servizi di esecuzione simili, offrendo agli acquirenti un riferimento competitivo. La competizione centrale è tra ambienti riservati in modo continuo e infrastrutture che preservano il lavoro di un agente rilasciando il calcolo inattivo.

Le richieste di CPU per l'AI agentica di Google vanno oltre il serving del modello

L'argomentazione di Google riguarda l'infrastruttura attorno a un modello AI, anziché una sostituzione dei processori AI specializzati.

Lohmeyer, vicepresidente e direttore generale di Google per l'AI e l'infrastruttura di calcolo, ha descritto questa distinzione nella discussione sui carichi di lavoro degli agenti. Secondo EE Times, gli agenti trasformano la richiesta di un utente in sottoattività che coinvolgono l'esecuzione di software ordinario. Il carico di lavoro risultante è intermittente e crea requisiti diversi per processori, archiviazione e gestione delle risorse.

L'importanza risiede in ciò che avviene dopo che un modello seleziona un'azione. Produrre un'istruzione plausibile e completare l'attività indicata consumano risorse diverse. Un browser deve caricare una pagina, un programma deve essere eseguito e un'applicazione deve restituire un risultato. Aggiungere intelligenza alla decisione non elimina queste operazioni.

Un agente, ovvero software che utilizza un modello per selezionare ed eseguire azioni verso un obiettivo, collega queste fasi. La sua utilità dipende dall'intera sequenza. Una risposta rapida del modello offre un beneficio limitato se il successivo ambiente di esecuzione impiega troppo tempo per diventare utilizzabile.

Questo aiuta a spiegare perché i requisiti delle CPU meritino attenzione accanto alla capacità di serving del modello. Il serving del modello significa eseguire un modello addestrato per produrre output. L'esecuzione complessiva di un agente include tale operazione, ma anche il codice e i servizi che lo circondano. Misurare solo il modello lascia una parte dell'applicazione fuori dal quadro delle prestazioni.

L'intervista non stabilisce nemmeno un vincitore universale tra i processori. Lohmeyer ha descritto l'uso da parte di Google Cloud di processori Intel e AMD insieme ai propri chip Axion basati su Arm. Arm e x86 sono famiglie di set di istruzioni per processori, che determinano le istruzioni macchina eseguite dal software. Carichi di lavoro degli agenti diversi possono favorire combinazioni differenti di prestazioni dei core, numero di core e archiviazione collegata.

Questa distinzione è importante per interpretare il titolo. Una maggiore attività degli agenti non significa automaticamente che ogni categoria di CPU ne tragga uguale vantaggio. Un carico di lavoro dominato dall'esecuzione di programmi differisce da uno dominato dall'attesa di servizi esterni. Gli acquirenti devono ancora comprendere il lavoro che effettivamente eseguono.

L'infrastruttura degli agenti Google rende ora questa argomentazione più concreta. Il 22 ottobre, Google ha presentato Agent Compute Engine, descrivendo un servizio che supporta già le attività di Gemini. Il suo annuncio indicava la disponibilità in anteprima per i clienti nei mesi successivi. Al 1° novembre, questa formulazione non dovrebbe essere interpretata come disponibilità generale.

La sequenza dà all'intervista un contesto specifico. Google sta spiegando un problema di esecuzione mentre prepara un servizio commerciale destinato ad affrontarlo. Ciò rende rilevante la sua descrizione tecnica, offrendo al contempo ai lettori un motivo per distinguere tra architettura documentata e benefici attesi per i clienti.

I team infrastrutturali ereditano il costo dell'attesa

La pressione immediata ricade sui team responsabili di mantenere pronti gli ambienti degli agenti tra un picco e l'altro di lavoro utile.

Un ambiente persistente conserva il materiale di lavoro tra le interazioni. Questo può includere file, software installato e stato dell'applicazione. La persistenza rende un agente utile lungo un'attività estesa, ma complica la gestione delle risorse. Mantenere disponibili le informazioni e mantenere assegnato un processore sono requisiti distinti.

Si consideri un assistente di programmazione che lavora a una modifica di un repository. Legge file, esegue un programma, attende l'output del modello e chiede l'approvazione di uno sviluppatore. Lo spazio di lavoro resta rilevante durante tutte queste pause. Il processore non deve necessariamente rimanere riservato per lo stesso periodo.

Questo è un carico di lavoro illustrativo, non un deployment cliente misurato. Mostra perché il tempo di sessione trascorso possa rappresentare in modo errato la domanda effettiva di esecuzione. Una sessione può restare preziosa pur essendo inattiva. Trattare ogni sessione aperta come continuamente occupata oscura questa distinzione.

La conseguenza raggiunge il modello di business dell'applicazione. Un acquirente che acquista un'esperienza basata su agenti desidera lavoro completato e continuità affidabile. Il fornitore dell'infrastruttura deve garantire questi risultati decidendo quanta parte dell'hardware riservare. Una cattiva allocazione può aumentare le spese operative senza migliorare il risultato dell'utente.

L'utilizzo della CPU degli agenti, ossia la quota della capacità di processore disponibile impiegata nell'esecuzione del lavoro, diventa rilevante in questo contesto. Tuttavia, un valore medio di utilizzo non descrive l'intera esperienza. Una piattaforma può mostrare un utilizzo medio basso e avere comunque difficoltà quando molti agenti in attesa diventano attivi contemporaneamente.

Questo crea requisiti operativi in competizione. I fornitori vogliono condividere la capacità in modo efficiente, mentre gli utenti si aspettano accesso immediato quando il lavoro riprende. La concentrazione degli ambienti aiuta solo se il sistema può gestire la ripresa dell'attività. I ritardi durante i periodi intensi possono annullare il vantaggio di mantenere disponibili le sessioni.

La descrizione di Google del 15 settembre di Agent Substrate affronta esplicitamente gli ambienti di esecuzione inattivi e i picchi di attività. L'azienda descrive software che separa l'esecuzione degli agenti dalla gestione delle macchine sottostanti. Offre inoltre diversi approcci di isolamento, riflettendo il fatto che i carichi di lavoro non condividono requisiti di sicurezza identici.

La pressione si estende agli acquisti aziendali. Le discussioni sulla capacità devono ora includere il modo in cui un agente si mette in pausa, conserva il lavoro e riprende. La sola specifica di un processore non può rispondere a queste domande. Il comportamento del servizio tra i picchi di esecuzione diventa parte del prodotto acquistato.

Questo modifica anche la responsabilità interna. Un team applicativo può scegliere un framework per agenti mentre un team di piattaforma ne gestisce il runtime, l'ambiente che esegue il software. Se nessuno dei due team misura l'allocazione delle risorse inattive, il consumo non necessario può ricadere tra le rispettive responsabilità. Il problema risultante appare nella fattura dell'infrastruttura anziché nella valutazione del modello.

Per gli sviluppatori, l'implicazione pratica è architetturale. Esperienze utente di lunga durata non dovrebbero richiedere automaticamente prenotazioni di processore altrettanto durature. La capacità di una piattaforma di separare questi cicli di vita determina con quale facilità un prototipo utile possa espandersi in un servizio.

Gli spazi di lavoro persistenti mettono in discussione il calcolo riservato in modo continuo

La domanda progettuale centrale è se un agente possa mantenere il proprio ambiente di lavoro rinunciando all'hardware di cui temporaneamente non ha bisogno.

Anche le applicazioni tradizionali gestiscono già periodi di inattività, quindi il problema sottostante ha dei precedenti. I carichi di lavoro degli agenti lo rendono più acuto combinando codice potenzialmente non attendibile con spazi di lavoro personalizzati e continuativi. L'ambiente deve restare utile attraverso le interruzioni senza diventare un'allocazione permanente non necessaria.

Una microVM è una macchina virtuale essenziale che usa la virtualizzazione hardware per isolare il proprio ambiente di esecuzione. Una sandbox è un ambiente ristretto pensato per contenere il codice e limitarne l'accesso. Questi concetti si sovrappongono nelle piattaforme per agenti, ma descrivono aspetti diversi: un meccanismo di implementazione e una finalità di sicurezza.

Il meccanismo non risolve da solo l'economia del sistema. Una piccola macchina isolata può comunque riservare risorse senza fare nulla. L'efficienza dipende da come il servizio gestisce l'intero ciclo di vita. Avviare, mettere in pausa, preservare, ripristinare ed eliminare un ambiente diventano tutte operazioni rilevanti.

Uno snapshot, ovvero una rappresentazione salvata dello stato di esecuzione, offre un modo per preservare la continuità. Ripristinare tale stato può evitare di ricostruire un ambiente dall'inizio. Tuttavia, anche il salvataggio e il ripristino coinvolgono archiviazione e spostamento dei dati. Spostare un carico di lavoro fuori dalla memoria attiva trasferisce i requisiti altrove.

Questo rende la pianificazione delle CPU inseparabile dalla pianificazione dello storage. Rilasciare processori aiuta meno quando il ripristino di un ambiente crea un lungo ritardo. Allo stesso modo, conservare tutto indefinitamente può creare un obbligo di archiviazione crescente. Un progetto completo necessita di politiche per lo stato conservato oltre che per l'esecuzione attiva.

La descrizione tecnica di Google degli ambienti persistenti per agenti illustra il checkpointing delle sessioni inattive preservando file e memoria. Il checkpointing consiste nel salvare uno stato di esecuzione recuperabile. Google descrive inoltre la conservazione delle credenziali di lunga durata al di fuori degli ambienti guest e l'instradamento delle richieste tramite gateway controllati. Si tratta di descrizioni aziendali del proprio design, non di risultati indipendenti sulla sicurezza.

Il punto analitico più ampio è che la continuità diventa una proprietà dei sistemi. Gli utenti vivono un agente come un'attività continuativa, mentre l'infrastruttura può attraversare diversi stati di risorse sottostanti. Un'implementazione riuscita nasconde queste transizioni senza perdere lavoro né indebolire i controlli di accesso.

AWS offre un confronto utile attraverso l'introduzione del 22 giugno di Lambda MicroVMs. AWS descrive ambienti isolati per codice scritto dagli utenti o generato dall'AI, con controllo diretto del ciclo di vita e stato preservato. La sua implementazione si basa su Firecracker, la tecnologia di virtualizzazione leggera dell'azienda.

Questo confronto supporta l'esistenza di un problema infrastrutturale condiviso. Non dimostra che i servizi di Google e AWS offrano le stesse prestazioni, supportino carichi di lavoro identici o impongano vincoli operativi equivalenti. Le loro descrizioni pubblicate forniscono un punto di partenza per la valutazione, piuttosto che un confronto completato.

L’infrastruttura per agenti di Google si inserisce quindi in una transizione più ampia verso la gestione degli ambienti di esecuzione come parte dell’applicazione agentica. La concorrenza rilevante non riguarda semplicemente quale fornitore offre più core di processore. Riguarda quale servizio conserva il lavoro utile, gestisce la ripresa dell’attività e rende comprensibile il consumo delle risorse.

Per gli acquirenti, questa distinzione modifica la domanda di valutazione. Chiedere con quale rapidità si avvia un ambiente vuoto non è sufficiente. La domanda più rivelatrice riguarda un workspace reale, con dipendenze e lavoro conservato, che torna operativo dopo un’interruzione.

Una maggiore densità di agenti non definisce una previsione della domanda di CPU

Una spiegazione credibile dell’aumento del lavoro sulle CPU è diversa dall’evidenza che mostra quanto hardware aggiuntivo richiederà il mercato.

Le esigenze di CPU dell’AI agentica di Google includono forze contrapposte. Più attività degli agenti creano ulteriore lavoro di esecuzione. Una migliore condivisione delle risorse riduce l’hardware necessario per supportare una determinata popolazione di agenti. Il risultato netto dipende dall’adozione, dall’intensità dei carichi di lavoro e dall’efficacia dei miglioramenti infrastrutturali.

Il materiale tecnico di Google illustra perché questa distinzione sia importante. In un benchmark sulla densità degli agenti del 30 luglio, l’azienda ha testato un carico di lavoro OpenClaw su una configurazione di macchina fissa. Ha riferito di supportare più agenti attraverso modifiche alla gestione dell’esecuzione e delle risorse. Questi risultati riguardano un carico di lavoro e una configurazione specifici.

Non dovrebbero trasformarsi in un moltiplicatore universale per le implementazioni in produzione. Agenti diversi mantengono quantità diverse di memoria, eseguono software differenti e trascorrono periodi diversi in attesa. Anche le configurazioni di sicurezza influenzano le risorse disponibili per le applicazioni. Un risultato sulla densità necessita delle sue condizioni di contesto per mantenere significato.

La stessa cautela vale nella direzione opposta. Una previsione di espansione del lavoro sulle CPU non dimostra che i processori diventino la risorsa limitante per ogni agente. Alcune applicazioni trascorreranno più tempo in attesa delle risposte del modello. Altre incontreranno restrizioni dei servizi esterni o ritardi di archiviazione.

L’utilizzo della CPU da parte degli agenti è quindi utile nell’ambito di un insieme più ampio di misurazioni. Un valore elevato può indicare un’esecuzione produttiva, ma può anche accompagnarsi a contesa delle risorse e attività ritardate. Un valore basso può indicare sprechi, ma può anche riflettere una capacità di riserva intenzionale. L’interpretazione richiede dati sulle prestazioni e sull’affidabilità dell’applicazione.

Anche l’unità commerciale conta. Contare gli agenti avviati può favorire un servizio che completa poco lavoro utile. Contare le sessioni attive può nascondere fallimenti ripetuti o attività abbandonate. Gli esiti completati e accettati offrono una base più rigorosa per valutare se i miglioramenti infrastrutturali apportino benefici ai clienti.

C’è un’altra incertezza attorno alla parola “agente”. Una breve richiesta di esecuzione del codice e un workspace browser persistente possono entrambi ricevere questa etichetta. Le loro esigenze di processore e persistenza differiscono. Aggregarli in una categoria di domanda indifferenziata nasconde la composizione dei carichi di lavoro che determina le effettive necessità di risorse.

Per questo la narrazione sulle CPU dovrebbe evitare di dichiarare vincitrice un’architettura. I design di Intel, AMD e basati su Arm competono all’interno di configurazioni di servizio più ampie. Compatibilità software, capacità di memoria e accesso allo storage possono influenzare il risultato insieme alla velocità di esecuzione del processore. Un confronto a livello applicativo deve mantenere coerenti i propri criteri di successo.

La conclusione più solida supportata dalle evidenze è più circoscritta di una previsione di mercato. Google ha identificato il normale lavoro di esecuzione come componente importante dei servizi per agenti. La sua direzione di prodotto affronta il divario tra sessioni persistenti e attività intermittente. L’entità della domanda hardware risultante resta una questione empirica.

Questo lascia spazio sia a una maggiore adozione sia a una migliore efficienza. Se gli agenti diventano utili in più flussi di lavoro, l’esecuzione totale può crescere nonostante una migliore condivisione delle risorse. Se l’adozione delude, la sola infrastruttura migliorata non genererà domanda sostenuta. Il meccanismo tecnico spiega un’opportunità senza determinarne la dimensione finale.

L’isolamento deve resistere alla spinta verso una migliore utilizzazione

Recuperare risorse inattive crea valore soltanto quando la piattaforma conserva i confini di sicurezza e lo stato di lavoro di cui i clienti hanno bisogno.

Gli agenti possono eseguire codice influenzato dall’output del modello e da informazioni esterne. Ciò crea una relazione di fiducia diversa rispetto all’esecuzione di software scritto e revisionato esclusivamente dagli sviluppatori di un’applicazione. Il runtime deve tenere conto di azioni che il suo operatore non ha esplicitamente creato.

L’isolamento limita ciò che un ambiente di esecuzione può raggiungere. L’autorizzazione determina quali azioni un’identità è autorizzata a compiere. Questi controlli risolvono problemi correlati ma distinti. Un ambiente isolato può comunque usare impropriamente l’accesso che un sistema gli concede legittimamente.

Questa distinzione evita un comune errore di categoria. Un confine di esecuzione sicuro non dimostra che un agente comprenda correttamente una richiesta. Non dimostra nemmeno che ogni azione consentita serva l’intento dell’utente. I controlli infrastrutturali contengono l’esecuzione, mentre i controlli applicativi governano l’attività.

La discussione sull’efficienza deve preservare entrambi i livelli. Consolidare più lavoro su hardware condiviso aumenta l’importanza di una separazione affidabile. Conservare le sessioni solleva interrogativi sui dati trattenuti e sulla scadenza degli accessi. La ripresa di un workspace non dovrebbe ripristinare silenziosamente permessi che non sono più appropriati.

Si consideri un agente di ricerca aziendale che legge documenti interni e prepara un briefing. L’agente ha bisogno di sufficiente continuità per conservare i propri progressi. Il suo accesso deve comunque riflettere le autorizzazioni correnti dell’utente. Un workspace salvato e una decisione di autorizzazione non dovrebbero essere trattati come registrazioni intercambiabili.

Questo esempio collega inoltre la progettazione dell’infrastruttura alla qualità delle informazioni. Conservare un processo è utile soltanto quando il sistema mantiene le fonti e il materiale di lavoro corretti. I team che realizzano una base di conoscenza ricercabile affrontano una sfida organizzativa correlata: mantenere le evidenze tecniche recuperabili nel corso del lavoro continuo. Questa esigenza integra la persistenza del runtime senza sostituirla.

La resilienza operativa merita uguale attenzione. Un ambiente che riprende correttamente in condizioni normali potrebbe comportarsi diversamente dopo una scrittura interrotta o una connessione non riuscita. Gli acquirenti devono comprendere cosa sopravvive a una pausa e cosa l’applicazione deve ricreare. In caso contrario, la continuità apparente può nascondere un ripristino incompleto.

Lo stesso principio si applica alla pulizia. Un agente che smette di lavorare dovrebbe infine rilasciare risorse secondo una politica di conservazione esplicita. Conservare tutto indefinitamente crea obblighi non necessari. Eliminare in modo troppo aggressivo compromette l’esperienza continua che l’infrastruttura è stata progettata per supportare.

Questi sono motivi per esaminare attentamente le affermazioni di Google, senza liquidare il progetto sottostante. La documentazione aziendale spiega i confini e i comportamenti previsti. Test indipendenti ed esperienza operativa stabiliscono come tali funzionalità si comportino nelle effettive condizioni applicative. Nessuno dei due dovrebbe sostituirsi all’altro.

L’implicazione per l’acquisto è concreta. Valutate insieme isolamento, continuità ed efficienza delle risorse. Un servizio che ottimizza una dimensione lasciando poco chiare le altre non risolve il problema infrastrutturale completo. L’esito rilevante è lavoro utile fornito entro un modello di sicurezza e operativo accettabile.

Le prossime evidenze dovrebbero provenire da accesso, carichi di lavoro e risultati

La prossima fase di questa storia dipende dal comportamento di esecuzione visibile ai clienti, piuttosto che da ulteriori affermazioni secondo cui gli agenti necessitano di CPU.

Il primo segnale è l’accesso pratico ad Agent Compute Engine. L’annuncio di Google di ottobre indica una disponibilità in anteprima nei prossimi mesi. Nei prossimi mesi, le condizioni di accesso pubblicate, le configurazioni supportate e i limiti operativi mostreranno come i clienti possano valutare quell’architettura.

Un’anteprima rafforzerebbe la narrazione spostando la discussione verso un comportamento del servizio osservabile. Un accesso limitato fornirebbe comunque evidenze utili, ma limiterebbe i confronti. La documentazione dovrebbe rendere chiari questi confini anziché lasciare che i lettori li deducano dalle descrizioni dell’uso interno di Google.

Il secondo segnale è il test di carichi di lavoro rappresentativi. Confronti utili dovrebbero includere esecuzione attiva, attesa, interruzione e ripristino all’interno della stessa attività. Un ambiente che si avvia rapidamente ma riprende male non offre una continuità coerente. Allo stesso modo, uno stato inattivo efficiente conta meno se transizioni ripetute interrompono il lavoro.

Tali test dovrebbero rendere noti il carico di lavoro e le condizioni che lo circondano. Requisiti di memoria, file conservati, concorrenza e impostazioni di isolamento influenzano tutti l’interpretazione. I confronti diventano più informativi quando includono AWS o altri servizi di esecuzione rilevanti con requisiti applicativi equivalenti.

Queste evidenze rafforzerebbero l’argomentazione di Google se una migliore gestione delle risorse preservasse tassi di completamento e reattività. Indebolirebbero il caso commerciale se i risparmi richiedessero ritardi inaccettabili o una compatibilità applicativa più limitata. Entrambi gli esiti fornirebbero più informazioni di un benchmark isolato del processore.

Il terzo segnale è la rendicontazione dei clienti sul lavoro completato. Le implementazioni aziendali possono rivelare se l’infrastruttura di esecuzione resti un vincolo sostanziale dopo la selezione del modello. Possono inoltre mostrare se gli ambienti persistenti migliorino abbastanza il completamento delle attività da giustificare la loro complessità operativa.

Tali report dovrebbero distinguere i problemi del modello dai problemi del runtime. Un agente che sceglie l’azione sbagliata presenta un fallimento diverso da un ambiente che non riesce a riprendere. Combinarli in un unico dato di successo rende difficile valutare l’infrastruttura. Separarli aiuta gli acquirenti a capire quali miglioramenti contano.

Le esigenze di CPU dell’AI agentica di Google diventeranno più facili da valutare quando questi segnali emergeranno insieme. L’accesso al servizio stabilisce cosa i clienti possono usare. I test rappresentativi stabiliscono come si comporta l’esecuzione. I risultati dei clienti stabiliscono se il sistema risultante produca abbastanza valore da supportare un’implementazione continua.

Per ora, la documentazione supporta un chiaro cambiamento di enfasi. Le applicazioni agentiche richiedono attenzione all’esecuzione software che circonda un modello, compresi i periodi in cui tale esecuzione si interrompe. Le CPU rimangono essenziali per quel lavoro, mentre persistenza e gestione delle risorse determinano con quale efficienza le piattaforme le forniscono.

Partite da un flusso di lavoro che la vostra organizzazione desidera effettivamente affidare a un agente. Identificate quali fasi eseguono codice, quali attendono e quali richiedono file o autorizzazioni conservati. Chiedete ai potenziali fornitori di dimostrare tali transizioni usando la stessa attività e gli stessi criteri di accettazione. Mantenete la valutazione concentrata sul lavoro completato, sullo stato recuperabile e su un consumo delle risorse comprensibile. Questo approccio offre a sviluppatori e acquirenti un modo pratico per valutare l’argomentazione di Google man mano che i nuovi servizi diventano accessibili. La decisione riguarda meno l’accettazione di un’ampia previsione della domanda di CPU che lo stabilire se una piattaforma supporti economicamente un’esperienza agentica continua. Cosa succede al computer del vostro agente quando l’agente non ha nulla da fare?