Clústeres de DGX Spark: 2, 3 y 4 nodos sin confundir memoria y servicio

Qué significa conectar dos DGX Spark para un modelo de hasta 405B

Dos unidades pueden conectarse mediante la interfaz ConnectX con un cable QSFP compatible para ejecutar cargas distribuidas admitidas por el software. Esto no crea un único espacio de memoria compartida transparente para cualquier aplicación. El framework divide o coordina el trabajo y ambas unidades deben utilizar una configuración compatible.

DGX Spark A ⇄ enlace ConnectX / QSFP ⇄ DGX Spark B
       ↘ red de gestión y usuarios ↙
           almacenamiento / servicio

1. Iguala versiones. Sistema, controladores, contenedores, programa que ejecuta el modelo y modelo deben estar alineados.
2. Instala el enlace dedicado. Utiliza el puerto y cable compatibles; no lo sustituyas por una red convencional y esperes el mismo comportamiento.
3. Configura direccionamiento y prueba conectividad. Verifica enlace, MTU cuando corresponda, latencia y ancho de banda antes del modelo.
4. Distribuye el artefacto. Ambos nodos necesitan acceso coherente a pesos y configuración.
5. Utiliza un motor que soporte el patrón. La división del modelo depende del framework y de la receta concreta.
6. Mide memoria y comunicación. El enlace puede convertirse en parte de la latencia.
7. Prueba recuperación. Define qué ocurre si un nodo se reinicia o pierde el enlace.

El límite citado por NVIDIA es una capacidad de plataforma, no una garantía universal. Formato, cuantización, caché, contexto y motor determinan si una variante concreta funciona y con qué velocidad.

Elige entre repartir el modelo o repartir las peticiones

Para una pyme, réplicas y tareas separadas suelen ser más fáciles de mantener. Utiliza paralelismo de modelo únicamente cuando la capacidad de una unidad sea el límite y exista una receta probada para el motor elegido.

Separar tráfico de modelo, gestión, datos y usuarios

La topología ConnectX atiende la comunicación distribuida. Dibuja además la red de gestión y servicio: consultas de usuarios, acceso a documentos, métricas, copias y administración. No mezcles todos los flujos sin saber qué ancho de banda y permisos necesita cada uno.

• Diagrama con interfaces, subredes y reglas
• DNS o inventario estable de nodos
• Sin puertos de inferencia expuestos a Internet
• Pruebas de latencia y rendimiento sostenido
• Rutas de copia y actualización separadas
• Capacidad de aislar un nodo sin detener toda la flota

Encolar, enrutar y limitar trabajos según el modelo que está residente

Un balanceador genérico puede distribuir HTTP, pero no conoce memoria, modelo, contexto ni tiempo de carga. Añade una capa que anuncie capacidad y salud. Evita descargar y cargar modelos en cada petición; agrupa trabajos o dedica nodos a modelos estables.

Cliente → autenticación → router de modelos → cola
                                      ↘ réplica A
                                      ↘ réplica B
                                      ↘ lote / trabajo largo

1. Identifica el modelo solicitado. Solo rutas aprobadas y variantes existentes.
2. Calcula prioridad y límites. Usuario, tamaño de contexto, tipo de carga y cuota.
3. Selecciona una réplica saludable. Considera cola, memoria, versión y modelo residente.
4. Asigna un identificador. Permite cancelación, seguimiento e evitar acciones duplicadas.
5. Establece tiempo máximo. Un trabajo bloqueado no ocupa el nodo indefinidamente.
6. Devuelve errores claros. Cola llena, modelo no disponible, contexto excesivo o servicio temporalmente no preparado.

Para lotes, utiliza una cola persistente y trabajadores. Para chat, conserva streaming y límites de sesión. Mezclar vídeo largo con conversación interactiva en la misma cola produce una experiencia impredecible.

Calcular nodos por demanda y nivel de servicio

Empieza por mediciones de una unidad o pareja: tiempo de carga, prefill, generación y memoria. Después utiliza el volumen y la concurrencia. Una media diaria baja puede ocultar un pico que satura el servicio.

trabajos por hora por réplica ≈ 3600 / tiempo medio del trabajo
capacidad útil = capacidad medida × factor de margen
réplicas necesarias = demanda pico / capacidad útil

Reserva capacidad para mantenimiento y fallos. Si la carga necesita todas las unidades para cumplir en condiciones normales, no existe tolerancia a una actualización o avería.

Versionar, monitorizar y recuperar una flota homogénea

• Imagen base, controladores y contenedores registrados
• Repositorio único de modelos con hashes
• Inventario de nodo, función, red y versión
• Actualización por grupos, no de toda la flota a la vez
• Pruebas de carga y calidad antes de promover
• Métricas de memoria, temperatura, cola, prefill y generación
• Alertas de diferencia de versión o artefacto
• Copias de configuración, índices y secretos cifrados
• Procedimiento para retirar un nodo comprometido
• Simulación de fallo de red, almacenamiento y modelo

La seguridad debe cubrir los nodos y la capa de acceso. Usa identidades de servicio, credenciales por función y segmentación. Un modelo no necesita permisos para administrar la infraestructura.

Datos necesarios para configurar dos unidades o una flota

Qué trabajo puede repartirse entre una flota sin fingir un único modelo gigante

Estas cargas escalan horizontalmente porque cada trabajo puede asignarse a un nodo o servicio. Para un único modelo, dos, tres o cuatro nodos pueden participar si el programa que ejecuta el modelo soporta el reparto y la topología se ha validado; no debe asumirse una memoria continua ni una mejora lineal.

Las capas que convierten varios equipos en un servicio operable

Empieza con una pareja o una pequeña flota y fuerza fallos: modelo que no carga, nodo fuera de red, trabajo duplicado, cola saturada y actualización fallida. Un clúster es útil cuando mantiene el servicio bajo estas condiciones, no cuando todos los nodos aparecen en un panel.