Model router: una clave, muchos modelos

¿Qué problema resuelve?

Si compras el acceso directamente a los fabricantes, cada familia de modelos significa una cuenta aparte, una clave aparte, una factura aparte y un trozo de código aparte. Con tres proveedores todavía se lleva. Con diez ya no, y diez es justo lo que haría falta para saber cuál te va bien.

El router te quita esa capa: una clave, una facturación, un formato de llamada alcanzan a la mayoría de los modelos del mercado. El nombre del modelo es un parámetro de texto — lo cambias y ya estás en otro fabricante.

Cuatro cosas distintas se llaman model router

Esta sección va delante porque sin ella compras lo que no era. Los cuatro tipos resuelven problemas distintos y tienen riesgos distintos:

El segundo tipo es el malentendido más frecuente. Quien anuncia «muchos modelos abiertos en una API» no es necesariamente un agregador: puede que una sola empresa los ejecute todos en sus propias máquinas. Eso no es un defecto — simplemente es otra cosa. En un agregador la empresa que trabaja detrás de ti puede cambiar de una petición a otra; en un proveedor de inference no cambia nunca.

¿Qué te da un router?

Cinco cosas, y no todas pesan igual:

• Una integración, muchos modelos. El formato de llamada es uniforme; cambiar de modelo es modificar una línea.
• Un respaldo si un proveedor se cae. Si la API de un fabricante se para, la llamada pasa automáticamente a otro. En un sistema en producción eso solo ya puede justificarlo.
• Acceso a modelos de pesos abiertos sin alojarlos. Los modelos abiertos chinos y europeos se alcanzan por la misma interfaz que los cerrados — sin servidor propio.
• Una lista de precios comparable. En un solo sitio ves cuánto cuesta la misma tarea en diez modelos. La facturación va por créditos, no por proveedor.
• Datos públicos de uso. Los routers grandes publican cuántos tokens pasan por ellos en cada modelo — una de las raras ocasiones en que no miras una cifra de marketing.

El mercado: quiénes son y cuánto cobran

El punto de referencia de la categoría es OpenRouter. En septiembre de 2026 su página de inicio anuncia más de 500 modelos y más de 80 proveedores, mientras que su API pública lista 445 modelos y 106 proveedores — no son la misma cuenta, y la diferencia enseña bien lo móvil que es esta cifra. Sobre el precio: una tarifa del 5,5 por ciento al comprar créditos, y ningún recargo sobre la ejecución en sí. También publica un ranking de uso que muestra, día a día, cuántos tokens pasan por cada modelo.

Y una cosa que pasó en 2026: el 19 de agosto, Stripe acordó la compra de OpenRouter. La empresa dice que el nombre, el producto y la hoja de ruta se quedan igual. Del cierre de la operación no se ha publicado nada — pero si construyes sobre ello ahora, esto conviene saberlo.

También hay una alternativa europea, y eso es raro en este sector:

En ninguno de los casos «500 modelos» significa 500 familias de modelos distintas: el mismo modelo puede estar disponible en varios proveedores, a distinto precio y distinta velocidad — y el router elige entre ellos. Un modelo de pesos abiertos lo puede ejecutar cualquiera que compre las máquinas para ello.

¿Cuánto cuesta? Tres precios ocultos

El router no trabaja gratis, y no solo cobra en dinero.

Un salto más en la cadena. Cada llamada pasa por un actor adicional. Eso añade latencia — normalmente poca, pero en una aplicación sensible y de cara al usuario cuenta.

Retraso en las funciones. Las capacidades nuevas de los fabricantes — parámetros nuevos, caché, ejecución por lotes — aparecen primero en la API nativa. La capa del router las traslada tarde o solo en parte.

Otro actor en la ruta de los datos. Es el más importante, y la sección siguiente lo trata aparte.

La cuestión de los datos, que no se puede esquivar

Cuando llamas a través de un router, tu prompt no va al fabricante directamente. Va al router y de ahí al proveedor que esté ejecutando ese modelo en ese momento — y ese proveedor puede ser una empresa de la que nunca has oído hablar, en un país que no elegiste.

Los routers mejores gestionan parte de esto: se puede configurar una política de datos que excluya a los proveedores que registran lo que envías o entrenan con ello. Ese ajuste no viene por defecto — si no lo tocas, no protege.

La restricción geográfica, en cambio, es más débil de lo que creerías, y mucha gente lo entiende mal. El filtrado por registro se puede poner petición a petición, pero el filtrado por región en el proveedor más grande no es un parámetro normal de la API: hace falta un endpoint regional aparte, y ese va a clientes de empresa, a petición. Si la sujeción geográfica es un requisito legal en tu caso, acláralo de antemano en vez de darlo por supuesto.

De ahí sale una regla sencilla: para experimentar y para contenido público el router es excelente; para datos de clientes, solo con la política configurada y el contrato en orden. El artículo Opciones europeas de IA recorre también ese lado.

El gateway: delante de tus propias claves

Esta es la categoría que la mayoría de las presentaciones se salta, y para un desarrollador puede ser la mejor respuesta. El gateway no da acceso a nada — trabaja con tus propias claves de proveedor y solo pone una capa delante de ellas: formato de llamada uniforme, registro, caché, tope de gasto, reintento automático, respaldo a otro proveedor.

Por qué compensa: tu prompt no entra en la ruta de una empresa ajena, porque la llamada va al fabricante con tu clave, desde tu cuenta. A cambio lo tienes que operar tú o pagar una suscripción, y no obtienes quinientos modelos — solo aquellos para los que tengas cuenta.

Dos gateways conocidos, en cambio, se han caído: a uno lo compró en 2026 una gran empresa de seguridad y lo renombró, el otro cambió de dueño y sus servicios funcionan desde entonces en modo mantenimiento. En este sector ese es el ritmo normal — por eso no te ates a una capa que no puedas cambiar en un día.

Si en lugar de un gateway prefieres ejecutar el modelo tú mismo, entonces ya eliges entre los ejecutores de IA local, y esa es una decisión completamente distinta.

El mercado de las nubes

Hay también una tercera vía: los mercados de modelos de los grandes proveedores de nube. Ahí también una clave alcanza muchos modelos, y todo queda bajo tu contrato existente — la misma factura, el mismo acuerdo de encargo de tratamiento, la misma elección de región que el resto de tus servicios de nube. Si en tu empresa el obstáculo son las compras, esta vía es más rápida.

Los tres grandes: Amazon Bedrock, Microsoft Foundry (antes Azure AI Studio, luego Azure AI Foundry) y Model Garden en la Gemini Enterprise Agent Platform de Google (antes Vertex AI). Como cuarto entra aquí IBM watsonx.ai. El cambio frecuente de nombre ya es una señal por sí solo: esta capa sigue buscando su forma.

Equivalente europeo en esta categoría no hay — no existe nube de la UE que venda los modelos cerrados de varios fabricantes grandes bajo un solo contrato. Lo que sí existe son API de modelos abiertos alojadas en la UE: eso lo ofrecen OVHcloud, Scaleway, IONOS y Nebius. Si la residencia de datos es tu criterio principal, la elección no es el proveedor sino el conjunto de modelos: un modelo cerrado de primera línea con contrato europeo hoy es difícil de conseguir.

El cuarto significado: el selector por petición

Cuando alguien dice «model router», a veces no se refiere a un mercado sino a que el sistema decide en cada petición qué modelo hace falta. La pregunta fácil va al barato, la difícil al caro.

Esto existe hoy en dos formas. Una es el selector automático integrado de los mercados y de las nubes: normalmente solo pagas por él el precio del modelo elegido — pero no siempre, porque Amazon cobra un dólar por cada mil peticiones por el routing en sí. La otra es el producto aparte: la solución independiente más conocida pide cinco céntimos por millón de tokens enrutados.

Categoría a tratar con reservas: dos de sus actores conocidos se salieron de ella para 2026 — ambos se convirtieron en laboratorio de investigación, y ninguno ofrece ya producto de routing. Hoy no merece la pena montar una arquitectura sobre un selector por petición, pero como complemento está bien.

¿Cuál y cuándo?

Deciden cinco señales:

• Probar, comparar, prototipar → mercado. No tiene sentido abrir cinco cuentas para cerrar cuatro en dos semanas.
• Usar modelos de pesos abiertos → mercado o proveedor de inference, porque sin operar máquinas propias de otro modo resulta incómodo.
• Sistema en producción, varios proveedores, con contratos propios → gateway. Consigues la interfaz uniforme sin que el prompt acabe en una ruta ajena.
• Un solo modelo, mucho tráfico, en producción → directo. Menos saltos, el juego completo de funciones, una cadena de responsabilidad más simple.
• Requisitos estrictos de datos → mercado de nube o contrato directo, no un mercado.

Un uso concreto: el torneo de modelos

El mejor uso de un mercado no es la producción sino la decisión. Cuando hay que averiguar qué modelo necesita tu tarea, en una superficie común eso es el trabajo de una tarde en vez de abrir cinco cuentas.

La receta: coge de 20 a 40 tareas reales, pásalas con el mismo prompt por cinco o seis modelos y mira el número de errores, el tiempo de respuesta y el precio. El router vuelve trivial justamente la parte que si no sería casi todo el trabajo — el artículo Un torneo de modelos en dos semanas lo describe paso a paso.

Después, una vez que tienes ganador, puedes pasarte al acceso directo. Un router es una herramienta, no un compromiso.

Malentendidos habituales

• «El router y el gateway son lo mismo.» No lo son. El mercado da acceso a servicios ajenos con su propia clave; el gateway se pone delante de tus claves. Desde el punto de vista de la ruta de los datos esa es la mayor diferencia de este artículo.
• «Muchos modelos abiertos en una API, luego es un agregador.» Puede ser una sola empresa que los ejecuta todos en sus propias máquinas. Pregunta quién es el operador.
• «En el router se puede ajustar en qué país se ejecuta.» El filtrado por registro sí; el filtrado por región, normalmente solo en un endpoint de empresa aparte.
• «Quien no cobra recargo es gratis.» La tarifa puede estar en la compra de créditos y no en la ejecución. Mira en cuál de las dos.
• «Esta capa es estable.» En dos años ha habido aquí una compra, un renombrado, un producto pasado a modo mantenimiento y dos salidas. Planifica una vía de salida.

Qué llevarte

Una clave, muchos modelos — para probar y como respaldo es hoy la mejor solución. Su precio es un salto más, funciones que llegan tarde y un actor adicional en la ruta de los datos, que hay que gestionar con una política y que se ata a la geografía peor de lo que creerías.

La primera pregunta de la decisión, en cambio, no es qué router elegir sino qué tipo hace falta. Para probar un mercado, en producción con contratos propios un gateway, para un solo modelo de mucho tráfico el acceso directo, para requisitos estrictos de datos un mercado de nube.

Y elijas lo que elijas: esta capa se mueve deprisa. En dos años ha habido aquí una compra multimillonaria, dos renombrados y dos salidas. Elige algo que puedas sustituir en un día — mantener el nombre del modelo en un parámetro de texto es buena idea justo por eso.