Gemini 3.6 Flash ou Flash-Lite: pague mais só quando o erro custa caro

Use o Gemini 3.5 Flash-Lite para classificação, extração padronizada, tradução e outras cargas previsíveis de alto volume. Encaminhe ao Gemini 3.6 Flash os casos ambíguos, agentes com várias etapas, alterações de código e decisões em que uma resposta errada provoque retrabalho caro ou uma ação difícil de reverter.

A escolha não depende apenas do preço por token nem do número da versão. Compare o custo total por tarefa aceita: inferência, novas tentativas, validação, revisão humana e correção das falhas que chegam à produção. Pagar mais pelo 3.6 Flash faz sentido quando a redução de erros observada na sua carga vale mais que o prêmio cobrado pelo modelo.

O papel de cada modelo

O Flash-Lite é o primeiro candidato para tarefas estreitas, com formato de saída definido e resultado verificável. O 3.6 Flash pode assumir a coordenação ou a rota de exceção quando a solicitação exige decomposição, uso de ferramentas, análise multimodal difícil ou consistência entre várias etapas.

Esse ponto de partida acompanha o posicionamento do fabricante. No anúncio dos modelos Gemini, o Google apresenta o 3.6 Flash como modelo de uso geral para programação, trabalho de conhecimento e tarefas multimodais, enquanto descreve o 3.5 Flash-Lite como opção de baixa latência e alto volume. É uma orientação para montar os testes, não uma garantia de superioridade em toda carga complexa.

• Flash-Lite: classificação, roteamento, tradução, extração de campos e transformação de dados com esquema rígido.
• 3.6 Flash: coordenação de agentes, programação, análise de documentos heterogêneos e exceções que exigem várias etapas.
• Fluxo híbrido: Flash-Lite no caminho comum; 3.6 Flash quando uma validação falha ou a consequência do erro aumenta.

Calcule com a tarifa realmente vigente

Na modalidade Standard paga, a tabela oficial da Gemini Developer API cobra pelo 3.6 Flash US$ 0,75 por milhão de tokens de entrada e US$ 3,75 por milhão de saída até 31 de dezembro de 2026; a partir de 1º de janeiro de 2027, os valores passam a US$ 1,50 e US$ 7,50. Para o 3.5 Flash-Lite, os preços Standard são US$ 0,30 na entrada e US$ 2,50 na saída. Tokens de raciocínio entram na cobrança de saída.

A conta básica é: tokens de entrada divididos por 1 milhão, multiplicados pelo preço de entrada, mais tokens de saída divididos por 1 milhão, multiplicados pelo preço de saída. Use medições de uma amostra representativa. Câmbio, impostos, grounding, cache, ferramentas externas e revisão humana devem entrar como parcelas separadas.

Em um exemplo hipotético de 1 milhão de chamadas, cada uma com 800 tokens de entrada e 100 de saída, o Flash-Lite custaria US$ 490. O 3.6 Flash custaria US$ 975 durante a tarifa temporária de 2026 e US$ 1.950 depois dela. A diferença de US$ 485 no primeiro período é o orçamento disponível para evitar falhas, revisões e repetições antes que o modelo mais caro deixe de compensar.

Velocidade não substitui taxa de acerto

O Flash-Lite leva vantagem quando a vazão de geração limita a capacidade do sistema. Em testes realizados antes do lançamento, a medição da Artificial Analysis registrou 350 tokens de saída por segundo para o 3.5 Flash-Lite e 304 para o 3.6 Flash. No índice agregado da organização, porém, os modelos receberam 36 e 50 pontos, respectivamente.

Esses resultados não preveem diretamente a latência nem a qualidade da sua aplicação. Tamanho do prompt, nível de raciocínio, região, concorrência, chamadas de ferramentas e tempo até o primeiro token mudam o resultado. Para classificação curta, meça o tempo até a resposta completa; para agentes, meça o ciclo inteiro, incluindo ferramentas, repetições e recuperação de falhas.

Capacidade semelhante não significa qualidade igual

O Flash-Lite não está restrito a texto simples. O model card do Gemini 3.5 Flash-Lite especifica entradas de texto, imagem, áudio e vídeo, janela de contexto de até 1 milhão de tokens e saída textual de até 64 mil tokens. O documento também inclui agentes, código, processamento de documentos e busca entre os usos previstos, mas reconhece limitações gerais de modelos fundacionais, como alucinações.

A janela de contexto informa quanto material pode ser enviado, não quanto será interpretado corretamente. Contratos digitalizados, tabelas desalinhadas, áudio ruidoso e instruções conflitantes ainda precisam de avaliações separadas por tipo de entrada. Em extração, JSON válido comprova apenas a sintaxe; um valor associado ao campo errado continua sendo um erro semântico.

Para código, o Flash-Lite pode cuidar de triagem, explicação de mensagens de erro, geração repetitiva e alterações pequenas protegidas por testes. Migrações amplas, edições em vários arquivos ou ações executadas por um agente elevam a consequência de uma decisão incorreta e justificam avaliar o 3.6 Flash, sem dispensar testes automatizados e revisão.

Transforme o custo do erro em uma matriz

Classifique cada carga pela consequência de uma falha que atravesse as validações. A complexidade aparente do prompt importa menos que o dano causado por uma saída incorreta.

• Risco baixo: etiquetas internas, detecção de idioma, deduplicação e extrações conferidas por regras determinísticas. Comece com o Flash-Lite e rejeite respostas fora do esquema.
• Risco médio: documentos variados, suporte ao cliente e sínteses consumidas por outra etapa. Use o Flash-Lite no primeiro passe e escale respostas inconsistentes, incompletas ou fora da distribuição esperada.
• Risco alto: alteração de código em produção, movimentação financeira, decisão regulatória ou agente autorizado a agir. Avalie o 3.6 Flash como rota principal e preserve aprovação humana quando a ação for difícil de desfazer.

Retomando o exemplo hipotético, suponha que o 3.6 Flash evite 100 erros adicionais em 1 milhão de chamadas. O prêmio de US$ 485 equivale a US$ 4,85 por erro evitado. Se cada falha do Flash-Lite custar mais que isso para detectar e corrigir, o modelo mais caro tende a compensar; se custar menos, o Lite permanece mais econômico. A quantidade de erros evitados precisa vir da sua avaliação, não de uma taxa presumida.

Implemente o roteamento pelas exceções

Monte uma amostra de casos reais em português, incluindo documentos difíceis, solicitações incompletas e entradas cujo significado dependa do contexto. Execute os dois modelos com o mesmo contrato de saída e registre tokens, latência, resultado das validações, correção semântica e necessidade de revisão.

1. Envie ao Flash-Lite tarefas de baixo risco e formato previsível.
2. Valide campos obrigatórios, tipos, limites e consistência entre valores.
3. Encaminhe ao 3.6 Flash respostas inválidas, entradas fora da distribuição e pedidos associados a ações sensíveis.
4. Compare o custo por resposta aprovada, não apenas por chamada concluída.
5. Revise falsos positivos, falsos negativos e mudanças no perfil das entradas.

Não use a autoconfiança declarada pelo modelo como único gatilho. Divergência entre extrações, falha de esquema, ausência de evidência, teste de código quebrado ou valor fora de uma faixa válida produzem uma política de escalonamento mais auditável.

O objetivo não é encontrar um vencedor universal. É deixar o Flash-Lite absorver o tráfego barato e previsível, enquanto o 3.6 Flash recebe os casos em que sua tarifa adicional pode evitar um erro mais caro que a diferença de inferência.