Una de las primeras cosas que se observan al desplegar un LLM en producción es la varianza en la complejidad de las consultas. Algunas son triviales — extraer un número de un texto, reformatear una dirección, validar un formato. Otras son genuinamente complejas — razonamiento en múltiples pasos, síntesis de varios documentos, análisis legal. El problema es que la mayoría de los sistemas envían todas estas consultas al mismo modelo. Se paga por un modelo frontier aunque esté respondiendo a algo que un modelo a una décima del precio gestionaría sin problemas.
El LLM routing resuelve exactamente esto. La idea es sencilla: antes de cada llamada LLM, estime primero la dificultad de la tarea y envíela al modelo más barato que la resuelva de forma fiable. Llame al modelo potente solo cuando la situación lo exija de verdad. En la práctica, esto significa que el 75–90 % de las llamadas van al modelo económico y los costes totales caen sin una pérdida perceptible de calidad en la mayoría de los casos de uso.
Qué es routing y qué es cascading
Routing (enrutamiento) es la decisión antes de la primera llamada: elegir el modelo en función de la entrada. Un clasificador evalúa la consulta y la envía o bien al modelo pequeño, o bien directamente al potente.
Cascading (cascada) añade un paso adicional: la consulta se envía primero al modelo barato y su respuesta se evalúa — si es suficientemente segura (puntuación de confianza, consistencia, formato), se devuelve al usuario. Si no, se escala automáticamente al modelo más potente y solo entonces se paga por él. Ambos enfoques se pueden combinar: el router decide el modelo de entrada, la cascada decide la escalación.
La diferencia clave: el routing es proactivo (clasificación antes de la llamada), el cascading es reactivo (escalación tras la llamada cuando la salida no es suficiente).
Por qué funciona — distribución de dificultad en la práctica
En los sistemas de producción reales que hemos analizado, la distribución es aproximadamente la siguiente:
- 30–40 % de las consultas son rutinarias — extracción, clasificación, reformateo, búsqueda sencilla. Las gestiona un modelo pequeño, por ejemplo de la familia Phi o Gemma, o el tier económico de los proveedores frontier.
- 40–50 % de las consultas son de dificultad media — resúmenes de textos largos, razonamiento sencillo, respuestas a preguntas frecuentes con contexto. Aquí basta un modelo intermedio.
- 10–20 % de las consultas son realmente difíciles — análisis complejos, razonamiento multi-hop, generación de código con requisitos no estándar, decisiones sensibles. Estas merecen un modelo frontier.
Si se envía todo al frontier, se paga el precio del modelo potente por cada consulta, incluido ese 30–40 % rutinario. Los precios de los modelos frontier (p. ej., la clase Claude Opus, GPT-5.x) se mueven en torno a ~$15–25 por millón de tokens de salida, mientras que el tier económico (equivalentes Flash/Haiku) se sitúa por debajo de $1–2. La diferencia es de 15–25 veces. Incluso con un routing modesto, donde el modelo pequeño gestiona solo la mitad de las consultas, los costes pueden reducirse entre un 40 y un 60 %.
El proyecto académico RouteLLM (LMSYS / UC Berkeley) demostró que un router bien entrenado puede enviar la mayoría de las consultas sencillas al modelo barato conservando al mismo tiempo gran parte de la calidad del modelo potente — en sus mediciones, eso suponía un ahorro de costes del orden del 85 % manteniendo una parte sustancial del rendimiento del modelo potente. Las cifras exactas dependen de la composición de las consultas y de la calibración del router.
Cómo funciona el clasificador de dificultad
El corazón del router es el clasificador, que decide adónde enviar la entrada. Existen varios enfoques con distintos trade-offs:
1. Router heurístico simple
Longitud de la entrada, palabras clave, tipo de tarea (extracción vs. generación vs. análisis). Funciona sorprendentemente bien en sistemas con un caso de uso estrecho y tipos de consultas claramente separados. Sin overhead, comportamiento determinista. Desventaja: frágil, requiere reglas manuales, no se adapta a casos límite.
2. Router basado en embeddings
La consulta se embebe (p. ej., con un modelo BGE pequeño) y se compara con ejemplos representativos de cada tier. Si la consulta se acerca a la muestra de tareas fáciles, va al modelo barato. El modelo de embeddings corre localmente, el overhead es mínimo (~5–15 ms). Ventaja: no requiere entrenar un clasificador, fácilmente ampliable con nuevos ejemplos.
3. Clasificador binario entrenado
Un modelo pequeño (regresión logística o un transformador pequeño) entrenado para predecir si la consulta requiere el modelo potente. RouteLLM ofrece precisamente este enfoque con clasificadores preentrenados. Ventaja: alta precisión tras la calibración con datos propios. Desventaja: requiere un conjunto de entrenamiento con anotaciones y actualización continua.
4. LLM-as-a-judge router
Un modelo barato evalúa por sí mismo si la consulta es difícil. Paradójico, pero funciona en la práctica — el modelo barato sabe distinguir "esto es una extracción sencilla" de "esto es un análisis complejo", aunque no pueda ejecutar bien ese análisis complejo. Overhead: una llamada LLM corta adicional. Adecuado para sistemas con cascada.
Para la mayoría de los sistemas de producción recomendamos comenzar con el router basado en embeddings o con el heurístico simple. El clasificador entrenado se añade cuando se dispone de logs operativos suficientes para el entrenamiento (del orden de miles de ejemplos anotados).
Patrón práctico de cascada
La cascada en la práctica funciona así:
- 1.La consulta llega al sistema.
- 2.El modelo pequeño genera una respuesta y, al mismo tiempo, una puntuación de confianza (confidence).
- 3.Si la puntuación supera el umbral (p. ej., 0,85), la respuesta se devuelve al usuario.
- 4.Si no, la misma consulta se envía al modelo intermedio o al potente y se devuelve el resultado de este.
La puntuación de confianza se puede derivar de varias formas:
- Log-probabilidad de los tokens — log-probabilidad media de los tokens generados. Un valor bajo indica que el modelo "titubeó". Disponible en frameworks de serving como
vLLMoSGLanga través del parámetrologprobs. - Consistencia por muestreo — genere 3–5 respuestas distintas (temperatura más alta) y mida la concordancia. Si el modelo se contradice, escale.
- Prompt de verificación — una llamada secundaria (con el modelo barato): "¿Es esta respuesta correcta y completa? Responde solo sí/no."
El umbral de escalación es el parámetro clave que hay que calibrar para cada caso de uso concreto. Un umbral demasiado alto = demasiadas escalaciones innecesarias, se pierde el ahorro. Un umbral demasiado bajo = el modelo pequeño responde a cosas que no maneja, la calidad cae.
Para sistemas con una tarea bien definida (p. ej., clasificación de documentos en categorías, extracción de datos estructurados) la cascada es especialmente eficaz — el modelo pequeño gestiona el 80–90 % de los casos y el potente solo recibe los genuinamente ambiguos. Para casos de uso generativos (texto libre, escritura creativa, respuestas complejas a preguntas abiertas) la cascada es más difícil de configurar, porque la "corrección" de la respuesta es difícil de evaluar automáticamente.
Los costes del routing — no son gratis
El routing no es gratuito, y es importante contabilizar sus propios costes:
- Latencia adicional — cada llamada de clasificación añade tiempo. Router basado en embeddings: ~5–15 ms. LLM-as-a-judge: 50–200 ms. En aplicaciones interactivas en tiempo real, esto puede ser perceptible.
- Cascada ante clasificación errónea — si el modelo pequeño responde a una consulta difícil y la respuesta es mala, se paga por dos llamadas (pequeño + potente) en lugar de una. Una clasificación errónea no reduce los costes, los aumenta.
- Complejidad operativa — el router es un componente más en el sistema que puede fallar, degradarse y que hay que monitorizar y actualizar.
- Problema de arranque en frío — un router nuevo sin datos históricos clasifica mal. Las primeras semanas pueden ser peores que la estrategia de un solo modelo.
Por eso el routing funciona mejor en sistemas con alto volumen, consultas heterogéneas y una separación clara entre tareas fáciles y difíciles. Si recibe 100 consultas al día y todas son aproximadamente igual de complejas, el overhead del router no aportará un ahorro significativo.
Antes del despliegue, respóndase: ¿cuál es realmente la distribución de dificultad de sus consultas? Si no tiene datos, dedique dos semanas a registrar y anotar manualmente una muestra de 200–300 consultas. Este ejercicio también revela otros problemas — por ejemplo, que el 40 % de las llamadas contiene el mismo system prompt largo, donde el prompt caching ahorraría más que el routing.
Cuándo el routing no es suficiente y qué hace cada técnica
El routing aborda un aspecto de los costes — la elección del modelo. Hay situaciones donde otra optimización es más eficaz:
Prompts con prefijos repetitivos → El Prompt caching suele ser un movimiento más potente. Si el 80 % de sus llamadas comparte el mismo system prompt de 3 000 tokens, el prompt caching en Anthropic reduce los costes de esos tokens en un 90 %. El routing no sería suficiente para el mismo problema.
Aumento del coste por un agente con historial largo → Aquí ayuda acortar el contexto y la sumarización, no el routing. Véase costes del agente de IA en producción.
Respuesta lenta bajo carga elevada → El routing también es aquí solo una respuesta parcial. La elección del framework de serving (vLLM vs. Ollama), el continuous batching y el tamaño del KV cache tienen mayor impacto en el throughput.
Routing por contenido, no por dificultad → Otro caso de uso: algunas consultas deben ir a un modelo entrenado en un dominio concreto (p. ej., un modelo fine-tuned para documentación de fabricación), otras al modelo general. Esto es content-based routing y es una capa arquitectónica independiente, ajena a la optimización de costes.
Implementación: por dónde empezar
Si quiere probar el routing, esta es la secuencia que recomendamos:
- 1.Recoja datos antes de implementar nada. Registre las consultas con metadatos — longitud, tipo de tarea, tiempo de respuesta, puntuación de calidad (si la tiene). Sin datos, cualquier router se calibra a ciegas.
- 1.Empiece con un router heurístico sobre la división más obvia. Si sabe que el 30 % de sus consultas son clasificaciones en cuatro categorías y el 70 % son generativas, una regla simple "si tipo=clasificación → modelo pequeño" aporta ahorro inmediato sin overhead de ML.
- 1.Pruebe la calidad del modelo pequeño con datos reales. No se apoye en cifras de benchmarks. Tome 100 consultas reales de su producción, ejecútelas a través del modelo pequeño y evalúelas manualmente. Descubrirá dónde falla el modelo y dónde sorprende.
- 1.Implemente la cascada con umbralado de logprobs.
vLLMySGLangexponen ambos las log-probabilidades de los tokens. Establezca el umbral de forma experimental: empiece en 0,80, mida las escalaciones y los falsos positivos.
- 1.Monitorice la distribución de escalaciones a lo largo del tiempo. Si la proporción de escalaciones crece, o bien está cambiando el tipo de consultas, o bien el modelo pequeño está degradando en alguna categoría. El router necesita calibración continua, no es algo de "configurar y olvidar".
Para un punto de partida de código abierto, RouteLLM de LMSYS / UC Berkeley (Apache 2.0) es una buena base — incluye clasificadores preentrenados y un harness de evaluación. Para despliegues enterprise con requisitos de funcionamiento on-prem, el enfoque basado en embeddings con embeddings BGE-M3 y almacenamiento vectorial local Qdrant es más práctico desde la perspectiva de la soberanía de datos.
Cuándo no hacer routing
A pesar del ahorro, el routing tiene contraindicaciones reales:
- Bajo volumen (menos de varios miles de consultas al día) — el overhead de implementación y mantenimiento no compensa el ahorro.
- Caso de uso homogéneo — si todas las consultas son igual de complejas (p. ej., puramente análisis legal complejo), el routing solo añade complejidad sin beneficio.
- Coste elevado del error — en entornos regulados donde incluso una respuesta parcialmente incorrecta del modelo barato causa problemas (sanidad, compliance, decisiones legales), la cascada es más arriesgada. Aquí es más seguro definir un conjunto estrecho de tareas para el modelo pequeño con verificación manual al 100 %.
- No determinismo del modelo al escalar — si su aplicación requiere reproducibilidad (la misma consulta, siempre la misma respuesta), la cascada lo complica: a veces responde el modelo pequeño, a veces el potente, las salidas difieren.
Preguntas frecuentes
¿Cómo sé si tengo suficiente diversidad de consultas para que el routing valga la pena?
Exporte una muestra de 200–300 consultas reales y clasifíquelas manualmente en tres grupos: fáciles, medias, difíciles. Si más del 30 % cae en la categoría "fácil", el routing aportará un ahorro medible. Si la distribución es uniforme o sesgada hacia "difíciles", el efecto será marginal.
¿En qué se diferencia el routing del balanceo de carga entre varias instancias del mismo modelo?
El balanceo de carga resuelve el throughput y la disponibilidad — distribuye las peticiones entre varias instancias del mismo modelo. El routing resuelve la selección del modelo — decide *qué* modelo (otra clase de capacidades, otro precio) recibe cada consulta. Son complementarios: puede tener routing entre modelos y balanceo de carga dentro de cada modelo.
¿Qué hacer cuando el modelo pequeño responde pero la respuesta parece plausible y, sin embargo, es factualmente incorrecta?
Este es el mayor riesgo del cascading. La puntuación de confianza basada en log-probabilidades no detecta errores factuales — el modelo puede estar "seguro" y equivocarse. Tres medidas ayudan: (1) restrinja el modelo pequeño a tareas con salida verificable (extracción, clasificación), no a preguntas factuales; (2) añada verificación post-procesamiento de la salida (regex, esquema JSON, lista de comprobación); (3) en dominios sensibles, escale siempre al modelo potente o añada un paso de human-in-the-loop.
¿Cuál es la diferencia entre routing y un sistema multi-agente donde el propio agente decide qué llamar?
En un sistema multi-agente, el agente orquesta otras herramientas y modelos como parte de la solución de la tarea — la toma de decisiones está dentro del bucle LLM. El router se sitúa antes de la llamada LLM y es un clasificador externo. El router es más rápido y barato de ejecutar, pero no tiene acceso a la semántica de la tarea con la profundidad que tiene un agente. Para pipelines complejos, consulte arquitecturas de agentes de IA.
¿Puedo aplicar routing también con modelos locales, no solo con la API en la nube?
Sí, y aquí el beneficio puede ser incluso más pronunciado. En el mismo servidor puede tener un modelo pequeño de 7B y uno mayor de 34B. El router envía las consultas sencillas al 7B (menos VRAM, menor latencia) y las complejas al 34B. El ahorro no es financiero, sino de capacidad — el 7B gestiona un throughput mucho más alto en el mismo hardware, de modo que el 34B permanece disponible para los casos difíciles sin cola.
*En MP Industrial Solutions ayudamos a las empresas a configurar una estrategia de routing que tenga sentido para su mix concreto de consultas — desde la heurística simple hasta el clasificador entrenado con datos propios. Si está gestionando los costes de LLM en producción o construyendo infraestructura de serving para varios casos de uso, estaremos encantados de analizar su situación juntos.*