¿Qué es una pasarela LLM?

¿Qué es una pasarela LLM?

Una pasarela LLM es un servicio entre tus aplicaciones y los proveedores de modelos. Las aplicaciones llaman a un único endpoint; la pasarela reenvía cada petición al modelo configurado, traduce protocolos, custodia las claves de los proveedores y registra el uso. No entrena con tu tráfico, no reescribe tus prompts y no sustituye al modelo.

• •Es infraestructura, no un modelo: los modelos siguen en los proveedores que elijas.
• •Un mismo endpoint sirve aplicaciones de chat, agentes de código, procesos por lotes, voz en tiempo real y llamadas a herramientas MCP.
• •La línea útil: la pasarela posee la ruta de la petición, la aplicación posee el prompt.

¿Qué hace realmente una pasarela LLM?

Cuatro cosas: enrutar cada petición al modelo adecuado, normalizar protocolos para que cualquier cliente hable con cualquier proveedor, centralizar claves y control de acceso, y registrar cada llamada para coste y auditoría. La caché, los presupuestos y las comprobaciones de contenido se construyen sobre esas cuatro, no en su lugar.

• •Enrutado y respaldo: un modelo por rol de agente, reintento en otro proveedor ante 5xx o timeout, agrupación de claves de origen.
• •Traducción de protocolos: cuatro familias de protocolos de chat en ambos sentidos, para que el cliente conserve su SDK.
• •Gobernanza: grupos de claves, admisión por cabecera, cuotas por inquilino, SSO y SCIM, registros de auditoría por petición.
• •Observabilidad: series de tokens y coste por clave, equipo y modelo con resolución de un minuto.

¿Por qué las empresas ponen una pasarela delante de sus modelos?

Porque el acceso a modelos deja de ser el problema de un solo equipo. Cuando varios equipos, proveedores y agentes llaman a modelos, las preguntas pasan a ser de compras: quién puede usar qué modelo, cuánto cuesta por departamento, si los datos salieron de la red y cuánto tiempo de ingeniería cuesta cambiar de proveedor. Una pasarela responde con configuración, no con cambios de código.

• •Atribución de costes: cada llamada lleva clave y etiqueta, el gasto se separa por equipo.
• •Ruta de datos: la pasarela se ejecuta en tu red; las peticiones solo van a los endpoints configurados.
• •Continuidad: las caídas de proveedor y los cambios de modelo se resuelven en la capa de enrutado.
• •Compras: autoalojamiento con BYOK mantiene claves y tráfico bajo tus contratos de proveedor.

¿Cuándo necesitas realmente una pasarela LLM?

Cuando se cumplen dos de estas condiciones: más de un proveedor de modelos, más de un equipo consumidor, un requisito de cumplimiento o residencia de datos, o un gasto que nadie sabe explicar. Por debajo de esa línea, llamar directamente a las API de los proveedores es más simple y más barato: una pasarela es un servicio más que operar.

• •Dos o más proveedores, por capacidad, coste o continuidad.
• •Los informes de coste por equipo o por cliente son una petición recurrente.
• •Los datos no pueden salir de una red, región o inquilino concretos.
• •Varios agentes e IDE comparten hoy una o dos claves de API.

¿Cuándo es una pasarela la decisión equivocada?

Cuando tienes un equipo, un proveedor y una aplicación. Una pasarela añade un salto, un despliegue y una guardia. Si el gasto mensual es predecible y tu cumplimiento es sencillo, llama directamente al proveedor y vuelve a planteártelo cuando llegue el segundo proveedor, el segundo equipo o la primera solicitud de auditoría.

• •Un prototipo o una herramienta interna única con un proveedor no la necesita.
• •La gestión de prompts y la evaluación de modelos son otros productos: una pasarela no los sustituye.
• •Ninguna pasarela te ahorra leer los contratos de tus proveedores.

¿En qué se diferencia de un servicio de retransmisión o de usar los SDK del proveedor?

Un servicio de retransmisión reenvía el tráfico a un proveedor por ti, a menudo guardando tu clave y cobrando una comisión. Una pasarela que tú operas mantiene claves y tráfico en tu red y añade enrutado, medición y políticas. Llamar directamente a los SDK evita el intermediario, pero deja la lógica de reintentos, protocolos y medición dentro de cada aplicación.

• •Para un prototipo un servicio de retransmisión puede bastar; el precio es que prompts y claves salen de tu red.
• •Usar solo SDK es lo más barato hasta que aparece el segundo proveedor: entonces cada aplicación necesita el mismo pegamento.
• •De las tres opciones, solo la pasarela puede decirte quién gastó qué.

¿La pasarela debe ser autoalojada o SaaS?

Autoalojada cuando las claves, los prompts o los registros no pueden salir de tu red, o cuando compras no acepta otro subencargado. SaaS gana cuando no hay equipo de plataforma y quieres cero operación. La pregunta decisiva no es la moda: es quién puede leer tu tráfico.

• •Autoalojar cuesta contenedores, actualizaciones y un runbook; SaaS cuesta una suscripción y una revisión de subencargados.
• •Existe el híbrido: plano de datos autoalojado con plano de control del proveedor; los prompts quedan dentro, los metadatos quizá no.
• •Pide el diagrama de flujo de datos, no la página de marketing.

¿Cómo deberías elegirla?

Puntúa la preselección en cinco cosas: dónde se ejecuta, sobre qué se ancla la factura, qué protocolos y SDK habla de forma nativa, con qué detalle gobierna claves e inquilinos y si el proveedor seguirá siendo dueño del producto el año que viene. Después comprueba lo que ninguna matriz muestra: ¿puedes reproducir hoy un informe de costes de hace un mes?

• •Despliegue: autoalojado, SaaS o híbrido, y si el plano de control llama a casa.
• •Anclaje de facturación: por instancia, por asiento, por token o un porcentaje del gasto.
• •Protocolos: OpenAI, Anthropic, Gemini y DashScope en ambos sentidos, con streaming y llamadas a herramientas realmente equivalentes.
• •Gobernanza: grupos de claves, ACL por cabecera, presupuestos, SSO y SCIM, exportación de auditoría.
• •Reproducibilidad: mismas entradas, mismas cifras, meses después.

Preguntas frecuentes sobre pasarelas LLM