Arquitetura Multi-LLM: Como Construir Para Não Depender de Um Único Provider (Depois do Ban do Fable 5)

Em 19 de junho de 2026, escrevi aqui sobre o risco operacional concreto do export control que derrubou o Claude Fable 5: um modelo que você usa hoje pode ser desligado amanhã à noite por ordem do governo americano, sem aviso prévio e sem grace period. A pergunta que mais chegou depois daquele post, nos comentários e no LinkedIn, foi a mais óbvia: "ok, e o que eu faço com isso na prática?"

Esse post é a resposta. Não a resposta de "diversifique seus providers por precaução" — essa é óbvia e qualquer pessoa com acesso ao HN já sabe. A resposta arquitetural concreta: como você estrutura o código e a infraestrutura de forma que trocar de provider, rotear entre providers ou fazer fallback em caso de falha seja uma operação de configuração, não uma refatoração de emergência num momento em que você está com o sistema fora do ar e o CEO ligando.

O Problema Que o Export Control Tornou Visível (Mas Que Sempre Existiu)

Provider lock-in em LLMs não nasceu em junho de 2026 com o export control. Ele existia antes, com um conjunto diferente de riscos: mudanças de preço unilaterais, descontinuação de modelos (lembra do GPT-3.5 sendo retirado do default?), degradação silenciosa de performance depois de um update de modelo sem versioning, outage de provider numa sexta à noite. O ban do Fable 5 foi o evento que tornou o risco tangível de uma forma que nenhuma discussão acadêmica sobre lock-in conseguia.

O que torna o problema arquiteturalmente interessante é que ele não é apenas "tenha um plano B". É que a maioria dos sistemas de produção com LLMs foi construída com a chamada ao modelo diretamente no código da aplicação: a URL do endpoint, o nome do modelo, os parâmetros, o parsing do response — tudo acoplado ao provider específico. Quando você precisa trocar o provider, você não está mudando uma config. Você está refatorando código de aplicação em pânico, com tempo de indisponibilidade se acumulando.

A solução não é nova — é o mesmo princípio que resolveu vendor lock-in em bancos de dados, cloud providers e message queues há décadas: uma camada de abstração entre o consumidor e o provider. No mundo de LLMs, essa camada tem um nome específico em 2026: LLM gateway.

O Que é um LLM Gateway e Por Que Você Precisa de Um

Um LLM gateway é um proxy que fica entre a sua aplicação e os providers de LLM. A sua aplicação faz uma chamada única, padronizada, para o gateway. O gateway traduz essa chamada para o formato do provider configurado, gerencia retries, fallbacks, caching e roteamento, e retorna a resposta num formato unificado para a aplicação. Do ponto de vista do código da aplicação, não existe diferença entre chamar Claude, GPT ou Gemini — existe apenas "chamar o LLM".

O LiteLLM é hoje a opção open-source mais adotada para esse papel, com suporte a mais de 100 providers e uma API que replica o formato da OpenAI (o que o torna compatível com a maioria dos SDKs existentes sem mudança de código). O Portkey oferece funcionalidades similares com foco em observabilidade e enterprise. Cloudflare Workers AI e Vercel têm suas próprias implementações de gateway com foco em edge delivery.

O valor central de ter um gateway não é só fallback automático. É que ele centraliza todos os cross-cutting concerns da camada de LLM:

Roteamento: você pode definir regras de roteamento por tipo de tarefa, custo, latência ou provider disponível. Tarefas de codificação vão para o modelo A, tarefas de sumarização vão para o modelo B (mais barato), tarefas que precisam de grounding em tempo real vão para o modelo C. Sem gateway, esse roteamento fica espalhado pelo código de aplicação em condicionais.

Caching semântico: respostas para prompts similares podem ser cacheadas e reutilizadas, reduzindo custo e latência. O gateway implementa isso centralmente sem que o código de aplicação precise saber.

Observabilidade: latência por provider, custo por chamada, taxa de erro, token usage — tudo centralizado num único ponto de instrumentação.

Budget enforcement: limites de gasto por aplicação, por usuário ou por período, aplicados antes que a chamada chegue ao provider.

Failover vs Fallback: A Distinção Que Importa Na Hora de Configurar

Uma distinção que aparece em documentação de produção de LLM gateways mas raramente em posts de introdução: failover e fallback são estratégias diferentes, para tipos de falha diferentes, e configurar as duas da mesma forma é um erro comum.

Failover trata de falhas de infraestrutura: o provider retornou 5xx, deu timeout, a rede caiu entre você e o endpoint. Nesses casos, você quer tentar o próximo provider da lista automaticamente, com o mesmo prompt e os mesmos parâmetros, sem intervenção humana. Failover é transparente para o usuário — a chamada leva mais tempo, mas o resultado é o mesmo que você esperaria do provider primário.

Fallback trata de falhas semânticas: o provider retornou 429 (rate limit), o prompt excedeu a janela de contexto do modelo primário, o modelo foi bloqueado por política de uso (como aconteceu com o Fable 5), ou a qualidade do output ficou abaixo do threshold mínimo que você definiu. Nesses casos, você precisa de lógica diferente: talvez um modelo alternativo com janela de contexto maior, talvez uma versão comprimida do prompt, talvez um modelo menos capaz mas disponível para cases de degradação aceitável.

A regra prática: configure failover para todos os providers no gateway como default, com lista ordenada por preferência. Configure fallback explicitamente por tipo de falha semântica que você conhece do seu sistema. Não misture os dois no mesmo pool — você vai acabar fazendo fallback para um provider caro quando devia estar só retentando o primário.

Como Estruturar Multi-Provider Sem Virar Spaghetti de Condicionais

O erro mais comum que vejo em times que tentam implementar multi-provider sem gateway é o seguinte padrão:

if model_primary_available:
    response = call_claude(prompt)
elif model_secondary_available:
    response = call_gpt(prompt)
else:
    response = call_gemini(prompt)

Isso parece razoável até o momento em que você precisa adicionar lógica de retry, caching, token counting, observabilidade e budget enforcement. Em dois meses, o arquivo que tinha 30 linhas tem 300, e ninguém mais quer mexer nele.

A estrutura que funciona em produção separa três responsabilidades:

1. Especificação da intenção (sem referência ao provider):

response = llm_client.complete(
    messages=messages,
    task_type="code_review",  # ou "summarization", "analysis"
    max_cost_cents=5,
    required_context_tokens=50000
)

O código de aplicação não sabe qual provider vai responder. Ele especifica o que precisa (tipo de tarefa, budget, tamanho de contexto necessário) e o gateway resolve.

2. Política de roteamento no gateway (configuração, não código):

routing_policies:
  code_review:
    primary: claude-opus
    fallback_on_429: gpt-5
    fallback_on_export_block: gemini-pro
    max_tokens: 100000
  summarization:
    primary: gemini-flash  # mais barato
    fallback_on_5xx: claude-haiku

Quando o Fable 5 foi bloqueado por export control, o que um time com essa estrutura precisou fazer foi adicionar uma linha na configuração de fallback. Sem toque no código de aplicação. Sem deploy de emergência. Sem debug de comportamento inesperado em produção.

3. Abstração de formato de resposta: O gateway normaliza o response de qualquer provider para o formato que a aplicação espera. Você não lida com a diferença entre choices[0].message.content da OpenAI e content[0].text da Anthropic no código da aplicação. O gateway faz essa tradução.

O Que Fazer Agora se Você Não Tem Gateway

Se você hoje não tem uma camada de abstração entre a aplicação e o LLM provider, a migração não precisa ser big bang. O caminho incremental que funciona:

Semana 1: Crie um módulo interno de wrapper que isola todas as chamadas ao LLM num único lugar. Nada mais no codebase chama o SDK do provider diretamente — tudo passa pelo wrapper. Isso não resolve failover ainda, mas consolida o surface area do problema.

Semana 2-3: Coloque o LiteLLM (ou equivalente) na frente do wrapper. Substitua a chamada direta ao SDK pelo LiteLLM. A aplicação não muda — só o wrapper. Agora você tem a infraestrutura de routing e fallback disponível sem tocar no código de feature.

Semana 4: Configure a política de roteamento e o primeiro fallback real. Teste o failover ativamente — desligue o provider primário intencionalmente e valide que o fallback funciona como esperado. Isso é o único jeito de saber que funciona antes de precisar que funcione.

A regra geral: se o seu sistema de produção tem menos de um dia de trabalho de engenharia para trocar o provider primário de LLM, você está em boa posição. Se é uma semana ou mais, você tem um risco que o ban do Fable 5 acabou de tornar muito mais concreto.

Drift Semântico: O Risco Que Ninguém Fala de Multi-Provider

Tem um risco de multi-provider que aparece raramente nos posts sobre resiliência mas que toda equipe que operou multi-provider por mais de alguns meses encontra: drift semântico entre providers. O mesmo prompt produz resultados estruturalmente diferentes em providers distintos — e quando você faz failover automático, o output que chega na aplicação pode ser diferente do que o código downstream espera.

Um exemplo concreto: você pediu para o Claude formatar um resultado como JSON com uma estrutura específica. Em produção, o Claude tem 99.9% de fidelidade nessa tarefa. Quando o fallback ativa para o GPT-5, a fidelidade é 94%. 6% das chamadas em fallback produzem um JSON levemente diferente, que quebra o parser downstream. Você só descobre isso quando o fallback está ativo em produção — que geralmente é durante um incidente.

A mitigação que funciona: validação de schema na saída do gateway, antes de retornar para a aplicação. O gateway valida que o output tem a estrutura esperada independente do provider que respondeu. Se não tiver, tenta com outro provider ou retorna erro explícito — nunca retorna output malformado silenciosamente.

O LiteLLM suporta output validators que você pode configurar por rota. Investir um dia nisso antes de colocar o failover em produção pode economizar horas de debugging de incidente.

Conclusão

O ban do Fable 5 foi o evento que tornou o risco de provider lock-in em LLMs impossível de ignorar. A resposta arquitetural não é "use dois providers" — é ter uma camada de abstração (gateway) que transforma troca de provider de refatoração de emergência em mudança de configuração.

LLM gateway com política de roteamento explícita, failover configurado por tipo de falha, validação de schema no output e observabilidade centralizada: não são features para um sistema maduro de larga escala. São o baseline razoável para qualquer sistema de produção que usa LLMs em 2026.

O ban do Fable 5 durou três dias. O próximo evento pode durar mais. E quando ele acontecer, você quer ser o tech lead que mudou uma linha de configuração, não o que passou o fim de semana refatorando código de produção.

Você já implementou multi-provider no seu stack? Qual é o gateway que você usa e qual foi o maior desafio operacional? Me conta no LinkedIn — especialmente histórias de drift semântico entre providers, que é o problema que menos aparece nas docs e mais aparece na prática.