آیا vLLM می‌تواند GGUF را اجرا کند؟ بله — فقط روی GPU

هفته پیش خواننده‌ای پرسید چرا فایل GGUF او روی ماشینی بدون GPU در vLLM شکست می‌خورد، در حالی که همان فایل در Ollama بی‌دردسر اجرا می‌شود. پاسخ کوتاه، پیش از هر چیز: بله، vLLM می‌تواند GGUF را اجرا کند — از طریق پلاگین رسمی، فقط روی GPU. نام پلاگین vllm-gguf-plugin است و سینتکس repo:quant_type؛ به محض اینکه روی CPU امتحانش کنید، از جدول سخت‌افزار پشتیبانی‌شده بیرون افتاده‌اید. همهٔ آنچه می‌آید از مستندات vLLM و سابقهٔ مخزن vllm-project/vllm است (بیش از ۹۲ هزار ستاره از فوریه ۲۰۲۳) — از مستندات، نه از میز تست من.

چگونه یک مدل 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

پرچم --tokenizer تزئین نیست. مستندات رسمی توکنایزر مدل پایه را توصیه می‌کنند، چون تبدیل توکنایزر از GGUF «زمان‌بر و ناپایدار است، مخصوصاً برای مدل‌هایی با واژگان بزرگ». حذفش یعنی معاوضهٔ یک پرچمِ یک‌خطی با استارت‌آپی طولانی و کلافه‌کننده.

دو GPU، یک مدل: --tensor-parallel-size 2 را اضافه کنید تا همان GGUF روی هر دو کارت پخش شود — موازی‌سازی تنسوری با GGUF مثل هر فرمت دیگری کار می‌کند.

چرا vLLM روی CPU سرِ GGUF زیر می‌زند؟

این همان بخشی است که غافلگیر می‌کند. اعتبار GGUF اول CPU است — فرمتی که llama.cpp نامش را روی لپ‌تاپ‌ها و Raspberry Pi با آن ساخت. اما درون vLLM جایگاه برعکس می‌شود. جدول رسمی سازگاری سخت‌افزار GGUF را این‌طور علامت می‌زند:

سخت‌افزار	GGUF در vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	پشتیبانی می‌شود
GPU ای‌ام‌دی	پشتیبانی می‌شود
GPU اینتل	پشتیبانی نمی‌شود
CPU x86	پشتیبانی نمی‌شود
CPU Arm	پشتیبانی نمی‌شود

منبع: مستندات کوانتیزاسیون vLLM. دلیل معماری است: مسیر GGUF در vLLM بلوک‌ها را به کرنل‌های GPU که برای سرو دهی دسته‌ای طراحی شده‌اند دی‌کوانتیزه می‌کند. پشتش هیچ کرنل CPUای نیست — چون vLLM یک موتور سرو است، نه اسباب‌بازی لپ‌تاپ. ماشینی بدون GPU، هیچ پرچمی نجاتش نمی‌دهد — از llama.cpp استفاده کنید.

چه چیزی می‌شکند: فهرست صادقانهٔ محدودیت‌ها

همان صفحهٔ مستندات هشداری دارد که ارزش نقل مستقیم دارد: «پشتیبانی GGUF در vLLM به‌شدت آزمایشی و کم‌بهینه است». به‌طور مشخص:

• پوشش کوانتیزاسیون باریک‌تر از llama.cpp است. K-quantهایی که همه دانلود می‌کنند (Q4_K_M و رفقایش) کار می‌کنند؛ اسکیم‌های عجیب همیشه نه. پیاده‌سازی مرجعِ فرمت همچنان llama.cpp است.
• پشتیبانی معماری‌ها عقب می‌ماند. خانواده‌های مدل جدید اول به llama.cpp می‌رسند؛ پلاگین بعداً می‌رسد.
• بارگذاری تنبل به سبک mmap وجود ندارد. llama.cpp فایل را در حافظه نگاشت می‌کند؛ vLLM مثل هر چک‌پوینت دیگری بارگذاری‌اش می‌کند.
• در نگاه اول یک قابلیتِ جای‌گیری حافظه است. مستندات GGUF را راهی برای پایین آوردن مصرف VRAM قاب می‌کند، نه شرط‌بندی روی throughput.

هیچ‌کدام از این‌ها پنهان نیست. همه در پاراگراف اولِ صفحهٔ رسمی GGUF هست — صادق‌تر از بیشتر قابلیت‌های آزمایشی.

GGUF با vLLM یا llama.cpp: کی می‌برد؟

دو ابزار متفاوت که یک فایل را می‌خوانند:

	vLLM + GGUF	llama.cpp
استنتاج روی CPU	نه	بله، درجه یک
کاربران همزمان	continuous batching، دقیقاً برای همین ساخته شده	محدود
پوشش کوانت	زیرمجموعه، آزمایشی	مرجع
نصب	vLLM + پلاگین	یک باینری
بهترین کاربرد	یک GPU، کاربران زیاد	یک کاربر، هر سخت‌افزاری

اگر از یک GPU برای تیم مدل سرو می‌کنید، vLLM + GGUF اجازه می‌دهد همان فایل‌های Q4_K_M را دوباره استفاده کنید که کل دنیای local-LLM در میان می‌گذارد — با انتخاب‌های بیشتر در راهنمای کوانتیزاسیون GGUF ما. برای مقایسهٔ کامل موتورها ببینید llama.cpp مقابل Ollama و نحوهٔ اجرای محلی مدل‌های GGUF.

قاعدهٔ یک‌خطی: همان فایل، غریزه‌های متضاد — llama.cpp با GGUF مثل «فرمت اصلی» رفتار می‌کند، vLLM مثل یکی از گزینه‌ها.