Optimiza el enrutamiento de agentes con NVIDIA NeMo Switchyard

NVIDIA NeMo Switchyard permite que los agentes de IA seleccionen dinámicamente el mejor modelo para cada tarea, basándose en capacidades, costos y señales de infraestructura, lo que mejora tanto la eficiencia como la calidad de los resultados.

El SDK de NeMo Switchyard es agnóstico respecto al proveedor, soporta algoritmos de enrutamiento sin ajuste y ajustables, y mantiene una separación clara entre la lógica de enrutamiento y los proveedores específicos, facilitando una integración flexible a medida que cambian los despliegues de modelos. Las pruebas con LangChain y Cognition demuestran que este enfoque reduce significativamente los costos manteniendo una alta precisión en entornos de producción.

Construir un agente de IA no termina con la elección de un modelo único. Cada modelo posee fortalezas, debilidades y perfiles de costos que fluctúan según la carga de trabajo. Por ejemplo, una tarea de agente puede requerir clasificación en un paso, razonamiento en el siguiente y un modelo pequeño para tareas rutinarias. Enviar cada solicitud al modelo más grande aumenta los costos y la latencia, mientras que usar solo modelos pequeños reduce la calidad en tareas complejas.

El enrutamiento de modelos soluciona este desafío orquestando modelos especializados y de frontera. NVIDIA NeMo Switchyard hace que este problema de ingeniería sea práctico, permitiendo a los desarrolladores enrutar el trabajo sin reconstruir sus aplicaciones para cada proveedor. En tiempo de ejecución, un enrutador evalúa cada solicitud y su contexto disponible, enviando el trabajo al modelo que mejor se adapte a los requisitos, restricciones y políticas de la tarea.

¿Cómo toman decisiones los enrutadores de modelos?

Consideremos un sistema de modelos realizando una tarea de uso de computadora medida por el benchmark Terminal-Bench Hard (Figura 1). Aunque DeepSeek V4 tiene la mayor precisión general en este ejemplo, no es el mejor modelo para cada grupo de tareas. Por ejemplo, Kimi K2.6 es más adecuado para grupos de tareas de ML y RL, mientras que Qwen3.5 397B A17B es preferible para matemáticas y ciencia. Los seis grupos de tareas restantes deberían utilizar DeepSeek V4. Este enfoque se aplica a nivel de tarea individual o en fases de resolución.

Figura 1. Precisión de los modelos en diferentes grupos de tareas en Terminal-Bench Hard con el agente Terminus.
Figura 1. Precisión de los modelos en diferentes grupos de tareas en Terminal-Bench Hard con el agente Terminus.

El costo y el tiempo de finalización complican la decisión, como se muestra en la Figura 2. Cada modelo tiene costos asociados de ejecución o acceso, además de un perfil de verbosidad que incluye tokens y llamadas a herramientas.

Figura 2. Precisión del modelo frente a tokens de prompt totales (izquierda) y tokens de salida totales (derecha) en Terminal-Bench Hard.
Figura 2. Precisión del modelo frente a tokens de prompt totales (izquierda) y tokens de salida totales (derecha) en Terminal-Bench Hard.

La construcción de un enrutador requiere considerar señales de diversas fuentes. Las decisiones de enrutamiento efectivas dependen de tres pilares:

  • Capacidades del modelo: Qué modelo(s) puede resolver la tarea correctamente.
  • Perfil de costo del modelo: Latencia y costo asociados a cada modelo.
  • Infraestructura: Señales a nivel de sistema que permiten transferencias confiables.

Para entender las señales de capacidad y costo, el enrutador puede:

  • Analizar la solicitud: Clasificar según tema o dificultad estimada usando modelos de embedding o clasificadores.
  • Evaluar el estado del modelo: Examinar logprobs, trazas de agentes, flujos residuales o matrices de atención.
  • Considerar el sistema: Evaluar precios, carga actual, latencia y señales específicas del agente como errores.

¿Cómo habilita NeMo Switchyard el enrutamiento?

Los algoritmos de enrutamiento generan señales que informan las decisiones. El sistema requiere infraestructura para enviar la solicitud al modelo elegido y devolver la respuesta. Esto comienza con switchyard-libsy, el SDK agnóstico que representa las solicitudes, define los modelos disponibles y gestiona las llamadas. Cada objetivo de modelo tiene un nombre semántico, mapeado por el cliente al endpoint del proveedor.

Figura 3. Diagrama de arquitectura que muestra el funcionamiento de NeMo Switchyard.
Figura 3. Diagrama de arquitectura que muestra el funcionamiento de NeMo Switchyard.

NeMo Switchyard puede mantener el estado de enrutamiento a través de la sesión de un agente cuando la política lo requiere, reteniendo información de turnos anteriores como resultados de herramientas o decisiones de afinidad. Esta separación es vital porque los despliegues cambian: un equipo puede actualizar un modelo, moverlo a otro endpoint o cambiar de proveedor sin modificar la integración de enrutamiento. El servidor de NeMo Switchyard actúa como referencia para exponer el enrutamiento mediante APIs estándar, aceptando solicitudes de OpenAI, Anthropic y Responses API, traduciéndolas internamente para la ejecución.

Vía NVIDIA Developer.