vLLM vs. llama.cpp: 5×-Prefill-Speed, aber GGUF-Kompatibilität fehlt
Ein Reddit-Nutzer (u/superloser48) testet Qwen3.6-35B-A3B auf einer RTX A6000 (48 GB, Ampere-Architektur) und misst mit vLLM Prefill-Raten von 5.000–10.000 Tokens/Sekunde gegenüber 800–1.000 Tokens/Sekunde mit llama.cpp – ein Faktor 5–10×. Für seinen konkreten Anwendungsfall (Pandas-Code-Generierung) liefert das offizielle FP8-Quant von Qwen schlechtere Ergebnisse als Unsloths Q8-GGUF-Quant; alle getesteten Q4-AWQ/GPTQ-Varianten scheiden für ihn komplett aus. Das Problem: Unsloth stellt seit einiger Zeit keine SafeTensors oder andere non-GGUF-Formate mehr bereit, und vLLM unterstützt GGUF-Architekturen nicht – der Versuch mit Single-File-GGUFs für Gemma 4 und Qwen3.6 MoE schlägt jeweils mit einem „unsupported architecture"-Fehler fehl. Der Post beleuchtet eine praktisch relevante Lücke im lokalen Inferenz-Stack: Quantisierungsqualität, Format-Ökosystem und Engine-Kompatibilität sind derzeit nicht gleichzeitig optimierbar.
- Benchmark-Hardware: RTX A6000 48 GB (Ampere), Modell: Qwen3.6-35B-A3B
- Prefill-Speed: llama.cpp 800–1.000 t/s vs. vLLM 5.000–10.000 t/s
- Unsloth Q8-GGUF schlägt offizielles FP8-Quant bei Pandas-Code-Generierung
- Unsloth liefert aktuell keine SafeTensors/non-GGUF-Formate mehr
- vLLM gibt bei GGUF-Einzeldateien (Gemma 4, Qwen3.6 MoE) Fehler 'unsupported architecture'
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
vLLM vs. llama.cpp: 5×-Prefill-Speed, aber GGUF-Kompatibilität fehlt
Ein Reddit-Nutzer (u/superloser48) testet Qwen3.6-35B-A3B auf einer RTX A6000 (48 GB, Ampere-Architektur) und misst mit vLLM Prefill-Raten von 5.000–10.000 Tokens/Sekunde gegenüber 800–1.000 Tokens/Sekunde mit llama.cpp – ein Faktor 5–10×. Für seinen konkreten Anwendungsfall (Pandas-Code-Generierung) liefert das offizielle FP8-Quant von Qwen schlechtere Ergebnisse als Unsloths Q8-GGUF-Quant; alle getesteten Q4-AWQ/GPTQ-Varianten scheiden für ihn komplett aus. Das Problem: Unsloth stellt seit einiger Zeit keine SafeTensors oder andere non-GGUF-Formate mehr bereit, und vLLM unterstützt GGUF-Architekturen nicht – der Versuch mit Single-File-GGUFs für Gemma 4 und Qwen3.6 MoE schlägt jeweils mit einem „unsupported architecture"-Fehler fehl. Der Post beleuchtet eine praktisch relevante Lücke im lokalen Inferenz-Stack: Quantisierungsqualität, Format-Ökosystem und Engine-Kompatibilität sind derzeit nicht gleichzeitig optimierbar.
- Benchmark-Hardware: RTX A6000 48 GB (Ampere), Modell: Qwen3.6-35B-A3B
- Prefill-Speed: llama.cpp 800–1.000 t/s vs. vLLM 5.000–10.000 t/s
- Unsloth Q8-GGUF schlägt offizielles FP8-Quant bei Pandas-Code-Generierung
- Unsloth liefert aktuell keine SafeTensors/non-GGUF-Formate mehr
- vLLM gibt bei GGUF-Einzeldateien (Gemma 4, Qwen3.6 MoE) Fehler 'unsupported architecture'
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.