AI inference distribuída: reduza a latência em 75% sem trocar o seu modelo

Todo time que tenta otimizar os custos de AI inference esbarra na mesma parede: o modelo fica mais barato, mas a conta continua igual.

Nos últimos seis meses, o Hacker News esteve cheio de projetos fazendo coisas extraordinárias com hardware mínimo: AirLLM rodando modelos de 70B parâmetros em uma única GPU de 4GB, Kimi K3 servindo tokens a $0,50/tok com 29GB de RAM, DeepSeek V4 Flash redefinindo benchmarks de custo-benefício para workloads em produção. O fio condutor é engenheiros descobrindo que o maior driver de custo em inference não é computação.

É distância.

TL;DR: A inference centralizada adiciona 100–180ms de latência de round-trip por requisição e força over-provisioning para manter o p95. Uma camada de pré-processamento distribuído — rodando auth, semantic caching e response streaming perto dos usuários — reduz a carga na origem de inference em 40–60% e a latência global p50 em 75%. Isso não exige trocar o seu provedor de inference. Exige inserir a camada certa na frente do que você já tem.

Por que a inference centralizada de LLM é estruturalmente cara

O deploy padrão funciona assim: o modelo roda em uma região (us-east-1, ou onde quer que esteja o seu cluster de GPU), as requisições chegam de todo lugar, as respostas voltam. Simples de configurar, familiar de operar, e cada vez mais difícil de justificar em escala.

O custo por token continua caindo. Tudo ao redor disso não.

A latência de rede se acumula. Um usuário em São Paulo fazendo requisições para um endpoint de inference na Virgínia adiciona 100–180ms de overhead de round-trip antes que um único token seja gerado. Para respostas em streaming, isso é uma pausa antes que qualquer coisa apareça na tela. Para agent loops fazendo dezenas de chamadas sequenciais, o overhead se empilha em segundos.

Falhas regionais têm blast radius global. Quando o seu endpoint de inference fica em uma região e essa região tem um caminho de rede degradado (ou um evento de energia como o shutdown da usina nuclear que a Hungria enfrentou este verão quando a seca baixou o nível do Danúbio a mínimos históricos), todos os usuários globalmente são afetados.

Over-provisioning é o item oculto da conta. Para lidar com picos de tráfego sem que cold starts destruam o p95, os times mantêm capacidade warm rodando o tempo todo. Com infraestrutura centralizada, você paga por essa capacidade ociosa independentemente de ela estar servindo requisições ou não. Em volume, através de múltiplas geografias, esse custo supera o próprio gasto com inference.

A divisão em três camadas: onde a inference distribuída realmente ajuda

Workloads modernos de inference têm três camadas distintas com perfis de computação diferentes:

1. Tratamento e pré-processamento de requisições: auth, rate limiting, montagem de prompt, injeção de contexto
2. Geração de tokens: a etapa que exige GPU ou hardware acelerado
3. Response streaming e pós-processamento: formatação, filtragem, caching, logging

O erro que a maioria dos times comete é tratar as três como uma unidade e fazer o deploy delas juntas em uma região centralizada. É por isso que você paga custos de latência em operações que não têm nada a ver com geração de tokens.

O princípio do pré-processamento distribuído: As camadas 1 e 3 (tratamento de requisições e processamento de respostas) podem rodar em uma arquitetura distribuída sem cold starts, com menos de 10ms de distância dos usuários, por uma fração do custo de manter essa lógica em um serviço centralizado. Apenas a camada 2, a computação do modelo, precisa ficar onde o hardware está.

Separe o stack nessa fronteira e você obtém:

• Pré-processamento abaixo de 10ms para auth, injeção de contexto e montagem de prompt antes da requisição chegar ao modelo
• Response streaming a partir do ponto de presença mais próximo, entregando tokens sem um round-trip extra à origem
• Semantic caching distribuído: padrões comuns de completion tratados na camada de rede, sem chamada ao modelo
• Failover regional sem re-arquitetura: roteie ao redor de regiões de inference degradadas de forma transparente

Uma implementação concreta

Veja como isso funciona na prática usando Azion Functions com um provedor de inference upstream ou modelo self-hosted:

// Function: auth, rate limiting, cache lookup, proxy para a origem de inference

export default async function handler(request) {
  const authResult = await validateRequest(request);
  if (!authResult.ok) return new Response("Unauthorized", { status: 401 });

  const cacheKey = await buildSemanticCacheKey(request);
  const cached = await azion.cache.get(cacheKey);
  if (cached) return streamFromCache(cached);

  // Só chega à origem de inference em caso de cache miss
  const inferenceResponse = await fetch(INFERENCE_ORIGIN, {
    method: "POST",
    body: await request.arrayBuffer(),
    headers: buildInferenceHeaders(authResult.token),
  });

  // Faz streaming dos tokens para o usuário enquanto escreve no cache
  return streamWithCacheWrite(inferenceResponse, cacheKey);
}

Essa function roda em 300+ pontos de presença globais sem cold starts. Auth, rate limiting e consultas ao cache acontecem na mesma localização do usuário. A origem de inference só vê as requisições que precisam de geração de tokens. Todo o resto é tratado antes de chegar lá.

O impacto no throughput é real. Times que usam esse padrão reportam reduções de 40–60% nas requisições que chegam à origem de inference, porque o semantic caching absorve queries repetidas ou quase idênticas. Para a maioria das features de AI em produção (suporte ao cliente, busca, geração de conteúdo), as distribuições de queries se agrupam em torno de intenções comuns muito mais do que parecem.

Os números que importam

Uma feature de AI em produção servindo 10 milhões de requisições por mês para uma base de usuários global:

O modelo de pré-processamento distribuído, alcançável hoje sem trocar o seu provedor de inference, reduz a latência global p50 em 75% e a carga na origem de inference em até 60%. Isso é uma classe diferente de experiência do usuário.

A economia de custos vem de dois lugares: menos requisições chegando a endpoints de inference pagos (cache hits são baratos), e infraestrutura de origem dimensionada corretamente porque você não está mais fazendo over-provisioning para compensar a latência.

Por que workloads de agentes tornam isso urgente

Inference de disparo único (usuário pergunta, modelo responde) é o caso fácil. Agentes são mais difíceis, e o problema de distância se acumula.

Um agente fazendo 15 tool calls sequenciais, cada um com 150ms de overhead de rede para um endpoint centralizado, acumula 2,25 segundos de latência de rede pura por agent loop. Antes de qualquer computação do modelo. Para agentes rodando múltiplos loops, você está em 10–20 segundos de overhead só de rede.

O pré-processamento distribuído resolve o loop externo: lógica de orquestração, roteamento de tool calls, gestão de contexto e caching entre etapas podem rodar perto do usuário. As chamadas ao modelo ainda vão para onde o hardware está, mas o overhead do agent loop cai drasticamente.

Times construindo agentes em produção focados em responsividade já estão dividindo seus stacks dessa forma. Os que não estão estão batendo num teto onde a experiência do usuário degrada mais rápido do que as melhorias de modelo compensam.

Por que modelos mais baratos ampliam o gap de arquitetura

À medida que os modelos ficam menores e mais eficientes (Qwen3.8B, DeepSeek Flash, Kimi K3), o caso para arquitetura distribuída fica mais urgente.

Modelos menores reduzem o custo por token. O que significa que o overhead de rede e o custo de pré-processamento se tornam uma fatia maior da sua estrutura de custo total. Um modelo de $0,001/1K tokens rodando atrás de 180ms de latência de rede evitável tem um perfil de custo efetivo pior do que um modelo de $0,003/1K tokens rodando com 20ms de overhead, porque a latência aparece como churn de usuários e over-provisioning em vez de aparecer como uma linha na sua conta de inference.

Melhorias na eficiência do modelo não corrigem ineficiência arquitetural. As duas curvas são independentes, e ignorar a curva de infraestrutura enquanto se celebra a curva do modelo é como times acabam com modelos rápidos entregando produtos lentos.

Como começar sem substituir sua configuração de inference

A migração não exige tocar no seu provedor de inference. Exige inserir uma camada distribuída na frente dele.

Três mudanças para começar:

1. Mova auth e rate limiting para a camada distribuída. Cada requisição de inference chegando à sua origem para fazer auth paga latência desnecessária. Azion Functions tratam isso em menos de 1ms, globalmente, sem cold starts.

2. Adicione semantic caching na camada de rede. Você não precisa de um modelo de similaridade sofisticado. Normalizar e fazer hash dos prompts captura 20–40% de cache hit rates na maioria dos workloads em produção.

3. Roteie por geografia. Se você tem capacidade de inference em múltiplas regiões, rotear requisições para a região mais próxima em vez de round-robinar para uma origem única é uma mudança de uma linha com impacto mensurável na latência.

Nenhuma dessas mudanças exige alterar o seu modelo, o seu provedor de inference ou o código da sua aplicação. Exigem colocar a camada certa na frente do que você já tem.

A conversa sobre custo de AI inference está em grande parte focada na camada do modelo: modelos menores, quantização, kernels eficientes. Esse trabalho importa. Mas os engenheiros colocando features de AI em produção em escala continuam chegando à mesma conclusão: a camada do modelo é só metade do problema.

A outra metade é tudo entre o modelo e o usuário. Essa metade já está resolvida, se você construir a arquitetura para aproveitar.

A Azion Web Platform roda execução distribuída sem cold starts em 300+ pontos de presença globais. Azion Functions tratam pré-processamento de requisições, caching e response streaming sem tocar na sua infraestrutura de inference. Veja a documentação →

Perguntas frequentes

Por que a inference de LLM ainda é cara mesmo com modelos mais baratos? Modelos mais baratos reduzem o custo por token, mas a latência de round-trip de rede e o over-provisioning permanecem constantes independentemente do preço do modelo. Um usuário em São Paulo chamando um endpoint de inference na Virgínia adiciona 100–180ms antes que um único token seja gerado. Para compensar, os times fazem over-provision de capacidade warm, pagando por computação ociosa o tempo todo. Esses custos de infraestrutura não aparecem na sua conta de inference, mas podem superá-la em escala.

O que é AI inference distribuída? A AI inference distribuída separa o tratamento de requisições e o response streaming da geração de tokens. Auth, rate limiting, montagem de prompt e semantic caching rodam em pontos de presença globais perto dos usuários, adicionando menos de 10ms de overhead. Apenas as requisições que erram o cache chegam à origem de inference para geração de tokens. Isso reduz a carga da origem em 40–60% e a latência global p50 em até 75% sem alterar o modelo ou o provedor de inference.

Quanto o semantic caching reduz os custos de inference de LLM? O semantic caching na camada de rede captura 20–40% de cache hit rates na maioria dos workloads de AI em produção. Aplicações de suporte ao cliente, busca e geração de conteúdo veem taxas mais altas porque as distribuições de queries se agrupam em torno de intenções comuns. Cada cache hit elimina uma chamada de inference por completo, reduzindo a geração de tokens pagos proporcionalmente.

Por que a latência de inference se acumula dentro de pipelines de agentes de AI? Agentes de AI encadeiam múltiplas chamadas de função por tarefa. Uma cadeia de quatro tool calls em que cada função adiciona 150ms de overhead de round-trip de rede acumula 600ms de latência de rede pura por agent loop, antes de qualquer computação do modelo rodar. Para agentes rodando múltiplos loops, isso se torna segundos. O tratamento distribuído de requisições elimina a maior parte desse overhead ao rodar a lógica de orquestração perto do usuário.

Qual é a diferença de custo de infraestrutura entre inference centralizada e distribuída? Para uma feature de AI em produção servindo 10 milhões de requisições por mês de uma base de usuários global, a inference centralizada em uma única região custa estimados $12.000–18.000/mês incluindo over-provisioning para p95. Adicionar uma camada de pré-processamento distribuído reduz para $5.000–8.000/mês enquanto reduz a latência global p50 de ~340ms para ~85ms.

A inference distribuída exige trocar o meu provedor de inference? Não. A camada distribuída fica na frente do seu endpoint de inference existente. Auth, rate limiting, semantic caching e response streaming rodam em pontos de presença globais. A origem de inference permanece inalterada. Ela simplesmente recebe menos requisições porque o cache absorve as queries repetidas antes de chegarem lá.

Como o tamanho menor do modelo afeta o caso para inference distribuída? À medida que o custo por token cai com modelos menores, o overhead de rede e o over-provisioning se tornam uma fatia maior do custo total de inference. Um modelo de $0,001/1K tokens rodando atrás de 180ms de latência de rede evitável tem um perfil de custo efetivo pior do que um modelo de $0,003/1K tokens com 20ms de overhead, porque a latência aparece como churn de usuários e over-provisioning em vez de aparecer como uma linha na conta de inference. Os ganhos de eficiência dos modelos aceleram o argumento para corrigir a ineficiência de infraestrutura.