■ space · مكتب المترجم

■ الإجابة أولًا

نعم — يُشغل vLLM ملفات GGUF، عبر vllm-gguf-plugin, على GPU وحده.

الصياغة repo:quant_type + --tokenizer النموذج الأساس؛ ‏CPU بـx86/‏Arm و‏GPU بـIntel: غير مدعوم.

‏GPU واحد، مستخدمون متزامنون كثر → vLLM؛ لا GPU، أو أوسع تغطية تكميم → llama.cpp.

عبارات التوثيق ذاته: «عالٍ التجريبية وغير مُحسَّن بما يكفي» — ميزة تُعنى بالبصمة الذاكرية، لا رهانًا على الطاقة.

عند المكتب

قل على ماذا يعمل الملف. المكتب يراجع قائمة ضيوفه — جدول التوافق العتادي للتكميم الرسمي عند vLLM — ثم يختم حكمًا.

مدعوم

أنوية GPU تقف خلف طريق GGUF — الملحق يزيل التكميم من الكتل مباشرة إلى الخدمة الدفعية. تفضّل إلى الكاونتر.

المسار: uv pip install vllm-gguf-plugin → vllm serve repo:quant

مصدر قائمة الضيوف: جدول التوافق العتادي الرسمي للتكميم عند vLLM — الرفض معماري: لا نواة CPU تقف خلف طريق GGUF، لأن vLLM محرّك خدمة، لا لعبة لابتوب

الكاونتر

خطوتان، وعَلَمٌ لا يكون زينة قط:

uv pip install vllm-gguf-plugin

# directly from Hugging Face, repo_id:quant_type format:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M \
  --tokenizer Qwen/Qwen3-0.6B

# or a local file you already downloaded:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf \
  --tokenizer Qwen/Qwen3-0.6B

بداية نظيفة. التوثيق يوصي بمُصفِّر النموذج الأساس لأن تحويل مُصفِّرات GGUF «مستهلك للوقت وغير ثابت، خصوصًا مع بعض النماذج ذات القواميس الكبيرة». سطر واحد، بلا بدء طويل.

دعم GGUF لم يعد يأتي ضمن جوهر vLLM — التوثيق يلاحظ أنه «هاجر إلى OOT vllm-gguf-plugin »؛ ‏ pip install vllm وحده لا يكفي.

‏GPU اثنان ونموذج واحد: --tensor-parallel-size 2 يشطر GGUF نفسه على البطاقتين.

جئت من Ollama على CPU؟ ذاك محرّك، لا صيغة — llama.cpp يشغّل GGUF حتى على Raspberry Pis. لا تقف عند vLLM نواة CPU خلف GGUF.

قفلٌ يعلو قفل العتاد: نظام التشغيل. vLLM على Windows يعني WSL2 — تجاوزه كلفة ضريبة الشوكة.

قائمة الحدود الصادقة

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

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

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

الملف نفسه، حدسان متضادان

	vLLM + GGUF	llama.cpp
الاستدلال على CPU	لا	نعم، من الطبقة الأولى
مستخدمون متزامنون	‏continuous batching، مبنيٌّ منتظار له	محدودة
تغطية التكميم	جزء من الصيغة، تجريبي	المرجع
التنصيب	vLLM + ملحق	ملف تنفيذي واحد
الأفضل لـ	‏GPU واحد، مستخدمون كثر	مستخدم واحد، أي عتاد

تخدم فريقًا من GPU واحد؟ vLLM + GGUF يعيد استعمال ملفات Q4_K_M نفسها التي يعتمدها بقية عالم الـlocal-LLM.

مستخدم واحد على أي عتاد؟ llama.cpp ملف تنفيذي واحد وكل الصيغة.

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

■ ختم الأمانة من التوثيق، لا من معدّات قياسي. مُختبَر على: السجل العام — vLLM + vllm-gguf-plugin · NVIDIA Volta → Hopper · GPU بـAMD. قِيس في 2026-09-23، ورُوّي في 2026-10-12. كل ما هنا من توثيق vLLM وسجل مستودع vllm-project/vllm (‏92,000+ نجمة منذ فبراير 2023): قائمة الضيوف هي جدولهم العتادي التوافق بالحرف، والتحذيرات بلفظهم بين مبرزين، ولم يُخترع أي tokens-per-second لسدّ الثغرات.

نهاية مكتب المترجم · لم يُجلب شيء · كل شيء محلي