Ein großes Modell auf zwei Rechner aufteilen — der ehrliche Stand

TL;DR

Ollama kann ein einzelnes Modell nicht über mehrere Maschinen verteilen — auch nicht in Version 0.32.5 vom 27. Juli 2026. Wer echtes Sharding braucht, nutzt llama.cpp mit RPC-Backend. Rechnen Sie mit 40 bis 50 Prozent weniger Token pro Sekunde als auf einer Maschine. Die größere Einzelkarte ist zwar teurer, aber für interaktive Nutzung fast immer die bessere Investition.

"Ollama-Cluster" meint zwei völlig verschiedene Dinge

Der Begriff wird in Foren und Blogs munter durcheinandergeworfen, und das führt zu falschen Hardware-Käufen. Es gibt zwei Szenarien, und sie haben fast nichts miteinander zu tun.

Szenario A — Lastverteilung. Sie haben ein Modell, das auf eine GPU passt, aber zu viele Nutzer. Dann laufen mehrere identische Ollama-Instanzen, und ein Reverse Proxy verteilt die Anfragen. Das ist gelöst, funktioniert stabil und skaliert linear. Den orchestrierten Weg dorthin beschreibt unser Ollama-Deployment auf Kubernetes.

Szenario B — Sharding. Ein Modell passt in keinen einzelnen Rechner, und Sie wollen die Gewichte auf zwei oder drei Maschinen aufteilen. Darum geht es hier. Und hier wird es unangenehm.

Ollama kann Sharding über Maschinengrenzen nicht. Punkt.

Das ist der Teil, den die meisten Anleitungen im Netz verschweigen oder verschleiern.

Ollama verteilt Modell-Layer automatisch über mehrere GPUs — aber nur über GPUs, die im selben Rechner stecken. Der Scheduler erkennt die NVIDIA- und AMD-Karten im System und packt standardmäßig erst GPU 0 voll, bevor er die nächste anfasst. Mit OLLAMA_SCHED_SPREAD=1 erzwingen Sie stattdessen eine Verteilung proportional zum freien VRAM. Für symmetrische Rigs (zweimal dieselbe Karte) ist das die bessere Wahl, für gemischte Bestückung meist nicht — dort erzeugt das Spreading zusätzlichen PCIe-Verkehr, ohne dass die schwächere Karte etwas beisteuert.

Über das Netzwerk hinaus endet die Fahnenstange. Der Feature-Request dafür liegt als Issue #4643 seit dem 26. Mai 2024 im Ollama-Repository. Offen. Keine Zuweisung, kein verlinkter Pull Request. Die Release Notes bis einschließlich v0.32.5 erwähnen weder RPC noch Multi-Node.

Wenn Ihnen jemand ein "Ollama-Cluster über mehrere Rechner" mit Modell-Sharding verkauft, prüfen Sie genau, was da wirklich passiert. Meist ist es Szenario A mit einem hübschen Dashboard davor.

Der Weg, der funktioniert: llama.cpp mit RPC-Backend

Ollama nutzt für GGUF-Modelle weiterhin llama.cpp unter der Haube. Und llama.cpp hat, was Ollama nicht nach außen gibt: ein RPC-Backend, das GGML-Geräte eines entfernten Hosts über TCP verfügbar macht. Der Head-Node lädt das Modell, verteilt Gewichte und KV-Cache über alle Geräte — lokal wie remote — und schickt die Berechnungen dorthin, wo die Layer liegen.

Eine Warnung vorweg, die direkt aus der offiziellen Dokumentation stammt: Das RPC-Backend ist ausdrücklich als Proof-of-Concept gekennzeichnet, "fragile and insecure". Es gibt keine Authentifizierung und keine Verschlüsselung. Wer den Port ins offene Netz hängt, öffnet eine Remote-Code-Execution-Tür. Das gehört in ein isoliertes VLAN, sonst nirgendwo hin.

Zuerst auf jedem beteiligten Rechner bauen:

# llama.cpp mit RPC-Backend kompilieren (CUDA-Variante)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build-rpc -DGGML_CUDA=ON -DGGML_RPC=ON
cmake --build build-rpc --config Release -j"$(nproc)"

Dann auf jedem Worker den RPC-Server starten. Zwei Details, an denen die meisten scheitern: Der Server bindet sich standardmäßig auf 127.0.0.1 — ohne -H sieht ihn kein anderer Rechner. Und ohne -c überträgt der Head-Node bei jedem Kaltstart die kompletten Gewichte erneut über das Netz.

# Worker-Node 1 (192.168.10.21): GPU 0 freigeben, auf LAN binden,
# Tensor-Cache aktivieren, damit der Kaltstart nicht jedes Mal
# zweistellige Gigabyte über das Kabel schiebt
./build-rpc/bin/ggml-rpc-server -H 0.0.0.0 -p 50052 --device CUDA0 -c

# Zugriff nur aus dem eigenen Subnetz erlauben
sudo ufw allow from 192.168.10.0/24 to any port 50052 proto tcp

Auf dem Head-Node schalten Sie lokale und entfernte Geräte zu einem Pool zusammen. Das GGUF, das Ollama bereits heruntergeladen hat, lässt sich direkt weiterverwenden:

# Welcher Blob gehört zum Modell? Ollama gibt den Pfad direkt aus
ollama show --modelfile qwen2.5:72b | grep FROM

# llama-server mit lokaler GPU plus zwei Remote-Nodes starten.
# -ngl 99 heißt: alle Layer auf Beschleuniger, nichts auf die CPU.
./build-rpc/bin/llama-server \
  -m /usr/share/ollama/.ollama/models/blobs/sha256-<hash> \
  --rpc 192.168.10.21:50052,192.168.10.22:50052 \
  --tensor-split 20,20,60 \
  -ngl 99 -c 8192 --host 0.0.0.0 --port 11435

Aufpassen: -c bedeutet in den beiden Befehlen etwas Verschiedenes. Beim ggml-rpc-server schaltet es den lokalen Tensor-Cache ein, bei llama-server setzt es die Kontextgröße in Token.

Hier lauert die Falle, die im Netz reihenweise falsch abgeschrieben wird: die RPC-Geräte stehen in der Geräteliste vorn, nicht hinten. llama.cpp sortiert sie bewusst an den Anfang, um Netzwerk-Transfers zu minimieren (src/llama.cpp: "add RPC servers at the front of the list to minimize network transfers"). --tensor-split 20,20,60 heißt deshalb: je 20 Prozent auf die beiden Worker, 60 Prozent auf die lokale GPU. Wer die Reihenfolge intuitiv andersherum liest, schiebt die Mehrheit der Gewichte übers Kabel und wundert sich über den Durchsatz. Prüfen Sie im Startlog, welches Gerät wie viel bekommen hat, bevor Sie benchmarken.

Ohne den Parameter verteilt llama.cpp proportional zum freien Speicher jedes Geräts. Manuell setzen lohnt sich, wenn ein Node über eine deutlich langsamere Leitung hängt — dann bekommt er weniger Layer.

llama-server liefert eine OpenAI-kompatible API auf /v1/chat/completions. Ihre bestehenden Clients funktionieren also weiter, es ändert sich nur der Port.

Das Netzwerk entscheidet — und 1 GbE reicht nicht

Bei jedem einzelnen generierten Token muss der Zwischenzustand über jede Geräte-Grenze wandern. Die Datenmenge ist winzig — ein paar Kilobyte Aktivierungen. Trotzdem kostet es: Zu der einen Übergabe pro Grenze kommen die RPC-Kommandos für jede einzelne Graph-Operation dazu, und die laufen synchron. Der Killer ist deshalb nicht die Bandbreite, sondern die Latenz. Die Messung im dokumentierten Setup unten beziffert den Aufschlag auf rund 0,2 Millisekunden pro Layer und Token über 10 Gbit/s.

Eine Rechnung, die den 1-GbE-Fall erledigt: Ein 72B-Modell in Q4_K_M belegt rund 44 GB. Landen davon 14 GB auf einem Worker, dauert der Transfer bei realen 110 MB/s über Gigabit-Ethernet etwa 127 Sekunden. Über 10 GbE sind es rund zwölf. Der lokale Cache (-c) entschärft das ab dem zweiten Start — beim ersten sitzen Sie zwei Minuten da.

Interessant wird es bei Thunderbolt 5. Apple hat mit macOS Tahoe 26.2 RDMA über Thunderbolt nachgereicht (Technote TN3205), was die Speicherzugriffs-Latenz von rund 300 Mikrosekunden über TCP auf unter 50 drückt. In einem Vier-Node-Test mit Mac Studios und DeepSeek V3.1 erreichte das Framework exo mit RDMA 32,5 Token/s, während llama.cpp über klassisches TCP bei 14,6 Token/s landete — und mit jedem zusätzlichen Node langsamer wurde statt schneller. Das ist die Zahl, die Sie sich merken sollten: llama.cpp über TCP skaliert negativ. Zwei Nodes sind ein Kompromiss, vier sind ein Rückschritt.

Auf Linux gibt es die Abkürzung übrigens auch: Steckt eine RoCEv2-fähige NIC im Rechner und wurde llama.cpp mit libibverbs gebaut, nutzt das RPC-Backend RDMA statt TCP — automatisch ausgehandelt, ohne geänderte Kommandozeile. Wer ernsthaft shardet, sollte genau dort ansetzen und nicht am nächsten Switch.

Was Sie realistisch an Durchsatz bekommen

Konkrete Messwerte aus einem öffentlich dokumentierten Setup (llama-cpp-distributed-benchmarks) mit Mac Studio (M2 Ultra, 128 GB, Metal) als Head und einer DGX Spark (GB10 Blackwell, 120 GB, CUDA) als Worker, verbunden über 10 GbE mit per iperf3 gemessenen 9,41 Gbit/s:

Lesen Sie die Tabelle zweimal. Die Generierung halbiert sich in beiden Fällen. Was gewinnt, ist ausschließlich die Prompt-Verarbeitung beim kleinen Modell, weil dort zusätzliche Rechenleistung ohne nennenswerten Netzwerk-Overhead greift.

Und ordnen Sie 5,9 Token/s ehrlich ein: Das ist ungefähr die Lesegeschwindigkeit eines Menschen. Für einen internen Dokumenten-Assistenten mit einem Nutzer gerade noch erträglich. Für einen Chatbot mit fünf gleichzeitigen Anfragen ist es unbrauchbar, und keine Netzwerk-Optimierung rettet das.

Die Regel, die daraus folgt: RPC verschafft Ihnen Kapazität, nicht Geschwindigkeit. Es ist die Antwort auf "das Modell passt nirgendwo hin", nicht auf "das Modell ist zu langsam".

Die Rechnung, die Sie vor dem Kauf machen müssen

Nehmen wir an, Sie wollen ein 72B-Modell in Q4 fahren. Bedarf: rund 44 GB VRAM plus Kontext.

Die folgende Rechnung legen wir offen, damit Sie sie mit Ihren eigenen Angeboten nachrechnen können. GPU-Preise schwanken 2026 stark — prüfen Sie sie am Kauftag nach, statt uns zu glauben.

Variante Sharding — zwei Rechner mit je einer RTX 5090 (32 GB):

Die 3.900 Euro sind der untere Rand der deutschen Marktpreise im Juli 2026; die Einführungs-UVP von rund 2.000 Euro sehen Sie im Handel seit Monaten nicht mehr. Ergebnis dieser Variante: 64 GB verteilter Speicher bei halbierter Generierungsgeschwindigkeit.

Variante Einzelkarte — eine RTX PRO 6000 Blackwell mit 96 GB: NVIDIA hat den Listenpreis im Juni 2026 auf 13.250 US-Dollar angehoben; im deutschen Handel landen Sie damit im Bereich 12.000 bis 14.000 Euro brutto, je nach Edition und Verfügbarkeit. Plus ein Basissystem: rund 13.500 bis 15.500 Euro. Ergebnis: 96 GB in einem Speicherraum, volle Geschwindigkeit, ein Rechner zu warten.

Die Einzelkarte ist also nicht billiger, sondern etwa 20 bis 35 Prozent teurer — und trotzdem die bessere Entscheidung, sobald ein Mensch auf die Antwort wartet. Sie liefert rund doppelten Token-Durchsatz, 50 Prozent mehr Speicher und ein einziges System, das ausfallen kann. Die Sharding-Variante spart einmalig ein paar tausend Euro und kostet Sie danach jeden Tag Latenz.

Dazu kommt der laufende Betrieb: Ein zweiter Rechner mit durchschnittlich 350 W über acht Stunden an 220 Arbeitstagen verbraucht 616 kWh — bei 0,30 Euro/kWh sind das 185 Euro pro Jahr zusätzlich. Kein Kaufargument für sich, aber es dreht die Rechnung auch nicht zurück. Wie sich das über die Nutzungsdauer summiert, zeigt unsere Stromkosten-Rechnung für KI-Server.

Unsere Empfehlung ist deshalb unmissverständlich: Kaufen Sie VRAM, nicht Netzwerk. Welche Karte für welche Modellgröße reicht, steht im GPU-Vergleich für LLM-Inferenz, die Systemkonfigurationen drumherum im Hardware-Guide für eigene KI-Server.

Wann Sharding trotzdem die richtige Antwort ist

Es gibt drei Fälle, in denen wir nicht abraten.

Erstens: Sie haben die Hardware bereits. Zwei Workstations mit je 24 GB stehen ohnehin herum, das Budget für eine neue Karte kommt frühestens nächstes Jahr. Dann ist ein Wochenende llama.cpp-RPC billiger als Nichtstun.

Zweitens: Sie evaluieren ein Modell, das keine Einzelkarte fassen kann — 405B, große MoE-Architekturen. Für einen Machbarkeitstest, bei dem Latenz egal ist, reicht verteilte Inferenz vollkommen.

Drittens: Sie fahren batch-artige Workloads über Nacht. Dokumenten-Klassifikation, Extraktion aus Archivbeständen, Übersetzungsläufe. Wenn kein Mensch auf die Antwort wartet, sind 6 statt 11 Token/s irrelevant.

Für alles, was nach Produktivbetrieb mit mehreren Nutzern aussieht, ist llama.cpp-RPC der falsche Hebel. Dort brauchen Sie Durchsatz durch Batching, nicht durch Speicheraddition — das liefert vLLM. Wie das über mehrere GPUs in einer Maschine aussieht, beschreibt unser Leitfaden zum vLLM-Cluster für 70B-Modelle. Und wenn Sie noch am Anfang stehen und erstmal einen sauberen Single-Node brauchen: Ollama unter Ubuntu installieren.

FAQ

Kann Ollama ein Modell über mehrere Rechner verteilen?

Nein. Ollama verteilt Modell-Layer automatisch über mehrere GPUs innerhalb eines Rechners, aber nicht über Maschinengrenzen hinweg. Der entsprechende Feature-Request (Issue #4643) ist seit Mai 2024 offen, und die Release Notes bis Version 0.32.5 vom Juli 2026 enthalten keine Multi-Node-Funktion. Für echtes Sharding müssen Sie auf llama.cpp mit RPC-Backend ausweichen.

Wie viel langsamer wird ein Modell durch verteilte Inferenz?

In dokumentierten Messungen über 10-Gigabit-Ethernet halbiert sich die Generierungsgeschwindigkeit ungefähr: Qwen2.5-72B fiel von 11,1 auf 5,9 Token pro Sekunde, ein 7B-Modell von 91,8 auf 52,7. Grund ist der Netzwerk-Round-Trip pro generiertem Token. Die Prompt-Verarbeitung kann dagegen schneller werden, weil dort zusätzliche Rechenleistung ohne ständigen Austausch greift.

Was kostet ein Sharding-Setup im Vergleich zu einer größeren GPU?

Zwei Rechner mit je einer RTX 5090 (32 GB, ab rund 3.900 Euro pro Karte im deutschen Handel Mitte 2026) plus Basissysteme und 10-GbE-Netzwerk landen bei etwa 11.300 Euro für 64 GB verteilten Speicher. Eine einzelne RTX PRO 6000 Blackwell mit 96 GB liegt bei einem NVIDIA-Listenpreis von 13.250 US-Dollar (Stand Juni 2026), mit System also eher bei 13.500 bis 15.500 Euro. Die Einzelkarte ist damit teurer, liefert aber rund doppelten Token-Durchsatz und 50 Prozent mehr Speicher. Dazu kommen beim Zwei-Rechner-Setup rund 185 Euro Mehrstromkosten pro Jahr bei acht Betriebsstunden täglich.

Reicht ein normales Gigabit-Netzwerk für einen Ollama-Cluster über mehrere Rechner?

Für Lastverteilung über mehrere unabhängige Instanzen ja — dort werden nur Prompts und Antworten übertragen. Für Sharding eines einzelnen Modells nein: Schon der initiale Transfer von 14 GB Gewichten dauert über 1 GbE etwa zwei Minuten, und jeder generierte Token kostet zusätzliche Round-Trips. Praktisches Minimum sind 10 GbE, besser Thunderbolt 5.

Ist das RPC-Backend von llama.cpp produktionsreif?

Nein. Die offizielle Dokumentation stuft es ausdrücklich als Proof-of-Concept ein und bezeichnet es als fragil und unsicher. Es gibt weder Authentifizierung noch Verschlüsselung, und der Server darf niemals in einem offenen Netz laufen. Betreiben Sie ihn ausschließlich in einem isolierten VLAN mit Firewall-Regeln, die den Port auf das eigene Subnetz beschränken.

Fazit

Sharding über mehrere Rechner ist technisch möglich, aber selten die wirtschaftlich richtige Entscheidung. Unsere Position: Solange interaktive Nutzer im Spiel sind, gewinnt die größere Karte — auch wenn sie in der Anschaffung teurer ist. Sharding rechnet sich nur, wenn die Hardware schon dasteht oder niemand auf die Antwort wartet. Wenn Sie das Budget für Ihren Fall gegenrechnen wollen, hilft der KI-Kosten-Kalkulator.