Esta ejecución dispersa puede reducir el cómputo necesario por token. No elimina la necesidad de almacenar o gestionar el modelo completo, pero sí puede mejorar su perfil de inferencia frente a una red densa de tamaño comparable.
Un agente autónomo suele hacer muchas más llamadas al modelo de las que sugiere la tarea inicial. Después de crear un plan, puede tener que seleccionar herramientas, consultar fuentes, extraer información, verificar resultados, aplicar reglas y reformatear la respuesta.
Usar un modelo de frontera para cada una de esas operaciones puede elevar la latencia y el coste operativo. Lightning pretende asumir la parte predecible y frecuente del flujo, mientras un modelo más capaz queda reservado para las decisiones ambiguas, las excepciones y el razonamiento complejo.
Una configuración de dos niveles podría funcionar así:
NVIDIA sitúa a Nemotron 3 Ultra —un modelo MoE de 550.000 millones de parámetros totales y 55.000 millones activos— en el terreno del razonamiento avanzado y la orquestación. El contraste ayuda a entender el papel de Lightning.
Para que esta división de trabajo sea viable, el sistema necesita decidir qué modelo recibe cada paso. No tendría mucho sentido enviar todas las solicitudes al mismo modelo si algunas son sencillas y otras exigen capacidades mucho mayores.
NeMo Switchyard es el SDK de enrutamiento independiente del proveedor que NVIDIA propone para representar solicitudes, definir modelos disponibles y gestionar las llamadas al proveedor o al identificador de modelo seleccionado.
En la práctica, permite construir una jerarquía de modelos: Lightning atiende las llamadas rutinarias y el modelo grande recibe los casos difíciles. Por eso, el valor principal de Lightning no está necesariamente en usarlo como chatbot aislado, sino en integrarlo dentro de un sistema de agentes con varios modelos y un mecanismo de enrutamiento.
NVIDIA anuncia una capacidad de contexto de hasta 1 millón de tokens. Esa cifra puede ser relevante para agentes que mantienen conversaciones prolongadas, procesan documentos extensos o conservan grandes cantidades de estado entre pasos. El contexto realmente utilizable y el rendimiento dependerán de la configuración y del sistema de inferencia empleado.
El checkpoint NVFP4 está orientado al despliegue de inferencia y utiliza kernels especializados de NVIDIA en generaciones de GPU compatibles. NVIDIA menciona posibilidades de ejecución en infraestructura local, estaciones de trabajo, centros de datos y nubes públicas; el modelo también está disponible a través de Hugging Face y servicios alojados.
AWS indica que Nemotron 3.5 Lightning puede utilizarse mediante SageMaker JumpStart, con despliegue desde la consola de SageMaker o mediante el SDK de Python. La documentación de NVIDIA ofrece además una vía independiente basada en contenedores NIM, con requisitos concretos de sistema operativo, CUDA, controladores y Docker.
Conviene, eso sí, no convertir la etiqueta “single-GPU” en una promesa válida para cualquier ordenador. La viabilidad depende de la GPU, la memoria disponible, la longitud del contexto, la precisión, el tipo de cuantización, el tamaño de lote y el software de servicio. Las afirmaciones sobre compatibilidad amplia con equipos GeForce RTX deben comprobarse en la tarjeta del modelo y en la receta de despliegue correspondiente.
NVIDIA y AWS hablan de hasta cuatro veces más rendimiento y hasta un 30 % menos de tiempo para completar tareas en cargas de trabajo específicas de agentes. Son cifras anunciadas por el fabricante y la plataforma, no una medida universal de inteligencia ni una garantía de rendimiento en producción.
Los resultados reales pueden variar según:
Por eso, una evaluación útil debería medir el flujo completo: precisión de la extracción, fiabilidad de las llamadas a herramientas, cumplimiento del formato solicitado, número de reintentos y tiempo total de finalización. Los tokens por segundo, por sí solos, cuentan solo una parte de la historia.
El acceso mediante API puede hacer atractivo a Lightning para inferencias de gran volumen. DeepInfra lo anunciaba a 0,05 dólares por cada millón de tokens de entrada y 0,20 dólares por cada millón de tokens de salida, con facturación por uso y sin necesidad de gestionar una GPU propia.
Ese precio no es una característica fija del modelo. Las tarifas cambian según el proveedor, la ruta, la precisión, el almacenamiento en caché y las condiciones del servicio; otros proveedores han publicado precios diferentes.
La comparación correcta debe incluir el coste de todo el flujo: reintentos, llamadas a herramientas, enrutamiento y solicitudes que todavía deban enviarse a un modelo más potente. Un modelo barato por token puede dejar de serlo si necesita más correcciones o produce resultados menos fiables para una tarea concreta.
Nemotron 3.5 Lightning es, sobre todo, un modelo trabajador rápido y personalizable para sistemas de agentes. Tiene sentido cuando una aplicación genera muchas llamadas similares y cuando la tarea puede especializarse, restringirse o ajustarse mediante postentrenamiento.
No se presenta como un reemplazo universal de un modelo de orquestación grande. La planificación compleja, el juicio ante situaciones inciertas y las tareas en las que un error resulta costoso pueden seguir requiriendo Nemotron 3 Ultra u otro sistema de frontera.
La conclusión práctica es sencilla: Lightning encaja mejor como la capa de ejecución de baja latencia dentro de una arquitectura de agentes con varios modelos. Sus 30.000 millones de parámetros totales, unos 3.000 millones activos, materiales abiertos, opción de inferencia NVFP4 y distintas vías de despliegue buscan que el trabajo rutinario sea más rápido y económico. Las mejoras anunciadas son prometedoras, pero deben validarse con el flujo de trabajo concreto antes de considerarlas resultados de producción.