تشغيل خادم llama.cpp على VPS خطوة بخطوة

ما الذي ستبنيه

يعني تشغيل خادم llama.cpp على VPS استخدام ملف ثنائي واحد، llama-server، يحمّل ملف نموذج GGUF واحداً ويستجيب لطلبات HTTP عبر API متوافق مع OpenAI. وجّه أي عميل OpenAI إلى http://127.0.0.1:8080/v1 وسيعمل. التثبيت هو الجزء الأسهل.

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

اختر وسم إصدار وسجّله

يضع llama.cpp وسم إصدار لكل عملية دمج تقريباً، لذلك تمثل الوسوم أرقام البناء. الإصدار b10488 هو الأحدث حتى 18 August 2026. لا يوجد فرع مستقر طويل الأمد، ما يعني أن «الأحدث» يتغير باستمرار، وأن الإصدار الذي اختبرته هو الإصدار الوحيد الذي يمكنك دعمه. اختر وسماً، وسجّله، واستخدم السلسلة نفسها في عملية الاستنساخ، واسم الملف الثنائي، وملاحظاتك.

يتضمن كل وسم أيضاً أرشيفات مبنية مسبقاً. بالنسبة إلى VPS x86 الذي يعمل بوحدة CPU فقط، يكون الأرشيف هو llama-b10488-bin-ubuntu-x64.tar.gz، ويوجد أرشيف arm64 بجواره إذا كنت تستخدم VPS يعمل بمعمارية ARM بدلاً من x86.

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

اعرض محتويات الأرشيف قبل فكّه، حتى تعرف مكان وضع الملفات. ترتبط هذه الملفات الثنائية بمكتبة C الخاصة بصورة النظام التي بنتها، ولذلك تفشل عند بدء التشغيل على توزيعة أقدم مع ظهور خطأ يذكر إصدار GLIBC_ غير المثبت. يستغرق البناء من المصدر بضع دقائق على VPS صغير، ويزيل هذه الفئة الكاملة من المشكلات، ولذلك سنستخدم هذا المسار أدناه.

بناء llama-server من وسم محدد

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

يؤدي --branch b10488 على نسخة --depth 1 إلى سحب ذلك الوسم دون أي شيء آخر، لذلك لا تتغير الشفرة المصدرية أثناء العمل.

يهم libssl-dev لأن الخيار LLAMA_OPENSSL مفعّل افتراضياً، وهو ما يتيح للملف الثنائي تنزيل النماذج عبر HTTPS لاحقاً. وبدون هذه الترويسات، تفشل خطوة configure.

يوفّر لك -DBUILD_SHARED_LIBS=OFF ملفاً ثنائياً مستقلاً بالكامل. يضع البناء الافتراضي المكتبات المشتركة بجوار الملف التنفيذي، لذلك تفشل لاحقاً عملية نسخ الملف التنفيذي وحده إلى /usr/local/bin مع error while loading shared libraries: libllama.so.

يبني -t llama-server هدف الخادم فقط. يترجم البناء الافتراضي أيضاً الأدوات الأخرى والاختبارات، ما يستهلك عدة دقائق إضافية على VPS ذي نواتين في ملفات لن تشغّلها أبداً.

استخدام -j 2 مقصود. تحتفظ كل مهمة ترجمة متوازية بمجموعة العمل الخاصة بها، لذلك ينتهي -j $(nproc) على خطة صغيرة بـc++: fatal error: Killed signal terminated program cc1plus، حيث يوقف قاتل نفاد الذاكرة في النواة المترجم. خفّض عدد المهام، أو أضف swap لعملية البناء.

هناك خيار واحد قد ترغب في تغييره: يكون GGML_NATIVE مفعّلاً افتراضياً، لذلك يستهدف المترجم وحدة المعالجة المركزية التي تنفّذ عملية البناء نفسها. هذا هو الإعداد المطلوب عندما تبني على الجهاز الذي سيشغّل الملف. إذا بنيت مرة واحدة ونسخت الملف الثنائي إلى مضيف مختلف، فأضف -DGGML_NATIVE=OFF، لأن الملف الثنائي الذي يستخدم تعليمات لا تدعمها وحدة المعالجة المركزية الأخرى يتوقف مع Illegal instruction (core dumped) عند أول استدلال.

ثبّته باسم يتضمن الوسم.

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

يطبع --version رقم البناء والالتزام. يجب أن يطابق الوسم الذي سحبته. إذا لم يطابقه، فقد بنيت شيئاً آخر. يؤدي الاحتفاظ بالرقم في اسم الملف وتوجيه رابط رمزي إليه إلى جعل الترقية عبارة عن ln -sfn واحد ثم إعادة تشغيل واحدة، ويكون الرجوع إلى إصدار سابق باستخدام الأمر نفسه مع الرقم القديم.

احصل على نموذج GGUF، وافحص القرص أولاً

GGUF هو تنسيق الملف الواحد الذي يحمّله llama.cpp. يحتوي الملف الواحد على الأوزان وtokeniser والبيانات الوصفية، لذلك لا تحتاج إلى تثبيت أي شيء آخر. تشير اللاحقة في اسم الملف إلى quantisation، أي الدقة التي تُخزَّن بها الأوزان: Q4_K_M هو مزيج بدقة 4-bit، وQ8_0 بدقة 8-bit، وf16 هو الملف غير المكمَّم بدقة نصفية.

أنشئ حساب خدمة ودليلاً للنموذج قبل تنزيل أي شيء.

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

يمكن للخادم جلب نموذج بنفسه باستخدام -hf، وهذه أسرع طريقة للتأكد من أن عملية البناء تعمل.

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

يحدّد LLAMA_CACHE دليل التنزيل. من دونه، يُحفظ الملف في ~/.cache/llama.cpp ضمن حساب المستخدم الذي نفّذ الأمر، وهذا هو المكان الخطأ لخدمة ستجعل مجلد home الخاص بها غير قابل للقراءة بعد قليل. شغّل ls -lh /srv/models بعد ذلك، لأن اسم الملف المخزّن مؤقتاً يُشتق من اسم المستودع، لا من اسم الملف العادي.

بالنسبة إلى الخدمة، نزّل النموذج إلى مسار اخترته، حتى يحتوي ملف الوحدة على مسار ثابت يشير إليه.

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

مساحة القرص هي أول قيد يواجهه معظم المستخدمين. هذه هي أحجام الملفات المنشورة لنموذجين، وقد جرى التحقق منها في 18 August 2026.

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

حجم ملف 4-bit للنموذج ذي 1B هو 0.81 GB. ويبلغ حجم النموذج نفسه من دون quantisation مقدار 2.01 GB، لذلك يغيّر اختيار التنسيق الحجم بأكثر من الضعف. ويبلغ حجم نموذج 20B باستخدام MXFP4 مقدار 12.11 GB، وهذا لا يناسب القرص في كثير من الخطط المبدئية، كما يجب بعد ذلك تحميله إلى الذاكرة.

افحص df -h قبل كل تنزيل. إذا امتلأ root filesystem أثناء نقل بحجم 12 GB، فسيتعطل كل ما يحتاج إلى الكتابة، بما في ذلك journal.

شغّله مرة واحدة يدوياً وتحقق منه

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

في جلسة ثانية، اسأل الخادم عمّا إذا كان جاهزاً.

curl -s http://127.0.0.1:8080/health

أثناء تحميل الملف، تحصل على استجابة HTTP 503 ويكون نصها:

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

عندما يصبح جاهزاً، يكون النص {"status": "ok" }. أرسل بعد ذلك طلباً فعلياً.

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

كائن JSON يحتوي على مصفوفة choices يعني أن الخادم يعمل. يوجد الحقل model لأن عملاء OpenAI يرسلونه دائماً. حمّل هذا الخادم نموذجاً واحداً فقط، لذلك لا تُستخدم هذه القيمة لاختيار أي شيء.

واجهة API المتوافقة مع OpenAI، وما يوجد أيضاً على المنفذ

POST /v1/chat/completions وPOST /v1/completions وPOST /v1/embeddings هي المسارات المتوافقة مع OpenAI، بينما يعرض GET /v1/models النموذج المحمّل. ويمثل GET /health فحص الجاهزية الوارد أعلاه، ويعيد GET /props الإعدادات الحالية للخادم، ويعرض GET /metrics عدادات Prometheus عند بدء التشغيل باستخدام --metrics.

يعمل أي OpenAI SDK بعد ضبط عنوان URL الأساسي على http://127.0.0.1:8080/v1 وتمرير سلسلة غير فارغة كمفتاح API. لا يتحقق أي شيء من هذا المفتاح إلى أن تضبط --api-key بنفسك.

لا تعتمد على ادعاء أي شخص بشأن معدل المعالجة باعتباره رقماً مناسباً لخطتك. تعتمد سرعة الاستدلال باستخدام CPU على عدد الأنوية، وعرض نطاق الذاكرة، والخدمات الأخرى التي تشاركك الخادم المضيف. لذلك قِس عدد الرموز في الثانية على خادمك وتعامل مع النتيجة باعتبارها المرجع الفعلي. يظهر وقت CPU الذي يستولي عليه جار مزعج هنا على شكل سرعة توليد تتغير من ساعة إلى أخرى.

أبقِ الخدمة على 127.0.0.1 وضع proxy أمامها

--host مضبوط افتراضياً بالفعل على 127.0.0.1، لذلك يتعذر الوصول إلى الخادم من الخارج حتى تغيّر ذلك. اتركه كما هو. لا يوفّر llama-server نموذج مستخدمين، ولا تحديداً لمعدل الطلبات، ولا سجل تدقيق مفيداً. وعنصر التحكم المدمج الوحيد هو --api-key، الذي يقارن سلسلة نصية واحدة. يمثّل منفذ inference مفتوحاً قدرة حوسبة مجانية لأي شخص يعثر عليه. والخطأ نفسه مع Ollama له النمط ذاته: ينطبق تأمين واجهة نموذج مستضاف ذاتياً هنا حرفياً.

أنهِ TLS (أمان طبقة النقل) في nginx، ووجّه الطلبات إلى منفذ loopback.

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

مطلوب proxy_buffering off لدعم البث. عند تفعيل التخزين المؤقت، يحتفظ nginx بأحداث الخادم المرسلة (SSE) حتى يكتمل الرد. لذلك ينتظر العميل بصمت، ثم يتلقى الإجابة كاملة دفعة واحدة. يغطي proxy_read_timeout 600s عمليات التوليد الطويلة، لأن القيمة الافتراضية البالغة 60 ثانية تحوّل الإجابة البطيئة إلى 504 Gateway Time-out. احصل على الشهادة باستخدام Certbot وLet's Encrypt مع nginx.

وحدة systemd

اكتب /etc/systemd/system/llama-server.service.

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

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

توجد الإعدادات في أسطر Environment= لأن llama-server يقرأ متغيرات LLAMA_ARG_* لمعظم الخيارات، وتطغى وسيطة سطر الأوامر على المتغير المطابق. يوفّر ذلك مكاناً واحداً لتغيير حجم السياق، ويحافظ على قِصر ExecStart بما يكفي لقراءته سريعاً.

يجعل ProtectSystem=strict نظام الملفات بأكمله للقراءة فقط بالنسبة إلى هذه الوحدة، وهذا مناسب لأن الخادم يقرأ النموذج فقط. أضف ReadWritePaths=/srv/models إذا أردت أن تنزّل الخدمة نفسها النماذج باستخدام -hf. يخفي ProtectHome=yes كلاً من /home و/root، وهذا هو السبب الثاني للاحتفاظ بالنماذج في /srv: عند تفعيل ProtectHome، لا يعود المسار الافتراضي ~/.cache/llama.cpp مرئياً للعملية إطلاقاً.

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

يمثل enable --now الجزء الذي يتجاوزه بعض المستخدمين. من دون enable، تتوقف الخدمة بعد إعادة التشغيل التالية. إذا أردت جدولة مهام مرتبطة بالخدمة، مثل التحقق ليلاً من إصدار جديد، فإن خدمة systemd مع مؤقت هي الآلية المناسبة لذلك.

حدّد سلوك النظام عند نفاد الذاكرة قبل حدوثه

ينقسم استخدام الذاكرة إلى جزأين، ويتصرف كل منهما بطريقة مختلفة عند فرض حد. يُربط ملف النموذج بالذاكرة افتراضياً، لذلك تكون صفحاته مدعومة بالملف: يمكن للنواة إسقاطها ثم قراءتها مجدداً من القرص. أما ذاكرة KV cache، وهي الحالة الخاصة بكل token التي يحتفظ بها الخادم لكل محادثة نشطة، فهي ذاكرة مجهولة. ولا يمكن إسقاطها، لذلك تكون هي ما يؤدي إلى قتل العملية.

لهذا تؤدي الحدان الموجودان في الوحدة وظيفتين مختلفتين. MemoryHigh=3G هو حد لين: عند تجاوزه تضع النواة cgroup تحت ضغط استعادة الذاكرة، فتُطرَد صفحات النموذج المربوطة بالذاكرة وتُقرأ مجدداً من القرص عند معالجة token التالي. تواصل الخدمة عملها، لكنها تصبح أبطأ. MemoryMax=3500M هو حد صارم: عند تجاوزه تُقتل العملية، ويذكر journal ذلك بوضوح.

llama-server.service: A process of this unit has been killed by the OOM killer.

اضبط --ctx-size بنفسك. القيمة الافتراضية هي 0، وهذا يعني حجم السياق الذي دُرّب النموذج باستخدامه. في نموذج حديث ذي سياق طويل، يؤدي ذلك إلى تخصيص ذاكرة KV cache كبيرة جداً عند بدء التشغيل. ثم تتوقف الخدمة قبل أن تعالج طلباً واحداً. يضاعف --parallel التكلفة نفسها، لأن كل slot يحتفظ بحالة محادثته الخاصة، لذلك اتركه مضبوطاً على 1 حتى تتأكد من حاجتك إلى التزامن.

مع Restart=on-failure تعود الخدمة المتوقفة إلى العمل. إذا توقفت عند كل بدء تشغيل، يتوقف systemd عن المحاولة وتطبع systemctl status القيمة start request repeated too quickly. هذا هو السلوك الصحيح: فحلقة إعادة تشغيل تعيد قراءة ملف حجمه 12 GB كل خمس ثوانٍ أسوأ من انقطاع الخدمة. أصلح الحد أو حجم السياق، ثم امسح الحالة باستخدام sudo systemctl reset-failed llama-server.

راقب القيمة الفعلية باستخدام systemctl show llama-server -p MemoryCurrent أثناء تشغيل طلب. يشرح تقييد ذاكرة العملية ووحدة المعالجة المركزية باستخدام systemd هذه التوجيهات بمزيد من التفصيل.

تجنّب swap مع هذا النوع من أحمال العمل. فعندما يُنقل النموذج إلى swap، يتحول كل token إلى قراءات عشوائية الإزاحة من القرص. يحقق ربط ملف النموذج بالذاكرة النتيجة نفسها مع ضرر أقل، لأن النواة تقرأ الصفحات المطلوبة مباشرة من الملف.

متى يكون Ollama هو الخيار الأفضل

هذا تفرّع في المسار. اختر llama-server عندما تريد عملية واحدة مع flags تحددها، وbuild ثبّتَّه، وملف اخترته بنفسك، بحيث لا يتغير شيء من دون علمك لأن لا شيء آخر قيد التشغيل.

اختر Ollama عندما تريد إدارة النماذج: سحب النماذج بالاسم، والاحتفاظ بعدة نماذج على القرص، وإلغاء تحميل نموذج خامل، وإجراء الترقية بأمر واحد بدلاً من إعادة البناء. هذا عمل فعلي كنت ستحتاج إلى كتابة script لتنفيذه بنفسك. تشغيل Ollama على VPS ينفذ المهمة نفسها مع إجراء المقايضة في الاتجاه الآخر. يوفّر كلاهما API متوافقاً مع OpenAI، لذلك تبقى شيفرة العميل قابلة للاستخدام عند التبديل في أي من الاتجاهين.

ترقية إصدار مثبت

استبدل bNNNNN بالوسم الذي تريد الانتقال إليه.

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

يبقى الملف الثنائي القديم على القرص، لذلك لا تتطلب عملية الرجوع سوى ln -sfn إلى llama-server-b10488 ثم إعادة التشغيل. اقرأ ملاحظات الإصدار قبل الانتقال. ملفات GGUF مرتبطة بإصدارات، وتظل الملفات القديمة قابلة للتحميل، لكن أسماء الخيارات تتغير أحياناً: --mlock و--no-mmap مهملان بالفعل لصالح --load-mode، كما أن ملف الوحدة الذي يمرر خياراً محذوفاً يفشل عند البدء برسالة تفيد بوجود وسيط غير معروف.

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

error while loading shared libraries: libllama.so بعد نسخ الملف التنفيذي إلى مكان آخر. ينشئ البناء الافتراضي مكتبات مشتركة إلى جانبه. أعد البناء باستخدام -DBUILD_SHARED_LIBS=OFF، أو انسخ الدليل build/bin بالكامل.

Illegal instruction (core dumped) عند بدء التشغيل أو عند أول طلب. جرى تجميع الملف التنفيذي مع تفعيل GGML_NATIVE، لمعالج CPU مختلف عن المعالج الذي يشغّله. أعد البناء على هذا الجهاز، أو اضبطه باستخدام -DGGML_NATIVE=OFF.

c++: fatal error: Killed signal terminated program cc1plus أثناء البناء. أوقف النظام المترجم لأنه استخدم مقداراً كبيراً من الذاكرة. خفّض -j، أو أضف swap أثناء البناء ثم أزله بعد ذلك.

curl: (7) Failed to connect ... Connection refused من حاسوبك المحمول. هذا صحيح: يستمع الخادم على عنوان loopback الخاص بـVPS. اختبره من VPS نفسه، أو افتح نفقاً باستخدام ssh -L 8080:127.0.0.1:8080 user@your-vps واستخدم http://127.0.0.1:8080 محلياً.

HTTP 503 مع "message":"Loading model" خلال الثواني أو الدقائق الأولى بعد إعادة التشغيل. تستغرق قراءة ملف متعدد الجيجابايت وقتاً، ويبلغ systemd عن الوحدة على أنها نشطة فور بدء العملية، قبل وقت طويل من تحميل النموذج في الذاكرة.

تتوقف الطلبات عن الاستجابة ثم تُرجع 504 Gateway Time-out. تخلّى الـproxy عن الانتظار قبل اكتمال النموذج. ارفع proxy_read_timeout، وعطّل proxy_buffering حتى تصل الرموز إلى العميل فور إنتاجها.

تتكرر إعادة تشغيل الوحدة ثم تتوقف مع start request repeated too quickly. هناك شيء ينهيها عند كل بدء تشغيل. افحص journalctl -u llama-server بحثاً عن سطر OOM killer، ثم خفّض --ctx-size، أو خفّض --parallel، أو ارفع MemoryMax.

FAQ

هل أشغّل خادم llama.cpp أم Ollama على VPS؟

شغّل llama-server عندما تريد تثبيت إصدار محدد بدقة، وتمرير أعلام محددة، والاحتفاظ بنموذج واحد في ملف واحد لا يحدّثه أي شيء من دون علمك. شغّل Ollama عندما تريد إدارة النماذج وترقيتها بأمر واحد، لأن تنزيل النماذج بالاسم، والاحتفاظ بعدة نماذج على القرص، وإلغاء تحميل النماذج غير النشطة، كلها مهام ستضطر إلى برمجتها بنفسك. يوفّر كلاهما API متوافقاً مع OpenAI، لذلك لا يتغير كود العميل إذا بدّلت بينهما لاحقاً.

ما إصدار llama.cpp الذي ينبغي تثبيته؟

استخدم أي tag أنشأته واختبرته فعلياً. ينشئ llama.cpp tag لكل عملية دمج تقريباً، وتكون الأسماء أرقام build مثل b10488، الذي كان الأحدث في 18 August 2026. لا يوجد فرع stable منفصل، لذلك يتغير الإصدار "الحالي" عدة مرات يومياً. نفّذ الاستنساخ باستخدام --branch <tag>، وثبّت الملف الثنائي باسم يتضمن ذلك tag، ثم وجّه إليه symlink، بحيث يصبح الترقية والتراجع إلى إصدار سابق أمرين منفصلين.

كم يحتاج llama-server من RAM؟

ابدأ بحجم ملف GGUF، ثم أضف ذاكرة التخزين المؤقت KV، التي تزداد مع --ctx-size ومع عدد خانات --parallel. لا تغني الأرقام المنشورة عن قياس إعدادك بنفسك، لأن الإجمالي يعتمد على النموذج، وquantisation، وسياق الطلب الذي تسمح به. شغّل systemctl show llama-server -p MemoryCurrent أثناء وجود طلب قيد التنفيذ، واستخدم الرقم الذي يظهر لك.

لماذا يعيد /health الرمز 503 مع الرسالة "Loading model"؟

بدأت العملية، لكن ملف النموذج لم يُحمّل إلى الذاكرة بعد، لذلك يعيد الخادم {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}. هذا طبيعي بعد كل إعادة تشغيل، ويستمر بالقدر الذي يستغرقه قراءة الملف. تصبح المشكلة فعلية فقط عندما يتعامل عميل أو proxy مع أول 503 على أنه فشل نهائي. نفّذ الاستعلام دورياً إلى /health حتى يعيد {"status": "ok" }.

هل يمكنني إتاحة llama-server مباشرة على الإنترنت؟

لا تربطه بـ 0.0.0.0 ولا تفتح المنفذ. لا يحتوي على حسابات أو تحديد لمعدل الطلبات أو سجل طلبات مناسب للتدقيق، والفحص المدمج الوحيد هو --api-key، الذي يقارن سلسلة نصية واحدة. أبقِ الربط الافتراضي 127.0.0.1، وضع nginx أمامه مع TLS، واضبط --api-key أيضاً، حتى لا يؤدي خطأ واحد في إعداد proxy إلى إتاحة النموذج للجميع.