Durante semanas tuvimos esta receta en revisión: no queríamos publicar una tabla de validación sin haberla validado. Ya la tenemos: dos máquinas sirviendo el mismo modelo, con las medidas en el registro.

Esto es lo que hay que saber antes de encender nada.

La trampa conceptual con la que hay que empezar

Dos máquinas con 128 GB cada una tienen 256 GB en el inventario. No tienen un pool de 256 GB.

No hay un único espacio de memoria coherente. Cualquier modelo que use los dos nodos tiene que repartir explícitamente pesos, caché KV y cómputo, y cada pieza viaja por una red que es órdenes de magnitud más lenta que la memoria local. Cuando alguien dice «me faltan 128 GB, compro otra máquina», está asumiendo que el problema era de espacio, y casi siempre el problema pasa a ser de comunicación.

Antes de gastar dinero, decide cómo se reparte:

Paralelismo de tensor (TP): cada capa se corta en trozos y los dos nodos calculan cada token a la vez. Reduce el consumo por nodo, pero todo token obliga a comunicarse.
Paralelismo de pipeline (PP): nodos distintos se llevan capas distintas. Menos comunicación por token, pero un nodo está parado mientras el otro trabaja.
Réplicas con router: dos máquinas independientes, dos cargas. No amplía el contexto de un solo modelo, pero escala el rendimiento total y es lo más fácil de operar.

Nosotros usamos TP=2 sobre red de alta velocidad, no llama.cpp RPC. La diferencia no es de gusto: con tensor parallel los dos nodos trabajan cada token; con RPC por capas, el cuello es la red.

La red no es un detalle, es la receta

Aquí es donde se decide si esto funciona. Un cable de casa no vale: lo que hace viable el reparto es una red con RDMA y los dos nodos en un enlace directo, sin pasar por el router de la casa.

Lo que registramos como condición, no como detalle:

Enlace directo entre nodos, con una segunda ruta por si una falla (doble vía).
RDMA verificado antes de tocar el modelo. NCCL y RDMA probados por separado; si eso no está verde, ningún runtime lo va a arreglar después.
Identificador de ruta (GID) correcto por nodo. No es el mismo en los dos extremos y puede cambiar tras un reinicio. Equivocarlo da un error de NCCL que no explica nada (P-092): compruébalo en cada arranque.
Los pesos compartidos por un sistema de ficheros de red privado sobre ese enlace, no por el disco local de cada nodo duplicado a mano.

Lo que hay que aceptar del primer arranque

Lee los pesos enteros dos veces y tarda minutos. En nuestro caso, unos 155 GiB por nodo y un timeout operativo de 30 minutos. Si tu herramienta “se ha colgado” a los cuatro minutos del primer arranque, no se ha colgado.

Y una regla operativa que nos ha costado: no arranques el nodo worker a mano. El lanzador del nodo principal ya lo hace por SSH y mantiene el rendezvous de NCCL. Arrancarlo a mano deja un contenedor huérfano y un estado que parece sano y no lo es. Si escribes un script de arranque, escribe también el de parada y compruébalo: el nuestro usaba un nombre antiguo de contenedor y dejaba el viejo vivo al reiniciar.

Las medidas, con nombre y apellidos

Del modelo residente dual, en contexto nativo de 262K:

Prefill 2.110 tok/s a 250K de entrada.
Decode caliente 37–40 tok/s típico, 47,7 tok/s en contexto largo.
180,4 tok/s agregados con cuatro peticiones concurrentes.
Sin estrangulamiento térmico, unos 75 °C por nodo en carga.

Y aquí la parte del protocolo que importa: esas cifras no son comparables con las de un solo nodo salvo que el runtime, el cuantizado, el contexto y la carga sean los mismos. Comparar “40 tok/s en dual” con “60 tok/s en otro modelo en un nodo” no dice nada del cluster: dice cosas distintas de modelos distintos.

La prueba de fuego de un cluster no es la velocidad, es que el modelo siga respondiendo bien repartido: salud, llamada a herramienta, visión, razonamiento y agujas en contexto largo. Nuestro banco agéntico completo (84 escenarios × 3 pasadas) dio 86/100 de mediana, con 72/84 escenarios aprobados al menos una vez. Eso es lo que hizo que el dual fuera adoptable; los tok/s vinieron después.

Cuándo no compensa

El modelo cabe en un nodo. Entonces el cluster solo añade puntos de rotura.
Carga de un solo usuario. Hemos medido que concurrencia en un nodo grande no escala lineal: cuatro peticiones daban un agregado más o menos plano, y el TTFT se multiplicaba por encolamiento. Dos nodos como réplicas resuelven eso mejor que un TP=2.
No tienes RDMA. Con red Ethernet normal, el coste de comunicación se come la ganancia de memoria.
No puedes pagar la operación. Un residente dual tiene un servicio que coordina dos máquinas, un lanzador worker-first y un reinicio que tarda. Eso es infraestructura que hay que mantener despierta.

Lo que sí compensa: el modelo que no cabe de ninguna otra manera y que necesitas con contexto largo. Ahí no hay alternativa, y dos máquinas pequeñas son la única forma de entrar.

Antes de comprar la segunda máquina

Contesta esto por escrito:

¿Qué modelo concreto quieres servir, con qué cuantizado y qué contexto?
¿Cabe en uno, o no cabe? Si cabe, para esto no hay cluster.
¿Tienes un enlace directo con RDMA entre las dos, o red de casa?
¿Qué prueba demuestra que el modelo repartido sigue siendo correcto — no solo rápido?
¿Quién levanta el sistema después de un reinicio, y en cuánto tiempo?

Si las cuatro primeras respuestas son claras y la quinta te da pereza escribirla, ya sabes qué es lo que te va a doler.

Contexto de estas cifras: dos ASUS Ascent GX10 (GB10, 128 GB unificados por nodo) con vLLM y tensor parallel 2, medidas propias en Benchmarks y registro. No son números de ficha de fabricante ni de un foro: son nuestras, con su commit de runtime y su temperatura.