LLM Benchmark de Latência 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 de ponta a ponta por model
LLM resultados do benchmark de latência
Relatamos models de raciocínio e models sem raciocínio separadamente. 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 de 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 tem apenas uma ou duas frases. Os models sem raciocínio concentram-se 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
Models de raciocínio foram mais lentos para chegar à 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
Nas perguntas curtas, a etapa de pensamento é, em grande parte, sobrecarga, já que a própria resposta é 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 e o tempo total de resposta assumem o controle. claude-haiku-4-5 liderou ambos, com streaming 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.
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 fazem streaming rapidamente depois que começam (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 ficar aberto, portanto os models não são comparados quanto à 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 conter seus tokens de pensamento, de modo que seus tempos de ponta a ponta refletem o pensamento mais a resposta, e não uma resposta cortada no meio do pensamento.
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 pequena.
- 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 que começaram abaixo de um segundo em prompts curtos, mas fica claramente à frente em saídas longas por causa da velocidade de streaming.
Latência no percentil 90
O principal padrão é que a cauda se multiplica para models de raciocínio em vez de apenas se deslocar. Na tarefa de coding, 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 permaneceu próximo de 3,7 segundos. O raciocínio por si só não torna um model imprevisível; é a quantidade de pensamento que torna.
- GPT-5.2 apresenta cauda apenas onde raciocina. Em Q&A, seu p90 ficou abaixo de 2 segundos, mas em coding, 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. Até o Sonnet 5, que se dispersou 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 coding, cerca de 13 segundos, não é a pior do grupo, mas seu p90 de cerca de 42 segundos iguala o Hunyuan, portanto, em uma solicitação ruim, ele é tão lento quanto qualquer coisa medida.
LLM raciocínio e seu efeito na velocidade
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 aumenta o tempo até a primeira resposta, de cerca de um segundo para models sem raciocínio para vários segundos ou mais.
Se um model raciocina 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 esse, “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 GPT-5.2 fica no grupo rápido em Q&A, mas recua em codificação.
Medimos cada model em seu estado padrão. Vários são híbridos que podem raciocinar sob demanda, mas são enviados com o pensamento desativado: Claude Opus 4.8, por exemplo, suporta pensamento estendido, mas ele está desativado por padrão, então nunca produziu tokens de raciocínio em nossas execuções e permaneceu rápido, assim como os outros models da Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Os demais raciocinaram em quase todas as solicitações, razão pela qual parecem mais lentos até a primeira resposta. Portanto, “nunca raciocina” aqui significa que não é por padrão, e não que a capacidade esteja ausente. 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 stack de serving do provedor, filas, o caminho de rede e a geografia. Nosso conjunto 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 Anthropic por sua própria API, levou cerca de 2 segundos.
Essas são versões diferentes, portanto 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 client de medição rodou na Europa, então o endpoint Vertex europeu tinha um caminho de rede mais curto, o que é parte do motivo de ter saído à frente.
Para ver como escolhemos o provedor para cada model, leia nossa metodologia de benchmark.
Limite máximo de tokens 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 tokens para toda a resposta, e é dele que veio a maioria das falhas:
- Models de raciocínio gastam parte do orçamento pensando antes de a resposta começar.
- Em prompts difíceis de codificação, 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 restam tokens para a resposta e a resposta volta vazia.
- Isso atingiu o MiniMax com mais força em codificação, onde a primeira passagem concluiu menos da metade de suas solicitações.
A conclusão é que o limite máximo de tokens é 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 models de raciocínio, demos espaço para o pensamento além do comprimento da resposta e tentamos novamente as solicitações que falharam. 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 metodologia do benchmark de latência
Fizemos benchmark de 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 o tamanho de um prompt ou resposta:
- Resposta curta (Q&A): entrada curta (cerca de 256 tokens), saída curta (limitada a 128 tokens). Exemplo: “Qual é a finalidade 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 URLs multithreaded em Python que recebe uma lista de URLs de imagem e as baixa concorrentemente.”
Cada caso de uso usou 20 prompts, e cada prompt foi enviado 3 vezes por model, resultando em 60 medições por model por caso de uso. Relatamos a mediana (p50) e o p90.
O que medimos
Fizemos streaming de todas as respostas 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 de 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 raciocínio quando a contagem estava acima de zero e sem raciocínio quando era zero, em vez de confiar no rótulo do model. Foi assim que descobrimos que GPT-5.2 raciocina em codificação, mas não em Q&A.
Como escolhemos provedores
O mesmo model é servido por provedores diferentes em velocidades diferentes, então fixamos cada model a um único provedor em vez de deixar as solicitações rotearem livremente. O OpenRouter lista uptime, latência e throughput 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 throughput. 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 no Novita, MiMo v2.5 no DeepInfra, MiniMax M3 no Together, Gemini 3.1 Pro no Google Vertex, e Hunyuan HY3 no GMICloud.
Controles
- Todas as solicitações rodaram a partir de uma única região de cliente.
- O comprimento da saída foi limitado (128 para curto, 1.024 para longo) para que a verbosidade não distorça a latência. Os models de raciocínio receberam orçamento extra para pensar além desse limite.
- Cada prompt começou com um bloco de texto único para impedir o cache de prompt, e verificamos que nenhum token de entrada veio do cache.
- Todas as contagens de tokens 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 Benchmark de Latência 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.