Ollama أم llama.cpp على VPS؟ أيهما تختار؟

Ollama مقابل llama.cpp: أي طبقة تريد تشغيلها؟

لا يُعد Ollama وllama.cpp منافسين بالطريقة التي يوحي بها السؤال. يمثّل llama.cpp محرك الاستدلال: يحمّل ملف النموذج ويحوّل prompt إلى tokens. أما Ollama فهو مدير نماذج، وdaemon يعمل في الخلفية، وواجهة HTTP API تعمل فوق ذلك المحرك. ما زال README الخاص بـOllama يدرج llama.cpp بوصفه backend للاستدلال (وفق التحقق في 2 August 2026). لذلك، السؤال الفعلي هو أي طبقة تريد تشغيلها على VPS لديك، وليس أيهما أسرع.

شغّل Ollama عندما تريد خدمة تجلب النماذج بالاسم وتواصل العمل دون تدخل. شغّل llama.cpp مباشرة عندما يكون الخادم صغيراً وتحتاج إلى اختيار ملف النموذج وحجم السياق وعدد الخيوط بدقة، لأن كل إعداد من هذه الإعدادات يستهلك ذاكرة لا تتوفر لديك على VPS صغير.

ما الذي يمثله كل مشروع فعلياً

llama.cpp هو تطبيق بلغة C وC++ للاستدلال باستخدام نماذج transformer، ومبني على مكتبة ggml. يقرأ ملفات GGUF. وGGUF ‏(تنسيق الملفات العالمي لـGGML) هو حاوية في ملف واحد تحتوي على الأوزان، وtokeniser، والبيانات الوصفية التي يحتاج إليها المحرك لتشغيل النموذج. يوفّر المشروع ملفات تنفيذية منفصلة للمهام المختلفة. llama-server هو خادم HTTP، وllama-cli هو موجه تفاعلي، وllama-bench يقيس معدل النقل. تُوسَم الإصدارات برقم البناء بدلاً من استخدام الإصدار الدلالي. الوسم الحالي هو b10224، وقد نُشر في 2 August 2026، ويصدر وسم جديد في معظم أيام العمل.

Ollama هو برنامج مكتوب بلغة Go. يحمّل daemon يعمل في الخلفية، ويُشغَّل باستخدام ollama serve، النماذج ويستجيب لطلبات HTTP، بينما يتصل عميل سطر الأوامر بذلك daemon. يوجد خلف كليهما سجل في ollama.com يحتوي على نماذج مُعدّة مسبقاً. يستخدم Ollama الإصدارات الدلالية، وقد صدر v0.32.5 في 27 July 2026. يجلب ollama pull ملف GGUF مع قالب prompt ومجموعة من المعلمات الافتراضية، ثم يخزّنه ضمن /usr/share/ollama/.ollama/models في Linux. توجد هذه الملفات على قرص الجذر، ويصل حجم كل منها إلى عدة غيغابايت، لذلك من المفيد، على VPS يحتوي على وحدة تخزين جذرية بسعة 25 GB، أن تعرف ما الذي يتركه pull وراءه وكيف تنقل دليل النموذج إلى مكان آخر قبل أن يملأ التنزيل الثالث المساحة.

هذا التغليف هو الفارق الأساسي كله. يحدد Ollama quantisation والقالب وطول السياق نيابةً عنك، ويمنحك اسماً واحداً لتتذكره. أما llama.cpp فلا يحدد شيئاً، ويمنحك flags.

المحور 1: التحكم في النموذج والتكميم

يقلّص التكميم حجم كل وزن من 16 أو 32 بت إلى 4 أو 5 أو 8 بت. وهذا ما يجعل نموذجاً يحتوي على 8 مليارات مُعامل قابلاً للتشغيل ضمن ذاكرة RAM الخاصة بـVPS عادي. تصبح تسمية GGUF واضحة بعد فهم النمط: ‏Q4_K_M يعني تكميم K بدقة 4 بت وبحجم متوسط. يحافظ الرقم الأعلى على دقة أكبر، لكنه يستهلك ذاكرة أكثر.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

هذه هي أحجام الملفات المنشورة في مستودع bartowski/Meta-Llama-3.1-8B-Instruct-GGUF على Hugging Face، وقد قُرئت في 2 August 2026 وحُوّلت من bytes إلى GiB. توجد 6 إصدارات مبنية من نموذج واحد، وأصغرها حجمه 2.96 GiB، مقابل 7.95 GiB لأكبرها. الخيار الافتراضي الشائع، Q4_K_M، حجمه 4.58 GiB. على VPS بسعة 4 GiB، يحدد هذا الاختيار وحده ما إذا كان النموذج سيُحمّل أصلاً. الحجم ليس سوى نصف القرار، لأن الصف الذي يمكنك تحمّل تكلفته ليس بالضرورة صفاً يستحق الاستخدام، وما الذي يكلّفك إياه Q4 وQ8 وfp16 فعلياً في جودة الإجابة هو ما يحدد ما إذا كانت وحدات GiB الإضافية ستمنحك فرقاً يمكنك ملاحظته.

مع llama.cpp، تحدد اسم الملف، لذلك تختار هذا الصف بنفسك.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

يمثل -c حجم السياق بوحدة tokens، ويمثل -t عدد سلاسل التنفيذ، بينما يحدد -ngl عدد الطبقات التي تُنقل إلى GPU، ويكون 0 على جهاز يعمل بوحدة CPU فقط. لا يجري تخمين أي قيمة نيابةً عنك.

مع Ollama، يأتي التكميم ضمن tag الذي تسحبه، ويعرض ollama ls ما لديك فعلياً على القرص. عندما لا يحتوي السجل على الإصدار المبني الذي تريده، استورد ملف GGUF بنفسك. اكتب Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

ثم أنشئه وتحقق من النتيجة:

ollama create llama31-q4 -f ./Modelfile
ollama ls

طول السياق هو الإعداد الذي يسبب المشكلات غالباً. يختار Ollama قيمته الافتراضية من VRAM المتاحة، ويستخدم الجهاز الذي لا يحتوي على GPU أصغر فئة: 4096 tokens. إذا أرسلت إليه مستنداً يحتوي على 20,000 token، تُحذف tokens الإضافية قبل أن يراها النموذج، فتكون الإجابة خاطئة بثقة بشأن ملف لم يقرأ منه سوى نصفه. ارفع القيمة باستخدام OLLAMA_CONTEXT_LENGTH على daemon، أو باستخدام PARAMETER num_ctx في Modelfile. إذا كانت مهمة واحدة فقط تحتاج إلى نافذة أكبر، فيمكن ضبط num_ctx لكل طلب بدلاً من ضبطه على مستوى الخادم، وبذلك لا تُضاف cache الإضافية إلى كل ما يُطلب من daemon تنفيذه. لا يملك llama.cpp أيضاً قيمة افتراضية يمكن الوثوق بها. اضبط -c صراحةً، واعرف القيمة التي ضبطتها.

الحسابات الفعلية للذاكرة التي لا يعرضها أحد

ملف النموذج ليس التكلفة الكاملة. تخزّن ذاكرة KV المؤقتة، أي ذاكرة التخزين المؤقت للمفاتيح والقيم، إدخالاً واحداً لكل طبقة ولكل رمز من سياق المحادثة، وتزداد مع نمو المحادثة.

احسبها لنموذج Llama 3.1 8B. يتكوّن النموذج من 32 طبقة، و8 رؤوس للمفاتيح والقيم، وبُعد الرأس فيه 128. يخزّن كل رمز مفتاحاً وقيمة، بحجم 2 بايت لكل منهما عند استخدام f16، ولذلك يكون الحساب 2 × 8 × 128 × 2 = 4096 بايت لكل طبقة. وعبر 32 طبقة، يعادل ذلك 128 KiB لكل رمز. لذلك يحتاج سياق من 4096 رمزاً إلى 512 MiB، بينما يحتاج سياق من 32,768 رمزاً إلى 4 GiB.

لذلك يحتاج نموذج Q4_K_M 8B بسياق 4k إلى نحو 4.58 GiB للأوزان، إضافةً إلى نحو 0.5 GiB لذاكرة التخزين المؤقت، وإضافةً إلى وقت التشغيل نفسه. لن يتسع ذلك في 4 GiB من RAM. وسيتسع في 8 GiB مع مساحة كافية للعمل. إذا رفعت السياق إلى 32k على الخادم نفسه ذي الذاكرة 8 GiB، فستستهلك ذاكرة التخزين المؤقت وحدها المساحة المتاحة. راقب الاستخدام مباشرةً عبر free -h أثناء تحميل النموذج، ولا تعتمد على تقدير لم تتحقق منه بالقياس. إذا كنت تجهّز نظاماً لنموذج يتجاوز 8B بفارق كبير، فإن تطبيق الحساب نفسه على نموذج 27B على VPS يعمل بالمعالج فقط يوضح ما الذي تستوعبه كل فئة بين 8 و64 GB فعلياً.

يزيد Ollama الأمر تعقيداً. تكون قيمة OLLAMA_NUM_PARALLEL الافتراضية هي 1، ويتناسب احتياج النموذج إلى الذاكرة مع حاصل ضرب هذه القيمة في طول السياق. إذا رفعت القيمتين معاً، فسيطلب البرنامج الخفي بصمت عدة أضعاف RAM التي توقعتها. ويحدد الحساب نفسه الحد الأقصى للمستخدمين المتزامنين، لأن كل طلب متزامن يحتاج إلى جزء خاص به من ذاكرة KV المؤقتة، وهذا هو سبب توقف خادم يبدو مستقراً لمستخدم واحد عند خمسة مستخدمين.

المحور 2: البرنامج الخفي الذي يجب عليك تشغيله

ينشئ نص تثبيت Ollama وحدة systemd، وينشئ مستخدم نظام ollama، ويفعّل الخدمة. وتحصل بذلك على إدارة دورة الحياة من دون كتابة أي من هذه العناصر بنفسك. يمر الإعداد عبر systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

يكون OLLAMA_KEEP_ALIVE أكثر أهمية على VPS يستخدم CPU من أي بيئة أخرى. تُبقي النماذج في الذاكرة لمدة 5 دقائق افتراضياً، ثم تفرغها. يجب على الطلب التالي قراءة الملف بأكمله من القرص قبل أن يحصل على إجابة، ولذلك يمكن لإعادة تحميل بحجم 4.58 GiB أن تحوّل إجابة تستغرق ثانيتين إلى إجابة تستغرق ثلاثين ثانية على وحدة تخزين بطيئة. يؤدي keep-alive طويل إلى خفض زمن الاستجابة، لكنه يستهلك RAM بشكل دائم. كلا الخيارين له تكلفة فعلية. اختر الخيار الأقل إضراراً بك. إذا قررت أن يبقى النموذج محمّلاً في الذاكرة ببساطة، فإن ضبط keep_alive ليبقى بعد فترات الخمول وإعادة التشغيل يتطلب بضعة أسطر، ويجنّبك تهيئة النموذج يدوياً في كل مرة يُعاد فيها تشغيل الخادم.

لا يوفر llama.cpp أي برنامج خفي، لذلك تكتب الوحدة بنفسك باستخدام /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

فعّله باستخدام sudo systemctl enable --now llama-server. تحتفظ العملية بالنموذج طوال مدة تشغيلها. لا تُفرغ العملية النموذج عند الخمول، ولذلك لا تواجه مفاجأة إعادة التحميل، ولا يمكنك استعادة الذاكرة إلا بإيقاف الخدمة. إذا كانت كتابة الوحدات أمراً جديداً عليك، فهذا هو النمط نفسه المتبع في تشغيل خدماتك الخاصة ضمن systemd على VPS.

المحور 3: واجهة API التي سيتصل بها تطبيقك

أصبح هذا المحور أضيق نطاقاً بكثير. يدعم المشروعان الآن تنسيق OpenAI للمحادثات، لذلك تعمل معظم مكتبات العملاء مع أيٍّ منهما بعد تغيير عنوان URL الأساسي فقط.

يستمع Ollama على 127.0.0.1:11434. وتوجد واجهة المسار المتوافقة مع OpenAI على http://localhost:11434/v1/chat/completions، كما يوفّر إلى جانبها واجهة API أصلية على /api/chat. كما أن هناك توثيقاً لمسار متوافق مع Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

يستمع llama-server على 127.0.0.1:8080، ويوفّر /v1/chat/completions و/v1/completions و/v1/embeddings، إضافةً إلى نقطة النهاية الخاصة به /completion وواجهة ويب مضمّنة. كما يوفّر مسارات تشغيلية لا يوفّرها Ollama: /health لفحص الجاهزية، و/props لإعدادات النموذج المحمّل، و/slots لعرض ما تنفّذه كل خانة طلب، و/metrics بتنسيق Prometheus. إذا كنت تخطط لمراقبة هذه الخدمة، فمن المرجح أن يكون هذا الاختلاف هو العامل الحاسم.

لا يفعّل أيٌّ من الخادمين المصادقة تلقائياً. ويستخدم كلاهما loopback افتراضياً لسبب وجيه. اتصل بهما عبر نفق SSH أو من خلف reverse proxy، ولا تفتح المنفذين 11434 أو 8080 على الإنترنت مطلقاً.

ما الذي يستطيع VPS يعمل بالـCPU فقط فعله بصدق

يشغّل VPS يعمل بالـCPU فقط النماذج الصغيرة ببطء. هذا هو الملخص الواقعي، والفائدة العملية هي معرفة الحد الفاصل. قِس الأداء قبل أن تبني أي شيء حوله:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

يمثل العمود pp سرعة معالجة الـprompt، ويمثل العمود tg سرعة توليد الـtokens، وكلاهما مقاس بالـtokens في الثانية. في خطة vCPU مشتركة، يحقق نموذج 8B بإعداد Q4_K_M عادةً سرعة منخفضة من رقم أحادي في tg. معالجة الـprompt هي الجزء الأبطأ: تُعالَج المطالبة كاملة قبل ظهور أول token في الناتج، لذلك يضيف system prompt طويل وقت انتظار إلى كل طلب. أما طول الرد فهو الجزء من التكلفة الذي يمكنك التحكم فيه فعلياً، لأن نموذجاً يجيب بسرعة 3 tokens في الثانية ويسترسل إلى 600 token سيشغل الخادم 3 دقائق؛ لذلك فإن تحديد طول الناتج باستخدام num_predict هو أرخص طريقة لمنع إجابة مطولة واحدة من التسبب في انتهاء مهلة الطلب.

يمكن استخدام CPU في هذه الحالات: نموذج بحجم 1B إلى 4B للتصنيف، أو الاستخراج، أو التلخيص القصير، أو التوجيه. تصل الردود خلال ثوانٍ، وتتناسب متطلبات الذاكرة مع خطة عادية. وللحصول على مثال عملي بهذا الحجم بدلاً من نطاق أحجام، يقدّم تنزيل Nemotron 3.5 Lightning وقياس أدائه على VPS الوسم الدقيق، وذاكرة RAM التي يطلبها فعلياً، والسرعة التي يحافظ عليها دون GPU. لا يصلح CPU للمحادثة التفاعلية بسرعة القراءة، أو لمساعدي البرمجة، أو لمعالجة المستندات الطويلة، أو لأي شيء يتضمن حلقة وكيل تُجري العديد من الاستدعاءات بالتتابع. فإذا أجرت الحلقة 12 استدعاءً، واستغرق كل منها 4 ثوانٍ، فستحتاج إلى دقيقة قبل إنتاج أي شيء. وإذا كان الهدف هو استخدام مساعد برمجة، فإن توجيه وكيل إلى نموذج تستضيفه بنفسك يوضح المهام التي ينجح فيها نموذج محلي صغير فعلياً، والمهام التي يجب أن تبقى على API مستضاف.

توجد طريقتان للخروج عندما لا تنجح الأرقام. إذا كانت المشكلة هي التزامن، أي وصول مستخدمين كثيرين إلى نموذج واحد في الوقت نفسه، فإن اختيار المحرك يتغير، وتغطي مقارنة Ollama مع vLLM لخدمة الطلبات المتزامنة هذا الجانب. وإذا كانت المشكلة هي السرعة الخام، فالحل هو VPS مزود بـGPU، حيث يبدأ -ngl في اكتساب معنى فعلي. وقبل تجربة أي من الحلين، احصل على خط أساس للعتاد نفسه، لأن معدل نقل القرص والذاكرة يؤثر في وقت التحميل بقدر تأثير CPU تقريباً. ويستحق اختبار VPS قابل للتكرار تخصيص ساعة له.

تثبيت llama.cpp مع تثبيت إصدار البناء

يتغير كلا المشروعين أسبوعياً، لذلك سجّل الإصدار الذي نشرته. يثبّت الأمر المختصر من المشروع المصدر البناء الحالي:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

لتثبيت بناء محدد، نزّل أرشيف tarball المسبق البناء من صفحة الإصدارات بدلاً من ذلك. البناء b10224 هو الوسم الحالي في 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

أو ابنِ الوسم نفسه من المصدر:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

يُعدّ libssl-dev التبعية الموثقة لميزات HTTPS. تستغرق عملية الترجمة عدة دقائق وتتطلب ذاكرة RAM أكبر مما توفره أصغر الخطط، لذلك نفّذ البناء على خادم أكبر وانسخ الملفات الثنائية إذا نفدت الموارد على الخادم الصغير.

ثبّت Ollama على إصدار محدد

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

يقرأ البرنامج النصي OLLAMA_VERSION، لذلك يمكنك تثبيت إصدار معروف بالاستقرار بدلاً من استخدام الإصدار الذي صدر هذا الصباح. نُشر v0.32.5 في 27 July 2026. يتوفر أيضاً مسار يدوي إذا كنت تفضّل عدم تمرير برنامج نصي إلى shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

لا ينشئ المسار اليدوي وحدة systemd أو مستخدم الخدمة، لذلك عليك إضافة كل منهما بنفسك. يشرح الدليل الكامل لتشغيل Ollama على VPS خطوة إعداد الخدمة بالتفصيل.

أوضاع الفشل والرسائل التي ستظهر لك

يرفض Ollama تحميل النموذج. يعرض ollama run سطراً بهذا الشكل:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

يتحقق Ollama من الحجم قبل التحميل، لذلك يفشل سريعاً ويوضح السبب. انتقل إلى صف تكميم أدنى، أو خفّض طول السياق، أو اختر نموذجاً أصغر.

لا يفشل llama.cpp، بل يصبح بطيئاً جداً. يربط llama.cpp ملف GGUF بالذاكرة افتراضياً، لذلك يبدأ حتى إذا كان الملف أكبر من RAM. بعد ذلك تنقل النواة الأوزان من القرص وإليه مع كل token، وتنخفض سرعة التوليد إلى عدة ثوانٍ لكل token، بينما يصل استخدام القرص إلى 100 بالمئة. مرّر --no-mmap لفرض تخصيص فعلي للذاكرة، كي يفشل فوراً بدلاً من تدهور الأداء. عندما تتدخل النواة، يعرض dmesg السبب:

Out of memory: Killed process 1234 (llama-server)

لن يُحمّل ملف النموذج إطلاقاً. ينتج عن استخدام GGUF مبني لعائلة نماذج أحدث من محركك خطأ يذكر البنية التي لا يتعرف إليها:

error loading model architecture: unknown model architecture: 'qwen3next'

الحل هو ترقية المحرك، وليس استخدام ملف مختلف. هذه هي تكلفة تثبيت الإصدارات، ولذلك تدوّن رقم البناء. يجب أن تعرف الإصدار الذي ستُجري الترقية انطلاقاً منه.

تستجيب API محلياً، لكن تطبيقك لا يستطيع الوصول إليها. يربط Ollama على 127.0.0.1:11434، لذلك يتلقى المضيف الآخر رفضاً للاتصال. اضبط OLLAMA_HOST=0.0.0.0:11434 عبر systemctl edit ollama فقط عندما يكون المنفذ خلف جدار ناري أو شبكة خاصة، لأن API لا تملك مصادقة أمامها.

يكون الرد الأول بعد التوقف بطيئاً جداً. حدث تفريغ النموذج بعد خمول دام 5 دقائق، ويجري الآن قراءته من القرص مرة أخرى. يعرض ollama ps، عند تشغيله قبل الطلب مباشرة، عدم تحميل أي نموذج، وهذا يؤكد السبب. ارفع OLLAMA_KEEP_ALIVE.

إذن، أيّهما ينبغي أن تستخدم؟

استخدم Ollama عندما تريد أن تُدار النماذج نيابةً عنك، وأن تحصل على endpoint متوافق مع OpenAI دون إعدادات إضافية. وهو الخيار الافتراضي المناسب لأول عملية نشر، وكذلك لأي استخدام ستتغير فيه اختيارات النموذج باستمرار.

شغّل llama.cpp مباشرةً عندما تكون الذاكرة محدودة إلى حد يتطلب منك اختيار صف quantisation بنفسك، أو عندما تريد /health و/slots و/metrics للمراقبة، أو عندما تحتاج إلى flag لا يتيحه Ollama. وهذا هو الخيار الصريح على VPS بالكاد تتسع ذاكرته للنموذج، لأن الإعدادات التي تتيح تشغيله هي نفسها التي يختارها Ollama نيابةً عنك.

من الطبيعي تشغيل كليهما. استخدم Ollama للتجارب، وllama.cpp للنموذج الوحيد الذي تضعه في بيئة الإنتاج ولا تريد تغييره مطلقاً.

FAQ

هل Ollama مجرد غلاف حول llama.cpp؟

إلى حدّ كبير، لكن الغلاف ينفّذ أعمالاً فعلية. يذكر README الخاص بـOllama أن llama.cpp هو محرك الاستدلال الخاص به (تم التحقق في 2 August 2026). يضيف Ollama فوقه سجلّاً للنماذج، وقالب المطالبة الذي يحوّل رسائل المحادثة إلى مطالبة، ومجموعة من معاملات أخذ العينات الافتراضية، وخدمة daemon تفرغ النماذج غير النشطة، وواجهة HTTP API. عند مقارنة عدد الرموز في الثانية باستخدام الإعدادات نفسها، فأنت تقارن المحرك نفسه بنفسه. ما تختاره فعلياً هو طبقة الإدارة.

ما الأسرع على VPS يعمل بالـCPU فقط؟

يشترك البرنامجان في المحرك نفسه، لذلك تكون النتائج متقاربة عند استخدام ملف النموذج نفسه، وإعداد quantisation نفسه، وحجم السياق نفسه، وعدد الخيوط نفسه. عادةً تنتج الفروقات التي يذكرها المستخدمون عن إعدادات افتراضية مختلفة، وغالباً عن طول السياق وعدد الخيوط، لا عن المحرك. قِس الأداء باستخدام llama-bench -m <file> -p 512 -n 128، ثم قارن عمود tg على خادمك قبل تصديق أي نتيجة منشورة.

هل يمكنني استخدام ملف GGUF الخاص بي مع Ollama؟

نعم. ضع الملف على الخادم، واكتب ملف Modelfile يكون سطره الأول FROM ./your-model.gguf، وأضف أي أسطر PARAMETER تحتاج إليها، مثل num_ctx، ثم شغّل ollama create your-name -f ./Modelfile. سيعرض ollama ls الملف إلى جانب أي ملفات سحبتها من السجل. بهذه الطريقة تستخدم إعداد quantisation لا يوفّره السجل.

ما مقدار RAM الذي أحتاج إليه لنموذج 8B؟

احسب حجم الملف، ثم أضف إليه ذاكرة KV cache وذاكرة وقت التشغيل. يبلغ حجم إصدار Q4_K_M من Llama 3.1 8B على القرص نحو 4.58 GiB، ويضيف سياق من 4096 رمزاً نحو 512 MiB من ذاكرة التخزين المؤقت. لذلك تكون RAM بسعة 8 GiB مناسبة، بينما لا تكفي 4 GiB. تتناسب ذاكرة التخزين المؤقت مع حجم السياق. يحتاج النموذج نفسه عند استخدام سياق من 32,768 رمزاً إلى نحو 4 GiB من ذاكرة التخزين المؤقت وحدها. مع Ollama، تذكّر أن المتطلب يتناسب أيضاً مع OLLAMA_NUM_PARALLEL.