llama.cpp مقابل Ollama: أيهما تشغّل في 2026؟

llama.cpp الخام إذا أردت أقصى token في الثانية وتحكمًا كاملًا؛ Ollama إذا أردت تثبيتًا بأمر واحد وخادم API يعمل من الصندوق. Ollama ليست محركًا منافسًا — إنها خدمة Go تضمّن llama.cpp كخلفية استدلال، وتضيف إدارة نماذج (ollama pull llama3.1)، وتقدّم REST API على المنفذ 11434. فالسؤال الحقيقي ليس “أي محرك أسرع” بل “كم من التحكم تريد على مفاتيح ذلك المحرك”. ولأن Ollama تشحن قيمًا افتراضية محافظة (ضغط Q4_K_M، سياق متواضع، وبلا flash attention حتى قريبًا)، يمكن للعتاد نفسه أن ينتج أرقامًا مختلفة بوضوح. أدناه: ما يختلف فعلًا، ومن أين تأتي فجوة السرعة، والنموذج نفسه يعمل في الاثنين، وجدول قرار.

ما الفرق بين llama.cpp وOllama؟

llama.cpp هو محرك الاستدلال: مشروع C/C++ واحد من صناع GGUF جورجي غيرغانوف يشغّل النماذج المضغوطة على المعالج أو GPU أو مزيج منهما. يمنحك llama-cli للاستعلامات المرة الواحدة وllama-server — خادم HTTP متوافق مع OpenAI — إضافة إلى كل خيار الضبط يدعمه المحرك: تحويل طبقات إلى GPU، ضغط KV cache، فك ترميز تخميني، وأجهزة أخذ عينات مخصصة.

Ollama منتج مبني فوق ذلك المحرك. وهي تفرّع llama.cpp وتضمّنه ثم تغلّفه بـ:

• سجل نماذج (ollama pull، ollama list) مع تقسيم تلقائي لأوزان GGUF،
• نظام Modelfile (مواصفة شبيهة بـ Dockerfile لقوالب الإرشادات والبارامترات)،
• عفريت في الخلفية يبقي النماذج دافئة في VRAM ويكشف REST API خاصًا به،
• كشف تلقائي للعتاد بقيم افتراضية آمنة.

النتيجة العملية: مع Ollama تدير النماذج؛ ومع llama.cpp تدير الاستدلال. إذا أردت يومًا تغيير صيغة الضغط، أو ضغط KV cache، أو رفع السياق فوق الافتراضي، أو تثبيت طبقات معينة على الـ GPU، فذلك ميدان llama.cpp. تخفي Ollama معظم هذه المفاتيح — بمعزل متعمد.

	llama.cpp	Ollama
ما هي	محرك استدلال (C/C++)	خدمة تغلّف llama.cpp
التثبيت	بناء من المصدر أو حزمة	مثبّت بسطر واحد، ثنائي واحد
تشغيل نموذج	llama-cli -m model.gguf + خيارات	ollama run llama3.1
API	متوافق مع OpenAI (llama-server)	REST خاص + نقطة متوافقة مع OpenAI
إدارة النماذج	تجلب ملفات GGUF بنفسك	سجل: pull/list/rm
القيم الافتراضية	تختار كل شيء	آمنة: Q4_K_M، سياق متواضع
تحديثات المحرك	من اليوم الأول (المصدر الأصلي)	تتأخر عن إصدارات المصدر
عمق الضبط	كامل (ضغط KV، فك تخميني، مجمعات)	مرور محدود
الأفضل لـ	أعمال الأداء، الخوادم، الأجهزة الطرفية	البدايات، أجهزة العمل

هل llama.cpp أسرع من Ollama؟

على ملف GGUF نفسه، وبضغط وسياق ونسخة llama.cpp نفسها — لا، الفرق داخل هامش الضجيج، لأن Ollama هي llama.cpp وهي تحسب. كل مقياس تقول “Ollama أبطأ بـ 30%” هو في حقيقته مقارنة قيم افتراضية. الفجوة تأتي من ثلاثة أماكن:

1. اختيار الضغط. سجل Ollama الافتراضي هو Q4_K_M. شغّل النموذج نفسه بصيغة Q5_K_M أو Q6_K من llama.cpp وستحصل على جودة أعلى لكل token بسرعة مشابهة — أو اختر Q4_0/IQ4 للسرعة الخام.
2. Flash attention وضغط KV cache. خيار --flash-attn مع -ctk q8_0 -ctv q8_0 يصغّر KV cache جذريًا، ما يرفع token في الثانية عند السياق الطويل ويتيح سياقات أكبر في VRAM نفسها. تكشف Ollama جزءًا فقط من هذا.
3. تأخر النسخ. تهبط تحسينات النواة على llama.cpp أسبوعيًا؛ وتدمج Ollama من المصدر على جدولها الخاص. بنية llama.cpp حديثة قد تكون أسرع بشكل قابل للقياس من ثنائي Ollama عمره أشهر على الجهاز نفسه — حتى تلحق Ollama.

أمر قياس سريع، محايد تجاه المحرك — يبلغ عن سرعة تقييم الإرشاد والتوليد:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

شغّله على ملف نموذج Ollama نفسه (~/.ollama/models/blobs/... بعد إعادة تسميته بـ .gguf) وستطابق عادة أرقام Ollama بالضبط — ثم تغلبها بإضافة -ctk q8_0 عند سياق 16k.

كيف تشغّل النموذج نفسه في الاثنين؟

كلاهما يستهلك GGUF. الحد الأدنى الكامل لكل منهما:

# --- مسار Ollama: ثبّت، اسحب، قدّم ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # ينزّل Q4_K_M، يحمله في VRAM، يفتح دردشة

# وAPI الخاص به، بأسلوب متوافق مع OpenAI:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- مسار llama.cpp: ابنِ، نزّل GGUF، قدّم ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # أو -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

يكشف llama-server مخطط OpenAI Chat Completions، فأمر curl نفسه على http://localhost:8080/v1/chat/completions يعمل دون تغيير. وأي أداة مبنية على OpenAI API — سكربتات، محررات، مسارات RAG — تستطيع الإشارة إلى أي منهما. الخيارات هي من يفعل العمل الحقيقي: -ngl 99 تحوّل كل طبقة إلى الـ GPU، و--flash-attn مع ثنائية -ctk/-ctv تضع سياق 16k داخل بطاقة 8 جيجابايت كانت قيم Ollama الافتراضية سترفض.

ولاختيار ملف GGUF ذاته ومعنى وسوم الضغط، انظر كيف تشغّل نماذج GGUF محليًا.

متى يكون Ollama الخيار الأعقل؟

معظم الناس ينبغي أن يبدأوا بـ Ollama، وهذا ليس جائزة ترضية:

• أريده يعمل الليلة. أمر واحد، النموذج مسحوب، والـ API جاهز. llama.cpp تعني اختيار خلفية (CUDA/Vulkan/HIP/Metal)، وبناء، وجلب أوزان بيدك.
• تتنقل بين نماذج كثيرة. السجل وإلغاء التحميل التلقائي وModelfiles تفوق إدارة مجلدات ملفات GGUF بيدك.
• جهازك متواضع. قيم Ollama الافتراضية محافظة لسبب — فهي تكاد تناسبه وتعمل دائمًا.
• تريد سطح API مستقرًا. عفريت Ollama يدير دورة حياة النماذج فلا تضطر خدمة طويلة العمر لذلك.

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

وإذا كانت مقارنتك فعلًا بين تطبيقات واجهة سطح المكتب، فذلك محور مختلف — انظر Ollama مقابل LM Studio — وولاختيار المحرك لكل مهمة، تغطي أفضل LLMs محلية للبرمجة جانب النموذج.

فأيهما تستخدم؟

قرر بالتحكم لا بالسرعة. المحركان واحد؛ القيم الافتراضية هي ما يختلف. ثبّت Ollama إذا كان الهدف “يعمل ويقدّم API” — ستخسر بعض المفاتيح التي لم تكن ستديرها أصلًا. وابنِ llama.cpp إذا كان الهدف token في الثانية أو طول السياق أو تحكم الضغط — فستحصل على كل مفتاح، ثمنًا لإدارة النماذج بنفسك. وفي الحالتين ستشغّل ملفات GGUF نفسها، والتحويل لاحقًا يكلف بعد غداء لا إعادة كتابة.