mrsaynothing.dev
أسئلة شائعة عن vLLM وGGUF: عشرة أسئلة من البحث، والإجابات
عشرة أسئلة بحثية حقيقية عن vLLM وGGUF — دعم المعالجات، صيغة التشغيل، تغطية الضغط، فخ الـtokenizer — تجيب عنها الوثائق ومقالاتنا المختبَرة.
قائمة تحقّق الخمس دقائق
لأنماط الإخفاق جدول — فامشِ فيه من أعلى إلى أسفل.
| العرض | السبب | العلاج |
|---|---|---|
404 أو "model not found" عند التشغيل |
مُرِّر الملف مسارًا عاديًا — وvLLM يريد repo:quant_type |
استعمل صيغة repo:quant_type (القسم التالي) |
| خطأ في الـtokenizer عند التحميل | خيار --tokenizer غائب أو مشير إلى مستودع GGUF |
وجّهه إلى مستودع النموذج الأصلي |
| يعمل في Ollama/llama.cpp ويرفض في vLLM | الملف نفسه والمحرك مختلف — ومسار GGUF في vLLM للبطاقات فقط | أجهزة المعالجات تبقى على llama.cpp |
| رُفض مخطط الضغط عند التحميل | ضغطٌ نادرٌ خارج تغطية الإضافة | انزل إلى Q4_K_M أو أخواتها — انظر دليل الضغط الكمّي |
Can vLLM run GGUF ?
نعم — عبر الإضافة الرسمية vllm-gguf-plugin، وعلى معالجات NVIDIA وAMD. والإضافة من صنع فريق vLLM نفسه، لا شوكةً مجتمعية. والنصفان مهمان معًا: الإضافة رسمية، وجدول الأجهزة يتوقف عند البطاقات. والمشي الكامل للتشغيل يسكن Can vLLM Run GGUF? Yes — on GPU Only.
هل يدعم vLLM صيغة GGUF على المعالجات؟
لا. فليس وراء مسار GGUF في vLLM أي نواة للمعالجات — فمعالجات x86/Arm وكرت Intel يقفان خارج جدول الأجهزة المدعومة. وهنا الفخ الذي يكمن خلف البلاغ المألوف: ملف GGUF نفسه الذي يعطي 404 في vLLM على حاشية محمولة يعمل بسلاسة في Ollama، لأن الموطن الأصلي للصيغة هي المحركات التي تُعلي المعالجات. والملف لم يكن يومًا هو المشكلة.
كيف تُشغِّل نموذج GGUF بواسطة vLLM؟
سطر واحد — المستودع، ونوع الضغط، والـtokenizer:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B
الصيغة هي repo:quant_type. والفخ يقع في خيار --tokenizer: فهو يسمّي مستودع النموذج الأصلي، لا مستودع GGUF أبدًا — ملفات GGUF تحمل الأوزان، وvLLM يريد الـtokenizer الحقيقي من النموذج المصدر.
متطلب التحقق: شغِّله ثم نفّذ nvidia-smi — فينبغي أن تجد العملية تشغل ذاكرة الشاشة لا ذاكرة النظام.
أي ضغطات GGUF يدعمها vLLM؟
الضغطات من عائلة K التي ينزّلها الناس فعلًا — Q4_K_M وأخواتها — تعمل؛ أما المخططات النادرة فقد لا تعمل. ويظل llama.cpp هو التنفيذ المرجعي للصيغة، لذا تنزل المخططات والمعماريات الجديدة فيه أولًا ثم تصل إلى الإضافة لاحقًا. وقبل تنزيل أي شيء، قدِّر حجمه بواسطة دليل الضغط الكمّي لـGGUF.
هل دعم vLLM للصيغة جاهز للإنتاج؟
الوثائق تجيب عن هذا السؤال بنفسها: "دعم GGUF في vLLM تجريبيٌّ إلى حدٍّ بعيد وغير مُحسَّن بعد." وهذه الجملة تجلس في الفقرة الأولى من صفحة الصيغة الرسمية — وهي نسبة صدقٍ تفوق ما تناله أغلب الخصائص التجريبية. فتعامل مع الإضافة بوصفها وسيلة لإعادة استعمال ملفات لديك أصلًا، واترك باب الرجوع إلى llama.cpp مفتوحًا.
هل يحمّل vLLM ملفات GGUF أسرع من llama.cpp؟
لا — والسرعة لم تكن يومًا هي القضية. فـllama.cpp يربط الملف بالذاكرة مباشرةً، فيبدأ GGUF عمله على مهل؛ بينما يحمله vLLM كما يحمل أي نقطة تفتيش أخرى. ووجود الصيغة داخل vLLM ميزةٌ تتعلق ببصمة الذاكرة: تقدّمها الوثائق بوصفها وسيلة لضغط استهلاك ذاكرة الشاشة، لا لعبةً في سرعة الإنتاجية. ومكسب الإنتاجية يتركز في مكان مختلف تمامًا وهو التجميع — وتكلفة الإقلاع تلك تتكرر مع كل إعادة تشغيل، بخلاف kv-cache الذي يدفع أجرته مادام النموذج محمَّلًا.
vLLM أم llama.cpp للصيغة — أيّهما ينتصر؟
الملف نفسه وغريزتان متعاكستان: يعتبر llama.cpp الصيغة هي الغاية، ويعتبرها vLLM خيارًا. بطاقة واحدة تخدم عدة أشخاص ← vLLM مع الإضافة. شخص واحد، أي جهاز، أوسع اختيار للضغط ← llama.cpp بملفّه التنفيذي الواحد. وجدول المواجهة — المعالجات، التزامن، تغطية الضغط، الإعداد — في التقصي الكامل.
لماذا يتعثّر ملف GGUF عندي في vLLM؟
ثلاثة أسباب حقيقية، كلها في الجدول أعلاه: صيغة تشغيل خاطئة (مسارٌ عاديٌّ بدل repo:quant_type)، أو --tokenizer غائبٌ أو مخطأ، أو جهازٌ خارج جدول الدعم. وسبب رابع يظهر أقل: مخطط ضغطٍ لا تغطيه الإضافة. فامشِ في الجدول من أعلى إلى أسفل — ثلاثة صفوف أولى تكفي أغلب البلاغات.
هل يشغّل Ollama ملفات GGUF؟
نعم — وبشكل أصيل؛ فالصيغة هي الصيغة الافتراضية لـOllama، لا إضافةً عليه. اسحب ملفًا من Hugging Face، ووجّه Ollama إليه، وهناك ينتهي الأمر. وإن بقت البطاقة عاطلةً أثناء العمل، فتلك مشكلةٌ مختلفة لها قائمة تدقيقها: Ollama Not Using GPU? Fix It.
هل يتقاسم عدة مستخدمين خادم vLLM واحدًا؟
تلك هي الوظيفة الوحيدة التي وُجد vLLM من أجلها: فالتجميعُ المستمر يصنع طابورًا للطلبات المتزامنة أمام نموذجٍ محمَّلٍ مرة واحدة. والإضافة ترث تلك الآلية بأكملها — والتحفُّط الصادق هو سطر الوثائق ذاتها "غير مُحسَّن بعد"، لذا فإن كنت تقدّر خادمًا مشتركًا فعاين ضغطتك على بطاقتك قبل أن توعد أحدًا برقم. وكل ما تفترضه هذه الوحدة — الصيغة، والمحركات، والأجهزة — مرسوم في مركز تشغيل النماذج محليًا.
وفخٌّ آخر: يُحمَّل ثم يفلت من الذاكرة تحت الحمل
ملفٌّ يخدم مستخدمًا واحدًا على نحوٍ ممتاز قد يتجاوز سعة الذاكرة رغمًا عنه حين يتضاعف kv-cache مع كل طلبٍ متزامن. فالأوزان تقلصت، والمخزون يكبر مع كل مستخدم. أنقص التزامن، أو قصّر السياق، أو انزل درجةً في الضغط — ومنطق تقدير الحجم نفسه لأي نشرٍ لـvLLM.
الإجابات العشر أعلاه ترجع إلى مصدرين: وثائق vLLM الرسمية وسجلّات التشغيل عندنا. ولم يَنشر أحدٌ بعد مِضمارًا — Q4_K_M عبر الإضافة في مواجهة الملف نفسه في llama.cpp على بطاقة واحدة، وسرعات tok/s جنباً إلى جنب. وحين يُدار ذلك المِضمار فسيهبط أولًا في local-LLM hub first.