Busbar: uma URL para governar todos os LLMs sem dependências

Se você já tentou colocar LLMs em produção, sabe que o problema não é escolher um modelo, é gerenciar vários. Cada provedor tem SDK, autenticação, limites de taxa e erros diferentes. O resultado: blocos try/except aninhados, filas de retry e um monte de código que só faz mandar requisições. Busbar aparece como uma alternativa: um único binário Rust que expõe uma URL compatível com OpenAI e roteia para Claude, GPT, Gemini e outros com failover real.

O Fato

Busbar é um gateway de LLM escrito em Rust, com 7,4 MB estático. Ele permite que você aponte seu SDK existente (OpenAI, Anthropic, Gemini) para uma única URL e use nomes simbólicos como fast que representam pools de modelos balanceados por peso. O failover acontece no meio da requisição, sem o cliente perceber. A instalação é simples: baixar o binário, configurar dois arquivos YAML e executar.

Como Funciona na Visão de Operador

A arquitetura é enxuta. O binário é compilado em Rust, sem runtime, sem coletor de lixo (GC). Ele inicia em menos de 15 ms e consome pouca memória. As traduções entre protocolos (OpenAI <-> Anthropic) são feitas via um IR (representação intermediária) que preserva campos como thinking blocks, citations e usage accounting. O balanceamento usa SWRR (Smooth Weighted Round Robin) com disjuntor de dois estágios: primeiro, falhas upstream (5xx, rate limit, quota) causam ejeção temporária; segundo, o disjuntor tem cooldown exponencial e recuperação half-open. O failover respeita cabeçalhos Retry-After e pode redirecionar requisições muito grandes para membros com contexto maior. Tudo isso sem que o cliente veja um byte de erro.

O Que Isso Muda na Prática

Para quem desenvolve, a mudança é quase invisível. Você troca a base URL no cliente OpenAI:

client = OpenAI(api_key=BUSBAR_TOKEN, base_url='http://busbar:8080')

E o modelo vira um nome de pool no YAML:

pools:
  fast:
    - provider: anthropic
      model: claude-sonnet-4-20250514
      weight: 80
    - provider: openai
      model: gpt-4o-mini
      weight: 20

Adicionar um novo provedor é editar três linhas de YAML, sem deploy. O código nunca precisa saber qual modelo real atendeu a requisição. E o failover não é um except block que fica tentando o próximo da lista: é um subsistema com saúde de backends, circuit breaker e afinidade de sessão. Em termos práticos, um provedor que fica lento ou retorna 429 não derruba seu chat. A carga é redistribuída automaticamente.

Tensão e Reflexão

Mas será que isso escala? O Busbar roda na sua infraestrutura, então você paga os provedores diretamente e não depende de um serviço externo. Porém, ele se torna um ponto único de falha: se cair, todas as chamadas de LLM param. A documentação menciona ser stateless, mas para resiliência total você precisaria de múltiplas instâncias e um balanceador na frente. Outra questão: a latência. A tradução entre protocolos adiciona alguns milissegundos, mas para chamadas de centenas de milissegundos isso é desprezível. O que me preocupa mais é a manutenção: protocolos evoluem, novos provedores aparecem. O projeto é open source, mas quem vai garantir que as traduções se mantenham atualizadas? Por enquanto, parece que resolve o problema de gerenciamento de provedores sem criar uma dependência maior do que já temos.

Conclusão

Busbar oferece uma forma pragmática de abstrair múltiplos LLMs com failover robusto, sem adicionar complexidade ao código do cliente. Se você está cansado de encadear SDKs e quer uma camada de roteamento leve, vale testar. Fica a pergunta: você prefere um binário seu ou delegar a um serviço gerenciado como OpenRouter, abrindo mão do controle dos seus tokens?