NVIDIA Nemotron 3.5 Super VL: 120 mil millones de parámetros, 12 mil millones activos, despliegue en AWS

NVIDIA ha lanzado el modelo multimodal Nemotron 3.5 Super VL, y el equipo de AWS ha explicado cómo ejecutarlo en clústeres propios de Kubernetes. El modelo tiene 120 mil millones de parámetros, pero por cada token (fragmento de palabra) trabajan solo 12 mil millones.

Es un esquema mixture-of-experts: dentro de la red hay grupos de «expertos» y, para cada token, un enrutador especial elige solo a unos pocos. El cómputo resultante es similar al de un modelo pequeño, pero la memoria de la GPU sigue teniendo que alojar los 120 mil millones de pesos. El modelo entiende texto, imágenes, documentos y vídeo, y genera texto.

Es abierto: NVIDIA publica los pesos, los datasets de entrenamiento y las recetas de ajuste fino. Se obtuvo por destilación a partir de Nemotron 3 Ultra, un modelo más grande; es decir, se entrenó para imitar el comportamiento de ese «maestro».

En AWS ya están disponibles, dentro de la línea Nemotron, Nemotron 3 Nano, Nano Omni, Super, Ultra y Nemotron 3.5 Lightning. Super VL se suma a esa lista.

Arquitectura híbrida y resultados declarados

En su interior se alternan tres tipos de capas: Mamba-2, atención convencional (attention) y capas de expertos. De la visión se encarga el codificador RADIO. La ventaja de Mamba-2 es que, al generar, almacena un estado de tamaño fijo. En la atención convencional, en cambio, la memoria del KV-cache (que guarda el contexto ya leído) crece con la longitud del texto. Por eso un contexto de hasta 1 millón de tokens resulta bastante más barato que en un transformer puro. Además, el modelo incorpora una cabeza de Multi-Token Prediction, que permite la decodificación especulativa: el modelo propone varios tokens por adelantado y después los verifica.

NVIDIA presenta estos resultados (son datos de la propia compañía; el material no incluye mediciones independientes):

• 63,44% en Hermes Bench, una prueba de tareas agénticas;
• 87,05% en las evaluaciones de agentes de LangChain, es decir, en comprobaciones de funcionamiento dentro de un framework popular para agentes;
• 80,8% en CharXiv, un conjunto de preguntas sobre gráficos de artículos científicos.

Los escenarios de uso declarados son: revisión y depuración de código, contraste de fuentes tras una búsqueda web, lectura de tablas y esquemas en documentos, análisis de vulnerabilidades y amenazas en ciberseguridad, y búsqueda y análisis de incidentes en vídeo.

Cuántas GPU hacen falta y cómo se organiza el clúster

Las configuraciones mínimas para vLLM (servidor de inferencia) son estas:

• B200/GB200: 8 GPU en BF16, 2 GPU en NVFP4;
• B300/GB300: 4 GPU en BF16, 1 GPU en NVFP4;
• H200: 8 GPU en BF16, 4 GPU en NVFP4;
• H100: 16 GPU en BF16, 8 GPU en NVFP4.

NVFP4 es un formato numérico de 4 bits. Comprime los pesos aproximadamente cuatro veces respecto a BF16, por lo que necesita entre dos y cuatro veces menos tarjetas. En H100, para BF16 habrá que usar dos nodos de 8 GPU cada uno.

La arquitectura de referencia de AWS es la siguiente. El plano de control de Kubernetes (control plane) se encarga de la API. Los nodos de CPU alojan los pods de servicio y de prueba, y los nodos de GPU ejecutan el modelo.

Las imágenes de contenedor están en Amazon ECR, los pesos se almacenan en un volumen compartido de Amazon FSx for Lustre y los nodos de GPU se conectan mediante la red Elastic Fabric Adapter (EFA). Los manifiestos de Kubernetes son idénticos para tres variantes de orquestación: EKS estándar, EKS Auto Mode (en el que AWS gestiona por sí misma el escalado, los drivers de GPU y EFA) y SageMaker HyperPod EKS. El esquema se probó en instancias p6-b200.

48xlarge (8 GPU B200) y p5en.48xlarge (8 GPU H200). La guía paso a paso está en el proyecto aws-do-eks.

Cómo planificar la capacidad con curvas de latencia

El modelo se sirve con NVIDIA Dynamo, que puede funcionar en dos modos: completo en un solo nodo o desagregado, con prefill (lectura del prompt) y decode (generación de la respuesta) en nodos distintos. En los modelos con visión, la codificación de imágenes y vídeo también puede trasladarse a un nodo aparte.

Primero se valida el clúster con un microbenchmark NCCL all-reduce. Si durante la prueba están cargadas todas las GPU y hay tráfico por todos los adaptadores EFA, la red está bien configurada. Después, la herramienta aiperf mide:

• TTFT, el tiempo hasta el primer token;
• ITL, la pausa entre tokens;
• TPS, el rendimiento total en tokens por segundo.

Las mediciones se repiten con distinto número de peticiones simultáneas (concurrency sweep). AWS muestra un ejemplo de planificación. Se fijan los límites: TTFT de hasta 600 ms e ITL de hasta 100 ms por token. Se busca el punto más a la derecha del gráfico que cumpla ambos límites. En el ejemplo son 32 peticiones simultáneas y unos 320 tokens por segundo por réplica, es decir, por pareja prefill-decode. Lo demás es aritmética: se divide el rendimiento objetivo entre esos 320 y se obtiene el número de parejas.

Con dos nodos, el modo desagregado dio un TTFT menor que el combinado, mientras que el ITL se mantuvo casi igual. Si el ITL aumenta, hay que añadir capacidad de decode; si aumenta el TTFT, de prefill.

Conclusión práctica para los ingenieros: para el modelo cuantizado basta con una sola B300, y conviene elegir entre los modos según las mediciones propias, repitiendo la prueba tras cambiar la precisión, el esquema de paralelismo o la versión de Dynamo y vLLM. Las cifras de calidad, por ahora, las declara la propia NVIDIA, y el material forma parte de la documentación de partners de AWS. Conviene comparar el modelo con sus competidores en sus propias tareas.