O preço por token não conta a história completa
Quando equipes de engenharia vão comparar modelos de IA generativa, o caminho mais óbvio é olhar para o preço por milhão de tokens. É o número que aparece em todas as páginas de precificação e, naturalmente, acaba sendo o número que domina as planilhas de decisão. O problema é que cargas de trabalho reais não compram tokens — elas compram resultados: um ticket de suporte resolvido, um resumo financeiro correto, um relatório de pesquisa completo.
Entre a página de preços e o resultado final existem multiplicadores que o preço nominal ignora: com que frequência o modelo acerta, quantos tokens ele precisa para chegar lá e, em cargas de trabalho agênticas, quantos turnos ele leva — porque cada turno reenvia o histórico crescente da conversa para o modelo.
A AWS publicou um estudo baseado em um harness de benchmarking de código aberto que mede esses multiplicadores em cinco modelos: os modelos OpenAI no Amazon Bedrock (gpt-5.6-luna, gpt-5.6-terra e gpt-5.6-sol) e dois modelos cost-efficient da API OpenAI (gpt-5.4-mini e gpt-5.4-nano). Os dois últimos foram escolhidos como linha de base porque a pergunta mais comum das equipes é: “Usamos mini ou nano hoje — vale migrar para um modelo mais novo no Amazon Bedrock?”
O estudo foca em três perguntas centrais: quanto custa uma resposta correta (não um token); quanto custam trajetórias de agentes completas, já que o número de turnos pode dominar a fatura; e se o modelo consegue produzir entregas que um profissional aprovaria, medidas em tarefas reais de trabalho, não em questões de quiz.
Todo o benchmarking é reproduzível: o repositório openai-on-aws/benchmarks-openai roda o mesmo caminho de código (a Responses API da OpenAI) contra ambas as plataformas, e a AWS encoraja que cada equipe rode os testes com suas próprias tarefas antes de tomar qualquer decisão.
Como o estudo foi estruturado
O harness avalia os cinco modelos por meio do mesmo cliente da Responses API, alternando apenas o backend e o ID do modelo enquanto mantém a lógica de avaliação constante. Os modelos no Amazon Bedrock rodaram com raciocínio (reasoning) desabilitado, enquanto os modelos da API OpenAI rodaram com as configurações padrão. Ou seja, é uma comparação de configurações práticas de implantação, não uma medição controlada de capacidade intrínseca dos modelos.
Três dimensões foram medidas: precisão em chamada única e custo em benchmarks que ainda diferenciam modelos de ponta (matemática de competição AIME, ciência de nível de pós-graduação GPQA Diamond e MMLU-Pro); trajetórias de agentes em tarefas reais de pesquisa na web; e entregas profissionais avaliadas por rubrica.
Medindo o custo de uma resposta correta
Para cada benchmark, o estudo divide o gasto total de um modelo — considerando tentativas certas e erradas — pelo número de respostas corretas. Isso estima o custo observado de uma resposta correta na amostra.
Dois pontos chamam atenção nos resultados. Primeiro, os níveis de capacidade são visíveis na amostra: o sol resolve 75% dos problemas do AIME contra 37% do mini, e lidera também no GPQA Diamond (68% contra 43%) e no MMLU-Pro (82% contra 59%). Segundo, a eficiência de tokens já decidia a fatura antes mesmo dos preços mudarem — e os preços mudaram.
Com o seu preço original (cerca de 1,5× o do mini), o luna já era 25% mais barato por resposta correta no AIME nessa configuração, porque com o raciocínio desabilitado ele usava menos tokens faturados do que o mini com suas configurações padrão. Após a redução de preços do GPT-5.6 Luna e Terra no Amazon Bedrock em 30 de julho de 2026 (luna −80%, terra −20%), o custo registrado por resposta correta no AIME passou a ser US$ 0,0021 para o luna contra US$ 0,0139 para o mini. Nas amostras analisadas, o luna apresentou o menor custo observado por resposta correta, inclusive contra o nano, mesmo que o preço nominal por token do nano seja ligeiramente menor.
Nota sobre preços: os arquivos de resultado utilizam US$ 0,22/US$ 1,32 por milhão de tokens de entrada/saída para o luna e US$ 2,20/US$ 13,20 para o terra. Confirme o nível de inferência aplicável no Amazon Bedrock e a região na página de preços atualizada antes de tomar decisões.
O custo das trajetórias de agentes
A precificação por chamada única ignora uma característica central de cargas de trabalho agênticas. O harness usa histórico gerenciado pelo cliente com store: false, o que significa que cada turno reenvia o prompt de sistema, os resultados anteriores de ferramentas e todo o contexto da conversa. O contexto por turno cresce de forma aproximadamente linear. Assim, o total de tokens de entrada faturados pode crescer de forma aproximadamente quadrática com o número de turnos. Cada turno também adiciona latência de ida e volta. Um modelo que termina em cinco turnos em vez de oito pode economizar muito mais do que os 37% de redução de turnos sugerem isoladamente.
Para medir isso em uma carga de trabalho real, o estudo rodou uma amostra estratificada de 50 questões do DeepSearchQA — perguntas de pesquisa na web em múltiplas etapas — por meio de um loop de agente ao vivo com ferramentas reais de web_search e fetch_page. As respostas foram pontuadas com uma pré-verificação determinística seguida de um avaliador automático (autorater) baseado no gpt-5.5. Uma questão passa com F1 ≥ 0,7.
O mini foi o modelo com mais turnos por questão entre todos (7,6 turnos, principalmente em loops de nova pesquisa), e cada turno extra reenviava um contexto acumulado com resultados de busca. Ao final, isso representou 2,3× o volume de tokens de entrada do terra (114 mil contra 50 mil tokens por questão). Nessa amostra, o preço maior por token do terra foi compensado por menos turnos e maior qualidade: US$ 0,31 por resposta aprovada contra US$ 0,40 do mini, com F1 médio de 0,50 contra 0,39.
As três configurações GPT-5.6 registraram F1 médio maior do que as duas linhas de base. O luna combinou menos turnos do que o mini com US$ 0,05 por resposta aprovada contra US$ 0,40 do mini. O preço nominal por token do nano era menor, mas com taxa de aprovação de 18%, seu custo observado por resposta aprovada foi de US$ 0,07 contra US$ 0,05 do luna.
A lição prática: a eficiência de turnos é uma variável de precificação que simplesmente não aparece na página de preços. Se os seus agentes encadeiam chamadas de ferramentas — pesquisa, consultas em múltiplos saltos, recuperação iterativa — é fundamental medir o custo da trajetória completa, não apenas o custo por chamada.
Avaliando entregas profissionais com o GDPval
Benchmarks avaliam respostas. Mas grande parte do que as equipes realmente entregam são documentos — pareceres de conformidade, planos financeiros, protocolos de atendimento — onde “correto” é uma rubrica, não uma correspondência de string. Por isso o estudo incluiu 48 tarefas do GDPval: entregas profissionais reais criadas por profissionais com média de 14 anos de experiência, cada uma avaliada contra sua rubrica de referência. Uma entrega passa com ≥ 70% dos pontos ponderados da rubrica.
As três configurações gpt-5.6 alcançaram pontuações de rubrica observadas mais altas do que mini e nano com raciocínio desabilitado. As maiores diferenças apareceram em tarefas de direito, enfermagem e consultoria financeira, onde as rubricas exigem ressalvas específicas, estrutura e completude.
O luna pontuou acima do mini em 31 das 48 entregas, abaixo em 9 e empatou em 8. Ele passou em 27 entregas contra 20 do mini. Como essa carga de trabalho é de chamada única sem efeitos de turno, antes da redução de preços o mini e o nano eram mais baratos por entrega aprovada, e o gpt-5.6 comprava apenas taxa de aprovação. Após a redução, o luna passou a ter o menor custo observado nessa amostra: US$ 0,010 por entrega aprovada contra US$ 0,030 do mini e US$ 0,012 do nano, com taxa de aprovação de 56% contra 42% do mini e 35% do nano.
O terra e o sol ainda têm um custo maior por aprovação, mas registram desempenho de rubrica mais alto. Se esse custo adicional se justifica depende do custo de revisão e retrabalho no fluxo de trabalho alvo.
Ressalva do GDPval: as saídas foram limitadas a 8.192 tokens, truncando 6 entregas do luna, 9 do terra, 7 do sol, 0 do mini e 1 do nano. Esses são resultados reais sob o limite testado. Um limite maior pode melhorar a qualidade, mas também pode aumentar o custo — é importante testar os dois juntos.
Framework de decisão por tipo de carga de trabalho
Para quem usa gpt-5.4-mini ou nano hoje, a questão de migração depende do perfil da carga de trabalho:
- Tarefas de alto volume e baixa complexidade, onde falhas são baratas: comece com o
gpt-5.6-lunano Amazon Bedrock. O luna registrou o menor custo por resultado bem-sucedido nas amostras analisadas. - Aplicações interativas onde precisão importa e há Objetivos de Nível de Serviço (SLOs) de latência: faça benchmark do
gpt-5.6-lunano Amazon Bedrock primeiro. Os resultados de latência são um retrato pontual regional — meça novamente em relação aos seus SLOs. - Agentes que encadeiam chamadas de ferramentas (pesquisa, consultas em múltiplos saltos): faça benchmark do
gpt-5.6-lunae dogpt-5.6-terrano Amazon Bedrock. Ambos registraram F1 mais alto no DeepSearchQA com menos turnos do que o mini. O luna custou cerca de 8× menos por resposta aprovada nessa amostra de 50 questões. - Produção de documentos com controle de qualidade: o
gpt-5.6-lunano Amazon Bedrock teve a maior taxa de aprovação entre os modelos cost-efficient no GDPval (27/48 contra 20/48 do mini) ao menor custo por entrega aprovada (US$ 0,010 contra US$ 0,030). - Precisão como requisito rígido em trabalhos genuinamente difíceis: faça benchmark do
gpt-5.6-solno Amazon Bedrock. Ele representa um nível diferente de capacidade e preço (AIME 75%, GDPval 31/48). Considere-o quando as configurações de menor custo não atingirem o seu limite de qualidade.
Latência: um retrato pontual
O estudo também mediu a latência dos mesmos modelos nas duas plataformas com o mesmo harness de streaming. Nas execuções de julho de 2026 (us-west-2, região única, retrato pontual), o tempo mediano até o primeiro token no Amazon Bedrock foi em média 21% menor para o luna e 5% menor para o terra nas 12 configurações correspondentes. O throughput do luna foi em média 43% maior no Amazon Bedrock em saídas com ≥ 500 tokens (terra +4%). As proporções piores-caso de tempo até o primeiro token para a mediana foram de 2,1–2,5× no Amazon Bedrock contra 4,6–6,6× na API OpenAI.
O sol tem comportamento diferente: é um modelo de raciocínio profundo com tempo até o primeiro token inerentemente longo e variável, e suas execuções no Amazon Bedrock usaram us-east-1. Os detalhes por configuração para os três modelos estão documentados na seção de performance do repositório.
Como rodar o benchmark na sua própria carga de trabalho
Os resultados refletem as escolhas de configuração do estudo: 50–198 questões por conjunto (DeepSearchQA 50, AIME 60, MMLU-Pro 140, GPQA Diamond 198), 48 entregas e raciocínio desabilitado para os modelos no Amazon Bedrock — um piso deliberado de custo. Habilitar o raciocínio aumenta tanto a qualidade quanto o gasto. As suas tarefas não são as tarefas do estudo.
A metodologia é a parte durável. Para reproduzir os benchmarks:
git clone https://github.com/openai-on-aws/benchmarks-openai
pip install -r requirements.txt
export OPENAI_API_KEY=sk-... # sua própria chave; não é armazenada
export AWS_REGION=us-west-2 # mais suas credenciais AWS padrão
python quality/quick_evals.py # precisão + custo por resposta correta
python quality/deepsearchqa/run_deepsearchqa.py # trajetórias de agentes com web ao vivo
python quality/gdpval_eval.py # entregas profissionais, avaliadas por rubrica
performance/run_all.sh # latência, ambas as plataformasSubstitua por 50–100 das suas próprias tarefas com saídas conhecidas e os mesmos scripts produzem números de custo por resultado no seu domínio, na sua conta.
Conclusão
O preço por token é uma entrada para a decisão, não a decisão em si. Nas configurações testadas, normalizar o custo por resultados bem-sucedidos mudou o ranking dos modelos depois que precisão, eficiência de tokens e comprimento de trajetória foram considerados. As páginas de preços também mudam — como as reduções de julho de 2026 para o GPT-5.6 demonstraram.
A recomendação é definir o resultado e o limite de qualidade que a sua aplicação precisa, medir o custo completo de sucessos e falhas, e repetir a avaliação quando preços, modelos ou padrões de carga de trabalho mudarem. Para começar com os modelos OpenAI no Amazon Bedrock, consulte a documentação do Amazon Bedrock. Para reproduzir os benchmarks nas suas próprias tarefas, clone o repositório openai-on-aws/benchmarks-openai.
Fonte
Beyond the price per token: Choosing the right OpenAI model on Amazon Bedrock for your workload (https://aws.amazon.com/blogs/machine-learning/beyond-the-price-per-token-choosing-the-right-openai-model-on-amazon-bedrock-for-your-workload/)
Leave a Reply