AI Gateway: provedores nativos vs compatíveis com OpenAI

Um AI Gateway centraliza chamadas para provedores externos de LLM por trás de uma única interface, em vez de codificar cada integração de SDK no lado do aplicativo. As chaves de API permanecem no lado do servidor, nunca expostas ao cliente. O gateway adiciona uma camada comum de novas tentativas, failover e contagem de custos além de provedores com diferentes formatos de resposta.

Em um backend Postgres como Aurabase, essa escolha tem uma consequência direta: o mesmo gateway alimenta o chat do aplicativo, o NL2SQL (tradução de linguagem natural para SQL) e o RAG (pesquisa vetorial pgvector). Um provedor mal integrado degrada todos os três recursos de uma vez, e não apenas um. Isso é o que torna a distinção nativo/compatível mais do que um detalhe de implementação.

Um cliente nativo codifica a forma real da API do provedor: estrutura de solicitação, formato de resposta, campos de uso específicos deste provedor. É o caso do Anthropic, cuja API de “Mensagens” não se assemelha à do OpenAI, ou do Gemini, cuja contagem de tokens de raciocínio (thoughtsTokenCount) é adicionada ao contador de saída em vez de já estar incluída lá.

Um endpoint compatível com OpenAI reutiliza o cliente OpenAI existente e altera apenas o URL base. Isso funciona porque o fornecedor terceirizado (Mistral, Scaleway AI, Ollama) optou por imitar o contrato de API da OpenAI, muitas vezes com desvios: nenhum campo de token de raciocínio separado, nenhuma garantia sobre a forma exata dos erros. A compatibilidade termina onde termina a imitação.

O arquivo que organiza os provedores em aura-ai não deixa espaço para ambigüidades. Três módulos, um por provedor nativo, nada mais declarado.

pub mod anthropic;
pub mod gemini;
pub mod openai;

Cada módulo implementa a característica ChatProvider (conclusão, streaming, nome do modelo). Dois deles, OpenAI e Gemini, implementam adicionalmente EmbeddingProvider. A Anthropic não precisa disso: Claude não expõe uma API de embeddings do lado do fornecedor, um produto da própria Anthropic, e não uma deficiência do código Aurabase.

Configurar Mistral, Scaleway AI ou Ollama não requer um novo módulo: a mesma variável OPENAI_BASE_URL redireciona o cliente openai.rs para outro endpoint compatível. Esta é uma alternância de configuração, não de desenvolvimento.

# Provedor padrão: OpenAI nativo
OPENAI_API_KEY=sk-...

# Mude para um provedor compatível com OpenAI (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# por exemplo Mistral: https://api.mistral.ai/v1

O comportamento muda de acordo. Os erros HTTP permanecem classificados pelo mesmo mecanismo (429 → limite de taxa, 5xx → transitório e repetível, 404 → modelo desconhecido), porque a classificação reside no nível de transporte HTTP, e não na análise específica do provedor. O que não acontece: a contagem precisa de tokens de raciocínio, específicos para o cliente Gemini dedicado.

O gateway Aurabase adiciona três mecanismos de resiliência além dos três clientes nativos. Um disjuntor por par (projeto, provedor) corta chamadas para um provedor que falhou repetidamente, com um token de teste em um estado semiaberto antes de reabri-lo. Uma nova tentativa de espera exponencial com jitter reinicia erros transitórios (tempo limite, 5xx, 429), sem dependência de uma biblioteca externa de números aleatórios.

Cada provedor também nomeia o motivo para interromper uma resposta de forma diferente: length na OpenAI, MAX_TOKENS na Gemini, max_tokens na Anthropic, para a mesma realidade (truncamento). O código normaliza esses três vocabulários em direção a um conjunto comum (stop, length, content_filter, tool_use, other). Sem essa padronização, um cliente de vários fornecedores precisaria conhecer todos os três vocabulários para detectar uma resposta truncada.

O faturamento ilustra o mesmo risco. Na OpenAI e na Anthropic, o raciocínio do modelo já está incluso no contador de tokens de saída cobrados. No Gemini, thoughtsTokenCount é adicionado separadamente a candidatesTokenCount: ignorá-lo subestima o custo real de uma consulta. Um adaptador genérico compatível com OpenAI não tem razão para conhecer essa particularidade, específica do formato de resposta nativo do Gemini.

O mercado confirma que um AI Gateway se tornou um tijolo esperado, e não um argumento de marketing isolado. Neon publica duas páginas de produtos dedicadas, “AI Gateway” e “Backend para agentes de IA”, ambas orientadas para desenvolvedores Postgres. LiteLLM se consolidou como um projeto de código aberto de referência para unificar chamadas para um grande número de provedores em um formato próximo ao OpenAI. A Braintrust, por sua vez, publica suas próprias comparações sobre o assunto, sinal de que a categoria é forte o suficiente para justificar conteúdo editorial dedicado.

Esses players respondem a uma necessidade real: reduzir o acoplamento entre o código da aplicação e um determinado provedor LLM. O diferencial do Aurabase é a integração. O gateway não fica próximo ao backend: ele compartilha o mesmo serviço que NL2SQL e RAG, no mesmo banco de dados Postgres. O compromisso oposto também existe: um proxy dedicado como o LiteLLM geralmente cobre mais provedores do que um gateway integrado no backend de um aplicativo.

Um gateway nativo como o do Aurabase tem uma vantagem real quando o backend e a IA devem permanecer no mesmo sistema: NL2SQL, RAG e chat de aplicação compartilham então a mesma política de resiliência e o mesmo faturamento, sem serviços adicionais para operar.

O compromisso oposto existe. Se a sua prioridade é cobrir um grande número de provedores, ou se o gateway deve servir vários backends independentes e não apenas um projeto Postgres, um proxy geral como o LiteLLM geralmente continua sendo a escolha certa. A Aurabase não pretende competir com esta amplitude de cobertura: a aposta é a profundidade em 3 grandes fornecedores, integrada com o resto do backend.

Para entender como essa integração muda concretamente o uso de NL2SQL em comparação com uma abordagem que usa conectores externos, abordagem escolhida pela Supabase, consulte Supabase depende de conectores, não de NL2SQL nativo.

Resumo dos critérios que realmente distinguem as duas abordagens, sem juízo de valor: cada uma responde a uma necessidade diferente.

Para ver esse gateway funcionando em um caso concreto, consulte o tutorial NL2SQL no Postgres. Para obter detalhes sobre os recursos de IA nativos do Aurabase, consulte a página Native AI.