Google Cloud estende gli strumenti per controllare i costi degli agenti AI e, parallelamente, modifica il modo in cui le risorse infrastrutturali possono essere prenotate, assegnate e riallocate quando i workload cambiano. I due interventi riguardano livelli diversi dello stack, ma affrontano lo stesso problema: gli agenti producono carichi molto meno prevedibili delle applicazioni tradizionali e rendono più difficile dimensionare in anticipo sia la spesa in token sia la capacità di calcolo necessaria.
Sul fronte economico, Google ha annunciato nuove opzioni di fatturazione e controllo dei costi per Gemini Enterprise, insieme all’integrazione dell’utilizzo di Google Antigravity e degli strumenti AI di Android Studio nella stessa gestione delle quote e della spesa. Sul fronte infrastrutturale, una seconda serie di novità riguarda il dynamic capacity management in Compute Engine e Google Kubernetes Engine (GKE), con sistemi per prenotare risorse, utilizzare configurazioni hardware alternative e riallocare automaticamente la capacità disponibile.
È una declinazione del FinOps, la disciplina che applica processi finanziari e operativi alla gestione del cloud, adattata a workload nei quali il consumo può crescere rapidamente in funzione del numero di agenti, della loro autonomia e della quantità di operazioni che eseguono.
Gemini Enterprise combina licenze per utente e consumo effettivo
Il primo cambiamento riguarda il modello economico di Gemini Enterprise. Alla tradizionale licenza mensile per utente, che comprende quote giornaliere condivise all’interno del progetto, Google affianca una nuova edizione pay-as-you-go, inizialmente disponibile per alcuni clienti e destinata a una distribuzione più ampia.
In questo caso non è previsto un impegno iniziale né un canone base: il cliente paga le risorse di calcolo e i token effettivamente consumati, applicando le tariffe standard delle API dei modelli. Il modello è pensato soprattutto per attività agentiche intermittenti, nelle quali il consumo può essere elevato durante l’esecuzione di un progetto e ridursi drasticamente negli altri periodi.
Le due modalità possono convivere. Google introduce infatti quote consolidate a livello di progetto, utilizzabili dalle applicazioni aziendali, dagli strumenti per sviluppatori e dagli agenti personalizzati. Le quote comprese negli abbonamenti vengono consumate per prime; una volta esaurite, l’amministratore può decidere se bloccare l’ulteriore utilizzo oppure consentire che prosegua applicando le tariffe pay-as-you-go.
Questo meccanismo interessa anche Google Antigravity, la piattaforma agentica per lo sviluppo software, il cui accesso viene progressivamente incluso negli abbonamenti Gemini Enterprise per i clienti idonei. La stessa quota può essere utilizzata anche dagli strumenti AI integrati in Android Studio. L’obiettivo operativo è evitare che capacità acquistata e rimasta inutilizzata da un gruppo di utenti non possa essere sfruttata da sviluppatori o agenti che nello stesso momento stanno generando un carico più elevato.
I Flexible Savings Plans riducono del 10 o del 20% il costo dei token
Per i workload più costanti Google introduce anche i Gemini Enterprise Flexible Savings Plans, basati su un impegno di spesa mensile anziché sull’acquisto anticipato di una specifica quantità di risorse.
Il piano prevede uno sconto del 10% sui token con un impegno di un anno e del 20% con un impegno di tre anni. Google non stabilisce un importo minimo o massimo per l’impegno mensile, che può quindi essere definito in funzione del traffico previsto e successivamente adeguato alla crescita dell’utilizzo.
Per le aziende che dispongono già di un Enterprise Agreement con Google Cloud, la spesa del Flexible Savings Plan viene scalata dall’accordo esistente, senza creare un contratto o un budget separato per Gemini Enterprise. I piani sono già disponibili sia per i clienti self-service sia per quelli con accordi enterprise.
Un’altra opzione, prevista prossimamente per alcuni workload, riguarda la deferred execution. Un’attività agentica che non deve essere eseguita immediatamente potrà essere contrassegnata come differibile; lo scheduler di Gemini Enterprise Agent Platform la collocherà quindi nelle finestre nelle quali è disponibile capacità fuori picco.
Google dichiara che questa modalità potrà ridurre fino al 50% il costo dell’inferenza e, poiché utilizza capacità off-peak separata, bypassare completamente i normali limiti di quota. Per workload batch, analisi periodiche o altre attività non sensibili alla latenza, questo permette di aumentare il volume elaborato mantenendo invariato il budget.
I limiti di spesa possono fermare direttamente le chiamate degli agenti
La maggiore elasticità introduce però il rischio opposto: un agente che esegue molte più operazioni del previsto può generare rapidamente consumi elevati. Google aggiunge quindi alla console di fatturazione controlli che agiscono direttamente sui workload AI.
Gli amministratori possono impostare un tetto mensile di spesa per progetto. Quando viene raggiunto, le chiamate API degli agenti vengono temporaneamente sospese, senza interrompere le altre componenti dell’infrastruttura di produzione. Il sistema invia inoltre avvisi automatici al raggiungimento del 50%, dell’80% e del 100% del budget.
Se l’attività deve proseguire, l’amministratore può riabilitarla dalla console oppure consentire preventivamente gli overage, facendo passare automaticamente il consumo eccedente alla tariffazione pay-as-you-go. Se è presente un Flexible Savings Plan, anche questa spesa può essere assorbita dall’impegno già sottoscritto.
Google aggiunge inoltre una funzione di rilevamento anticipato delle anomalie di spesa. Quando il costo di un progetto cresce rispetto al comportamento abituale, il sistema effettua un’analisi della causa e identifica i tre SKU che contribuiscono maggiormente all’aumento, permettendo di capire quali servizi hanno modificato il profilo della spesa.
Il Google Cloud Pricing Calculator viene aggiornato per stimare insieme costi delle licenze per utente, strumenti per sviluppatori e runtime degli agenti. I report centralizzati possono invece essere interrogati attraverso il FinOps agent, che genera in linguaggio naturale sintesi e spiegazioni sull’origine dei costi.
Per i picchi di utilizzo più elevati Google richiama inoltre Provisioned Throughput, il meccanismo con cui la capacità dei modelli Gemini può scalare senza ricorrere a infrastruttura dedicata lasciata inutilizzata nei periodi di bassa domanda. Google indica una capacità di elaborazione fino a 50 milioni di token al minuto, pensata per workload che devono sostenere volumi molto elevati senza incontrare limiti artificiali di throughput.
Per gli agenti serve un’infrastruttura meno rigida
La pressione sui costi non riguarda soltanto i token. Secondo i dati citati da Google, il 90% delle imprese prevede di distribuire agenti AI entro i prossimi tre anni, ma soltanto il 17% dei responsabili IT ritiene che l’infrastruttura attuale sia in grado di sostenerne il carico.
La difficoltà deriva anche dalla natura di questi workload. Gli agenti possono produrre carichi brevi e molto intensi, accedere contemporaneamente a database e applicazioni aziendali oppure richiedere acceleratori specializzati solo durante alcune fasi dell’elaborazione. A differenza degli utenti umani, possono inoltre generare accessi e operazioni a un volume molto superiore, facendo crescere rapidamente la pressione sui sistemi con cui interagiscono.
Per questo Google affianca ai tradizionali modelli On-Demand, Spot e Committed Use Discount (CUD) una strategia di dynamic capacity management che distingue innanzitutto fra capacità prevedibile e domanda inattesa. L’hardware specializzato – GPU, TPU e processori come Google Axion – rimane una componente fondamentale, ma la strategia proposta da Google riguarda soprattutto il modo in cui queste risorse vengono prenotate, sostituite e riallocate.
La capacità può essere prenotata quando il carico è prevedibile
Con Dynamic Workload Scheduler le risorse possono essere richieste in due modalità. Flex-start è destinato ai workload che tollerano un’attesa, come elaborazioni batch, training e fine-tuning offline: viene specificata la durata richiesta e il job rimane in coda fino a quando diventano disponibili GPU, TPU o altre risorse compatibili.
Calendar mode permette invece di indicare in anticipo data di inizio e fine di un evento. La capacità viene prenotata per quella finestra temporale e diventa quindi garantita per la durata specificata, una caratteristica utile per migrazioni programmate, lanci di prodotti, training pianificati o picchi stagionali.
Le due modalità permettono quindi di separare i workload che richiedono capacità in un momento preciso da quelli che possono essere spostati nel tempo per ottenere maggiore disponibilità e costi inferiori.
Compute Engine può passare automaticamente a un hardware alternativo
Per la domanda non prevedibile Google propone un’altra strategia: evitare che un’applicazione dipenda da una sola configurazione hardware.
Nei managed instance group (MIG) di Compute Engine, la funzione di instance flexibility permette di specificare più tipi di macchina compatibili. Se la configurazione preferita non è disponibile, il sistema può scegliere automaticamente un’alternativa in funzione della capacità presente in quel momento.
La ricerca può essere estesa a più zone della stessa regione. In presenza di Spot VM, Compute Engine utilizza inoltre i segnali relativi alla capacità Spot per privilegiare le configurazioni che presentano una maggiore durata stimata e una minore probabilità di preemption, cioè di revoca della macchina da parte della piattaforma.
Questo meccanismo consente anche una migrazione progressiva verso nuove generazioni di VM: le configurazioni più recenti possono diventare la scelta prioritaria, mentre quelle precedenti rimangono disponibili come fallback automatico.
La stessa logica può comprendere lo storage: è possibile definire impostazioni di base e override dei dischi affinché la configurazione rimanga compatibile quando il workload viene spostato su un diverso tipo di VM. Per i dati che devono sopravvivere alla macchina virtuale Google indica, tra le opzioni, l’utilizzo di Hyperdisk, separando così la vita del volume da quella della singola istanza.
GKE automatizza fallback, migrazioni e assegnazione delle risorse
Con Google Kubernetes Engine il meccanismo viene gestito a livello del control plane Kubernetes. Le Custom ComputeClasses permettono ai team di piattaforma di definire una sequenza prioritaria di famiglie di VM, dimensioni, rapporti fra CPU e memoria, zone e modalità On-Demand o Spot.
Quando il nodo preferito non è disponibile, GKE può passare alla successiva configurazione ammessa. Con l’active migration, quando torna disponibile una risorsa con priorità maggiore il workload può essere trasferito nuovamente sulla configurazione preferita.
Google descrive GKE anche come ambiente adatto all’esecuzione degli agenti in container e sandbox isolate, facendo gestire allo stesso control plane sia la disponibilità delle risorse sia il loro riallocamento quando i workload cambiano.
A questo si aggiunge la Dynamic Resource Allocation, che consente di descrivere con maggiore granularità le caratteristiche dell’acceleratore richiesto dal workload. Invece di trattare necessariamente GPU o TPU come risorse indivisibili, le applicazioni possono specificare parametri quali memoria e numero di core, permettendo alla piattaforma di assegnare soltanto la porzione di hardware necessaria e aumentare il livello di utilizzo delle risorse disponibili.
Google suggerisce inoltre di usare Dynamic Workload Scheduler come destinazione della capacità e le Custom ComputeClasses come livello di policy e priorità, costruendo così una catena automatica che va dalla richiesta delle risorse alla scelta dell’hardware alternativo e alla successiva migrazione.
Per i workload più stabili rimangono disponibili i Compute Flexible Committed Use Discounts, con i quali Google indica riduzioni di prezzo fino al 63% in cambio di un impegno minimo di spesa, senza vincolare lo sconto a una specifica macchina o località.
