llama.cpp RPC: Qwen 3 27B auf 5070 Ti + 1080 Ti über Gigabit-Ethernet
Der Beitrag dokumentiert einen praxisnahen Erfahrungsbericht zur llama.cpp-RPC-Funktion, die es erlaubt, GPU-VRAM über Netzwerkverbindungen zu bündeln. Der Autor nutzte eine RTX 5070 Ti (16 GB) als primäre Karte und die GPU seines NAS – eine GTX 1080 Ti – als RPC-Client, verbunden über Gigabit-Ethernet mit aktivierten Jumbo Frames. Betrieben wurde das Modell Qwen 3 27B in zwei Quantisierungsstufen: UD-Q4_K_XL für geschwindigkeitsorientierte und UD-Q5_K_XL für qualitätsorientierte Szenarien. Ein zentraler Befund ist die GPU-Reihenfolge in der RPC-Kette: Wird die 5070 Ti als letztes Gerät (RPC0, CUDA0) statt als erstes konfiguriert, steigt die Token-Generierungsgeschwindigkeit von 22–25 auf über 36 tg/s, weil MTP (Multi-Token Prediction) am Ende jeder Generierungsschleife ausgeführt wird und damit von der stärksten GPU profitiert. Weniger bekannt ist ein Nebeneffekt des KV-Quant für das MTP-Draft-Modell: Entgegen der Erwartung verringert es den verfügbaren Kontext, nicht erhöht ihn – ein Verhalten, das laut dem Autor auch in einem GitHub-Discussion-Thread (ggml-org/llama.cpp #24102) als „expected behaviour" bestätigt wurde. Bei reiner Geschwindigkeitsfokussierung belegte die 5070 Ti gut 14 GB VRAM, die 1080 Ti nur 7,2 GB – womit laut dem Autor theoretisch auch eine 8-GB-Karte mit ähnlicher Bandbreite ausreichen würde. Alle Messungen erfolgten unter laufendem KDE-Desktop, was die 5070 Ti laut eigener Schätzung um 1–1,5 GB VRAM belastet.
- llama.cpp-Version b10362 war die Basis aller Tests; n-gram Speculation war durchgehend aktiv (match 16, min 32, max 6).
- KV-Quant für das MTP-Draft-Modell reduziert den verfügbaren Kontext statt ihn zu erweitern – als 'expected behaviour' in GitHub-Discussion #24102 bestätigt.
- Optimale Batch-Größen unterscheiden sich je nach Modus: 512/64 für Prefill-Fokus, 1536/256 bei aktiviertem MTP und umgekehrter GPU-Reihenfolge.
- Bei UD-Q5_K_XL mit vollem KV-Cache und deaktiviertem MTP erreichte das Setup 380 pp/s und 15 tg/s bei 12k Kontext – der qualitätsorientierte Betriebsmodus.
- Jumbo Frames müssen netzwerkweit (NIC, Switch, Host/Hypervisor) aktiviert sein, um Paketfragmentierung und Performanzeinbrüche zu vermeiden.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
llama.cpp RPC: Qwen 3 27B auf 5070 Ti + 1080 Ti über Gigabit-Ethernet
Der Beitrag dokumentiert einen praxisnahen Erfahrungsbericht zur llama.cpp-RPC-Funktion, die es erlaubt, GPU-VRAM über Netzwerkverbindungen zu bündeln. Der Autor nutzte eine RTX 5070 Ti (16 GB) als primäre Karte und die GPU seines NAS – eine GTX 1080 Ti – als RPC-Client, verbunden über Gigabit-Ethernet mit aktivierten Jumbo Frames. Betrieben wurde das Modell Qwen 3 27B in zwei Quantisierungsstufen: UD-Q4_K_XL für geschwindigkeitsorientierte und UD-Q5_K_XL für qualitätsorientierte Szenarien. Ein zentraler Befund ist die GPU-Reihenfolge in der RPC-Kette: Wird die 5070 Ti als letztes Gerät (RPC0, CUDA0) statt als erstes konfiguriert, steigt die Token-Generierungsgeschwindigkeit von 22–25 auf über 36 tg/s, weil MTP (Multi-Token Prediction) am Ende jeder Generierungsschleife ausgeführt wird und damit von der stärksten GPU profitiert. Weniger bekannt ist ein Nebeneffekt des KV-Quant für das MTP-Draft-Modell: Entgegen der Erwartung verringert es den verfügbaren Kontext, nicht erhöht ihn – ein Verhalten, das laut dem Autor auch in einem GitHub-Discussion-Thread (ggml-org/llama.cpp #24102) als „expected behaviour" bestätigt wurde. Bei reiner Geschwindigkeitsfokussierung belegte die 5070 Ti gut 14 GB VRAM, die 1080 Ti nur 7,2 GB – womit laut dem Autor theoretisch auch eine 8-GB-Karte mit ähnlicher Bandbreite ausreichen würde. Alle Messungen erfolgten unter laufendem KDE-Desktop, was die 5070 Ti laut eigener Schätzung um 1–1,5 GB VRAM belastet.
- llama.cpp-Version b10362 war die Basis aller Tests; n-gram Speculation war durchgehend aktiv (match 16, min 32, max 6).
- KV-Quant für das MTP-Draft-Modell reduziert den verfügbaren Kontext statt ihn zu erweitern – als 'expected behaviour' in GitHub-Discussion #24102 bestätigt.
- Optimale Batch-Größen unterscheiden sich je nach Modus: 512/64 für Prefill-Fokus, 1536/256 bei aktiviertem MTP und umgekehrter GPU-Reihenfolge.
- Bei UD-Q5_K_XL mit vollem KV-Cache und deaktiviertem MTP erreichte das Setup 380 pp/s und 15 tg/s bei 12k Kontext – der qualitätsorientierte Betriebsmodus.
- Jumbo Frames müssen netzwerkweit (NIC, Switch, Host/Hypervisor) aktiviert sein, um Paketfragmentierung und Performanzeinbrüche zu vermeiden.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.