LLM inference: entenda a latência e escolha a infraestrutura

LLM inference, ou inferência de LLMs, tem 2 fases principais: processar o prompt e gerar a resposta. Quando um recurso demora a começar a responder, a solução é diferente da necessária quando ele começa rápido, mas leva tempo demais para terminar. Meça essas esperas separadamente antes de trocar de modelo, contratar uma hospedagem mais rápida ou alugar GPUs.

Comece com uma API hospedada, a menos que exista um motivo concreto para operar a infraestrutura de inferência por conta própria. Pode ser a necessidade de controlar a implantação, usar um modelo aberto específico ou atender a um tráfego constante que justifique manter capacidade própria. Uma resposta lenta, por si só, não basta: primeiro descubra em que parte da requisição está a demora.

A documentação e o escopo das versões apresentados abaixo foram conferidos nas páginas oficiais dos desenvolvedores em 21 de outubro de 2026. O exemplo com cálculos usa uma resposta de API publicada, com as contas à vista. Não se trata de um benchmark executado por nós nem de uma indicação da velocidade que sua aplicação vai alcançar.

O que é LLM inference? Primeiro o prompt, depois a resposta

Inferência de LLM é o trabalho que um grande modelo de linguagem já treinado realiza para produzir uma saída a partir de uma entrada. Em uma requisição típica de geração de texto, isso significa preparar o prompt, prever uma continuação e devolver o texto gerado. O modelo processa tokens, unidades de texto que podem ser palavras, fragmentos de palavras ou sinais de pontuação. Explicação da NVIDIA sobre inferência.

Pense em organizar anotações antes de escrever uma resposta. Ler e ordenar o material recebido é a fase de preparação. Escrever a resposta é a fase de continuação. Ter as anotações prontas evita repetir a preparação, mas a resposta ainda precisa ser escrita. Na implementação, o que fica armazenado é um estado numérico, não anotações legíveis.

O prefill processa a entrada já conhecida. Instruções, documentos recuperados, histórico da conversa e resultados de ferramentas viram tokens do prompt. Como essas posições já existem, o sistema pode processá-las em conjunto, respeitando as regras de atenção do modelo. Essa etapa constrói o estado usado para produzir o primeiro token de saída.

O decode gera a continuação. Na geração autorregressiva convencional, cada novo token depende da continuação escolhida até aquele momento. O runtime executa o modelo repetidamente, escolhe o próximo token, atualiza o estado e segue até atingir uma condição de parada. A NVIDIA descreve as duas fases.

Em um assistente de atendimento, um documento extenso de políticas pode tornar a preparação custosa mesmo quando a resposta pedida é curta. Em um gerador de relatórios, um prompt pequeno pode ser seguido de uma longa espera enquanto o modelo escreve. São cargas de trabalho diferentes, embora usem o mesmo endpoint.

Qual é a diferença entre inferência e treinamento de LLMs?

O treinamento altera os parâmetros aprendidos pelo modelo; a inferência usa esses parâmetros. Também chamados de pesos, eles são os valores numéricos aprendidos durante o treinamento. Incluir um documento no prompt fornece contexto para aquela requisição; isso, por si só, não treina esses pesos novamente. Explicação da IBM sobre inferência e treinamento.

Essa distinção ajuda a diagnosticar problemas no produto. Se a resposta ignora uma política, melhore o contexto fornecido e avalie o comportamento do modelo. Se a resposta está correta, mas demora demais, examine os tempos de inferência. Treinamento, qualidade da recuperação de informações e desempenho da infraestrutura de inferência são frentes de intervenção distintas.

Por que os tokens de saída costumam custar mais?

Gerar uma continuação costuma permitir menos trabalho em paralelo por requisição do que processar um prompt já conhecido. Com lotes pequenos, o decode pode passar boa parte do tempo movimentando pesos do modelo e estado de atenção pela memória. Processar mais posições conhecidas da entrada em conjunto pode aproveitar o hardware de outra forma. Isso ajuda a explicar por que muitas APIs cobram mais pelos tokens de saída. Como funcionam prefill e decode, segundo a NVIDIA.

A proporção exata entre os preços é uma decisão do fornecedor, não uma constante física. O tratamento do cache, o modelo escolhido e as condições do serviço também entram na conta. Não presuma que encurtar a entrada e encurtar a saída tenham o mesmo efeito sobre a latência ou a cobrança.

Na prática: se o recurso precisa apenas de uma categoria e de uma explicação curta, peça esse resultado. Exigir um texto longo cria mais trabalho de geração, que mesmo um provedor mais rápido terá de executar.

Separe o tempo até o primeiro token da velocidade em tokens por segundo

O tempo até o primeiro token indica quanto a resposta demora para começar; a velocidade de geração indica o ritmo depois que ela começa. Use pontos de início e fim consistentes nas medições.

• Tempo até o primeiro token, ou TTFT: vai do envio da requisição ao modelo até o recebimento do primeiro token de saída não vazio. Fila, processamento do prompt e tráfego de rede podem contribuir para essa espera.
• Latência entre tokens: é o intervalo entre os tokens de saída depois que a geração começa. Um fluxo pode começar rapidamente e ainda parecer lento se esses intervalos forem longos.
• Latência da requisição de ponta a ponta: vai do envio da requisição até o recebimento do último token de saída.
• Vazão do sistema: é o total de saída útil produzido pelo conjunto de requisições simultâneas. Ela pode aumentar enquanto a experiência de um usuário individual fica mais lenta.

Essas distinções seguem as definições de métricas da NVIDIA. É por isso que um número de tokens por segundo em destaque não responde a toda pergunta sobre desempenho.

Confira o denominador sempre que comparar tokens por segundo. Um provedor pode dividir os tokens de saída pelo tempo de geração, enquanto a medição no cliente inclui a espera inicial. Um resultado agregado do servidor pode reunir vários usuários. São números que descrevem coisas diferentes.

Em uma resposta por streaming com vários tokens, o intervalo médio entre tokens pode ser calculado como (final-token time − first-token time) / (output-token count − 1). A fórmula exclui a espera inicial; a subtração considera os intervalos entre tokens. A definição da NVIDIA explicita esses limites.

Mantenha uma medição separada na aplicação, da ação do usuário até o resultado utilizável. A recuperação de documentos antes da chamada ao modelo, as chamadas a ferramentas externas e a validação posterior entram nessa medição. Trocar de provedor de inferência não elimina o tempo de espera pelo seu próprio banco de dados.

Uma requisição e as parcelas da sua latência

O exemplo de resposta publicado pela Groq mostra por que é preciso examinar um campo chamado total_time. A Groq, provedora de inferência hospedada, inclui campos de tempo nos dados de uso da API. A referência da API Chat Completions traz um exemplo com 18 tokens de prompt e 556 tokens de conclusão.

Estes são os valores publicados no exemplo, com os tempos convertidos de segundos para milissegundos e arredondados:

Fonte: objeto de uso do exemplo da Groq. São tempos de um exemplo de documentação, não latências esperadas em produção.

Nesse exemplo, o total informado inclui o processamento do prompt e a geração:

Prompt + conclusão = 0.000680594 + 0.463333333 = 0.464013927 segundos. O resultado coincide exatamente com o total_time informado. Nesse exemplo, a fila fica fora do total.

Fila + prompt + conclusão = 0.501507683 segundos, ou aproximadamente 501.508 ms. Esse é o subtotal que calculamos para as etapas identificadas no servidor. Ele ainda não revela a espera completa na aplicação, porque o exemplo não informa os tempos de rede do cliente nem o trabalho da aplicação antes e depois da chamada.

Dividir os 556 tokens de saída do exemplo pelo tempo de conclusão de 0.463333333 segundo resulta em aproximadamente 1,200 tokens de saída por segundo. É uma conta feita sobre uma resposta de exemplo, não um benchmark nem uma promessa. A Groq documenta esse cálculo de contagem dividida pelo tempo de conclusão em suas orientações sobre métricas de inferência.

Para o seu recurso, o que importa é separar o tempo nessas parcelas. Uma fila longa aponta para a admissão de requisições e a capacidade disponível. Muito tempo no processamento do prompt aponta para o trabalho com a entrada. Uma conclusão demorada aponta para o trabalho de geração. Se a espera no cliente for muito maior que a soma das etapas informadas pelo servidor, investigue a rede e o caminho percorrido dentro da aplicação.

Otimização de inferência: escolha a solução conforme a origem da espera

Uma otimização só ajuda quando altera uma parte relevante da sua carga de trabalho. O mesmo recurso pode ser valioso para um assistente de documentos e quase irrelevante para prompts curtos e sem relação entre si.

Os mecanismos estão documentados pela NVIDIA e nos guias dos runtimes citados a seguir. A última coluna delimita o que se pode concluir ao decidir uma implantação.

KV cache: aproveite o trabalho já realizado

O cache de chaves e valores, ou KV cache, preserva o estado de atenção dos tokens anteriores. A atenção é o mecanismo pelo qual um transformer incorpora o contexto anterior à previsão atual. Manter as chaves e os valores anteriores evita reconstruí-los a cada avanço do modelo. O cache cresce ou é gerenciado conforme a arquitetura de atenção do modelo e a política da infraestrutura de inferência. Explicação da NVIDIA sobre KV cache.

Essa reutilização consome memória. O fato de os pesos de um modelo caberem em uma GPU não significa que conversas longas de vários usuários simultâneos também vão caber. Além dos pesos, considere o estado das requisições ativas e a memória de trabalho.

O cache de prefixo estende a reutilização a requisições que começam da mesma forma. Um assistente que recebe repetidamente as mesmas instruções e o mesmo documento de referência pode reaproveitar esse prefixo já processado. Ele ainda precisa processar o trecho final que mudou e gerar uma nova resposta.

O vLLM, um motor de inferência e disponibilização de modelos de código aberto, documenta explicitamente que seu cache automático de prefixo poupa trabalho de prefill, e não de decode. Limites do cache do vLLM.

Mantenha o contexto compartilhado útil no início das requisições e depois examine o uso de cache informado. Se os prompts têm pouco em comum, ou se a espera se concentra na escrita de respostas longas, a reutilização de prefixos resolve pouco do problema. O guia de KV cache detalha o estado, a retenção e as formas de reutilização de cada provedor.

Batching: compartilhe a capacidade entre requisições

O batching contínuo melhora o aproveitamento do servidor. Ele permite que sequências concluídas saiam e novas requisições entrem enquanto outras sequências continuam gerando texto. Assim, um grupo inteiro não precisa ficar aberto à espera da resposta mais longa. Explicação da NVIDIA sobre batching contínuo.

Para quem opera um serviço com muitos clientes, isso pode tornar a capacidade mais produtiva. Para quem está esperando uma única resposta, um aumento na vazão agregada não representa uma melhora automática. Teste a distribuição dos tempos de resposta sob o tráfego simultâneo que seu recurso precisa atender.

Não confunda o batching contínuo dentro de um motor de inferência com uma API de processamento assíncrono em lote. Esta última permite enviar trabalho para ser concluído depois, o que serve para tarefas como classificações executadas durante a noite. É uma escolha de produto diferente de agendar com eficiência requisições de chat em tempo real.

O chunked prefill reduz a interferência entre novos prompts e respostas em andamento. Ele divide um prefill grande em partes menores, que podem ser agendadas junto com o trabalho de decode. O vLLM documenta uma relação de compromisso entre a latência até o primeiro token e a latência entre tokens conforme muda o orçamento de tokens do agendador. Guia de ajustes do vLLM.

Isso importa quando alguém envia um documento enquanto outros clientes já estão conversando. O objetivo é manter a fluidez dessas respostas e, ao mesmo tempo, admitir o novo trabalho, em vez de otimizar uma requisição isolada em um servidor vazio.

Quantização: use menos espaço por valor

A quantização reduz a precisão usada para representar valores numéricos. Representações menores podem diminuir a necessidade de memória e ajudar quando a execução é limitada pela largura de banda. A quantização de pesos e a quantização do KV cache afetam alocações diferentes. Documentação de quantização do vLLM.

A decisão depende de a representação escolhida preservar o comportamento exigido pela aplicação em um runtime e um dispositivo compatíveis. Avalie a extração de informações de documentos, os argumentos enviados a ferramentas e as tarefas de contexto longo relevantes para seu recurso. Um arquivo menor e um modelo carregado com sucesso não comprovam que o resultado é aceitável.

Não prometa ganho de velocidade apenas pelo nome do formato. Os kernels compatíveis, o hardware e a carga de trabalho determinam o resultado. Consulte o guia de quantização de LLMs para escolher entre formatos e entender qual uso de memória está sendo reduzido.

Decodificação especulativa: proponha, depois verifique

A decodificação especulativa tenta aceitar mais trabalho de continuação a cada passagem de verificação. Um mecanismo de rascunho de menor custo propõe tokens, e o modelo-alvo os verifica. As propostas aceitas podem poupar trabalho de geração sequencial; as rejeitadas e a própria verificação continuam tendo um custo. Documentação do vLLM sobre decodificação especulativa.

O rascunho pode vir de outro modelo ou de um método de previsão compatível. O benefício depende da aceitação das propostas, do modelo-alvo, das configurações de amostragem, do hardware e do tráfego. Vale avaliar a técnica quando a geração é o gargalo; ela não resolve uma recuperação lenta de documentos nem garante uma fila inicial mais curta.

Os métodos convencionais de amostragem por rejeição buscam preservar a distribuição-alvo dentro dos limites numéricos. Não estenda essa promessa a todo recurso que recebe o nome de especulativo: na mesma documentação, o vLLM distingue suas garantias convencionais dos métodos de verificação deliberadamente sujeitos a perdas.

Arquitetura de inferência de LLMs: quem vai operar o serviço?

Defina a divisão de responsabilidades antes de escolher o hardware. Uma API do desenvolvedor do modelo, um provedor de inferência e um runtime próprio podem transformar prompts em respostas. O trabalho que fica sob sua responsabilidade muda em cada opção.

API do modelo: contrate acesso aos modelos do desenvolvedor

A Claude API, da Anthropic, oferece acesso programático hospedado aos modelos Claude. Sua Messages API recebe requisições e gera respostas, com interfaces de streaming e uso de ferramentas documentadas pela empresa. Visão geral da Claude API.

Esse caminho atende a quem prioriza levar o comportamento necessário do modelo para um produto. Você define prompts, contexto, requisitos de saída e controles da aplicação; o desenvolvedor do modelo opera a infraestrutura de inferência.

O limite está no controle. Contratar acesso ao modelo não dá acesso ao agendador do provedor nem instala esse modelo na sua infraestrutura. Escolha essa opção quando o modelo e o contrato do serviço atenderem à necessidade. Antes de iniciar um projeto com GPUs só porque uma resposta da API está lenta, meça onde ocorre a espera.

Provedor de inferência: escolha quem hospeda o modelo

A Groq oferece uma API hospedada de chat completions com um catálogo de modelos documentado. As páginas dos modelos listam os recursos e limites de cada um; por isso, verifique o endpoint específico que pretende usar. Catálogo de modelos da Groq.

Isso permite avaliar quem hospeda um modelo disponível sem operar o hardware por conta própria. O limite está na combinação oferecida: disponibilidade do modelo, limites de requisição e suporte aos recursos. Uma família de modelos aparecer em outro lugar não significa que o provedor disponibilize o checkpoint necessário ou aceite todos os campos da requisição.

A Cerebras oferece uma API e um SDK de inferência hospedada, incluindo geração por streaming. O guia de início rápido mostra a configuração da chave de API e o fluxo de requisição. Início rápido de inferência da Cerebras.

Avalie a Cerebras como mais uma candidata, usando os comprimentos reais dos seus prompts, os requisitos de saída e o padrão de tráfego. O limite continua sendo a adequação do serviço: confirme o modelo oferecido, os recursos necessários e as condições de capacidade. Um streaming rápido em um exemplo curto não basta para validar um recurso de produção que processa muitos documentos. O guia de preços da Cerebras e o guia de preços da Groq abordam essas escolhas comerciais.

Exemplo de preço de inferência hospedada: a Groq lista o Qwen3.8-27B, da Alibaba, por $0.80 por milhão de tokens de entrada e $4.00 por milhão de tokens de saída; consulte a listagem atual de modelos ao comparar o uso de um serviço hospedado com a capacidade e o trabalho de operação que você teria de financiar.

Esse exemplo se refere a um modelo específico. Não é uma cotação para o exemplo de tempos apresentado antes, nem estabelece uma classificação da Groq em relação a outro modelo ou implantação.

Motor de inferência próprio: assuma o runtime e a capacidade

O vLLM oferece um runtime para disponibilizar modelos com batching contínuo, streaming, cache de prefixo e servidor de API. São componentes úteis quando atender a requisições simultâneas é sua responsabilidade. Ainda é preciso verificar a compatibilidade com modelos, hardware e opções de otimização para a sua implantação. Recursos documentados do vLLM.

O desafio está no serviço ao redor do motor: provisionar capacidade, implantar mudanças, admitir tráfego, monitorar falhas e manter folga suficiente para os períodos de maior demanda. Um runtime pode agendar o trabalho nos dispositivos disponíveis; ele não pode decidir os requisitos de confiabilidade da sua aplicação.

O Ollama é um runtime para executar modelos na sua máquina ou no seu servidor, com opções de execução em CPU e GPU. Seu FAQ documenta o processamento simultâneo, as filas e a memória adicional necessária para requisições paralelas. Orientações do Ollama sobre concorrência.

O Ollama é um ponto de partida adequado para desenvolvimento local ou uma carga interna controlada. Seu limite está na memória e na capacidade operacional por trás da interface conveniente. Use o comparativo entre Ollama e vLLM para decidir entre ele e uma implantação voltada ao atendimento de requisições; depois, valide com requisições simultâneas, não apenas com uma conversa isolada que funcionou.

O DeepInfer, da DeepSeek, é um framework especializado em inferência cujo repositório público foi iniciado em 20 de outubro de 2026. O README descreve a versão aberta como uma solução de inferência offline com componentes para disponibilizar modelos em escala, com suporte a DeepSeek-V4.1-Flash, GPUs NVIDIA SM100 e NPUs Huawei Ascend 950. Histórico do repositório, README do desenvolvedor.

A versão publicada não é um serviço completo de inferência. A DeepSeek lista explicitamente um sistema de KV cache, a separação entre encoding/prefill/decode e o balanceamento de carga entre réplicas como componentes necessários que não estão incluídos. São ausências na infraestrutura do serviço; isso não significa que o motor de inferência deixe de fazer cache do estado de atenção. Componentes que o DeepInfer declara não incluir.

Para uma equipe de infraestrutura que pretende usar esse modelo e esse hardware, vale avaliar o código. Para quem tenta melhorar uma aplicação comum nesta semana, ele não é um atalho que dispensa a operação de um serviço. Separe a decisão sobre o modelo DeepSeek V4 da decisão de construir sua infraestrutura de inferência.

Opte pela hospedagem própria quando esse controle resolver um requisito específico e houver equipe para assumir a responsabilidade. Uma demanda constante pode justificar a avaliação; uma demanda irregular pode deixar ociosa a capacidade que você paga para manter. Considere o contexto ativo, a concorrência, as falhas e os picos. Não existe um limiar universal de tráfego que permita afirmar que, a partir dele, GPUs próprias são a melhor escolha.

Onde há exagero nas promessas de inferência mais rápida?

Uma taxa de geração maior só é útil quando melhora o resultado que o usuário está esperando. O streaming mostra o progresso mais cedo, mas não elimina a geração que ainda falta. Um fluxo de trabalho que precisa validar uma resposta estruturada completa pode continuar dependendo de esperar até o fim.

Qual é a inferência de LLM mais rápida? Depende da carga de trabalho

Uma comparação relevante deixa claros o comportamento do modelo, o comprimento do prompt e da saída, as condições de cache e a concorrência. Sem isso, um resultado mais rápido pode representar apenas uma requisição mais fácil ou um denominador de tempo diferente. A vazão agregada de um provedor não é uma promessa sobre a chegada do primeiro token para um cliente individual.

O mesmo rigor vale para as alegações de otimização. Um acerto de cache poupa a preparação repetida que pode ser reaproveitada, não todas as etapas de uma tarefa. Representações numéricas menores não comprovam que a qualidade da tarefa permanece igual. Um framework aberto de inferência não entrega um serviço operacional completo.

Comece já pela medição e pela eliminação de trabalho desnecessário. Só migre a infraestrutura quando essas medições apontarem um motivo. Se uma chamada curta de API já atende aos requisitos de qualidade e latência, o lançamento de um motor de inferência não cria um problema que você precisa resolver.

Perguntas frequentes sobre inferência

O que é inferência em ML?

ML significa machine learning, ou aprendizado de máquina. A inferência aplica um modelo treinado a uma nova entrada para obter uma saída. A geração de texto com LLMs é uma aplicação desse processo mais amplo.

O que significa LLM em inteligência artificial?

LLM é a sigla de large language model, ou grande modelo de linguagem. No contexto de geração de texto tratado aqui, ele processa o contexto e prevê tokens para formar uma continuação.

O que é inferência de linguagem?

Nesse contexto, a expressão costuma se referir à inferência realizada por um modelo de linguagem. Não é o nome de uma linguagem de programação obrigatória; a aplicação pode chamar o modelo pela API ou pelo runtime.

Qual é a diferença entre inferência e previsão em ML?

Inferência é o processo de executar o modelo treinado. Uma previsão é uma saída desse processo. Na geração autorregressiva de linguagem, previsões sucessivas do próximo token constroem a resposta.

Quais são os três tipos de inferência?

Em discussões sobre raciocínio, a expressão costuma se referir a dedução, indução e abdução. Essas são categorias lógicas. Uma API do desenvolvedor do modelo, um provedor de inferência hospedada e um runtime sob gestão própria são escolhas de implantação, não esses três métodos de raciocínio.

Quais são cinco exemplos de inferência?

Exemplos de tarefas com modelos de linguagem incluem classificar um e-mail, resumir um documento, traduzir um trecho, redigir uma resposta e gerar código. São exemplos de tarefas, não alegações de desempenho de um modelo específico.

Pode dar um exemplo de inferência?

Uma aplicação de atendimento envia a pergunta de um cliente e o texto relevante de uma política a um modelo treinado, que gera uma sugestão de resposta. Preparar esse contexto e gerar a resposta são trabalhos de inferência.

Como fazer inferência com um LLM?

Escolha um modelo treinado, envie o prompt relevante por uma API ou um runtime e avalie a saída recebida. Você pode usar um modelo já treinado sem precisar treiná-lo por conta própria.

O que é inferência em palavras simples?

É usar o que um modelo aprendeu para produzir uma saída a partir de uma nova entrada. Em um chatbot, é o trabalho do modelo entre receber a conversa e produzir a próxima resposta.

O que mudar na próxima semana

Quem desenvolve deve instrumentar a requisição; quem opera deve testá-la sob carga; quem contrata deve comparar os requisitos de serviço resultantes. Esses trabalhos se conectam, mas não substituem uns aos outros.

1. 1

   Registre o caminho completo

   Para uma tarefa representativa, registre a contagem de tokens de entrada e de saída, a chegada da primeira saída não vazia, a saída final e os campos de tempo disponíveis no provedor. Mantenha os tempos de recuperação de informações e de chamadas a ferramentas ao lado do tempo do modelo. Identifique separadamente as requisições com e sem uso de cache.

2. 2

   Atue na etapa que mais consome tempo

   Se o processamento repetido do prompt concentra a espera, investigue a reutilização de prefixos e o contexto irrelevante. Se a geração domina, reduza a saída desnecessária ou avalie um modelo ou uma configuração de decodificação adequados. Se o gargalo é a fila, investigue a capacidade e a admissão de requisições antes de reescrever o prompt.

3. 3

   Reproduza um tráfego realista

   Compare a qualidade da tarefa e a latência com o volume esperado de requisições simultâneas, incluindo entradas e saídas longas. Use essas evidências para manter a API atual, avaliar outro provedor ou justificar a operação de capacidade própria. Antes de escolher esse último caminho, defina quem responderá pelas falhas.

Assine a newsletter para receber explicações práticas sobre os sistemas por trás dos produtos de IA.