Latência vs. Throughput de LLMs: Como compradores de API devem medir a velocidade

Ao avaliar APIs de modelos, entender as compensações entre latência e throughput de LLMs é essencial para otimizar tanto a experiência do usuário quanto os custos de infraestrutura. A latência mede o tempo decorrido para um modelo responder a uma consulta, enquanto o throughput mede o volume de tokens processados ou gerados pelo sistema em um intervalo de tempo específico. Para desenvolvedores e criadores de produtos de IA, otimizar uma métrica muitas vezes exige fazer concessões em relação à outra.

Selecionar a métrica de velocidade errada pode levar a interfaces de usuário lentas ou contas de API desnecessariamente altas. Esta análise fornece uma estrutura para medir essas métricas, selecionar as APIs certas para suas cargas de trabalho específicas e implementar estratégias de otimização.

Principais conclusões

• Time to First Token (TTFT) é a métrica de latência crítica para aplicações interativas, como interfaces de chat, impactando diretamente a velocidade percebida pelo usuário.
• Tokens Per Second (TPS) por stream é a principal métrica de throughput para tarefas de processamento em segundo plano, como resumo de documentos ou extração de dados em massa.
• A arquitetura e o tamanho do modelo ditam o desempenho básico, com modelos menores como DeepSeek V4 Flash ou Gemini 3.5 Flash oferecendo velocidades mais rápidas do que modelos carro-chefe como Claude Fable 5 ou GPT-5.5.
• Roteamento multi-provedor permite que desenvolvedores otimizem para latência ou throughput dinamicamente com base no desempenho do provedor em tempo real.

---

Definindo as métricas principais: Latência vs. Throughput

Para tomar decisões informadas ao comprar ou rotear APIs, os desenvolvedores devem dividir a "velocidade" em componentes distintos e mensuráveis.

Linha do tempo de uma requisição de API de LLM:
[Usuário envia requisição] 
       │
       ▼ (Trânsito de rede + Processamento de prompt)
[Time to First Token (TTFT)] <--- Crítico para UX interativa
       │
       ▼ (Geração autorregressiva: Tokens por segundo)
[Inter-Token Latency (ITL)]  <--- Dita o conforto de leitura
       │
       ▼ (Geração concluída)
[Latência Total]              <--- Crítico para chamadas bloqueantes sem streaming

1. Time to First Token (TTFT)

TTFT é a duração entre o envio de uma requisição de API e o recebimento do primeiro token da resposta. Esta métrica inclui o tempo de ida e volta da rede (round-trip), a serialização do prompt e o tempo necessário para o modelo processar os tokens de entrada (fase de prefill). Para aplicações interativas, o TTFT é a métrica mais importante, pois determina a rapidez com que o usuário vê uma resposta começar a ser transmitida.

2. Inter-Token Latency (ITL)

ITL é o tempo médio decorrido entre a geração de tokens consecutivos durante a fase de streaming. Se o ITL for muito alto, o texto é transmitido mais lentamente do que um humano consegue ler, resultando em uma experiência de usuário frustrante. Um ITL estável e baixo garante uma renderização de texto fluida.

3. Tokens Per Second (TPS)

TPS representa o throughput de geração do modelo. É calculado como o número total de tokens de saída dividido pelo tempo total de geração (excluindo a fase de prefill). Ao avaliar o throughput, os desenvolvedores devem distinguir entre:

• TPS de usuário único: A velocidade de geração de um único stream ativo.
• Throughput do sistema: O número total de tokens que o provedor de API pode processar simultaneamente em todos os usuários ativos.

4. Latência Total

A latência total é a duração completa da requisição de API do início ao fim. Para requisições sem streaming, como extração de JSON estruturado ou classificação em segundo plano, a latência total é a principal métrica a ser monitorada.

---

As compensações arquiteturais: Por que a velocidade varia

A compensação entre latência e throughput de LLMs está enraizada na física das arquiteturas de transformadores e na largura de banda da memória de hardware. Durante a fase de prefill (que determina o TTFT), o cálculo é altamente paralelizável porque todo o prompt de entrada é processado de uma só vez. Esta fase é tipicamente limitada pelo poder computacional (compute-bound).

Durante a fase de geração (que determina o TPS), o modelo gera tokens um por um. Cada novo token requer o carregamento de todos os pesos do modelo da High Bandwidth Memory (HBM) para a SRAM da GPU. Este processo autorregressivo é limitado pela largura de banda da memória (memory-bandwidth bound).

Devido a essas restrições, os desenvolvedores devem alinhar suas escolhas de modelo com seus requisitos de desempenho primários:

• Modelos Carro-chefe: Modelos como Claude Fable 5, Claude Opus 4.8 e GPT-5.5 priorizam a profundidade de raciocínio sobre a velocidade bruta. Eles apresentam contagens massivas de parâmetros, resultando em maior TTFT e menor TPS.
• Modelos rápidos e de baixo custo: Modelos como DeepSeek V4 Flash, Gemini 3.5 Flash e Laguna XS 2.1 são otimizados para velocidade. Eles usam contagens de parâmetros menores, decodificação especulativa ou arquiteturas destiladas para oferecer TTFT excepcionalmente baixo e TPS alto.

Os desenvolvedores podem consultar o TokenLab LLM API Leaderboard for Developers para comparar métricas de velocidade em tempo real entre esses níveis de modelos.

---

Estrutura de decisão: Quando priorizar latência vs. throughput

A prioridade entre latência e throughput depende inteiramente do caso de uso da aplicação.

Caso de Uso	Métrica Primária	Métrica Secundária	Classe de Modelo Recomendada
Chatbots Interativos	Time to First Token (TTFT)	Inter-Token Latency (ITL)	Fast Frontier (ex: Gemini 3.5 Flash)
Assistentes de Programação	TTFT & TPS de stream único	Latência Total	Programação Especializada (ex: Claude Sonnet 5, Kimi K2.7 Code)
Extração de Dados em Massa	Throughput do Sistema	Custo por Tarefa	Open-Weight de Baixo Custo (ex: DeepSeek V4 Flash, GLM-5.2)
Agentes Autônomos	Latência Total (Sem streaming)	TTFT	Open-Weight de Alto Raciocínio (ex: DeepSeek V4 Pro)
Geração de Imagem/Vídeo	Latência Total	Custo por Imagem	APIs de Mídia Especializadas (ex: Nano Banana 2, Seedance)

Aplicações Interativas (Latência em primeiro lugar)

Para UIs conversacionais, bots de suporte ao cliente e assistentes de busca ao vivo, a retenção de usuários cai se o sistema parecer não responsivo. Os desenvolvedores devem priorizar a minimização do TTFT. Mesmo que a geração total leve vários segundos, um TTFT abaixo de 300 milissegundos mantém os usuários engajados.

Processamento em Lote e Pipelines (Throughput em primeiro lugar)

Para tarefas offline, como processar milhares de faturas em PDF, gerar relatórios diários ou executar avaliações em lote, o TTFT é irrelevante. O objetivo é maximizar o volume total de tokens processados por minuto ao menor custo possível. Os desenvolvedores devem focar no throughput do sistema e na eficiência de custos. Para uma análise aprofundada da otimização de custos durante o processamento em lote, veja o TokenLab AI Model Routing Benchmark Cost Per Task.

---

Medindo o desempenho da API: Um exemplo prático de código

Para medir com precisão TTFT, ITL e TPS, os desenvolvedores devem usar APIs de streaming e registrar timestamps em pontos específicos do ciclo de vida da requisição. Abaixo está um script Python executável usando o cliente compatível com OpenAI para medir essas métricas para um determinado modelo.

import time
import os
from openai import OpenAI

# Inicializar cliente (configurado para OpenRouter ou qualquer provedor compatível)
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)

def measure_api_performance(model_name: str, prompt: str):
    print(f"Avaliando métricas de velocidade para: {model_name}")
    
    start_time = time.time()
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    
    ttft = None
    token_timestamps = []
    total_tokens = 0
    
    for chunk in response:
        chunk_time = time.time()
        # Verificar se o conteúdo de texto está presente no chunk
        if chunk.choices and chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            # Estimar contagem de tokens (1 token ≈ 4 caracteres para medição aproximada)
            estimated_tokens = max(1, len(content) // 4)
            total_tokens += estimated_tokens
            
            if ttft is None:
                ttft = chunk_time - start_time
                print(f"-> Time to First Token (TTFT): {ttft:.3f} segundos")
            
            token_timestamps.append(chunk_time)
            
    end_time = time.time()
    total_duration = end_time - start_time
    generation_time = total_duration - ttft if ttft else total_duration
    
    # Calcular Inter-Token Latency (ITL) e Tokens Per Second (TPS)
    if len(token_timestamps) > 1:
        intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
        avg_itl = sum(intervals) / len(intervals)
        tps = total_tokens / generation_time if generation_time > 0 else 0
    else:
        avg_itl = 0
        tps = 0
        
    print(f"-> Latência Total: {total_duration:.3f} segundos")
    print(f"-> Latência Inter-Token Média (ITL): {avg_itl:.3f} segundos")
    print(f"-> Throughput Estimado (TPS): {tps:.2f} tokens/seg")
    print("-" * 50)

# Exemplo de uso com um modelo rápido e de baixo custo
if __name__ == "__main__":
    test_prompt = "Escreva um ensaio de 200 palavras sobre a história da computação."
    # Usando um exemplo de modelo de roteamento de baixo custo atual
    measure_api_performance("google/gemini-3.5-flash", test_prompt)

---

Estratégias de otimização para compradores de API

Se suas medições revelarem que a API escolhida está muito lenta ou muito cara, várias estratégias de otimização podem melhorar o desempenho.

1. Otimização de Prompt e Redução de Prefill

Como a fase de prefill escala com o tamanho do prompt de entrada, reduzir o comprimento do prompt diminui diretamente o TTFT.

• Remova instruções redundantes.
• Use cache de prompt de sistema se suportado pelo provedor. Isso permite que o host da API armazene em cache o estado compilado de um prompt de sistema longo, ignorando o cálculo de prefill em requisições subsequentes.

2. Roteamento Dinâmico de Provedor

De acordo com a documentação de seleção de provedor do OpenRouter, o desempenho de um modelo pode variar significativamente dependendo de qual host subjacente (provedor) atende à requisição. Alguns provedores otimizam para baixa latência, enquanto outros oferecem custos menores à custa da velocidade.

Ao utilizar camadas de roteamento, os desenvolvedores podem:

• Consultar vários provedores para encontrar a menor latência atual.
• Definir caminhos de fallback para que, se um provedor primário sofrer um pico de latência, as requisições sejam roteadas automaticamente para uma alternativa mais rápida.
• Filtrar provedores com base em limites de desempenho específicos.

3. Nivelamento de Modelos (Model Tiering)

Não use modelos carro-chefe como Claude Fable 5 ou GPT-5.5 para tarefas que podem ser tratadas por modelos menores. Implemente um roteador que envie consultas simples (ex: classificação, formatação) para DeepSeek V4 Flash ou GLM-5.2, reservando modelos caros apenas para etapas de raciocínio complexas.

---

Limitações dos benchmarks de velocidade

Ao avaliar métricas de velocidade, os desenvolvedores devem ter em mente as seguintes limitações:

• Variância de Rede: A latência da API é altamente dependente da distância física entre seus servidores de aplicação e a região de hospedagem do provedor de API. Sempre execute benchmarks a partir de servidores localizados na mesma região que sua implantação de produção.
• Congestionamento do Provedor: O throughput e a latência flutuam ao longo do dia com base nos padrões globais de tráfego. Uma única execução de benchmark não representa um desempenho de produção consistente.
• Discrepâncias na Estimativa de Tokens: Modelos diferentes usam tokenizadores diferentes. Um modelo com um TPS maior pode não ser realmente mais rápido se seu tokenizador dividir palavras em tokens menores e mais numerosos do que um modelo concorrente.

---

Perguntas Frequentes

Um throughput (TPS) maior sempre significa uma experiência de usuário mais rápida?

Não. Se uma API tem alto throughput, mas um TTFT ruim, o usuário experimentará uma pausa longa e não responsiva antes que o texto apareça repentinamente na tela. Para aplicações interativas, um TTFT baixo é mais crítico do que um TPS alto.

Como o cache de prompt afeta a latência?

O cache de prompt reduz significativamente o TTFT para prompts longos. Ao armazenar em cache os tokens processados de instruções de sistema ou documentos de contexto, o provedor pula a fase de prefill (que consome muitos recursos) em requisições subsequentes, levando a tempos de resposta mais rápidos.

Devo escolher modelos open-weight ou de código fechado para obter a melhor velocidade?

Depende da infraestrutura de hospedagem. Modelos open-weight como Qwen3.7 Plus, GLM-5.2 ou DeepSeek V4 Pro podem ser implantados em hardware privado dedicado, permitindo que você garanta o throughput. No entanto, APIs gerenciadas de código fechado geralmente usam infraestrutura massiva e otimizada que pode ser difícil de replicar de forma econômica em instâncias privadas. Você pode comparar os rankings de desempenho atuais no TokenLab Model Rankings.

---

Próximos passos

Para otimizar a velocidade e a eficiência de custos da sua aplicação, comece medindo suas cargas de trabalho de produção atuais usando as métricas de streaming descritas acima.

Pronto para avaliar e comparar os modelos mais recentes para seu pipeline de produção? Comece agora com os rankings abrangentes de modelos do TokenLab para encontrar o equilíbrio ideal de latência, throughput e custo para sua aplicação.