Velocidade de LLM sem mudança de preço: quando o preço congela, a rota muda

Sete modelos ficaram mais rápidos em uma semana, nenhum ficou mais caro, e essa combinação é mais desconfortável do que parece para quem decide rota de LLM em produção. São sete modelos com leitura de velocidade, dentro dos dez que o painel rastreia para preço. A Artificial Analysis, no painel lido em 2026-09-21, registra ganho de velocidade de saída entre 13,0% e 26,0% em quase todos os modelos que acompanha. No mesmo período, o preço por milhão de tokens não se moveu em nenhum dos dez modelos rastreados. Quando o custo por token para de discriminar, o empate deixa de ser resolvido por preço, e a variável que sobra é o tempo de resposta.

A leitura corrente é que uma métrica de velocidade de LLM não muda contrato nenhum. Muda, e por um motivo contábil. Uma rota escolhida por preço só é ótima enquanto o preço diferencia as opções. No dia em que dois modelos custam o mesmo por milhão, a conta empata e quem decide é a latência, medida no horário de pico, não na média do painel.

O achado em uma frase: com o preço por milhão de tokens plano, a latência e a variância de resposta passam a ser a variável de decisão da rota, e um gateway que só compara preço deixa de decidir qualquer coisa.

Como os dados foram coletados?

Os números vêm de duas leituras do painel público da Artificial Analysis em tokens por segundo, uma em 2026-09-14 e outra em 2026-09-21, no endereço artificialanalysis.ai/leaderboards/models. São sete modelos com leitura de velocidade, dentro dos dez que o painel rastreia para preço, e os sete aparecem em ambas as leituras. A variação percentual compara as duas fotos por modelo, e o preço por milhão de tokens foi conferido no mesmo painel sem alteração em nenhum dos dez.

Duas fotografias semanais não são uma série temporal. São uma foto contra outra. Um salto simultâneo em quase todos os modelos é igualmente compatível com uma mudança na janela de medição, um ajuste de método no painel, ou uma rodada de otimização de inferência nos provedores. Nada aqui distingue essas hipóteses, e a peça não finge que distingue. O que se pode afirmar com o dado em mãos é mais estreito e ainda útil: houve ganho de velocidade de saída medido, o preço ficou plano, e a combinação muda a pergunta que quem roteia precisa responder.

Cabe um recorte técnico que o painel não resolve sozinho. Tokens por segundo é a velocidade de geração, o tempo entre o primeiro e o último token de saída. Em uma chamada de prompt curto, o que o usuário sente é outra coisa: prefill, fila de espera no provedor e latência de rede dominam o total, e o ganho de geração aparece diluído. Medir tokens por segundo e chamar isso de latência é a confusão que faz uma decisão de rota parecer correta no gráfico e errada no produto.

Quanto os modelos ganharam de velocidade em uma semana?

A resposta curta é que o ganho varia de 13,0% a 26,0% entre os modelos rastreados, e o maior salto percentual não é o maior ganho absoluto. O GPT-5.6 Sol subiu 26,0% sobre uma base baixa de velocidade. Já o Gemini 3.8 Flash, que já era o mais rápido da lista, somou 53,4 tokens por segundo em termos absolutos, quase um segundo modelo inteiro de diferença no mesmo intervalo de tempo.

A tabela abaixo traz o par de valores por modelo. Nenhuma linha de preço aparece porque nenhuma mudou: a coluna de variação seria uma sequência de zeros, e essa é exatamente a informação que move a tese.

O padrão que salta da tabela não é a média. É a assimetria. O modelo mais rápido da lista ficou 19,2% mais rápido, e o segundo mais rápido, 13,0%, o que significa que uma rota escolhida por velocidade bruta em 14 de setembro continua sendo a escolha por velocidade bruta em 21 de setembro, sem que ninguém precise trocar nada. O ganho agregado não redistribuiu o ranking de velocidade. Ele manteve a ordem e levantou todo mundo na mesma direção, que é o comportamento que motiva a ressalva de janela de medição.

Por que o preço plano muda a lógica de decisão da rota?

Porque o critério de desempate desaparece. Uma rota por custo funciona comparando preço de entrada e de saída por milhão de tokens. Se dois modelos custam o mesmo, esse critério retorna empate, e o sistema que decide por preço precisa de um segundo critério que ele talvez nunca tenha implementado. O trabalho que guia a promoção de rota por evidência de tráfego já existe e está descrito em como decidir a rota de LLM com evidência de tráfego real, mas ele precisa da métrica certa para medir. Quando o preço está plano, essa métrica é tempo de resposta.

O caso oposto, preço em movimento, tem um post próprio neste blog: o que fazer quando o preço do token muda trata exatamente do caso em que o custo volta a discriminar. Os dois regimes se complementam. Quando o preço se move, a conta manda. Quando ele congela, a conta empata e a latência assume. Nenhuma empresa opera em um dos dois regimes para sempre, e a arquitetura que aguenta a troca é a que já mede as duas variáveis o tempo todo, em vez de descobrir uma no dia em que ela passa a decidir.

Há uma razão para desconfiar da média de velocidade como critério. A distribuição de latência de um provedor de LLM tem cauda longa, e o valor que o usuário percebe está na cauda, não no centro. Um modelo com média de 68 tokens por segundo pode ter um p99 de quatro segundos em uma tarde de pico, enquanto outro com média menor nunca passa de dois segundos. A média esconde justamente o evento que estraga a experiência. Quem decide rota por número de painel decide por uma estatística que o usuário nunca vê.

O que exatamente deve ser medido, então?

Três coisas, e nenhuma delas é a média de tokens por segundo do painel. Tempo até o primeiro token, que define a sensação de resposta imediata. Tempo total até o último token, que define se a tarefa termina. E a distribuição dessas duas métricas por horário, com p90 e p95 explícitos, porque é na cauda que a decisão errada custa caro.

1. Tempo até o primeiro token (TTFT). O intervalo entre o envio da requisição e o primeiro fragmento de saída. Domina a percepção em prompts curtos e é o que a média de tokens por segundo ignora por construção.
2. Tempo total até o último token. O que decide se uma tarefa longa, como gerar um relatório ou revisar um arquivo de código, termina dentro do orçamento de tempo da operação.
3. p90 e p95 por janela horária. A métrica que separa um provedor estável de um provedor que funciona bem às dez da manhã e mal às três da tarde, quando a fila enche.

O detalhe que quase ninguém instrumenta é a variância entre provedores no mesmo modelo. O mesmo modelo servido por dois provedores diferentes tem duas curvas de latência distintas, porque a configuração de hardware, a política de batching e a carga da região não são as mesmas. Escolher o modelo não é escolher a rota, do mesmo jeito que escolher o destino não é escolher a estrada. O painel da Artificial Analysis mede um provedor de referência, e tratar esse número como se valesse para todos os provedores é um erro que só aparece na produção.

Vale declarar onde este texto discorda da leitura mais comum. A leitura corrente trata latência como uma métrica de experiência do usuário. Isso subestima o problema. Latência, quando o preço é plano, é uma métrica de risco operacional: uma cauda longa em um provedor pode estourar o timeout de um passo de agente, queimar uma tentativa inteira e reprocessar a chamada, e o custo desse reprocessamento aparece na fatura por um caminho que ninguém mapeou. A economia que o preço plano prometia é devolvida em retrabalho.

O gateway que só compara preço decide algo quando o preço é igual?

Decide nada. E esse é o ponto em que a camada de gateway deixa de ser um detalhe de infraestrutura e vira a peça que sustenta a decisão. O Nexforce Router é um gateway de LLM que roteia entre mais de trezentos modelos por uma única API, e o roteamento inteligente dele considera custo, desempenho, latência e contexto da requisição. Quando o custo empata, é essa combinação que continua produzindo uma decisão em vez de um empate técnico.

O que importa não é a lista de recursos, é a ordem em que eles operam sob preço plano. Medir latência por provedor e por modelo, aplicar o roteamento por desempenho medido, e fazer failover automático quando um provedor fica lento no meio da janela, com fallback configurável para um modelo equivalente. O failover deixa de ser uma rede de segurança contra queda e passa a ser uma resposta a degradação de tempo de resposta, que é um modo de falha mais silencioso e mais frequente do que a indisponibilidade total. O gateway também mantém cache de respostas e embeddings, que ataca a latência por outro caminho: a resposta mais rápida é a que não precisa ser gerada de novo.

Há um segundo trabalho que o gateway faz quando a rota passa a ser decidida por tempo de resposta. Ele precisa provar depois por que decidiu o que decidiu. Uma trilha auditável de cada chamada, com o provedor, o modelo e a latência registrados, é o que permite responder em uma reunião de operação se a rota degradou na terça à tarde ou se foi sempre assim. Sem esse registro, a decisão de rota vira folclore. Com ele, vira insumo para a próxima promoção de rota.

Um ponto que merece insistência: adicionar latência como critério não aposenta o controle de custo. O teto de gasto continua valendo e continua sendo o que impede que uma rota mais rápida e mais cara consuma o orçamento. O orçamento por unidade, tratado em identidade do chamador no gateway e orçamento por unidade, é o que mantém a decisão de latência dentro de um limite econômico. Roteamento por latência sem teto de gasto é uma forma elegante de trocar uma economia de 50% por uma fatura maior.

Onde entra o custo por tarefa quando o preço empata?

Entra como a unidade que reconcilia as duas métricas. Preço por milhão de tokens é uma unidade de insumo. Custo por tarefa concluída é uma unidade de resultado, e é ela que captura o efeito do retrabalho. Um modelo barato e lento que estoura o timeout e obriga a uma segunda tentativa pode custar mais por tarefa do que um modelo caro e rápido que fecha na primeira chamada. A análise de o custo por tarefa decide a rota aprofunda essa unidade, e ela é o juiz final quando o preço por token empata.

A consequência prática é uma inversão de prioridade. A prioridade inverte. Em um painel por preço, o modelo caro é o suspeito padrão. Em um painel por custo por tarefa, com preço plano e latência em jogo, o modelo que parece caro pode ser o mais barato da lista, porque termina a tarefa e não devolve o problema para a fila. Medir por tarefa é medir o que a empresa realmente paga.

Como decidir a rota quando o preço não decide?

Sequência concreta, na ordem em que a decisão se resolve:

1. Confirmar o empate de preço no painel, por modelo e por provedor, antes de tratar latência como desempate. Se o preço ainda discrimina, a conta manda e a latência é secundária.
2. Instrumentar TTFT, tempo total e p95 por horário, por provedor e por modelo, no próprio tráfego de produção. Número de painel de terceiro é ponto de partida, nunca critério final.
3. Definir o limite de tempo que a tarefa tolera antes de falhar. É esse limite, não a média, que transforma latência em regra de rota.
4. Promover a rota por evidência acumulada, com failover configurado para o modelo equivalente mais rápido disponível no momento da degradação.
5. Manter o teto de gasto ativo por chave ou por projeto, para que a rota por latência não vire uma conta sem freio.

O erro mais comum nessa sequência é pular o passo dois e decidir com o número do painel. O painel não é a empresa. O painel mede um provedor de referência em uma janela fixa. O tráfego da empresa mede o provedor que ela realmente usa, na hora em que ela realmente usa, com a carga que ela mesma coloca naquele provedor ao longo do dia. A diferença entre os dois é onde mora a decisão.

O que muda para quem opera LLM em produção?

Muda a pergunta, não a ferramenta. A pergunta deixa de ser qual modelo é o mais barato por milhão e passa a ser qual modelo fecha a tarefa dentro do tempo que a operação tolera, ao menor custo por tarefa concluída. Essa pergunta não tem resposta de painel. Tem resposta de medição contínua na própria rota, e ela só existe se a camada que decide estiver medindo tempo de resposta o tempo todo, e não só quando alguém abre o gráfico de velocidade.

O dado da semana reforça a tese e a limita ao mesmo tempo. Os ganhos de 13,0% a 26,0% são reais como leitura, e a ressalva de janela de medição continua de pé. Um time que decide rota tratando esses números como sentença trata uma foto de sete dias como se fosse um regime permanente. Um time que mede o próprio tráfego, ao contrário, usa a foto apenas como sinal e o dado próprio como critério de decisão. O segundo time não depende disso. Ele não precisa saber se o salto veio do provedor ou de um ajuste na janela de medição, porque a decisão dele se sustenta no próprio tráfego de qualquer forma.

É por isso que a peça pousa no gateway. Roteamento por latência não é um recurso que se liga. É uma postura de medir, decidir e reverter em cima de um dado que muda toda semana. O preço plano não é o fim da otimização de custo. É o começo da otimização de tempo, e ela só funciona se a camada de decisão estiver olhando para o relógio, não só para a fatura.

Perguntas frequentes

O que significa preço por milhão de tokens plano? Significa que os modelos rastreados mantiveram o mesmo preço de entrada e de saída por milhão de tokens entre as duas leituras, em 2026-09-14 e 2026-09-21. Sem diferença de preço, o critério de custo empata entre opções de velocidade diferente, e o desempate passa a vir do tempo de resposta.

Velocidade de saída em tokens por segundo é a mesma coisa que latência? Não é a mesma coisa. Tokens por segundo mede a velocidade de geração entre o primeiro e o último token. Latência percebida inclui o tempo até o primeiro token, a fila no provedor e a rede. Em prompts curtos, a latência percebida é dominada por esses outros fatores, e o ganho de geração aparece diluído.

Por que uma mudança de janela de medição importa para esta análise? Porque duas leituras semanais não distinguem um ganho real de velocidade de um ajuste no método do painel. Um salto simultâneo em quase todos os modelos é compatível com as duas hipóteses, e nenhuma empresa deveria trocar a arquitetura de rota com base em duas fotos. A ressalva é parte do achado, não uma nota de rodapé.

O roteamento por latência substitui o controle de custo? Não. O teto de gasto por chave, por agente ou por projeto continua ativo e é o que impede que uma rota rápida e cara consuma o orçamento. Latência e custo por tarefa operam juntos: a latência decide entre opções de mesmo preço, e o teto de gasto impõe o limite econômico da decisão.

Quantos provedores o mesmo modelo pode ter, e isso afeta a medição? O mesmo modelo pode ser servido por vários provedores, e cada um tem curva de latência própria por hardware, batching e região. O painel de terceiro mede um provedor de referência. A medição que decide deve vir do provedor que a empresa de fato usa, no horário em que ela usa.

Referências e Leitura Complementar

• Artificial Analysis, leaderboards de modelos, leitura de 2026-09-21, fonte primária dos dados de tokens por segundo.
• Nexforce Router, gateway de LLM com roteamento inteligente, failover automático e observabilidade de chamadas.
• Como decidir a rota de LLM com evidência de tráfego real, o método de promoção de rota por dado próprio.
• O que fazer quando o preço do token muda, o caso oposto, com preço em movimento.
• O custo por tarefa decide a rota, a unidade de decisão quando o preço por token empata.

Próximo passo: medir o relógio, não só a fatura

O dado de 2026-09-21 diz que o preço parou e a velocidade subiu. O que ele não diz, e nenhum painel de terceiro diz, é o tempo de resposta do provedor que a sua operação usa às três da tarde de uma terça. Esse número mora no seu tráfego, e a camada que decide a rota é onde ele precisa ser capturado e transformado em regra. Enquanto o preço por milhão estiver plano, quem mede tempo de resposta decide; quem só compara preço empata. O relógio decide. Para ver como o Nexforce Router trata latência, falha e custo na mesma decisão, a página do produto é o ponto de partida.