Bisakah vLLM menjalankan GGUF? Bisa — hanya di GPU

Minggu lalu seorang pembaca bertanya kenapa file GGUF-nya gagal di vLLM pada mesin tanpa GPU, padahal file yang sama jalan mulus di Ollama. Jawaban singkat, sebelum apa pun: ya, vLLM menjalankan GGUF — lewat plugin resmi, hanya di GPU. Pluginnya bernama vllm-gguf-plugin, sintaksnya repo:quant_type, dan begitu Anda mencobanya di CPU, Anda keluar dari tabel hardware yang didukung. Semua di bawah ini berasal dari dokumentasi vLLM dan riwayat repositori vllm-project/vllm (92.000+ bintang sejak Februari 2023) — dari dokumen, bukan dari rig pengujian saya.

Bagaimana menyajikan model GGUF dengan vLLM?

Dua langkah: pasang plugin, lalu arahkan vLLM ke model. Dukungan GGUF tidak lagi tinggal di inti vLLM — dokumentasi mencatat ia “telah bermigrasi ke vllm-gguf-plugin”, jadi sekadar pip install vllm tidak cukup:

uv pip install vllm-gguf-plugin

# Langsung dari Hugging Face, format repo_id:quant_type:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# Atau file lokal yang sudah diunduh:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

Flag --tokenizer bukan hiasan. Dokumentasi resmi menyarankan tokenizer dari model dasar karena konversi tokenizer GGUF “memakan waktu dan tidak stabil, terutama untuk model dengan kosakata besar”. Melewatannya berarti menukar satu flag dengan proses mulai yang panjang dan rewel.

Dua GPU, satu model: tambahkan --tensor-parallel-size 2 untuk memecah GGUF yang sama ke kedua kartu — tensor parallelism bekerja dengan GGUF sama seperti format lain.

Kenapa vLLM menolak GGUF di CPU?

Inilah bagian yang mengejutkan. Reputasi GGUF adalah CPU dulu — itulah format yang menjadi fondasi nama llama.cpp, berjalan di laptop dan Raspberry Pi. Di dalam vLLM keadaannya terbalik. Tabel kompatibilitas hardware resmi menandai GGUF:

Hardware	GGUF di vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	didukung
GPU AMD	didukung
GPU Intel	tidak didukung
CPU x86	tidak didukung
CPU Arm	tidak didukung

Sumber: dokumentasi kuantisasi vLLM. Alasannya arsitektural: jalur GGUF vLLM mendekuantisasi blok ke kernel GPU yang dibangun untuk serving per batch. Tak ada kernel CPU di belakangnya — sebab vLLM adalah mesin serving, bukan mainan laptop. Tanpa GPU, tak ada flag yang menolong — pakai llama.cpp.

Apa yang rusak: daftar batas yang jujur

Halaman dokumentasi yang sama memuat peringatan yang layak dikutip apa adanya: “dukungan GGUF di vLLM sangat eksperimental dan belum teroptimasi.” Secara konkret:

• Cakupan kuantisasi lebih sempit daripada llama.cpp. K-quant yang semua orang unduh (Q4_K_M dan kawan-kawan) berfungsi; skema eksotis belum tentu. llama.cpp tetap implementasi referensi untuk format ini.
• Dukungan arsitektur tertinggal. Keluarga model baru mendarat di llama.cpp lebih dulu; plugin menyusul.
• Tidak ada lazy loading ala mmap. llama.cpp memetakan file ke memori; vLLM memuatnya seperti checkpoint lain.
• Ini sebelum segalanya fitur jejak memori. Dokumentasi membingkai GGUF sebagai cara menekan pemakaian VRAM, bukan taruhan throughput.

Tidak ada yang disembunyikan. Semuanya ada di paragraf pertama halaman GGUF resmi — lebih terbuka daripada kebanyakan fitur eksperimental.

vLLM atau llama.cpp untuk GGUF: siapa menang?

Dua alat berbeda yang membaca file yang sama:

	vLLM + GGUF	llama.cpp
Inferensi CPU	tidak	ya, kelas satu
Pengguna bersamaan	continuous batching, memang dibuat untuk itu	terbatas
Cakupan quant	subset, eksperimental	referensinya
Pemasangan	vLLM + plugin	satu biner
Paling cocok untuk	satu GPU, banyak pengguna	satu pengguna, hardware apa pun

Jika Anda menyajikan model untuk satu tim dari satu GPU, vLLM + GGUF memungkinkan Anda memakai ulang file Q4_K_M yang sama dengan seluruh dunia local-LLM — dengan lebih banyak pilihan di panduan kuantisasi GGUF kami. Untuk perbandingan engine lengkap, lihat llama.cpp vs Ollama dan cara menjalankan model GGUF secara lokal.

Aturan satu baris: file yang sama, naluri berlawanan — llama.cpp memperlakukan GGUF sebagai formatnya, vLLM sebagai salah satu opsi.