هل يشغّل vLLM صيغة GGUF؟ نعم — على GPU فقط

الأسبوع الماضي سأل قارئٌ لماذا يفشل ملف GGUF الخاص به داخل vLLM على جهاز بلا GPU، بينما يعمل الملف نفسه بلا مشاكل في Ollama. الجواب المختصر قبل كل شيء: نعم، vLLM يشغّل GGUF — عبر إضافة رسمية، وعلى GPU فقط. الإضافة اسمها vllm-gguf-plugin، والصيغة repo:quant_type؛ ومجرّد أن تجرّبها على المعالج تكون قد خرجت من جدول العتاد المدعوم. كل ما يلي من وثائق vLLM وسجل مستودع vllm-project/vllm (أكثر من 92 ألف نجمة منذ فبراير 2023) — من الوثائق، لا من منصّة اختباري.

كيف تقدّم نموذج 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 ليس زينة. توصي الوثائق الرسمية باستخدام tokenizer النموذج الأساسي، لأن تحويل الـtokenizer من GGUF «مُستهلك للوقت وغير مستقر، خصوصًا مع النماذج ذات المعاجم الكبيرة». إسقاطه يعني استبدال خيار من سطر واحد ببدء تشغيل طويل صعب المزاج.

بطاقتا GPU ونموذج واحد: أضف --tensor-parallel-size 2 لتقسيم ملف GGUF نفسه على البطاقتين — التوازي الشريحي يعمل مع GGUF كما مع أي صيغة أخرى.

لماذا يرفض vLLM صيغة GGUF على المعالج؟

هذا الجزء هو المُفاجئ. سمعة GGUF أنّه للمعالج أولًا — إنها الصيغة التي بنت llama.cpp اسمها عليها في الحواسيب المحمولة وRaspberry Pi. لكن داخل vLLM ينقلب الموقف. جدول التوافق الرسمي للعتاد يعلّم GGUF هكذا:

العتاد	GGUF في vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	مدعوم
GPU من AMD	مدعوم
GPU من Intel	غير مدعوم
معالج x86	غير مدعوم
معالج Arm	غير مدعوم

المصدر: وثائق الضغط الكمّي في vLLM. السبب معماري: مسار GGUF في vLLM يفكّ ضغط الكتل إلى نوى GPU مصممة للخدمة بالدفعات. لا توجد نواة معالج خلفها — لأن vLLM محرّك خدمة، لا لعبة حاسوب محمول. بلا GPU في الجهاز لا ينقذك أي خيار — استخدم llama.cpp.

ما الذي ينكسر: قائمة الحدود بصراحة

تحمل الصفحة نفسها من الوثائق تحذيرًا يستحق الاقتباس حرفيًا: «دعم GGUF في vLLM تجريبي للغاية وغير مُحسَّن بشكل كافٍ». وعلى سبيل التحديد:

• تغطية أنواع الضغط أضيق من llama.cpp. أنواع K-quant التي ينزّلها الجميع (Q4_K_M وأخواتها) تعمل؛ المخططات النادرة ليست دائمًا كذلك. llama.cpp يبقى التطبيق المرجعي للصيغة.
• دعم المعماريات يتأخر. عائلات النماذج الجديدة تصل أولًا إلى llama.cpp؛ والإضافة تلحق بها لاحقًا.
• لا تحميلًا كسولًا بنمط mmap. llama.cpp يربط الملف بالذاكرة مباشرة؛ أما vLLM فيحمّله كأي نسخة محفوظة.
• هو أولًا ميزة لتقليص الذاكرة. تقدّم الوثائق GGUF كوسيلة لخفض استهلاك VRAM، لا كرهان على معدل النقل.

لا شيء من هذا مخفي. كله في الفقرة الأولى من صفحة GGUF الرسمية — وهي أصدق من معظم الميزات التجريبية.

GGUF مع vLLM أم llama.cpp: من يفوز؟

أداتان مختلفتان تقرآن الملف نفسه:

	vLLM + GGUF	llama.cpp
الاستدلال على المعالج	لا	نعم، من الطبقة الأولى
مستخدمون متزامنون	دفعات متصلة، صُمم لأجلها	محدود
تغطية أنواع الضغط	جزء فرعي، تجريبي	المرجع
التثبيت	vLLM + إضافة	ملف تنفيذي واحد
الأنسب لـ	بطاقة واحدة، مستخدمون كثر	مستخدم واحد، أي عتاد

إن كنت تقدّم نموذجًا لفريق من بطاقة واحدة، فأن vLLM + GGUF يتيح لك إعادة استخدام ملفات Q4_K_M نفسها التي يتقاسمها عالم النماذج المحلية — مع خيارات أكثر في دليلنا للضغط الكمّي GGUF. وللمقارنة الكاملة بين المحرّكات راجع llama.cpp مقابل Ollama وكيفية تشغيل نماذج GGUF محليًا.

القاعدة في سطر واحد: الملف نفسه، فطرتان متعاكستان — llama.cpp يعامل GGUF كأنه الصيغة الأم، وvLLM يعامله كخيار من الخيارات.