Nvidia entra en el mercado del enrutamiento de modelos con NeMo Switchyard

Nvidia ha entrado en el mercado del enrutamiento de modelos con NeMo Switchyard, añadiendo una nueva capa de software a un sector ya saturado de gateways, proxies y sistemas de enrutamiento personalizados. El lanzamiento llegó a Google News junto con los últimos anuncios de modelos de Nvidia, pero la competencia va más allá de otro lanzamiento de producto. Nvidia quiere influir en qué modelo de IA gestiona cada solicitud, no solo suministrar el hardware que hay debajo.

Switchyard es un proxy de código abierto situado entre una aplicación y múltiples backends de modelos. Puede traducir formatos de API, clasificar solicitudes, mantener la afinidad de conversación, recopilar datos de uso y enviar distintas llamadas a distintos modelos. Un agente de programación podría reservar un modelo avanzado para la planificación o la recuperación de errores y utilizar después un modelo eficiente para ediciones rutinarias.

Este diseño desafía la práctica dominante de asignar un modelo a una aplicación completa o a una sesión de agente. También sitúa a Nvidia en competencia con gateways de modelos, plataformas cloud, routers de código abierto y los sistemas internos de orquestación que las empresas ya mantienen. La cuestión central es si Nvidia puede hacer que la selección automatizada de modelos sea lo bastante fiable para el trabajo en producción.

Nvidia se ha situado por encima del endpoint del modelo

Switchyard convierte la selección de modelos de una configuración de aplicación en una política operativa.

Según su documentación del proyecto, Switchyard acepta solicitudes en formatos de API de OpenAI y Anthropic. Después aplica una política de enrutamiento antes de reenviar cada solicitud a un backend configurado. El backend puede ser un proveedor alojado, un servicio Nvidia NIM, un endpoint privado, vLLM o un servidor local como Ollama.

Esta ubicación es importante. Por lo general, las aplicaciones nombran directamente un modelo, mientras que los desarrolladores gestionan las diferencias entre proveedores dentro de su código o mediante un proxy básico. Switchyard inserta un punto de decisión programable entre ambas capas. La aplicación sigue utilizando una API conocida, mientras el router decide adónde debe ir la solicitud.

El software incluye varios patrones de enrutamiento. Los equipos pueden distribuir el tráfico de forma aleatoria para realizar pruebas comparativas, utilizar un clasificador LLM, crear lógica de enrutamiento personalizada o aplicar una estrategia consciente de las etapas. También pueden omitir el enrutamiento y seleccionar un modelo cuando una ruta determinista importa más que la optimización.

El router por etapas de Switchyard es la parte más importante del lanzamiento. Evalúa señales de la actividad reciente de un agente y elige entre niveles de modelos capaces y eficientes. La guía de enrutamiento de Nvidia describe la exploración, el razonamiento difícil y la recuperación de errores como trabajo para modelos más potentes. La ejecución más mecánica puede pasar al nivel eficiente.

Esto no equivale a enrutar cada prompt de usuario por tema. Las cargas de trabajo de los agentes contienen muchas llamadas dentro de una misma tarea, y la dificultad cambia a medida que la tarea avanza. Un agente de programación podría necesitar un razonamiento más sólido al inspeccionar un repositorio desconocido. Una vez que formula un plan, las actualizaciones de archivos y las transformaciones estructuradas pueden requerir menos capacidad.

Por tanto, Switchyard toma decisiones de enrutamiento dentro de una sesión, no solo al inicio de esta. Puede mantener turnos relacionados en el mismo backend mediante afinidad de sesión, al tiempo que admite alternativas configuradas. Esa combinación aborda un problema práctico: los cambios sin restricciones pueden perjudicar la continuidad cuando los modelos interpretan el contexto de forma diferente.

El router también traduce entre protocolos de proveedores. Un cliente diseñado en torno a la API Messages de Anthropic puede acceder a un backend compatible con OpenAI sin reescribir la integración del cliente. Switchyard normaliza la solicitud, selecciona un destino, convierte la carga útil y devuelve una respuesta con la estructura que espera el cliente.

Esta traducción amplía el papel de Nvidia. La empresa ya no presenta únicamente un endpoint optimizado para modelos alojados por Nvidia. Ofrece software que puede situarse por encima de modelos de varios proveedores, incluidos modelos que compiten con la propia cartera de Nvidia.

La cobertura de Google News presentó el movimiento como la entrada de Nvidia en un mercado candente. El cambio más relevante es arquitectónico. Nvidia intenta que su software forme parte de la decisión que precede a cada llamada de inferencia, incluso cuando otra empresa suministra el modelo elegido.

Por qué el enrutamiento de modelos se convirtió en un campo de batalla de costes

Los flujos de trabajo con agentes hicieron cada vez más difícil justificar el enfoque de un modelo por sesión.

Un chatbot convencional suele generar una respuesta para una solicitud de usuario. Un agente puede inspeccionar archivos, llamar a herramientas, revisar un plan, recuperarse de errores, validar resultados y generar una respuesta final. Cada paso puede activar otra llamada al modelo, mientras el historial de conversación sigue creciendo.

Usar el modelo disponible más capaz en cada paso simplifica la ingeniería. También aplica el nivel más alto de razonamiento a tareas que pueden consistir en dar formato a JSON, resumir la salida de una herramienta o cambiar una cadena conocida. A escala, esas llamadas repetidas generan presión para ajustar la capacidad del modelo a la dificultad real de la tarea.

El enfoque opuesto crea otro problema. Los equipos pueden escribir reglas manuales que enruten prompts según el tipo de tarea, la longitud, el grupo de usuarios o el estado de la aplicación. Esas reglas se convierten en infraestructura que requiere pruebas, supervisión y ajustes cada vez que cambian los modelos o los flujos de trabajo.

Un análisis de InfoWorld sobre el enrutamiento de modelos describió esta capa emergente como una forma de variar el uso de modelos según los requisitos del prompt. La lógica subyacente es sencilla. No todas las solicitudes merecen el mismo modelo, pero alguien debe hacer la selección de manera fiable.

Switchyard intenta empaquetar esa decisión como infraestructura reutilizable. Su router por etapas examina señales relacionadas con herramientas en la conversación activa. Los equipos configuran dos destinos, establecen el comportamiento de enrutamiento y miden el tráfico resultante por nivel de modelo.

El sistema puede utilizar un clasificador para los turnos inciertos, pero la clasificación es opcional. La documentación de Nvidia recomienda empezar por las señales de herramientas porque llamar a otro modelo para clasificar cada solicitud introduce latencia, gasto y otro punto de fallo. Un clasificador puede limitarse a los casos en que el router no dispone de suficiente confianza.

Esta distinción importa para los despliegues empresariales. Un router que reduce el consumo de modelos pero añade otra llamada de modelo en cada turno puede perder parte de su ventaja. Un router que se basa únicamente en reglas fijas podría seguir siendo rápido, pero no detectar cambios en la dificultad de la tarea.

El mercado ya ha ido más allá de la simple distribución de prompts. Los gateways de IA suelen proporcionar límites de tasa, alternativas, registros, aplicación de políticas y abstracción de proveedores. Un debate de CIO sobre los gateways de IA cita el enrutamiento de modelos como una parte de una capa de control empresarial más amplia.

Eso significa que Nvidia no está creando una categoría vacía. Está entrando en una capa disputada en la que los clientes quizá ya utilicen gateways comerciales, controles nativos de la nube o proyectos de código abierto. Algunas organizaciones también han construido sistemas privados de enrutamiento en torno a sus datos de evaluación y reglas de negocio.

La oportunidad de Switchyard procede del creciente número de aplicaciones multimodelo. Las empresas combinan cada vez más un modelo general de razonamiento con modelos más pequeños, modelos privados y endpoints especializados. Una vez que existen varias opciones, la selección se convierte en una preocupación operativa y no en una preferencia del desarrollador.

Su desafío proviene de la misma diversidad. Cada organización define la calidad de forma distinta. Una ruta correcta para la atención al cliente puede ser incorrecta para la generación de código, el análisis de seguridad o la revisión de contratos. El coste y la latencia son medibles, pero la calidad a nivel de tarea suele requerir una evaluación específica del dominio.

La atención de Google News puede generar notoriedad, pero la adopción dependerá de esas mediciones. Los compradores querrán pruebas de que el enrutamiento produce resultados aceptables con sus propios prompts, herramientas, casos de fallo y límites de cumplimiento normativo.

Switchyard enfrenta el enrutamiento basado en políticas con la elección fija de modelos

La competencia principal no es Nvidia contra un único proveedor de gateways. Es el enrutamiento dinámico frente a la previsibilidad de un modelo fijo.

Una ruta de modelo fija tiene ventajas evidentes. Los equipos saben qué proveedor recibe sus datos, qué comportamiento deben evaluar, qué ventana de contexto se aplica y dónde investigar los fallos. Las actualizaciones de modelos siguen introduciendo variación, pero la ruta de la solicitud permanece comparativamente simple.

El enrutamiento dinámico intercambia parte de esa simplicidad por eficiencia. La aplicación puede llamar a distintos modelos durante el mismo flujo de trabajo. Un modelo capaz gestiona el razonamiento difícil, mientras un modelo eficiente procesa los turnos rutinarios. El sistema también puede conmutar por error cuando un destino deja de estar disponible o no puede aceptar el contexto actual.

La arquitectura de Switchyard separa la normalización de solicitudes, el enrutamiento, la ejecución y la traducción de respuestas. Esa separación permite a los desarrolladores sustituir la política de enrutamiento sin cambiar la integración orientada al cliente. También convierte la decisión de enrutamiento en un componente observable en vez de lógica de aplicación oculta.

El router por etapas va más allá al tratar la ejecución de un agente como una secuencia de condiciones cambiantes. Los resultados recientes de herramientas, los fallos y las señales de conversación influyen en qué nivel recibe la siguiente solicitud. Este enfoque reconoce que la dificultad existe a nivel de turno, no solo a nivel de aplicación.

Consideremos un agente de mantenimiento de software. Puede comenzar explorando un repositorio, localizando módulos relevantes e interpretando pruebas desconocidas. Estas acciones se benefician de un razonamiento más sólido. Tras identificar una corrección acotada, varias ediciones y pasos de validación pueden seguir un patrón claro.

Una configuración de modelo fijo envía ambas fases al mismo endpoint. Un router consciente de las etapas puede reservar su destino más potente para la exploración y la recuperación, y después trasladar el trabajo rutinario al destino eficiente. Si la validación falla, el router puede mover las llamadas posteriores de vuelta hacia el nivel capaz.

Este mecanismo ofrece más flexibilidad que asignar un modelo a la «programación» y otro a la «redacción». También crea más formas en que los errores de enrutamiento pueden afectar al resultado final. Un modelo débil seleccionado demasiado pronto podría malinterpretar una restricción, producir una edición defectuosa u ocultar un error tras una salida plausible.

Las consecuencias no siempre son visibles en el turno enrutado. Un pequeño error puede permanecer en el contexto e influir en llamadas posteriores. La respuesta final puede parecer coherente porque un modelo más potente reparó la presentación sin detectar el defecto subyacente.

Por eso el enrutamiento de modelos no puede juzgarse solo por el uso agregado de tokens o la latencia media. Los equipos necesitan evaluaciones a nivel de tarea que comprueben si todo el flujo de trabajo tuvo éxito. También necesitan trazas que conecten cada decisión de enrutamiento con las llamadas de herramientas resultantes, las salidas, los reintentos y el resultado final.

Switchyard expone estadísticas por solicitud sobre latencia, consumo de tokens y coste estimado. Su documentación sobre el router por etapas también describe estadísticas específicas por nivel. Estas mediciones ayudan a los operadores a entender con qué frecuencia se seleccionó cada modelo y dónde cambió el comportamiento de enrutamiento.

Sin embargo, la observabilidad no establece automáticamente la corrección. Un panel puede mostrar que un modelo eficiente gestionó la mayoría de las llamadas, pero no puede determinar si un resumen legal omitió una cláusula. Ese juicio requiere un conjunto de evaluación u otra prueba de aceptación fiable.

Por lo tanto, el enfoque de modelo fijo sigue siendo una alternativa significativa. Es más fácil de explicar, reproducir y auditar. El enrutamiento dinámico solo gana cuando el beneficio de eficiencia supera el coste operativo de evaluación, depuración y gobernanza.

La estrategia de Nvidia consiste en reducir ese coste operativo. Si Switchyard proporciona traducción de protocolos, patrones de enrutamiento comunes, estadísticas e iniciadores, los equipos pueden centrarse en la política y la evaluación. Si esos componentes siguen siendo difíciles de calibrar, las organizaciones podrían seguir utilizando modelos fijos para flujos de trabajo importantes.

La decisión del router puede convertirse en el eslabón más débil

El valor de Switchyard depende de seleccionar el modelo adecuado sin convertir el proceso de selección en otra costosa carga de trabajo de inferencia.

Ningún clasificador universal puede conocer la definición de tarea sencilla de cada organización. Una instrucción breve puede requerir conocimiento especializado, mientras que una larga puede solicitar una extracción mecánica. El historial de herramientas puede revelar el estado del flujo de trabajo, pero no puede garantizar que el siguiente turno sea simple.

Las señales conscientes de la etapa proporcionan contexto útil. La exploración, los fallos repetidos y los intentos de recuperación suelen justificar un modelo más potente. El uso estable de herramientas y la implementación repetitiva pueden indicar una fase rutinaria. Sin embargo, las ejecuciones reales de agentes no siempre siguen una progresión limpia del razonamiento a la ejecución.

Una edición de apariencia rutinaria puede tener consecuencias significativas. Cambiar una regla de autorización puede implicar solo unas pocas líneas, pero un error sutil puede exponer datos. Una solicitud larga de resumen puede ser de bajo riesgo cuando la salida recibe revisión humana.

Por ello, las organizaciones necesitan políticas de enrutamiento que tengan en cuenta el impacto, no solo la dificultad prevista. Las operaciones sensibles podrían utilizar siempre un modelo aprobado. Ciertas herramientas pueden requerir un nivel capaz, mientras que las transformaciones de bajo riesgo pueden seguir siendo elegibles para el enrutamiento eficiente.

La traducción entre proveedores presenta otra fuente de incertidumbre. Las API de OpenAI, Anthropic y compatibles no exponen semánticas idénticas. Las llamadas a herramientas, los campos de razonamiento, el comportamiento de streaming, las salidas estructuradas y las respuestas de error pueden diferir entre proveedores.

Switchyard busca preservar el formato de respuesta que espera el cliente mientras se comunica con otro backend. Esa abstracción es útil, pero los equipos deben probar las funciones específicas de las que dependen sus agentes. La compatibilidad de protocolos no implica equivalencia de comportamiento entre modelos.

Los límites de contexto también complican el enrutamiento. Un modelo seleccionado por eficiencia puede no aceptar la sesión acumulada. Según la documentación de stage-router, Switchyard admite un comportamiento de respaldo configurado para el desbordamiento de contexto. Los respaldos preservan la disponibilidad, pero pueden cambiar el coste, la latencia y las características de salida.

Luego está el propio clasificador. Un clasificador LLM opcional puede ayudar con solicitudes inciertas, pero añade otra llamada de red. Nvidia advierte que compartir la capacidad del proveedor entre el clasificador y un destino eficiente puede contribuir a la presión sobre los límites de tasa.

El clasificador también necesita evaluación. Si envía con frecuencia solicitudes sencillas al nivel capaz, los ahorros se reducen. Si envía trabajo difícil al nivel eficiente, la calidad disminuye. Un umbral cambia el equilibrio, pero ningún umbral elimina la disyuntiva.

La investigación sobre enrutamiento se ha centrado repetidamente en preservar la calidad mientras reduce el gasto de inferencia. El proyecto RouteLLM demostró que los routers aprendidos pueden seleccionar entre modelos más potentes y más débiles usando datos de preferencias. Sus resultados también subrayan un punto más amplio: el rendimiento del router depende de los datos de entrenamiento, el diseño de la evaluación y el par de modelos que se enruta.

Una política calibrada para un par no se transferirá automáticamente a otro. Los proveedores actualizan modelos, las instrucciones evolucionan y las aplicaciones incorporan nuevas herramientas. Los equipos necesitan una evaluación recurrente, no una única prueba de referencia completada antes del despliegue.

El lanzamiento también es reciente. Su repositorio público enumera problemas conocidos, desarrollo activo y un conjunto creciente de componentes de enrutamiento. Esa apertura favorece la inspección y la experimentación, pero no establece que todas las funciones estén maduras para cargas de trabajo reguladas o de alto riesgo.

Nvidia ha posicionado Switchyard como infraestructura independiente del modelo, aunque su incentivo más amplio sigue siendo claro. Una inferencia más eficiente puede hacer económicamente viables los despliegues de agentes, aumentando la demanda de los sistemas de cómputo que los sustentan. El router puede admitir proveedores competidores y, al mismo tiempo, ampliar el volumen total de trabajo de IA.

Ese incentivo no invalida el producto. Explica por qué Nvidia está avanzando hacia el software situado por encima del punto final de inferencia. La empresa se beneficia cuando los clientes ejecutan más modelos, más agentes y más inferencia en una gama más amplia de hardware.

Por lo tanto, la interpretación prudente es más limitada que el ciclo de titulares de Google News. Switchyard proporciona un conjunto de herramientas creíble para experimentar con tráfico multimodelo. Su valor en producción sigue dependiendo de evidencia específica de cada carga de trabajo que demuestre que los errores de enrutamiento se mantienen dentro de límites aceptables.

Nvidia está ampliando su estrategia de inferencia full-stack

Switchyard conecta la elección de modelo con el esfuerzo más amplio de Nvidia por controlar una mayor parte de la pila operativa de inferencia.

La posición de Nvidia en IA comenzó con aceleradores y se expandió mediante redes, bibliotecas optimizadas, software de servicio de modelos, paquetes empresariales y modelos abiertos. Una capa de enrutamiento amplía esa pila hacia el límite de la aplicación.

La empresa ya ofrece Nvidia NIM para empaquetar y servir modelos a través de puntos finales estandarizados. Dynamo aborda la programación de inferencia distribuida y la asignación de solicitudes entre trabajadores. NeMo admite el desarrollo y la personalización de modelos. OpenShell proporciona un entorno de ejecución controlado para cargas de trabajo de agentes.

Estos sistemas resuelven problemas de enrutamiento diferentes. El enrutamiento consciente de KV de Dynamo selecciona un trabajador adecuado teniendo en cuenta el estado reutilizable de la caché y la carga activa. Switchyard selecciona un modelo o backend de acuerdo con una política de nivel de aplicación.

Esa distinción es importante. El enrutamiento de infraestructura pregunta dónde debe ejecutarse una solicitud para un servicio eficiente. El enrutamiento de modelos pregunta qué modelo debe recibir la solicitud. Un despliegue puede usar ambas decisiones: Switchyard selecciona el modelo y, después, un sistema de servicio elige el trabajador.

El resultado es una cadena más larga de componentes gestionados por Nvidia. Una empresa podría construir un agente con herramientas de NeMo, enrutar sus llamadas mediante Switchyard, servir un modelo abierto a través de NIM y programar la inferencia con Dynamo sobre hardware de Nvidia.

Nvidia no necesita que cada solicitud use un modelo Nemotron para que esta estrategia importe. Si Switchyard se convierte en un punto de control común, Nvidia gana influencia sobre cómo los desarrolladores evalúan y operan sistemas multimodelo. También puede conectar esas decisiones de enrutamiento con su pila de servicio y observabilidad.

Esta es la verdadera presión competitiva creada por el lanzamiento. Los proveedores de gateways se enfrentan ahora a un competidor de código abierto bien financiado procedente del principal proveedor de hardware de IA. Los proveedores de nube deben demostrar por qué sus capas nativas de enrutamiento y gobernanza ofrecen más valor. Las empresas de modelos deben facilitar la evaluación de sus puntos finales dentro de despliegues mixtos.

Los proyectos de código abierto afrontan una comparación distinta. Muchos ya proporcionan API unificadas, lógica de respaldo, equilibrio de carga y selección de modelos. Switchyard debe competir en calidad de enrutamiento, conciencia de agentes, cobertura de protocolos y claridad operativa, en lugar de por la capacidad básica de reenviar una solicitud.

Su licencia Apache 2.0 reduce la barrera para la experimentación. Los equipos pueden inspeccionar el código de enrutamiento, añadir políticas personalizadas y desplegar el proxy cerca de sus aplicaciones. Esa flexibilidad puede atraer a organizaciones que no quieren que un gateway alojado observe cada instrucción.

Sin embargo, el autoalojamiento transfiere la responsabilidad. Los operadores deben proteger las credenciales, gestionar las actualizaciones, conservar los registros, supervisar el comportamiento de enrutamiento y validar las integraciones con proveedores. El código abierto cambia quién controla el sistema, no el trabajo necesario para operarlo de forma segura.

La mayor ventaja de Nvidia puede ser la integración, más que un único algoritmo de enrutamiento. La empresa puede conectar Switchyard con modelos, servidores de inferencia, entornos de ejecución de agentes y telemetría de hardware. Un proveedor de routers más pequeño puede ofrecer una neutralidad más amplia entre proveedores, pero carecer de ese alcance de ingeniería de extremo a extremo.

El peligro para los clientes es una concentración innecesaria de la pila. Utilizar un único proveedor para desarrollo, enrutamiento, servicio y cómputo puede simplificar el soporte. También puede aumentar los costes de cambio, incluso cuando los componentes individuales siguen siendo de código abierto.

El soporte de Switchyard para varios proveedores ayuda a contrarrestar esa preocupación. Su utilidad dependerá de si esas integraciones siguen siendo de primera clase a medida que Nvidia amplía el proyecto. Los clientes deberían probar los backends que no son de Nvidia con el mismo cuidado que los alojados por Nvidia.

El movimiento de la empresa no resuelve el mercado de routers de modelos. Confirma que el enrutamiento se ha convertido en infraestructura estratégica. La decisión sobre qué modelo responde a una solicitud ahora afecta al coste, la latencia, la fiabilidad, el manejo de datos y la influencia de los proveedores.

Lo que los lectores de Google News deberían vigilar a continuación

Tres señales mostrarán si Switchyard se convierte en infraestructura de producción o sigue siendo un interesante experimento para desarrolladores.

La primera señal es la evaluación a nivel de carga de trabajo. Nvidia y los primeros adoptantes necesitan publicar resultados que conecten las decisiones de enrutamiento con los resultados completos de las tareas. Un menor consumo de tokens solo importa cuando el agente sigue completando correctamente su asignación.

La evidencia útil incluiría tasas de fallo, comportamiento de recuperación, distribuciones de latencia y comparaciones de calidad entre varios pares de modelos. Los resultados también deberían separar la sobrecarga del router de los ahorros creados al trasladar llamadas a un modelo eficiente.

Si pruebas independientes reproducen resultados sólidos a nivel de tarea, el caso de Nvidia se fortalece. Si los resultados dependen de benchmarks estrechos o pares de modelos cuidadosamente seleccionados, los despliegues de modelo fijo seguirán siendo atractivos para flujos de trabajo importantes.

La segunda señal es la integración más allá de los propios servicios de Nvidia. Switchyard ya describe soporte para puntos finales de OpenAI, Anthropic y compatibles con OpenAI. Los usuarios de producción pondrán a prueba si las llamadas a herramientas, el streaming, las respuestas estructuradas, el manejo de contexto y los errores siguen siendo fiables entre esos proveedores.

Las integraciones amplias y bien mantenidas respaldarían la afirmación de Nvidia de ser independiente del modelo. Un comportamiento desigual en backends competidores la debilitaría y haría más atractivos los gateways neutrales.

La tercera señal es el control empresarial. Los compradores buscarán aplicación madura de políticas, registros de auditoría, aislamiento de credenciales, orientación para despliegues y flujos de trabajo de evaluación. También necesitarán una forma clara de fijar las solicitudes sensibles a modelos aprobados.

Unas sólidas funciones de gobernanza trasladarían el enrutamiento de la optimización para desarrolladores a la ingeniería de plataformas. Controles débiles limitarían la adopción a experimentos, herramientas internas y agentes de menor riesgo.

Estas señales importan más que las cifras de descargas o los titulares. Google News puede amplificar la entrada de Nvidia, pero no puede establecer si una decisión de enrutamiento fue correcta. Esa prueba llegará de ejecuciones reales de agentes bajo modelos, herramientas y restricciones empresariales cambiantes.

Para los desarrolladores, la acción inmediata es práctica: elijan un flujo de trabajo acotado, definan el éxito antes de enrutarlo y comparen Switchyard con una referencia de modelo fijo. Realicen un seguimiento de los resultados completos de las tareas junto con la latencia y el uso de modelos.

Para los compradores empresariales, pregunten quién es responsable de la política de enrutamiento y con qué rapidez la organización puede detectar una mala decisión. Una llamada más barata no es más barata cuando genera retrabajo, debilita el cumplimiento o oculta un error.

Nvidia ha hecho más difícil descartar el enrutamiento de modelos como una abstracción de nicho. Los próximos meses mostrarán si Switchyard puede convertir la elección dinámica de modelos en una práctica operativa tan habitual como el equilibrio de carga, o si el propio enrutador sigue siendo el modelo más difícil de confiar.