llama.cpp

يُعد llama.cpp محرك استدلال مبني بلغة C/C++ للنماذج اللغوية الكبيرة، ابتكره Georgi Gerganov وصدر لأول مرة في مارس 2023. ما بدأ كمشروع برمجي سريع في أمسية واحدة لتشغيل نموذج Llama التابع لشركة Meta على جهاز MacBook بدون وحدة معالجة رسومات (GPU)، أصبح الآن البنية التحتية الأساسية لجميع أدوات النماذج اللغوية الكبيرة (LLM) المحلية تقريباً: Ollama و LM Studio و Jan و AnythingLLM، حيث تستخدم جميعها llama.cpp كخلفية استدلال أساسية. المشروع مرخص بموجب MIT، وحصد أكثر من 108,000 نجمة على GitHub، وأصدر أكثر من 5,000 إصدار. يعمل المحرك على معالجات Apple Silicon (Metal)، ووحدات معالجة الرسومات NVIDIA (CUDA)، ووحدات معالجة الرسومات AMD (HIP)، و Vulkan لدعم وحدات معالجة الرسومات من مختلف الشركات المصنعة، بالإضافة إلى وحدات المعالجة المركزية (CPU) الخالصة مع تحسينات مجموعة تعليمات AVX/AVX2/AVX512.

يدعم المحرك أكثر من 50 بنية نماذج، بما في ذلك متغيرات LLaMA و Mistral و Mixtral و Gemma و Phi و DeepSeek و Qwen. ويستخدم تنسيق ملفات GGUF، الذي قدمه Gerganov في أغسطس 2023 والذي أصبح منذ ذلك الحين المعيار العالمي لتوزيع النماذج اللغوية الكبيرة المحلية. تتراوح خيارات التكميم (Quantization) من 1.5-bit إلى 8-bit، مما يسمح لنموذج يحتوي على 7 مليارات معلمة بالعمل على ذاكرة وصول عشوائي (RAM) تقل عن 4 جيجابايت. يوفر المشروع خادم HTTP متوافقاً بالكامل مع OpenAI (llama-server)، وواجهة دردشة عبر سطر الأوامر (llama-cli)، وأدوات قياس الأداء، ودعم الاستدلال متعدد الوسائط عبر مكتبة libmtmd التي أُضيفت في أبريل 2025. يبلغ حجم التثبيت أقل من 90 ميجابايت. لا يوجد أي اعتماد على السحابة، ولا يتطلب إنشاء حساب، ولا تغادر أي بيانات الجهاز الذي يعمل عليه.

ما الذي يقدمه llama.cpp فعلياً في مايو 2026

يوفر الإصدار الحالي (b9012، 3 مايو 2026) حزمة استدلال محلية كاملة. نقطة الدخول الأساسية لمعظم المطورين هي llama-server، والذي يطلق واجهة برمجة تطبيقات (API) متوافقة مع OpenAI على localhost:8080 بأمر واحد. يعمل أي عميل مبني على حزمة تطوير برمجيات OpenAI (SDK) دون أي تعديل، مما يعني أن llama.cpp يندمج مباشرة مع إضافات VS Code، أو نصوص Python البرمجية، أو أي تطبيق يستخدم /v1/chat/completions.

يُعد التكميم (Quantization) القدرة التقنية الأساسية التي تجعل llama.cpp قابلاً للتشغيل على الأجهزة الاستهلاكية. يجمع تنسيق GGUF النموذج المُكمم والمفردات وتكوين البنية في ملف واحد. التوصية الافتراضية لمعظم حالات الاستخدام هي Q4_K_M (حوالي 4.5 جيجابايت لنموذج 7B)، والذي يقدم خسارة لا تُذكر في الجودة مقارنة بنسخة الدقة الكاملة، بينما يعمل على جهاز MacBook بذاكرة وصول عشوائي (RAM) سعتها 8 جيجابايت بسرعة تزيد عن 40 رمزاً (token) في الثانية. بالنسبة للأجهزة ذات الموارد المحدودة، يسمح تنسيق Q1_0 الصادر في أبريل 2026 بتشغيل نماذج قادرة بحجم يقل عن 1 جيجابايت. أما للمستخدمين الذين يعطون الأولوية للجودة، فتتوفر خيارات Q8_0 أو Q5_K_M.

تتم معالجة تفريغ الأجهزة (Hardware offloading) تلقائياً. عندما يتجاوز النموذج سعة ذاكرة الوصول العشوائي للفيديو (VRAM) المتاحة في وحدة معالجة الرسومات، يقوم llama.cpp بتقسيمه: تُرسل الطبقات التي تتسع لها الذاكرة إلى وحدة معالجة الرسومات، وتُعالج البقية على ذاكرة الوصول العشوائي لوحدة المعالجة المركزية (CPU RAM). يتراجع الأداء بسلاسة بدلاً من الفشل التام. على معالجات Apple Silicon، يكون تسريع Metal مدعوماً بشكل أصلي. وعلى أنظمة Linux المزودة بأجهزة NVIDIA، يكون CUDA هو الخيار الافتراضي. يمكن تجميع ملف تنفيذي واحد مع دعم Vulkan للعمل على وحدات معالجة الرسومات AMD أو Intel Arc أو أي وحدة معالجة رسومات تدعم Vulkan دون الحاجة إلى برامج تشغيل خاصة بالشركة المصنعة.

أضافت إصدارات أبريل 2026 توازي الموترات (tensor parallelism) المستقل عن الخلفية عبر NCCL و RCCL، والذي يقسم العمليات الفردية عبر وحدات معالجة رسومات متعددة في وقت واحد بدلاً من مجرد تقسيم طبقات النموذج. بالنسبة لتكوينات وحدات معالجة الرسومات المتعددة، ينتج عن ذلك مكاسب في الإنتاجية تتراوح بين 3 إلى 4 أضعاف مقارنة بنهج تقسيم الطبقات القديم، مما يجعل llama.cpp خياراً قابلاً للتطبيق بشكل متزايد لعمليات النشر الإنتاجية الصغيرة، وليس للاستخدام الشخصي فقط. في نفس الشهر، تم إطلاق تدوير ذاكرة التخزين المؤقت Walsh-Hadamard KV، مما رفع درجات معيار الاستدلال AIME25 من 0.0% إلى 21.7% تحت تكميم Q4_0، وهو تحسن كبير للاستدلال المُكمم في مهام الاستدلال متعددة الخطوات.

يتكامل تنزيل النماذج مباشرة مع Hugging Face و Docker Hub. يؤدي تمرير معرف نموذج Hugging Face إلى llama-server إلى سحب ملف GGUF وبدء تشغيل الخادم. نظراً لأن Hugging Face يقوم بفهرسة ملفات GGUF بشكل أصلي، فإن هذا يعمل مع الآلاف من النماذج المُكممة من قِبل المجتمع دون أي خطوة تحويل.

"لقد تمكنت من تشغيل مجموعة بيانات 13B على جهاز Pi4 واحد بذاكرة 8 جيجابايت.. هذا هو الواقع الحالي للنماذج اللغوية الكبيرة (LLM) القابلة لإعادة الإنتاج في المنزل على أي جهاز تملكه" - cameron_b، Hacker News، سبتمبر 2023

موقع llama.cpp مقارنة بـ vLLM و MLX

llama.cpp مقابل vLLM: تخدم هاتان الأداتان طرفين مختلفين من طيف النشر ونادراً ما تتنافسان على نفس حالة الاستخدام. يُعد vLLM إطار عمل استدلال مبني على Python ويركز على خوادم وحدات معالجة الرسومات، وهو مبني حول التجميع المستمر (continuous batching) و PagedAttention، وهي آلية لإدارة ذاكرة التخزين المؤقت KV على مستوى الصفحة. على وحدة معالجة الرسومات NVIDIA H200 عند ذروة التحميل، يقدم vLLM إنتاجية طلبات تبلغ 35 ضعفاً وإخراج رموز (tokens) يبلغ 44 ضعفاً في الثانية مقارنة بـ llama.cpp، ولكن هذه المقارنة لا تصح إلا عند وجود 10 مستخدمين متزامنين أو أكثر على أجهزة من فئة المؤسسات. بالنسبة لأعباء العمل الخاصة بمستخدم واحد أو ذات التزامن المنخفض، فإن زمن الانتقال بين الرموز في llama.cpp أقل بكثير لأنه لا يقوم بتجميع الطلبات. يتطلب vLLM تقنية CUDA ولا يعمل بشكل فعال على الأجهزة الاستهلاكية أو أجهزة كمبيوتر سطح المكتب بنظام Windows أو معالجات Apple Silicon. بينما يعمل llama.cpp في كل مكان. يمكنك مقارنة vLLM إذا كنت تنشر واجهة برمجة تطبيقات (API) إنتاجية على خادم وحدة معالجة رسومات مخصص مع 5 مستخدمين متزامنين أو أكثر؛ أما llama.cpp فهو الخيار الصحيح لكل شيء آخر.

llama.cpp مقابل MLX: يُعد MLX إطار عمل التعلم الآلي الخاص بشركة Apple، وهو مُحسّن لبنية الذاكرة الموحدة لشرائح Apple Silicon. نظراً لأن وحدة المعالجة المركزية ووحدة معالجة الرسومات تتشاركان نفس الذاكرة الفعلية على Apple Silicon، يحقق MLX عمليات موترات (tensor operations) بدون نسخ، مما يقضي على عبء نقل البيانات الذي يتكبده llama.cpp عند نقل البيانات بين مظللات Metal. على شريحة M2 Pro التي تشغل نموذج Llama 3.1 8B بتكميم Q4_K_M، يحقق MLX ما يقرب من 45-58 رمزاً في الثانية مقابل 38-48 في llama.cpp. بالنسبة لسير عمل التطوير المقتصر على أجهزة Mac، فإن هذه الفجوة مهمة. يدعم MLX أيضاً الضبط الدقيق الأصلي لـ LoRA و QLoRA، وهو ما لا يدعمه llama.cpp. القيد الحاسم هو: MLX مخصص لمعالجات Apple Silicon فقط. فهو لا يعمل على أنظمة Windows أو Linux أو Android. كما يتطلب تحويل النموذج من تنسيق GGUF، وغالباً ما تظهر نماذج المجتمع بتنسيق GGUF أولاً بينما تتأخر تحويلات MLX لساعات أو أيام. يتمتع llama.cpp بدعم من اليوم الأول للإصدارات الجديدة من المجتمع ويعمل على أي أجهزة.

"لقد انتقلت للتو من ollama وكانت سرعة توليد الرموز ومكاسب الكفاءة رائعة حقاً." - مراجعة مستخدم، itsfoss.com، 2025

كيف يبدو سير عمل الاستدلال اليومي

المسار الأدنى لتشغيل نموذج يتكون من ثلاث خطوات: تنزيل ملف GGUF من Hugging Face، وتشغيل llama-server -m model.gguf، والوصول إلى localhost:8080/v1/chat/completions. يبدأ الخادم في أقل من خمس ثوانٍ على وحدات التخزين السريعة. يستغرق الإيقاف وإعادة التشغيل بنموذج مختلف نفس القدر من الوقت. لا توجد إدارة للبرامج الخفية (daemon)، ولا سجل للنماذج، ولا خدمة خلفية تستهلك الموارد عند الخمول.

للاستخدام التفاعلي، يفتح الأمر llama-cli -m model.gguf --interactive جلسة دردشة في الوحدة الطرفية (terminal). تتيح لك قيود القواعد النحوية (Grammar constraints) فرض إخراج JSON أو تقييد الاستجابات بمخطط محدد، وهو أمر مفيد لمسارات استخراج البيانات المنظمة. طول نافذة السياق قابل للتكوين عبر علامة سطر الأوامر، ويقتصر على ذاكرة الوصول العشوائي (RAM) المتاحة.

توفر واجهة مستخدم الويب، التي تم تقديمها في عام 2024، واجهة دردشة قائمة على المتصفح يستضيفها llama-server. وهي تدعم المحادثات متعددة الأدوار، وتكوين موجه النظام (system prompt)، وتعديل المعلمات دون لمس سطر الأوامر. قد لا تكون مصقولة مثل واجهة LM Studio، ولكنها تعمل في أي متصفح ولا تتطلب أي تثبيت بخلاف الملف التنفيذي للخادم.

بالنسبة للمستخدمين الذين يبنون تطبيقات تعتمد على llama.cpp، تتوفر إضافات VS Code و Vim/Neovim كجزء من المشروع، حيث تقوم بتوجيه طلبات إكمال التعليمات البرمجية عبر نقطة نهاية llama-server المحلية. تعني طبقة التوافق مع OpenAI أن أي أداة تقبل عنوان URL أساسي مخصص، مثل AnythingLLM أو Continue.dev، تتصل دون الحاجة إلى تغييرات في التكوين.

لمن صُمم llama.cpp

يستهدف llama.cpp المطورين والمستخدمين التقنيين الذين يريدون تحكماً كاملاً في حزمة الاستدلال الخاصة بهم ومستعدون لقضاء 30-60 دقيقة في الإعداد الأولي لتجنب الاعتماد على السحابة، أو التكاليف لكل رمز (per-token)، أو طبقات التجريد التي تضيفها الأدوات ذات المستوى الأعلى. يعتمد عليه المستخدمون المهتمون بالخصوصية الذين لا يستطيعون أو لا يرغبون في إرسال البيانات إلى واجهات برمجة تطبيقات (APIs) خارجية. يستخدمه الباحثون الذين يجرون تجارب على الأجهزة الاستهلاكية للوصول إلى نفس أوزان النماذج التي يقدمها مزودو الخدمات السحابية بتكلفة هامشية صفرية لكل استعلام. يقوم مطورو الأنظمة المدمجة وحوسبة الحافة بتجميعه لأجهزة Raspberry Pi و Android (تسريع أصلي عبر Qualcomm Hexagon منذ أبريل 2026) وأجهزة ChromeOS.

من الصعب المبالغة في أهمية النظام البيئي: حتى المستخدمين الذين لا يتعاملون مع llama.cpp بشكل مباشر من المحتمل أنهم يقومون بتشغيله إذا كانوا يستخدمون أي أداة واجهة أمامية للنماذج اللغوية الكبيرة (LLM) المحلية. يساعد فهم ماهية llama.cpp المستخدمين على فهم أين يحدث الاستدلال الخاص بهم فعلياً، ولماذا تعمل مستويات تكميم GGUF معينة بشكل أفضل على أجهزتهم، وكيفية تصحيح مشكلات الأداء التي لا تكشفها واجهة المستخدم الرسومية (GUI) الخاصة بهم.

يحصل المستخدمون الذين يقرنون llama.cpp مباشرة مع نماذج Llama التابعة لشركة Meta على التوافق الكامل، حيث تم بناء المشروع في الأصل من أجل Llama ويظل الاثنان متوافقين بشكل وثيق في دعم البنى الجديدة. إن النظام البيئي لنماذج المجتمع على Hugging Face، حيث توجد الآلاف من تكميمات GGUF لكل إصدار رئيسي مفتوح الأوزان، يجعل llama.cpp فعلياً نقطة الانطلاق لأي نموذج جديد في غضون ساعات من إصداره.

ما لا يمثله llama.cpp

لا يُعد llama.cpp تطبيقاً رسومياً. سيجد المستخدمون الذين يتوقعون إدارة النماذج بنقرة زر أن واجهة سطر الأوامر (CLI) غير مألوفة. وُجدت أدوات مثل LM Studio و Jan خصيصاً لإضافة طبقة واجهة المستخدم الرسومية (GUI) هذه فوق محرك استدلال llama.cpp.

إنه ليس خادم استدلال متعدد المستخدمين على نطاق واسع. يعالج المحرك الطلبات بالتسلسل. عند وجود خمسة مستخدمين متزامنين أو أكثر، ينمو زمن انتقال قائمة الانتظار بشكل كبير. لتقديم واجهة برمجة تطبيقات (API) إنتاجية بمتطلبات تزامن حقيقية، يكون vLLM أو نقطة نهاية مستضافة خياراً أكثر ملاءمة.

إنه ليس أداة للضبط الدقيق (fine-tuning). لا توجد حلقة تدريب، ولا تنفيذ لـ LoRA، ولا مسار لمجموعة البيانات. إذا كنت بحاجة إلى ضبط دقيق لنموذج، فإن هذا العمل يتم في إطار عمل Python (مثل PyTorch أو MLX أو Axolotl) ثم يتم تحويل الأوزان الناتجة إلى GGUF للاستدلال.

إنه ليس مركزاً للنماذج أو أداة استكشاف. لا يقوم llama.cpp بتنظيم النماذج أو التوصية بها. يجد المستخدمون النماذج على Hugging Face أو من خلال موارد المجتمع مثل r/LocalLLaMA، ثم يقومون بتنزيل ملفات GGUF مباشرة.

من الجدير بالذكر أيضاً توضيح مسألة الإسناد في النظام البيئي. لا يدرك العديد من مستخدمي Ollama أو LM Studio أن هذه الأدوات تعتمد على llama.cpp في الاستدلال الخاص بها. من الإحباطات المستمرة في المجتمع، والتي ظهرت في مشكلة GitHub رقم 3185 ونوقشت مراراً وتكراراً على Hacker News، أن Ollama لا ينسب الفضل بوضوح إلى llama.cpp في وثائقه أو واجهته الموجهة للمستخدم. هذا الأمر مهم لأن مشكلات الأداء وسلوك التكميم وبنى النماذج المدعومة هي جميعها خصائص لـ llama.cpp، وليست للأداة المغلِّفة (wrapper tool). إن معرفة أن llama.cpp هو المحرك الفعلي يمنح المستخدمين مفردات ذات مغزى لتصحيح الأخطاء والتحسين.

الآثار العملية: إذا كنت تختار بين Ollama و llama.cpp مباشرة، فأنت لا تختار بين محركات استدلال مختلفة. بل تختار بين مستويات مختلفة من التجريد فوق نفس محرك الاستدلال. بالنسبة لمعظم المستخدمين، تفوز بساطة Ollama. أما بالنسبة للمطورين الذين يحتاجون إلى ضبط المعلمات، أو بناء مسارات مخصصة، أو تشغيل نماذج لا يحملها سجل Ollama، فإن الوصول المباشر إلى llama.cpp هو الطبقة الصحيحة للعمل عليها.