Benchmark LLM: velocidade vai além de tokens por segundo

O que a taxa de tokens por segundo mede?

A taxa de tokens de saída por segundo mede a rapidez com que um LLM entrega os tokens gerados depois da chegada do primeiro token. Um grande modelo de linguagem, ou LLM, processa texto em tokens: unidades que podem ser palavras, partes de palavras ou sinais de pontuação. Tokens não equivalem a uma contagem universal de palavras. A definição da Cerebras deixa essa diferença explícita.

Imagine que você vai a uma biblioteca buscar uma sequência de livros. Esperar a porta abrir é diferente do ritmo em que os livros são entregues, e os dois fatores determinam quando você poderá sair com tudo de que precisa. Uma entrega rápida não apaga uma longa espera do lado de fora.

Na aplicação, mantenha estas medições separadas:

Esses intervalos seguem as definições de métricas da Artificial Analysis. O primeiro token de raciocínio pode chegar antes do primeiro token de resposta; por isso, esses tempos precisam de nomes distintos.

A latência de ponta a ponta da aplicação começa na ação do usuário e termina em um resultado útil. Para um assistente de voz, isso pode significar fala audível; para um agente, uma ação concluída. Busca de informações, execução de ferramentas, síntese de áudio e atualizações da interface podem ocorrer fora da requisição ao modelo. Instrumente também esse percurso completo.

As etapas subjacentes são prefill, o processamento do prompt, e decode, a geração da continuação. O guia sobre inferência de LLMs acompanha esse trabalho pelo sistema que atende às requisições.

Benchmark LLM: por que uma taxa isolada engana

Um resultado de velocidade descreve uma carga de trabalho em um endpoint, não uma propriedade do modelo que vale em qualquer situação. Se o trabalho ou as condições de atendimento mudam, a comparação também muda.

Tamanho do prompt e contexto em cache

Um chat de suporte com uma pergunta curta é diferente do mesmo chat com um histórico longo e documentos de políticas recuperados por busca. Uma entrada maior muda o trabalho realizado antes da resposta. A Groq aponta o tamanho da entrada como um dos fatores que afetam o TTFT em seu guia de latência.

Registre o tamanho do prompt e o estado do cache em cada teste. O guia sobre KV cache explica o estado de atenção armazenado durante a geração e a relação entre reutilização de prompts e cache. Um prompt repetido, já com o cache aquecido, não deve representar uma nova conversa com um cliente sem que essa diferença fique clara.

Raciocínio antes da resposta

Um modelo de raciocínio pode produzir tokens intermediários antes de entregar a resposta. Uma geração rápida não revela quanto raciocínio ele fará. Verifique se a velocidade informada inclui esse fluxo e se a medição do tempo até o primeiro token termina no raciocínio ou no texto da resposta.

Em um assistente de reservas, o evento útil é uma resposta utilizável ou uma chamada de ferramenta. Um indicador visual de que o sistema está pensando pode confirmar o recebimento da solicitação, mas não conclui a reserva.

Processamento em lote e requisições simultâneas

O processamento em lote agrupa trabalho para aproveitar melhor o hardware. A vazão agregada contabiliza a saída de várias requisições; a velocidade por usuário descreve o fluxo que chega a uma requisição individual. A Cerebras observa que o processamento em lote pode aumentar a vazão e, ao mesmo tempo, acrescentar espera. Fonte: explicação da Cerebras sobre vazão.

Quem opera o sistema precisa saber: cada conversa continua avançando quando chegam outras conversas? Meça um tráfego simultâneo representativo, incluindo requisições que falham e novas tentativas. Um bom resultado em um endpoint que estava ocioso não responde a essa pergunta.

Região e entrega da resposta

A localização da aplicação e do endpoint que atende às requisições afeta o atraso de rede. A Groq distingue os tempos medidos no servidor da latência percebida pelo cliente em suas orientações para análise de rede.

Meça a partir da região em que seu backend roda. Se a aplicação repassa o streaming ao navegador por um proxy, acrescente uma medição no navegador: o acúmulo em buffers entre esses pontos pode fazer uma resposta contínua na origem chegar em rajadas. Corrigir esse caminho pode fazer mais diferença do que trocar de modelo.

Tokens por segundo por GPU

Uma GPU, o acelerador que executa a inferência, não tem uma taxa única e significativa de tokens por segundo que independa do modelo e da carga de trabalho. Uma comparação de hardware precisa trazer, ao lado do resultado, o modelo, a precisão numérica, o contexto, a configuração de atendimento e a carga simultânea.

A quantização reduz a precisão numérica para economizar memória; os efeitos sobre velocidade e qualidade dependem da implementação. A Cerebras documenta essa distinção em sua explicação sobre compressão de modelos. Consulte o guia de quantização de LLMs ao comparar implantações com modelos comprimidos e mantenha uma avaliação da qualidade das respostas junto com as medições de tempo.

Como os fornecedores apresentam suas velocidades

Trate as velocidades publicadas como declarações atribuídas ao fornecedor, sempre associadas a um modelo e a uma data. As páginas dos fornecedores a seguir foram verificadas em 24 de outubro de 2026. Os números são deles; não são medições realizadas para este artigo.

Cerebras: velocidade publicada com ressalva sobre a implantação

A Cerebras, fornecedora de inferência, lista o OpenAI GPT-OSS 120B com “~3000 tokens/s” na tabela Developer. A mesma página informa que o desempenho varia conforme o modelo e a configuração e descreve o acesso Developer como voltado à avaliação, não à produção. Fonte: preços da Cerebras.

A pergunta relevante é se a implantação que você pode contratar atende à sua carga de trabalho com a agilidade e a capacidade necessárias. A tabela, sozinha, não responde.

Tokens por segundo na Groq: confira a linha do modelo

A Groq, fornecedora de inferência, lista o OpenAI GPT-OSS 120B com “500” na coluna “SPEED (T/SEC)” de sua tabela de modelos compatíveis. Esse é o número publicado pela Groq para essa linha. Fonte: modelos compatíveis da Groq.

Essas tabelas não estabelecem uma proporção entre as velocidades dos fornecedores dentro de uma aplicação. Para fazer essa afirmação, ainda é preciso usar prompts, configurações de raciocínio, contagem de tokens, carga e intervalos de medição equivalentes.

Para decidir entre velocidade e custo, compare o preço de uma tarefa bem-sucedida e a capacidade necessária com o guia de preços da Cerebras e o guia de preços da Groq.

Onde encontrar medições independentes

A Artificial Analysis, serviço independente de benchmarks, é um ponto de partida útil para comparar modelos e fornecedores de inferência. Abra seu ranking de fornecedores e examine o endpoint e a carga de trabalho por trás de cada resultado.

Sua metodologia de avaliação de desempenho especifica atualmente:

• Uma carga de trabalho padrão de aproximadamente 10,000 tokens de entrada e pelo menos 1,500 tokens de resposta.
• Resultados representados pela mediana das últimas 72 horas para as cargas de trabalho habituais.
• Um servidor principal de testes na zona us-central1-a do Google Cloud.
• Contagens de desempenho normalizadas com o200k_base, em vez do tokenizador nativo de cada modelo.

Isso oferece uma referência comum, não uma promessa sobre a sua aplicação. Confira o tamanho do prompt, o endpoint, o modo de raciocínio e a data antes de comparar resultados. Prompts mais longos podem alterar tanto a espera pelo primeiro token quanto a velocidade de saída.

Para modelos que ocultam parte dos tokens de raciocínio, a Artificial Analysis calcula a velocidade de saída com base nos últimos 80% dos blocos de resposta. O script simples a seguir não reproduz esse método nem a carga completa do benchmark. Ele mede o fluxo de texto observado por você.

Como medir o streaming da sua aplicação

Meça no cliente que recebe a resposta e conte tokens de texto, não eventos do streaming. Um evento pode não conter texto ou trazer um bloco inteiro; contar eventos resulta em blocos por segundo.

O exemplo em Python a seguir usa a API de streaming da Groq e o tiktoken, um tokenizador de texto. Ele informa a espera pelo primeiro bloco de texto, o tempo da requisição até o último texto, o tempo até a conclusão do streaming e uma estimativa de tokens de saída normalizados por segundo.

Instale as dependências:

python3 -m pip install groq tiktoken

Defina GROQ_API_KEY no ambiente. Em GROQ_MODEL, informe um modelo de texto sem raciocínio que esteja disponível na sua conta e conste na lista de modelos compatíveis da Groq. Coloque um prompt representativo da aplicação em prompt.txt. Salve o código como measure_stream.py e execute python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

O SDK da Groq permite desativar novas tentativas automáticas. O exemplo usa essa opção para evitar que a espera por novas tentativas entre, sem indicação, em uma amostra que acaba sendo registrada como bem-sucedida; uma requisição que falha deve ser registrada como falha.

O cálculo da taxa exclui o primeiro bloco de texto tanto da contagem de tokens quanto do intervalo de entrega. Ele segue a fórmula baseada em blocos das definições da Artificial Analysis. Também ignora metadados finais ao determinar o momento da chegada do último texto.

Use esse exemplo para texto simples. Um fluxo de raciocínio, argumentos de chamadas de ferramenta ou áudio exige um tratamento específico para seus tipos de evento e uma definição da primeira saída útil. Nas comparações, mantenha o prompt e as configurações, registre o tamanho da saída e repita as medições a partir da região de implantação, com carga representativa. Guarde os resultados típicos e os lentos; não transforme a amostra mais rápida em garantia.

O que calculadoras e simuladores conseguem mostrar?

Uma ferramenta de planejamento pode ilustrar uma hipótese de tempo; ela não descobre o atraso do seu endpoint.

Simulador de tokens por segundo

Use um simulador para discutir se uma interface de chat deve mostrar o texto à medida que ele chega ou esperar por um objeto completo. Depois, valide esse design com um streaming observado na prática. Uma taxa simulada constante não permite saber se a resposta real faz pausas, chega em rajadas ou fica esperando uma ferramenta.

Para uma resposta de texto concluída, a conta é direta: o tempo da requisição até o último texto é igual à espera inicial mais o intervalo entre o primeiro e o último texto. O script mede os dois intervalos em vez de deduzi-los de uma taxa anunciada.

Qual é uma boa taxa de tokens por segundo?

A meta útil depende dos pontos de espera da tarefa. Para defini-la, responda a perguntas sobre a experiência que você está construindo.

Para quem desenvolve aplicações de voz: depois de terminar uma frase, quanto tempo a pessoa ao telefone espera até ouvir uma resposta útil? A fala pode começar antes que a resposta inteira esteja escrita? O buffer de áudio chega a esvaziar? A pessoa pode interromper? Se o silêncio ocorre antes do início do texto, uma taxa de decodificação maior pode deixar o principal problema intacto.

Para quem desenvolve chats: o usuário espera pela primeira frase útil, pela explicação completa ou por um resultado estruturado válido? A interface consegue exibir uma saída parcial? Uma resposta de suporte e um relatório exportável têm eventos de conclusão diferentes. Meça o evento de que sua interface precisa.

Para quem opera agentes: quanto da tarefa corresponde à geração do modelo e quanto à execução de ferramentas? Uma resposta mais rápida preserva os argumentos corretos das ferramentas e o sucesso da tarefa? A próxima etapa depende da saída completa? Melhorar o intervalo errado pode deixar o tempo total do fluxo de trabalho quase inalterado.

Para quem contrata um fornecedor: a implantação proposta consegue manter a experiência necessária com seu tráfego, a partir da sua região e com seus prompts? O resultado informado é típico dessa implantação? O que acontece quando as requisições falham ou a capacidade está ocupada?

Aja quando os rastros de execução mostrarem que os usuários esperam pela geração ou pela primeira resposta útil. Espere para migrar de fornecedor enquanto o atraso dominante não tiver sido isolado. Uma tarefa em segundo plano que já termina dentro do prazo pouco ganha com uma taxa anunciada mais alta, a menos que a vazão ou o custo por tarefa bem-sucedida mude a decisão.

Onde está o exagero nas promessas de velocidade dos LLMs?

O maior exagero é afirmar que a taxa de saída mais alta identifica o melhor endpoint para uma aplicação. A velocidade não comprova a qualidade da resposta, a validade da saída nem o uso bem-sucedido de ferramentas.

Todo endpoint rápido esbarra na aplicação ao seu redor. Texto gerado mais depressa não corrige uma chamada lenta ao banco de dados, um raciocínio desnecessariamente longo ou uma resposta que não passa na validação. Da mesma forma, um excelente tempo até o primeiro token pode esconder um fluxo que trava antes de entregar algo útil ao usuário.

Mantenha a velocidade na avaliação, mas considere a tarefa concluída quando houver um resultado correto e utilizável.

Perguntas frequentes

O próximo passo na sua aplicação

Na próxima iteração, escolha uma interação de voz, um prompt de chat ou uma tarefa de agente que represente o uso real e defina o que torna seu resultado utilizável. Instrumente esse evento junto com a primeira saída e a conclusão do streaming. Compare os endpoints candidatos na mesma tarefa, analise as falhas e otimize o intervalo que mantém o usuário esperando.

Para receber guias práticos sobre como criar aplicações úteis de IA, assine a newsletter.