Usar siempre el modelo más potente parece una decisión segura, pero puede encarecer y ralentizar un agente sin mejorar todas sus respuestas. Usar siempre uno pequeño reduce coste, aunque puede fallar justo en las tareas que necesitan más razonamiento. NVIDIA plantea otra opción: un sistema que reúne contexto con un modelo especializado, responde directamente cuando la petición es sencilla y escala a un modelo más potente cuando el problema lo exige. Tiene sentido, pero solo si el enrutado se prueba con trabajo real de la empresa.
Qué ha pasado exactamente
NVIDIA publicó el 4 de agosto de 2026 el vídeo Why AI Agents Need More Than One Model. Su tesis es que un agente empresarial puede combinar modelos de frontera para tareas difíciles, modelos abiertos especializados para trabajo repetitivo y despliegues locales cuando importan la privacidad, la latencia o el volumen.
El ejemplo presentado es Waldo, un modelo especializado de Glean entrenado a partir de NVIDIA Nemotron 3 Nano. Según el vídeo, Waldo reúne contexto de fuentes como tickets de soporte, Slack y encuestas, y decide si el sistema puede responder directamente o si debe entregar ese contexto a un modelo de frontera para un análisis más profundo.
NVIDIA afirma que este enrutado permite a Glean buscar contexto empresarial diez veces más rápido, reducir la latencia un 50 % y utilizar un 25 % menos de tokens sin reducir la calidad de las respuestas. Son métricas comunicadas por el proveedor en una pieza promocional; no se aporta en el vídeo el conjunto de pruebas completo para reproducirlas de forma independiente.
La idea del router no depende de NVIDIA. RouteLLM, un proyecto abierto asociado a investigadores de LMSYS y UC Berkeley, ofrece un servidor compatible con la API de OpenAI para decidir entre un modelo fuerte y otro más barato. Su documentación insiste en calibrar el umbral con consultas parecidas a las que recibirá el sistema y en evaluar después coste y calidad.
Qué hace realmente un router de modelos
Un router observa la petición y decide qué modelo debe atenderla. La versión más sencilla aplica reglas: por ejemplo, usar un modelo local para clasificar documentos y uno de frontera para redactar una recomendación compleja. Otras versiones estiman la dificultad de la consulta, el riesgo, el coste permitido o la probabilidad de que el modelo barato produzca una respuesta suficiente.
La dificultad está en que el router también puede equivocarse. Si envía una tarea compleja al modelo barato, aumenta el retrabajo o el riesgo. Si escala casi todo al modelo fuerte, el sistema conserva el coste y la latencia que pretendía evitar. Por eso el porcentaje de peticiones enviadas a cada modelo no sirve como única métrica: hay que observar el resultado correcto por tipo de tarea.
Cuándo tiene sentido usar varios modelos
La arquitectura suele tener sentido cuando el flujo mezcla trabajos muy distintos. Una consultora puede clasificar documentación con un modelo pequeño y reservar el modelo potente para elaborar hipótesis. Una agencia puede resumir campañas de forma barata y escalar el análisis de anomalías. Un SaaS B2B puede atender preguntas frecuentes con baja latencia y derivar los casos ambiguos a un modelo más capaz o a una persona.
No aporta valor añadir un router cuando el volumen es bajo, las tareas son homogéneas o todavía no existe una forma fiable de evaluar las respuestas. En ese escenario, la complejidad operativa puede superar el ahorro. Primero conviene estabilizar una tarea, registrar sus fallos y entender cuánto cuesta revisarla.
El router debe equilibrar coste, calidad, velocidad y control
NVIDIA, RouteLLM y análisis DÍA UNO · 5 de agosto de 2026
Modelo rápido o especializado
Modelo rápido o especializado- Clasificación, extracción y respuestas frecuentes con criterios estables.
- Menor coste y latencia cuando el volumen es alto.
- Puede ejecutarse en local si la privacidad o la conectividad lo justifican.
Modelo más potente
Modelo más potente- Casos ambiguos, análisis complejos y decisiones con más contexto.
- Mayor coste por llamada y, normalmente, más tiempo de respuesta.
- Debe reservarse para tareas donde su mejora compense el coste y la revisión.
Cómo elegir modelos para un agente de IA
La elección no debería empezar por una tabla de benchmarks generales. Debe empezar por una muestra de trabajo real: consultas simples, excepciones, documentos largos, peticiones sensibles y casos donde una respuesta incorrecta obliga a repetir el proceso. Esa muestra permite comparar qué modelo resuelve cada categoría con calidad suficiente.
El coste relevante tampoco es solo el precio por token. Incluye la llamada al router, la recuperación de contexto, los reintentos, la revisión humana y el retrabajo provocado por una mala decisión. Un modelo barato que obliga a corregir muchas salidas puede resultar más caro por resultado correcto.
Privacidad y control pueden cambiar la decisión. Un modelo abierto ejecutado en infraestructura propia reduce ciertos movimientos de datos, pero no elimina la necesidad de permisos, registros, aislamiento y mantenimiento. Un modelo externo puede simplificar la operación, aunque exige revisar qué información recibe y bajo qué condiciones.
La dependencia geográfica también cuenta: una posible restricción al acceso exterior de modelos chinos recuerda que una API o unos pesos pueden dejar de estar disponibles bajo las mismas condiciones. Y una novedad como Kimi K3 debe evaluarse por licencia, reproducibilidad, operación y sustitución, no solo por su posición en un benchmark.
La configuración debe poder revertirse. Si el router no mejora coste por resultado correcto, latencia y calidad de forma conjunta, conviene volver a una asignación fija de modelos hasta disponer de más evidencia.
Hecho de la fuente
Hecho de la fuenteNVIDIA ha publicado un caso donde un modelo especializado reúne contexto y decide si responde directamente o escala a un modelo de frontera. RouteLLM ofrece código abierto para servir, calibrar y evaluar una decisión similar entre un modelo fuerte y otro más barato.
Lectura DÍA UNO
Lectura DÍA UNOLectura DÍA UNO: añadir modelos no crea valor por sí solo. Cada tarea debe ir al modelo suficiente, y el router tiene que reducir coste o latencia sin aumentar errores, revisión ni exposición de datos.
Qué probaríamos esta semana
- Elegir una tarea con volumen
Seleccionar un flujo repetido que ya tenga ejemplos y un criterio reconocible de respuesta correcta, como clasificación de leads o resumen de incidencias.
- Comparar dos modelos
Ejecutar la misma muestra con un modelo rápido y otro más potente, conservando calidad, latencia, coste y tiempo de revisión por caso.
- Definir la escalada
Empezar con reglas visibles para los casos ambiguos, sensibles o largos antes de entrenar un router que nadie pueda explicar.
- Medir el resultado completo
Aceptar el enrutado solo si mejora el coste por resultado correcto sin aumentar errores críticos, retrabajo o tiempo total del responsable humano.
Revisión recomendada: 19 agosto 2026.
Qué no sabemos todavía
Las fuentes demuestran que el enrutado multimodelo es técnicamente viable, pero no permiten trasladar un ahorro concreto a cualquier empresa, tarea o combinación de modelos.
- No conocemos el conjunto completo de evaluación utilizado para las métricas del caso Glean presentado por NVIDIA.
- Los resultados publicados por RouteLLM dependen del par de modelos, los precios y los benchmarks utilizados en cada evaluación.
- No existe un umbral universal para decidir cuándo escalar; debe calibrarse con consultas representativas de cada empresa.
- Un router añade otra pieza que observar, proteger y mantener, y puede convertirse en un punto adicional de fallo.
Fuentes y método
- Fuente primariaWhy AI Agents Need More Than One Model
- Código y evaluaciónRouteLLM: A framework for serving and evaluating LLM routers
- InvestigaciónRouteLLM: Learning to Route LLMs with Preference Data
- Conversación de mercadoLLM Router: Best way to dynamically route prompts between proprietary and open-sourced models?
Separación editorial: los hechos proceden de las fuentes enlazadas; la lectura, las implicaciones y las acciones están identificadas como análisis propio de DÍA UNO. La imagen conserva su procedencia y no se usa como prueba del hecho.