DGX Spark im Cluster: drei Geräte ohne Switch, ab vier mit

5. Aug 2026 Deutsch 17 Min. Lesezeit Auch auf: English, Español

nvidia-dgx-spark lokale-ki hardware

Auf X kursiert seit dem 4. August ein kurzer Ratgeber zur Switch-Wahl für DGX-Spark-Cluster. Er nennt drei MikroTik-Modelle und geht davon aus, dass ab mehr als drei Geräten ein Switch fällig wird. Das trifft den Kern, lässt aber die Frage offen, die für einen Betrieb zuerst zählt: Was genau ändert sich zwischen zwei, drei und vier Geräten, und was bekommt man für das Geld überhaupt.

Wir haben Ende Juni zwei DGX Spark Schritt für Schritt zu einem Cluster verkabelt. Dieser Beitrag setzt darüber an: drei Geräte, vier Geräte, acht Geräte, dazu die Gegenprobe gegen einen Mac Studio und am Ende ein durchgerechnetes Beispiel mit 25 gleichzeitigen Nutzern.

Was NVIDIA offiziell unterstützt

Die verbindliche Auskunft steht nicht in einem Forenbeitrag, sondern im Cluster-Assistenten von NVIDIA Sync. Er deckt zwei bis maximal vier DGX Spark ab und beschreibt drei Wege:

Zwei Geräte: ein Kabel, direkt von Port zu Port.
Drei Geräte: drei Kabel als Ring, jedes Gerät ist mit den beiden anderen verbunden.
Vier Geräte: ein Kabel je Gerät, über einen Switch. Vier Geräte verlangen einen Switch.

Dazu eine Regel, die man leicht überliest: nicht mischen. Entweder alle Geräte direkt verkabeln oder alle über den Switch. Ein Cluster aus zwei direkt verbundenen Geräten plus einem dritten am Switch ist nicht vorgesehen.

Wer über vier Geräte hinaus will, verlässt den Bereich, den dieses Werkzeug abdeckt. Technisch spricht nichts dagegen, es bleibt gewöhnliches Ethernet mit RoCE, aber die geführte Einrichtung endet dort, und damit auch der bequeme Weg zurück, wenn etwas klemmt.

Drei Geräte sind der ruhige Punkt

Drei DGX Spark ergeben 384 GB gemeinsamen Speicher, brauchen drei Kabel und kein zusätzliches Gerät im Schrank. Kein Switch heißt: keine zweite Firmware, kein zweites Netzteil, kein weiteres Teil, das nachts ausfallen kann. Für ein Modell, das in 128 GB nicht passt, in 384 GB aber schon, ist das die einfachste Bauform, die es gibt.

Die Rechnung dahinter sollte man trotzdem kennen. Ein Gerät hat insgesamt rund 200 Gbit pro Sekunde, verteilt auf zwei PCIe-Gen5-x4-Strecken. Im Ring teilen sich zwei Nachbarn dieses Budget. Zwischen zwei direkt verbundenen Geräten steht es einer einzigen Verbindung zur Verfügung, im Ring eben nicht. Planen Sie deshalb pro Nachbar mit ungefähr der Hälfte dessen, was das Zwei-Geräte-Paar liefert. NVIDIA veröffentlicht für den Ring keine eigenen Durchsatzwerte, hier hilft nur die eigene Messung.

Die 200 Gbit, die kein einzelner Datenstrom sieht

Das ist der Teil, an dem in der Praxis die meiste Zeit verbrannt wird, und er verdient mehr als einen Halbsatz.

ServeTheHome hat den Aufbau vermessen und beschreibt ihn als ungewöhnlich für eine 200GbE-Anbindung: Hinter den QSFP-Buchsen sitzen zwei 100-Gbit-MACs auf zwei getrennten PCIe-Gen5-x4-Strecken. Gemessen wurden je Strecke 92 bis 98 Gbit pro Sekunde mit RoCE, zusammen rund 190. Mit Jumbo Frames und 60 bis 64 parallelen Strömen kamen je nach Richtung 160 bis 198 Gbit pro Sekunde heraus. Die Zahl auf dem Karton ist also erreichbar, aber sie ist eine Summe, kein Wert, den eine einzelne Verbindung sieht.

Ein Praxisbericht im NVIDIA-Entwicklerforum zeigt denselben Effekt aus der anderen Richtung. Dort läuft ein Cluster aus vier Geräten an einem MikroTik CRS812 mit Breakout-Kabeln. Anfangs kam ein einzelner TCP-Strom auf rund 30 Gbit pro Sekunde, parallel waren es etwa 106, obwohl die Verbindung mit 200GbE ausgehandelt war. Erst als der Betreiber erkannte, dass der eine Port als zwei logische Schnittstellen erscheint und beide bespielt werden müssen, dazu MTU 9000 setzte und IPv6 abschaltete, standen rund 196 bis 198 Gbit pro Sekunde je Geräte-Paar. Ein NCCL-Test lieferte danach etwa 23,76 GB pro Sekunde Bus-Bandbreite. Nebenbei fand er einen alten Eintrag NCCLIBDISABLE=1 in der Konfiguration, der RDMA vollständig blockierte.

Daraus folgen vier Punkte für die Praxis.

Ein einzelner Datenstrom endet bei etwa 100 Gbit pro Sekunde. Das ist keine Fehlkonfiguration, das ist die Bauform. Wer mit iperf3 ohne Parallelität misst, sieht die Hälfte und sucht danach tagelang einen Fehler, den es nicht gibt.

Die beworbene Zahl setzt Parallelität voraus. Beide logischen Schnittstellen müssen Verkehr tragen, sonst liegt eine der beiden PCIe-Strecken brach. Bei verteilter Inferenz erledigt das NCCL, wenn es richtig eingerichtet ist. Bei jedem selbstgebauten Datentransfer erledigt es niemand.

Ein Kabel mehr erhöht das Budget des Geräts nicht. Die zweite Buchse verteilt es nur anders. Deshalb ist die zweite Buchse für Topologie da, nicht für Tempo, und deshalb halbiert der Ring die Bandbreite je Nachbar.

Messen Sie drei Werte, bevor ein Modell auf die Maschine kommt. Erstens iperf3 mit einem einzigen Strom, das ist Ihre Untergrenze. Zweitens iperf3 mit mehreren parallelen Strömen und MTU 9000, das ist Ihre Obergrenze. Drittens einen NCCL-Test über alle Knoten, denn nur der zeigt, ob RDMA wirklich läuft. Eine Verbindung, die im Datenblatt 200 sagt und im ersten Test 30 liefert, ist der Normalzustand vor der Konfiguration, kein Defekt.

Ab vier Geräten: welcher Switch

Hier ist der Ratgeber auf X nützlich, weil er die drei Modelle richtig einordnet. Wir haben die Angaben gegen die Herstellerseiten geprüft.

MikroTik CRS504-4XQ-IN, vier Ports mit 100 Gbit, im Handel je nach Anbieter rund 640 bis 780 US-Dollar. Vier Ports heißen vier Geräte, das ist exakt die Obergrenze des offiziellen Cluster-Assistenten. Der Ratgeber nennt nach Nutzerberichten rund 98 Prozent der Leistung deutlich teurerer Switches. Diese Zahl ist unbestätigt, aber sie ist plausibel: Wenn ein einzelner Strom ohnehin bei 100 Gbit endet, kostet ein 100-Gbit-Port weniger Leistung, als das Datenblatt vermuten lässt.

MikroTik CRS804-4DDQ-hRM, vier Ports mit 400 Gbit im Format QSFP56-DD, Listenpreis 1.295 US-Dollar. Acht native 200-Gbit-Ports hat das Gerät nicht. Man teilt jeden 400er per Breakout-Kabel in zwei 200er, vier mal zwei ergibt acht Geräte. Das ist der sauberste Weg, wenn acht Geräte das Ziel sind.

MikroTik CRS812-8DS-2DQ-2DDQ-RM, ebenfalls 1.295 US-Dollar, mit zwei 400-Gbit-Ports, zwei nativen 200-Gbit-Ports und acht Ports mit 50 Gbit. Zwei mal Breakout ergibt vier 200-Gbit-Strecken, plus die beiden nativen Ports sind das sechs Geräte mit voller Anbindung. Für acht teilt man einen der 400er stattdessen in vier mal 100 Gbit, dann hängen vier Geräte mit 200 und vier mit 100 Gbit am Switch. Genau dieses Gerät steht im oben verlinkten Praxisbericht, der Weg ist also im Feld erprobt.

Eine Korrektur in eigener Sache: In unserer Juni-Anleitung stand der CRS504 als 200GbE-Switch für vier bis acht Geräte. Beides war ungenau. Er hat vier Ports mit 100 Gbit, damit sind vier Geräte die Grenze. Wir haben die Stelle korrigiert.

Was ein Cluster wirklich kauft: Speicher, nicht Tempo

Die wichtigste Zahl steht nicht im Datenblatt eines Switches. StorageReview hat einen Zwei-Geräte-Cluster mit verteilter Inferenz vermessen und kommt bei GPT-OSS-120B auf rund 464 bis 505 Token pro Sekunde je nach Hersteller des Geräts. Die Einordnung dort ist deutlich: Ein Cluster bringt vor allem Speicherkapazität, nicht Durchsatz, und die Verbindung zwischen den Geräten bleibt der begrenzende Faktor.

Der Grund liegt in der Arbeitsteilung. Beim üblichen Verfahren, der Pipeline-Parallelität, bekommt jedes Gerät einen Teil der Schichten. Jedes Token läuft dann durch alle Geräte, und zwar nacheinander. Die Verbindung liegt damit im Weg jedes einzelnen Tokens, nicht nur beim Laden des Modells. Große Stapel verdecken diesen Aufschlag teilweise, weil die Pipeline gefüllt bleibt, aber sie schaffen ihn nicht ab. Zwei Geräte verdoppeln den Speicher, nicht den Durchsatz.

Bei Mixture-of-Experts-Modellen kommt eine zweite Eigenheit dazu, die gern übersehen wird. MoE spart Rechenaufwand, nicht Speicher. Bei Gemma 4 26B sind zwar nur vier Milliarden Parameter je Token aktiv, aber alle 26 Milliarden müssen im Speicher liegen, weil der Router vorher nicht weiß, welche der 128 Experten das nächste Token braucht. Google schreibt das in der Modellübersicht selbst so. Und bei vielen gleichzeitigen Nutzern schrumpft auch der Rechenvorteil: Jeder Nutzer trifft andere Experten, über einen Stapel von 25 Anfragen ist die Vereinigung der angesprochenen Experten deutlich größer als bei einer einzelnen. Der Speicherverkehr nähert sich also genau dann dem vollen Modell an, wenn viele Leute gleichzeitig arbeiten.

Das ändert die Kaufentscheidung. Ein DGX Spark kostet seit Februar 2026 laut Hersteller 4.699 US-Dollar statt vorher 3.999. Drei Geräte sind also gut 14.000 US-Dollar plus Kabel, bevor eine einzige Anfrage beantwortet ist. Wer diese Summe ausgibt, um ein Modell schneller zu machen, das bereits in 128 GB läuft, kauft am Ziel vorbei. Die Frage lautet immer zuerst: Passt das Modell, das wir wirklich brauchen, in ein Gerät? Wenn ja, ist der zweite Kasten falsch investiert. Wenn nein, ist der Cluster nicht Luxus, sondern die Voraussetzung dafür, dass es überhaupt lokal läuft.

Gegenprobe: Mac Studio Max und Ultra

Für lokale Inferenz war der Mac Studio bisher die naheliegende Alternative, und auf dem Papier hat er ein starkes Argument. Ein M4 Max liegt bei rund 546 GB pro Sekunde Speicherbandbreite, ein M3 Ultra bei rund 819. Der DGX Spark kommt auf rund 273. Bei einem einzelnen Nutzer, der auf seine Antwort wartet, schlägt genau diese Zahl in Token pro Sekunde durch. Wir haben das im Juli im direkten Vergleich beider Geräte beschrieben, und daran hat sich technisch nichts geändert.

Am Markt hat sich dagegen sehr viel geändert. Wegen der Knappheit bei Speicherbausteinen hat Apple die großen Ausbaustufen gestrichen: erst die 512 GB im März 2026, dann auch 128 und 256 GB. Aktuell lässt sich ein Mac Studio mit M3 Ultra nur noch mit 96 GB bestellen, ab 3.999 US-Dollar, und Macworld nennt 13 bis 14 Wochen Lieferzeit, bei den großen Händlern ist kein Lagerbestand. Ein DGX Spark mit 128 GB ist lieferbar. Das ist kein technisches Argument, aber es ist das Argument, das ein Projekt im dritten Quartal entscheidet.

Für einen Mac-Cluster gilt zusätzlich die Verbindungsfrage. Apple verbindet seine Geräte über Thunderbolt 5, seit macOS Tahoe 26.2 mit RDMA über JACCL, in unseren Messungen und denen der Community sind das 50 bis 60 Gbit pro Sekunde. Drei Mac Studio mit je 96 GB ergeben zwar 288 GB, aber auf etwa einem Drittel der Verbindungsbandbreite, die zwei DGX Spark untereinander haben. Und weil ein Cluster ohnehin vor allem Speicher kauft, ist das genau die Stelle, an der es weh tut.

Bleibt die Software. Für einen einzelnen Nutzer ist MLX ausgereift und schnell. Für viele gleichzeitige Nutzer fehlt dem MLX-Stack bis heute ein Gegenstück zu PagedAttention und zur Anfrageplanung von vLLM. Eine Arbeit zu Inferenz im großen Maßstab auf Apple Silicon misst auf einem M4 Max mit 128 GB bei Qwen3-8B den Faktor 2,6 zwischen einer und 16 gleichzeitigen Anfragen und benennt für größere Modelle die Sättigung der Speicherbandbreite als Grenze. Das ist ordentlich, aber es ist nicht die Skalierung, die ein CUDA-Stack mit kontinuierlichem Batching liefert.

Kurz gefasst: Ein Nutzer, lange Antworten, kein Feintuning, das ist Mac-Gelände, sofern man auf die Lieferung warten kann. Viele Nutzer, lange Eingaben, Feintuning oder eine Linux-Produktionsumgebung, das ist Spark-Gelände.

Rechenbeispiel: Gemma 4 26B MoE für 25 gleichzeitige Nutzer

Machen wir es konkret, weil abstrakte Empfehlungen an dieser Stelle nichts wert sind.

Gemma 4 26B A4B hat 26 Milliarden Parameter, aktiviert vier davon je Token, verteilt auf 128 Experten, und arbeitet mit 256K Kontext. Google gibt den Speicherbedarf der Gewichte offiziell mit 57,7 GB in BF16, 28,8 GB in 8 Bit und 14,4 GB in 4 Bit an.

Damit ist die Cluster-Frage schon beantwortet. In BF16 belegt das Modell auf einem einzigen DGX Spark gut 58 der 128 GB. Es bleiben rund 70 GB für KV-Cache, Aktivierungen und Betriebssystem, und der KV-Cache ist bei 25 Sitzungen der Posten, der wirklich zählt. Für dieses Modell und diese Nutzerzahl brauchen Sie keinen zweiten Kasten, keinen dritten und erst recht keinen Switch. In 8 Bit passt es mit weitem Abstand, dann bleibt Platz für längere Kontexte oder ein zweites Modell daneben.

Auf einem Mac Studio mit den heute bestellbaren 96 GB passt BF16 ebenfalls, aber der Abstand ist knapp: macOS reserviert einen Teil des gemeinsamen Speichers, und 25 Sitzungen mit langem Kontext fressen genau den Rest. Hier ist 8 Bit nicht eine Option, sondern die vernünftige Einstellung.

Für die 25 Nutzer entscheiden dann drei Dinge, und Bandbreite ist nur eines davon.

Die Prompt-Verarbeitung. 25 Nutzer, die je eine Seite Kontext oder einen RAG-Auszug schicken, erzeugen vor allem Rechenlast, nicht Speicherverkehr. Das ist die Disziplin, in der die Blackwell-GPU des Spark ihren Vorsprung hat und die Bandbreite des Mac wenig hilft.

Die Verwaltung des KV-Caches. 25 Sitzungen bedeuten 25 wachsende Caches mit unterschiedlicher Länge und Lebensdauer. Genau dafür gibt es PagedAttention. Ohne ein Gegenstück dazu endet der Cluster nicht in schlechten Zahlen, sondern in abgewiesenen Anfragen, sobald der Speicher fragmentiert.

Der Experten-Effekt von oben. Bei Stapelgröße 25 nähert sich der Speicherverkehr dem vollen Modell an, der Vorteil der vier aktiven Milliarden schrumpft. Wer seine Auslegung auf dem Wert für einen einzelnen Nutzer aufbaut, plant zu knapp.

Die Empfehlung für diesen Fall lautet deshalb: ein DGX Spark, Gewichte in 8 Bit, vLLM mit kontinuierlichem Batching, und die Abnahmemessung mit 25 parallelen Anfragen statt mit einer. Reicht ein Gerät der Last nicht, folgt daraus trotzdem kein Cluster, sondern eine zweite Kopie daneben. Warum, steht im nächsten Abschnitt.

Eine ehrliche Einschränkung dazu: Die Speicherzahlen sind offiziell, die Schlussfolgerung daraus ist Arithmetik. Eine veröffentlichte Messung genau dieser Kombination, Gemma 4 26B auf DGX Spark bei 25 gleichzeitigen Nutzern, kennen wir nicht. Was Ihre Prompts, Ihre Kontextlängen und Ihr Antwortverhalten daraus machen, zeigt nur ein Testlauf mit Ihren echten Anfragen.

Drei Geräte parallel statt im Cluster

Wenn das Modell in ein Gerät passt und trotzdem mehr Last kommt, ist die richtige Antwort nicht der Cluster, sondern die Kopie. Das sind zwei Bauformen für zwei verschiedene Probleme, und sie werden regelmäßig verwechselt.

Cluster mit Pipeline-Parallelität löst: Das Modell passt nicht in ein Gerät. Der Speicher wird zusammengelegt, jedes Token läuft nacheinander durch alle Knoten, Durchsatz gewinnt man dabei nicht, und fällt ein Knoten aus, steht der ganze Verbund.

Repliken hinter einem Router lösen: Das Modell passt, aber die Last passt nicht. Jedes Gerät hält das vollständige Modell und beantwortet Anfragen unabhängig von den anderen. Der Durchsatz wächst nahezu linear mit der Zahl der Geräte, ein Ausfall kostet ein Drittel der Kapazität statt aller, und Aktualisierungen lassen sich nacheinander fahren, ohne den Dienst anzuhalten.

Für Gemma 4 26B bei 25 Nutzern ist die zweite Bauform die richtige, sobald ein Gerät nicht mehr reicht. Sie braucht keinen Switch für 100 oder 400 Gbit, kein QSFP-Kabel und kein NCCL. Zwischen Repliken fließen nur Anfragen und Antworten, keine Zwischenergebnisse, dafür genügt das gewöhnliche Firmennetz.

LiteLLM ist dafür die naheliegende Schicht: ein OpenAI-kompatibler Endpunkt vorne, drei vLLM-Instanzen dahinter, dazu Verteilstrategien wie least-busy oder latenzbasiert, automatische Rückfallketten, wenn eine Instanz nicht antwortet, und Schlüssel, Budgets und Kostenzuordnung je Team. Das ist ohnehin die Infrastruktur, die ein Betrieb für lokale Modelle braucht, unabhängig von der Zahl der Geräte.

Ein Detail dabei kostet leicht viel Rechenzeit, und es steht in keiner Kabelliste: Reihumverteilung zerstört die Wiederverwendung des Prefix-Caches. Wenn 25 Nutzer denselben langen System-Prompt oder denselben RAG-Kontext schicken, soll dieselbe Sitzung immer auf demselben Gerät landen, sonst wird derselbe Präfix auf jedem Gerät neu verarbeitet. Der Router des vLLM-Produktionsstapels beherrscht genau das, sitzungsbasiert, prefix-bewusst und KV-Cache-bewusst. Bei kurzen, verschiedenartigen Anfragen ist das gleichgültig. Bei langen gemeinsamen Präfixen ist es der Unterschied zwischen einmal und fünfundzwanzig Mal Vorverarbeitung.

Oft ist die zweite Maschine ohnehin kein Zwilling, sondern trägt ein anderes Modell, Einbettungen, einen Reranker oder ein Coding-Modell. Dann verteilt LiteLLM nach Modellnamen statt nach Last, und der Cluster war nie die Frage.

Arbeitsplätze sind nicht gleichzeitige Anfragen

Bevor irgendetwas bestellt wird, muss eine Zahl geklärt sein, und sie wird ständig verwechselt: 25 Arbeitsplätze und 25 gleichzeitig in der Maschine liegende Anfragen sind zwei völlig verschiedene Dinge.

Als Faustwert sind zur Spitzenzeit drei bis acht Prozent der Sitzplätze gleichzeitig in Bearbeitung. 25 Arbeitsplätze ergeben damit ein bis zwei parallele Anfragen, da genügt ein Gerät mit großem Abstand. 500 Arbeitsplätze ergeben grob 15 bis 40, und 25 gleichzeitige Anfragen sind für eine Belegschaft dieser Größe ein realistischer Auslegungspunkt. Genau dieser Fall verlangt eine andere Planung.

Drei Anforderungen kommen bei 500 Sitzplätzen dazu, die bei 25 keine Rolle spielen. Spitzen: Montagmorgen, eine Rundmail, ein Stapeljob, der jemand nachts angestoßen hat. Wer auf den Mittelwert auslegt, produziert die Warteschlange genau dann, wenn sie alle sehen. Ausfallsicherheit: 500 Menschen an einem Gerät sind ein einzelner Fehlerpunkt. N plus eins ist hier keine Kür, sondern der Grund, warum man ohnehin mehr als eine Maschine kauft. Aufgabenvielfalt: 500 Leute bringen Programmierung, lange RAG-Kontexte und Zusammenfassungen mit, und die Kontextlänge bestimmt den Bedarf am KV-Cache stärker als die Zahl der Nutzer.

Beim Aufteilen auf Repliken hilft bei einem MoE-Modell zusätzlich ein Effekt, der in die entgegengesetzte Richtung zeigt als die übliche Intuition. Gemma 4 wählt zwei von 128 Experten je Token. Über einen Stapel von B gleichzeitigen Anfragen wird ein einzelner Experte mit einer Wahrscheinlichkeit von eins minus (eins minus 2 durch 128) hoch B angesprochen:

Stapel 8: rund 12 Prozent der Experten je Schicht
Stapel 25: rund 33 Prozent
Stapel 50: rund 55 Prozent

Drei Repliken mit je acht gleichzeitigen Anfragen lesen je Rechenschritt also deutlich weniger Gewichte als ein Gerät mit 25. Das ist eine Überschlagsrechnung mit gleichverteilten Experten, in der Praxis ähneln sich die Prompts und der Wert fällt niedriger aus. Die Richtung stimmt trotzdem: Bei Mixture-of-Experts arbeiten mehrere kleine Stapel sparsamer mit der Speicherbandbreite als ein großer.

Und damit die unbequeme Frage, die man sich bei dieser Last stellen muss: Sind drei DGX Spark überhaupt der richtige Kauf? Der Spark ist mit 273 GB pro Sekunde Speicherbandbreite als Entwicklungsgerät ausgelegt, nicht als Serverkarte. Eine RTX PRO 6000 Blackwell hat 96 GB GDDR7 und 1.792 GB pro Sekunde, also gut das Sechseinhalbfache, und Gemma 4 26B passt in 8 Bit mit 28,8 GB bequem hinein, mit reichlich Rest für den KV-Cache. Seit Juni 2026 liegt sie bei rund 13.250 US-Dollar, also ungefähr auf dem Niveau von drei Sparks.

Die ehrliche Gegenüberstellung für 25 gleichzeitige Anfragen sieht deshalb so aus:

Drei DGX Spark, rund 14.100 US-Dollar. Je Gerät acht gleichzeitige Anfragen, N plus eins ohne Aufpreis, kein Rack und keine Serverkühlung nötig, und jedes Gerät ist nebenbei eine Entwicklungsmaschine. Dafür die niedrigste Bandbreite je Anfrage.
Eine RTX PRO 6000 Blackwell im Server, rund 13.250 US-Dollar plus Wirtssystem. Die mit Abstand beste Antwortzeit je Anfrage, aber ein einzelner Fehlerpunkt für 500 Menschen und 600 Watt im Rack. Für N plus eins verdoppelt sich der Betrag.

Für 500 Arbeitsplätze planen wir mit drei Repliken und machen die Wahl zwischen Spark und Serverkarte an der zugesagten Antwortgeschwindigkeit fest. Reicht Lesegeschwindigkeit für den Nutzer, sind drei Sparks der ruhigere und ausfallsicherere Aufbau. Sind kurze Wartezeiten bei langen Eingaben zugesagt, etwa in einem Coding-Werkzeug, ist die Serverkarte die ehrlichere Wahl. Was in beiden Fällen nicht hilft, ist der Cluster.

Was das für einen Betrieb heißt

Kabel und Switch sind der kleinste Posten in diesem Aufbau, und trotzdem entscheiden sie darüber, ob die Investition ihre Leistung zeigt. Ein Cluster, der mit falscher MTU und einem einzigen Datenstrom läuft, liefert ein Drittel dessen, wofür bezahlt wurde, und niemand merkt es, weil alles funktioniert.

Der Rest ist die bekannte Rechnung. Läuft die Inferenz im Haus, verlässt keine Anfrage das Netz, das ist der Kern dessen, was wir unter lokale KI beschreiben, und für regulierte Branchen oft der eigentliche Grund für diese Hardware. Ob dafür ein Gerät reicht oder drei nötig sind, hängt allein am Modell, das Ihre Aufgabe löst, nicht an der Empfehlung eines Beitrags im Netz.

Wenn Sie diese Abwägung mit Ihren eigenen Zahlen führen wollen, statt sie aus einer Kabelliste abzuleiten, ist ein Pilotprojekt der kurze Weg. Wir messen Ihre Aufgabe auf einem Gerät, bevor wir über das zweite reden.

Quellen

Häufige Fragen

Wie viele DGX Spark kann ich ohne Switch verbinden?

Bis zu drei. Zwei Geräte verbindet ein Kabel direkt, drei Geräte bilden mit drei Kabeln einen Ring, in dem jedes Gerät mit den beiden anderen verbunden ist. Ab dem vierten Gerät verlangt NVIDIA in seinem eigenen Cluster-Assistenten einen Switch. Mischen ist nicht vorgesehen, entweder alle direkt oder alle über den Switch.

Welcher Switch passt zu einem DGX-Spark-Cluster?

Für bis zu vier Geräte reicht ein MikroTik CRS504 mit vier 100-Gbit-Ports, im Handel je nach Anbieter rund 640 bis 780 US-Dollar. Wer auf acht Geräte plant, nimmt den CRS804 mit vier 400-Gbit-Ports und teilt jeden davon per Breakout-Kabel in zwei 200-Gbit-Strecken. Der CRS812 ist die Ausweichlösung bei Lieferengpässen, beide liegen bei rund 1.295 US-Dollar Listenpreis.

Braucht Gemma 4 26B MoE für 25 gleichzeitige Nutzer einen Cluster?

Nein. Das Modell hat 26 Milliarden Parameter gesamt und aktiviert vier davon je Token. Google gibt den Speicherbedarf mit 57,7 GB in BF16, 28,8 GB in 8 Bit und 14,4 GB in 4 Bit an. Alle drei Varianten passen in ein einziges Gerät mit 128 GB, es bleibt genug Platz für den KV-Cache von 25 Sitzungen. Reicht die Leistung eines Geräts nicht, stellt man eine zweite Kopie daneben und verteilt mit LiteLLM, statt einen Cluster zu bauen. Repliken erhöhen den Durchsatz, Cluster-Knoten nicht.

Mac Studio oder DGX Spark bei vielen gleichzeitigen Nutzern?

Bei einem einzelnen Nutzer gewinnt der Mac Studio, weil seine Speicherbandbreite von 546 bis 819 GB pro Sekunde gegen 273 GB pro Sekunde beim Spark direkt in Token pro Sekunde durchschlägt. Bei 25 gleichzeitigen Nutzern verschiebt sich das: Dann entscheiden Prompt-Verarbeitung und die Planung des KV-Caches, und dort ist der CUDA-Stack mit vLLM dem MLX-Stack voraus. Dazu kommt die Lage am Markt, der Mac Studio ist derzeit auf 96 GB gedeckelt und hat 13 bis 14 Wochen Lieferzeit.