Verteiltes Training auf heterogener Hardware stößt auf einen zentralen Engpass, den die meisten Frameworks so behandeln, als gäbe es ihn nicht: unterschiedliche Knotengeschwindigkeiten.

Das eigentliche Problem ist nicht nur, dass „langsame Knoten länger brauchen“ – ein einzelner langsamer Knoten wird zur Synchronisationsbarriere und legt dadurch den gesamten Cluster lahm. Deine schnellen GPUs verbrauchen Strom, während sie darauf warten, dass irgendein CPU-gebundener Knoten seine Gradientenberechnung abschließt.

Das ist das Straggler-Problem im großen Maßstab. Beim synchronen Training bist du nur so schnell wie dein langsamster Worker. Wenn du eine Mischung aus A100s, V100s und beliebiger übriger Hardware hast, die du zusammenkratzen konntest, bricht der Trainingsdurchsatz auf den kleinsten gemeinsamen Nenner ein.

Die meisten Frameworks für verteiltes Training (PyTorch DDP, Horovox) gehen von homogenen Clustern aus, weil große Forschungslabore eben solche Cluster haben. In der realen Welt – besonders in dezentralen Rechennetzwerken – ist heterogene Hardware jedoch der Normalfall, nicht die Ausnahme.

Die Rechenverschwendung ist enorm: Wenn dein langsamster Knoten doppelt so lange braucht, sind alle anderen Knoten zu 50 % ungenutzt. Bei Dutzenden von Knoten verbrennst du so Geld für Rechenleistung, die keinerlei Gradientenaktualisierungen hervorbringt.

Es gibt Lösungen (asynchrones SGD, Umgang mit veralteten Gradienten, adaptives Batching), doch sie bringen Konvergenzprobleme und zusätzliche Implementierungskomplexität mit sich. Der Kompromiss zwischen Synchronisationsgenauigkeit und asynchroner Effizienz ist nach wie vor eine offene Forschungsfrage.