Clúster de DGX Spark: tres equipos sin switch, cuatro ya con switch

5. ago 2026 Español 19 min de lectura También en: Deutsch, English

nvidia-dgx-spark ia-local hardware

Desde el 4 de agosto circula en X una guía breve para elegir switch en clústeres de DGX Spark. Menciona tres modelos de MikroTik y da por hecho que a partir de tres equipos hace falta un switch. El planteamiento es correcto, pero deja fuera lo que una empresa necesita saber primero: qué cambia exactamente entre dos, tres y cuatro equipos, y qué se compra con ese dinero.

A finales de junio cableamos dos DGX Spark como clúster paso a paso. Este artículo continúa desde ahí: tres equipos, cuatro equipos, ocho equipos, la comparación con un Mac Studio y, al final, un ejemplo calculado con 25 usuarios simultáneos.

Qué admite NVIDIA de forma oficial

La respuesta con valor de referencia no está en un hilo de foro, sino en el asistente de clúster de NVIDIA Sync. Cubre de dos a un máximo de cuatro DGX Spark y describe tres caminos:

Dos equipos: un cable, de puerto a puerto.
Tres equipos: tres cables en anillo, cada equipo conectado con los otros dos.
Cuatro equipos: un cable por equipo a través de un switch. Cuatro equipos exigen switch.

Hay una regla fácil de pasar por alto: no mezclar. O todos los equipos van conectados directamente o todos pasan por el switch. Dos equipos cableados entre sí más un tercero colgando de un switch no es una topología prevista.

Pasar de cuatro equipos significa salir del terreno que cubre esa herramienta. Nada lo impide técnicamente, sigue siendo Ethernet con RoCE, pero la configuración guiada termina ahí, y con ella el camino cómodo de vuelta cuando algo falla.

Tres equipos es el punto tranquilo

Tres DGX Spark suman 384 GB de memoria compartida, necesitan tres cables y no añaden ningún aparato al armario. Sin switch no hay un segundo firmware, ni una segunda fuente de alimentación, ni una pieza más que pueda caerse de madrugada. Para un modelo que no cabe en 128 GB pero sí en 384 GB, esta es la forma más sencilla que existe.

Conviene conocer igualmente la aritmética. Un equipo dispone de unos 200 Gb por segundo en total, repartidos en dos rutas PCIe Gen5 x4. En el anillo, dos vecinos comparten ese presupuesto. Entre dos equipos conectados directamente pertenece a un único enlace, en el anillo no. Planifique por tanto con aproximadamente la mitad del ancho de banda por vecino que da la pareja de dos equipos. NVIDIA no publica cifras de rendimiento para el anillo, así que solo queda la medición propia.

Los 200 Gb que ningún flujo ve por sí solo

Aquí es donde se quema más tiempo en la práctica, y merece algo más que media frase.

ServeTheHome midió el montaje y lo describe como poco habitual para un enlace de 200GbE: detrás de las jaulas QSFP hay dos MAC de 100 Gb sobre dos rutas PCIe Gen5 x4 separadas. Midieron entre 92 y 98 Gb por segundo por ruta con RoCE, unos 190 en conjunto. Con tramas jumbo y de 60 a 64 flujos en paralelo salieron entre 160 y 198 Gb por segundo según la dirección del tráfico. La cifra de la caja es alcanzable, pero es una suma, no algo que vea un único enlace.

Un informe de campo en el foro de desarrolladores de NVIDIA muestra el mismo efecto desde el otro lado. Allí funciona un clúster de cuatro equipos con un MikroTik CRS812 y cables breakout. Al principio un solo flujo TCP llegaba a unos 30 Gb por segundo y en paralelo unos 106, aunque el enlace había negociado a 200GbE. Solo cuando el operador se dio cuenta de que ese puerto físico aparece como dos interfaces lógicas y hay que usar las dos, además de fijar MTU 9000 y desactivar IPv6, la pareja se quedó en unos 196 a 198 Gb por segundo. Una prueba de NCCL dio después unos 23,76 GB por segundo de ancho de banda de bus. De paso encontró una entrada antigua NCCLIBDISABLE=1 en la configuración que bloqueaba el RDMA por completo.

De ahí salen cuatro consecuencias prácticas.

Un flujo aislado termina cerca de 100 Gb por segundo. No es un error de configuración, es la arquitectura. Quien mida con iperf3 sin paralelismo verá la mitad de su capacidad y buscará durante días una avería que no existe.

La cifra del folleto presupone paralelismo. Las dos interfaces lógicas tienen que llevar tráfico, si no una de las dos rutas PCIe queda parada. En inferencia distribuida de eso se encarga NCCL cuando está bien configurado. En cualquier transferencia hecha a mano no se encarga nadie.

Un cable más no amplía el presupuesto del equipo. La segunda jaula solo lo reparte de otra manera. Por eso la segunda jaula existe para la topología y no para la velocidad, y por eso el anillo reduce a la mitad el ancho de banda por vecino.

Mida tres valores antes de subir un modelo a la máquina. Primero iperf3 con un solo flujo, ese es su suelo. Segundo iperf3 con varios flujos en paralelo y MTU 9000, ese es su techo. Tercero una prueba NCCL entre todos los nodos, porque solo esa demuestra que el RDMA está activo. Un enlace que promete 200 en la ficha y da 30 en la primera prueba es el estado normal antes de configurar, no una avería.

A partir de cuatro equipos: qué switch

Aquí la guía de X resulta útil porque sitúa bien los tres modelos. Hemos contrastado los datos con las páginas del fabricante.

MikroTik CRS504-4XQ-IN, cuatro puertos de 100 Gb, entre 640 y 780 dólares según el distribuidor. Cuatro puertos significan cuatro equipos, justo el techo del asistente oficial. La guía cita informes de usuarios con cerca del 98 por ciento del rendimiento de switches mucho más caros. La cifra no está confirmada, pero es plausible: si un flujo aislado se queda en 100 Gb de todos modos, un puerto de 100 Gb cuesta menos rendimiento del que sugiere la ficha técnica.

MikroTik CRS804-4DDQ-hRM, cuatro puertos de 400 Gb en formato QSFP56-DD, tarifa de 1.295 dólares. No tiene puertos nativos de 200 Gb. Cada puerto de 400 se divide en dos enlaces de 200 con cable breakout, cuatro por dos son ocho equipos. Es la vía más limpia si el objetivo son ocho.

MikroTik CRS812-8DS-2DQ-2DDQ-RM, también 1.295 dólares, con dos puertos de 400 Gb, dos puertos nativos de 200 Gb y ocho de 50 Gb. Dos breakouts dan cuatro enlaces de 200 Gb, y con los dos puertos nativos suman seis equipos a pleno ancho. Para ocho se divide uno de los puertos de 400 en cuatro de 100, con lo que quedan cuatro equipos a 200 Gb y cuatro a 100 Gb. Este es exactamente el switch del informe de campo enlazado arriba, así que el camino está recorrido.

Una corrección propia: en nuestra guía de junio el CRS504 aparecía como switch de 200GbE para cuatro a ocho equipos. Las dos cosas eran inexactas. Tiene cuatro puertos de 100 Gb, lo que lo limita a cuatro equipos. Hemos corregido el pasaje.

Qué compra realmente un clúster: memoria, no velocidad

La cifra más importante no está en la ficha de ningún switch. StorageReview midió un clúster de dos equipos con inferencia distribuida y da entre 464 y 505 tokens por segundo con GPT-OSS-120B según el fabricante del equipo. Su conclusión es directa: agrupar equipos aporta sobre todo capacidad de memoria, no rendimiento, y el enlace entre ellos sigue siendo el cuello de botella.

El motivo está en el reparto del trabajo. Con paralelismo de pipeline, que es lo habitual, cada equipo se queda con una parte de las capas. Cada token recorre entonces todos los equipos, uno detrás de otro. El enlace queda así en el camino de cada token, no solo en la carga del modelo. Los lotes grandes tapan parte de ese coste porque mantienen la tubería llena, pero no lo eliminan. Dos equipos duplican la memoria, no el rendimiento.

En los modelos de mezcla de expertos aparece además un detalle que se pasa por alto. MoE ahorra cálculo, no memoria. Gemma 4 26B activa solo 4.000 millones de parámetros por token, pero los 26.000 millones tienen que estar en memoria, porque el enrutador no sabe de antemano cuál de los 128 expertos hará falta para el siguiente token. Google lo dice así en su resumen del modelo. Y con muchos usuarios simultáneos también encoge la ventaja de cálculo: cada usuario toca expertos distintos, así que en un lote de 25 peticiones la unión de expertos activados es mucho mayor que en una sola. El tráfico de memoria se acerca al modelo completo justo cuando hay mucha gente trabajando a la vez.

Eso cambia la decisión de compra. Un DGX Spark cuesta 4.699 dólares de tarifa desde febrero de 2026, frente a los 3.999 anteriores. Tres equipos son por tanto más de 14.000 dólares más cables antes de haber respondido a una sola consulta. Gastar esa cantidad para acelerar un modelo que ya funciona en 128 GB es gastar al lado del objetivo. La primera pregunta siempre es si el modelo que de verdad necesita cabe en un equipo. Si cabe, la segunda caja está mal invertida. Si no cabe, el clúster no es un lujo, es la condición para que funcione en local.

Contraste: Mac Studio Max y Ultra

Para inferencia local el Mac Studio ha sido la alternativa evidente, y sobre el papel tiene un argumento fuerte. Un M4 Max ronda los 546 GB por segundo de ancho de banda de memoria y un M3 Ultra los 819. El DGX Spark se queda en unos 273. Con un solo usuario esperando su respuesta, esa cifra se traduce directamente en tokens por segundo. Lo describimos en julio en la comparación directa de ambos equipos y técnicamente no ha cambiado nada.

Lo que sí ha cambiado es el mercado. Por la escasez de chips de memoria, Apple ha ido retirando las configuraciones grandes: primero los 512 GB en marzo de 2026, después también 128 y 256 GB. Hoy un Mac Studio con M3 Ultra solo se puede pedir con 96 GB, desde 3.999 dólares, y Macworld habla de 13 a 14 semanas de plazo sin existencias en los grandes distribuidores. Un DGX Spark con 128 GB se entrega. No es un argumento técnico, pero es el argumento que decide un proyecto en el tercer trimestre.

En un clúster de Macs se suma la cuestión del enlace. Apple conecta sus equipos por Thunderbolt 5, con RDMA a través de JACCL desde macOS Tahoe 26.2, y en nuestras mediciones y las de la comunidad eso son 50 a 60 Gb por segundo. Tres Mac Studio de 96 GB suman 288 GB, sí, pero sobre un tercio del ancho de banda que tienen dos DGX Spark entre sí. Y como un clúster compra sobre todo memoria, ese es justo el punto donde duele.

Queda el software. Para un solo usuario, MLX es maduro y rápido. Para muchos usuarios simultáneos, al stack de MLX le sigue faltando un equivalente a PagedAttention y a la planificación de peticiones de vLLM. Un trabajo sobre inferencia a escala en Apple Silicon mide en un M4 Max de 128 GB un factor de 2,6 entre una y 16 peticiones simultáneas con Qwen3-8B, y señala la saturación del ancho de banda de memoria como techo para modelos mayores. Es un resultado digno, pero no es la escalabilidad de un stack CUDA con batching continuo.

En resumen: un usuario, respuestas largas y sin ajuste fino es terreno Mac, siempre que se pueda esperar a la entrega. Muchos usuarios, entradas largas, ajuste fino o un entorno Linux de producción es terreno Spark.

Ejemplo calculado: Gemma 4 26B MoE para 25 usuarios simultáneos

Vamos a lo concreto, porque a estas alturas los consejos abstractos no valen nada.

Gemma 4 26B A4B tiene 26.000 millones de parámetros, activa 4.000 millones por token repartidos en 128 expertos y trabaja con 256K de contexto. Google cifra oficialmente los pesos en 57,7 GB en BF16, 28,8 GB en 8 bits y 14,4 GB en 4 bits.

Con eso la pregunta del clúster queda resuelta. En BF16 el modelo ocupa unos 58 de los 128 GB de un solo DGX Spark. Quedan unos 70 GB para caché KV, activaciones y sistema operativo, y con 25 sesiones la caché KV es la partida que de verdad cuenta. Para este modelo y este número de usuarios no hace falta una segunda caja, ni una tercera, y mucho menos un switch. En 8 bits cabe de sobra, lo que deja margen para contextos más largos o para un segundo modelo al lado.

En un Mac Studio con los 96 GB que se pueden pedir hoy, BF16 también cabe, pero el margen es estrecho: macOS reserva parte de la memoria compartida y 25 sesiones con contexto largo se comen justo lo que queda. Aquí los 8 bits no son una opción, son el ajuste razonable.

Para esos 25 usuarios deciden tres cosas, y el ancho de banda es solo una de ellas.

El procesado del prompt. 25 usuarios que envían cada uno una página de contexto o un extracto de RAG generan carga de cálculo, no tráfico de memoria. Es la disciplina en la que la GPU Blackwell del Spark mantiene su ventaja y en la que el ancho de banda del Mac ayuda menos.

La gestión de la caché KV. 25 sesiones son 25 cachés que crecen con longitudes y duraciones distintas. Para eso existe PagedAttention. Sin un equivalente, el fallo no aparece como cifras malas, sino como peticiones rechazadas en cuanto la memoria se fragmenta.

El efecto de los expertos. Con lote de 25 el tráfico de memoria se acerca al modelo completo y la ventaja de los 4.000 millones activos se reduce. Dimensionar con el dato de un solo usuario es dimensionar corto.

La recomendación para este caso es por tanto: un DGX Spark, pesos en 8 bits, vLLM con batching continuo y una prueba de aceptación con 25 peticiones en paralelo en lugar de una. Y si un equipo no da abasto, la respuesta sigue sin ser un clúster, sino una segunda copia al lado. El motivo está en el apartado siguiente.

Una limitación honesta: las cifras de memoria son oficiales, la conclusión que sacamos de ellas es aritmética. No conocemos una medición publicada de esta combinación exacta, Gemma 4 26B sobre DGX Spark con 25 usuarios simultáneos. Lo que hagan con ella sus prompts, sus longitudes de contexto y su patrón de respuesta solo lo enseña una prueba con su tráfico real.

Tres equipos en paralelo en lugar de en clúster

Cuando el modelo cabe en un equipo y aun así crece la carga, la respuesta correcta no es el clúster, es la réplica. Son dos arquitecturas para dos problemas distintos y se confunden con frecuencia.

El clúster con paralelismo de pipeline resuelve que el modelo no cabe en un equipo. La memoria se junta, cada token recorre todos los nodos en serie, el rendimiento no mejora y, si cae un nodo, se para el conjunto.

Las réplicas detrás de un router resuelven que el modelo cabe pero la carga no. Cada equipo tiene el modelo completo y responde de forma independiente. El rendimiento crece casi linealmente con el número de equipos, una caída cuesta un tercio de la capacidad en lugar de toda, y las actualizaciones se hacen máquina a máquina sin parar el servicio.

Para Gemma 4 26B con 25 usuarios, la segunda arquitectura es la correcta en cuanto un equipo se queda corto. No necesita switch de 100 ni de 400 Gb, ni cable QSFP, ni NCCL. Entre réplicas solo viajan peticiones y respuestas, nunca resultados intermedios, así que basta la red normal de la empresa.

LiteLLM es la capa evidente para esto: un endpoint compatible con OpenAI delante, tres instancias de vLLM detrás, estrategias de reparto como least-busy o por latencia, cadenas de reserva automáticas cuando una instancia deja de responder, y claves, presupuestos e imputación de costes por equipo. Es la infraestructura que una empresa necesita igualmente para modelos locales, con independencia del número de equipos.

Hay un detalle que consume mucho cálculo en silencio y que no aparece en ninguna lista de cables: el reparto por turnos destruye la reutilización de la caché de prefijos. Si 25 usuarios envían el mismo prompt de sistema largo o el mismo contexto de RAG, la misma sesión debe caer siempre en el mismo equipo, si no el prefijo idéntico se vuelve a procesar en cada máquina. El router del production stack de vLLM hace exactamente eso, por sesión, consciente del prefijo y consciente de la caché KV. Con peticiones cortas y variadas da igual. Con prefijos largos compartidos es la diferencia entre procesarlos una vez y procesarlos veinticinco.

La segunda máquina, además, muchas veces no es una gemela, sino que lleva otro modelo, embeddings, un reranker o un modelo de programación. Entonces LiteLLM reparte por nombre de modelo en lugar de por carga, y el clúster nunca fue la pregunta.

Los puestos no son peticiones simultáneas

Antes de encargar nada hay que aclarar una cifra que se confunde continuamente: 25 puestos de trabajo y 25 peticiones a la vez dentro de la máquina son dos cosas completamente distintas.

Como regla aproximada, en hora punta se está atendiendo a la vez entre el tres y el ocho por ciento de los puestos. 25 puestos dan por tanto una o dos peticiones en paralelo, y con eso basta un equipo de sobra. 500 puestos dan aproximadamente entre 15 y 40, así que 25 peticiones simultáneas es un punto de diseño realista para una plantilla de ese tamaño. Ese caso exige otra planificación.

Con 500 puestos aparecen tres requisitos que con 25 no existen. Los picos: lunes por la mañana, un correo a toda la empresa, un proceso por lotes que alguien lanzó de madrugada. Quien dimensiona por la media genera la cola justo cuando la ve todo el mundo. La tolerancia a fallos: 500 personas en un solo equipo son un punto único de fallo. Aquí N más uno no es un lujo, es la razón por la que se compra más de una máquina. La variedad de tareas: 500 personas traen programación, contextos largos de RAG y resúmenes, y la longitud de contexto marca la necesidad de caché KV más que el número de usuarios.

Al repartir en réplicas, un modelo de mezcla de expertos añade un efecto que va en contra de la intuición habitual. Gemma 4 elige dos de 128 expertos por token. En un lote de B peticiones simultáneas, un experto concreto se activa con una probabilidad de uno menos (uno menos 2 entre 128) elevado a B:

Lote de 8: en torno al 12 por ciento de los expertos por capa
Lote de 25: en torno al 33 por ciento
Lote de 50: en torno al 55 por ciento

Tres réplicas con ocho peticiones simultáneas cada una leen por paso bastante menos pesos que un equipo con 25. Es un cálculo aproximado que supone expertos repartidos de forma uniforme, y en la práctica los prompts se parecen entre sí y la cifra sale más baja. La dirección se mantiene: en mezcla de expertos, varios lotes pequeños son más suaves con el ancho de banda de memoria que uno grande.

Lo que lleva a la pregunta incómoda con esta carga: ¿son tres DGX Spark la compra correcta? Con 273 GB por segundo de ancho de banda, el Spark está pensado como equipo de desarrollo, no como tarjeta de servidor. Una RTX PRO 6000 Blackwell lleva 96 GB de GDDR7 a 1.792 GB por segundo, unas seis veces y media más, y Gemma 4 26B en 8 bits cabe holgadamente en sus 28,8 GB con margen de sobra para la caché KV. Desde junio de 2026 está en unos 13.250 dólares, más o menos lo que cuestan tres Sparks.

La comparación honesta para 25 peticiones simultáneas queda así:

Tres DGX Spark, unos 14.100 dólares. Ocho peticiones simultáneas por equipo, N más uno sin coste adicional, sin rack ni refrigeración de servidor, y cada equipo sirve además como máquina de desarrollo. A cambio, el menor ancho de banda por petición.
Una RTX PRO 6000 Blackwell en servidor, unos 13.250 dólares más el anfitrión. Con diferencia el mejor tiempo de respuesta por petición, pero un punto único de fallo para 500 personas y 600 vatios en el rack. Para N más uno, el doble.

Para 500 puestos planificamos con tres réplicas y decidimos entre Spark y tarjeta de servidor según la velocidad de respuesta comprometida. Si al usuario le basta con la velocidad de lectura, tres Sparks son el montaje más tranquilo y más resistente a fallos. Si hay comprometidos tiempos cortos con entradas largas, por ejemplo en una herramienta de programación, la tarjeta de servidor es la elección más honesta. Lo que no ayuda en ninguno de los dos casos es el clúster.

Qué significa esto para una empresa

Los cables y el switch son la partida más pequeña de este montaje y aun así deciden si la inversión rinde. Un clúster con la MTU equivocada y un solo flujo entrega un tercio de lo que se pagó, y nadie lo nota porque todo funciona.

El resto es el cálculo conocido. Si la inferencia corre en casa, ninguna consulta sale de la red, que es el núcleo de lo que describimos en IA local y, en sectores regulados, suele ser el motivo real para comprar este hardware. Si eso requiere un equipo o tres depende del modelo que resuelva su tarea, no de la recomendación de un hilo.

Si prefiere hacer esa comparación con sus propias cifras en lugar de deducirla de una lista de cables, un proyecto piloto es el camino corto. Medimos su carga real en un equipo antes de hablar del segundo. Para una pyme que además quiera revisar la financiación disponible, el marco está en Kit Digital.

Fuentes

Preguntas frecuentes

¿Cuántos DGX Spark puedo conectar sin switch?

Hasta tres. Dos equipos se unen con un solo cable directo y tres forman un anillo con tres cables, en el que cada equipo se conecta con los otros dos. A partir del cuarto, el propio asistente de clúster de NVIDIA exige un switch. No se pueden mezclar los dos métodos, o todos los equipos van directos o todos pasan por el switch.

¿Qué switch encaja en un clúster de DGX Spark?

Para cuatro equipos basta un MikroTik CRS504 con cuatro puertos de 100 Gb, que se encuentra entre 640 y 780 dólares según el distribuidor. Si el objetivo son ocho equipos, el CRS804 con cuatro puertos de 400 Gb permite dividir cada uno en dos enlaces de 200 Gb con cables breakout. El CRS812 es la alternativa cuando el CRS804 no está disponible, ambos rondan los 1.295 dólares de tarifa.

¿Gemma 4 26B MoE necesita un clúster para 25 usuarios simultáneos?

No. El modelo tiene 26.000 millones de parámetros en total y activa 4.000 millones por token. Google cifra los pesos en 57,7 GB en BF16, 28,8 GB en 8 bits y 14,4 GB en 4 bits. Las tres variantes caben en un solo equipo de 128 GB y queda sitio para la caché KV de 25 sesiones. Si un equipo no da abasto, se pone una segunda copia al lado y se reparte con LiteLLM, en vez de montar un clúster. Las réplicas suman rendimiento, los nodos de clúster no.

¿Mac Studio o DGX Spark con muchos usuarios simultáneos?

Con un solo usuario gana el Mac Studio, porque sus 546 a 819 GB por segundo de ancho de banda de memoria frente a los 273 del Spark se traducen directamente en tokens por segundo. Con 25 usuarios simultáneos el peso se desplaza al procesado del prompt y a la gestión de la caché KV, y ahí el stack CUDA con vLLM va por delante del stack MLX. A eso se suma la situación del mercado, el Mac Studio está hoy limitado a 96 GB y con 13 a 14 semanas de plazo.