Key Takeaways
- محرك الاستدلال هو برمجية C/C++/Python التي تحمّل ملف نموذج وتولّد token. وهو مستقل عن طبقة واجهة المستخدم أو API.
- llama.cpp = خفيف، فعّال على CPU، يشغّل Ollama. مثالي لـ: الحواسيب المحمولة الاستهلاكية، مستخدم واحد، بلا اعتماديات.
- vLLM = بمستوى إنتاجي، أقصى إنتاجية GPU، يدعم المعالجة بالدُفعات والاستدلال الموزّع. مثالي لـ: خوادم API، متعدد المستخدمين، إنتاجية عالية.
- Text-Generation-WebUI = أداة تجريب غنية بالميزات بواجهة ويب مدمجة. مثالية لـ: الضبط الدقيق، واختبار LoRA، وضبط التكوينات المتقدمة.
- اعتبارًا من أبريل 2026، يتصدّر vLLM الاستخدام الإنتاجي، ويتصدّر llama.cpp الاستخدام الاستهلاكي، ويتصدّر Text-Generation-WebUI سير عمل البحث والضبط الدقيق.
ما هو محرك الاستدلال؟
محرك الاستدلال هو مكوّن البرمجيات الذي يحمّل ملف نموذج مدرّب مسبقًا وينفّذ العمليات الرياضية اللازمة لتوليد النص. وهو مختلف عن واجهة دردشة (مثل Open WebUI أو Enchanted UI) أو طبقة API (مثل REST API الخاص بـ Ollama).
يتكون نشر LLM محلي نموذجي من ثلاث طبقات:
1. ملف النموذج (مثل llama-3.1-8b.gguf) -- أوزان الشبكة العصبية.
2. محرك الاستدلال (مثل llama.cpp، vLLM) -- يحمّل النموذج ويولّد token.
3. الواجهة أو API (مثل REST API، دردشة الويب، امتداد VS Code) -- يتيح لك التفاعل مع المحرك.
Ollama نفسه هو أساسًا غلاف حول llama.cpp بواجهة API متوافقة مع OpenAI. vLLM محرك استدلال بلا واجهة مستخدم مدمجة. Text-Generation-WebUI محرك استدلال بواجهة ويب مدمجة.
مقارنة الميزات: llama.cpp مقابل vLLM مقابل Text-Generation-WebUI
| الميزة | llama.cpp | vLLM | Text-Gen-WebUI |
|---|---|---|---|
| — | مكتبة C++ (خفيفة) | إطار Python (إنتاجي) | تطبيق Python (تجريبي) |
| — | NVIDIA، AMD، Apple Metal | NVIDIA فقط (أفضل دعم) | NVIDIA، AMD، CPU |
| — | ممتاز | ضعيف | جيد |
| — | متوسطة (1-100) | عالية جدًا (100-1000+) | متوسطة (1-100) |
| — | محدود | كامل (دُفعات 100+) | محدود |
| — | لا | لا | نعم |
| — | ليس مباشرة | محدود | مدمج |
| — | GGUF، GGML | دقة كاملة، 8-bit، 4-bit | GGUF، safetensors، fp16 |
| — | عبر Ollama (سهل) | pip install (متوسط) | استنساخ GitHub (متوسط) |
| — | مجاني | مجاني | مجاني |
فهم llama.cpp: الأساس
llama.cpp هو تنفيذ بلغة C++ لاستدلال LLM، كُتب أصلًا لتشغيل نموذج Llama من Meta على عتاد استهلاكي دون تسريع GPU. اعتبارًا من أبريل 2026، يبقى محرك الاستدلال الأخف والأكثر قابلية للنقل.
لماذا يهيمن llama.cpp على الاستخدام الاستهلاكي:
- حمل ذاكرة إضافي ضئيل -- يمكن أن يعمل بذاكرة 8 GB من RAM فقط باستخدام CPU وحده.
- يدعم خلفيات GPU متعددة (NVIDIA، AMD، Apple Metal، Intel).
- صيغة GGUF: صيغة نموذج مكمَّم تضغط نماذج 70B إلى 20-40 GB.
- يشغّل Ollama داخليًا -- أنت تستخدم llama.cpp في كل مرة تشغّل فيها Ollama.
llama.cpp ليس تطبيقًا كاملًا؛ إنه مكتبة. تتفاعل معه عبر Ollama (الطريقة الأكثر شيوعًا) أو عبر أدوات أخرى تدمجه. إذا أردت استخدام llama.cpp مباشرة للضبط المتقدم، فعليك بنائه والتفاعل معه عبر أدوات سطر الأوامر أو روابط Python.
فهم vLLM: معيار الإنتاج
vLLM هو إطار Python مصمّم للاستدلال عالي الإنتاجية على عناقيد GPU. يحسّن تقديم النماذج عبر API، مع دعم المعالجة بالدُفعات، والاستدلال الموزّع، والجدولة المتقدمة.
لماذا يهيمن vLLM على الإنتاج:
- Paged Attention: يستخدم vLLM تخطيط ذاكرة مبتكرًا يحسّن استخدام GPU من ~20% إلى ~70%، مما يزيد الإنتاجية بشكل كبير.
- المعالجة بالدُفعات: يمكنه معالجة 50-100 موجّه في وقت واحد، لخدمة مزيد من المستخدمين لكل GPU.
- الاستدلال الموزّع: يقسّم تلقائيًا نموذج 70B عبر عدة وحدات GPU.
- دعم واسع للنماذج: يعمل مع أي نموذج من HuggingFace (Llama، Qwen، Mistral، Phi، إلخ).
اعتبارًا من أبريل 2026، تستخدم معظم عمليات نشر LLM المحلية الإنتاجية في المؤسسات vLLM. المقايضة أن vLLM يتطلب وحدات GPU من NVIDIA؛ وأداؤه ضعيف على CPU.
# Install vLLM
pip install vllm
# Run a model via API
vllm serve meta-llama/Llama-3.3-8B-Instruct \
--host 0.0.0.0 --port 8000 \
--gpu-memory-utilization 0.9
# Now accessible at http://localhost:8000/v1/completionsفهم Text-Generation-WebUI: أداة الباحث
Text-Generation-WebUI (يُسمى أيضًا oobabooga) هو تطبيق Python كامل بواجهة ويب للتجريب مع النماذج. يجمع الاستدلال مع أدوات مدمجة للضبط الدقيق، وتدريب LoRA، وتوليد embeddings، واختبار الموجّهات المتقدم.
لماذا يستخدم الباحثون Text-Generation-WebUI:
- ضبط دقيق LoRA مدمج: درّب محوّلات LoRA مخصصة فوق نماذج أساسية دون الحاجة إلى نصوص تدريب خارجية.
- محركات استدلال متعددة: يمكنه التبديل بين llama.cpp وGPTQ وexllama وخلفيات أخرى.
- تقمّص الشخصيات: نظام مدمج لإنشاء واختبار شخصيات.
- عرض API: يعرض واجهة FastAPI للاستخدام البرمجي.
- منظومة الامتدادات: امتدادات بناها المجتمع لسير عمل مخصص.
Text-Generation-WebUI هو أداة بحث وتجريب أكثر منه خادم إنتاج. الإعداد أكثر تعقيدًا (يتطلب استنساخ GitHub وإدارة اعتماديات Python)، لكنه بمجرد تشغيله، قوي للغاية للتطوير.
ما مدى سرعة كل محرك؟ مقارنة الأداء
تعتمد الإنتاجية (token في الثانية) على حجم النموذج والعتاد وتحسين المحرك. اعتبارًا من أبريل 2026، هذه معايير من العالم الحقيقي على عتاد استهلاكي:
| السيناريو | llama.cpp | vLLM | Text-Gen-WebUI |
|---|---|---|---|
| — | 150 token/ثانية | 300 token/ثانية (مع المعالجة بالدُفعات) | 150 token/ثانية |
| — | 5 token/ثانية | 0.5 token/ثانية (غير قابل للاستخدام) | 4 token/ثانية |
| — | 20 token/ثانية (GPU واحدة) | 100 token/ثانية (موزّع) | 20 token/ثانية |
| — | 30 token/ثانية | غير متاح (بلا دعم Metal) | 25 token/ثانية |
أي محرك لعمليات النشر الإنتاجية؟
vLLM هو معيار الإنتاج اعتبارًا من أبريل 2026. تستخدم معظم المؤسسات التي تشغّل واجهات API لـ LLM محلي في الإنتاج vLLM لتحسين الإنتاجية ودعم المعالجة بالدُفعات. يمكن لنسخة vLLM واحدة خدمة 50+ مستخدمًا متزامنًا على GPU واحدة، مقابل 1-2 لـ llama.cpp.
مع ذلك، يعتمد اختيار الإنتاج على القيد لديك:
- خدمة 100+ طلب/يوم بـ GPU محدودة: استخدم vLLM (أفضل إنتاجية).
- الخدمة على CPU فقط أو Apple Silicon: استخدم llama.cpp عبر Ollama (أفضل دعم CPU).
- استخدام نماذج Llama تحديدًا: كلاهما llama.cpp وvLLM يعملان؛ vLLM أسرع.
- استخدام صيغ نماذج متنوعة (GPTQ، GGUF، safetensors): يدعم Text-Generation-WebUI الجميع؛ يتطلب vLLM دقة كاملة أو صيغ تكميم محددة.
متى يجب أن تختار كل محرك؟
استخدم إطار القرار هذا:
- llama.cpp (عبر Ollama): أنت مستخدم استهلاكي، لست مطورًا، أو تنشر على CPU/Apple Silicon. أفضل سهولة استخدام عامة.
- vLLM: تقدّم API بـ 50+ مستخدمًا متزامنًا، لديك وحدات GPU من NVIDIA، وتحتاج أقصى إنتاجية. معيار الإنتاج.
- Text-Generation-WebUI: تضبط النماذج بدقة، أو تختبر محوّلات LoRA، أو تجرّب تكوينات استدلال متقدمة. الخيار الأفضل للبحث.
اختيار محرك الاستدلال حسب المنطقة
لاختيار محرك الاستدلال آثار مباشرة على الامتثال التنظيمي الإقليمي وعمليات النشر المؤسسية عبر ولايات قضائية تنظيمية مختلفة.
- الاتحاد الأوروبي / GDPR: لعمليات النشر المؤسسية في الاتحاد الأوروبي، يبقي vLLM يعمل داخل المنشأة كل الاستدلال ضمن البنية التحتية للاتحاد الأوروبي -- لا يغادر أي token أو موجّه أو استجابة خوادمك. لامتثال BSI IT-Grundschutz الألماني، vLLM هو محرك الإنتاج الموصى به لأنه يوفّر سجل تدقيق منظّمًا عبر مقاييس Prometheus (نقطة النهاية /metrics)، وجميع إصدارات النماذج قابلة للتثبيت عبر معرّفات نماذج HuggingFace لتوثيق الامتثال. نماذج Mistral (Mistral AI، فرنسا، Apache 2.0) هي الخيار المفضّل في الاتحاد الأوروبي لعمليات النشر الإنتاجية بـ vLLM -- منشأ أوروبي، ترخيص نظيف، أداء جيد. أمر vLLM: `vllm serve mistralai/Mistral-7B-Instruct-v0.3`
- منطقة الخليج / السعودية (PDPL): للجهات في السعودية والإمارات العاملة بموجب أطر السيادة على الذكاء الاصطناعي ونظام حماية البيانات الشخصية (PDPL)، يبقي vLLM يعمل داخل المنشأة كل الاستدلال على عتاد سيادي. توفّر مقاييس Prometheus المنظّمة في vLLM سجل تدقيق يلبي متطلبات التوثيق الحكومية. للجهات التي تفضّل نموذجًا عربي المنشأ، يُعد Jais (G42) وALLaM وFalcon (TII، الإمارات) خيارات سيادية تعمل مع vLLM. أمر vLLM: `vllm serve tiiuae/falcon-7b-instruct`
- الصين: بموجب قانون أمن البيانات الصيني (数据安全法)، يجب أن يبقى كل الاستدلال داخل المنشأة للبيانات الحساسة. يتوافق vLLM مع نسخ GPU من نوع A10 وA100 على Alibaba Cloud. نماذج Qwen3 (Alibaba) محسّنة أصليًا لـ vLLM وتوفّر أفضل أداء باللغة الصينية. للإنتاج المؤسسي في الصين: vLLM + Qwen3 14B على Alibaba Cloud هو الحزمة القياسية اعتبارًا من أبريل 2026.
أخطاء شائعة مع محركات الاستدلال
- الاعتقاد بأن عليك الاختيار بين Ollama وهذه المحركات. يستخدم Ollama llama.cpp داخليًا. أنت لا تختار Ollama مقابل vLLM؛ vLLM هو *خلفية* بديلة لـ Ollama، وليس تطبيق دردشة. لكلٍّ منهما غرضه.
- افتراض أن vLLM أسرع على CPU. أداء vLLM ضعيف على CPU؛ llama.cpp أسرع بـ 10 مرات على CPU. تحقق من توفر GPU لديك قبل اختيار vLLM.
- تشغيل vLLM على GPU حاسوب محمول. vLLM محسّن لوحدات GPU لمراكز البيانات (RTX 4090، A100). على وحدات GPU الاستهلاكية، قد يُبطئ حمل مجدول الدُفعات في vLLM فعليًا أداء الطلب الواحد. استخدم llama.cpp للحواسيب المحمولة.
- نسيان أن إنتاجية الاستدلال ليست نفسها زمن استجابة تجربة المستخدم. يمكن لـ vLLM معالجة 100 طلب بالدُفعات، لكن كل طلب لا يزال يستغرق وقتًا لتوليد token الخاص به. الإنتاجية العالية لا تعني زمن استجابة منخفضًا.
- تثبيت اعتماديات Text-Generation-WebUI بشكل خاطئ. تفترض تعليمات GitHub أن لديك Git وPython 3.10+ وpip مثبتة. على Windows، يفشل هذا غالبًا بصمت. تحقق دائمًا من إصدار Python قبل الاستنساخ.
أسئلة شائعة حول محركات الاستدلال
هل يمكنني تغيير محرك الاستدلال دون تغيير نموذجي؟
في الغالب، نعم. تعمل ملفات النماذج بصيغة GGUF مع llama.cpp (Ollama) وText-Generation-WebUI. يتطلب vLLM دقة كاملة أو صيغ تكميم محددة. نماذج safetensors من HuggingFace تعمل مع الثلاثة جميعًا.
أي محرك أفضل لـ Mac؟
llama.cpp عبر Ollama. لديه تحسين ممتاز لـ Apple Silicon (سلسلة M). لا يدعم vLLM Metal (GPU من Apple)، لذا أداؤه على CPU ضعيف. يعمل Text-Generation-WebUI على Mac لكنه أبطأ من Ollama.
هل vLLM جزء من Ollama؟
لا. يستخدم Ollama llama.cpp داخليًا. vLLM محرك استدلال مستقل من UC Berkeley. يخدمان أغراضًا مختلفة: Ollama للبساطة؛ وvLLM لأداء الإنتاج.
هل يمكنني استخدام vLLM دون GPU؟
تقنيًا نعم، لكنه بطيء بشكل غير قابل للاستخدام. vLLM مصمّم لـ GPU. لعمليات النشر على CPU فقط، استخدم llama.cpp (Ollama).
هل يتوسّع Text-Generation-WebUI إلى الإنتاج؟
غير موصى به. Text-Generation-WebUI أداة بحث، وليس خادم إنتاج. يفتقر إلى ميزات مثل موازنة الحمل، والمراقبة، والاستدلال الموزّع التي تحتاجها خدمات الإنتاج. استخدم vLLM للإنتاج.
ما هو Paged Attention ولماذا يهم؟
Paged Attention هو نظام إدارة الذاكرة في vLLM الذي يستعير مفاهيم الذاكرة الافتراضية من أنظمة التشغيل. بدلًا من تخصيص كتلة متجاورة ثابتة من ذاكرة GPU لكل طلب، يخصّص الذاكرة في صفحات يمكن مشاركتها وإعادة استخدامها بين الطلبات. يحسّن هذا استخدام ذاكرة GPU من ~20% إلى ~70%، مما يتيح لـ vLLM خدمة 3-4 أضعاف المستخدمين المتزامنين لكل GPU مقارنة بتنفيذات الانتباه الساذجة. هذا هو السبب الرئيسي لتفوق vLLM على llama.cpp في سيناريوهات متعددة المستخدمين.
أي محرك يجب أن أستخدم إذا كان لدي 8 GB من RAM فقط؟
llama.cpp عبر Ollama. بذاكرة 8 GB من RAM إجمالًا، يستخدم نموذج 7B بـ Q4_K_M ~4.7 GB. يتعامل llama.cpp مع هذا جيدًا بـ ~5 tok/ثانية على CPU أو ~80 tok/ثانية على GPU مخصصة. يتطلب vLLM حملًا إضافيًا أكبر بكثير ويعمل بشكل سيئ بذاكرة RAM استهلاكية. Text-Generation-WebUI قابل للتطبيق أيضًا لكنه يضيف حملًا أكبر من Ollama.
هل يمكنني تشغيل vLLM وOllama على الجهاز نفسه؟
نعم، إذا كانت VRAM كافية. شغّلهما على منافذ مختلفة (vLLM الافتراضي: 8000، Ollama الافتراضي: 11434). إعداد نموذجي: يتعامل Ollama مع طلبات الدردشة السريعة لمستخدم واحد، ويتعامل vLLM مع طلبات API بالدُفعات. مع ذلك، لا يمكنهما تحميل النموذج نفسه في وقت واحد دون مضاعفة VRAM. أدِر أي خدمة نشطة وفقًا لعبء عملك.
المصادر
- Gerganov, G. (2024). "llama.cpp GitHub." https://github.com/ggerganov/llama.cpp -- الشيفرة المصدرية لمحرك الاستدلال بلغة C++ وتوثيق التكميم.
- vLLM Team. (2024). "vLLM GitHub." https://github.com/vllm-project/vllm -- الشيفرة المصدرية لمحرك الاستدلال الإنتاجي وتوثيق خادم API.
- Kwon et al. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." https://arxiv.org/abs/2309.06180 -- الورقة الأصلية حول Paged Attention التي تشرح نهج إدارة الذاكرة في vLLM.
- oobabooga. (2024). "Text-Generation-WebUI GitHub." https://github.com/oobabooga/text-generation-webui -- الشيفرة المصدرية ودليل التثبيت لـ Text-Generation-WebUI.