NVIDIA presenta Switchyard, un puente para enrutar tráfico entre OpenAI y Anthropic

NVIDIA presentó Switchyard, un proxy y biblioteca de código abierto que traduce y enruta solicitudes entre las APIs de OpenAI y Anthropic. La herramienta también incorpora algoritmos de selección, métricas de Prometheus y compatibilidad con distintos backends, aunque el proyecto advierte que sigue en etapa prealfa y no debe utilizarse en producción.
***

• Switchyard funciona como una capa intermedia entre agentes, APIs y modelos alojados en servicios como vLLM, NVIDIA NIM u Ollama.
• El sistema acepta formatos de OpenAI Chat Completions, OpenAI Responses y Anthropic Messages, incluidos eventos de streaming.
• La herramienta se distribuye bajo Apache 2.0, pero el proyecto la considera experimental y anticipa cambios importantes antes de su versión 1.0.

Los equipos que desarrollan agentes de programación suelen enfrentar un problema menos visible que la elección del modelo: la incompatibilidad entre interfaces. Claude Code utiliza la API Messages de Anthropic, Codex CLI se comunica mediante la interfaz de OpenAI y los modelos que una organización quiere servir pueden encontrarse detrás de vLLM, NVIDIA NIM u Ollama. Cuando esas piezas no hablan el mismo idioma, cambiar el agente completo deja de ser una alternativa práctica.

NVIDIA presentó Switchyard como una capa intermedia diseñada para resolver precisamente esa fragmentación. El proyecto combina un proxy y una biblioteca escritos en Rust, capaces de enrutar solicitudes entre proveedores, traducir formatos de entrada y salida, registrar métricas operativas y exponer algoritmos de selección tipados y componibles. MarkTechPost reportó el lanzamiento y describió la herramienta como una propuesta de infraestructura orientada principalmente a evaluación y experimentación.

El software se publica bajo la licencia Apache 2.0 y cuenta con documentación en el sitio de NVIDIA dedicado a NeMo Switchyard. Sin embargo, el proyecto está etiquetado como prealfa y experimental, además de advertir que no está destinado a entornos de producción y que tanto su interfaz como sus algoritmos podrían cambiar de manera significativa antes de la versión 1.0.

Una capa para separar al agente del modelo

Switchyard permite que el cliente conserve la interfaz que ya conoce mientras el proxy transforma la solicitud en estructuras neutrales al proveedor. Después de decodificarla, el sistema ejecuta un algoritmo de enrutamiento, selecciona un backend, vuelve a codificar la petición en el formato requerido y llama al modelo correspondiente. La respuesta recorre el camino inverso hasta regresar al agente con la estructura que este espera.

El servidor admite tres formatos de entrada: OpenAI Chat Completions, OpenAI Responses y Anthropic Messages. Cualquiera de esas interfaces puede dirigirse a cualquiera de las rutas configuradas, mientras cada cliente de modelo define su propio formato de salida. En la práctica, esto significa que la API utilizada por un agente ya no tiene que coincidir con la API nativa del modelo que atiende la solicitud.

La separación también puede ayudar a organizaciones que operan modelos en infraestructuras heterogéneas. Un equipo podría mantener un cliente compatible con OpenAI y redirigirlo hacia un servicio que exponga un formato distinto, sin reescribir la lógica principal del agente. La ventaja propuesta no consiste en crear un nuevo modelo, sino en reducir el trabajo de integración que aparece cuando cambian los proveedores o los servidores utilizados.

El alcance incluye las respuestas transmitidas por partes, un elemento importante para agentes que necesitan mostrar texto progresivamente o reaccionar a eventos durante una ejecución. Switchyard traduce también los eventos de streaming, de modo que la compatibilidad no se limita a solicitudes y respuestas completas. Aun así, el carácter experimental del proyecto obliga a probar con cuidado cada combinación de cliente, backend y formato antes de asumir estabilidad.

Tres caminos para ejecutar el proyecto

NVIDIA plantea una ruta de lanzamiento pensada para agentes de programación. El usuario puede instalar la herramienta mediante uv tool install --python 3.12 "nemo-switchyard[cli]" y después utilizar comandos como switchyard launch claude, switchyard launch codex o switchyard launch openclaw. Esos comandos pueden apuntar a un despliegue empaquetado o a un archivo TOML propio, según la configuración elegida.

La segunda alternativa consiste en ejecutar el servidor independiente como un proxy separado del agente. Para ello, la documentación indica la instalación con cargo install --locked switchyard-server, seguida de una validación de la configuración mediante la opción --dry-run. Una vez revisados los parámetros, el servicio puede atender en el host y el puerto que defina el operador.

La tercera vía utiliza switchyard-libsy para integrar los algoritmos de enrutamiento dentro de una aplicación escrita en Rust. Esta biblioteca no se apropia de una pila HTTP ni llama directamente a un modelo, sino que decide qué objetivo debe utilizarse y devuelve la información de la llamada al programa que la incorpora. Esa arquitectura ofrece mayor control a los desarrolladores que prefieren conservar la gestión de red dentro de su propia aplicación.

Las tres modalidades apuntan a necesidades diferentes, aunque comparten el mismo principio de desacoplamiento. El lanzador simplifica las pruebas con agentes conocidos, el servidor funciona como una pieza independiente de infraestructura y la biblioteca permite integrar la lógica de decisión en productos más personalizados. Ninguna de ellas elimina la necesidad de administrar credenciales, disponibilidad de proveedores o compatibilidad específica entre modelos.

Rutas simples y decisiones basadas en capacidad

En Switchyard, una ruta combina un identificador de modelo visible para el cliente con el algoritmo que determina qué backend atenderá cada solicitud. La opción passthrough representa el caso más sencillo: envía todas las peticiones hacia un único objetivo. Este modo puede servir para introducir la capa de traducción sin añadir una lógica adicional de selección.

La opción random distribuye el tráfico entre varios objetivos y permite asignar pesos relativos a cada uno. También admite una semilla opcional para reproducir la secuencia de decisiones, una característica útil en experimentos controlados, pruebas A/B y evaluaciones de costos. El sistema no presenta esta alternativa como una garantía de rendimiento, sino como un mecanismo predecible para repartir solicitudes.

El algoritmo llm_classifier agrega un objetivo clasificador que emite un veredicto sobre la capacidad necesaria para resolver una solicitud. A partir de ese resultado, Switchyard puede enviarla a un objetivo débil o fuerte, mientras parámetros como base_threshold, min_confidence, capability_elevated_floor y session_affinity ajustan el comportamiento. El umbral base es obligatorio y, cuando el juez no logra decidir, la solicitud termina en el objetivo fuerte.

La configuración también contempla el modo escalation, que ejecuta inicialmente cada turno en el nivel débil y permite que un juez determine si debe repetirse en el nivel fuerte. La estrategia puede reducir el uso de modelos más costosos en tareas sencillas, aunque incorpora el riesgo de pagar por una segunda ejecución cuando la primera no resulta suficiente. En este diseño, los términos fuerte y débil describen roles dentro de una ruta y no propiedades permanentes de un modelo.

El stage router y la observabilidad

El stage_router intenta elegir entre un objetivo capaz y otro eficiente utilizando señales derivadas de los resultados de herramientas y del progreso del agente en turnos recientes. Su propósito es evitar una llamada adicional a un clasificador en la mayoría de los turnos, al tomar la decisión a partir del contexto acumulado de la sesión. El mismo modelo puede desempeñar roles distintos en rutas diferentes, según las reglas definidas por el operador.

La observabilidad ocupa un lugar central en la propuesta. La ruta GET /metrics entrega texto compatible con Prometheus mediante el proveedor de OpenTelemetry del proceso completo del servidor, con familias que cubren solicitudes, errores, latencia de llamadas al modelo, duración total de los turnos y consumo de tokens. También registra datos de caché, creación de caché, razonamiento e intentos HTTP de salida clasificados por resultado y código.

Una etiqueta denominada tier distingue los niveles strong y weak en las decisiones del clasificador, mientras las llamadas realizadas por ese clasificador quedan fuera de las familias principales de métricas. La herramienta incluye además switchyard_routing_overhead_ms, que informa el tiempo de ejecución del algoritmo de enrutamiento después de descontar la llamada que atendió la solicitud. En las rutas con clasificador, el tiempo de clasificación permanece incluido en ese cálculo.

Los buckets de latencia comienzan en 0,1 milisegundos, lo que permite observar diferencias pequeñas en las rutas simples. Por separado, la opción --routing-log-file agrega un registro JSON por cada respuesta completada, y GET /v1/routing/session-stats devuelve totales de llamadas y tokens por sesión a partir de ese registro. La combinación ofrece a los equipos una forma de comparar el costo de la decisión con el tiempo consumido por el modelo.

Configuración, credenciales y límites actuales

Un despliegue basado en TOML se organiza en tres capas. llm_clients define la URL base, el formato de transmisión, la variable de entorno que contiene las credenciales y la política de reintentos; targets vincula un identificador de modelo de salida con un cliente; y routes expone al cliente un identificador visible junto con el algoritmo que administrará el tráfico.

El diseño evita guardar secretos directamente en el archivo de configuración. El parámetro api_key_env solo señala el nombre de la variable de entorno donde el operador debe colocar la credencial, una separación que reduce la posibilidad de incluir claves en repositorios o archivos compartidos. La protección real, no obstante, dependerá de cómo cada equipo gestione esas variables y el acceso al entorno de ejecución.

El valor predeterminado de max_retries es 2 y se aplica a fallos de transporte, tiempos de espera agotados, respuestas HTTP 408 y 429, además de errores 5xx. Ese comportamiento puede ayudar a enfrentar interrupciones transitorias, pero también debe evaluarse junto con los límites de cada proveedor y con el riesgo de repetir operaciones que consumen tokens. La configuración de reintentos, por tanto, forma parte de la estrategia operativa y no solo de la instalación.

La principal cautela sigue siendo la madurez del proyecto. Switchyard puede autohospedarse y sus componentes están disponibles mediante crates.io y PyPI, pero el proyecto debe tratarse como una herramienta de evaluación, no como una dependencia estable para cargas críticas. Antes de llevarlo a un entorno sensible, los equipos tendrían que comprobar compatibilidad de streaming, comportamiento de reintentos, métricas, afinidad de sesión y cambios de API en futuras versiones.

Con Switchyard, NVIDIA apunta a un problema concreto de la infraestructura de IA: permitir que los agentes sobrevivan a la diversidad de proveedores y formatos sin quedar atados a un único backend. La propuesta combina traducción, enrutamiento y observabilidad en una sola capa, pero su promesa de flexibilidad todavía está condicionada por el estado prealfa y experimental del proyecto.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín