Clústeres de DGX Spark: dos unidades para un modelo y flotas para más trabajo

Dos unidades: un modelo de hasta 405B

NVIDIA documenta la conexión de dos DGX Spark mediante ConnectX-7 para trabajar con modelos de hasta 405.000 millones de parámetros. La capacidad efectiva depende del formato, la cuantización, el contexto y el motor. La interconexión reduce el coste de mover datos entre ambos sistemas, pero no elimina la sobrecarga de distribuir la ejecución.

Esta pareja debe tratarse como una configuración concreta: mismas versiones de sistema y contenedores, modelo compatible, enlace validado, memoria reservada y pruebas de recuperación. El cable DAC QSFP es una parte física; el resultado también depende del software.

Cuatro arquitecturas que sí escalan

¿Cuántos DGX Spark se pueden conectar: 2, 4, 8, 50, 500? Las reglas, claras

1. Un cable de red por unidad. Cada Spark trae un puerto de red estándar (10 GbE): de cada unidad sale un cable de red normal hasta el switch — en estrella, nunca encadenados. N unidades, N cables.
2. El switch, a tu red. El switch se conecta al router o a la red de la empresa. Desde ese momento todas las unidades se ven entre sí y son accesibles para los empleados.
3. El mismo modelo en cada una. En cada Spark se carga con Ollama el mismo modelo (o distintos modelos por función): copias completas e independientes, listas para responder.
4. Un repartidor con una sola dirección. Un pequeño servicio repartidor (por ejemplo LiteLLM, instalado en una de las unidades o en un mini PC) publica una única dirección para toda la empresa y envía cada petición a la unidad más libre. Si una se apaga, reparte entre las restantes y el servicio no se interrumpe.
5. El cable QSFP, solo para parejas. La unión especial por QSFP sirve exclusivamente para que dos unidades ejecuten un único modelo de hasta 405B. No se usa para la flota de ocho: la flota va por red normal.

La misma receta en todas las escalas

Honestidad de arquitecto: a partir de varias decenas de unidades conviene comparar la flota de Sparks con DGX Station o servidores GPU — más capacidad por caja y menos puntos de gestión. Distribuimos ambas vías y calculamos los dos escenarios con tus cifras.

Ejemplo real: una asesoría de 60 personas monta la flota de ocho. Cada empleado usa el chat de empresa desde su navegador con una única dirección interna; en hora punta las ocho unidades responden en paralelo; un martes falla una, se aparta para revisión y nadie en la oficina lo nota.

La topología no se improvisa

Una pareja directa y una flota tienen necesidades diferentes. Para una flota, la red de gestión, la red de servicio y las interconexiones de cómputo deben diseñarse por separado cuando el proyecto lo requiera. También hay que definir DNS, direcciones, sincronización de tiempo, almacenamiento de modelos y una ruta de actualización.

El balanceador debe conocer la salud del servicio y, si hay conversaciones con estado, mantener afinidad o externalizar ese estado. Los modelos y sus hashes deben estar versionados para que una réplica no responda con una revisión distinta.

Calcula servicio, no solo memoria

Empieza con una prueba de carga representativa: distribución real de prompts, contexto, salidas y usuarios. El promedio no basta; utiliza percentiles de latencia y contempla picos.

Seguridad, actualización y recuperación

• Identidad y autorización: ningún endpoint de modelos debe quedar abierto por conveniencia. Aplica autenticación, roles, límites y segmentación de red.
• Versionado: fija imágenes, motores, modelos y configuraciones. Actualiza por etapas y conserva una ruta de reversión.
• Datos: separa modelos, índices, documentos y registros; define copia, cifrado y retención para cada conjunto.
• Secretos: no introduzcas credenciales en prompts ni variables visibles. Utiliza un gestor y permisos mínimos.
• Observabilidad: correlaciona solicitud, modelo, versión, nodo, tiempos y errores sin registrar más datos personales de los necesarios.
• Continuidad: comprueba qué ocurre si cae un nodo, la red, el almacenamiento o el coordinador.

Para una interfaz de equipo, consulta Open WebUI. Para automatizaciones con revisión humana, consulta n8n, Ollama y Outlook. Para tratamiento de datos personales, revisa IA local y RGPD.

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, runtime 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.

Distinguir paralelismo de modelo, réplicas, lotes y funciones especializadas

A partir de dos unidades, la afirmación prudente es escalado horizontal: más réplicas, colas o trabajos. No prometas que diez cajas suman su memoria para un único modelo sin una arquitectura distribuida específica, probada y mantenible.

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

Un enlace directo entre dos Spark sirve al patrón emparejado. Una flota necesita además red de gestión y servicio. Dibuja cada flujo: sincronización de pesos, consultas de usuarios, acceso a RAG, métricas, copias y administración.

• 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 idempotencia.
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. No implican que un modelo cualquiera se reparta de forma transparente entre muchas unidades. Para un solo modelo, el emparejamiento oficial documentado se limita a dos DGX Spark y necesita un motor compatible.

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.