Single-Node mit mehreren GPUs oder Multi-Node: wann sich Scale-out lohnt

Der teuerste Fehler beim Einkauf besteht darin, ein GPU-Budget auf zwei Knoten aufzuteilen, wo ein größerer Knoten die Aufgabe erledigt hätte. Der zweitteuerste ist, bei einem Knoten zu bleiben, obwohl der Workload wirklich ein Fabric braucht – und dann ein halbes Jahr so zu tun, als käme die Kiste mit.

Dieser Artikel liefert die Entscheidungslogik für genau diese Aufteilung: wann eine einzelne Box mit 8 GPUs die richtige Antwort ist, wann nicht und woran Sie erkennen, auf welcher Seite der Linie Ihr Workload liegt. Begleitartikel behandeln die Mechanik (K02 Training, K03 Inferenz, K07 PCIe-Grenzen, K06 Umgang mit Ausfällen); hier geht es um die Kaufentscheidung.

Die 8-GPU-Obergrenze, nach Modell

Die erste Frage lautet, ob das Modell in einen Knoten passt. Mit 8× RTX Pro 6000 Blackwell (je 96 GB) stehen 768 GB nutzbarer VRAM bereit, mit 8× RTX 5090 (je 32 GB) sind es 256 GB. Beides ist nach Maßstäben von 2026 nicht wenig, und beides fasst nicht alles.

Die Klippe liegt bei der 405B-/671B-Marke. Darunter reicht eine 8-GPU-Box mit Pro 6000. Ab dort quantisieren Sie entweder aggressiv (INT4-Gewichte – für Inferenz in Ordnung, fürs Training eine Qual) oder Sie überschreiten die Knotengrenze.

„Passt“ ist nicht dasselbe wie „läuft gut“. Ein Modell, das 95 % des VRAM belegt und keinen Spielraum für KV-Cache, Prefix-Cache, CUDA-Graphs oder Aktivierungsspeicher lässt, verdrängt unter realer Last Anfragen. Die Faustregel: Gewichte bei 60–70 % des VRAM, 30–40 % bleiben für alles andere. Unter dieser Bedingung passt 405B in FP8 für Inferenz bei brauchbarer Nebenläufigkeit nicht bequem auf 8× Pro 6000 – die Gewichte passen, der Workload nicht.

Wann Sie NICHT skalieren sollten

Fälle, in denen ein einzelner Knoten eindeutig richtig ist:

• Inferenz für jedes Modell, das hineinpasst. Wenn Modell plus KV bei der angestrebten Nebenläufigkeit passen, ist Multi-Node-TP über Ethernet oder InfiniBand grundsätzlich langsamer als ein einzelner Knoten. PCIe Gen5 innerhalb einer Box liefert ~50 GB/s zwischen GPUs am selben Switch; 200 Gbit/s InfiniBand zwischen Knoten liefern ~25 GB/s. Ein Workload, der auf PCIe schon schleicht, kriecht über IB.
• Produktives Serving für einen einzelnen Mandanten. Ein Modell, ein Kunde, moderate Nebenläufigkeit. Eine 8-GPU-Box mit Pro 6000 bedient 70B mit 32–64 parallelen Anfragen problemlos. Eine zweite Box taugt nur als Hot Spare oder zur Verdopplung des Durchsatzes per Data Parallelism – beides ist kein „Scale-out“ im eng gekoppelten Sinn.
• Forschungslabore mit Modellen von 7B bis 72B. Die meiste akademische und angewandte Arbeit liegt 2026 genau hier – Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma und der Schwanz der 70B-Feinabstimmungen. Nichts davon braucht mehr als einen Knoten.
• LoRA-/QLoRA-Feinabstimmung. Der Sinn von PEFT ist gerade, dass Sie keine Ressourcen für ein Full-Model-Training brauchen. 70B mit LoRA passt auf 4–8 GPUs in einem Knoten; 405B mit QLoRA passt auf 8× Pro 6000.
• Batch-Inferenz und Offline-Workloads. Wenn das SLA lautet „dieses Korpus bis Freitag verarbeiten“, erledigt das Batching im Durchsatzmodus auf einer 8-GPU-Box. Multi-Node hilft nur, wenn Sie es zeitlich nicht schaffen – und das liegt meist daran, dass das Modell zu groß ist, nicht daran, dass ein Knoten zu langsam wäre.

Rund 80 % der Kentino-Kunden sollten einen größeren Knoten statt zwei kleinerer kaufen, und die meisten der verbleibenden 20 % wollen eigentlich datenparallele Replikate hinter einem Load Balancer, keinen Cluster.

Wann Sie skalieren MÜSSEN

Die Fälle, in denen ein Knoten wirklich nicht reicht, sind seltener, als viele annehmen.

Ein Modell ab 70B von Grund auf trainieren. Acht GPUs reichen bei der Laufzeit nicht. Ein 70B-Pretraining mit den veröffentlichten Token-Budgets (1.5–15T) verschlingt Hunderte GPU-Monate auf Hardware der H100-Klasse, auf PCIe-Consumer-GPUs noch mehr. Dafür brauchen Sie 32–128+ GPUs und ein SXM-Fabric. Diese Klasse baut Kentino nicht.

Vollständige Feinabstimmung ab 70B. Nicht LoRA, sondern echtes Full-Fine-Tuning mit Optimizer-States, Gradienten und Aktivierungen im Speicher. Eine vollständige 70B-Feinabstimmung (FP16-Gewichte + FP32-Adam + Gradienten + Aktivierungen) umfasst 1.2–1.5 TB Zustand – selbst mit FSDP mehr, als ein 8-GPU-Knoten fasst. Das rechtfertigt einen IB-Cluster aus 2–4 Knoten.

405B+ mit Produktionslatenz hosten. Die Gewichte passen in INT4 auf 8× Pro 6000, aber KV-Cache plus paralleles Serving bei brauchbarer Latenz treibt Sie auf zwei oder mehr Knoten. Zwei 8-GPU-Boxen mit Pro 6000 in TP=8 × PP=2 oder TP=4 × PP=4 sind das realistische Minimum für Llama 3.1 405B bei ordentlichem QPS. K03 geht darauf im Detail ein.

Produktiver Mehrmandantenbetrieb über >100k QPS gesamt. Ein 8-GPU-Knoten liefert bei 70B in FP8 aggregiert 500–2,000 Token/s. Jenseits von Zehntausenden QPS wollen Sie mehrere Replikate, und darüber hinaus einen echten Cluster mit Router und Prefix-Cache-bewusstem Routing. Die richtige Antwort lautet meist: viele datenparallele Replikate, kein einzelner riesiger TP-Cluster.

Außerhalb dieser vier Fälle wird die Argumentation schnell dünn. Die meisten „Ich brauche Multi-Node“-Aussagen entpuppen sich als „Ich will mehr Durchsatz“ – eine Frage der Replikate, nicht des Fabrics.

Der Sweet Spot für einen einzelnen Knoten

So sieht ein starker Einzelknoten aus, auf Hardware, die Kentino tatsächlich ausliefert:

Die entscheidende Einschränkung: Diese Karten haben kein NVLink. RTX 5090, RTX Pro 6000 Blackwell, L40 und L4 sind PCIe-angebunden. SXM-Module mit NVLink-Fabric (H100 SXM, B200 SXM, GB200) verlangen HGX-Baseboards, die wir nicht bauen. K07 behandelt die Kosten, N03 erklärt, wann NVLink wirklich zählt.

Der PCIe-Weg ist richtig für inferenzlastige Arbeit und für das meiste Training unterhalb der Spitzenklasse. Beim Batching im Durchsatzmodus amortisiert sich der Aufwand für All-Reduce in der Inferenz. Bei der Feinabstimmung von Modellen fester Größe liegt der Laufzeitnachteil gegenüber SXM bei 1.2–1.4× – in der Regel akzeptabel. Beim tensorparallelen Training ab 70B von Grund auf sind es 2–3×, und dann lautet die Antwort: „SXM kaufen oder diese Arbeit nicht auf Kentino-Hardware machen“.

Die Klippe zwischen einem Knoten und mehreren

Was Multi-Node zu einer anderen Kategorie von System macht, ist der Bruch beim Interconnect zwischen Knoten-intern und Knoten-übergreifend – bei Bandbreite wie bei Latenz.

Innerhalb einer Box reden zwei GPUs mit ~50 GB/s und Hops unterhalb einer Mikrosekunde. Knotenübergreifend bleiben ~25 GB/s auf 200-Gbit/s-IB – ein Faktor 2 auf IB, 4–5 auf 100 GbE, 15 auf 25 GbE. Für TP-Kollektive, die in jeder Transformer-Schicht feuern, tut das richtig weh. K07 enthält die Zeittabelle für All-Reduce.

Die Latenz verstärkt das Ganze: knotenübergreifend sind es 5–15 Mikrosekunden auf getuntem RoCE gegenüber Nanosekunden innerhalb einer Box. Für Training und Prefill fällt das nicht ins Gewicht, für latenzsensible interaktive Inferenz mit engem TP sehr wohl.

Genau wegen dieser Klippe ist „einfach noch eine Box dazustellen“ keine stufenlose Entscheidung. Was innerhalb eines Knotens auf PCIe gerade so überlebt, überlebt zwischen Knoten auf Ethernet oder IB nicht.

Strong Scaling: wo die Rechnung kippt

Amdahls Gesetz: Der Speedup ist durch den seriellen Anteil des Workloads begrenzt, und beim verteilten Training ist dieser Anteil der Kommunikations-Overhead. Für einen Trainingsschritt der 70B-Klasse auf PCIe-Hardware der Kentino-Klasse sieht die Skalierungseffizienz (Durchsatz pro GPU gegenüber der Einzel-GPU-Basis) über die von uns ausgelieferten Builds so aus:

Zwei Erkenntnisse. Erstens: Einen 8-GPU-Job auf zwei 4-GPU-Knoten aufzuteilen ist schlechter, als ihn in einer Box laufen zu lassen – jedes knotenübergreifende Fabric ist langsamer als das PCIe in der Box, die Sie ohnehin schon hatten. Zweitens: Datenparallelität skaliert über ein Fabric deutlich besser als Tensorparallelität. Wenn Ihre eigentliche Frage lautet „Kann ich mehr Anfragen bedienen?“ und nicht „Kann ich ein größeres Modell schneller rechnen?“, funktionieren DP-Replikate – und zwar über handelsübliches 100 GbE.

Fällt die prognostizierte Effizienz unter 60 %, hat der Workload für Multi-Node auf Standard-Fabric das falsche Profil. Bauen Sie die Architektur um (TP innerhalb eines Knotens, PP oder DP darüber hinweg), kaufen Sie einen größeren Einzelknoten oder Hardware der SXM-Klasse. Rohe Gewalt hilft hier nicht.

Die Forschungslabor-Falle und die operative Steuer

Ein Muster, das wir oft genug sehen, um es zu benennen: Ein Labor plant „für die Zukunft“ und bestellt zwei 4-GPU-Knoten statt eines 8-GPU-Knotens. Was dabei herauskommt, ist schlechteres Training (0.65× bei knotenübergreifendem TP gegenüber 0.73× knotenintern), schlechtere Inferenz für jedes Modell, das in eine Box gepasst hätte, doppelter Betriebsaufwand (zwei BMCs, zwei NIC-Tunings, zwei Treiberstände, zwei Fehlerdomänen) – und nach der zweiten NIC, dem zweiten Netzteil und dem Switch-Upgrade ungefähr dieselben Materialkosten. Kaufen Sie zuerst einen 8-GPU-Knoten.

Multi-Node ist, wenn es denn die richtige Antwort ist, nicht umsonst. Die zusätzliche Steuer:

• Gemeinsamer Storage – lokaler NVMe reicht nicht mehr. NFS, BeeGFS oder Lustre, dazu ein Storage-VLAN (K04).
• Asynchrone, geshardete Checkpoints – synchrone, ungeshardete Schreibvorgänge auf NFS legen den Cluster lahm. PyTorch DCP oder NeMo sind Pflicht, nicht Kür.
• NIC- und NCCL-Tuning – RoCE-Flusskontrolle, PFC, ECN, Jumbo Frames, Wahl des NCCL-Transports, Topologiedateien, Ring- oder Tree-Algorithmen. Jeder einzelne Parameter steht ab Werk falsch.
• Monitoring – DCGM pro Knoten, Prometheus-Föderation, NCCL-Trace-Puffer.
• Umgang mit Ausfällen – Knoten fallen weg, NICs setzen zurück, Switch-Ports flappen. K06 beschreibt die Fehlerbilder; die Ausfallraten im Multi-Node-Betrieb liegen ungefähr beim N-Fachen eines Einzelknotens, und die Wiederherstellung ist unangenehmer.

In Engineering-Zeit kostet Multi-Node pro zusätzlichem Knoten das 4–5-Fache. Planen Sie das ein – oder nehmen Sie in Kauf, dass der Cluster sein erstes halbes Jahr bei der Hälfte der theoretischen Leistung verbringt.

Der konkrete Entscheidungsweg

Arbeiten Sie die Punkte der Reihe nach ab. Das erste „Ja“ beendet die Diskussion.

1. Passt das Modell in 8× 96 GB bei FP8 mit 30–40 % VRAM-Reserve für KV? Wenn ja: ein Knoten, fertig.
2. Passt es bei INT4 mit derselben Reserve? Wenn ja und Sie machen Inferenz (kein Training), ist ein Knoten mit INT4 die Antwort. Für den Gradientenpfad des Trainings sind INT4-Gewichte nicht brauchbar – lesen Sie weiter.
3. Ist der Workload durchsatzgebunden statt modellgrößengebunden? Wenn ja, lautet die Antwort: datenparallele Replikate von Einzelknoten-Konfigurationen, kein Cluster. Zwei Boxen hinter einem Load Balancer, kein Fabric nötig.
4. Ist der Workload tensorparalleles Training eines Modells, das nicht in einen Knoten passt? Multi-Node mit InfiniBand. Schätzen Sie die Skalierungseffizienz anhand der Tabelle in K07. Unter 60 % bauen Sie die Architektur um (TP intern, PP übergreifend) oder reduzieren die Knotenzahl und akzeptieren die längere Laufzeit.
5. Ist der Workload das Pretraining eines Modells ab 70B von Grund auf? Der Fall an der Spitze. Multi-Node mit NDR-IB oder SXM. Kentino kann die IB-Seite bauen, aber die meisten Kunden, die so fragen, müssen diese Arbeit gar nicht selbst machen.

Die Schritte eins und zwei decken den Großteil des Marktes ab. Schritt drei heißt, dass Sie gut wachsen – die Antwort sind Replikate, kein Cluster. Die Schritte vier und fünf sind real, aber selten.

Ehrliche Einschätzung

Multi-Node ist an der Spitze richtig – Training ab 70B von Grund auf, Inferenz ab 405B mit Produktionslatenz, Serving im Hyperscale-Bereich über 100k QPS oder Forschung, die auf einen Tagesdurchsatz angewiesen ist, den eine Box nicht liefert. Das sind reale Workloads. Sie sind nur nicht das, was üblicherweise gebaut wird.

Für alles andere ist ein gut spezifizierter 8-GPU-Knoten die Antwort. Er fährt jeden Inferenz-Workload mit offenen Gewichten von 2026, der in 768 GB bei FP8/INT4 passt, LoRA und QLoRA bis 405B, vollständige Feinabstimmungen der 13B-Klasse ohne Murren – und er skaliert für mehr Durchsatz auf zwei oder drei DP-Replikate ganz ohne Cluster-Fabric. Dazu ist er im Betrieb dramatisch einfacher.

So läuft das Gespräch mit den meisten Kunden: Workload beschreiben, die Passrechnung machen, die Skalierungseffizienz abschätzen. Ergibt die Prognose einen Cluster, bauen wir einen Cluster. Ergibt sie einen Knoten, bauen wir einen Knoten. Ergibt sie zwei Replikate hinter einem Router, bauen wir das. Wir verkaufen nicht die größte Konfiguration, die Sie sich gefallen lassen – wir verkaufen die, die am Ende funktioniert.

---

Dieser Beitrag ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Computing, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen gerne an info@kentino.com.