Dos GX10 en clúster: cuándo compensa juntarlas y cuándo es mejor tener dos cerebros
Juntar dos máquinas en un solo modelo da un millón de contexto y modelos de 300B. Separarlas da casi el doble de trabajo total. Las cifras de un mes probando las dos cosas en el mismo par de GX10.
Cuando tienes dos ASUS Ascent GX10 y un cable de 200 Gb/s entre ellas, la tentación es obvia: juntarlas y correr un modelo que no cabe en una. Lo hicimos. Funciona. Y aun así, la mayor parte del tiempo tenemos las dos máquinas separadas.
Este post resume por qué, con las cifras de los experimentos que lo decidieron.
Las dos formas de usar dos máquinas
Clúster (tensor parallel, TP=2). Las dos máquinas calculan cada token. Cada una lleva la mitad de los pesos y se pasan resultados intermedios por el cable a cada paso. Sirve un modelo que no cabría en una sola.
Residentes independientes. Cada máquina sirve su propio modelo. Dos cerebros. Si una se cae, la otra sigue.
No se pueden tener las dos cosas a la vez. Cuando el clúster arranca, la segunda máquina no está libre: está dentro. En el laboratorio lo llamamos, medio en broma, modo bestia y modo normal.
El cable: primero, que el clúster sea posible
Antes de discutir si compensa hay que conseguir que funcione. Nuestro primer intento dio una sorpresa: el enlace estaba conectado pero al 11 % de su velocidad nominal . La causa resultó ser tan tonta como un reinicio pendiente de los dos nodos. Tras reiniciarlos, un único cable QSFP expuesto como dos caminos lógicos dio (EXP-0055):
| prueba | resultado |
|---|---|
| RDMA simultáneo por los dos caminos | 98,01 + 98,01 = 196,02 Gb/s |
NCCL all_gather con 16 GiB |
21,78 GB/s de bus, cero errores |
| DeepSeek-V4-Flash repartido en TP=2 | 43,91 tok/s con 1M de contexto |
Dos trampas que conviene conocer antes de empezar: el índice GID de RoCE cambia tras un reinicio y NCCL no te avisa (P-092), y un enlace que negocia 200G puede quedarse en 13–15 Gb/s por camino tras conectarlo en caliente (P-079).
Modo bestia contra modo normal, medidos igual
La comparación que lo decidió todo (EXP-0059), con el mismo banco y los tokens contados por el servidor:
| modo bestia (1 modelo en 2 máquinas) | modo normal (2 modelos) | |
|---|---|---|
| pico de trabajo agregado | 95,5 tok/s | ~170 tok/s |
| una sola petición | 40,9 tok/s | 20,3 y 20,8 tok/s |
| contexto | 1.048.576 | 131.072 + 262.144 |
| cerebros | 1 | 2 |
El modo normal hace casi el doble de trabajo total. El clúster gana en una cosa, y es grande: el millón de contexto y la velocidad de un solo flujo. Si trabajas con varios agentes en paralelo —que es el uso real—, dos cerebros ganan por bastante.
Cuando el clúster sí compensa
Hay tres casos en los que lo tenemos claro:
- El modelo no cabe en una. GLM-5.3-Flash en EXL3 4 bpw, MiMo-V2.6-Flash o DeepSeek-V4.1 no caben en 128 GB con contexto útil. En dos, GLM sirve 1M de contexto con la receta TensorFold y ha pasado la aguja de contexto a casi 200.000 tokens (EXP-0129).
- Necesitas contexto enorme. Meterle un repositorio entero o un año de documentación.
- La calidad del modelo grande marca la diferencia. GLM-5.3 en clúster saca 90/100 en nuestro banco agéntico de 84 escenarios; es el mejor resultado que tenemos (EXP-0130).
Cuando no: el caso Hy3
No todo lo que cabe en dos máquinas merece estar ahí. Hy3 de 295B arrancó, respondió bien… y a 8,17 tok/s, cinco veces más lento que DeepSeek en las mismas máquinas y con ocho veces menos contexto. Descartado el mismo día (EXP-0056).
La regla que sacamos: un modelo en clúster tiene que ganar en algo que no puedas conseguir con dos modelos separados. Si solo es «más grande», no basta.
Y a veces, una sola máquina basta
Un detalle que nos sorprendió: una receta de una sola Spark para DeepSeek-V4-Flash, con los expertos podados y 3 bpw, reprodujo sus cifras publicadas (≈46 tok/s en salida estructurada) y no salió peor en calidad que nuestro DeepSeek completo (EXP-0064). Menos bits y menos expertos no siempre significan peor modelo. Hay que medirlo.
Lo que hacemos hoy
- Por defecto: GLM-5.3-Flash repartido en las dos (el mejor en herramientas y contexto).
- Cuando priorizamos agentes en paralelo: rotamos a dos residentes independientes, uno por máquina, elegibles desde un único gateway por nombre de nodo (guía 10).
- La rotación entre modos la hace Mission Control con una transacción que drena, cambia, prueba y, si algo falla, vuelve atrás.
Si solo tienes una máquina, casi todo lo que cuenta este post se resume en una frase: un buen MoE con pocos parámetros activos en una sola GX10 te dará más trabajo útil por vatio que cualquier clúster. El clúster es para cuando necesitas lo que una sola no puede darte.
Todas las cifras enlazan a su experimento. La clasificación completa, con las condiciones de cada medida, está en Benchmarks.