Conectar dos DGX Spark: QSFP, SSH, RoCE y Cluster Assistant

Un DGX Spark es un host sólido de inferencia en un solo nodo. Dos Sparks enlazados sobre ConnectX-7 son la vía por la que NVIDIA espera que crezcas hacia modelos y cargas de agentes que no caben en un pool de memoria coherente de 128 GB — o que necesitan serving tensor-parallel entre nodos.

Este artículo sigue el cuadro oficial de clustering de NVIDIA y el playbook connect-two-sparks. No sustituye a la documentación vigente el día en que conectes las cajas.

Fuentes primarias (empieza aquí):

• ConnectX-7 Networking / clustering (DGX Spark User Guide)
• playbook connect-two-sparks
• NVIDIA Sync (Cluster Assistant)
• Contexto de producto: DGX Spark · qué es Spark · realidad de la inferencia

La reconfiguración de red puede aislar un nodo o romper el acceso de gestión. Trabaja desde una ruta SSH conocida y buena en la interfaz de gestión / 10 GbE antes de cambiar el netplan de ConnectX-7. Usa cables QSFP aprobados; no fuerces un conector mal orientado en el puerto — NVIDIA documenta que forzar puede dañar el puerto.

Qué estás construyendo

A alto nivel:

1. Conecta físicamente las dos unidades con un cable QSFP en los puertos ConnectX-7 (ruta de clase 200 Gbps; el cable debe soportar al menos 200 Gb/s).
2. Asigna IPs a las interfaces Ethernet de Linux que aparecen para ese puerto (cada puerto QSFP mapea a dos interfaces lógicas).
3. Usa el mismo nombre de usuario en ambos sistemas.
4. Establece SSH sin contraseña entre nodos.
5. Ejecuta cargas distribuidas sobre la ruta de alta velocidad (tráfico orientado a NCCL / RoCE para inferencia o entrenamiento multinodo).

El playbook de NVIDIA publica sus propias estimaciones de tiempo y riesgo. Trátalas como notas de planificación del proveedor, no como una promesa para tu entorno. Vuelve a leer el README vigente antes del cambio porque la guía de interfaces y los prerrequisitos pueden cambiar.

Prerrequisitos

Del playbook oficial:

Opcional pero útil: una segunda persona vigilando las sesiones SSH de gestión, y una nota escrita de la salida previa al cambio de ip addr / ibdev2netdev.

Ruta A: NVIDIA Sync Cluster Assistant

Si quieres menos trabajo manual de netplan, NVIDIA documenta NVIDIA Sync Cluster Assistant como una ruta guiada:

• Descubrimiento automático y creación de red para topologías soportadas.
• Aplica ajustes de ConnectX-7, comprueba el rendimiento del enlace y configura SSH entre nodos.
• Soporta hasta tres Sparks conectados directamente por cables, y hasta cuatro al usar un switch (según la documentación de NVIDIA Sync / clustering).

Instala Sync en tu portátil, añade los Sparks y luego usa Cluster Assistant en lugar de editar YAML a mano — si tu topología está soportada. Para reglas de cableado físico, orientación izquierda/derecha del puerto y contexto de nombres de interfaz, sigue leyendo ConnectX-7 Networking. Cluster Assistant te ahorra teclear; no elimina la necesidad de cables correctos ni de un plan de rollback.

Ruta B: Playbook manual (connect-two-sparks)

1. Mismo nombre de usuario

whoami

Si los nombres difieren, crea un usuario coincidente (el ejemplo del playbook usa nvidia) en ambos sistemas, otorga sudo y continúa como ese usuario. Las recetas distribuidas y los scripts de claves SSH asumen paridad.

2. Conexión física QSFP

• Conecta un cable QSFP entre los dos Sparks.
• Prefiere la misma posición física de puerto en cada dispositivo al seguir playbooks orientados a NCCL (NVIDIA señala la coherencia de puertos para evitar problemas en las pruebas).
• Orienta la pestaña de extracción hacia arriba; inserta del todo sin forzar.
• Confirma el estado del enlace con ibdev2netdev — espera que las interfaces relevantes muestren Up.

Cada puerto físico QSFP aparece como dos interfaces Ethernet de Linux (y dispositivos RoCE correspondientes). Los nombres de ejemplo del playbook de NVIDIA tienen este aspecto: enp1s0f1np1 y enP2p1s0f1np1 para el mismo puerto físico — tus nombres pueden diferir; confía en ibdev2netdev en tus unidades.

Los puertos QSFP en Spark están configurados como Ethernet en la documentación de clustering de NVIDIA. Usa cables que NVIDIA liste como aptos para ≥200 Gb/s. Cables más rápidos no elevan el tope de 200 Gb/s del puerto.

3. Configuración de IP

El playbook ofrece:

• Opción 1 — netplan (/etc/netplan/40-cx7.yaml): persistente tras reinicio; chmod 600; sudo netplan apply.
• Opción 2 — ip addr add: más rápido de probar; las IPs no sobreviven al reinicio.

Patrón de direccionamiento de ejemplo del playbook (ajusta los nombres de interfaz a tus interfaces Up):

Las dos direcciones anteriores pertenecen a las dos interfaces lógicas del mismo puerto cableado, así que un enlace de un solo cable ya usa dos subredes. El manual de NVIDIA indica que el ancho de banda completo se alcanza con un solo cable QSFP, y su propia guía de evaluación de rendimiento con dos Spark mide el ancho de banda RoCE sobre un cable y suma los dos enlaces de ese puerto hasta unos 190 Gb/s, el tope de 200 Gb/s del puerto. Lo único que dice el manual sobre un segundo cable es un requisito de configuración: si se conectan dos cables, hay que asignar direcciones IP a las cuatro interfaces para obtener el ancho de banda completo. NVIDIA no documenta que un segundo cable entre los mismos dos sistemas aumente el rendimiento, así que planifica un segundo cable como topología —un tercer nodo o una red conmutada—, no como ancho de banda adicional para el mismo par.

Verifica con ip addr show <iface> en ambos nodos antes de depurar SSH.

4. SSH sin contraseña

Automático: ejecuta el script discover-sparks del playbook desde un nodo para descubrir los nodos pares y distribuir claves (puede pedirte contraseñas una vez).

Manual: ssh-copy-id tu clave pública a las IPs ConnectX-7 de ambos nodos usando el nombre de usuario compartido.

Verifica:

ssh <node1-cx7-ip> hostname
ssh <node2-cx7-ip> hostname

5. Cargas distribuidas y RoCE

SSH sin contraseña y alcanzabilidad L3 son la base. Las recetas de inferencia y entrenamiento multinodo luego dependen de la ruta ConnectX-7 / RoCE para comunicación colectiva (NCCL y similares). No esperes que Wi-Fi 7 o el puerto RJ-45 de 10 GbE lleven ese fabric.

Los siguientes pasos tras la conectividad suelen vivir en otros playbooks (vLLM multinodo, pruebas NCCL, recetas de modelos específicas). Valida los colectivos con las comprobaciones NCCL / clustering documentadas por NVIDIA para tu versión de software antes de culpar al servidor de modelo.

Trampa de los nombres de interfaz (léela antes de escribir YAML)

La guía de clustering de NVIDIA explica por qué la disposición ConnectX-7 de Spark confunde a quien está acostumbrado a un NIC = un eth0:

• Cada puerto QSFP tiene dos rutas PCIe hacia el SoC.
• Linux por tanto expone dos interfaces Ethernet por puerto físico, más dispositivos RoCE correspondientes.
• Los ejemplos del playbook (enp1s0f1np1, enP2p1s0f1np1, …) son ilustraciones. Siempre mapea desde ibdev2netdev en tu par tras asentar el cable.

Si netplan referencia las interfaces Down mientras el par Up se ignora, perseguirás fantasmas de «cable malo» durante una hora. Imprime la tabla de correspondencia de la documentación de clustering y tenla junto a tu terminal en la primera puesta en marcha.

Notas de seguridad para la subred CX7

Trata el enlace ConnectX-7 como un fabric de confianza, no como Wi-Fi de invitados:

• No lo puentes casualmente a una VLAN de usuarios corporativos.
• Limita qué procesos se enlazan a los puertos RPC / NCCL / inferencia en esas IPs.
• Recuerda que SSH sin contraseña entre nodos es movimiento lateral potente si alguna de las cajas se ve comprometida — protege el acceso físico y las cuentas del OS en consecuencia.
• Mantén los hábitos de gestión y «SSH humano» en la ruta de gestión documentada para que un error de CX7 no equivalga a un bloqueo total.

Riesgo, validación y rollback

Diseño del rollback (adapta el playbook de NVIDIA al host):

• Antes de editar, identifica si /etc/netplan/40-cx7.yaml ya existe y si algún otro archivo de netplan configura las mismas interfaces. Haz copia de seguridad de los archivos afectados y anota sus hashes, su propietario y sus permisos.
• No elimines a ciegas un archivo preexistente. Restaura los archivos exactos previos al cambio, ejecuta sudo netplan generate, inspecciona el resultado generado y luego aplícalo a través de la ruta de gestión conocida y buena.
• Para las direcciones temporales, elimina solo las direcciones explícitas que añadiste en este cambio y verifica las rutas y el estado del enlace resultantes.
• Mantén acceso por consola o por una vía de gestión independiente hasta que ambos nodos pasen las comprobaciones de SSH y enrutamiento posteriores al rollback.

El rollback restablece la red del clúster. Prográmalo como una ventana de cambio si alguien depende del endpoint multinodo. Confirma que el SSH de gestión sigue funcionando antes de borrar configs.

Tabla rápida de solución de problemas

Extraída de los síntomas del playbook de NVIDIA:

No hagas esto aún

• No arranques un modelo tensor-parallel de producción antes de que pasen SSH y las comprobaciones de enlace.
• No mezcles IPs ad hoc con archivos netplan olvidados entre reinicios.
• No expongas la subred CX7 a redes no confiables.
• No fuerces conectores QSFP ni uses cables DAC aleatorios sin comprobar notas de velocidad/compatibilidad en la guía de usuario.

Prueba mínima de aceptación

Antes de apuntar agentes a un endpoint multinodo:

1. Ambos nodos alcanzables por ping en la subred CX7.
2. SSH sin contraseña en ambas direcciones como el usuario compartido.
3. La comprobación NCCL o de enlace documentada en el playbook da verde.
4. La lista de nodos de la receta de serving usa direcciones CX7, no IPs Wi-Fi.
5. Pasos exactos de copia de seguridad y restauración probados en una ventana de mantenimiento sin perder la ruta de gestión.

Dos Sparks más una ruta QSFP aprobada son un patrón documentado de NVIDIA. Los comandos de puesta en marcha y de rollback de este artículo siguen la documentación del proveedor; no son un resultado certificado para tu hardware, tu cableado ni tus versiones de software. Trata cualquier puesta en marcha de un fabric nuevo como un corte de red bajo control de cambios, recoge tu propia evidencia de aceptación y ten a la vista las restricciones de realidad de la inferencia solo después de que el fabric supere esas pruebas.