Google: Gemini 3.1 Pro Preview vs Google: Gemma 4 31B

Em preço, Google: Gemma 4 31B é a opção mais barata — cerca de 94% abaixo de Google: Gemini 3.1 Pro Preview nos tokens de entrada. Para cargas de trabalho sensíveis à latência, Google: Gemma 4 31B retorna o primeiro token mais cedo. Escolha Google: Gemma 4 31B para minimizar o custo, ou Google: Gemma 4 31B quando a velocidade de resposta importa mais.

Tanto Google: Gemini 3.1 Pro Preview quanto Google: Gemma 4 31B estão disponíveis pelo mesmo endpoint do OrcaRouter ao custo do provedor e sem qualquer acréscimo sobre os tokens, então alternar entre eles é uma mudança de uma linha e os números abaixo são o que você realmente paga. Esta comparação puxa preços ao vivo, a context window publicada e as próprias medições de latency e throughput do OrcaRouter, para que você possa ponderar custo contra desempenho para a sua carga de trabalho específica em vez de confiar no benchmark de vitrine de um fornecedor. A escolha certa quase sempre depende do formato do seu tráfego — comprimento dos prompts, quanto texto você gera, quão sensíveis à latency são seus usuários e quão difícil é o raciocínio — por isso as seções abaixo destrincham a decisão uma dimensão de cada vez e terminam com uma recomendação concreta. Sempre que faltar uma métrica para um dos dois modelos, essa linha é omitida em vez de adivinhada, de modo que toda afirmação aqui é respaldada por um número real.

Em tokens de entrada, Google: Gemini 3.1 Pro Preview custa $2.00 por milhão contra $0.13 de Google: Gemma 4 31B, e na saída $12.00 contra $0.38 por milhão. A conta costuma ser decidida nos tokens de saída: uma carga de chat ou de agent que gera completions longas é dominada pela taxa de saída, então um modelo que parece mais barato na entrada ainda pode ser a escolha mais cara de ponta a ponta. Estime sua real proporção entrada-saída antes de escolher só pelo preço — um prompt intensivo em recuperação com resposta curta e um prompt curto com geração longa caem em extremos opostos desta tabela. Uma forma prática de dimensionar isso é pegar uma amostra representativa dos seus prompts, contar a média de tokens de entrada e de saída, e multiplicar cada uma pelas respectivas taxas dos dois modelos; o modelo com o menor custo combinado (blended) no seu mix real é o que precisa ser superado. Lembre-se de que ambos os preços aqui são a taxa bruta do provedor — o OrcaRouter não adiciona acréscimo — então a comparação é de igual para igual e a economia que você calcula é a economia que você fica.

Latency e throughput decidem como o modelo se sente em produção. A latency de resposta mediana (p50) é quanto uma requisição típica espera antes do primeiro token; o throughput (tokens por segundo) define a que velocidade a resposta é transmitida depois de iniciada. Para chat interativo e loops de agent, uma latency p50 baixa importa mais porque o usuário está esperando o primeiro token; para geração em lote e saída de formato longo, o throughput domina o tempo total porque a resposta é longa. Os gráficos de tendência de 7 dias acima mostram se a latency de cada modelo é estável ou está derivando, algo que um único número de destaque esconde — um modelo com ótima média mas cauda ruidosa ainda pode não cumprir um SLA p95 rígido. Se o seu produto tem um orçamento de latency, leia tanto a mediana quanto o formato da curva, e lembre-se de que a latency de ponta a ponta também inclui o seu salto de rede e qualquer recuperação ou chamada de ferramenta que você faça em torno do modelo.

Pontuações de benchmark aproximam a capacidade, mas não substituem testes com seus próprios prompts. Os índices compostos mostrados aqui agregam várias avaliações públicas, e o percentil marca onde cada modelo se posiciona frente a todos os modelos comparáveis do catálogo — um sinal útil de pré-seleção, não uma garantia para a sua tarefa. Um modelo que lidera num índice de inteligência geral pode ficar para trás no seu domínio (código, extração, multilíngue, raciocínio de contexto longo), então use os benchmarks para estreitar o campo e depois rode ambos os modelos numa fatia representativa do seu tráfego. Preste atenção ao índice específico que corresponde ao seu caso de uso em vez do número principal: um produto com muito código deve pesar o índice de código, um assistente de pesquisa o índice de raciocínio. Os benchmarks também envelhecem à medida que os modelos são atualizados, então trate-os como uma hipótese inicial que você confirma com o seu próprio conjunto de avaliação.

Se o custo é a restrição decisiva, comece com o modelo mais barato no seu mix real entrada-saída e só suba de nível se a qualidade não atender. Se a prioridade é a capacidade de resposta — chat voltado ao usuário, agents, qualquer caso em que alguém esteja esperando — dê mais peso à latency p50 e ao throughput do que a uma pequena diferença de preço. Se você está forçando o raciocínio, o código ou o trabalho de contexto longo mais exigentes, deixe o vencedor em benchmark e context window liderar e aceite a taxa mais alta onde ela se paga. Como ambos os modelos ficam atrás da mesma API, a jogada de baixo risco é rotear uma fração do tráfego real para cada um e comparar custo, latency e qualidade das respostas nos seus próprios prompts antes de se comprometer. Um padrão comum é escalonar (tier): envie o grosso das requisições fáceis e de alto volume para o modelo mais barato ou mais rápido e reserve o modelo mais forte para as requisições que realmente precisam dele, o que captura a maior parte do ganho de qualidade por uma fração do custo. Seja qual for a sua escolha, mantenha a troca reversível — com uma mudança de nome de modelo de uma linha você pode devolver o tráfego assim que os números ou seus requisitos mudarem.

Nos últimos 7 dias, Google: Gemma 4 31B mantém a menor latência de resposta mediana.