Quanto "pensa" davvero la traduzione AI?

Gemini non smette mai di stupire. È il miglior LLM per la traduzione pronto all'uso per la maggior parte delle lingue. Grazie alle sue capacità di ragionamento, è possibile risolvere anche le sfide più ostiche, come i modi di dire, i riferimenti agli anime o la propria brand voice™.

Il problema è che il ragionamento richiede tempo. E il ragionamento costa: ogni singolo token viene fatturato. Come sviluppatore, l'obiettivo è avere il controllo su entrambi.

Gemini 2.5 aveva vita facile. Gemini 3 ha complicato le cose.

Ecco cosa abbiamo scoperto nei laboratori di Transept

Cosa è cambiato in Gemini 3

Gemini 2.5 disponeva di thinkingBudget: un tetto numerico ai token di ragionamento. Gemini 3 lo ha rimosso. Il suo sostituto è thinkingLevel: un'impostazione categorica con quattro valori — minimal, low, medium, high. I due parametri si escludono a vicenda; l'invio di entrambi a un modello Gemini 3 restituisce un errore 400 sugli SDK attuali.

Questo cambia il significato pratico di "controllo dei costi". In precedenza, si poteva impostare un limite massimo alla spesa. Ora, spetta al modello decidere quanto consumare in base a ciò che ritiene essere il livello 'medium'.

Presumiamo che il motivo sia che i modelli vengono post-addestrati per adattare la lunghezza del ragionamento alla difficoltà del compito, proprio come fanno gli esseri umani. Di conseguenza, l'impostazione di limiti arbitrari comprometterebbe questa capacità.

Ma quanti token consumano effettivamente i livelli low, medium e high?

I dati

Ecco un campione di due settimane del nostro traffico di traduzione reale, circa 1.000 chiamate distribuite su tre modelli Gemini 3. I dati sui token di ragionamento provengono da usageMetadata.thoughtsTokenCount in ogni risposta, la fonte più accurata possibile.

Token di ragionamento per modello

Quel 15.725 non è un errore di battitura. Una singola chiamata di traduzione, con un modello Flash e impostazione media, ha consumato quindicimila token di ragionamento.

Di solito, simili eccessi di token sono causati dal fatto che Gemini lascia trapelare i suoi token di pensiero grezzi nell'output. Come forse saprete, il "pensiero" del modello non è ciò che pensa davvero, ma piuttosto una sintesi rielaborata; il vero ragionamento dell'LLM somiglia più a un flusso di coscienza.

Vale la pena notare, però, che in questo caso specifico Gemini ha rimuginato tranquillamente sulla traduzione inglese-ucraino di un brano letterario con una frase come "l'acciaio puro respinge lacche e vernici". Stava procedendo per tentativi, "leggendo a voce alta" circa dodici opzioni finché non è rimasto soddisfatto del risultato.

Qualche settimana dopo, un aggiornamento. Quel 15,725 non era un atto di devozione isolato di Gemini, ma un comportamento ricorrente specifico dei compiti complessi.

Con l'aumento del traffico, specialmente su gemini-3.1-flash-lite, lo stesso numero continua a ripresentarsi. Un intervallo sospettosamente ristretto tra 15,724 e 15,729, riscontrato in decine di chiamate, quasi tutte di modelli Lite che macinano revisioni di glossari. È interessante notare che girano con l'impostazione di basso sforzo di pensiero (low), che non ci si aspetterebbe essere la più costosa.

Un modello che si attesta sullo stesso numero per undici volte ha raggiunto un limite massimo, non ha semplicemente scelto una formulazione. L'impostazione low thinking satura intorno ai 15.700 token. Poiché i modelli piccoli come i lite pensano in modo meno efficace, i compiti difficili li spingono a bruciare una gran quantità di token; questo non accade mai con i modelli più grandi, dove ogni token ha maggiori probabilità di rappresentare un passo significativo verso la risposta.

La saturazione ha inoltre un costo. Su Gemini 3, i token di pensiero vengono conteggiati nei maxOutputTokens. Una chiamata che ne consuma 15.700 per pensare non lascia quasi nulla per la risposta; tuttavia, tutto il pensiero viene fatturato nella fascia di output. Con un budget di 16.000 token, l'audit risultava vuoto (finishReason=MAX_TOKENS) circa la metà delle volte sui documenti piccoli, il che ci ha spinto a indagare.

Aumentare il budget cura il sintomo, non la causa. Abbiamo portato il budget per l'audit a 32.000 su low, il che lascia circa 16.000 token per l'output dopo una fase di pensiero giunta a saturazione — le risposte vuote sono cessate. Ma il pensiero non si è ridotto. Su Gemini 3 non è possibile porvi un limite, quindi continua a bruciarne circa 15.700; il budget più ampio serve solo a dare alla risposta lo spazio necessario per essere generata.

L'unica vera soluzione al thinkingmaxxing a 16k è stata ridurre la portata del compito.

minimal è l'unico livello che si comporta come un vero limite, con un tetto di circa 2.000 token. È disponibile però solo per i modelli Lite.

Token di pensiero per tipo di attività (Flash vs Pro, entrambi su medium)

Nelle traduzioni semplici, Pro ragiona meno di Flash, quasi la metà. Lo supera solo nei compiti di riscrittura. L'impegno nel ragionamento segue la difficoltà del compito, non la fascia commerciale del modello.

Si può sostenere che Pro ottenga risultati migliori nei benchmark di traduzione proprio grazie alla sua capacità di riflettere più a fondo quando necessario.

Consigli pratici

• Non impostare thinkingBudget su un modello Gemini 3. Verrà ignorato o restituirà un errore.
• medium non ha un limite superiore prefissato. Una stima realistica è di circa 4.000 token di ragionamento (p90) per chiamata, non 2.000.
• Se hai bisogno di un limite di spesa rigoroso, usa minimal dove possibile. Non ha senso interrompere l'output: l'addebito avverrà comunque.
• Leggi usageMetadata.thoughtsTokenCount in ogni risposta se calcoli i costi per chiamata. Il valore non è presente nel corpo della risposta, ma compare in fattura.
• Con l'impostazione medium, Pro tende a ragionare meno della sua mediana sui compiti semplici e di più su quelli complessi. Lite e Flash non mostrano questa variabilità.

Questo rende Pro il modello ideale per la revisione e il perfezionamento che vanno oltre lo standard dei LLM, poiché è proprio in queste fasi che emerge la sua creatività. Per le traduzioni grezze, invece, Flash è più indicato.

Tutto questo ha però un costo, sia in termini di tempo che di risorse. In Transept, siamo riusciti a contenere i costi di Pro adottando una logica di revisione intelligente che lo attiva solo per i passaggi più complessi. Utilizziamo Pro anche per la pianificazione e il processo decisionale, delegando l'esecuzione a modelli più piccoli o ottimizzati.

In questo modo, tutto funziona a dovere.