Enrutamiento de modelos: cómo elegir y evaluar cada ruta

Tu modelo más potente debería encargarse del trabajo que exige sus capacidades. Una respuesta sobre el estado de un pedido con datos autenticados y una disputa por un reembolso con registros contradictorios no deberían seguir automáticamente la misma ruta. Lo difícil es distinguir ambos casos antes de que una respuesta barata termine generando trabajo adicional costoso.

El funcionamiento de los productos descritos aquí se verificó con su documentación pública vigente el 21 de octubre de 2026. La carga de trabajo de soporte y los cálculos son ejemplos ilustrativos, no mediciones de producción ni afirmaciones de ahorro de los proveedores.

¿Qué es el enrutamiento de modelos y cómo funciona?

Un enrutador de modelos es una regla o un clasificador entrenado que elige qué modelo de lenguaje de gran tamaño, o LLM, responde a cada solicitud. Un clasificador asigna una entrada a una categoría. Para elegir el modelo, el enrutador puede considerar el tipo de tarea de la aplicación, la conversación, las herramientas necesarias, el tamaño de la entrada o una estimación de la dificultad.

Imagina a alguien que distribuye el trabajo de un equipo de soporte. Una consulta rutinaria va a quien puede resolverla con eficiencia; un caso en disputa, a un especialista. También hace falta una regla para escalar el trabajo que nadie tiene autorización para completar.

En una aplicación, eso significa comprobar qué modelos son aptos antes de optimizar: ¿puede este modelo procesar la entrada, llamar a las herramientas necesarias y ejecutarse a través de un proveedor aprobado? Solo los candidatos que cumplan esos requisitos deberían competir por costo o calidad prevista.

El enrutamiento de modelos, el enrutamiento de proveedores y los mecanismos de respaldo resuelven preguntas distintas. El primero elige qué modelo responde. El segundo decide dónde ejecutar un modelo ya seleccionado, por ejemplo, entre distintos proveedores de alojamiento. El respaldo determina qué alternativa probar cuando un intento falla. Una pasarela, la capa de acceso entre tu aplicación y las API de los modelos, puede implementar todas estas funciones. Pero añadir una pasarela no basta para tener un selector de modelos que tenga en cuenta la calidad.

Aquí, un modelo de frontera es el candidato de propósito general más potente que estás considerando. También puede dar respuestas incorrectas. El enrutamiento distribuye capacidades; no garantiza la veracidad.

Tres formas de enrutar las solicitudes entre modelos

Empieza con reglas que puedas explicar. La selección automática aporta valor cuando resuelve variaciones que esas reglas no contemplan y sigue superando tus controles de aceptación. Estas son tres opciones de implementación que pueden combinarse: una pasarela puede alojar un enrutador entrenado.

Reglas definidas por tu equipo

La aplicación asigna modelos a tipos de tareas y restricciones conocidos. Una solicitud de un endpoint de estado de pedidos que incluye datos autenticados y una plantilla de respuesta aprobada es mejor candidata para un modelo pequeño que un mensaje clasificado como fácil solo por ser corto.

Las reglas son útiles cuando la aplicación ya conoce el flujo de trabajo. Su límite es la ambigüedad: un mismo endpoint puede recibir una consulta sencilla o una queja con registros contradictorios. Mantén una ruta explícita para los casos inciertos, en lugar de acumular una lista cada vez mayor de palabras clave poco fiables.

Enrutamiento automático desde una pasarela

Envías una solicitud a un alias de enrutamiento y la pasarela selecciona el modelo. Según el producto, la selección puede apoyarse en un clasificador, niveles configurados u otras señales. Centralizas el comportamiento, pero también adoptas el criterio del enrutador sobre qué modelo encaja mejor.

Esta opción tiene sentido cuando las tareas entrantes son variadas y mantener tu propio selector supondría un esfuerzo desproporcionado. Conserva un conjunto de candidatos aprobados y registra qué modelo respondió realmente. Un alias no identifica de forma estable a un modelo.

Cómo aprende un enrutador de LLM

Un enrutador entrenado aprende, a partir de ejemplos y etiquetas de resultados, qué candidato tiene más probabilidades de rendir mejor. La pregunta útil para entrenarlo es si el modelo más potente aporta valor a esa solicitud, no simplemente si el texto parece complicado.

RouteLLM es un framework de código abierto para ejecutar y evaluar enrutadores. Su documentación describe la selección entre modelos más y menos potentes mediante entrenamiento con preferencias, así como la calibración de umbrales. El umbral controla con qué frecuencia se selecciona el modelo más potente. Los resultados publicados no demuestran cómo funcionará con tus tickets. Documentación de RouteLLM.

El reto de mantenimiento aparece cuando cambia la distribución de las solicitudes: nuevos tipos de tareas o modelos de reemplazo pueden invalidar un umbral que antes funcionaba. Entrena o calibra con ejemplos de desarrollo y evalúa después con casos separados que nunca se hayan usado para ajustar el enrutador.

Una política de enrutamiento para una aplicación de soporte, paso a paso

Envía al modelo pequeño las respuestas acotadas y respaldadas por datos; reserva el modelo de frontera para el razonamiento aún por resolver. Las decisiones de autorización deben seguir en la política de la aplicación. Ningún modelo obtiene permiso para emitir reembolsos solo porque sepa explicarlos.

Imagina un comercio por suscripción cuya aplicación recupera el pedido del cliente, la política pertinente y el historial de la conversación antes de redactar una respuesta. Lo que sigue es una propuesta de política, no una afirmación de que un modelo pequeño concreto ya la cumpla.

La ruta del modelo pequeño debe abstenerse de responder cuando falte la información necesaria. La aplicación puede detectar campos ausentes en el pedido, una estructura de salida inválida o una acción solicitada fuera del flujo permitido. Una contradicción factual puede requerir un verificador independiente o revisión humana. Una respuesta con sintaxis válida puede seguir siendo incorrecta.

Usa el modelo de frontera para los casos difíciles y escala un intento fallido del modelo pequeño solo cuando el fallo sea detectable. Si faltan registros, hace falta recuperarlos o pedir una aclaración; enviar la misma información incompleta a un modelo más grande no resuelve el problema.

Cuenta también las llamadas escaladas

Supongamos un lote ilustrativo de 1,000 solicitudes. La política envía 700 al modelo pequeño y 300 directamente al modelo de frontera. De esas llamadas iniciales al modelo pequeño, 70 no superan un control y vuelven a ejecutarse con el modelo de frontera.

Ahora pagas 700 llamadas al modelo pequeño y 370 al modelo de frontera, además del enrutamiento y la validación. Son 1,070 llamadas a modelos que generan respuestas, no 1,000. Un reintento implica trabajo adicional, aunque el usuario solo vea la respuesta final.

Sea r el costo medio de enrutamiento por solicitud original, s el costo medio de una llamada al modelo pequeño, f el costo medio de una llamada al modelo de frontera y g los cargos adicionales de pasarela o validación para todo el lote. En este ejemplo simplificado, suponemos que el promedio del modelo de frontera es el mismo en la referencia, las llamadas directas y los escalamientos:

Costo con enrutamiento = 1,000r + 700s + 370f + g

Referencia con todas las solicitudes al modelo de frontera = 1,000f

El enrutamiento solo resulta más barato cuando 700(f − s) > 70f + 1,000r + g. El lado izquierdo representa el costo inicial de respuesta que se evita al usar la ruta del modelo pequeño; el derecho, los reintentos adicionales con el modelo de frontera y los gastos asociados.

Calcula los costos de llamada con los modelos y las tarifas que elijas: costo por llamada = (tokens de entrada sin caché × tarifa de entrada + tokens de entrada en caché × tarifa de caché + tokens de salida facturados × tarifa de salida) / 1,000,000, cuando las tarifas se expresen por millón de tokens; añade las herramientas y los cargos por solicitud que se facturen aparte.

En producción, sustituye estos promedios simplificados por el consumo real de cada tarea y ruta. Los tickets difíciles pueden generar respuestas más largas, los reintentos pueden incluir más contexto y cambiar de modelo puede afectar a la reutilización de la caché. Incluye los tokens del clasificador del enrutador y los tokens de razonamiento facturados cuando corresponda, sin contar dos veces el mismo cargo. Compara ambos sistemas con la misma política de reintentos.

El resultado que importa es un menor costo por resolución aceptada, manteniendo el nivel mínimo de calidad. Una factura más baja acompañada de más promesas de reembolso sin fundamento no supera esa prueba.

Qué hacen las opciones de enrutamiento según su documentación

Revisa cómo se selecciona el modelo antes de adoptar un endpoint de enrutamiento. Estos productos permiten tomar decisiones distintas; que todos usen la palabra «router» no significa que su comportamiento predeterminado sea equivalente.

OpenRouter: Auto Router según el tipo de tarea

OpenRouter, una pasarela gestionada para acceder a múltiples proveedores de modelos, ofrece Auto Router mediante openrouter/auto. Su documentación actual describe una clasificación de tareas seguida de una ordenación de los modelos según el gasto de la comunidad en cada tipo de tarea durante una ventana móvil de 7 días. Después se aplican filtros por franja de costo y requisitos de elegibilidad. Es una señal de uso agregado, no tu criterio de calidad para soporte. Documentación de Auto Router.

Las opciones de cost_tier son low, medium, high, xhigh y max; el comportamiento predeterminado se aproxima a low. Un nivel es una franja, no un límite estricto de gasto. Restringe los candidatos con allowed_models y excluded_models, y registra el campo model de la respuesta. La persistencia de la selección dentro de una conversación puede conservar el modelo elegido, pero no garantiza que permanezca fijo.

Con una clave de API configurada en el entorno, este comando envía una solicitud mínima de enrutamiento:

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Usa un conjunto restringido de candidatos para la evaluación. De lo contrario, los cambios en el conjunto de modelos dificultarán la interpretación de los resultados de calidad del día anterior.

LiteLLM: enrutamiento de despliegues y Auto Router son funciones distintas

LiteLLM, una pasarela configurable para LLM, documenta estrategias de enrutamiento entre despliegues que incluyen selección ponderada, menor ocupación, latencia y costo. Su estrategia predeterminada, simple-shuffle, no clasifica la dificultad de los tickets de soporte. Documentación del enrutador.

Su función independiente Auto Router documenta clasificadores heurísticos, basados en LLM, en reglas de palabras clave y en plugins personalizados. Los niveles SIMPLE, MEDIUM, COMPLEX y REASONING se asignan a modelos o conjuntos de modelos configurados. En el panel, la ruta de configuración documentada es Models + Endpoints → Add Model → Auto Router, seguida de la configuración y Test Routing. Documentación de Auto Router.

Encaja con equipos de desarrollo que necesitan controlar los modelos candidatos y el comportamiento de la clasificación. El límite está en la responsabilidad operativa: asignar modelos a niveles no demuestra que cumplan tus reglas de aceptación. La comparativa de LiteLLM y OpenRouter profundiza en esa decisión de infraestructura.

Vercel AI Gateway: selección de proveedores y controles explícitos de enrutamiento

Vercel AI Gateway, una capa de acceso gestionada para las API de modelos, elige los proveedores predeterminados según su disponibilidad y latencia recientes. Sus opciones de proveedor controlan el orden y los filtros; los modelos de respaldo indicados como cadenas de texto permiten probar alternativas cuando el principal falla o no está disponible. Son mecanismos útiles para la fiabilidad. Por sí solos, no deciden si un ticket de soporte necesita un modelo de frontera. Documentación sobre enrutamiento de proveedores y respaldo.

Las reglas de enrutamiento de la pasarela también permiten sustituir el modelo solicitado por otro o denegar la solicitud. Una sustitución puede migrar el tráfico de forma centralizada, pero reemplazar todas las solicitudes dirigidas a un modelo es distinto de clasificar la dificultad de cada una. Documentación de las reglas de enrutamiento.

Cuando necesites un comportamiento explícito, aplica estos controles por debajo de una política de selección definida en la aplicación. El error sería suponer que elegir automáticamente un proveedor también implica seleccionar automáticamente según la calidad necesaria para la tarea. Para comparar las capas de acceso en general, consulta las pasarelas de IA para aplicaciones con varios modelos.

Microsoft Foundry: un enrutador entrenado y gestionado por el proveedor

El enrutador de modelos de Microsoft Foundry es un selector entrenado que se ofrece como despliegue. Microsoft describe una selección basada en la complejidad, el razonamiento, el tipo de tarea y otros atributos. Ofrece los modos Balanced, Quality y Cost, además de subconjuntos de modelos. Conceptos del enrutador de modelos.

Esta opción encaja con una aplicación que ya usa Foundry y busca una selección gestionada entre modelos aptos. El límite importante es el conjunto de candidatos: la región y los permisos de acceso afectan a la disponibilidad, y la documentación de Microsoft advierte que la ventana de contexto más pequeña entre los modelos subyacentes limita lo que el enrutador puede aceptar de forma fiable. Restringe el subconjunto a los modelos que cumplan tus requisitos de entrada.

Un modo llamado Quality no sustituye la evaluación de las tareas. Prueba el subconjunto elegido con tus longitudes reales de conversación, tus herramientas y tus reglas de aceptación.

Cómo elegir un enrutador de modelos de IA

Mantén las reglas de la aplicación cuando puedas identificar de forma fiable el trabajo sencillo. Considera el enrutamiento automático gestionado cuando la variedad de tareas vuelva frágiles esas reglas. Entrenar un selector tiene sentido cuando dispones de suficientes resultados representativos y etiquetados para justificar su mantenimiento.

Para comparar alternativas de infraestructura más allá de estos mecanismos, el siguiente paso es la guía de alternativas a OpenRouter. La primera decisión sigue siendo la política de enrutamiento y las pruebas que la respaldan, no ampliar la lista de proveedores.

Cómo evaluar un enrutador con un conjunto de pruebas

Evalúa las respuestas que produce el enrutamiento, no su coincidencia con etiquetas como «fácil» y «difícil». Un selector puede clasificar correctamente las categorías de tareas y aun así enviar al modelo pequeño los casos equivocados.

Un conjunto de evaluación reúne solicitudes, contexto y criterios de aceptación que permiten repetir la prueba. En la aplicación de soporte, cada caso debe incluir la conversación, una copia de los datos del pedido en ese momento, la política aplicable, los hechos esperados, las afirmaciones o acciones prohibidas y el comportamiento de escalamiento requerido.

La tabla de métricas debe dejar a la vista los errores costosos:

Si ningún caso cumple las condiciones del denominador de una métrica, indícala como indefinida, no como cero. Estima la tasa de asignación perjudicial al modelo pequeño a partir de las respuestas de los modelos evaluadas por separado y registra también los errores finales tras cualquier escalamiento. Identifica por separado los casos en que ambos modelos fallan: un selector no puede obtener una respuesta aceptable de esos candidatos.

Decide antes de la prueba qué diferencia de calidad no crítica aceptarás e investiga cada nueva regresión crítica. Usa intervalos de confianza adecuados para la muestra pareada; si la incertidumbre todavía abarca una pérdida inaceptable, reúne más pruebas antes de declarar equivalencia.

Por último, ejecuta el enrutador en paralelo, sin mostrar sus respuestas, sobre una muestra acotada de tráfico real mientras el modelo actual sigue atendiendo a los clientes. Esas llamadas adicionales también generan gasto. Tras revisar los resultados, realiza un despliegue limitado con una vía inmediata para volver a la política de modelos existente. Sigue supervisando por tipo de solicitud y repite la evaluación cuando cambien los prompts, las herramientas, los modelos o el comportamiento del enrutamiento.

Qué se exagera sobre el enrutamiento de modelos

«La misma calidad por menos» es un resultado que depende de una carga de trabajo concreta, no una propiedad del enrutador. Depende de las solicitudes recibidas, los candidatos disponibles y lo que se considere aceptable. Ningún porcentaje de ahorro obtenido con la carga de trabajo de otra organización sustituye esas mediciones.

Una respuesta exitosa de la API también dice poco sobre la calidad del contenido. El respaldo ante errores puede sortear un endpoint no disponible; no detecta una política inventada en una respuesta fluida. El escalamiento por calidad necesita una comprobación independiente, con su propia tasa de error y su propio costo.

Las puntuaciones de dificultad merecen el mismo examen. La confianza de un clasificador no equivale automáticamente a la probabilidad de que el modelo seleccionado responda bien. Calibra cualquier umbral con los resultados observados en las tareas. No permitas que texto del usuario como «esto es fácil» anule los permisos de la aplicación o las restricciones de candidatos.

Además, la selección automática puede cambiar aunque el código de tu aplicación siga igual. Los candidatos de OpenRouter, basados en el gasto, evolucionan; la versión actual del enrutador de modelos de Microsoft puede incorporar nuevos modelos subyacentes. Estos comportamientos documentados convierten el registro de candidatos y la actualización de las evaluaciones en parte de la operación del enrutador, no en tareas opcionales de mantenimiento.

Quién debería empezar, quién debería esperar y cuál es el siguiente paso

Los equipos de desarrollo deberían actuar cuando puedan aislar trabajo repetible con un criterio claro de aceptación. Añade una ruta al modelo pequeño para respuestas de estado respaldadas por datos, conserva una ruta prudente para los casos inciertos y versiona la política para poder reproducir los fallos.

Los equipos de operaciones deberían exigir pruebas del flujo de trabajo completo. Una factura de inferencia más baja no basta si aumentan los tickets reabiertos, la revisión humana o el tiempo de resolución. Sigue esos resultados junto con la evaluación fuera de producción.

Quienes evalúan la compra deberían pedir que se reproduzcan sus propios casos. Exige visibilidad sobre los modelos seleccionados y el comportamiento del respaldo. Un benchmark general no demuestra que un enrutador comprenda tu política de reembolsos.

Espera si no puedes definir un resultado correcto, no puedes restringir el conjunto de candidatos o no tienes suficiente tráfico para compensar el trabajo operativo. Una aplicación que ya usa un modelo pequeño validado para una tarea fija y acotada puede ganar poco al añadir otro selector.

Para empezar el lunes: exporta un conjunto representativo de casos de soporte, fija la información que los respalda y evalúa tu modelo actual junto a un candidato más pequeño. Escribe una regla de enrutamiento acotada al subconjunto que el candidato pequeño resuelve correctamente. Asigna tráfico a un enrutador automático solo después de que mejore el costo de esa regla cumpliendo los mismos requisitos de calidad.

Preguntas frecuentes sobre el enrutamiento de modelos

Suscríbete al boletín para recibir guías prácticas sobre cómo crear y evaluar aplicaciones de IA.