Enrutadores de inferencia: elegir modelo según la petición
Actualizado: 2026-05-03
Un enrutador de inferencia decide, para cada petición que llega a tu aplicación, a qué modelo concreto enviarla. Durante 2023 y 2024 la arquitectura dominante era una aplicación apuntando a un único modelo, y esa simplicidad daba tranquilidad. Los equipos serios han descubierto que un único modelo no es óptimo ni por coste ni por latencia ni por adecuación al tipo de petición, y los enrutadores se han convertido en pieza estándar de producción.
Puntos clave
- Un enrutador bien diseñado reduce el coste total de tokens entre un 30 y un 70 % manteniendo la calidad percibida.
- Las peticiones no son homogéneas: clasificar cuáles van al modelo barato y cuáles al grande es el núcleo de la decisión.
- Cuatro patrones cubren el 90 % de los casos: longitud, tipo de tarea, clasificador auxiliar y enrutamiento aprendido.
- Sin observabilidad, el enrutador puede tomar decisiones malas durante meses sin que nadie lo detecte.
- La complejidad solo se justifica cuando el volumen es significativo y las peticiones son heterogéneas.
El problema que resuelven
Las peticiones a un modelo de lenguaje no son homogéneas. Una clasificación simple, una extracción de entidades corta o una consulta de soporte frecuente se resuelven perfectamente con un modelo barato y rápido. Un análisis de código extenso, una redacción técnica exhaustiva o una pregunta que exige razonamiento en varios pasos se benefician de un modelo grande. Enviar todo al modelo grande es caro; enviar todo al pequeño baja la calidad donde más importa. La solución intermedia es enrutar.
El enrutador típico recibe la petición, la evalúa, decide qué modelo debe atenderla y reenvía la petición devolviendo la respuesta al cliente. Esa decisión puede tomarse con heurísticas simples, con un clasificador entrenado, con un modelo pequeño que actúa como triage, o con una combinación de los tres.
Patrones de decisión
Por longitud. Si la petición es corta, modelo pequeño; si es larga, modelo grande. Esta heurística captura bastante valor con mínima complejidad porque las tareas simples suelen ser cortas y las complejas, largas. Es el punto de partida natural.
Por tipo de tarea. La aplicación sabe qué función se invoca: resumen, extracción, generación creativa, razonamiento. Cada función tiene un modelo preconfigurado. Cuando la estructura lo permite, la decisión es determinista y auditable.
Clasificador auxiliar. Un modelo pequeño muy barato decide si la petición es simple o compleja y enruta al ejecutor correspondiente. Si acierta el 90 % de las veces, el ahorro compensa con creces la latencia añadida de unos cientos de milisegundos.
Enrutamiento aprendido. Se recogen registros de producción, se etiquetan cuáles el modelo barato resolvió bien y cuáles necesitaron el grande, y se entrena un clasificador. Es el patrón que más reduce coste pero el que más esfuerzo operativo exige: hay que reentrenar periódicamente y vigilar la deriva de distribución.
Proveedores y opciones
- LiteLLM[1] se ha consolidado como la capa de abstracción de referencia: un proxy local que habla con la mayoría de proveedores con interfaz uniforme, permitiendo cambiar de modelo sin tocar el código de la aplicación.
- OpenRouter[2] ofrece enrutamiento como servicio con políticas de optimización por coste, latencia o equilibrio.
- Portkey[3] y Helicone[4] se centran en observabilidad y gobernanza: trazas, métricas agregadas y control de presupuesto.
Para equipos que quieren control total, construir sobre LiteLLM o directamente sobre los SDK oficiales es razonable. La lógica central no es compleja; la complejidad reside en la observabilidad, los fallos controlados y la política de reintentos.
Ejemplo mínimo funcional
def route_request(prompt: str, history: list) -> str:
tokens = estimate_tokens(prompt) + sum(
estimate_tokens(m) for m in history[-6:]
)
has_code = "```" in prompt or any("```" in m for m in history[-3:])
complexity_keywords = ["analiza", "explica por qué", "compara", "diseña"]
is_complex = any(k in prompt.lower() for k in complexity_keywords)
if tokens > 2000 or has_code or is_complex:
return "sonnet-4-5"
return "haiku-3-5"Este enrutador de veinte líneas captura patrones útiles: longitud, presencia de código y palabras clave de complejidad. En aplicaciones reales baja el coste alrededor de un 40 % sin sofisticación adicional. Las variantes más complejas solo valen cuando el ahorro marginal justifica el trabajo.
Trampas comunes
- Probar solo con datos sintéticos. Las peticiones reales tienen distribución distinta: más diversidad, más casos atípicos, más formatos inesperados. Un enrutador afinado con cien ejemplos puede comportarse muy distinto con diez mil peticiones reales.
- No medir degradación de calidad. El enrutador puede estar ahorrando dinero a costa de una experiencia peor sin que nadie lo detecte. Las evaluaciones automatizadas sobre muestras de producción son la única forma fiable.
- Sin escalado de fallos. Cuando el modelo barato devuelve algo inadecuado hay que tener un flujo de escalado al grande. El patrón correcto: intenta modelo barato → si supera criterios úsalo → si no, reintenta con el grande.
- Ignorar el contexto de conversación. En un chat, si el usuario ha hecho seis preguntas complejas, la séptima probablemente también lo es aunque parezca breve.
Observabilidad mínima
Un enrutador ciego es peligroso. Para cada petición hay que registrar qué modelo fue elegido, con qué razón, qué latencia tuvo, qué coste supuso y qué resultado dio. Sin esa telemetría el enrutador puede tomar decisiones malas durante meses sin que nadie lo note.
Conviene exponer también métricas agregadas al equipo: distribución de modelos usados, coste medio por petición, proporción de escalados al modelo grande y distribución de latencias. Una alerta simple sobre la proporción de escalados detecta derivas antes de que se conviertan en problemas percibidos. Esto conecta directamente con lo que cubre una buena estrategia de observabilidad para LLM y con las herramientas que se repasan en el stack de observabilidad 2026.
Cuándo compensa
Un enrutador no tiene sentido si la aplicación usa un solo modelo y el volumen es bajo. Tiene sentido cuando:
- El volumen de peticiones es razonable.
- Las peticiones son heterogéneas en complejidad.
- El equipo puede invertir tiempo en medir y afinar.
En esa combinación los ahorros son consistentes y el riesgo de degradación se controla con observabilidad correcta. La recomendación operativa es empezar simple, con heurísticas claras desde el primer día, iterar con datos reales y solo pasar a enfoques aprendidos cuando las heurísticas se hayan agotado. Un enrutador de cincuenta líneas con buena telemetría supera casi siempre a un clasificador entrenado sin métricas, porque el primero se adapta y el segundo se oxida. Esta misma lógica aplica cuando se combina el enrutador con cachés de LLM para maximizar el ahorro. Para quien gestiona la infraestructura subyacente, containerd con Wasm ofrece otra palanca de eficiencia en el plano de ejecución.
