Qwen3.8-27B auf 2× RTX 5070 Ti: llama.cpp vs vLLM vs NInfer im Vergleich
Der Benchmark wurde auf einem Selbstbau-Workstation mit AMD Ryzen 7 5800X, 64 GB DDR4 und zwei RTX 5070 Ti (je 16 GB, PCIe 4.0 x8/x8, Blackwell-Architektur sm_120) durchgeführt – ohne NVLink, mit PHB-Topologie und host-gesteuerten Kopien für die Multi-GPU-Kommunikation. Betriebssystem war Ubuntu 26.04 mit CUDA 13.3 und Treiber 595.84. Bei llama.cpp wurde das Modell als unsloth/Qwen3.8-27B-GGUF in Q4_K_XL-Quantisierung (17,6 GB) eingesetzt; mit Tensor-Split über beide GPUs erreichte es 71,7 tok/s ohne und 110–115 tok/s mit MTP3-spekulativem Decoding bei einer MTP-Akzeptanzrate von 65 %. Das maximale Kontextfenster beträgt hier 220.000 Token mit q8_0-KV-Cache. vLLM 0.28.0 nutzte das NVFP4-Modell (21 GB) und lieferte rund 110 tok/s, ist aber auf 122.880 Token Kontext beschränkt, da CUDA-Graph-Capture auf 16-GB-Karten mehr Overhead erzeugt. NInfer (Fork wamansou/ninfer-tp2-1m), ursprünglich nur für die RTX 5090 (sm_120a) dokumentiert, lief ohne Anpassungen auf den 5070 Ti (sm_120) und erreichte 60,3 tok/s ohne bzw. ~97,5 tok/s mit MTP3 – bei einem nativen Kontextfenster von bis zu 262.000 Token. Ein zentraler praktischer Befund: Der vLLM-Flag --enforce-eager reduziert den Durchsatz auf Blackwell-GPUs von ~110 auf 9,6 tok/s – ein Faktor 11, der leicht übersehen wird.
- llama.cpp Single-GPU-Prefill: 1.835 tok/s (pp512); mit Tensor-Split auf 2 GPUs sinkt pp512 auf 1.711 tok/s, pp8192 auf 1.039 tok/s.
- vLLM benötigt MAX_JOBS=1 vor dem Start, da FlashInfers JIT-Kompilierung der NVFP4-CUTLASS-Kernel sonst OOM-Kill auslöst.
- NInfer MTP-Sweep: 1 Draft-Token → 91,0 tok/s (68% Akzeptanz); 3 Draft-Tokens → 97,5 tok/s (41% Akzeptanz) – Mehrwert flacht ab 3 Tokens ab.
- vLLM-Flag --kv-cache-memory 2500000000 reserviert explizit 2,5 GB KV-Cache pro GPU und verhindert Auto-Sizing-OOM bei 16-GB-Karten.
- NInfer ist eine eigenständige C++/CUDA-Engine ohne Abhängigkeit von llama.cpp oder vLLM; der sm_120a-Code läuft laut Test fehlerfrei auf sm_120 (5070 Ti).
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Qwen3.8-27B auf 2× RTX 5070 Ti: llama.cpp vs vLLM vs NInfer im Vergleich
Der Benchmark wurde auf einem Selbstbau-Workstation mit AMD Ryzen 7 5800X, 64 GB DDR4 und zwei RTX 5070 Ti (je 16 GB, PCIe 4.0 x8/x8, Blackwell-Architektur sm_120) durchgeführt – ohne NVLink, mit PHB-Topologie und host-gesteuerten Kopien für die Multi-GPU-Kommunikation. Betriebssystem war Ubuntu 26.04 mit CUDA 13.3 und Treiber 595.84. Bei llama.cpp wurde das Modell als unsloth/Qwen3.8-27B-GGUF in Q4_K_XL-Quantisierung (17,6 GB) eingesetzt; mit Tensor-Split über beide GPUs erreichte es 71,7 tok/s ohne und 110–115 tok/s mit MTP3-spekulativem Decoding bei einer MTP-Akzeptanzrate von 65 %. Das maximale Kontextfenster beträgt hier 220.000 Token mit q8_0-KV-Cache. vLLM 0.28.0 nutzte das NVFP4-Modell (21 GB) und lieferte rund 110 tok/s, ist aber auf 122.880 Token Kontext beschränkt, da CUDA-Graph-Capture auf 16-GB-Karten mehr Overhead erzeugt. NInfer (Fork wamansou/ninfer-tp2-1m), ursprünglich nur für die RTX 5090 (sm_120a) dokumentiert, lief ohne Anpassungen auf den 5070 Ti (sm_120) und erreichte 60,3 tok/s ohne bzw. ~97,5 tok/s mit MTP3 – bei einem nativen Kontextfenster von bis zu 262.000 Token. Ein zentraler praktischer Befund: Der vLLM-Flag --enforce-eager reduziert den Durchsatz auf Blackwell-GPUs von ~110 auf 9,6 tok/s – ein Faktor 11, der leicht übersehen wird.
- llama.cpp Single-GPU-Prefill: 1.835 tok/s (pp512); mit Tensor-Split auf 2 GPUs sinkt pp512 auf 1.711 tok/s, pp8192 auf 1.039 tok/s.
- vLLM benötigt MAX_JOBS=1 vor dem Start, da FlashInfers JIT-Kompilierung der NVFP4-CUTLASS-Kernel sonst OOM-Kill auslöst.
- NInfer MTP-Sweep: 1 Draft-Token → 91,0 tok/s (68% Akzeptanz); 3 Draft-Tokens → 97,5 tok/s (41% Akzeptanz) – Mehrwert flacht ab 3 Tokens ab.
- vLLM-Flag --kv-cache-memory 2500000000 reserviert explizit 2,5 GB KV-Cache pro GPU und verhindert Auto-Sizing-OOM bei 16-GB-Karten.
- NInfer ist eine eigenständige C++/CUDA-Engine ohne Abhängigkeit von llama.cpp oder vLLM; der sm_120a-Code läuft laut Test fehlerfrei auf sm_120 (5070 Ti).
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.