LLM Benchmark de Latência por Casos de Uso
Analisámos 11 dos melhores modelos de linguagem de grande escala com um total de 1.320 pedidos, separando modelos de raciocínio e que não usam raciocínio, e medimos a latência do primeiro token, a latência por token e o tempo total de resposta.
LLM benchmark de latência
Pode encontrar aqui os detalhes sobre como medimos a latência.
Tempo de resposta ponta a ponta por modelo
LLM resultados do benchmark de latência
Relatamos os modelos de raciocínio e os que não usam raciocínio separadamente. Os modelos de raciocínio passam vários segundos a pensar antes da primeira resposta visível, pelo que compará-los diretamente com modelos sem raciocínio em termos de latência seria enganador. Alguns modelos também mudam de comportamento consoante a tarefa: o GPT-5.2 responde a perguntas e respostas sem raciocinar, mas raciocina nos prompts de programação.
Caso de resposta curta (P&R)
No caso curto, o que importa é a rapidez com que surge o primeiro token da resposta, uma vez que toda a resposta tem apenas uma frase ou duas. Os modelos sem raciocínio agrupam-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
Os modelos de raciocínio foram mais lentos a chegar à primeira palavra de 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, o passo de pensamento é sobretudo um custo adicional, uma vez que a resposta em si é curta.
Caso de resposta longa (geração de código)
No caso longo, o atraso do primeiro token é menos importante, e a velocidade de streaming e o tempo total de resposta assumem o controlo. O claude-haiku-4-5 liderou em ambos, transmitindo a cerca de 180 tokens por segundo e terminando em cerca de 5,5 segundos. Os outros modelos 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 modelos 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 quando começam (hy3-preview funciona a cerca de 200 tokens por segundo), mas o pensamento inicial mantém o total elevado.
O comprimento da saída foi limitado em vez de ficar em aberto, pelo que os modelos não são comparados em termos de verbosidade: cerca de 128 tokens para respostas curtas e 1.024 para respostas longas. Os modelos de raciocínio receberam um orçamento extra para além deste limite para guardar os seus tokens de pensamento, de modo que os seus tempos totais refletem o pensamento mais a resposta, em vez de uma resposta cortada a meio do raciocínio.
Respostas curtas versus respostas longas
O contraste entre os dois casos é a principal conclusão:
- No caso curto, os modelos mais rápidos responderam em menos de um segundo e a dispersão foi reduzida.
- No caso longo, os modelos sem raciocínio mantiveram-se perto da frente (Haiku foi o mais rápido com cerca de 5,5 segundos), enquanto os modelos de raciocínio ficaram bastante atrás, entre 18 e 35 segundos.
- A ordem dentro do grupo sem raciocínio também se altera: o Haiku foi um dos vários que arrancaram em menos de um segundo nos prompts curtos, mas destaca-se claramente nas saídas longas devido à sua velocidade de streaming.
Latência no percentil 90
O padrão principal é que a cauda se multiplica para modelos de raciocínio, em vez de apenas se deslocar. Na tarefa de programação, o MiniMax passou de cerca de 13 segundos na mediana para 42 segundos no p90, e o Hunyuan de cerca de 16 para 46 segundos. O tempo extra é de pensamento, e a duração do pensamento varia de pedido para pedido, pelo que estes modelos não são apenas mais lentos, mas também menos previsíveis.
Alguns pontos destacam-se:
- O MiMo é a exceção entre os modelos de raciocínio. Raciocina em todos os pedidos, mas pensa brevemente, pelo que o seu p90 se manteve perto de 3,7 segundos. O raciocínio por si só não torna um modelo imprevisível; é a quantidade de pensamento que o faz.
- O GPT-5.2 mostra uma cauda apenas quando raciocina. Em P&R, o seu p90 foi inferior a 2 segundos, mas em programação, onde ativa o raciocínio, o p90 subiu para cerca de 11 segundos.
- Os modelos sem raciocínio mantiveram-se compactos. O Haiku 4.5 e o Opus 4.8 mantiveram o p90 dentro de cerca de 2 a 2,5 segundos. Mesmo o Sonnet 5, que se alargou nas saídas longas (cerca de 4 segundos na mediana para 8 no p90), ficou muito abaixo do grupo de raciocínio.
O ponto prático é que a mediana pode esconder isto. A mediana do MiniMax em programação, cerca de 13 segundos, não é a pior do grupo, mas o seu p90 de cerca de 42 segundos iguala o Hunyuan, pelo que num mau pedido é tão lento como qualquer outro medido.
LLM raciocínio e o seu efeito na velocidade
Os modelos de raciocínio demoram mais tempo a produzir o primeiro token de resposta porque geram tokens internos de cadeia de pensamento antes da resposta visível. Esse passo de pensamento é o que aumenta o tempo até à primeira resposta, de cerca de um segundo para modelos sem raciocínio para vários segundos ou mais.
O facto de um modelo raciocinar nem sempre é fixo. Detetámos o raciocínio por pedido a partir do número de tokens de raciocínio que cada resposta devolveu e depois agrupámos os resultados por tarefa. A percentagem de pedidos em que cada modelo raciocinou:
O GPT-5.2 mostra isto diretamente: respondeu a prompts curtos de P&R sem raciocinar, mas raciocinou na maioria dos prompts de programação. Para um modelo híbrido como este, “raciocínio” não é um rótulo fixo; o modelo decide com base na tarefa, e a sua latência altera-se com essa decisão. É por isso que o GPT-5.2 se situa no grupo rápido em P&R, mas fica para trás na programação.
Medimos cada modelo no seu estado padrão. Vários são híbridos que podem raciocinar a pedido, mas são fornecidos com o pensamento desligado: o Claude Opus 4.8, por exemplo, suporta pensamento alargado, mas está desativado por defeito, pelo que nunca produziu tokens de raciocínio nas nossas execuções e manteve-se rápido, tal como os outros modelos Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Os restantes raciocinaram em quase todos os pedidos, razão pela qual parecem mais lentos até à primeira resposta. Portanto, “nunca raciocina” aqui significa não por defeito, e não que a capacidade esteja ausente. O GPT-5.2 destaca-se porque tomou esta decisão por si próprio, ativando o raciocínio para os prompts de programação mais difíceis e deixando-o desligado para P&R.
Efeito do endpoint na latência para LLMs
A latência de um modelo alojado não é apenas o modelo. Inclui também a pilha de serviço do fornecedor, o enfileiramento, o caminho de rede e a geografia. O nosso painel mostra isto dentro de uma única linha de modelo. O Claude Opus 4.8, servido através do Google Vertex na Europa, devolveu o primeiro token em cerca de 0,75 segundos, enquanto o Claude Opus 4.7, servido através da API própria da Anthropic, demorou cerca de 2 segundos.
Estas são versões diferentes, pelo que a diferença não é puramente do 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. O nosso cliente de medição funcionou na Europa, pelo que o endpoint Vertex europeu tinha um caminho de rede mais curto, o que é parte da razão pela qual ficou à frente.
Para ver como escolhemos o fornecedor de cada modelo, leia a nossa metodologia do benchmark.
Limite máximo de tokens e modelos de raciocínio
Para medir a latência de forma justa, definimos um comprimento máximo fixo de saída para que nenhum modelo seja recompensado ou penalizado por escrever mais. Esse limite é o orçamento de tokens para toda a resposta, e foi aí que ocorreram a maioria das falhas:
- Os modelos de raciocínio gastam parte do orçamento a pensar antes de a resposta começar.
- Em prompts de programação difíceis, alguns pensam muito, e de forma imprevisível (o MiniMax usou cerca de 2.500 a 3.700 tokens de pensamento num único prompt).
- Quando o pensamento preenche todo o orçamento, não restam tokens para a resposta e a resposta volta vazia.
- Isto afetou o MiniMax com mais força na programação, onde a primeira passagem completou menos de metade dos seus pedidos.
A conclusão é que o limite máximo de tokens é um parâmetro que vale a pena vigiar: defina-o demasiado baixo e um modelo de raciocínio pode gastá-lo todo a pensar e nunca chegar a uma resposta. Aumentámos o orçamento para modelos de raciocínio, demos espaço de pensamento para além do comprimento da resposta e tentámos novamente os pedidos que falharam. A maioria das lacunas foi preenchida, embora algumas ainda tenham falhado quando o pensamento de um modelo ultrapassou mesmo o orçamento maior.
Adicionar como fonte preferencialLLM metodologia do benchmark de latência
Analisámos 11 modelos de linguagem com 1.320 pedidos, medindo a rapidez com que cada modelo responde.
Modelos
Pegámos nos cinco modelos mais utilizados no OpenRouter e adicionámos mais seis modelos atuais:
- Sem raciocínio por defeito: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Com raciocínio por defeito: DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Casos de uso e prompts de exemplo
Utilizámos dois casos de uso com comprimentos fixos de entrada e saída, para que os resultados reflitam a velocidade e não o tamanho do prompt ou da resposta:
- Resposta curta (P&R): entrada curta (cerca de 256 tokens), saída curta (limitada a 128 tokens). Exemplo: “Qual é o propósito de uma chave primária numa base de dados?”
- Resposta longa (geração de código): entrada curta (cerca de 512 tokens), saída longa (limitada a 1.024 tokens). Exemplo: “Construa um descarregador de URLs multithreaded em Python que receba uma lista de URLs de imagens e as descarregue concorrentemente.”
Cada caso de uso utilizou 20 prompts, e cada prompt foi enviado 3 vezes por modelo, resultando em 60 medições por modelo por caso de uso. Apresentamos a mediana (p50) e o p90.
O que medimos
Transmitimos cada resposta e registámos quando o pedido foi enviado, quando chegou o primeiro token, quando chegou o primeiro token de resposta (após qualquer pensamento) e quando chegou o último token. A partir destes, derivámos o tempo até ao primeiro token, o tempo até ao primeiro token de resposta, a latência por token e a velocidade de saída, e o tempo total ponta a ponta.
Raciocínio vs não raciocínio
Cada resposta devolve um resumo de utilização que inclui uma contagem de tokens de raciocínio. Lemos isto para cada pedido e marcámos o pedido como raciocínio quando a contagem era superior a zero e como não raciocínio quando era zero, em vez de confiar no rótulo do modelo. Foi assim que descobrimos que o GPT-5.2 raciocina em programação, mas não em P&R.
Como escolhemos os fornecedores
O mesmo modelo é servido por diferentes fornecedores a velocidades diferentes, pelo que fixámos cada modelo a um fornecedor em vez de deixar os pedidos encaminharem livremente. O OpenRouter lista o tempo de atividade, a latência e a taxa de transferência de cada fornecedor, e usámos esses números para escolher. Descartámos qualquer fornecedor abaixo de cerca de 98 por cento de tempo de atividade e depois escolhemos o mais rápido dos restantes por latência e taxa de transferência. Fixámos esse fornecedor para todos os pedidos e registámos o fornecedor que realmente serviu cada resposta para confirmar que a fixação se manteve. Alguns dos fornecedores mais rápidos não estavam acessíveis com a nossa conta e devolveram erros de limite de taxa, pelo que utilizámos o fornecedor mais rápido que serviu de forma fiável.
Os fornecedores 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.
Controlos
- Todos os pedidos foram executados 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 modelos de raciocínio receberam um orçamento extra para pensamento para além deste limite.
- Cada prompt começava com um bloco de texto único para evitar a cache de prompts, e verificámos que nenhum token de entrada veio da cache.
- Todas as contagens de tokens utilizam um único tokenizador, para que a velocidade seja comparável entre modelos.
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 = jul,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Acessado em 8 Julho 2026}
}Resultados e carimbos de data/hora de 1.3 mil pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo um arquivo CSV e um README.
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.