¿Por qué un producto usaría más de un modelo?

Porque casi todas las peticiones son fáciles y unas pocas difíciles, mientras que un único modelo fuerte cobra el precio de la petición difícil por todo. El routing manda las fáciles a un modelo barato y rápido y reserva el caro, y eso puede recortar mucho el costo con una calidad parecida.

¿Cuál es la diferencia entre routing de modelos y una cascada?

Un router decide una vez, antes de que corra ningún modelo: clasifica la petición y se compromete con un modelo. Una cascada decide después: ejecuta el modelo barato, revisa la respuesta y escala solo si la revisión falla. El routing es más rápido porque no se reintenta nada. La cascada es más segura porque la revisión atrapa un error de cálculo. Los sistemas en producción suelen enrutar primero y dejar una cascada como red de seguridad.

¿Cuánto dinero ahorra el routing en realidad?

Depende de tu mezcla de tráfico, y por eso las cifras publicadas varían tanto. Los resultados reportados van de cerca del 30 por ciento a cerca del 85 por ciento de recorte de costo con calidad parecida, con sistemas de investigación como RouteLLM en el extremo alto en sus benchmarks. La forma honesta de estimar el tuyo: toma una muestra de tráfico real, respóndela con el modelo barato y cuenta qué tan seguido esa respuesta habría bastado.

¿Un gateway de LLM es lo mismo que un router?

Se traslapan pero no son lo mismo. Un gateway es plomería: una sola API delante de muchos modelos, con llaves, registro, seguimiento de costos y respaldo ante fallas. Un router es una política de decisión: qué modelo debe atender esta petición. Muchos gateways incluyen un router como función, como la opción auto de OpenRouter, pero puedes usar un gateway con un modelo fijo, y puedes construir un router sin ningún gateway.

¿Puede el modelo decidir por sí mismo qué modelo usar?

Eso son los modos auto. A mediados de 2026, el modo por defecto de ChatGPT enruta cada mensaje entre variantes instantáneas y de razonamiento, y los proveedores de API exponen perillas parecidas como ajustes de esfuerzo o de razonamiento. El auto-routing es cómodo, pero el proveedor lo ajusta para tráfico promedio y para sus propios costos, así que los productos con exigencias estrictas de calidad igual comprueban con sus propios evals si el auto rinde lo mismo que un modelo fijo.

¿Necesito un router para una app chica?

Probablemente no al principio. Si tu factura mensual de modelos es chica, un buen modelo y un prompt simple le ganan a cualquier esquema de routing, y la pieza móvil extra solo complica la depuración. Vuelve a pensarlo cuando la factura sea dinero de verdad, cuando la latencia en peticiones fáciles moleste a los usuarios o cuando duelan las caídas de un proveedor. Incluso entonces, empieza con dos reglas, no con un router entrenado.

¿Por eso el mismo chatbot parece más listo algunos días?

Puede ser. Cuando un producto hace routing automático, dos preguntas que a ti te parecen iguales pueden ser respondidas por modelos distintos. Es una razón más para que tu propio conjunto de pruebas te diga más que un benchmark del proveedor.

Explicador en lenguaje claro

El routing de modelos, explicado

¿Qué es el routing de modelos, y cómo eliges qué modelo de IA usar?

El routing de modelos manda cada petición al modelo más barato que aún pueda resolverla, en vez de usar un modelo grande para todo. La mayoría de las peticiones son fáciles, así que un modelo pequeño y barato las resuelve, y solo las pocas difíciles necesitan un modelo de frontera. Un router puede decidir por adelantado, o hacer cascada: probar un modelo pequeño, comprobar el resultado y escalar solo si se queda corto. Bien hecho, mantienes el nivel de calidad mientras recortas costo y latencia, porque dejas de pagar precios de frontera por trabajo fácil.

Revisado por última vez el 4 de agosto de 2026

Leer es el camino lento. Empieza con una lección gratis que puedes operar ahora mismo.

Empieza gratis: Del internet a tu respuesta →

Gratis, sin código, sin registro.

Y después ve más a fondo: Enrutamiento de modelos: el modelo más barato que pasa Bloqueada

¿Qué es exactamente un router de modelos?

Todo producto de IA que ofrece más de un modelo responde una pregunta pequeña miles de veces al día: ¿qué modelo debería tomar esta petición? Un router de modelos es la pieza que la responde. Se coloca delante de una familia de modelos, inspecciona cada petición que llega y elige qué modelo la atiende. El usuario ve un solo asistente. Tras bambalinas, una pregunta fácil puede ir a un modelo pequeño y rápido mientras una difícil va a un modelo de frontera.

El router en sí suele ser aburrido a propósito. Puede ser un puñado de reglas, un clasificador pequeño entrenado o, en los productos más nuevos, la propia familia de modelos juzgando la dificultad de la petición. Sea cual sea la forma, tiene un solo trabajo: tomar una decisión suficientemente buena en milisegundos, por una fracción mínima del costo de la llamada que está por hacer. Un router que cuesta tanto como las llamadas que ahorra no es un router, es sobrecosto.

Dos formas cubren casi todos los sistemas reales. Un router decide una vez, por adelantado, y se compromete. Una cascada prueba primero el modelo barato, revisa la respuesta y escala a un modelo más fuerte solo cuando la revisión falla. El routing es más rápido porque no se reintenta nada. Las cascadas son más seguras porque un error de cálculo se atrapa. Los sistemas maduros suelen enrutar primero y dejar una cascada como red de seguridad.

¿Por qué no usar el mejor modelo para todo?

Porque pagarías precios de frontera por trabajo que no necesita un modelo de frontera. El tráfico real está desbalanceado. Un bot de soporte ve restablecimientos de contraseña mucho más seguido que casos legales límite. Un asistente de código renombra variables más seguido de lo que diseña sistemas. Cuando la mayoría de las peticiones son fáciles, mandar todo al modelo más grande significa pagar de más en casi todo lo que hace tu producto.

La brecha de precios entre niveles es lo que hace que el routing valga el esfuerzo. Dentro del catálogo de cada proveedor grande, el nivel pequeño es entre 5 y 10 veces más barato que el nivel frontera, y los análisis de la industria en 2026 ponen la distancia entre un modelo barato de batalla y uno de última generación en 10 a 20 veces. Los modos de razonamiento amplían la brecha todavía más: un modelo que piensa también genera muchos más tokens de salida por respuesta, y los tokens de salida son los caros.

La latencia se escalona igual. Los modelos pequeños responden en bastante menos de un segundo, mientras que un modelo de frontera en modo de razonamiento puede tardar decenas de segundos. Para las peticiones fáciles, enrutar hacia abajo no es un sacrificio: obtienes una mejor experiencia, antes, a una décima parte del precio. La lección interactiva de este sitio te deja jugar al router: clasificas un flujo de peticiones entre niveles y ves cómo se mueven juntos costo, latencia y calidad. La tabla muestra las brechas entre niveles a mediados de 2026.

Precios de lista redondeados por millón de tokens a mediados de 2026. Cambian seguido. Lo que importa es la proporción entre niveles, no la cifra exacta.

Catálogo del proveedor	Nivel pequeño, entrada / salida	Nivel frontera, entrada / salida	Brecha aproximada
OpenAI, de nano al insignia	US$0.20 / US$1.25	US$1.25 / US$10	de 6 a 8x
Google, de Flash-Lite a Pro	US$0.25 / US$1.50	US$2 / US$12	cerca de 8x
Anthropic, de Haiku al nivel más alto	US$1 / US$5	US$5 a 10 / US$25 a 50	de 5 a 10x

¿Qué estrategias de routing usan los equipos?

Cuatro patrones cubren el campo, en orden aproximado de sofisticación.

Reglas. Si el mensaje es corto y coincide con una intención fácil conocida, usa el modelo pequeño. Las reglas son transparentes, gratis de ejecutar y capturan las victorias obvias. Casi todos los equipos deberían empezar aquí.
Routers aprendidos. Un clasificador pequeño entrenado con tráfico pasado predice si el modelo barato bastaría para esta petición. RouteLLM, un proyecto abierto de investigación del grupo LMSYS, reportó recortes de costo de hasta cerca del 85 por ciento en sus benchmarks manteniendo cerca del 95 por ciento de la calidad del modelo de frontera, mandando hacia arriba solo la minoría difícil de las consultas.
Cascadas con respaldo. Ejecuta el modelo barato, verifica la respuesta y escala si falla. FrugalGPT, un proyecto temprano de Stanford, reportó igualar la calidad de frontera en algunas tareas a un pequeño porcentaje del costo con este método. El problema es la latencia: una petición escalada paga dos llamadas seguidas, así que la verificación tiene que ser lo bastante estricta como para dispararse poco.
Auto-routing. Los productos más nuevos dejan que la familia de modelos juzgue su propia dificultad. Un modo auto lee la petición y elige entre una variante instantánea y una variante que razona. Eso es un router con la insignia del propio modelo.

¿Dónde te cruzas con el routing en productos que ya usas?

ChatGPT es el ejemplo más ruidoso. A mediados de 2026 su modo Auto por defecto es un router: cada mensaje se clasifica y lo atiende un modelo instantáneo rápido o se escala a un modelo que razona, y los mensajes auto-escalados ni siquiera han contado contra la cuota semanal de razonamiento. Llegar ahí costó. Cuando GPT-5 se lanzó con routing en 2025, las peticiones mal enrutadas hicieron que el producto se sintiera más débil que sus partes, y el reclamo de los usuarios empujó a OpenAI a restaurar selectores manuales de modelo junto al modo Auto. La calidad del routing es la calidad del producto.

Otros asistentes empaquetan la misma idea como un interruptor de rápido contra razonar o un ajuste de esfuerzo, y las herramientas de código enrutan por superficie sin decirlo: el autocompletado sale de un modelo pequeño de baja latencia mientras el panel de chat usa uno grande.

Los gateways convierten el routing en un producto propio. OpenRouter expone cientos de modelos tras una sola API y ofrece una opción auto que elige un modelo por prompt, impulsada por el router comercial Not Diamond y cobrada a la tarifa normal del modelo elegido. Amazon Bedrock vende routing de prompts entre modelos de la misma familia, y reporta recortes de costo de hasta cerca del 30 por ciento en sus pruebas. La mayoría de los gateways también suma el lado de confiabilidad del routing: si un proveedor falla o tarda de más, la petición pasa a un respaldo.

¿Cómo decide el router, y qué puede salir mal?

Los routers leen señales baratas: qué tan largo es el prompt, a qué tarea se parece (traducir, resumir, depurar, planear), si hay herramientas o imágenes de por medio, cuánto historial de conversación viene adjunto y, a veces, quién pregunta, porque los planes gratis suelen enrutarse más abajo que los de pago. Los routers aprendidos agregan la señal más fuerte de todas, el historial: en tráfico pasado parecido a este, ¿bastó el modelo pequeño?

Los modos de falla son predecibles. El peor es la pregunta difícil mal enrutada: una petición que parece simple, recibe el modelo pequeño y regresa como una respuesta equivocada y segura de sí misma que nadie marca. El segundo es la inconsistencia: modelos distintos tienen voces y hábitos distintos, así que un producto con routing puede sentirse como un asistente diferente de un mensaje al siguiente. El tercero es el punto ciego de los evals: si evalúas los modelos uno por uno pero producción sirve una mezcla, tus tableros describen un sistema que ningún usuario experimenta.

Las defensas no tienen glamour. Registra qué modelo atendió cada petición. Mantén una vía de escalado que el usuario pueda activar, como un reintento que fuerza el modelo grande. Y corre tus evals contra la mezcla enrutada, no contra el mejor modelo aislado.

¿Tu equipo debería construir un router o comprarlo?

Compra primero la plomería. Un gateway que te da una sola API sobre muchos modelos, elección de modelo por petición, respaldo ante fallas y seguimiento de costos elimina la mayor parte del trabajo aburrido. Comprar además la decisión, dejando que el modo auto de un proveedor elija modelos por ti, es otra discusión: la definición de suficientemente bueno del proveedor se ajustó con tráfico general y con su propia estructura de costos, no con los tuyos.

Construye la decisión cuando tres cosas sean ciertas. Tu tráfico muestra una división clara entre fácil y difícil. Tu factura es lo bastante grande como para que un recorte del 40 por ciento pague la ingeniería: enrutar un gasto mensual de US$50 es un pasatiempo, enrutar uno de US$50,000 es un trabajo. Y tienes un conjunto de evals propio, porque un router sin evals es un recorte de costos que no puedes acotar.

En cualquier caso, empieza con reglas sobre tráfico registrado y mide qué tan seguido fallan antes de entrenar nada. Una página de reglas suele capturar una buena parte de la ganancia, y te construye los hábitos de registro y evals que un router aprendido necesita de todos modos.

Lo que la gente entiende mal

Usa siempre el modelo más capaz. Es lento y caro para las muchas peticiones que no lo necesitan.
El enrutado daña la calidad. Con una comprobación o una cascada mantienes el nivel y solo escalas cuando hace falta.
Los modelos baratos no sirven. Resuelven una gran parte del tráfico real a una fracción del costo.
El routing es solo para ahorrar dinero. También es latencia y resiliencia: los modelos pequeños responden más rápido, y un router puede pasar a otro modelo cuando un proveedor tiene una caída.

Dónde lo ves en productos reales

Los asistentes enrutan consultas simples a modelos pequeños y el razonamiento a los grandes.
Las apps sensibles al costo van en cascada de barato a caro solo cuando hace falta.
Las plataformas exponen un único endpoint que elige el modelo por detrás.
Los asistentes de código sirven el autocompletado con un modelo pequeño y rápido y el chat con uno grande.

Preguntas frecuentes

¿Por qué un producto usaría más de un modelo?: Porque casi todas las peticiones son fáciles y unas pocas difíciles, mientras que un único modelo fuerte cobra el precio de la petición difícil por todo. El routing manda las fáciles a un modelo barato y rápido y reserva el caro, y eso puede recortar mucho el costo con una calidad parecida.
¿Cómo decide el router?: Suele ser un clasificador pequeño entrenado con el tráfico anterior, a veces reglas simples de largo y tipo de tarea, y a veces el propio modelo fuerte juzgando la dificultad. Sea lo que sea, la decisión de routing tiene que ser mucho más barata que la llamada que ahorra para que valga la pena.
¿Cuál es la diferencia entre routing de modelos y una cascada?: Un router decide una vez, antes de que corra ningún modelo: clasifica la petición y se compromete con un modelo. Una cascada decide después: ejecuta el modelo barato, revisa la respuesta y escala solo si la revisión falla. El routing es más rápido porque no se reintenta nada. La cascada es más segura porque la revisión atrapa un error de cálculo. Los sistemas en producción suelen enrutar primero y dejar una cascada como red de seguridad.
¿Cuánto dinero ahorra el routing en realidad?: Depende de tu mezcla de tráfico, y por eso las cifras publicadas varían tanto. Los resultados reportados van de cerca del 30 por ciento a cerca del 85 por ciento de recorte de costo con calidad parecida, con sistemas de investigación como RouteLLM en el extremo alto en sus benchmarks. La forma honesta de estimar el tuyo: toma una muestra de tráfico real, respóndela con el modelo barato y cuenta qué tan seguido esa respuesta habría bastado.
¿Un gateway de LLM es lo mismo que un router?: Se traslapan pero no son lo mismo. Un gateway es plomería: una sola API delante de muchos modelos, con llaves, registro, seguimiento de costos y respaldo ante fallas. Un router es una política de decisión: qué modelo debe atender esta petición. Muchos gateways incluyen un router como función, como la opción auto de OpenRouter, pero puedes usar un gateway con un modelo fijo, y puedes construir un router sin ningún gateway.
¿Puede el modelo decidir por sí mismo qué modelo usar?: Eso son los modos auto. A mediados de 2026, el modo por defecto de ChatGPT enruta cada mensaje entre variantes instantáneas y de razonamiento, y los proveedores de API exponen perillas parecidas como ajustes de esfuerzo o de razonamiento. El auto-routing es cómodo, pero el proveedor lo ajusta para tráfico promedio y para sus propios costos, así que los productos con exigencias estrictas de calidad igual comprueban con sus propios evals si el auto rinde lo mismo que un modelo fijo.
¿Necesito un router para una app chica?: Probablemente no al principio. Si tu factura mensual de modelos es chica, un buen modelo y un prompt simple le ganan a cualquier esquema de routing, y la pieza móvil extra solo complica la depuración. Vuelve a pensarlo cuando la factura sea dinero de verdad, cuando la latencia en peticiones fáciles moleste a los usuarios o cuando duelan las caídas de un proveedor. Incluso entonces, empieza con dos reglas, no con un router entrenado.
¿Por eso el mismo chatbot parece más listo algunos días?: Puede ser. Cuando un producto hace routing automático, dos preguntas que a ti te parecen iguales pueden ser respondidas por modelos distintos. Es una razón más para que tu propio conjunto de pruebas te diga más que un benchmark del proveedor.

Explicadores relacionados

Evals de LLM Agents de IA Cómo funcionan los LLM Costo de la inferencia Modelos de razonamiento

Más en Velocidad, costo y control

Una idea a la vez, en tu correo

Lecciones y explicadores nuevos, escritos como están escritas estas páginas. De vez en cuando, no a diario, y nunca una secuencia de venta.

Primero te enviamos un enlace de confirmación. Puedes darte de baja con un clic, cuando quieras. Privacidad.

Parte de See How AI Works, un curso interactivo gratuito, donde aprendes cómo funciona la IA moderna operándola, no viendo videos.