LLM gateway: por que a latência cresce com o contexto?

Um LLM gateway gastava 553 ms de TTFB antes de chamar o modelo numa conversa de 439.945 tokens, com 334 turnos e 18 ferramentas. Depois de cortar três etapas de pré-voo, o mesmo caminho respondeu em 35 ms, num benchmark publicado em 3 de outubro de 2026 por um projeto de gateway de LLM de código aberto.

A medição separa duas coisas que a fatura junta: o trabalho que o gateway executa entre a chegada da requisição e o repasse ao provedor, e o tempo que o modelo leva para emitir o primeiro token. Com um provedor que respondia de imediato, o que sobra no cronômetro pertence ao caminho. Numa sessão de código longa, esse caminho cobra pelo histórico acumulado, e o histórico só cresce: a etapa mais cara relia a conversa inteira para responder sim ou não sobre cache. O gargalo estava antes da chamada.

Quais números o benchmark de 3 de outubro publica?

Nove números, uma fonte, duas rotas e uma máquina. Cada linha pode ser citada isoladamente desde que carregue a atribuição: um benchmark publicado em 3 de outubro de 2026 por um projeto de gateway de LLM de código aberto, rodado em ambiente local.

1. 553 ms. TTFB mediano do caminho de chat completions antes da correção, com o provedor respondendo de imediato.
2. 35 ms. O mesmo caminho, depois.
3. 94%. Redução no TTFB mediano do caminho de chat completions.
4. 542 ms. TTFB mediano no endpoint de Messages, antes da correção.
5. 40 ms. O mesmo endpoint, depois.
6. 439.945 tokens. Tamanho da conversa usada no teste.
7. 334 turnos. Pares de requisição e resposta na mesma conversa, com resultados de ferramenta no meio.
8. 18 ferramentas. Ferramentas disponíveis na sessão.
9. Três requisições. A mediana de cada ponto, medida depois de um aquecimento.

Duas ressalvas valem. Os números vêm de duas rotas medidas numa máquina local, não de tráfego de produção: não há p50, p95 nem p99, e a mediana de três requisições é toda a estatística. E os 94% pertencem ao TTFB mediano do caminho de chat completions, nesse desenho.

Como esse benchmark foi feito?

O caminho de requisição rodou em Python, com um único deployment saudável, cache de resposta em Redis, checagem de prompt caching habilitada e um provedor de teste que respondia de imediato. Cada ponto é a mediana de três requisições após um aquecimento, na mesma máquina local, em duas rotas.

O upstream instantâneo é o que dá sentido ao desenho. Com um provedor real no fim da linha, o TTFB mistura o tempo do gateway com a fila e o pré-preenchimento do modelo, e não há como separar os dois só pelo número. Com algo que responde no mesmo instante, o que resta é o caminho.

O deployment único trabalha pelo mesmo princípio: com uma só rota saudável não existe decisão a tomar. O teste mede, então, o caso em que a pergunta de elegibilidade não decidia nada. O que falta: distribuição, cauda e preço.

De onde vinham os 518 ms que o LLM gateway gastava antes da chamada?

Três etapas da versão anterior respondem pelos 518 ms. A maior delas era uma checagem opcional de prompt caching que contava a conversa inteira para responder se o texto atingia o mínimo de tamanho que o deployment exige para reaproveitar o prefixo, que é definido por modelo e neste gateway medido fica em 1.024 tokens. As outras duas: hash de prefixo e busca de cache pin.

A checagem tinha motivo defensável: manter a requisição num deployment com cache economiza computação do lado do modelo. O problema era o método. A resposta é sim ou não, e o gateway lia tudo.

Numa sessão de código com centenas de turnos e resultados de ferramenta, essa contagem podia significar centenas de milissegundos de trabalho em Python antes da chamada ao modelo. O gateway lia o histórico inteiro para decidir se valia mandar o histórico inteiro a um deployment com cache.

Os 518 ms somam as três etapas que a versão nova pula, e a contagem responde pela parte que cresce com a conversa. Os 35 ms que sobram não são resíduo delas: no caminho medido as três etapas são puladas por inteiro, e o que fica no cronômetro é o resto do caminho na mesma máquina, o mesmo que a Figura 1 rotula de resíduo do caminho.

A pergunta custava mais do que a resposta.

Convém separar dois caches que aparecem juntos nesta conversa. O cache de prompt do provedor guarda representações de chave e valor e os hashes dos blocos cacheados, em memória, com TTL de minutos ou de uma hora, e não o prefixo como texto nem em repouso. A transferência de KV cache entre modelos é outra técnica, de infraestrutura, e não o reaproveitamento de prefixo por requisição. A decisão de cache no gateway é outra coisa: a pergunta sobre onde a requisição deve cair.

Por que o custo cresce com o tamanho da conversa?

O custo crescia porque a etapa percorria o texto que chegava. O trabalho acompanha tokens e turnos, e a carga agêntica maximiza os dois: cada resultado de ferramenta entra no histórico, o histórico volta inteiro na requisição seguinte, e a sessão que mais precisa de contexto é a que mais paga.

Isso é leitura de mecanismo, não medição direta. A etapa percorria a conversa inteira, então o custo removido acompanha o texto contado, com a ressalva de que a fonte publica um ponto, não uma curva. Taxa em milissegundos por token não existe, e uma regressão de overhead contra contexto seria invenção.

Uma decisão de roteamento que examine o texto consome o insumo sobre o qual decide. Em prompt curto, a conta é irrelevante. Em conversa de 439.945 tokens, as três etapas de pré-voo somavam 518 ms, e o que o modelo gasta depois disso não está medido.

Quando o preço empata, a latência vira a variável da rota, e a que decide ali é a do modelo, medida por quem serve a inferência. A latência deste texto é a do caminho até o modelo.

O que muda quando existe mais de um deployment?

O caminho muda, o cache não. Com um único deployment saudável não existe rota a escolher, e a versão nova pula a checagem de elegibilidade, o hash de prefixo e a busca de cache pin. Com vários deployments, a contagem para na primeira mensagem que atinge o mínimo de tamanho que o deployment exige para reaproveitar o prefixo. Esse mínimo é definido por modelo, e a faixa vai de 512 a 4.096 tokens; neste gateway medido o corte acontece em 1.024 tokens. Afinidade e hash continuam em uso.

A correção para o caso multi-deployment separa overhead de funcionalidade. Ninguém desligou o prompt caching. A pergunta continuou existindo, com um teto: para de contar quando a resposta já é conhecida. O custo da decisão de roteamento de LLM cai porque ela não percorre mais a conversa inteira para responder algo que a primeira mensagem resolvia.

O terceiro caminho, o endpoint /v1/responses, já ignorava a checagem e ficou aproximadamente estável. A contabilização de uso não mudou em nenhum ramo.

A economia de cache read no roteamento é aritmética de preço: quanto custa ler um prefixo já cacheado. O que este benchmark mede é o preço de decidir quem pode ler o cache: o custo da decisão, não a economia que ela compra. Com upstream instantâneo não há prefill real, então o ganho do cache fica inobservável neste desenho.

O que muda no orçamento de latência de uma aplicação?

O que muda é a forma da soma. O TTFB é o trabalho de pré-voo do gateway, mais a rede, mais a fila do provedor, mais o prefill e a primeira decodificação do modelo. O pré-voo cresce com aquilo que o resto da soma consome. Em gateways que fazem trabalho proporcional ao contexto antes do despacho, como o medido aqui, overhead medido com prompt curto subestima a latência de uma carga agêntica. Num gateway que escolhe rota por metadados, saúde de deployment e tabela de custo, o pré-voo não cresce com a conversa, e a subestimação não aparece.

Os valores vêm do benchmark de 3 de outubro de 2026, mediana de três requisições após aquecimento na mesma máquina. As duas colunas da direita são subtrações das medianas publicadas.

A consequência para quem arquiteta é desconfortável. Um orçamento de latência montado com medição de prompt curto não vale para a carga agêntica, medida aqui numa sessão de código de 439.945 tokens e 334 turnos. A decisão de roteamento de LLM por latência passa a precisar dos dois termos da soma.

Ler o número alheio exige a mesma disciplina, e as métricas de benchmark de roteador separam o que a medição cobre do que ela só sugere. Um TTFB de 35 ms com upstream instantâneo não é o que o usuário sente. É o piso do caminho.

Como medir o overhead do seu gateway com contexto longo

Sete passos, e cada um evita um erro específico. O desenho parte do benchmark de 3 de outubro de 2026, aplicado ao seu tráfego: conversa real longa, upstream imediato, amostra suficiente para percentis, concorrência, fronteira de medição, rotas medidas em separado e comparação com a checagem ligada e desligada.

1. Capture uma conversa real longa. Use uma sessão que já aconteceu, com turnos e resultados de ferramenta. Evita medir com prompt de brinquedo e concluir que o overhead de gateway é pequeno.
2. Aponte para um upstream que responde de imediato. Evita misturar geração do modelo com trabalho do caminho.
3. Amostre o suficiente para p95 e p99. Mediana de três requisições não descreve cauda. Descarte o aquecimento e publique percentis. Evita esconder um p99 que desaba.
4. Meça cada rota separadamente. Evita uma média que esconde a rota que dói.
5. Meça sob concorrência. O benchmark é serial. Contagem de tokens em Python dentro de um gateway assíncrono é trabalho CPU-bound no mesmo processo: ocupa o event loop e bloqueia toda requisição concorrente do mesmo worker. Evita aceitar uma mediana serial enquanto o p99 com dezenas de sessões simultâneas colapsa.
6. Meça dentro do processo ou no mesmo host. TTFB medido no cliente inclui TCP, TLS e RTT, e num corpo de 439.945 tokens a ida e volta e a transmissão podem exceder o efeito medido. Evita atribuir ao pré-voo o que é rede.
7. Repita com a checagem ligada e desligada. Só a diferença entre as rodadas pertence ao pré-voo. Evita creditar a melhoria a outra mudança.

Esse desenho responde pelo formato da carga. A distribuição em tráfego real ainda pede o método para p50, p95 e p99 em medir o overhead operacional de um gateway: uma peça mede a distribuição, a outra mede como o overhead de gateway muda com a conversa.

O que o Nexforce Router entrega nessa camada

O Router entrega as três coisas que esse desenho exige, e nenhuma delas é promessa de latência menor. O Router escolhe rota por custo, desempenho, latência e contexto, guarda cache de respostas e de embeddings, e mantém trace completo de cada chamada com logs, métricas e alertas no mesmo lugar.

A seleção por latência conversa com o orçamento descrito acima: quem decide rota sem saber quanto do TTFB é pré-voo otimiza o termo errado da soma. O trace resolve o mesmo problema por outro ângulo, porque sem registro por chamada o overhead pago não aparece na fatura nem no painel do provedor.

Vale registrar o limite. Nenhum número de latência do Router entra aqui, porque não existe medição pública que sustente um. O produto entrega a camada onde a medição acontece.

Perguntas frequentes

O que é TTFB em uma chamada de LLM? É o tempo entre o início da requisição e o primeiro byte da resposta, a definição de TTFB na documentação da MDN, que vale igual para uma chamada de modelo. Numa chamada de LLM ele soma cinco parcelas: o trabalho de pré-voo do gateway, a rede, a fila do provedor, o prefill e a primeira decodificação do modelo.

O que é prompt caching e por que ele influencia a rota? É o reaproveitamento de um prefixo já processado, para o provedor não recalcular o mesmo trecho a cada turno, como descreve a documentação de prompt caching da Anthropic. Influencia a rota porque nem todo deployment reaproveita o prefixo, e a elegibilidade depende de o prompt atingir o mínimo em tokens daquele modelo. A documentação não fixa uma constante: a faixa vai de 512 a 4.096 tokens e o valor é definido por modelo, então vale conferir o modelo que você usa, e neste gateway medido o corte acontece em 1.024 tokens.

Por que contar tokens antes da chamada pode custar caro? Porque contar exige percorrer o texto, e o texto de uma sessão longa é o ativo mais pesado do caminho. Numa conversa de 439.945 tokens, com 334 turnos e 18 ferramentas, a contagem podia significar centenas de milissegundos de Python antes da chamada ao modelo, segundo o benchmark de 3 de outubro de 2026.

94% de redução significa que meu gateway pode ficar 94% mais rápido? Não. O número vale para o TTFB mediano do caminho de chat completions, numa conversa de 439.945 tokens, com um deployment saudável e um provedor que respondia de imediato, mediana de três requisições numa máquina local. Ele mede a remoção de três etapas de pré-voo nesse desenho, que não inclui fila de provedor, rede nem tráfego real.

Referências e Leitura Complementar

A fonte numérica é um benchmark publicado em 3 de outubro de 2026 por um projeto de gateway de LLM de código aberto, em ambiente local, com leitura integral em 22 de outubro de 2026. A atribuição é por categoria e data porque o projeto é concorrente e não é nomeado em nenhuma superfície publicada.

• Definição de Time to First Byte, documentação da MDN
• Prompt caching, documentação da Anthropic

A leitura complementar interna está no corpo, nos cinco textos citados ao longo das seções. Nenhum link aponta para o projeto medido.

A conta que não entra na planilha de latência

O item mais caro do orçamento de latência foi uma pergunta que o gateway fazia a si mesmo. A chamada ao modelo, a fila do provedor e o tamanho da resposta ficam de fora. O que pesa é a contabilidade interna que decide onde a requisição deve cair, executada em toda requisição, sobre o texto que chegou.

Duas ações, nesta ordem. Primeiro, medir o TTFB com uma conversa real longa e um upstream instantâneo, porque o número medido com prompt curto não descreve a carga que importa. Depois, revisar o que roda antes da chamada e perguntar, item por item, se aquilo precisa rodar em toda requisição.

O limite honesto: nenhum dado público diz com que frequência esse padrão aparece em outros gateways. O que existe é uma medição datada, num caminho, com desenho explícito, e um mecanismo que qualquer gateway que decida rota pode reproduzir.

Como citar: benchmark publicado em 3 de outubro de 2026 por um projeto de gateway de LLM de código aberto, rodado em ambiente local, com leitura em 22 de outubro de 2026. Atualização: revisão quando houver nova medição pública do mesmo caminho.