Quanto a tradução por IA realmente pensa?

O Gemini é uma ferramenta que não para de surpreender. É o melhor LLM para tradução pronto para o uso na maioria dos idiomas. Com sua capacidade de raciocínio, você consegue decifrar até os problemas mais complexos, como expressões idiomáticas, referências de anime ou o tom de voz exclusivo da sua marca™.

O problema é que raciocinar leva tempo. Raciocinar custa dinheiro; cada token é cobrado. Como desenvolvedor, você quer ter controle sobre as duas coisas.

Com o Gemini 2.5, era fácil. O Gemini 3 complicou as coisas.

Eis o que descobrimos nos laboratórios da Transept

O que mudou no Gemini 3

O Gemini 2.5 usava o thinkingBudget: um limite numérico para os tokens de raciocínio. O Gemini 3 abandonou esse recurso. O substituto é o thinkingLevel: uma configuração categórica com quatro níveis — minimal, low, medium e high. Os dois parâmetros são mutuamente exclusivos; enviar ambos para um modelo Gemini 3 gera um erro 400 nos SDKs atuais.

Isso muda o que "controle de custos" significa na prática. Antes, era possível definir um teto rígido para os gastos. Agora, cabe ao modelo decidir o quanto consumir com base no que ele entende pelo nível 'medium'.

Acreditamos que o motivo seja o pós-treinamento dos modelos para adaptar a duração do raciocínio à complexidade da tarefa, assim como nós, humanos, fazemos. Por isso, impor limites arbitrários acabaria prejudicando essa capacidade.

Mas quantos tokens os níveis low, medium e high consomem na prática?

Os dados

Apresentamos uma amostra de duas semanas do nosso tráfego real de tradução, totalizando cerca de 1.000 chamadas em três modelos Gemini 3. Os dados dos tokens de raciocínio vêm do usageMetadata.thoughtsTokenCount em cada resposta, a fonte mais precisa possível.

Tokens de raciocínio por modelo

O valor 15.725 não é erro de digitação. Uma única chamada de tradução, em um modelo Flash na configuração média (medium), consumiu quinze mil tokens de raciocínio.

Geralmente, essas inflações de tokens ocorrem porque o Gemini deixa vazar seus tokens brutos de pensamento para a saída. Como você deve saber, o "pensamento" do modelo não é exatamente o que ele pensa, mas sim resumos polidos; o raciocínio real do LLM é mais parecido com um fluxo de consciência.

Vale notar, porém, que, neste caso específico, o Gemini vasculhou calmamente uma tradução de inglês para ucraniano de um trecho literário com uma frase como "o aço puro rejeita vernizes e tintas". Ele estava testando por força bruta e lendo em voz alta umas doze opções até gostar do resultado.

Algumas semanas depois, uma atualização. Aquele 15,725 não foi um ato isolado de dedicação do Gemini, mas um padrão específico de tarefas complexas.

Com o aumento do tráfego, especialmente no gemini-3.1-flash-lite, o mesmo número continua aparecendo. Uma faixa suspeitamente estreita entre 15,724 e 15,729 em dezenas de chamadas, quase todas de modelos Lite processando revisões de glossários. O curioso é que elas rodam com esforço de pensamento baixo (low), que não seria a configuração que se esperaria ser a mais cara.

Um modelo que chega ao mesmo número onze vezes atingiu um teto, não escolheu uma redação. O pensamento no nível low satura em torno de 15,7 mil tokens. Como modelos pequenos, como o lite, não pensam de forma tão eficaz, tarefas complexas os estimulam a consumir muitos tokens; isso nunca acontece em modelos maiores, onde cada token tem mais chances de ser um passo relevante rumo à resposta.

Além disso, essa saturação tem um custo. No Gemini 3, os tokens de pensamento são descontados do maxOutputTokens. Uma chamada que gasta 15,7 mil tokens pensando não deixa quase nada para a resposta; no entanto, todo o pensamento é cobrado na tarifa de saída. Com um orçamento de 16 mil, a auditoria retornava vazia (finishReason=MAX_TOKENS) em cerca de metade das vezes em documentos pequenos, o que nos levou a investigar.

Aumentar o limite trata o sintoma, não a causa. Elevamos o limite da auditoria para 32 mil no nível low, o que deixa cerca de 16 mil para a saída após um pensamento saturado — as respostas vazias pararam. Mas o pensamento não encolheu. Não há como limitá-lo no Gemini 3, então ele continua consumindo cerca de 15,7 mil tokens; o limite maior apenas dá espaço para a resposta aparecer.

A única solução real para esse uso extremo de 16 mil tokens de pensamento foi reduzir o escopo da tarefa.

O nível minimal é o único que se comporta como um limite real, com um teto de aproximadamente 2 mil tokens. No entanto, ele só está disponível para modelos Lite.

Tokens de pensamento por tipo de tarefa (Flash vs Pro, ambos no nível medium)

O Pro pensa quase duas vezes menos que o Flash em traduções simples. Ele só supera o Flash em tarefas de reescrita. O esforço de raciocínio acompanha a dificuldade da tarefa, não o nível de marketing do modelo.

Pode-se argumentar que o Pro alcança resultados melhores em benchmarks de tradução justamente por sua capacidade de raciocinar com mais profundidade quando necessário.

Conclusões práticas

• Não defina o thinkingBudget em modelos Gemini 3. Ele será ignorado ou retornará um erro.
• O nível medium não tem um limite superior definido. Um planejamento realista prevê cerca de 4 mil tokens de raciocínio (p90) por chamada, em vez de 2 mil.
• Se precisar de um limite rígido de custo, use minimal sempre que possível. Não faz sentido interromper a geração: você será cobrado de qualquer forma.
• Verifique o usageMetadata.thoughtsTokenCount em cada resposta se você cobra por chamada. O número não está no corpo da resposta, mas consta na fatura.
• No nível medium, o Pro tende a raciocinar menos que sua mediana em tarefas simples e mais nas difíceis. O Lite e o Flash não apresentam essa variação.

Isso torna o Pro o melhor modelo para revisão e refinamento acima do nível básico de um LLM, pois é aí que sua criatividade desperta. Para rascunhos brutos de tradução, o Flash é superior.

Isso exige tempo e dinheiro, no entanto. Na Transept, descobrimos como mitigar os custos do Pro usando uma lógica de revisão inteligente para acioná-lo apenas nas partes mais complexas. Também usamos o Pro para planejar e tomar decisões, delegando a execução a modelos menores e fine-tunes.

Dessa forma, tudo funciona.