Verificamos esta distinción directamente en el código del servicio aura-ai, no en una página de marketing: tres módulos de proveedor (anthropic, gemini, openai) forman la puerta de enlace, nada más. El resto del panorama confirma que se trata de una categoría de desarrollador real, no de un argumento de marketing aislado. Neon publica dos páginas dedicadas (“AI Gateway” y “Backend for AI Agents”), LiteLLM se ha consolidado como un proyecto de código abierto de referencia y Braintrust le dedica sus propias comparaciones.
Lo esencial
- 3 proveedores nativos verificados en código: OpenAI, Anthropic (Claude), Google Gemini (
aura-ai/src/llm/mod.rs). - Mistral, Scaleway AI y Ollama pasan por el adaptador OpenAI genérico (
OPENAI_BASE_URL), no por un cliente dedicado. - El nativo aporta más que la conexión: disyuntor por (proyecto, proveedor), reintento de retroceso, cadena de respaldo (orden predeterminado Anthropic → OpenAI → Google), estandarización de los motivos de cierre.
- Anthropic solo cubre el chat: no hay API integradas, a diferencia de OpenAI y Gemini que cubren ambos.
- Neon, LiteLLM y Braintrust confirman la misma categoría en el mercado, con tres enfoques diferentes: gateway gestionado, proxy de código abierto y contenido comparativo.
¿Qué es una puerta de enlace AI en un backend de Postgres?
Un AI Gateway centraliza las llamadas a proveedores LLM externos detrás de una única interfaz, en lugar de codificar cada integración de SDK en el lado de la aplicación. Las claves API permanecen en el lado del servidor y nunca se exponen al cliente. La puerta de enlace agrega una capa común de reintento, conmutación por error y conteo de costos además de proveedores con diferentes formatos de respuesta.
En un backend de Postgres como Aurabase, esta elección tiene una consecuencia directa: la misma puerta de enlace alimenta el chat de la aplicación, NL2SQL (traducción de lenguaje natural a SQL) y RAG (búsqueda de vectores pgvector). Un proveedor mal integrado degrada las tres funciones a la vez, no sólo una. Esto es lo que hace que la distinción nativo/compatible sea más que un detalle de implementación.
Proveedor nativo o punto final compatible: la diferencia concreta
Un cliente nativo codifica la forma real de la API del proveedor: estructura de solicitud, formato de respuesta, campos de uso específicos de este proveedor. Es el caso de Anthropic, cuya API “Messages” no se parece a la de OpenAI, o a Gemini, cuyo recuento de tokens de razonamiento (thoughtsTokenCount) se añade al contador de salida en lugar de estar ya incluido allí.
Un punto final compatible con OpenAI reutiliza el cliente OpenAI existente y solo cambia la URL base. Esto funciona porque el proveedor externo (Mistral, Scaleway AI, Ollama) optó por imitar el contrato API de OpenAI, a menudo con desviaciones: sin campo de token de razonamiento separado, sin garantía sobre la forma exacta de los errores. La compatibilidad termina donde termina la imitación.
3 clientes nativos de LLM en Aurabase, no más
El archivo que organiza los proveedores en aura-ai no deja lugar a ambigüedades. Tres módulos, uno por proveedor nativo, nada más declarado.
Cada módulo implementa el rasgo ChatProvider (finalización, transmisión, nombre del modelo). Dos de ellos, OpenAI y Gemini, implementan además EmbeddingProvider. Anthropic no lo necesita: Claude no expone una API de incrustaciones del lado del proveedor, un producto de Anthropic en sí, no una deficiencia del código de Aurabase.
| Abierto AI | CLIENTE NATIVO | Chat + cálculo de incrustaciones de vectores de alta fidelidad |
|---|---|---|
| Antrópico (Claude) | CLIENTE NATIVO | Inferencia de chat y finalización de modelo estructurado Claude |
| Google Géminis | CLIENTE NATIVO | Chat + incrustaciones, recuento de tokens de razonamiento aditivo |
| mistral | UBICACIÓN COMPATIBLE | Enrutamiento a través del protocolo estándar compatible con OpenAI (URL personalizada) |
| IA de escala | UBICACIÓN COMPATIBLE | Ruta a través del cliente openai.rs, variable OPENAI_BASE_URL |
| Ollama (autohospedado) | UBICACIÓN COMPATIBLE | Ruta a través del cliente openai.rs, variable OPENAI_BASE_URL |
Conecte Mistral, Scaleway AI u Ollama a un proyecto de Aurabase
Configurar Mistral, Scaleway AI u Ollama no requiere un nuevo módulo: la misma variable OPENAI_BASE_URL redirige el cliente openai.rs a otro punto final compatible. Esto es un cambio de configuración, no un desarrollo.
El comportamiento cambia en consecuencia. Los errores HTTP siguen clasificados mediante el mismo mecanismo (429 → límite de velocidad, 5xx → transitorio y reintentable, 404 → modelo desconocido), porque la clasificación reside en el nivel de transporte HTTP, no en el análisis específico del proveedor. Lo que no sigue: el recuento preciso de tokens de razonamiento, específicos del cliente Gemini dedicado.
Por qué lo nativo cambia las reglas del juego: conmutación, errores, facturación
La puerta de enlace de Aurabase agrega tres mecanismos de resiliencia además de los tres clientes nativos. Un disyuntor por par (proyecto, proveedor) corta las llamadas a un proveedor que falla repetidamente, con un token de sonda en un estado semiabierto antes de volver a abrirlo. Un reintento de retroceso exponencial con fluctuación reinicia errores transitorios (tiempo de espera, 5xx, 429), sin depender de una biblioteca de números aleatorios externa.
Cuando se configuran varios proveedores en una cadena, solo se realiza un intento por proveedor antes de cambiar al siguiente, para evitar la amplificación (reintento × retroceso) que multiplicaría las llamadas ascendentes y la latencia total. El orden predeterminado de este canal es Anthropic, luego OpenAI y luego Google Gemini.
Cada proveedor también nombra el motivo para detener una respuesta de manera diferente: length en OpenAI, MAX_TOKENS en Gemini, max_tokens en Anthropic, para la misma realidad (truncamiento). El código normaliza estos tres vocabularios hacia un conjunto común (stop, length, content_filter, tool_use, other). Sin esta estandarización, un cliente de múltiples proveedores necesitaría conocer los tres vocabularios para detectar una respuesta truncada.
La facturación ilustra el mismo riesgo. En OpenAI y Anthropic, el razonamiento del modelo ya está incluido en el contador de tokens de salida cargados. En Gemini, thoughtsTokenCount se agrega por separado a candidatesTokenCount: ignorarlo subestima el costo real de una consulta. Un adaptador genérico compatible con OpenAI no tiene por qué conocer esta particularidad, específica del formato de respuesta nativo de Gemini.
Neon, LiteLLM, Braintrust: ¿dónde están las mejores puertas de enlace de LLM en 2026?
El mercado confirma que un AI Gateway se ha convertido en un ladrillo esperado, no en un argumento de marketing aislado. Neon publica dos páginas de productos dedicadas, “AI Gateway” y “Backend for AI agentes”, ambas orientadas a desarrolladores de Postgres. LiteLLM se ha consolidado como un proyecto de código abierto de referencia para unificar llamadas a un gran número de proveedores detrás de un formato cercano a OpenAI. Braintrust, por su parte, publica sus propias comparaciones sobre el tema, señal de que la categoría es lo suficientemente fuerte como para justificar un contenido editorial dedicado.
Estos jugadores responden a una necesidad real: reducir el acoplamiento entre el código de la aplicación y un proveedor LLM determinado. La diferencia con Aurabase es la integración. La puerta de enlace no vive al lado del backend: comparte el mismo servicio que NL2SQL y RAG, en la misma base de datos de Postgres. También existe el compromiso opuesto: un proxy dedicado como LiteLLM generalmente cubre más proveedores que una puerta de enlace integrada en el backend de una aplicación.
| Aurabase | Integrado con el backend de Postgres (servicio aura-ai) | 3 nativos verificados + compatible con OpenAI para el resto |
|---|---|---|
| Puerta de enlace de IA de neón | Producto dedicado, junto con la base de datos administrada de Postgres | Documentado en dos páginas oficiales separadas. |
| LiteLLM | Proxy independiente de código abierto, frente a cualquier backend | Amplia gama de proveedores a través de un formato cercano a OpenAI |
Cuándo elegir una puerta de enlace nativa, cuándo elegir un proxy general
Una puerta de enlace nativa como la de Aurabase tiene una ventaja real cuando el backend y la IA deben permanecer en el mismo sistema: NL2SQL, RAG y el chat de aplicaciones comparten la misma política de resiliencia y la misma facturación, sin servicios adicionales para operar.
Existe el compromiso opuesto. Si su prioridad es cubrir una gran cantidad de proveedores, o si la puerta de enlace debe servir a varios backends independientes y no solo a un proyecto de Postgres, un proxy general como LiteLLM a menudo sigue siendo la opción correcta. Aurabase no busca competir con esta amplitud de cobertura: la apuesta es la profundidad a través de 3 proveedores principales, integrados con el resto del backend.
Para comprender cómo esta integración cambia concretamente el uso de NL2SQL en comparación con un enfoque que utiliza conectores externos, el enfoque elegido por Supabase, consulte Supabase se basa en conectores, no en NL2SQL nativo.
Puerta de enlace nativa integrada versus proxy LLM general
Resumen de los criterios que realmente distinguen los dos enfoques, sin juicio de valor: cada uno responde a una necesidad diferente.
| Proveedores | Profundidad sobre 3 proveedores principales + compatible con OpenAI para el resto | Amplia gama de proveedores, integración generalmente uniforme. |
|---|---|---|
| Claves API | Cifrado en el backend, mismo servicio que la base de datos. | Cifrado en el lado del proxy, servicio separado del backend de la aplicación |
| Enlace NL2SQL/RAG | Mismo servicio, mismo proveedor de resolución | Sin enlaces nativos, cree su propia integración |
| Resiliencia | Disyuntor por (proyecto, proveedor), respaldo, reintento de retroceso | Depende de la configuración elegida para el proxy. |
| Implementación | Un servicio menos para operar (ya en el backend) | Desmontable, reutilizable en múltiples proyectos/backends |
Para ver esta puerta de enlace en funcionamiento en un caso concreto, consulte el tutorial de NL2SQL en Postgres. Para obtener detalles sobre las capacidades de IA nativa de Aurabase, consulte la página AI nativa.