llama.cpp auf zwei bis vier GPUs: split-mode layer, row und tensor mit NVIDIA RTX PRO

Wie llama.cpp ein Modell auf mehrere GPUs verteilt

llama.cpp verteilt ein GGUF-Modell mit --split-mode auf mehrere NVIDIA-GPUs. Der Standard layer gibt jeder Karte einen Teil der Schichten samt KV-Cache und lässt die Karten nacheinander als Pipeline rechnen; row und der neuere Modus tensor teilen jede Gewichtsmatrix, sodass die Karten parallel rechnen. Ohne NVLink, wie bei allen RTX-PRO-Blackwell-Karten, schickt layer am wenigsten über PCIe, und tensor ist der Modus, der ein einzelnes Gespräch schneller machen kann.

Die Parameter unten stammen aus der README von llama-server auf GitHub, gelesen am 24. Oktober 2026; der neueste Release war Build b11829 vom 22. Oktober. llama.cpp veröffentlicht nummerierte Builds statt Versionen, mehrere am Tag, daher können sich Parameter und Standardwerte von Build zu Build ändern; prüfen Sie llama-server --help auf dem Build, den Sie betreiben.

README von llama.cpp tools/server und tools/llama-bench auf GitHub, gelesen am 24. Oktober 2026; Release-Liste mit Build b11829 (22. Oktober 2026).

--fit verdient einen Hinweis. Weil es standardmäßig aktiv ist, verkleinert llama-server nicht gesetzte Werte wie die Kontextlänge, bis das Modell auf die Karten passt, bis hinunter zu --fit-ctx, standardmäßig 4.096 Token; --fit-target setzt eine Reserve in MiB je Gerät. Legen Sie auf einer gemeinsam genutzten Maschine Kontext und Zahl der Slots (-np) selbst fest, damit ein Neustart nach einem Treiber-Update den Nutzern nicht unbemerkt einen kürzeren Kontext gibt.

Layer, row und tensor: was über PCIe geht

Im Modus layer rechnet die erste Karte ihre Schichten für einen Batch von Token und übergibt das Ergebnis an die zweite, die ihre Schichten rechnet, und so weiter. Über PCIe gehen an jeder Grenze die Aktivierungen der laufenden Token, Kilobyte je Token, ein winziger Bruchteil der Gewichte; der Modus läuft daher gut über eine einfache PCIe-Verbindung und braucht keinen Peer-to-Peer-Zugriff. Der Preis: Für ein einzelnes Gespräch arbeitet immer nur eine Karte. Zwei Karten fassen ein doppelt so großes Modell, aber ein einzelner Strom erzeugt nicht schneller als auf einer Karte mit genug Speicher. Bei mehreren Gesprächen bündelt llama-server sie, und die Pipeline hält mehr als eine Karte beschäftigt; die Build-Anleitung empfiehlt CUDA_SCALE_LAUNCH_QUEUES=4x besonders für Pipeline-Parallelität auf mehreren GPUs, um die Prompt-Verarbeitung zu beschleunigen.

Der Modus row teilt jede Gewichtsmatrix zeilenweise, sodass jede Karte einen Teil jeder Schicht rechnet; die Haupt-GPU sammelt die Ergebnisse und hält den KV-Cache. Jede Schicht braucht dann einen Austausch zwischen den Karten. Im Dreiervergleich des Pull Requests für tensor, auf zwei RTX 4090 mit einem 8B-Modell in Q4_0, war row der langsamste der drei Modi: 67,00 Token pro Sekunde bei der Generierung gegen 175,43 mit layer, und 2.997 gegen 12.551 bei der Prompt-Verarbeitung.

Der Modus tensor kam mit Pull Request 19378, Titel „backend-agnostic tensor parallelism (experimental)“. Er teilt Gewichte und KV-Cache und synchronisiert die Karten nur dort, wo die Rechnung es verlangt. Die Beschreibung, gelesen am 24. Oktober 2026, sagt, dass „only the CUDA backend has received the necessary extensions and performance optimizations“, dass NCCL „for good performance“ installiert sein sollte und dass die Funktion als experimentell und „not yet production ready“ gilt.

llama.cpp Pull Request 19378, Beschreibung gelesen am 24. Oktober 2026; Token pro Sekunde mit llama-bench, gemessen vom Autor des Pull Requests auf GeForce RTX 4090, „All GPUs are connected via 16x PCIe 4.0“. Generierung ist tg128, Prompt-Verarbeitung pp512.

Der Autor fasst zusammen, tensor „works comparatively better for slow GPUs with fast interconnect running large, dense models“ und schlechter bei schnellen GPUs an langsamen Verbindungen mit kleinen Modellen. Die 70B-Zeile zeigt den Gewinn für ein dichtes Modell, die Zeile zu gpt-oss 20B, wie wenig ein kleines Mixture-of-Experts-Modell gewinnt. Eine veröffentlichte llama.cpp-Messung der Split-Modi auf RTX-PRO-Blackwell-Karten mit ihren PCIe-5.0-Anbindungen haben wir nicht gefunden; lesen Sie die Werte der Consumer-Karten daher als Richtung des Effekts, nicht als Prognose für Ihre Workstation.

Grenzen des Modus tensor im Oktober 2026

Der Pull Request nennt die Bedingungen, unter denen tensor heute läuft:

• FlashAttention muss aktiviert und die Quantisierung des KV-Caches deaktiviert sein, der Cache bleibt also in f16 oder bf16
• --fit und Backend-Sampling sind nicht umgesetzt, und der Speicherverbrauch ist wegen Überallokationen ineffizient; lassen Sie auf jeder Karte Reserve
• ein VRAM-Leck durch CUDA-Graphen, die fortlaufend erzeugt, aber nie freigegeben werden
• 23 Architekturen gelten als „definitely broken“, darunter deepseek2, mamba, mamba2, olmoe und t5
• beliebig viele GPUs, bis 16; ROCm läuft über HIP, Vulkan läuft technisch nur bei kurzen Kontexten und langsam, andere Backends gelten als nicht nutzbar

Für einen produktiven Dienst, der monatelang laufen soll, würden wir heute layer einplanen und tensor auf demselben Build in einem Testlauf mit Ihrem eigenen Modell ausprobieren. Ein Modell, dessen Architektur auf der Liste steht, bleibt bei layer.

Peer-to-Peer-Zugriff zwischen den Karten

Das CUDA-Backend von llama.cpp kopiert Daten zwischen GPUs über den Systemspeicher, solange kein Peer-to-Peer-Zugriff aktiviert ist. Laut Build-Anleitung lässt sich dieser mit der Umgebungsvariablen GGML_CUDA_P2P einschalten; er braucht Treiberunterstützung, meist auf Workstation- oder Rechenzentrums-GPUs, und kann auf manchen Mainboards und BIOS-Einstellungen, etwa mit aktiver IOMMU, zu Abstürzen oder fehlerhaften Ausgaben führen. Ein veröffentlichter Test zeigte P2P zwischen zwei RTX PRO 6000 Workstation Edition; ob es in einer bestimmten Maschine funktioniert, hängt von IOMMU und ACS ab, die unser Leitfaden zu RTX PRO 6000 P2P unter Linux mit nvidia-smi topo -m, NVIDIAs simpleP2P-Beispiel und nccl-tests durchgeht. layer braucht P2P kaum; tensor, das in jeder Schicht Daten austauscht, profitiert davon und von NCCL.

Wir bauen Workstations und Server mit zwei bis vier RTX-PRO-Karten und installieren auf Wunsch Linux, Treiber und CUDA; schicken Sie uns Ihre GGUF-Modelle und die Zahl der Nutzer, und unser Team antwortet mit einer Konfiguration und einem Split-Modus für den Start.

Speicherbedarf: welche GGUF-Dateien auf zwei oder vier Karten passen

llama.cpp reserviert keinen festen Speicheranteil wie vLLM, die Karten brauchen aber trotzdem Platz für CUDA-Laufzeit, Rechenpuffer und Cache. Wir planen mit unserer Regel für Nutzer je Karte: 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB je Karte, abzüglich der Gewichte. Das ergibt 83,0 GiB auf einer RTX PRO 6000 Max-Q mit 96 GB und 61,5 GiB auf einer RTX PRO 5000 mit 72 GB, skaliert von den 95,6 GiB, die eine 96-GB-Karte meldet. Die Dateigrößen stammen aus den Dateilisten auf Hugging Face.

Unsere Schätzung nach der Regel für Nutzer je Karte mit 16-Bit-KV-Cache: Gespräche zu 8.192 Token mit je 2,5 GiB für Llama 3.3 70B, zu 32.768 Token mit je 1,125 GiB für gpt-oss-120b. Dateigrößen aus bartowski/Llama-3.3-70B-Instruct-GGUF (Q8_0 in zwei Teilen zu 39,9 und 35 GB) und ggml-org/gpt-oss-120b-GGUF, gelesen am 24. Oktober 2026.

Die Rechnung für eine Zeile: Zwei Max-Q ergeben 2 × 83,04 = 166,1 GiB; die Q8_0-Gewichte mit 74,9 GB sind 69,8 GiB, es bleiben 96,3 GiB oder 38 Gespräche zu 8K mit je 2,5 GiB. Auf einer einzelnen RTX PRO 5000 mit 72 GB lässt gpt-oss-120b nur 2,5 GiB übrig, Cache für zwei lange Gespräche; auf dieser Karte gehört es daher auf ein Paar. Der kleine Cache der Sliding-Window-Schichten von gpt-oss ist nicht eingerechnet. --cache-type-k von llama-server akzeptiert unter anderem q8_0 und q4_0, um den Cache zu verkleinern, im Modus tensor jedoch nicht.

Passt ein Modell auf eine Karte, teilen Sie es nicht. Zwei llama-server-Prozesse, jeweils mit -sm none und eigener GPU über CUDA_VISIBLE_DEVICES oder -dev gestartet, ergeben zwei unabhängige Kopien ohne Verkehr zwischen den Karten; ein dritter Prozess auf einem anderen Port kann ein zweites Modell bedienen. gpt-oss-120b auf zwei Max-Q ist der klare Fall: Eine Kopie je Karte hält jeweils 21 Gespräche, und fällt eine Karte aus, antwortet die andere weiter. Unsere Seiten zu 2× RTX PRO 6000 Max-Q in einer Workstation und 4× RTX PRO 5000 72 GB behandeln diese Systeme für vLLM.

Tempo für ein Gespräch, nach unserer Schätzung

Die Token-Generierung liest die Gewichte einmal je Token, daher setzt die Speicherbandbreite eine Obergrenze. Im Modus layer lesen die Karten ihre Teile nacheinander, ein Gespräch sieht die Bandbreite einer Karte; im Modus tensor lesen sie parallel, vor den Kosten der Synchronisation.

Unsere Schätzung: 74,9 oder 42,5 GB je Token gelesen, geteilt durch 1.792 GB/s je Max-Q oder 1.344 GB/s je RTX PRO 5000 (NVIDIA-Produktseiten), für tensor mal der Zahl der Karten. Obergrenzen, keine Messungen; reale Werte liegen darunter, und tensor verliert einen Teil des Gewinns an den Austausch über PCIe.

Der Vier-Karten-Wert im Pull Request, 48,31 gegen 21,25 Token pro Sekunde für ein 70B in Q4_K_M, also Faktor 2,3 bei einer Obergrenze von 4, zeigt, wie viel des Gewinns die Synchronisation über PCIe 4.0 kostete. Für ein dichtes 70B-Modell, das jeweils eine Person nutzt, ist tensor die Einstellung, die sich spürbar auswirkt; gpt-oss-120b liest je Token nur seine aktiven Experten, eine Kopie auf einer Karte ist schon schnell, und Aufteilen bringt weniger.

Modelle größer als der GPU-Speicher: Experten im Systemspeicher

llama.cpp kann einen Teil des Modells im Systemspeicher halten, was vLLM anders löst. --cpu-moe hält alle Mixture-of-Experts-Gewichte auf der CPU, --n-cpu-moe N die der ersten N Schichten; --override-tensor platziert Tensoren nach Namensmuster. Attention-Schichten und gemeinsame Gewichte bleiben auf den GPUs, wo sie für jedes Token gelesen werden, und die Experten kommen aus dem DDR5 mit der Geschwindigkeit der Speicherkanäle des Prozessors. Damit wird ein Mixture-of-Experts-Modell, das größer ist als der gesamte GPU-Speicher, für eine oder zwei Personen nutzbar, wenn auch langsam. Unser Leitfaden zum MoE-Experten-Offload mit KTransformers geht ein solches Offload für Kimi durch, und Gesamt- und aktive Parameter erklärt, warum es funktioniert; die Build-Anleitung beschreibt außerdem GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 unter Linux, womit das CUDA-Backend bei vollem VRAM in den Systemspeicher auslagert, statt abzubrechen.

llama.cpp für RTX PRO Blackwell bauen

RTX-PRO-Blackwell-Karten haben in NVIDIAs Liste der CUDA-GPUs die Compute Capability 12.0. Build b11829 liefert Ubuntu-Binärdateien für CUDA 12.8 und CUDA 13.4, und der CUDA-Build der Anleitung lautet cmake -B build -DGGML_CUDA=ON, gefolgt von cmake --build build --config Release, mit CMAKE_CUDA_ARCHITECTURES auf die Compute Capability Ihrer Karte gesetzt, wenn nvcc sie nicht erkennt. NCCL, das tensor nutzen will, ist eine eigene NVIDIA-Bibliothek, die neben CUDA installiert wird.

Zwei Einstellungen der Build-Anleitung betreffen die FP4-Tensor-Cores von Blackwell. GGML_CUDA_MMQ_PREC legt die Genauigkeit der Aktivierungen für NVFP4- und MXFP4-Matrixmultiplikationen fest: q4 behält den nativen W4A4-Pfad, der Prompts schneller verarbeitet, mit etwas Genauigkeitsverlust, q8 nutzt W4A8 für jede Schicht. gpt-oss-120b erscheint in MXFP4, die Einstellung betrifft also auch dieses Modell. Welcher Treiberzweig CUDA 13 mitbringt, erklärt unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen.

Die Modi auf der eigenen Maschine vergleichen

llama-bench, das mit llama.cpp kommt, nimmt je Parameter mehrere kommagetrennte Werte, sodass ein Lauf die Modi vergleicht: -sm layer,tensor mit -fa on misst beide am selben Modell, -p 512 -n 128 legt Prompt- und Generierungslänge fest, und -d fügt eine Kontexttiefe hinzu, sodass sich der Vergleich bei 8K oder 32K Kontext wiederholen lässt. Führen Sie ihn mit dem Build, dem Treiber und den Leistungsgrenzen aus, die Sie produktiv nutzen. Mit CUDA_VISIBLE_DEVICES begrenzen Sie die GPUs eines Laufs und sehen so auch, wie ein Paar gegenüber allen vier Karten abschneidet.

Wann vLLM die bessere Engine ist

llama-server bündelt die Anfragen seiner Slots fortlaufend und bedient mit layer ein kleines Team gut. Für einen Endpunkt mit Dutzenden gleichzeitigen Anfragen zählen ein seitenweise verwalteter KV-Cache, Prefix-Caching und Tensor-Parallel-Kernel mehr, und dafür planen wir vLLM oder SGLang ein, wie unser Vergleich von vLLM, SGLang, TensorRT-LLM, llama.cpp und Ollama erklärt. Auf Karten ohne NVLink bevorzugt die Anleitung von vLLM Pipeline- statt Tensor-Parallelität; auf RTX PRO 6000 behalten TP=2-Paare das eigene All-Reduce von vLLM, das es bei mehr als zwei reinen PCIe-GPUs standardmäßig abschaltet, wie RTX PRO 6000 ohne NVLink ausführt. vLLM 0.30.0 (Release Notes vom 22. September 2026) brachte für Systeme ohne NVLink ein optional einschaltbares FlashInfer-PCIe-IPC-All-Reduce (#53576).

Unsere Empfehlung auf Grundlage der README von llama.cpp, des Pull Requests 19378 und der Parallelisierungsanleitung von vLLM, Stand Oktober 2026.

Ollama, aufgebaut auf der GGML-Bibliothek von llama.cpp, entscheidet die Aufteilung selbst: Es legt ein Modell auf eine GPU, wenn es dort passt, und verteilt es sonst auf alle, ohne Wahl des Split-Modus.

Was wir liefern

Wir liefern die RTX PRO 6000 Max-Q und Workstation Edition, die RTX PRO 5000 mit 48 und 72 GB sowie die RTX PRO 4500 und 4000 und bauen Workstations mit zwei bis vier Karten auf Bestellung, auf Wunsch mit Linux, Treiber, CUDA und Container-Laufzeit, wie unsere Seite zu KI-Servern angibt. Für einen gemeinsam genutzten Dienst bauen wir Server mit RTX PRO 6000 Server Edition. Modell, Serving-Engine und Plattform darüber sind unser Service Private AI/ML; beschreiben Sie Modelle, Nutzer und den Zugang zur Maschine, und wir schlagen System und Engine vor.

FAQ