llama.cpp Pipeline-Parallelismus verschwendet bis zu 1,5 GB VRAM ohne Speed-Vorteil
Der Reddit-Beitrag aus r/LocalLLaMA untersucht ein konkretes VRAM-Effizienzproblem im Standard-Build von llama.cpp: Sobald Pipeline-Parallelismus aktiv ist – was automatisch geschieht, wenn `--split-mode layer` (Standard) zusammen mit vollständigem GPU-Offload verwendet wird –, allokiert llama.cpp vier sogenannte „Sched Copies" im Compute-Buffer statt nur einer. Der Autor testete drei Build-Varianten mit dem Vulkan-Backend: den Standard-Build (`GGML_SCHED_MAX_COPIES=4`), einen mit `GGML_SCHED_MAX_COPIES=1` und einen mit aktiviertem OpenBLAS, das Pipeline-Parallelismus zufällig deaktiviert. Als Testmodell kam Qwen3.6-27B-UD-Q5_K_XL auf einem Zwei-GPU-System zum Einsatz. Die Messergebnisse über je drei Durchläufe zeigen: Der Compute-Buffer schrumpft von rund 1.022/910 MB (GPU1/GPU2) auf jeweils 242/242 MB, wenn nur eine Sched Copy genutzt wird – das entspricht einer Ersparnis von ca. 1,5 GB VRAM. Besonders gravierend ist der Overhead in Kombination mit Context-Cache-Quantisierung (`--cache-type-k f16 --cache-type-v q8_0`): Hier frisst der Buffer-Bloat einen erheblichen Teil der durch die Quantisierung gewonnenen VRAM-Einsparungen wieder auf. Ohne Cache-Quantisierung beträgt der Overhead „nur" rund 0,5 GB. Die Inferenzgeschwindigkeit unterschied sich in keiner Konfiguration messbar – Input- und Output-Token/s blieben über alle neun Testläufe nahezu konstant.
- Testmodell: Qwen3.6-27B-UD-Q5_K_XL.gguf auf einem Zwei-GPU-System mit Vulkan-Backend und den Flags -fa on, --mlock, -ngl 999.
- Compute-Buffer mit 4 Sched Copies: ~1.022 MB (GPU1) + ~910 MB (GPU2); mit 1 Sched Copy: je ~242 MB – Differenz ca. 1,5 GB.
- Ohne Cache-Quantisierung beträgt der Overhead durch 4 Sched Copies nur ~0,5 GB (481 MB vs. 219 MB pro GPU).
- Der verfügbare Kontext steigt durch GGML_SCHED_MAX_COPIES=1 von ~88.576 auf ~113.920 Token – ein Plus von rund 28 %.
- OpenBLAS-Build (GGML_BLAS=ON, GGML_BLAS_VENDOR=OpenBLAS) deaktiviert Pipeline-Parallelismus als Nebeneffekt und liefert identische Buffer-Größen wie der 1-Copy-Build.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
llama.cpp Pipeline-Parallelismus verschwendet bis zu 1,5 GB VRAM ohne Speed-Vorteil
Der Reddit-Beitrag aus r/LocalLLaMA untersucht ein konkretes VRAM-Effizienzproblem im Standard-Build von llama.cpp: Sobald Pipeline-Parallelismus aktiv ist – was automatisch geschieht, wenn `--split-mode layer` (Standard) zusammen mit vollständigem GPU-Offload verwendet wird –, allokiert llama.cpp vier sogenannte „Sched Copies" im Compute-Buffer statt nur einer. Der Autor testete drei Build-Varianten mit dem Vulkan-Backend: den Standard-Build (`GGML_SCHED_MAX_COPIES=4`), einen mit `GGML_SCHED_MAX_COPIES=1` und einen mit aktiviertem OpenBLAS, das Pipeline-Parallelismus zufällig deaktiviert. Als Testmodell kam Qwen3.6-27B-UD-Q5_K_XL auf einem Zwei-GPU-System zum Einsatz. Die Messergebnisse über je drei Durchläufe zeigen: Der Compute-Buffer schrumpft von rund 1.022/910 MB (GPU1/GPU2) auf jeweils 242/242 MB, wenn nur eine Sched Copy genutzt wird – das entspricht einer Ersparnis von ca. 1,5 GB VRAM. Besonders gravierend ist der Overhead in Kombination mit Context-Cache-Quantisierung (`--cache-type-k f16 --cache-type-v q8_0`): Hier frisst der Buffer-Bloat einen erheblichen Teil der durch die Quantisierung gewonnenen VRAM-Einsparungen wieder auf. Ohne Cache-Quantisierung beträgt der Overhead „nur" rund 0,5 GB. Die Inferenzgeschwindigkeit unterschied sich in keiner Konfiguration messbar – Input- und Output-Token/s blieben über alle neun Testläufe nahezu konstant.
- Testmodell: Qwen3.6-27B-UD-Q5_K_XL.gguf auf einem Zwei-GPU-System mit Vulkan-Backend und den Flags -fa on, --mlock, -ngl 999.
- Compute-Buffer mit 4 Sched Copies: ~1.022 MB (GPU1) + ~910 MB (GPU2); mit 1 Sched Copy: je ~242 MB – Differenz ca. 1,5 GB.
- Ohne Cache-Quantisierung beträgt der Overhead durch 4 Sched Copies nur ~0,5 GB (481 MB vs. 219 MB pro GPU).
- Der verfügbare Kontext steigt durch GGML_SCHED_MAX_COPIES=1 von ~88.576 auf ~113.920 Token – ein Plus von rund 28 %.
- OpenBLAS-Build (GGML_BLAS=ON, GGML_BLAS_VENDOR=OpenBLAS) deaktiviert Pipeline-Parallelismus als Nebeneffekt und liefert identische Buffer-Größen wie der 1-Copy-Build.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.