Colocar LLM em produção: o gateway que segura custo, latência e queda

Colocar um LLM para responder num notebook é fácil. O openai.chat.completions.create funciona de primeira, a demo impressiona, e todo mundo acha que a parte difícil já passou. Ela não passou — ela só ainda não chegou. A parte difícil é o segundo provedor caindo às 2h da manhã, é a conta triplicando num pico de uso que ninguém previu, é o P99 de latência que só aparece quando o tráfego real bate.

O que separa um POC de IA de um sistema de IA confiável quase nunca é o modelo. É a camada de infraestrutura entre a sua aplicação e o provedor — o gateway de LLM. Se cada serviço da sua empresa fala direto com a API do provedor, você não tem um sistema, você tem uma coleção de integrações frágeis que vão falhar de formas diferentes e no pior momento possível.

Por que "chamar a API direto" não escala

O SDK do provedor resolve o caso feliz. O problema é que produção é feita de casos infelizes:

1. Provedores caem — e caem juntos. Rate limit estourado, região indisponível, degradação silenciosa onde a API responde 200 mas com latência de 40s. Se a sua única saída é um provedor, a disponibilidade do seu produto é a disponibilidade dele. E você não controla o SLA dele.
2. Custo é invisível até virar problema. Sem instrumentação por token, você descobre o gasto no fim do mês, pela fatura. Aí já é tarde para descobrir que um endpoint mal desenhado está mandando 12 mil tokens de contexto para responder "sim" ou "não".
3. Cada time reimplementa a mesma coisa (errado). Retry, timeout, contagem de token, tratamento de erro — replicado em cinco serviços, cada um com um bug diferente. É a receita para inconsistência.

O que o gateway realmente faz

Um gateway de LLM é um ponto único de entrada por onde todo tráfego de inferência passa. Não é um proxy burro; é onde moram as decisões de confiabilidade e custo. As responsabilidades centrais:

Roteamento entre provedores. A aplicação pede "um modelo de raciocínio forte" ou "um modelo barato e rápido para classificação", não "o modelo X do provedor Y". O gateway resolve isso. Trocar de provedor vira uma mudança de configuração, não um deploy em vinte serviços.

Fallback e failover. Provedor primário retornou 429 ou 5xx? Cai para o secundário automaticamente. Aqui vale um alerta honesto: fallback entre modelos diferentes muda o comportamento da resposta. O modelo B pode não seguir o mesmo formato do modelo A, e se você faz parsing estruturado do output, o fallback pode quebrar de um jeito silencioso. Fallback sem teste de compatibilidade de output é uma falha esperando para acontecer.

Rate limiting e quotas. Por time, por feature, por chave. Isso protege o provedor (para você não estourar o limite dele) e protege você de si mesmo (um loop com bug que dispara 100 mil chamadas).

Cache. Semântico ou por chave exata, dependendo do caso. Muita carga de LLM em produção é repetitiva — as mesmas perguntas, os mesmos prompts de sistema. Cache bem colocado corta custo e latência de forma que nenhuma otimização de modelo consegue.

Observabilidade e custo por token. Cada requisição registrada com modelo, tokens de entrada e saída, latência, custo estimado, provedor que atendeu. Sem isso você está pilotando no escuro.

# A aplicação fala com o gateway, nunca com o provedor direto.
# A intenção é semântica ("preciso de raciocínio"), não um SKU de modelo.
resposta = gateway.completar(
    perfil="raciocinio-forte",   # o gateway escolhe modelo/provedor
    mensagens=mensagens,
    tenant="time-cobranca",      # para quota, rate limit e atribuição de custo
    cache="semantico",           # opt-in por chamada
    timeout_ms=8000,
    fallback=True,               # cai para o secundário em 429/5xx
)

O caso do custo por token

Vale insistir nesse ponto porque é onde mais se sangra dinheiro sem perceber. Numa fintech brasileira em escala (grupo global de pagamentos), rodando análise assistida por LLM sobre um volume na casa de milhões de eventos por dia, a diferença entre rotear tudo para o modelo mais caro e rotear por complexidade da tarefa foi de ordem de grandeza na conta mensal. A maioria das chamadas era classificação simples que um modelo pequeno resolve. O modelo grande ficou reservado para os poucos casos que realmente exigiam raciocínio.

Você não descobre isso sem medição por token na camada de gateway. Instrumentar depois, na aplicação, é caro e sempre incompleto. Instrumentar no gateway é de graça — todo mundo já passa por ali.

Latência: onde o tempo realmente vai

Uma armadilha comum: culpar o modelo pela latência quando boa parte do tempo está no seu próprio caminho. Prompt gigante inflando o tempo de processamento, ausência de streaming fazendo o usuário esperar a resposta inteira, cache desligado repetindo trabalho já feito. O gateway é o lugar certo para atacar tudo isso de forma centralizada: streaming como padrão, corte de contexto redundante, cache antes de tocar no provedor.

Não construa tudo de uma vez

Ninguém precisa de um gateway completo no dia um. A ordem que funciona na prática:

1. Primeiro, observabilidade e custo por token. Só de enxergar já muda decisão.
2. Depois, timeout e retry sensatos. Baratos e evitam a maioria dos incidentes bobos.
3. Então, fallback entre provedores — com teste de compatibilidade de output.
4. Por fim, cache e roteamento por complexidade, que é onde a economia grande aparece.

Existem gateways open source e comerciais decentes; construir do zero raramente se justifica no começo. O que não se justifica nunca é seguir chamando o provedor direto de dentro dos serviços e chamar isso de "IA em produção".