LLM Gateway vs Router vs Inference Provider: El límite de la arquitectura

Un LLM gateway, un router y un inference provider son tres capas distintas en la pila de servicio de modelos, y confundirlos es el error más común que cometen los equipos al diseñar productos de IA. El gateway se sitúa más cerca de su aplicación y gestiona la autenticación, la normalización y la observabilidad; el router decide qué modelo o proveedor gestiona una solicitud determinada; el inference provider es la entidad que realmente ejecuta los pesos y devuelve los tokens.

No definir bien este límite conduce a integraciones frágiles: los equipos codifican de forma rígida el SDK de un solo proveedor, para luego descubrir meses después que añadir un modelo de respaldo o comparar costes entre Claude Sonnet 5, GPT-5.5 y DeepSeek V4 Flash implica reescribir gran parte de su gestión de solicitudes. Este artículo separa las tres capas, muestra dónde residen realmente las responsabilidades y ofrece un marco de decisión para evaluar proveedores en cada categoría.

Conclusiones clave

• Un inference provider ejecuta los pesos del modelo y expone una API (OpenAI, Anthropic, Google, DeepSeek o un motor autohospedado como vLLM); un router selecciona entre proveedores o modelos por solicitud; un gateway es la capa orientada a la aplicación que unifica la autenticación, el formato, el registro y la conmutación por error entre ambos.
• La lógica de enrutamiento (selección basada en costes, latencia o capacidad) puede existir como un servicio independiente o como una función dentro de un gateway; no es lo mismo que el gateway en sí.
• El autohospedaje de un inference provider, el uso de un proveedor basado en API y el uso de un gateway multiproveedor no son mutuamente excluyentes; los sistemas de producción a menudo combinan los tres dependiendo del modelo y la carga de trabajo.
• Evalúe a los proveedores preguntando en qué capa operan realmente, ya que un producto comercializado como "router" puede solo enrutar entre endpoints compatibles con OpenAI que no aloja, mientras que un "gateway" puede incluir enrutamiento más funciones de gobernanza que aún no necesita.

Qué hace realmente un Inference Provider

El inference provider es la capa que posee los pesos del modelo, las GPU (o aceleradores equivalentes) y el motor de servicio de bajo nivel. Esto incluye proveedores comerciales de API como Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2) y DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash), así como despliegues autohospedados de modelos de pesos abiertos como Qwen3.7 Plus, MiniMax M3 o Kimi K2.7 Code.

Si realiza un autohospedaje, la capa de inference provider es software que usted mismo ejecuta. La documentación de servicio de vLLM describe un motor de inferencia construido en torno al procesamiento por lotes continuo y el manejo de atención eficiente en memoria para servir cargas de trabajo de LLM a escala, que es el tipo de componente que se sitúa directamente bajo un despliegue de modelo autohospedado. Ejecutar vLLM (o un motor comparable) le convierte en el inference provider de ese modelo, responsable de la planificación de capacidad de GPU, el escalado y el tiempo de actividad, a cambio de control sobre el coste y la localidad de los datos.

Si utiliza una API comercial, la infraestructura y los límites de tasa del proveedor se convierten en su restricción. Cada proveedor tiene su propio esquema de autenticación, esquema de solicitud y respuesta, códigos de error y comportamiento de límite de tasa. Esta es la capa donde se determinan realmente la calidad del modelo, la ventana de contexto y la latencia bruta. Ningún router o gateway puede cambiar de lo que es capaz un inference provider; solo cambian la forma en que usted llega a él.

Qué hace un Router

Un router es una lógica de decisión que selecciona un destino, modelo o proveedor para una solicitud entrante. El enrutamiento puede ocurrir en varios ejes: coste (enviar consultas simples a un modelo barato como DeepSeek V4 Flash o Gemini 3.5 Flash, reservar Claude Opus 4.8 para las complejas), latencia (preferir el proveedor que responda más rápido para un modelo dado) o disponibilidad (conmutar por error a un segundo proveedor si el primero está degradado).

El explicador público de OpenRouter sobre el enrutamiento de modelos describe este patrón a nivel de modelo: las solicitudes para un modelo de pesos abiertos pueden enrutarse a través de múltiples proveedores que alojan los mismos pesos, por lo que una sola llamada lógica de modelo puede ser cumplida por cualquiera de varios backends. La documentación de selección de proveedores de OpenRouter describe además parámetros para expresar preferencias de orden y para excluir proveedores específicos de la consideración, que es el mecanismo mediante el cual un llamador expresa la intención de enrutamiento explícitamente en lugar de dejarlo enteramente a la plataforma.

El punto arquitectónico importante es que el enrutamiento es una política, no una categoría de producto por sí misma. Puede implementar un enrutamiento básico usted mismo en el código de la aplicación (un simple if/else sobre el tipo de tarea o un bucle de reintento en caso de error), comprarlo como una capa de enrutamiento dedicada o incluirlo dentro de un gateway más amplio. Evalúe la capacidad de enrutamiento preguntando qué señales utiliza (precio, latencia, tasa de error, capacidad del modelo) y si esas señales son configurables o fijas.

Qué hace un Gateway

Un gateway es la capa con la que habla realmente el código de su aplicación. Su trabajo es presentar una interfaz consistente independientemente de qué inference provider sirva finalmente la solicitud. Un gateway normalmente incluye:

• Un esquema de solicitud y respuesta unificado entre proveedores, de modo que cambiar de GPT-5.5 a Claude Sonnet 5 no requiera reescribir su lógica de análisis.
• Autenticación y gestión de claves, para que las credenciales del proveedor no estén dispersas por el código de la aplicación.
• Registro, seguimiento de uso y atribución de costes en cada modelo y proveedor en uso.
• Comportamiento de conmutación por error y reintento cuando un proveedor es lento, tiene límites de tasa o devuelve un error.
• Opcionalmente, lógica de enrutamiento como una característica entre varias, en lugar de todo el producto.

La página de investigación de modelos de TokenLab cataloga los modelos actuales entre proveedores, incluyendo modelos de frontera (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), modelos orientados a la codificación (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) y candidatos de enrutamiento de bajo coste (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3), que es el tipo de referencia que un usuario de gateway necesita al decidir a qué enrutar. Consulte el artículo de TokenLab sobre por qué un gateway de API de IA unificado es importante en 2026 para un tratamiento más completo del problema de la unificación en sí.

El límite de la arquitectura, concretamente

El límite es más fácil de ver rastreando una sola solicitud a través de las tres capas.

1. Su aplicación envía una solicitud de chat completion al endpoint del gateway, especificando un tipo de tarea o una preferencia de modelo.
2. El gateway autentica la solicitud, la normaliza al esquema esperado de cada proveedor candidato y la entrega a la lógica de enrutamiento.
3. El router evalúa su política configurada (techo de coste, objetivo de latencia u orden de proveedor explícito) y elige un destino, por ejemplo Claude Sonnet 5 a través de la API de Anthropic, o una instancia de DeepSeek V4 Pro autohospedada servida a través de vLLM.
4. El inference provider ejecuta el modelo y devuelve tokens.
5. El gateway normaliza la respuesta de vuelta a una forma consistente y registra el resultado (latencia, coste, proveedor utilizado, éxito o fallo) para su capa de observabilidad.

Cada capa puede fallar de forma independiente. Una interrupción del proveedor es un problema de la capa de inferencia; una mala decisión de enrutamiento (enviar solicitudes de contexto largo a un modelo con una ventana de contexto pequeña) es un problema de la capa de router; un esquema de respuesta inconsistente que rompe su analizador es un problema de la capa de gateway. Entender qué capa produjo un fallo determinado es lo que hace que la depuración sea manejable. El artículo de TokenLab sobre infraestructura de fiabilidad para APIs de IA cubre el aislamiento de fallos a través de estas capas con más profundidad.

Lista de verificación de decisiones

Utilice esta lista de verificación al evaluar si necesita un gateway, un router, una integración directa con un proveedor o alguna combinación.

Pregunta	Si es sí	Si es no
¿Llama a más de un modelo o proveedor hoy, o espera hacerlo en los próximos 12 meses?	Necesita una capa de gateway o router, no llamadas directas al SDK por proveedor.	Una integración directa con el SDK del proveedor puede ser suficiente a corto plazo.
¿Necesita conmutación por error automática cuando un proveedor está degradado o limitado en su tasa?	Necesita lógica a nivel de router con comprobaciones de salud y orden de respaldo.	Los reintentos manuales en el código de la aplicación pueden ser aceptables inicialmente.
¿Necesita visibilidad de costes y uso por modelo entre proveedores en un solo lugar?	Necesita registro y atribución a nivel de gateway.	Los paneles nativos del proveedor pueden cubrir sus necesidades por ahora.
¿Está autohospedando algún modelo de pesos abiertos (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)?	También está operando una capa de inference provider y necesita infraestructura de servicio como vLLM.	Puede confiar totalmente en proveedores de API comerciales.
¿Necesita enrutar por tipo de tarea (modelo barato para clasificación, modelo de frontera para razonamiento)?	Necesita una política de router explícita, no solo conmutación por error.	Un solo modelo predeterminado puede ser suficiente.

Ejemplo de forma de solicitud

El ejemplo a continuación ilustra la forma general de una solicitud de estilo gateway que expresa tanto una preferencia de modelo principal como una lista de respaldo, un patrón consistente con cómo la documentación de selección de proveedores de OpenRouter describe la expresión de preferencias de enrutamiento. Trate los nombres de los campos como ilustrativos; verifique los parámetros exactos contra la referencia de API actual de su gateway elegido antes de realizar el despliegue.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

En esta forma, el gateway posee la normalización de la solicitud y el contrato de respuesta, el router posee la interpretación de routing_policy y fallback_models, y cualquier proveedor que sea finalmente seleccionado posee la generación real del completion. Confirme el esquema exacto de solicitud y respuesta contra la documentación actual antes de confiar en cualquier nombre de campo específico en producción.

Limitaciones

La documentación pública de OpenRouter y vLLM describe mecanismos generales de enrutamiento y servicio, no garantías universales. La latencia exacta, los precios y el comportamiento de conmutación por error varían según el proveedor y cambian con el tiempo, así que verifique los números actuales directamente contra la documentación del proveedor en lugar de este artículo. El autohospedaje con vLLM traslada la responsabilidad operativa (planificación de capacidad, escalado, parches) a su equipo; no elimina el trabajo de infraestructura, lo reubica. Ninguna política de enrutamiento puede compensar una elección de modelo fundamentalmente desajustada, como enviar una tarea que requiere razonamiento de contexto largo a un modelo no adecuado para ello; la configuración del router no es un sustituto para evaluar la capacidad del modelo frente a su carga de trabajo, por lo que mantener una referencia de modelo actualizada como la investigación de modelos de TokenLab es importante.

Preguntas frecuentes

¿Es un gateway lo mismo que un router? No. Un router es una lógica de decisión para seleccionar un modelo o proveedor; un gateway es la capa más amplia orientada a la aplicación que incluye el enrutamiento como una característica posible junto con la autenticación, la normalización y el registro.

¿Puedo ser mi propio inference provider y seguir usando un gateway? Sí. Los modelos autohospedados servidos a través de un motor como vLLM pueden situarse detrás del mismo gateway que los proveedores de API comerciales, siempre que el gateway admita endpoints personalizados o compatibles con OpenAI.

¿Necesito las tres capas desde el primer día? No necesariamente. Una integración directa con un solo proveedor es razonable para un prototipo temprano. Tan pronto como necesite conmutación por error, control de costes de múltiples modelos o comparación de proveedores, introducir un gateway con enrutamiento se vuelve rentable frente al coste de ingeniería.

Si está evaluando qué capa adoptar primero, revise las opciones de modelos actuales en la página de investigación de modelos de TokenLab y comience con una configuración de gateway que le permita añadir enrutamiento y proveedores de forma incremental en lugar de comprometerse con una sola integración desde el principio.