Google deprecia parâmetros de temperatura no Gemini

Resumo rápido

• A documentação oficial do Gemini API confirma: para os modelos da linha Gemini 3.x, o Google recomenda remover temperature, top_p e top_k das requisições e manter os valores padrão.
• Em alguns modelos mais recentes (como Gemini 3.6 Flash e variantes 3.5 Flash-Lite), esses parâmetros já são simplesmente ignorados pela API, sem gerar erro.
• Seu código continua rodando sem quebrar, mas o comportamento pode mudar: é hora de auditar chamadas que dependem desses parâmetros para controlar aleatoriedade.

Se você trabalha com a API do Gemini, provavelmente já viu ou usou algo como temperature: 0.2 para deixar as respostas mais previsíveis, ou temperature: 0.9 para gerar textos mais criativos. Essa prática, comum em praticamente toda API de LLM, está mudando na linha mais recente do Gemini.

O que a documentação oficial do Google realmente diz

Vale separar o que é fato confirmado do que é especulação. Segundo a página oficial “What’s new in Gemini 3.5”, da documentação do Gemini API:

> “temperature, top_p e top_k não são mais recomendados para todos os modelos Gemini 3.x.” A orientação direta é: “remova esses parâmetros de todas as requisições.”

Já o Gemini 3 Developer Guide reforça isso especificamente para o parâmetro temperature:

> “Para todos os modelos Gemini 3, recomendamos fortemente manter o parâmetro temperature no valor padrão de 1.0.” O motivo apontado é que “as capacidades de raciocínio do Gemini 3 são otimizadas para as configurações padrão”, e reduzir a temperatura pode causar “comportamento inesperado, como loops ou desempenho degradado, principalmente em tarefas complexas de matemática ou raciocínio.”

Isso confirma o fato central: a mudança é real e está documentada oficialmente pelo Google, embora a formulação exata varie por modelo. Em alguns lançamentos mais recentes dentro da família 3.x, os parâmetros já passam a ser ignorados de fato pela API (sem erro), com a expectativa de que futuras gerações de modelo retornem erro HTTP 400 caso ainda sejam enviados. Se você trabalha com modelos Gemini anteriores à linha 3.x, vale checar a documentação de depreciações do Gemini API para confirmar o comportamento específico da versão que está usando, já que a mudança é tratada por modelo, não como uma regra universal para toda a API.

O que significam esses parâmetros

Antes de entender o impacto da mudança, vale relembrar o papel de cada um deles no processo de geração de texto:

Temperature controla o nível de aleatoriedade na seleção de tokens. Valores baixos (próximos de 0) tornam o modelo mais determinístico e conservador, escolhendo sempre as opções mais prováveis. Valores altos (próximos de 1 ou acima) aumentam a criatividade e a imprevisibilidade, permitindo que o modelo explore opções menos óbvias.

Top_p (também conhecido como nucleus sampling) define um limiar de probabilidade acumulada. O modelo considera apenas os tokens mais prováveis cuja soma de probabilidades atinge esse valor. Por exemplo, com top_p=0.9, o modelo escolhe entre os tokens que representam 90% da massa de probabilidade.

Top_k limita a escolha aos k tokens mais prováveis em cada etapa de geração. Com top_k=40, o modelo considera apenas as 40 opções mais prováveis, descartando todas as outras, independentemente de sua probabilidade.

Se você já testou modelos como o Gemini ou fez comparações práticas entre ferramentas, talvez tenha visto esses parâmetros aparecerem em discussões sobre qual IA “acerta mais” ou “varia mais” nas respostas. Vale revisitar nosso comparativo entre Gemini e ChatGPT para entender como essas diferenças de configuração afetavam o comportamento de cada modelo até aqui.

Por que esses parâmetros eram importantes

O controle fino sobre temperature, top_p e top_k permitia aos desenvolvedores ajustar o comportamento do modelo para diferentes casos de uso. Aplicações que exigem precisão e consistência, como geração de código, análise de documentos técnicos ou assistentes em contextos médicos e jurídicos, tradicionalmente se beneficiavam de valores baixos de temperatura (0.1 a 0.3).

Já aplicações criativas, como geração de histórias, brainstorming ou criação de conteúdo de marketing, frequentemente utilizavam temperaturas mais altas (0.7 a 1.0 ou superior) para obter respostas mais variadas.

Essa flexibilidade também era usada no ajuste de comportamento em produção. Equipes de desenvolvimento experimentavam diferentes combinações desses parâmetros para encontrar o equilíbrio entre criatividade e confiabilidade para seu caso específico, um processo parecido com o que discutimos em como usar IA, ChatGPT e Copilot para programar e aprender mais rápido.

O que muda na prática para o seu código

A mudança tem consequências diretas para código em produção. Se sua aplicação já define explicitamente esses parâmetros ao chamar um modelo Gemini 3.x, o código continua rodando sem erros, mas o comportamento pode ser diferente do esperado, já que os valores enviados podem não ter mais efeito.

Isso significa que:

• Código que define temperature=0.1 esperando respostas determinísticas pode passar a receber saídas mais variadas
• Aplicações que usam temperature=0.9 para gerar respostas mais criativas podem não notar diferença, ou receber respostas menos “soltas” que o esperado
• Testes automatizados que dependem de consistência de saída podem começar a falhar de forma intermitente
• Estratégias de “repetir a chamada com uma temperatura diferente” deixam de fazer sentido nos modelos afetados

Um exemplo típico de chamada que precisa ser revisada:

generation_config = {
    "temperature": 0.2,
    "top_p": 0.8,
    "top_k": 40
}

response = model.generate_content(
    prompt,
    generation_config=generation_config
)

Esse código provavelmente ainda executa sem erro em modelos Gemini 3.x, mas os três parâmetros podem ser ignorados, e o Google já sinaliza que versões futuras podem passar a rejeitar a requisição com erro HTTP 400 caso esses campos sejam enviados. O caminho recomendado pela documentação é remover esses campos da chamada e, se você precisa de determinismo, expressar isso via instruções de sistema em vez de parâmetros de amostragem.

Por que o Google está fazendo essa mudança

A documentação oficial explica o racional para o caso específico da temperatura no Gemini 3: o modelo já foi treinado e otimizado considerando o valor padrão, e mexer nesse parâmetro pode degradar o raciocínio em tarefas complexas, incluindo loops de repetição indesejados.

Isso reflete uma tendência mais ampla entre provedores de LLM: em vez de expor parâmetros de baixo nível para ajuste manual, alguns modelos mais recentes, com capacidades de raciocínio mais sofisticadas, funcionam melhor quando o controle de amostragem é deixado no padrão calibrado durante o treinamento. Discutimos uma lógica parecida ao explicar como as práticas de prompt mudaram na prática em context engineering para Claude, onde o ajuste fino do comportamento também migrou de parâmetros soltos para instruções mais estruturadas.

O que fazer agora

Se você mantém integrações com a API do Gemini, vale considerar estas ações:

Auditoria de código: identifique onde temperature, top_p e top_k são usados e documente qual era o comportamento esperado com cada um. Isso facilita detectar mudanças de comportamento em produção.

Testes de regressão: compare respostas geradas antes e depois de remover esses parâmetros, para os modelos Gemini 3.x que você utiliza, e veja se há diferença significativa.

Monitoramento: adicione logging para acompanhar a variabilidade das respostas, principalmente em fluxos que dependiam de alta previsibilidade.

Leitura da documentação por modelo: como a mudança não é uniforme entre todas as versões do Gemini, confira a página de depreciações do Gemini API e a página do que há de novo no Gemini 3.5 para o modelo específico que você usa antes de decidir remover os parâmetros em produção.

Perguntas frequentes

Isso vale para todos os modelos Gemini, incluindo versões antigas? Não necessariamente. A recomendação oficial de remover temperature, top_p e top_k é feita para os modelos da linha Gemini 3.x. Modelos anteriores podem continuar respeitando esses parâmetros normalmente; o ideal é checar a documentação de depreciações para a versão específica que você usa.

Meu código vai parar de funcionar se eu continuar enviando esses parâmetros? Na maioria dos modelos afetados hoje, não. Os parâmetros são apenas ignorados, sem gerar erro. O Google já sinaliza, porém, que gerações futuras de modelo podem passar a retornar erro HTTP 400 se esses campos forem enviados, então vale planejar a remoção com antecedência.

Existe algum parâmetro que substitua temperature, top_p e top_k? A orientação oficial não aponta um parâmetro substituto direto. A recomendação é usar instruções de sistema para expressar o comportamento desejado (mais determinístico ou mais criativo) em vez de ajustar parâmetros de amostragem.

Isso afeta só quem usa a API diretamente, ou também ferramentas que usam Gemini por baixo dos panos? Depende de como cada ferramenta expõe esses controles. Se você usa um SDK ou produto de terceiros que repassa temperature, top_p ou top_k para o Gemini, vale confirmar com o fornecedor se esses parâmetros ainda têm efeito nos modelos que ele utiliza.

Conclusão

A mudança é real e está documentada oficialmente pelo Google: para a linha Gemini 3.x, temperature, top_p e top_k deixaram de ser recomendados, e em modelos específicos já são ignorados na prática. Isso marca uma mudança de filosofia sobre como interagimos com esses modelos. O controle manual desses parâmetros oferecia flexibilidade, mas também exigia calibragem cuidadosa e podia levar a resultados ruins quando mal configurado.

Se você mantém código em produção com esses parâmetros, o passo mais seguro agora é auditar onde eles aparecem, testar o comportamento sem eles nos modelos Gemini 3.x e acompanhar a documentação oficial à medida que novas versões do modelo forem lançadas.