Un enrutador de inferencia es la pieza que decide, para cada petición que llega a tu aplicación con modelos de lenguaje, a qué modelo concreto se la envías. Durante 2023 y buena parte de 2024 la arquitectura dominante era una aplicación apuntando a un único modelo, habitualmente GPT-4 o Claude, y esa simplicidad daba tranquilidad. Durante 2025, sin embargo, los equipos serios se han dado cuenta de 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 de inferencia se han convertido en pieza estándar de despliegues de producción. Vale la pena entender qué hacen, qué patrones funcionan, qué cautelas importan y cuándo su complejidad se justifica.
Qué problema resuelven
El punto de partida es que las peticiones a un modelo de lenguaje no son homogéneas. Una pregunta de clasificación simple, una conversación de soporte conocido, una extracción de entidades de un documento corto pueden resolverse perfectamente con un modelo barato y rápido. Una pregunta abierta que requiere razonamiento complejo, un análisis de código largo, una redacción técnica exhaustiva se benefician de un modelo grande. Enviar todo al modelo grande es caro; enviar todo al modelo barato es malo en los casos complejos. La solución intermedia es enrutar.
El enrutador típico recibe la petición, la evalúa rápidamente, decide qué modelo debe atenderla, y reenvía la petición a ese modelo devolviendo la respuesta al cliente. Esa decisión puede hacerse con heurísticas simples, con un clasificador entrenado, con un modelo pequeño auxiliar que actúa como triage, o con una combinación. El objetivo es que el cliente no note diferencia y la factura baje significativamente.
En un caso de uso típico bien diseñado, un enrutador sensato reduce el coste total de tokens entre un treinta y un setenta por ciento manteniendo la calidad percibida. Eso es dinero real en producciones con volumen, y es una de las razones por las que los enrutadores han pasado de curiosidad a infraestructura asumida.
Patrones de decisión
El patrón más básico es enrutamiento por longitud. Si la petición es corta y la respuesta esperada es corta, modelo pequeño; si la petición es larga, modelo grande. Esta heurística captura bastante valor con mínima complejidad, porque las tareas simples suelen ser cortas y las complejas suelen ser largas. No es perfecta pero es un buen punto de partida.
Un patrón más sofisticado es enrutamiento por tipo de tarea. La aplicación sabe qué función se está invocando: resumen, extracción, generación creativa, razonamiento. Cada función tiene un modelo óptimo preconfigurado. Este patrón requiere que el código diferencie tipos de petición explícitamente, pero cuando la estructura lo permite es muy eficaz porque la decisión es determinista y auditable.
Un patrón híbrido interesante es usar un modelo pequeño como clasificador. La petición llega, un modelo pequeño muy barato decide si es simple o compleja, y en función de esa decisión se enruta a un modelo ejecutor. El modelo clasificador puede ser algo como GPT-4o mini o Claude Haiku, cuesta una fracción del ejecutor, y añade unos cientos de milisegundos de latencia. Si el clasificador acierta el noventa por ciento de las veces, el ahorro compensa con creces.
El patrón más avanzado es enrutamiento aprendido. Se recogen registros de peticiones y resultados en producción, se etiqueta cuáles fueron atendidas bien por el modelo barato y cuáles necesitaron el grande, y se entrena un clasificador especializado. Este patrón es el que más reduce coste pero también el que más esfuerzo operativo exige: hay que reentrenar periódicamente, vigilar deriva y mantener una infraestructura de recolección de datos.
Proveedores y opciones
El ecosistema de 2025 ofrece varias opciones para no construir un enrutador desde cero. LiteLLM se ha consolidado como la capa de abstracción de referencia: un proxy local que habla con la mayoría de proveedores grandes con interfaz uniforme, permitiendo cambiar de modelo sin tocar el código de la aplicación. Muchos equipos lo usan como base sobre la que montar su lógica de enrutamiento.
OpenRouter va un paso más allá ofreciendo enrutamiento como servicio: se conecta a decenas de proveedores y deja elegir políticas como optimizar por coste, por latencia o por equilibrio. Es útil para equipos que quieren flexibilidad sin operar infraestructura propia, aunque introduce dependencia de un proveedor más.
Portkey y Helicone ocupan un espacio adyacente con enfoques más orientados a observabilidad y gobernanza: trazas de peticiones, métricas agregadas, control de presupuesto. Menos centrados en decisión de enrutamiento pura, pero cubriendo un espacio importante en aplicaciones serias.
Para equipos que quieren control total, construir sobre LiteLLM o directamente sobre los SDK oficiales es razonable. La lógica central de un enrutador no es compleja; la complejidad está en los detalles de observabilidad, fallo controlado y política de retries.
Trampas comunes
El error más frecuente es probar el enrutador solo con peticiones de prueba y no con tráfico real. Las peticiones reales tienen distribución distinta: más diversidad, más casos atípicos, más formatos inesperados. Un enrutador afinado con un conjunto de pruebas de cien ejemplos puede comportarse muy distinto con diez mil peticiones reales, y descubrir los fallos solo cuando ya están en producción es doloroso.
Otro error es no medir degradación de calidad. Enrutar al modelo barato reduce coste pero puede bajar calidad en casos donde la heurística falla. Si no hay una forma sistemática de medir esa degradación, el equipo puede estar ahorrando dinero a costa de una experiencia de usuario peor sin darse cuenta. Las evaluaciones automatizadas ejecutadas regularmente sobre muestras de producción son la única forma fiable de detectar esto.
Un tercer error es la asimetría de fallo. Cuando el modelo barato falla o devuelve algo inadecuado, hay que tener un flujo de escalado al modelo grande. Si ese flujo no existe, una parte de los usuarios recibe una respuesta pobre y nunca se recupera. El patrón correcto es: intenta modelo barato, si la respuesta cumple criterios aceptables úsala, si no, reintenta con modelo grande y devuelve esa. Esto tiene coste en latencia pero preserva calidad.
Un cuarto error es ignorar el contexto de conversación. En un chat, la decisión de qué modelo usa el turno actual debería tener en cuenta el historial. Si el usuario ha hecho seis preguntas complejas, es probable que la séptima también lo sea, aunque parezca breve. Los enrutadores que deciden turno por turno sin contexto suelen equivocarse más de lo que deberían.
Ejemplo mínimo de enrutador
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 sin complejidad: longitud, presencia de código, palabras clave que sugieren complejidad. No es óptimo pero baja coste un cuarenta por ciento en aplicaciones reales que he visto, con retorno que compensa el esfuerzo de escribirlo y mantenerlo. Variantes más sofisticadas solo valen la pena cuando el ahorro marginal justifica el trabajo.
Observabilidad mínima
Un enrutador ciego es peligroso. Hay que registrar para cada petición qué modelo fue elegido, con qué razón, qué latencia tuvo, qué coste supuso y qué resultado dio. Esa telemetría permite luego analizar si las heurísticas eran correctas, detectar patrones que antes no se veían y ajustar el enrutador con datos. Sin telemetría el enrutador puede estar tomando decisiones malas durante meses sin que nadie se entere.
También conviene exponer métricas agregadas al equipo: distribución de modelos utilizados, coste medio por petición, proporción de escalados al modelo grande, distribución de latencias. Estas métricas detectan derivas tempranas, como cuando un cambio en los tipos de petición hace que el modelo barato ya no baste y la proporción de escalados sube. Una alerta simple sobre esa proporción captura esa deriva antes de que pase a ser un problema percibido.
Cuándo compensa
Un enrutador de inferencia no tiene sentido si tu aplicación usa un solo modelo para todo y el volumen es bajo. La complejidad añadida no se paga con el ahorro. Tiene sentido cuando el volumen es razonable, cuando las peticiones son heterogéneas en complejidad, y cuando el equipo puede invertir algún tiempo en medir y afinar. En esa combinación los ahorros son consistentes y el riesgo de degradación se controla con observabilidad correcta.
Mi lectura
Los enrutadores de inferencia son una de esas piezas que en 2023 parecían sobreingeniería y en 2025 son práctica asumida. La tecnología de modelos ha creado un espacio con mucha variación de precio y capacidad, y tratar ese espacio como si fuera homogéneo deja mucho dinero sobre la mesa. Bien diseñados son una palanca enorme de eficiencia; mal diseñados son una fuente silenciosa de degradación.
La recomendación operativa es empezar simple, con heurísticas claras y observabilidad desde el primer día. Iterar con datos reales, resistir la tentación de sofisticación prematura, 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 ni revisión, porque el primero se adapta y el segundo se oxida. Esa disciplina es lo que separa el ahorro real del ahorro aparente.
