Tokens por segundo e latência: o que o benchmark de velocidade diz sobre rodar o modelo em produção?

Fala aí, beleza? "Esse modelo é rápido" é uma das frases mais inúteis que circulam em thread de lançamento

Rápido em quê? Rápido pra começar a responder, rápido pra cuspir texto depois que começou, ou rápido pra terminar a tarefa inteira? São três coisas diferentes, medidas de formas diferentes, e elas não andam juntas

Um benchmark de velocidade não devolve uma medida: devolve tempo até a primeira resposta, ritmo de geração e tempo total. Cada uma delas machuca um tipo específico de aplicação, e é bem comum o modelo campeão de uma ser mediano na outra

O recorte deste post é bem específico: quem vai colocar o modelo atrás de uma interface com um humano esperando na frente da tela. Se liga que aqui a métrica errada custa produto ruim, não só tabela feia 🙂

Tempo até o primeiro token, tokens por segundo e tempo total: qual métrica dói em qual aplicação

Antes de comparar modelo, vale entender o que cada número está contando. Vou usar as definições do Artificial Analysis e da documentação da Anthropic, porque elas são explícitas sobre o que entra e o que fica de fora de cada medida

Tempo até o primeiro token (TTFT): quanto tempo a tela fica vazia

O Artificial Analysis define o tempo até o primeiro token como o tempo em segundos entre enviar a requisição para o serviço e receber o primeiro token da resposta

A documentação da Anthropic descreve a mesma ideia pelo outro lado: TTFT mede o tempo até o modelo gerar o primeiro token da resposta, contado do envio do prompt. E ela é direta sobre onde isso importa, ou seja, aplicações interativas, chatbots e sistemas em tempo real

Os fatores que puxam esse número, segundo a própria Anthropic: tamanho do modelo, capacidade de hardware, condições de rede e complexidade do prompt

Agora o detalhe que derruba muita comparação ingênua

Em modelos de raciocínio, esse primeiro token é um token de raciocínio. Ou seja, o cronômetro para quando o modelo começa a PENSAR, não quando ele começa a responder o usuário. Por isso o Artificial Analysis publica também uma métrica separada, o time to first answer token, medida depois do tempo de "thinking"

Se o seu produto mostra a resposta pro usuário e não o raciocínio, é essa segunda métrica que descreve a sua tela em branco

Tem ainda um conceito irmão que a Anthropic chama de latência de base: o tempo que o modelo leva pra processar o prompt e gerar a resposta, sem considerar tokens de entrada e saída por segundo. Serve pra ter uma ideia geral da velocidade do modelo, não pra dimensionar uma interface

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Tokens por segundo: o ritmo depois que a resposta já começou

Aqui mora a confusão mais cara do assunto

A velocidade de saída em tokens por segundo, na definição do Artificial Analysis, é o número médio de tokens recebidos por segundo DEPOIS que o primeiro token chega

Leia de novo: depois

Ou seja, é ritmo de geração, não tempo total de resposta. Um modelo pode ter tokens por segundo excelente e ainda assim deixar o seu usuário olhando pro nada, porque o tempo até começar foi longo

A analogia que uso: é a diferença entre a velocidade máxima do carro e o tempo que ele leva pra sair da garagem. Se a garagem demora, a velocidade máxima consola pouco 😀

Onde tokens por segundo realmente manda é em resposta longa. Quando o modelo precisa produzir muito texto, o ritmo de geração vira o pedaço dominante do tempo, e aí a métrica descreve bem a experiência

Tempo total ponta a ponta: segundos para produzir 500 tokens de saída

Essa é a medida que mais se parece com o que o usuário sente

O Artificial Analysis chama de End-to-End Response Time: o tempo total para receber uma resposta completa, incluindo processamento da entrada, tempo de raciocínio do modelo e geração da resposta

Ela é publicada como "segundos para produzir 500 tokens de saída", e é calculada a partir do tempo até o primeiro token, do tempo de "thinking" (nos modelos de raciocínio) e da velocidade de saída

Repare que é uma métrica DERIVADA. Ela não é um quarto fenômeno independente, é a soma das outras com o raciocínio no meio

E como o raciocínio entra numa estimativa? A média de tokens de "reasoning" é calculada sobre um conjunto diverso de 60 prompts. Quando esse número médio não está disponível, assume-se 2.000 tokens de raciocínio

Guarde esse detalhe pro final, porque é ele que explica por que o tempo total publicado pode não bater com a sua carga real

Mapeando: qual delas é o seu SLA?

Aplicação interativa, tipo chatbot e assistente de código, se beneficia principalmente de baixo tempo até o primeiro token e baixa latência entre tokens, pra manter a sensação de resposta imediata. Não é throughput agregado que resolve isso, é o par TTFT + intervalo entre tokens

Geração de texto longo vive de tokens por segundo

Pipeline assíncrono, aquele que roda sem ninguém esperando, vive de tempo total (e de custo)

Três produtos, três métricas, três decisões de modelo diferentes

TTFT x tokens por segundo x tempo total: comparativo rápido

Repare numa linha dessa tabela: o streaming aparece na percepção, não no total. Já volto nisso

Como o Artificial Analysis mede: metodologia, janela e o que o número NÃO diz

Essa parte quase ninguém lê, e é ela que decide se o número serve pra você

Os valores publicados de desempenho são a mediana (P50) das últimas 72 horas, justamente pra refletir mudanças sustentadas de desempenho em vez de soluço momentâneo. A exceção é a carga de 100 mil tokens de entrada, testada uma vez por semana e representada como mediana (P50) dos últimos 14 dias

A frequência de coleta segue a mesma lógica: as cargas de 1k e 10k tokens de entrada e a carga de visão são testadas 8 vezes por dia, mais ou menos a cada 3 horas. A de 100k roda uma vez por semana

Cada rodada usa um prompt inédito, gerado no momento do teste e executado em todos os endpoints cobertos

E tem um teste que quase ninguém cita: uma vez por dia, em horário aleatório, são enviadas 10 requisições concorrentes com a carga de 1k tokens de entrada. Isso é separado do teste padrão de fluxo único feito 8 vezes por dia

Tome cuidado com esse ponto na hora de comparar. O número que você vê por padrão é de fluxo único, e a sua produção provavelmente não é de fluxo único…

Outro detalhe que muda leitura: a medição de velocidade padrão exibida hoje reflete prompts de 10 mil tokens de entrada (antes era 1 mil). As medições com 100 tokens de entrada foram descontinuadas, e as cargas de 1k, 10k e 100k continuam acessíveis nas páginas pelo menu "Prompt Options"

Ou seja: se você comparar um print antigo com a página de hoje, pode estar comparando cargas diferentes 😛

E aquela estimativa de raciocínio que citei lá em cima entra aqui de novo. O tempo total considera uma média de tokens de "reasoning" sobre 60 prompts, com fallback de 2.000 tokens quando a média não está disponível. Se a sua tarefa faz o modelo pensar muito mais (ou muito menos) que isso, o tempo total publicado descreve outra coisa que não a sua

Por fim, o limite declarado pela própria metodologia: o benchmark mede o desempenho ponta a ponta experimentado por clientes de serviços de inferência. Os resultados NÃO pretendem representar o desempenho máximo possível de uma plataforma de hardware, e sim o desempenho real observado entre provedores

Isso é ótimo pra escolher provedor, e ruim pra prever a sua carga específica

Onde o tempo total realmente aparece: um teste lado a lado no meu terminal

Vou trazer um caso concreto, porque teoria de métrica cansa

No vídeo do canal eu comparo o tempo de resposta da MESMA pergunta com e sem a skill FastContext, que delega a busca no contexto pra um agente separado. Rodei cada versão em um terminal, lado a lado, cronometrando na prática

A versão com a busca delegada respondeu em cerca de 40 segundos na minha máquina

A versão sem a skill, no outro terminal, passou de 50 segundos

Aí veio a crítica óbvia, que eu mesmo antecipei no vídeo: os dois testes não usavam exatamente o mesmo prompt. Então refiz a comparação com o texto idêntico, mudando só uma vírgula e o pedido pra usar a skill. Mesmo nesse teste mais justo, a versão com delegação terminou bem antes, com uma vantagem de aproximadamente 40 e poucos segundos a favor dela

E a pergunta era simples! Na minha visão, quanto maior a complexidade da tarefa, maior tende a ser o ganho de tempo e de tokens

O porquê importa mais que o cronômetro aqui. Sem delegação, o modelo mais caro faz sozinho o grep, o glob e a leitura de arquivo, e cada busca dessas vira histórico que polui o raciocínio seguinte. Com a busca delegada, o trabalho fica dividido: um modelo menor procura no código, e o modelo principal só monta a resposta final

Repare no que isso diz sobre métrica

Eu não estava medindo tokens por segundo. Nenhuma das duas execuções ficou mais "rápida por token": o que mudou foi quanto trabalho e quanto contexto entrou no caminho até a resposta. Ou seja, reduzir tokens de entrada é alavanca de latência tanto quanto trocar de modelo

Quem sente o problema no dia a dia mede tempo total de tarefa, não ritmo de geração

Dois avisos honestos, porque o ganho não vem de graça

O primeiro: exige configuração prévia da skill e do modelo de busca pra deixar tudo rodando. O segundo: a ativação implícita não é garantida, então prefiro acionar de forma explícita, por slash command ou por uma regra no projeto, pra o comportamento ser previsível

E, sobre o modelo que faz a busca, trato como escolha de custo por tarefa: aponto pra um modelo mais barato que eu já assino, um gratuito ou um local. É o mesmo raciocínio de quando comparo quanto a conta de tokens cai trocando o modelo de uma etapa específica do fluxo

Deixando claro o que isso é e o que não é: observação pontual, em uma máquina, com uma pergunta. Não é benchmark controlado, não tem mediana de 72 horas, não tem prompt inédito por rodada. Serve como sinal de onde o tempo vai, não como número pra tabela

Pra começar do zero no assunto de desperdício de contexto e no efeito disso no tempo de resposta, este vídeo do canal dá a visão geral do tema e mostra a comparação rodando. Bora ver na prática?

E, já que o assunto é dividir trabalho entre modelos, tem um caso primo desse que é usar um segundo agente para conferir o achado do primeiro: mesma lógica de separar quem faz de quem valida

O que fazer quando o número não fecha: alavancas para cortar latência em produção

Beleza, você mediu e o tempo não cabe no seu produto. O que dá pra puxar? Vou amarrar cada alavanca à métrica que ela move, porque puxar a alavanca errada é o esporte nacional aqui

1. Trocar por um modelo mais rápido. É a primeira recomendação da documentação da Anthropic pra reduzir latência, e ela cita o Claude Haiku 4.5. Ataca TTFT e tempo total ao mesmo tempo. O erro comum deste passo: trocar o modelo do fluxo inteiro quando só uma etapa (busca, classificação, extração) precisava de velocidade

2. Reduzir tokens de prompt e de saída. Também está na lista de alavancas da Anthropic, e é a mais ignorada. Prompt menor mexe no TTFT (a complexidade do prompt é um dos fatores citados), saída menor mexe no tempo total. O erro comum: cortar o prompt e esquecer da saída, ou vice-versa

3. Ligar streaming. O streaming permite que o modelo comece a enviar a resposta antes de completá-la, melhorando a responsividade PERCEBIDA porque o usuário vê a saída em tempo real. Guarde bem: ele ataca a percepção de espera, não o tempo total de geração. O erro comum deste passo é justamente esse, achar que ligou streaming e resolveu latência. Não resolveu, você mudou o que o usuário sente enquanto espera

4. Usar prompt caching. Na API da Anthropic, prefixos de prompt são cacheados com o parâmetro cache_control, via cache automático ou breakpoints explícitos, com TTL de 5 minutos ou de 1 hora. O cache pode reduzir a latência em até 85% para prompts longos e o custo em até 90%. É a alavanca com melhor relação esforço/resultado quando você tem um prefixo grande e estável (system prompt gordo, documentação, esquema de ferramentas)

5. Controlar a profundidade de raciocínio. Orçamentos maiores de raciocínio permitem raciocínio mais completo, com retornos decrescentes que dependem da tarefa e ao custo de latência maior. É troca direta, sem almoço grátis. E o jeito de controlar mudou: o extended thinking com thinking.type "enabled" mais budget_tokens está descontinuado nos modelos Claude 4.6 (as requisições ainda funcionam), e nos modelos Claude 4.7 e posteriores ele NÃO é suportado, com requisições contendo budget_tokens sendo rejeitadas com erro 400. O parâmetro effort substitui o budget_tokens pra controlar profundidade nos modelos novos, e os modelos 4.6 usam thinking adaptativo (thinking: {type: "adaptive"}). O effort não exige mais header beta e passou a suportar o Claude Opus 4.6

6. Se precisa cortar latência com thinking adaptativo, baixe o nível. A orientação é reduzir o effort ou usar max_tokens como limite rígido junto do thinking adaptativo. O max_tokens continua sendo o teto duro do total de saída. O erro comum deste passo: tentar segurar o raciocínio com budget_tokens num modelo que já não aceita, e comer o 400

7. Mandar pro lote o que ninguém está esperando. A Message Batches API processa requisições de forma assíncrona a 50% do preço padrão da API. Os resultados ficam disponíveis quando todas as mensagens terminam ou após 24 horas, o que vier primeiro, e lotes expiram se não completarem em 24 horas. A maioria dos lotes termina em até 1 hora, mas o compromisso formal é 24 horas, então dimensione o seu produto pelas 24 e não pela 1. Tem ainda uma orientação específica: para orçamentos de thinking acima de 32k tokens, use processamento em lote, porque requisições muito longas podem estourar timeouts de sistema e limites de conexão aberta

Repare que só a alavanca 3 mexe em percepção. Todas as outras mexem em tempo de verdade

Vale escolher modelo por tokens por segundo?

Veredito honesto: sozinho, não

Tokens por segundo é um número ruim pra decidir modelo, e não é porque ele seja impreciso. É porque ele descreve ritmo DEPOIS que a resposta começou. Ele literalmente não fala sobre o pedaço da experiência em que o seu usuário está olhando pra uma tela vazia

Pra interface com gente esperando, quem manda é o par tempo até o primeiro token + latência entre tokens. Streaming entra pra mudar a percepção, e é uma mudança real de produto, só não confunda com redução de tempo total

Pra pipeline assíncrono, quem manda é tempo total e custo. Aí tokens por segundo volta a importar (porque ele compõe o total), e o batch entra como decisão de arquitetura, não como gambiarra

E o benchmark público, serve ou não serve?

Serve muito pra comparar provedores em condições reais, que é exatamente o que ele se propõe a fazer: desempenho ponta a ponta experimentado por clientes de serviços de inferência, com mediana de 72 horas e prompt novo a cada rodada. Isso é honesto e é difícil de reproduzir sozinho

Não serve pra prever o desempenho da SUA carga. A metodologia mesmo avisa que os resultados não pretendem representar o desempenho máximo possível de uma plataforma de hardware. Some a isso o padrão de fluxo único, a carga de 10k tokens de entrada e a estimativa de raciocínio com fallback de 2.000 tokens, e fica claro por que o seu número vai dar diferente

Usar benchmark público pra ranquear provedor: massa

Usar benchmark público como capacity planning: aí não 🙂

Conclusão

Recapitulando o que interessa: velocidade não é um número, são três

Tempo até o primeiro token é a métrica de quem tem usuário esperando o início da resposta. Tokens por segundo é o ritmo depois que a resposta começou, e domina quando a saída é longa. Tempo total ponta a ponta é a soma com o raciocínio no meio, e é a métrica de quem roda tarefa sem ninguém olhando

O próximo passo é bem concreto, e ele vem ANTES de abrir qualquer tabela comparativa

Primeiro, defina qual dessas três é o SLA do seu produto. Uma só, a que dói de verdade no seu caso

Depois, meça a sua própria carga: seu prompt real, seu tamanho de entrada real, seu volume de saída real. O benchmark público te diz como os provedores se comportam entre si, não como o seu sistema se comporta

Só então ligue as alavancas na ordem que corresponde à métrica escolhida: prompt caching e prompt menor pra TTFT, streaming pra percepção, effort e max_tokens pra segurar raciocínio, batch pro que pode esperar

E, se o seu gargalo for parecido com o que eu cronometrei no terminal, comece cortando o que entra no contexto antes de sair trocando de modelo…

até o próximo post! 😀