Per què un clúster AMD de quatre nodes era lent: la lliçó sobre latència, RDMA i vLLM
Alex Ziskind explica tres mesos de proves amb quatre equips Strix Halo. El coll d’ampolla no era l’amplada de banda: calien paral·lelisme tensorial, RDMA i un entorn ROCm compatible.
Alex Ziskind va reunir quatre equips amb AMD Ryzen AI Max+ 395 i 128 GB de memòria unificada cadascun per executar models de llenguatge massa grans per a un sol node. Sobre el paper, el conjunt disposava de prop de mig terabyte de memòria compartida entre CPU i GPU. A la pràctica, afegir ordinadors no accelerava la generació de text.
Durant tres mesos va culpar la xarxa, va canviar targetes, va provar commutadors de gran capacitat i va combinar diverses eines. El vídeo reconstrueix els errors fins a arribar a la causa: estava tractant com un problema d’amplada de banda una càrrega que depenia sobretot de la latència, del tipus de paral·lelisme i de la compatibilitat del programari.
Més nodes donaven memòria, però no més velocitat
El primer experiment utilitzava eines que repartien el model entre màquines. Aquesta estratègia permetia carregar pesos que no cabien en un sol equip, però cada token havia de travessar les parts de manera successiva. El node següent esperava el resultat de l’anterior, de manera que la feina no avançava simultàniament.
La diferència és entre repartir capacitat i paral·lelitzar càlcul. Amb l’RPC de llama.cpp, Ziskind podia sumar memòria remota i executar models grans. En les seves proves, però, dos o quatre nodes no augmentaven proporcionalment els tokens per segon; a vegades, la comunicació feia que el conjunt fos més lent.
El projecte llama.cpp descriu el seu backend RPC com una tecnologia encara experimental. Pot exposar dispositius remots i distribuir-hi pesos i memòria cau, però això no converteix qualsevol xarxa de màquines en una GPU virtual ràpida.
El salt al paral·lelisme tensorial
Per accelerar una sola inferència, Ziskind necessitava que diversos nodes participessin alhora en les operacions matemàtiques de cada capa. Aquest és el paper del paral·lelisme tensorial: divideix els tensors i combina els resultats durant el càlcul, en comptes de limitar-se a passar el token per una cadena de fragments.
La seva eina principal passa a ser vLLM. El projecte permet definir quants acceleradors formen el grup tensorial i combinar aquesta tècnica amb paral·lelisme de pipeline o de dades. En un centre de dades, les GPU solen estar connectades amb interconnexions de molt baixa latència; en quatre miniordinadors, cada sincronització ha de creuar la xarxa.
El canvi resol un error conceptual, però en crea un d’infraestructura. El paral·lelisme tensorial pot sumar càlcul, però també exigeix molts intercanvis per cada token. Si cada viatge tarda massa, els acceleradors passen una part considerable del temps esperant.
El coll d’ampolla era la latència, no els gigabits
Ziskind havia instal·lat targetes i un commutador capaços de moure un volum enorme de dades. Les proves d’iperf confirmaven una amplada de banda alta, però la velocitat dels models gairebé no canviava. La mètrica impressionant no era la que governava la càrrega.
Una transferència llarga aprofita desenes o centenars de gigabits per segon. El paral·lelisme tensorial fa moltes operacions col·lectives petites i necessita que totes les parts arribin a temps. En aquest cas, pesa més el retard de cada anada i tornada que la quantitat màxima de dades que el cable pot transportar.
La solució és RDMA, accés directe a memòria remota. Aquesta tecnologia evita part del recorregut de la pila TCP i permet que les targetes moguin dades entre memòries amb menys intervenció de la CPU. La documentació d’RCCL d’AMD també situa RDMA i les interconnexions d’alta velocitat com a peces centrals de les comunicacions col·lectives entre nodes.
RDMA només funciona si tota la cadena és compatible
Activar RDMA no va ser marcar una casella. Ziskind va barrejar inicialment targetes i implementacions que no parlaven exactament el mateix llenguatge. Una combinació d’adaptadors Intel i Mellanox podia mostrar connectivitat, però no necessàriament oferir el camí de baixa latència que necessitava vLLM.
El muntatge exigia targetes compatibles, controladors correctes, permisos de memòria bloquejada i una configuració Linux coherent. llama.cpp pot negociar un transport RDMA quan troba libibverbs i una NIC RoCEv2 compatible, però la seva pròpia documentació avisa que el servidor RPC és fràgil i no s’ha d’exposar a una xarxa no fiable.
La lliçó és que «100 GbE» no descriu tot el sistema. El protocol, el controlador, el firmware, el commutador i la biblioteca col·lectiva han d’encaixar. Una sola conversió o ruta per TCP pot anul·lar l’avantatge del maquinari.
Kernel, ROCm i quantització: l’altre mig del problema
Quan la xarxa va deixar de ser el principal sospitós, encara quedaven models que es bloquejaven o no detectaven bé la GPU integrada. Algunes combinacions de models MoE i quantització AWQ no funcionaven en aquell entorn. El procés podia quedar aparentment actiu mentre els acceleradors no feien feina.
Ziskind va actualitzar el kernel de Linux i va utilitzar contenidors i eines preparats específicament per a Strix Halo i ROCm. Després del reinici, configuracions que abans quedaven penjades van començar a carregar. Per als models de mescla d’experts, va trobar més estabilitat amb quantització de pesos a quatre bits i activacions de setze bits.
Aquest detall evita una conclusió equivocada: no tot bloqueig d’un clúster és culpa de la xarxa. Una versió de kernel, un kernel de càlcul no implementat o un format de quantització incompatible poden produir el mateix símptoma extern —GPU inactiva i cap token— per causes completament diferents.
DeepSeek R1 i el resultat final
La prova culmina amb DeepSeek R1 de 671.000 milions de paràmetres en una quantització de quatre bits. Repartit entre els quatre nodes amb vLLM i el camí de comunicació afinat, el sistema arriba a uns 6,23 tokens per segon. Ziskind compara la dada amb els 5,94 tokens per segon d’una demostració del fabricant i calcula un avantatge pròxim al 5%.
No és una màquina especialment eficient: cada node consumeix aproximadament entre 180 i 187 watts sota càrrega i el conjunt genera molta calor. Tampoc tots els models escalen igual. Els models densos aprofiten millor l’augment de càlcul, mentre que en una mescla d’experts només una part dels paràmetres s’activa per token i la comunicació pot pesar més.
El valor de l’experiment no és derrotar una xifra comercial per unes dècimes. És mostrar una pila completament oberta capaç d’executar localment un model enorme i, sobretot, documentar per què tres mesos d’optimització apuntaven al lloc equivocat.
Què cal comprovar abans de construir un clúster local
El vídeo deixa un ordre de diagnòstic útil. Primer cal decidir si l’objectiu és fer cabre un model o augmentar-ne la velocitat: repartir pesos pot resoldre el primer sense millorar el segon. Després s’ha d’escollir el paral·lelisme adequat i mesurar separadament amplada de banda, latència i operacions col·lectives.
També convé validar un node abans d’afegir-ne més, mantenir homogènies les NIC i comprovar la compatibilitat entre kernel, ROCm, vLLM i quantització. Finalment, cal comparar tokens per segon, consum i estabilitat, no només la capacitat teòrica de la xarxa.
Quatre ordinadors amb molta memòria no formen automàticament un superordinador. El rendiment apareix quan càlcul, comunicació i programari treballen al mateix ritme; en aquesta mena de clúster, el microsegon pot importar més que el gigabit.
Contrast i context
Fonts consultades
- 01
- 02
-
03
llama.cpp RPC backend documentation
-
04
AMD ROCm vLLM inference and serving on ROCm
-
05
AMD ROCm RCCL Documentation
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
Four AMD Ryzen AI Max+ 395 machines, each with 128 GB of unified memory, should be an AI supercomputer on a desk. It took me more than three months to make the cluster work as fast as it finally did, largely because I was wrong about the problem. Across four Minisforum systems, the GPUs can use roughly 460 GB. My first attempt used Mesh LLM, but multi-node models crashed or failed to see the GPU.
-
2:14
, obre el vídeo en una pestanya nova
Donato Capitella’s Strix Halo toolboxes made llama.cpp with ROCm and Vulkan easy to deploy. Llama 3.1 405B ran across two nodes at only 1.2 tokens per second. The reason is that llama.cpp RPC uses pipeline parallelism: it lets a large model fit across machines, but every token still walks through them sequentially. What we needed was tensor parallelism, where every machine works on the same token at the same time.
-
4:29
, obre el vídeo en una pestanya nova
In the Python LLM ecosystem, tensor parallelism points to vLLM, although getting it to work across AMD integrated GPUs required effort. My original theory was simple: the cluster communicates over a network, so a faster network should make it faster. I installed high-bandwidth cards and confirmed the throughput with iperf, but model speed barely changed.
-
6:43
, obre el vídeo en una pestanya nova
With Llama 3.3 70B on two nodes, moving from one gigabit to faster links did not materially improve tokens per second. The bottleneck was latency, not bandwidth. Tensor parallelism requires several round trips per generated token, and TCP adds hundreds of microseconds. RDMA lets the network card write directly into remote memory and can reduce the round trip to roughly five microseconds.
-
8:58
, obre el vídeo en una pestanya nova
Donato’s vLLM toolboxes made RDMA possible on Strix Halo. Ubuntu did not cooperate, so I installed Fedora on every node. One Qwen 7B model ran at 15.5 tokens per second on a single machine. Connecting a second node over TCP raised that to 22.9, proving that tensor parallelism could finally make the cluster faster rather than merely increase memory.
-
11:13
, obre el vídeo en una pestanya nova
The first RDMA attempt mixed Intel E810 and Mellanox cards, which use incompatible implementations, and performance fell to 9.1 tokens per second. A matched Mellanox pair using RoCE v2 worked after setting memlock to unlimited and rebooting. Two-node speed reached 25.6 tokens per second, 65 percent above one node and 12 percent above TCP.
-
13:27
, obre el vídeo en una pestanya nova
Four nodes reached 38.3 tokens per second on dense Qwen 2.5 7B with RDMA, nearly two and a half times the single-node throughput. A Qwen 30B mixture-of-experts model scaled much less because it activates only three billion parameters per token. Active parameters, not the total model size, determine whether tensor parallelism is worth the communication overhead.
-
15:42
, obre el vídeo en una pestanya nova
DeepSeek R1 at four-bit AWQ occupied about 365 GB but hung after loading. Other AWQ models also failed at tensor parallel size four. A compressed-tensor W4A16 quantization, with four-bit weights and 16-bit activations, worked reliably on Qwen 30B. The failures showed that network tuning was only part of the problem; model architecture, quantization and kernel support also mattered.
-
17:56
, obre el vídeo en una pestanya nova
New Strix Halo images were compiled for a newer Linux kernel. Fedora 43 shipped with 6.17, so I updated to 6.19 and retested. Models that had previously hung began to run, including Gemma, Qwen, Llama 70B and even Llama 405B. That left DeepSeek R1, which finally loaded across all four nodes with W4A16 after a clean reboot.
-
20:11
, obre el vídeo en una pestanya nova
DeepSeek R1 activated 37 billion parameters per token, used about 99 percent of the available memory and drew roughly 180 to 187 watts per machine. It generated 4,058 tokens in ten minutes, or 6.23 tokens per second. Minisforum’s own four-node demonstration reported 5.94, so this open-source vLLM stack was about five percent faster. The stack is still early, and Linux support for the built-in Realtek network interface remains a weakness.
