vLLM รัน GGUF ได้ไหม? ได้ — แต่ต้องบน GPU เท่านั้น

สัปดาห์ที่แล้วมีผู้อ่านถามว่าทำไมไฟล์ GGUF ของเขาถึงล้มใน vLLM บนเครื่องที่ไม่มี GPU ทั้งที่ไฟล์เดียวกันรันได้ลื่นใน Ollama คำตอบสั้น ๆ ก่อนอย่างอื่น: ได้ vLLM รัน GGUF ได้ — ผ่านปลั๊กอินทางการ บน GPU เท่านั้น ปลั๊กอินชื่อ vllm-gguf-plugin syntax คือ repo:quant_type พอคุณลองบน CPU คุณก็ออกนอกตารางฮาร์ดแวร์ที่รองรับไปแล้ว ทุกอย่างด้านล่างมาจากเอกสารของ vLLM และประวัติของรีโป vllm-project/vllm (กว่า 92,000 ดาวตั้งแต่เดือนกุมภาพันธ์ 2023) — จากเอกสาร ไม่ใช่จากเครื่องทดสอบของผม

จะ serve โมเดล GGUF ด้วย vLLM อย่างไร?

สองขั้น: ติดตั้งปลั๊กอิน แล้วชี้ vLLM ไปที่โมเดล การรองรับ GGUF ไม่ได้อาศัยอยู่ในแกนของ vLLM อีกต่อไป — เอกสารระบุว่ามัน “ย้ายไปที่ vllm-gguf-plugin” แล้ว pip install vllm อย่างเดียวจึงไม่พอ:

uv pip install vllm-gguf-plugin

# โหลดตรงจาก Hugging Face ด้วยรูปแบบ repo_id:quant_type:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# หรือใช้ไฟล์ในเครื่องที่โหลดไว้แล้ว:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

flag --tokenizer ไม่ใช่ของตกแต่ง เอกสารทางการแนะนำให้ใช้ tokenizer ของโมเดลต้นแบบ เพราะการแปลง tokenizer จาก GGUF “กินเวลาและไม่เสถียร โดยเฉพาะกับโมเดลที่มีคลังคำศัพท์ใหญ่” ข้ามมันไปเท่ากับแลก flag หนึ่งบรรทัดกับการเริ่มระบบที่ยาวและอารมณ์เสีย

สอง GPU หนึ่งโมเดล: เพิ่ม --tensor-parallel-size 2 เพื่อกระจาย GGUF ตัวเดิมลงทั้งสองการ์ด — tensor parallelism ทำงานกับ GGUF เหมือนกับทุกฟอร์แมตอื่น

ทำไม vLLM ถึงปฏิเสธ GGUF บน CPU?

ตรงนี้แหละที่ทำให้หลายคนตกใจ ชื่อเสียงของ GGUF คือ CPU มาก่อน — เป็นฟอร์แมตที่ llama.cpp สร้างชื่อบนแล็ปท็อปและ Raspberry Pi แต่ใน vLLM สถานการณ์กลับด้าน ตารางความเข้ากันได้ทางการให้คะแนน GGUF แบบนี้:

ฮาร์ดแวร์	GGUF ใน vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	รองรับ
GPU ของ AMD	รองรับ
GPU ของ Intel	ไม่รองรับ
CPU x86	ไม่รองรับ
CPU Arm	ไม่รองรับ

ที่มา: เอกสาร quantization ของ vLLM เหตุผลอยู่ที่สถาปัตยกรรม: เส้นทาง GGUF ของ vLLM ถอด quant บล็อกต่าง ๆ เข้าสู่ kernel ของ GPU ที่ออกแบบมาเพื่อการ serve แบบเป็นชุด ไม่มี kernel สำหรับ CPU อยู่เบื้องหลัง — เพราะ vLLM คือเอนจินเพื่อการ serve ไม่ใช่ของเล่นบนแล็ปท็อป เครื่องไหนไม่มี GPU ต่อให้ใส่ flag ไหนก็ไม่รอด — ใช้ llama.cpp ครับ

อะไรพัง: รายการข้อจำกัดแบบไม่อวย

หน้าเอกสารเดียวกันมีคำเตือนที่ควรอ้างแบบคำต่อคำ: “การรองรับ GGUF ใน vLLM ยังเป็นแบบทดลองอย่างสูงและยังไม่ได้รับการปรับแต่ง” จับตัวเป็นข้อ ๆ:

• ความครอบคลุมของ quant แคบกว่า llama.cpp K-quant ที่ทุกคนโหลดกัน (Q4_K_M และเพื่อนพ้อน) ใช้ได้ ส่วนสกีมแปลก ๆ ไม่แน่เสมอไป ตัว reference implementation ของฟอร์แมตนี้ยังเป็น llama.cpp
• การรองรับสถาปัตยกรรมตามหลัง ตระกูลโมเดลใหม่ลงถึง llama.cpp ก่อน ปลั๊กอินค่อยตามไป
• ไม่มี lazy loading แบบ mmap llama.cpp map ไฟล์เข้าหน่วยความจำ ส่วน vLLM โหลดเหมือน checkpoint ทั่วไป
• เบื้องต้นแล้วคือฟีเจอร์ประหยัดหน่วยความจำ เอกสารวาง GGUF เป็นวาลลดการกิน VRAM ไม่ใช่เกมส์ทาง throughput

ไม่มีอะไรถูกซ่อนเลย ทุกอย่างอยู่ในย่อหน้าแรกของ หน้า GGUF ทางการ — ตรงไปตรงมากว่าฟีเจอร์ทดลองส่วนใหญ่เสียอีก

GGUF ระหว่าง vLLM กับ llama.cpp: ใครชนะ?

เครื่องมือต่างกันที่อ่านไฟล์เดียวกัน:

	vLLM + GGUF	llama.cpp
inference บน CPU	ไม่ได้	ได้ เต็มขั้น
ผู้ใช้พร้อมกัน	continuous batching ออกแบบมาเพื่อสิ่งนี้	จำกัด
ความครอบคลุม quant	เซตย่อย ยังทดลอง	คือมาตรฐานอ้างอิง
การติดตั้ง	vLLM + ปลั๊กอิน	ไบนารีตัวเดียว
เหมาะที่สุดกับ	GPU หนึ่งตัว ผู้ใช้หลายคน	ผู้ใช้หนึ่งคน ฮาร์ดแวร์อะไรก็ได้

ถ้าคุณ serve โมเดลให้ทีมจาก GPU ตัวเดียว vLLM + GGUF ทำให้คุณใช้ไฟล์ Q4_K_M ชุดเดียวกับที่โลก local-LLM ทั้งใบแชร์กันอยู่ — ทางเลือกเพิ่มเติมอยู่ใน คู่มือ quantization ของ GGUF ส่วนเปรียบเทียบเอนจินแบบเต็มดูที่ llama.cpp vs Ollama และ วิธีรันโมเดล GGUF ในเครื่อง

กฎหนึ่งบรรทัด: ไฟล์เดียวกัน สัญชาตญาณตรงข้าม — llama.cpp ถือว่า GGUF คือฟอร์แมตหลัก ส่วน vLLM ถือว่ามันเป็นแค่หนึ่งในตัวเลือก