هل يشغّل vLLM ملفات GGUF؟ عشر أسئلة، والإجابات أولًا

يشغّل vLLM ملفات GGUF عبر الإضافة الرسمية vllm-gguf-plugin، وعلى معالجات NVIDIA وAMD فقط. وصيغة التشغيل هي repo:quant_type مع --tokenizer إلزاميٍّ يشير إلى النموذج الأصلي. وعلى المعالجات يبقى llama.cpp هو الجواب.

بطاقة واحدة تخدم عدة أشخاص ← vLLM + vllm-gguf-plugin. شخص واحد، أي جهاز، أوسع اختيار للضغط ← llama.cpp بملفّه التنفيذي الواحد. لا بطاقة أو كرت Intel ← llama.cpp، فالمعالجات لديه مواطنة كاملة. وكلا المحركين يقرأ GGUF نفسه؛ والفارق فيما يُحسِّن كلاً منهما — فاختر حسب الجهاز وعدد المستخدمين، لا حسب صيغة الملف.

نعم — عبر الإضافة الرسمية vllm-gguf-plugin، وعلى معالجات NVIDIA وAMD. والإضافة من صنع فريق vLLM نفسه، لا شوكةً مجتمعية. والنصفان مهمان معًا: الإضافة رسمية، وجدول الأجهزة يتوقف عند البطاقات.

لا. فليس وراء مسار GGUF في vLLM أي نواة للمعالجات — فمعالجات x86/Arm وكرت Intel يقفان خارج جدول الأجهزة المدعومة. وهنا الفخ الذي يكمن خلف البلاغ المألوف: ملف GGUF نفسه الذي يعطي 404 في vLLM على حاشية محمولة يعمل بسلاسة في Ollama، لأن الموطن الأصلي للصيغة هو المحركات التي تُعلي المعالجات. الملف لم يكن يومًا هو المشكلة.

سطر واحد — المستودع، ونوع الضغط، والـtokenizer:

vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B

الصيغة هي repo:quant_type. والفخ يقع في خيار --tokenizer: فهو يسمّي مستودع النموذج الأصلي، لا مستودع GGUF أبدًا — ملفات GGUF تحمل الأوزان، وvLLM يريد الـtokenizer الحقيقي من النموذج المصدر.

الضغطات من عائلة K التي ينزّلها الناس فعلًا — Q4_K_M وأخواتها — تعمل؛ أما المخططات النادرة فقد لا تعمل. ويظل llama.cpp هو التنفيذ المرجعي للصيغة، لذا تنزل المخططات والمعماريات الجديدة فيه أولًا ثم تصل إلى الإضافة لاحقًا.

الوثائق تجيب عن هذا السؤال بنفسها: "دعم GGUF في vLLM تجريبيٌّ إلى حدٍّ بعيد وغير مُحسَّن بعد." وهذه الجملة تجلس في الفقرة الأولى من صفحة الصيغة الرسمية — وهي نسبة صدقٍ تفوق ما تناله أغلب الخصائص التجريبية. فتعامل مع الإضافة بوصفها وسيلة لإعادة استعمال ملفات لديك أصلًا، واترك باب الرجوع إلى llama.cpp مفتوحًا.

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

ثلاثة أسباب حقيقية: صيغة تشغيل خاطئة (مسارٌ عاديٌّ بدل repo:quant_type)، أو --tokenizer غائبٌ أو مخطأ، أو جهازٌ خارج جدول الدعم. وسبب رابع يظهر أقل: مخطط ضغطٍ لا تغطيه الإضافة. فامشِ في الجدول أدناه من أعلى إلى أسفل — ثلاثة صفوف أولى تكفي أغلب البلاغات.

نعم — وبشكل أصيل؛ فالصيغة هي الصيغة الافتراضية لـOllama، لا إضافةً عليه. اسحب ملفًا من Hugging Face، ووجّه Ollama إليه، وهناك ينتهي الأمر. وإن بقت البطاقة عاطلةً أثناء العمل، فتلك مشكلةٌ مختلفة لها قائمة تدقيقها.

تلك هي الوظيفة الوحيدة التي وُجد vLLM من أجلها: فالتجميعُ المستمر يصنع طابورًا للطلبات المتزامنة أمام نموذجٍ محمَّلٍ مرة واحدة. والإضافة ترث تلك الآلية بأكملها — والتحفّط الصادق هو سطر الوثائق ذاتها "غير مُحسَّن بعد"، لذا فإن كنت تقدّر خادمًا مشتركًا فعاين ضغطتك على بطاقتك قبل أن توعد أحدًا برقم. وفخٌّ آخر: ملفٌّ يخدم مستخدمًا واحدًا على نحوٍ ممتاز قد يتجاوز سعة الذاكرة رغمًا عنها حين يتضاعف مخزون المفاتيح مع كل طلبٍ متزامن — فالأوزان تقلصت، والمخزون يكبر مع كل مستخدم. أنقص التزامن، أو قصّر السياق، أو انزل درجةً في الضغط.