Como Desenhamos Nossa Infra de Inferência LLM Multi-Provider (e Por Que Roteamento Importa Mais que Modelo)
Arquitetura técnica de infra de inferência LLM com três provedores, roteamento por intenção, fallback e observabilidade. Decisões de engenharia e trade-offs reais.
Todo provedor de IA enfrenta o mesmo dilema de infraestrutura: os modelos precisam estar próximos da origem do pedido para responder rápido, mas cada chamada a modelo de primeira linha tem custo unitário que não escala linearmente com volume.
A gente precisava de uma solução que usasse nossa estrutura atual sem esperar nova fase de investimento. E precisava ser modular o suficiente para substituir qualquer componente sem parar operação. Este texto descreve a arquitetura que a gente desenhou, por que escolheu cada decisão e quais foram os trade-offs reais.
O Problema
Antes do redesenho, a gente tinha o padrão que quase toda operação de IA em produção tem: um provedor único, integração direta do código cliente com a API do provedor, sem camada intermediária de controle.
Consequências operacionais desse padrão, observadas em 6 meses de operação:
- Custo imprevisível: picos de tráfego estouravam orçamento mensal em dias de campanha.
- Latência acoplada ao provedor: quando o provedor tinha incidente, a operação toda parava.
- Vendor lock-in real: trocar de provedor exigia mexer em centenas de pontos de integração.
- Zero observabilidade fina: a gente sabia quanto gastava mas não sabia onde.
- Modelo caro rodando tarefa barata: classificação de intenção rodando em modelo de ponta custava 12x o necessário.
Os options disponíveis não resolviam. Camada de abstração genérica perdia as capacidades específicas de cada provedor. Proxy simples gerava nova ponto único de falha. Escolhemos desenhar nossa própria camada de roteamento.
A Arquitetura em 5 Componentes
Componentes descritos do pedido do cliente até o retorno da resposta.
1. Edge Gateway
Recebe todo pedido de inferência, aplica autenticação, rate limiting por tenant e enriquece o pedido com metadados de contexto (qual cliente, qual fluxo, qual SLA). Nenhum código de aplicação conversa diretamente com provedor. Sempre passa pelo gateway.
Decisão importante: rate limiting é por tenant, não global. Cliente que fez contratação de plano alto nunca é afetado por spike de tráfego de cliente de plano baixo.
2. Intent Router
Classifica o pedido em uma de sete categorias de intenção — classificação simples, extração de dados, conversa casual, conversa crítica, geração de conteúdo longo, raciocínio complexo, execução de ferramentas — e encaminha para o pool de modelos adequado.
A classificação em si roda em modelo pequeno local que custa R$ 0,002 por classificação. Depois desse passo, 40% do tráfego vai para modelo barato, 35% para modelo médio, 25% para modelo de ponta.
Impacto direto no custo: queda de 47% no custo por interação nas primeiras quatro semanas.
3. Provider Pool
Para cada categoria de intenção, a gente mantém três provedores candidatos em ordem de preferência. Se o primário falha ou excede SLA, o pedido é redirecionado ao secundário automaticamente sem intervenção humana.
Configuração atual:
| Categoria | Primário | Secundário | Terciário |
|---|---|---|---|
| Classificação | Modelo pequeno local | Provedor barato A | Provedor barato B |
| Extração | Provedor médio A | Provedor médio B | Modelo local grande |
| Conversa crítica | Provedor premium A | Provedor premium B | Provedor médio A |
| Raciocínio profundo | Provedor premium A | Provedor premium B | — |
Nenhum fluxo crítico tem provedor único. Incidente em um provedor nunca derruba operação inteira.
4. Tool Use Broker
Quando o modelo decide chamar uma ferramenta, o broker intercepta a chamada, valida contra schema esperado, executa e devolve resultado. Broker também aplica autorização (este cliente pode chamar esta ferramenta?) e timeout.
Separar tool use em broker dedicado permitiu duas coisas importantes: auditoria completa de cada ação executada pelo agente e possibilidade de mockar ferramentas em ambiente de teste sem recriar integração inteira.
5. Observability Layer
Cada etapa — pedido, classificação, escolha de provedor, tool call, resposta final — emite evento estruturado para pipeline de métricas. A gente consegue responder em tempo real:
- Qual tenant consome mais por tipo de intenção
- Qual provedor tem maior latência p99 na última hora
- Qual prompt está mais próximo do limite de tokens
- Quais ferramentas estão sendo chamadas mais frequentemente e por quê
Sem este componente, otimização é chute. Com ele, cada decisão técnica tem dado por trás.
Trade-offs Que Tivemos Que Aceitar
Nenhuma arquitetura é grátis. Os três preços que pagamos:
Complexidade operacional. A camada de roteamento adiciona um componente que precisa ser mantido, monitorado e escalado. Time precisou aprender a operar isso.
Latência base maior. Cada pedido passa por gateway, router e broker antes de chegar ao provedor. Isso adiciona 80-120 ms ao caminho crítico. Aceitamos porque ganhamos em tudo o resto.
Esforço inicial alto. Desenhar e construir isso levou 9 semanas com dois engenheiros. Para operação pequena, não vale. Para operação com volume, paga o investimento em 3-4 meses só na economia de custo.
Lições que Aplicamos
Cinco aprendizados das primeiras 16 semanas operando essa arquitetura.
Observabilidade é a primeira coisa, não a última. A gente construiu os outros componentes primeiro e a observabilidade depois. Isso gerou dois meses operando no escuro. Se fosse refazer, começaria pela observabilidade.
Modelo bom em inglês não é modelo bom em português brasileiro. Modelo que brilha em benchmark internacional às vezes gera frase estranha em pt-BR. Teste com dado real do seu domínio antes de colocar em produção.
Fallback automático não substitui plano B humano. Quando três provedores caem simultaneamente (aconteceu uma vez), o automatic fallback não serve. Precisa existir procedimento manual de degradação graciosa.
Cache agressivo em classificação e extração. 30% das chamadas de classificação são repetição exata da mesma frase. Cache de 1 hora economizou 18% adicional do custo.
Rate limiting por tenant desde o dia 1. Sem isto, o cliente barulhento afoga o cliente silencioso. Aprendemos caro.
O Que Não Resolvemos (Ainda)
Nem tudo está pronto. Três problemas abertos:
Roteamento dinâmico por SLA. Hoje a ordem de preferência é estática. Idealmente, o roteador deveria aprender em tempo real qual provedor está melhor para cada categoria em cada janela do dia.
Cost attribution por fluxo de negócio. Sabemos custo por tenant e por categoria de intenção. Falta amarrar isso a fluxo específico de produto (qualificação de lead, pós-venda, renovação).
Experimentação A/B entre modelos. Rodar 10% do tráfego em modelo alternativo para comparar qualidade em dado real exige infra que ainda não construímos.
Conclusão
A discussão em conferência é sempre qual modelo escolher. A decisão real em produção é como rotear tráfego entre modelos. Roteamento bem desenhado vale mais que escolher o melhor modelo isoladamente.
Se você quer discutir arquitetura de infra de inferência para sua operação, agende uma análise gratuita.
Sakaguchi IA — Inteligência Artificial para Empresas Brasileiras