LLM Latência Benchmark por Casos de Uso
We benchmarked 11 top large language models with a total of 1,320 requests, splitting reasoning and non-reasoning models, and measured first-token latency, per-token latency, and overall response time.
Você pode encontrar detalhes sobre como medimos a latência aqui.
Tempo de resposta ponta a ponta por model
LLM Latência Benchmark Resultados
Relatamos os models de raciocínio e sem raciocínio separadamente. Os models de raciocínio passam vários segundos pensando antes da primeira resposta visível, portanto compará-los diretamente com models sem raciocínio em latência seria enganoso. Alguns models também mudam o comportamento por tarefa: GPT-5.2 responde a Q&A sem raciocinar, mas raciocina nos prompts de codificação.
Caso de resposta curta (Q&A)
No caso curto, o que importa é a rapidez com que o primeiro token de resposta aparece, já que toda a resposta é apenas uma ou duas frases. Os models sem raciocínio se concentram na região de baixa latência:
- claude-opus-4-8: 0,75 segundos
- gpt-5-2: 0,8 segundos
- claude-haiku-4-5: 0,96 segundos
- claude-sonnet-5: 1,5 segundos
- claude-opus-4-7: 2 segundos
Os models de raciocínio foram mais lentos para alcançar a primeira palavra da resposta mesmo aqui, porque pensam primeiro:
- mimo-v2-5: 1,2 segundos
- minimax-m3: 2,4 segundos
- deepseek-v4-flash: 3,6 segundos
- gemini-3-1-pro-preview: 9 segundos
- hy3-preview: 14,6 segundos
Em perguntas curtas, a etapa de pensamento é principalmente sobrecarga, já que a resposta em si é curta.
Caso de resposta longa (geração de código)
No caso longo, o atraso do primeiro token importa menos, e a velocidade de streaming spNo caso longo, o atraso do primeiro token importa menos, e a velocidade de streaming e o tempo total de resposta assumem o controle. claude-haiku-4-5 liderou ambos, transmitindo a cerca de 180 tokens por segundo e terminando em cerca de 5,5 segundos. Os outros models sem raciocínio terminaram em aproximadamente 10 a 13 segundos: claude-sonnet-5 em 10 segundos, claude-opus-4-8 em 10.8 e claude-opus-4-7 em 12.7.
Os models de raciocínio produziram tempos totais mais longos, porque o pensamento e a saída longa se somam:
- gemini-3-1-pro-preview: 18,5 segundos
- hy3-preview: 23,1 segundos
- deepseek-v4-flash: 24,3 segundos
- minimax-m3: 28,1 segundos
- mimo-v2-5: 35 segundos
Alguns transmitem rapidamente uma vez iniciados (hy3-preview roda a cerca de 200 tokens por segundo), mas o pensamento inicial mantém o total alto.
O comprimento da saída foi limitado em vez de deixado aberto, para que os models não sejam comparados pela verbosidade: cerca de 128 tokens para respostas curtas e 1.024 para respostas longas. Os models de raciocínio receberam um orçamento extra além desse limite para manter seus tokens de pensamento, de modo que seus tempos ponta a ponta refletem o pensamento mais a resposta, em vez de uma resposta cortada no meio do raciocínio.
Respostas curtas versus respostas longas
O contraste entre os dois casos é a principal conclusão:
- No caso curto, os models mais rápidos responderam em menos de um segundo e a dispersão foi estreita.
- No caso longo, os models sem raciocínio permaneceram perto da frente (Haiku mais rápido em cerca de 5,5 segundos), enquanto os models de raciocínio ficaram bem atrás com 18 a 35 segundos.
- A ordem dentro do grupo sem raciocínio também muda: o Haiku foi um dos vários iniciadores abaixo de um segundo em prompts curtos, mas se destaca claramente em saídas longas por causa de sua velocidade de streaming.
Latência no percentil 90
O padrão principal é que a cauda multiplica para os models de raciocínio em vez de apenas se deslocar. Na tarefa de codificação, MiniMax passou de cerca de 13 segundos na mediana para 42 segundos no p90, e Hunyuan de cerca de 16 para 46 segundos. O tempo extra é pensamento, e a duração do pensamento varia de solicitação para solicitação, portanto esses models não são apenas mais lentos, mas também menos previsíveis.
Alguns pontos se destacam:
- MiMo é a exceção entre os models de raciocínio. Ele raciocina em todas as solicitações, mas pensa brevemente, então seu p90 ficou perto de 3,7 segundos. Raciocinar por si só não torna um model imprevisível; a quantidade de pensamento torna.
- GPT-5.2 mostra uma cauda apenas onde raciocina. Em Q&A, seu p90 foi abaixo de 2 segundos, mas em codificação, onde ativa o raciocínio, seu p90 subiu para cerca de 11 segundos.
- Os models sem raciocínio permaneceram estáveis. Haiku 4.5 e Opus 4.8 mantiveram o p90 dentro de cerca de 2 a 2,5 segundos. Mesmo o Sonnet 5, que se alargou em saídas longas (cerca de 4 segundos na mediana para 8 no p90), permaneceu muito abaixo do grupo de raciocínio.
O ponto prático é que a mediana pode esconder isso. A mediana do MiniMax em codificação, cerca de 13 segundos, não é a pior do grupo, mas seu p90 de cerca de 42 segundos corresponde ao Hunyuan, então em uma solicitação ruim ele é tão lento quanto qualquer coisa medida.
LLM Raciocínio e seu efeito na velocidade
Os models de raciocínio demoram mais para produzir o primeiro token de resposta porque geram tokens internos de cadeia de pensamento antes da resposta visível. Essa etapa de pensamento é o que eleva o tempo até a primeira resposta, de cerca de um segundo para models sem raciocínio a vários segundos ou mais.
O fato de um model raciocinar nem sempre é fixo. Detectamos o raciocínio por solicitação a partir do número de tokens de raciocínio que cada resposta retornou e, em seguida, agrupamos os resultados por tarefa. A proporção de solicitações em que cada model raciocinou:
GPT-5.2 mostra isso diretamente: respondeu a prompts curtos de Q&A sem raciocínio, mas raciocinou na maioria dos prompts de codificação. Para um model híbrido como este, “raciocínio” não é um rótulo fixo; o model decide com base na tarefa, e sua latência muda com essa decisão. É por isso que o GPT-5.2 fica no grupo rápido em Q&A, mas recua na codificação.
Medimos cada model em seu estado padrão. Vários são híbridos que podem raciocinar sob demanda, mas vêm com o pensamento desativado: Claude Opus 4.8, por exemplo, suporta pensamento estendido, mas está desativado por padrão, por isso nunca produziu tokens de raciocínio em nossas execuções e permaneceu rápido, assim como os outros models Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Os demais raciocinaram em quase todas as solicitações, por isso parecem mais lentos até a primeira resposta. Portanto, “nunca raciocina” aqui significa não por padrão, não que a capacidade esteja ausente. O GPT-5.2 se destaca porque fez essa escolha por conta própria, ativando o raciocínio para os prompts de codificação mais difíceis e deixando-o desativado para Q&A.
Efeito do endpoint na latência para LLMs
A latência de um model hospedado não é apenas o model. Ela também inclui a pilha de servidores do provedor, filas, o caminho de rede e a geografia. Nosso elenco mostra isso dentro de uma única linha de model. Claude Opus 4.8, servido pelo Google Vertex na Europa, retornou seu primeiro token em cerca de 0,75 segundos, enquanto Claude Opus 4.7, servido pela própria API da Anthropic, levou cerca de 2 segundos.
Essas são versões diferentes, então a diferença não é puramente o endpoint, mas o padrão corresponde a um efeito bem conhecido: os mesmos pesos podem ser várias vezes mais rápidos ou mais lentos dependendo de onde e como são servidos. Nosso cliente de medição rodou na Europa, então o endpoint da Vertex europeia tinha um caminho de rede mais curto, o que é parte do motivo pelo qual saiu à frente.
Para ver como escolhemos o provedor para cada model, leia nossa metodologia de benchmark.
Limite máximo de token e models de raciocínio
Para medir a latência de forma justa, definimos um comprimento máximo fixo de saída para que nenhum model seja recompensado ou penalizado por escrever mais. Esse limite é o orçamento de token para toda a resposta, e é daí que veio a maioria das falhas:
- Os models de raciocínio gastam parte do orçamento pensando antes de a resposta começar.
- Em prompts de codificação difíceis, alguns pensam muito, e de forma imprevisível (MiniMax usou cerca de 2.500 a 3.700 tokens de pensamento em um único prompt).
- Quando o pensamento preenche todo o orçamento, não sobram tokens para a resposta e a resposta volta vazia.
- Isso atingiu o MiniMax com mais força na codificação, onde a primeira passada concluiu menos da metade de suas solicitações.
A conclusão é que o limite máximo de token é um parâmetro que vale a pena observar: defina-o muito baixo e um model de raciocínio pode gastar tudo pensando e nunca chegar a uma resposta. Aumentamos o orçamento para os models de raciocínio, demos espaço para o pensamento além do comprimento da resposta e repetimos as solicitações com falha. A maioria das lacunas foi preenchida, embora algumas ainda tenham falhado quando o pensamento de um model ultrapassou até mesmo o orçamento maior.
Adicionar como fonte preferencialLLM Latência Benchmark Metodologia
Avaliamos 11 language models com 1.320 solicitações, medindo a rapidez com que cada model responde.
Models
Pegamos os cinco models mais usados no OpenRouter e adicionamos mais seis models atuais por cima:
- Sem raciocínio por padrão: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Com raciocínio por padrão: DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Casos de uso e exemplos de prompts
Usamos dois casos de uso com comprimentos fixos de entrada e saída, para que os resultados reflitam a velocidade e não quanto tempo um prompt ou resposta por acaso tinha:
- Resposta curta (Q&A): entrada curta (cerca de 256 tokens), saída curta (limitada a 128 tokens). Exemplo: “Qual é o propósito de uma chave primária em um banco de dados?”
- Resposta longa (geração de código): entrada curta (cerca de 512 tokens), saída longa (limitada a 1.024 tokens). Exemplo: “Crie um downloader de URL multithread em Python que receba uma lista de URLs de imagem e as baixe simultaneamente.”
Cada caso de uso usou 20 prompts, e cada prompt foi enviado 3 vezes por model, gerando 60 medições por model por caso de uso. Relatamos a mediana (p50) e o p90.
O que medimos
Transmitimos cada resposta e registramos quando a solicitação foi enviada, quando o primeiro token chegou, quando o primeiro token de resposta chegou (após qualquer pensamento) e quando o último token chegou. A partir disso, derivamos o tempo até o primeiro token, o tempo até o primeiro token de resposta, a latência por token e a velocidade de saída, e o tempo ponta a ponta.
Raciocínio vs sem raciocínio
Cada resposta retorna um resumo de uso que inclui uma contagem de tokens de raciocínio. Lemos isso para cada solicitação e marcamos a solicitação como com raciocínio quando a contagem estava acima de zero e como sem raciocínio quando era zero, em vez de confiar no rótulo do model. Foi assim que descobrimos que o GPT-5.2 raciocina na codificação, mas não em Q&A.
Como escolhemos os provedores
O mesmo model é servido por diferentes provedores em velocidades diferentes, por isso fixamos cada model em um provedor em vez de deixar as solicitações rotearem livremente. O OpenRouter lista o uptime, a latência e a taxa de transferência de cada provedor, e usamos esses números para escolher. Descartamos qualquer provedor abaixo de cerca de 98 por cento de uptime e, em seguida, escolhemos o mais rápido do restante por latência e taxa de transferência. Fixamos esse provedor para cada solicitação e registramos o provedor que realmente serviu cada resposta para confirmar que a fixação se manteve. Alguns dos provedores mais rápidos não estavam acessíveis com nossa conta e retornaram erros de limite de taxa, então usamos o provedor mais rápido que serviu de forma confiável.
Os provedores fixados foram Claude Opus 4.8 no Google Vertex (Europa), Claude Opus 4.7 na Anthropic, Claude Sonnet 5 e GPT-5.2 no Azure, Claude Fable 5 e Claude Haiku 4.5 no Amazon Bedrock, DeepSeek V4 Flash na Novita, MiMo v2.5 na DeepInfra, MiniMax M3 na Together, Gemini 3.1 Pro no Google Vertex, e Hunyuan HY3 na GMICloud.
Controles
- Todas as solicitações foram executadas a partir de uma única região de cliente.
- O comprimento da saída foi limitado (128 para curtas, 1.024 para longas) para que a verbosidade não distorça a latência. Os models de raciocínio receberam orçamento extra para o pensamento além desse limite.
- Cada prompt começou com um bloco único de texto para evitar o cache de prompt, e verificamos que nenhum token de entrada veio do cache.
- Todas as contagens de token usam um único tokenizer para que a velocidade seja comparável entre os models.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{LLM Latência Benchmark por Casos de Uso}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Acessado em 6 agosto 2026}
}Resultados e carimbos de data/hora de 1.4 mil pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 6 arquivos CSV e um README.
Quer os dados granulares por trás disso? Assine o Premium
Registro de alterações
5 atualizaçõesSubstituídos os intervalos de latência aproximados por valores de tempo precisos por modelo no benchmark de latência.
A lista de modelos comparados foi substituída por 11 modelos atuais com e sem raciocínio.
Expandida a seção "Resultados do benchmark de latência LLM" com resultados detalhados de latência do primeiro token e latência por token.
O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.
Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.