LLM Benchmark de Latência por Casos de Uso
Fizemos o benchmark de 11 dos principais modelos de linguagem de grande escala com um total de 1.320 pedidos, dividindo modelos de raciocínio e não-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 detalhes sobre como medimos a latência aqui.
Tempo de resposta ponta a ponta por modelo
LLM resultados do benchmark de latência
Relatamos modelos de raciocínio e não-raciocínio separadamente. Modelos de raciocínio gastam vários segundos a pensar antes da primeira resposta visível, portanto compará-los diretamente com modelos não-raciocínio na latência seria enganoso. Alguns modelos também mudam de comportamento por tarefa: GPT-5.2 responde a Q&A sem raciocínio, 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. Modelos não-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
Modelos de raciocínio foram mais lentos a atingir a 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 é 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 controlo. claude-haiku-4-5 liderou ambos, transmitindo a cerca de 180 tokens por segundo e terminando em cerca de 5.5 segundos. Os outros modelos não-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.
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 uma vez iniciados (hy3-preview corre 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 deixado em aberto, para que os modelos não sejam comparados quanto à verbosidade: cerca de 128 tokens para respostas curtas e 1.024 para respostas longas. Aos modelos de raciocínio foi dado um orçamento extra além deste limite para conter os seus tokens de pensamento, pelo que os seus tempos ponta a ponta refletem o pensamento mais a resposta, em vez de uma resposta cortada a meio do pensamento.
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 não-raciocínio mantiveram-se perto da frente (Haiku mais rápido a cerca de 5.5 segundos), enquanto os modelos de raciocínio ficaram bem atrás, a 18 a 35 segundos.
- A ordem dentro do grupo não-raciocínio também muda: Haiku foi um dos vários iniciadores abaixo de um segundo em prompts curtos, mas destaca-se claramente em saídas longas devido à sua velocidade de streaming.
Latência no percentil 90
O padrão principal é que a cauda se multiplica para os modelos de raciocínio, em vez de apenas se deslocar. Na tarefa de codificaçã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 é pensamento, e o comprimento 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. Ele raciocina em cada pedido, mas pensa brevemente, por isso o seu p90 manteve-se 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.
- GPT-5.2 mostra uma cauda apenas onde raciocina. Em Q&A, o seu p90 foi inferior a 2 segundos, mas em codificação, onde ativa o raciocínio, o seu p90 subiu para cerca de 11 segundos.
- Modelos não-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 em saídas longas (cerca de 4 segundos na mediana para 8 no p90), manteve-se muito abaixo do grupo de raciocínio.
O ponto prático é que a mediana pode esconder isto. A mediana do MiniMax em codificaçã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 pedido mau é tão lento como qualquer coisa medida.
LLM raciocínio e o seu efeito na velocidade
Modelos de raciocínio demoram mais a produzir o seu 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 seu tempo até à primeira resposta, de cerca de um segundo para modelos não-raciocínio para vários segundos ou mais.
O facto de um modelo raciocinar nem sempre é fixo. Detetámos raciocínio por pedido a partir do número de tokens de raciocínio que cada resposta retornou, e depois agrupámos os resultados por tarefa. A proporção de pedidos em que cada modelo raciocinou:
GPT-5.2 mostra isto diretamente: respondeu a prompts curtos de Q&A sem raciocínio, mas raciocinou na maioria dos prompts de codificaçã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 muda com essa decisão. É por isso que o GPT-5.2 fica no grupo rápido em Q&A, mas recua em codificação.
Medimos cada modelo no seu estado padrão. Vários são híbridos que podem raciocinar sob demanda, mas são enviados com pensamento desligado: 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 na primeira resposta. Portanto, “nunca raciocina” aqui significa não por defeito, e não que a capacidade esteja ausente. GPT-5.2 destaca-se porque fez esta escolha por si próprio, ativando o raciocínio para os prompts de codificação mais difíceis, enquanto o deixava desligado para Q&A.
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, filas de espera, o caminho de rede e a geografia. A nossa lista mostra isto dentro de uma única linha de modelo. Claude Opus 4.8, servido através do Google Vertex na Europa, retornou o seu primeiro token em cerca de 0.75 segundos, enquanto Claude Opus 4.7, servido através da Anthropic própria API, demorou cerca de 2 segundos.
Estas são versões diferentes, pelo que 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. O nosso cliente de medição correu 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 de benchmark.
Limite máximo de tokens e modelos de raciocínio
Para medir a latência de forma justa, definimos um comprimento máximo de saída fixo, para que nenhum modelo seja recompensado ou penalizado por escrever mais. Esse limite é o orçamento de tokens para toda a resposta, e é de onde vieram a maioria das falhas:
- Modelos de raciocínio gastam parte do orçamento a pensar 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 num único prompt).
- Quando o pensamento preenche todo o orçamento, não sobram tokens para a resposta e a resposta volta vazia.
- Isto afetou mais o MiniMax em codificação, onde a primeira passagem completou menos de metade dos seus pedidos.
A lição é que o limite máximo de tokens é um parâmetro a ter em conta: 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 margem de pensamento em cima do comprimento da resposta, e tentámos novamente os pedidos falhados. A maioria das lacunas foi preenchida, embora algumas ainda tenham falhado quando o pensamento de um modelo ultrapassou até o orçamento maior.
Adicionar como fonte preferencialLLM metodologia do benchmark de latência
Fizemos o benchmark de 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 por cima:
- Não-raciocínio por defeito: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- 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 exemplos de prompts
Usámos dois casos de uso com comprimentos de entrada e saída fixos, para que os resultados reflitam a velocidade e não o tamanho que um prompt ou resposta porventura tivesse:
- 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 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: “Crie um descarregador de URL multi-threaded em Python que recebe uma lista de URLs de imagens e as descarrega concorrentemente.”
Cada caso de uso usou 20 prompts, e cada prompt foi enviado 3 vezes por modelo, dando 60 medições por modelo por caso de uso. Relatamos a mediana (p50) e o p90.
O que medimos
Transmitimos cada resposta e registámos quando o pedido foi enviado, quando o primeiro token chegou, quando o primeiro token de resposta chegou (após qualquer pensamento), e quando o último token chegou. A partir destes, derivámos o tempo até ao primeiro token, tempo até ao primeiro token de resposta, latência por token e velocidade de saída, e o tempo ponta a ponta.
Raciocínio vs não-raciocínio
Cada resposta retorna 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 estava acima de zero e não-raciocínio quando era zero, em vez de confiar no rótulo do modelo. Foi assim que descobrimos que GPT-5.2 raciocina em codificação, mas não em Q&A.
Como escolhemos os fornecedores
O mesmo modelo é servido por diferentes fornecedores a velocidades diferentes, por isso fixámos cada modelo a um fornecedor em vez de deixar os pedidos encaminhar livremente. OpenRouter lista o tempo de atividade, latência e débito 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 débito. Fixámos esse fornecedor para cada pedido 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 eram acessíveis com a nossa conta e retornaram erros de limite de taxa, pelo que usá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 correram 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. Aos modelos de raciocínio foi dado orçamento extra para pensar por cima deste limite.
- Cada prompt começou com um bloco de texto único para evitar a cache de prompt, e verificámos que nenhum token de entrada veio da cache.
- Todas as contagens de tokens usam 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 = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Acessado em 12 Agosto 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.
O trabalho de Cem foi citado por publicações globais de destaque, incluindo Business Insider, Forbes, Washington Post, empresas globais como Deloitte, HPE e ONGs como o Fórum Econômico Mundial e organizações supranacionais como a Comissão Europeia.
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas em 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 aquisições de uma empresa de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de tecnologia profunda Hypatos, que alcançou 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 de destaque como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou na Universidade Bogazici como engenheiro de computação 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.