TL;DR:
- Nvidia publicó Nemotron 3.5 Lightning, un modelo de pesos abiertos con 30,000 millones de parámetros totales y 3,000 millones activos por token.
- La compañía promete hasta cuatro veces más velocidad de salida y 30% menos tiempo por tarea de agente, aunque su propia tabla deja a modelos rivales por delante en varias pruebas.
- NeMo Switchyard puede repartir solicitudes entre modelos abiertos y propietarios, pero su repositorio oficial lo clasifica como software pre-alpha y no apto para producción.
Nvidia lanzó el 11 de agosto de 2026 Nemotron 3.5 Lightning, un modelo de pesos abiertos de 30,000 millones de parámetros que activa 3,000 millones por token, y NeMo Switchyard, una biblioteca de código abierto para repartir las tareas de un agente entre distintas IA. La propuesta apunta a sistemas que trabajan durante horas y no necesitan usar un modelo de frontera en cada paso: Lightning ejecutaría el volumen de trabajo especializado y Switchyard decidiría cuándo conviene recurrir a otra opción. Nvidia promete hasta cuatro veces más velocidad de salida y una reducción de 30% en el tiempo necesario para completar tareas de agente frente a modelos de su clase. El límite inmediato está en Switchyard: su repositorio lo clasifica como software pre-alpha, experimental y todavía no apto para producción.
Nemotron 3.5 activa solo una décima parte de sus parámetros
Nemotron 3.5 Lightning combina capas Mamba-2, una mezcla de expertos (MoE) y capas de atención. En lugar de activar toda la red para producir cada token, selecciona unos 3,000 millones de parámetros de un total de 30,000 millones. Esa arquitectura reduce el cómputo por paso sin renunciar a una reserva mayor de conocimiento distribuida entre sus expertos.
El modelo también incorpora predicción de múltiples tokens y admite dos sistemas auxiliares de decodificación especulativa, DFlash y DSpark. En términos simples, estas técnicas preparan varios tokens candidatos para que el modelo principal los verifique en bloque, en vez de generar la respuesta estrictamente de uno en uno.
La ficha oficial describe un modelo de entrada y salida de texto, con razonamiento activable o desactivable y una ventana máxima de un millón de tokens. Ese máximo depende del despliegue: el ejemplo para una sola H100 utiliza 256,000 tokens, mientras que la configuración completa de un millón aparece para ocho H100 o una GB200. Nvidia también incluye español entre los seis idiomas admitidos, aunque la tabla principal de evaluación no ofrece una medición general dedicada al rendimiento en español.
Las versiones BF16 y NVFP4 están disponibles desde el lanzamiento. Los pesos BF16 pueden ejecutarse en una H100 o A100 de 80 GB, mientras que Nvidia recomienda NVFP4 para inferencia optimizada. La licencia OpenMDW 1.1 permite uso comercial, según la ficha del modelo.
Más velocidad no significa cuatro veces menos espera
La cifra principal de Nvidia necesita contexto. La empresa afirma que Nemotron 3.5 Lightning alcanza hasta cuatro veces más velocidad de salida, pero traduce esa mejora en tareas completas de agente a un ahorro de tiempo de 30%. Una tarea de este tipo también incluye planificación, llamadas a herramientas, lectura de resultados y coordinación con otros modelos. La diferencia entre ambos porcentajes apunta a que generar tokens es solo una parte del cuello de botella.
La propia tabla de Nvidia muestra el intercambio entre capacidad y velocidad. En SWE-bench Verified, Lightning obtiene 51.56 puntos frente a 70.12 de Qwen 3.6 35B A3B; en Terminal-Bench 2.1 registra 24.58 frente a 44.38. En PinchBench queda mucho más cerca, con 85.37 puntos frente a 88.07 de Qwen, y supera los 74.70 de Gemma 4 26B A4B. Todos esos resultados fueron medidos por Nvidia con su propio entorno de evaluación y pueden diferir de las cifras publicadas por otros proveedores.
El lanzamiento llega un día después de que Meta liberara Muse Glimmer, otro modelo de 30,000 millones de parámetros pensado para agentes que pueden correr en una computadora personal. Nvidia añade una segunda pieza a esa carrera: un sistema que decide qué modelo debe atender cada paso.
Alejandro Castillo Leone
Switchyard decide cuándo usar un modelo barato o uno más capaz
Switchyard se coloca entre la aplicación y los modelos. Recibe solicitudes en los formatos de OpenAI Chat Completions, OpenAI Responses o Anthropic Messages, elige un destino y devuelve la respuesta en el formato que espera la aplicación. Puede enviar el trabajo a vLLM, Nvidia NIM, Ollama o cualquier endpoint compatible con OpenAI sin obligar a reescribir el agente.
El proyecto ofrece varias estrategias. Un modelo clasificador puede decidir si una solicitud necesita el nivel débil o el fuerte; un router por etapas puede reaccionar a resultados de herramientas y errores; otro modo prueba primero la opción barata y escala si un juez considera insuficiente la respuesta. También permite dividir tráfico al azar para pruebas A/B y registra latencia, tokens, errores y sobrecarga mediante Prometheus.
Nvidia sostiene que, en una prueba interna, Switchyard redujo el costo de completar tareas a casi un tercio del gasto de usar únicamente Opus 4.8, manteniendo una precisión comparable a la frontera. Los resultados de socios muestran que el ahorro puede exigir concesiones: LangChain reportó 74% menos costo en 145 tareas de varias interacciones al enviar apenas 7% de las llamadas a un modelo de frontera, pero aceptó una caída de 6% en precisión.
Ese potencial no elimina el estado actual del software. El README de GitHub advierte que Switchyard evoluciona con rapidez, que su API y sus algoritmos pueden cambiar antes de la versión 1.0 y que todavía no debe desplegarse en producción. Su licencia sí es Apache 2.0 y el repositorio ya incluye rutas para probarlo con Claude Code, Codex CLI y OpenClaw.
El modelo ya está disponible; el router sigue siendo una prueba
Nemotron 3.5 Lightning puede descargarse en Hugging Face y ModelScope, usarse mediante OpenRouter o ejecutarse como un microservicio Nvidia NIM en build.nvidia.com. Switchyard está disponible en GitHub y Nvidia dice que llegará más adelante a plataformas asociadas.
La apuesta divide el trabajo de un agente en dos capas: un modelo con pocos parámetros activos para resolver muchas tareas con rapidez y un router para reservar los modelos más costosos a los pasos difíciles. La primera pieza ya tiene pesos, licencia y rutas de despliegue; la segunda todavía es una herramienta experimental que necesita madurar antes de sostener operaciones reales.
