NVIDIA ha presentado NeMo Switchyard, un proyecto de código abierto pensado para resolver uno de los problemas que empieza a aparecer al llevar agentes de inteligencia artificial a producción: utilizar siempre el mismo modelo puede resultar caro, lento y, además, no necesariamente ofrece el mejor resultado. La propuesta introduce una capa de enrutamiento capaz de decidir qué modelo debe ejecutar cada petición o incluso cada etapa de un trabajo, teniendo en cuenta capacidad, coste, latencia y el estado del propio agente.
Las claves de NVIDIA NeMo Switchyard en 20 segundos
- NeMo Switchyard permite repartir el trabajo de un agente entre diferentes modelos de IA.
- Puede utilizar modelos de distintos proveedores y traducir entre APIs de OpenAI y Anthropic.
- Incluye routers sin entrenamiento y otros que pueden aprender de cargas reales.
- En una prueba de LangChain, el enrutamiento redujo el coste un 74 %, aunque con unos seis puntos menos de precisión.
- El proyecto es abierto y está publicado bajo licencia Apache 2.0.
El planteamiento parte de una realidad cada vez más evidente para quienes desarrollan aplicaciones con grandes modelos de lenguaje (LLM). Un agente no realiza una única tarea. Puede empezar clasificando una petición, consultar documentación, escribir código, llamar a varias herramientas, detectar un error, razonar sobre él y terminar realizando una operación bastante rutinaria.
Pagar por el modelo más capaz para todos esos pasos puede ser innecesario. Utilizar siempre uno pequeño y barato plantea el problema contrario: cuando aparece una tarea difícil puede disminuir la tasa de éxito.
NVIDIA propone sustituir esa elección estática por un sistema de modelos en el que el modelo utilizado pueda cambiar mientras el agente trabaja.
Un router que decide qué modelo necesita cada tarea
NeMo Switchyard funciona como una capa situada entre la aplicación y los modelos.
Cuando llega una petición, el router puede analizar diferentes señales para decidir dónde enviarla. NVIDIA agrupa esas señales en tres grandes áreas: capacidades del modelo, perfil de coste e infraestructura.
La decisión puede tener en cuenta el contenido de la consulta y su dificultad estimada, pero también información generada durante la ejecución: errores, llamadas a herramientas, latencia, carga del sistema, precios o el comportamiento observado anteriormente.
Esto permite llegar a escenarios bastante más interesantes que un simple balanceador.
Un agente de programación podría utilizar inicialmente un modelo económico para explorar un repositorio. Si comienza a acumular errores o entra en un bucle sin resolver el problema, Switchyard puede elevar la tarea a un modelo más capaz. Superado el obstáculo, las siguientes modificaciones mecánicas podrían regresar al modelo más eficiente.
También puede mantenerse afinidad durante una sesión. Si el router ya ha determinado que una conversación debe utilizar determinado modelo, esa decisión puede conservarse en los siguientes turnos cuando no tenga sentido volver a clasificar cada petición.
La arquitectura intenta además desacoplar el nombre lógico del modelo del proveedor que realmente lo ejecuta. Un equipo podría cambiar un modelo, trasladarlo a otro endpoint o modificar el proveedor sin tener que reconstruir toda la lógica de routing.
El repositorio actual describe Switchyard como un proxy Python para tráfico LLM que puede traducir entre OpenAI Chat Completions, Anthropic Messages y OpenAI Responses. También admite endpoints compatibles con OpenAI, lo que permite utilizar plataformas como vLLM u Ollama, además de otros servicios de inferencia.
De clasificar una consulta a detectar que el agente se ha atascado
Una parte especialmente interesante de Switchyard son sus diferentes estrategias de routing.
El LLM classifier utiliza otro modelo como juez para seleccionar el candidato apropiado. Después puede mantener afinidad con ese modelo durante la sesión. Un sistema podría, por ejemplo, separar consultas de programación, matemáticas o tareas especializadas y enviarlas a modelos distintos.
El stage router va un paso más allá porque intenta entender en qué fase se encuentra un agente.
En un agente de programación, una sucesión de errores graves, exploraciones prolongadas o intentos improductivos puede indicar que hace falta mayor capacidad de razonamiento. Por el contrario, una secuencia estable de escrituras y modificaciones, especialmente después de superar las pruebas, puede justificar el uso de un modelo más eficiente.
El escalation router adopta otra estrategia: empieza directamente con el modelo económico y observa cómo progresa la tarea. Si un LLM utilizado como juez detecta dificultades mantenidas, errores repetidos o desviaciones, la sesión puede escalar hacia un modelo superior.
La idea se parece a trasladar al software una práctica bastante lógica: no asignar el recurso más caro hasta que realmente haga falta.
Switchyard incluye además routers ajustables mediante datos.
El denominado prefill router utiliza durante su entrenamiento información del estado interno de un LLM para aprender a estimar la dificultad de las consultas. En inferencia puede predecir la probabilidad de que diferentes modelos resuelvan correctamente una tarea y combinar esa estimación con coste, latencia u otras restricciones.
La diferencia es importante. El objetivo deja de ser responder a la pregunta «¿cuál es el mejor modelo?» y pasa a ser algo más concreto: «¿qué modelo tiene suficiente probabilidad de resolver esta petición con el coste y la latencia aceptables?».
LangChain mide un ahorro del 74 %, pero hay letra pequeña
NVIDIA aporta algunas cifras que ayudan a entender el potencial y también las concesiones de esta arquitectura.
LangChain evaluó Switchyard con un conjunto interno de 145 tareas multi-turno inspiradas en cargas de producción. Incluyen soporte al cliente sujeto a políticas, investigación de incidentes, automatización mediante correo y mensajería, utilización de herramientas, recuperación de información y trabajo con contextos largos.
Al enrutar las solicitudes entre NVIDIA Nemotron 3.5 Lightning y Claude Opus 4.8, el escalation router redujo el coste un 74 % frente a utilizar exclusivamente el modelo frontier. Solo el 7 % de las llamadas terminaron enviándose al modelo más potente.
El ahorro tuvo contrapartida: NVIDIA informa de aproximadamente seis puntos de pérdida de precisión.
Es una distinción relevante porque el routing no produce automáticamente mejores resultados y menor coste al mismo tiempo. El desarrollador tiene que decidir qué degradación de calidad considera admisible y configurar la política alrededor de ese objetivo.
Cognition también aplicó la metodología de routing por etapas en Devin Desktop. En FrontierCode Main utilizó Opus 5 y Kimi K2.7 y obtuvo un 50,6 % con un coste medio de 3,11 dólares. Según los datos publicados por NVIDIA, quedó a 2,8 puntos porcentuales del resultado de Opus 5 utilizado como referencia, pero con aproximadamente un 28 % menos de coste medio.
Son resultados proporcionados en el contexto del lanzamiento y no deben interpretarse como una garantía para cualquier agente. El ahorro dependerá de los modelos seleccionados, precios, prompts, número de llamadas a herramientas, dificultad de las tareas y política de routing.
El modelo deja de ser una decisión fija de la aplicación
La consecuencia técnica más interesante de Switchyard quizá no sea ninguno de sus routers concretos.
Durante los últimos años muchas aplicaciones de IA se han construido alrededor de una decisión bastante rígida: elegir GPT, Claude, Gemini, Llama u otro modelo y desarrollar el producto alrededor de su API.
La aparición de agentes cambia esa lógica.
Un agente puede realizar decenas o cientos de inferencias para completar un trabajo. Si algunas requieren razonamiento avanzado y otras son operaciones sencillas, la selección del modelo puede convertirse en una decisión dinámica de infraestructura.
Switchyard también intenta reducir el coste técnico de trabajar con varios proveedores. Su servidor de referencia acepta peticiones compatibles con APIs de OpenAI, Anthropic y Responses API, las convierte a su representación interna y devuelve después el formato esperado por la aplicación. Además, registra modelo seleccionado, latencia, tokens, resultado de las llamadas y razones utilizadas para tomar determinadas decisiones.
El repositorio permite incluso lanzar herramientas como Claude Code, Codex u OpenClaw a través del proxy de Switchyard y dirigir posteriormente sus peticiones hacia diferentes backends. El software puede instalarse mediante pip y utilizarse como servidor o directamente como biblioteca Python.
NVIDIA está integrando además el routing de Switchyard dentro del conjunto más amplio de NeMo, donde aparece como una de las herramientas destinadas a ajustar y mejorar agentes.
La propuesta encaja con una evolución que puede adquirir bastante importancia en la siguiente generación de aplicaciones de IA. La competición ya no consiste únicamente en encontrar un modelo que sea unos puntos mejor en un benchmark. Para determinadas cargas, puede resultar más útil disponer de varios modelos especializados y una capa suficientemente inteligente para saber cuándo utilizar cada uno.
Eso convierte el routing en otra pieza de la arquitectura de inferencia, junto con elementos ya habituales como gateways, observabilidad, cachés, balanceo de carga o gestión de costes. Y plantea también un reto adicional: cuanto más inteligente sea el router, más necesario será medir si sus decisiones realmente compensan la complejidad que introduce.
Preguntas frecuentes
¿Qué es NVIDIA NeMo Switchyard?
Es un proyecto de código abierto para enrutar peticiones de agentes y aplicaciones de IA entre diferentes modelos. Puede tomar decisiones utilizando criterios como capacidad, coste, latencia y señales obtenidas durante la ejecución.
¿NeMo Switchyard funciona únicamente con modelos de NVIDIA?
No. Su arquitectura es independiente del proveedor y puede trabajar con diferentes backends y formatos de API. El repositorio contempla OpenAI, Anthropic y endpoints compatibles con OpenAI, entre otros escenarios.
¿Puede cambiar de modelo mientras trabaja un agente?
Sí. Algunas estrategias pueden seleccionar un modelo para una sesión, mientras que otras analizan cada etapa y escalan hacia un modelo más capaz cuando detectan errores, bloqueos o mayor dificultad.
¿NeMo Switchyard es open source?
Sí. NVIDIA publica Switchyard como proyecto de código abierto bajo licencia Apache 2.0, con el código disponible en GitHub.
