تفاوت Ollama و llama.cpp برای اجرا روی VPS

Ollama در برابر llama.cpp: می‌خواهید کدام لایه را اجرا کنید؟

Ollama و llama.cpp به شکلی که این پرسش القا می‌کند، رقیب یکدیگر نیستند. llama.cpp موتور inference است: فایل model را بارگذاری می‌کند و prompt را به token تبدیل می‌کند. Ollama یک model manager، یک background daemon و یک HTTP API است که روی این موتور قرار دارد. README مربوط به Ollama همچنان llama.cpp را به‌عنوان inference backend معرفی می‌کند (بررسی‌شده در 27 October 2026). بنابراین پرسش واقعی این نیست که کدام‌یک سریع‌تر است؛ پرسش این است که می‌خواهید کدام لایه را روی VPS خود اجرا کنید.

وقتی می‌خواهید سرویسی داشته باشید که modelها را با name دریافت کند و بدون نیاز به رسیدگی مداوم به کار ادامه دهد، Ollama را اجرا کنید. وقتی سرور کوچک است و باید فایل model، اندازه دقیق context و تعداد دقیق threadها را انتخاب کنید، llama.cpp را مستقیماً اجرا کنید؛ زیرا در یک VPS کوچک، هرکدام از این تنظیمات بخشی از memory محدودی را مصرف می‌کند که در اختیار ندارید.

ماهیت هر پروژه

پروژه llama.cpp یک پیاده‌سازی از استنتاج ترنسفورمر (transformer inference) به زبان‌های C و C++ است که بر پایه کتابخانه ggml ساخته شده است. این پروژه فایل‌های GGUF را می‌خواند. فرمت GGUF (مخفف GGML universal file format) یک کانتینر تک‌فایلی است که وزن‌ها، توکنایزر و متادیتای مورد نیاز موتور برای اجرای مدل را در خود جای می‌دهد. این پروژه برای وظایف مختلف، باینری‌های جداگانه‌ای ارائه می‌دهد. llama-server یک سرور HTTP است، llama-cli یک محیط تعاملی (prompt) است و llama-bench نرخ پردازش (throughput) را اندازه‌گیری می‌کند. این پروژه اکنون نسخه‌هایی با شماره‌گذاری معنایی (MAJOR.MINOR.PATCH) منتشر می‌کند و نسخه v0.7.0 که در 15 اکتبر 2026 منتشر شد، آخرین نسخه تا تاریخ 27 اکتبر 2026 بود. تگ‌های شبانه (nightly) با شماره ساخت نیز همچنان در کنار آن‌ها منتشر می‌شوند که روزانه چندین مورد هستند و جدیدترین آن‌ها در 27 اکتبر 2026، نسخه b11913 بود.

Ollama یک برنامه به زبان Go است. یک دیمون پس‌زمینه که با ollama serve اجرا می‌شود، مدل‌ها را بارگذاری کرده و به درخواست‌های HTTP پاسخ می‌دهد، و یک کلاینت خط فرمان با آن دیمون ارتباط برقرار می‌کند. در پشت هر دوی این‌ها، یک رجیستری در ollama.com قرار دارد که مدل‌های از پیش بسته‌بندی‌شده را نگهداری می‌کند. Ollama از نسخه‌گذاری معنایی استفاده می‌کند. نسخه v0.32.5 در 27 ژوئیه 2026 منتشر شد و نسخه v0.40.12 در 27 اکتبر 2026 در ساعت 00:07 UTC عرضه گردید. دستور ollama pull یک فایل GGUF را به همراه یک قالب پرامپت و مجموعه‌ای از پارامترهای پیش‌فرض دریافت کرده و سپس آن را در مسیر /usr/share/ollama/.ollama/models در لینوکس ذخیره می‌کند. این فایل‌ها روی دیسک روت قرار می‌گیرند و حجم هر کدام به چندین گیگابایت می‌رسد؛ بنابراین در یک VPS با حجم دیسک روت 25 گیگابایت، بهتر است پیش از آنکه سومین دانلود دیسک را پر کند، بدانید که دستور pull چه فایل‌هایی باقی می‌گذارد و چگونه می‌توان دایرکتوری مدل‌ها را به جای دیگری منتقل کرد.

این بسته‌بندی، تمام تفاوت موجود است. Ollama کوانتیزاسیون، قالب و طول کانتکست را برای شما تعیین می‌کند و یک نام واحد برای به‌خاطر سپردن به شما می‌دهد. در مقابل، llama.cpp این انتخاب‌ها را به صورت فلگ (flag) در اختیار شما می‌گذارد و برای تنظیماتی که تعیین نمی‌کنید، مقادیر پیش‌فرض خودکار در نظر می‌گیرد.

محور 1: کنترل مدل و کوانتیزاسیون (Quantisation)

کوانتیزاسیون، وزن‌ها را در بیت‌هایی کمتر از 16 یا 32 بیتِ مدل اصلی ذخیره می‌کند و بیلد‌های رایج GGUF به‌طور میانگین حدود 4، 5 یا 8 بیت برای هر وزن در نظر می‌گیرند. دقت در سراسر فایل یکسان نیست. در سورس کد کوانتیزر llama.cpp (مطالعه‌شده در 27 اکتبر 2026)، یک بیلد Q4_K_M اکثر تنسورها را در 4 بیت نگه می‌دارد، اما به لایه خروجی، تنسورهای attention value و feed-forward down در حدود نیمی از لایه‌ها، دقت 6 بیت Q6_K اختصاص می‌دهد، در حالی که تنسورهای کوچک مانند normها اصلاً کوانتیزه نمی‌شوند. همین موضوع باعث می‌شود یک مدل 8 میلیارد پارامتری در RAM یک VPS معمولی جا شود. نام‌گذاری GGUF پس از درک الگو خوانا است: Q4_K_M یعنی K-quant چهار بیتی، با اندازه متوسط (medium). عدد بالاتر دقت بیشتری حفظ می‌کند و حافظه بیشتری اشغال می‌کند.

[
  {
    "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 اوت 2026 خوانده شده و از بایت به GiB تبدیل شده‌اند. 6 بیلد از یک مدل وجود دارد و کوچک‌ترین آن‌ها 2.96 GiB و بزرگ‌ترین آن‌ها 7.95 GiB است. گزینه پیش‌فرض رایج، یعنی Q4_K_M، برابر با 4.58 GiB است. روی یک VPS با 4 GiB رم، همین یک انتخاب تعیین می‌کند که آیا مدل اصلاً بارگذاری می‌شود یا خیر. اندازه تنها نیمی از این تصمیم است، زیرا ردیفی که توانایی پرداخت هزینه آن را دارید، لزوماً ردیفی نیست که ارزش استفاده داشته باشد، و هزینه واقعی Q4، Q8 و fp16 در کیفیت پاسخ همان چیزی است که به شما می‌گوید آیا گیگابایت‌های اضافی ارزش افزوده محسوسی دارند یا خیر.

با 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 اندازه کانتکست (context size) بر حسب توکن است، -t تعداد تردها (thread count) است و -ngl تعیین می‌کند چند لایه به GPU منتقل شوند (در سرورهای بدون GPU، مقدار آن 0 است). تنظیمات تعیین‌نشده دارای مقادیر پیش‌فرض هستند و --fit به‌طور پیش‌فرض فعال است تا آرگومان‌های تنظیم‌نشده را با حافظه دستگاه تطبیق دهد.

در Ollama، کوانتیزاسیون همراه با تگی که pull می‌کنید اعمال می‌شود و ollama ls نشان می‌دهد که دقیقاً چه چیزی روی دیسک دارید. زمانی که رجیستری بیلد مورد نظر شما را ندارد، یک فایل GGUF را شخصاً import کنید. یک Modelfile بنویسید:

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

سپس آن را بیلد کرده و نتیجه را بررسی کنید:

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

طول کانتکست (Context length) تنظیمی است که کاربران را به دردسر می‌اندازد. Ollama مقدار پیش‌فرض خود را بر اساس VRAM موجود انتخاب می‌کند و سروری که GPU ندارد در کوچک‌ترین دسته قرار می‌گیرد: 4096 توکن. اگر یک سند 20000 توکنی به آن بفرستید، توکن‌های اضافی پیش از آنکه مدل آن‌ها را ببیند حذف می‌شوند، بنابراین مدل با اطمینان درباره فایلی که فقط نیمی از آن را خوانده، پاسخ اشتباه می‌دهد. آن را با OLLAMA_CONTEXT_LENGTH در دیمون یا با PARAMETER num_ctx در یک Modelfile افزایش دهید. اگر فقط یک کار به پنجره بزرگ‌تری نیاز دارد، num_ctx را می‌توان به ازای هر درخواست تنظیم کرد نه در سطح کل سرور، که باعث می‌شود کش اضافی برای سایر کارهایی که از دیمون خواسته می‌شود، اشغال نشود. llama.cpp نیز هیچ پیش‌فرض قابل اعتمادی ندارد. مقدار -c را صریحاً تعیین کنید و بدانید چه مقداری را تنظیم کرده‌اید.

محاسبات حافظه که کسی به شما نمی‌گوید

فایل مدل تمام هزینه نیست. کش KV (کش کلید/مقدار) به ازای هر لایه و هر توکن از متن، یک ورودی نگه می‌دارد و با رشد گفتگو، حجم آن نیز افزایش می‌یابد.

این محاسبات را برای Llama 3.1 8B انجام دهید. این مدل دارای 32 لایه، 8 هد کلید/مقدار و ابعاد هد 128 است. هر توکن هم یک کلید و هم یک مقدار را با 2 بایت برای هر کدام در فرمت f16 ذخیره می‌کند، بنابراین 2 x 8 x 128 x 2 = 4096 بایت به ازای هر لایه. در مجموع 32 لایه، این مقدار برابر با 128 KiB به ازای هر توکن است. در نتیجه، یک متن با 4096 توکن، 512 MiB و یک متن با 32,768 توکن، 4 GiB حافظه اشغال می‌کند.

بنابراین یک مدل Q4_K_M 8B با متن 4k، تقریباً به 4.58 GiB برای وزن‌ها، به علاوه حدود 0.5 GiB برای کش و همچنین حافظه مورد نیاز برای runtime نیاز دارد. این مدل در 4 GiB رم جا نمی‌شود. در 8 GiB رم با فضای کافی برای اجرا قرار می‌گیرد. اگر متن را در همان سیستم 8 GiB به 32k افزایش دهید، کش به‌تنهایی تمام فضای خالی را مصرف می‌کند. در حالی که مدل بارگذاری شده است، آن را به‌صورت زنده با free -h مشاهده کنید و به تخمینی که خودتان اندازه‌گیری نکرده‌اید، اعتماد نکنید. اگر برای چیزی فراتر از 8B برنامه‌ریزی می‌کنید، همان محاسبات انجام‌شده برای یک مدل 27B روی یک VPS فقط با CPU نشان می‌دهد که هر رده از 8 تا 64 گیگابایت واقعاً چه مقدار ظرفیت دارد.

Ollama این مقدار را چند برابر می‌کند. مقدار پیش‌فرض OLLAMA_NUM_PARALLEL برابر با 1 است و حافظه مورد نیاز مدل با ضرب این عدد در طول متن افزایش می‌یابد. اگر هر دو را هم‌زمان افزایش دهید، دیمون بی‌سروصدا چندین برابر رم مورد انتظار شما را درخواست می‌کند. همان محاسبات، سقف تعداد کاربران هم‌زمان شما را تعیین می‌کند، زیرا هر درخواست هم‌زمان به سهم خود از کش KV نیاز دارد، که این دلیل کند شدن سروری است که برای یک نفر مناسب به نظر می‌رسد اما در پنج نفر متوقف می‌شود.

محور 2: دیمونی که باید مدیریت کنید

اسکریپت نصب Ollama یک unit برای 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 دقیقه در حافظه نگه داشته شده و سپس تخلیه می‌شوند. درخواست بعدی باید کل فایل را دوباره بارگذاری کند تا بتواند پاسخ دهد. اگر کرنل هنوز فایل را در page cache خود نگه داشته باشد، این کار سریع است، اما فقط RAM مازاد آن را آنجا نگه می‌دارد و به‌محض اینکه پردازش‌های دیگر آن را خارج کنند، فایل باید از دیسک خوانده شود؛ بنابراین بارگذاری مجدد یک فایل 4.58 گیگابایتی، یک پاسخ 2 ثانیه‌ای را در حافظه‌های کند به 30 ثانیه تبدیل می‌کند. یک keep-alive طولانی، تأخیر را برطرف کرده و RAM را به‌طور دائم اشغال می‌کند. هر دو مورد هزینه‌های واقعی هستند. موردی را انتخاب کنید که آسیب کمتری می‌زند. اگر تصمیم گرفتید که مدل باید همیشه در حافظه بماند، تنظیم keep_alive برای حفظ مدل در دوره‌های بیکاری و پس از راه‌اندازی مجدد تنها به چند خط نیاز دارد و شما را از گرم کردن دستی مدل پس از هر بار restart سرور بی‌نیاز می‌کند.

llama.cpp هیچ دیمون یا کاربر سرویسی به شما نمی‌دهد، بنابراین باید هر دو را خودتان تنظیم کنید. از دایرکتوری llama.cpp که در آن build را انجام دادید، فایل باینری و کتابخانه‌های آن را در /usr/local نصب کنید، یک کاربر llama بسازید و یک کپی از مدل را به آن بدهید:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

اگر به‌جای build کردن از آرشیو release استفاده کردید، ExecStart را به llama-server موجود در آن ارجاع دهید، زیرا آرشیو کتابخانه‌هایش را در کنار فایل باینری نگه می‌دارد. سپس unit را به عنوان /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 فعال کنید. در این حالت، پردازش مدل را در تمام طول عمر خود در حافظه نگه می‌دارد. به‌صورت پیش‌فرض هیچ‌چیز در حالت بیکاری تخلیه نمی‌شود، اما افزودن --sleep-idle-seconds امکان تخلیه و بارگذاری خودکار را بدون متوقف کردن سرویس فراهم می‌کند. اگر نوشتن unitها برای شما تازگی دارد، این کار همان الگوی اجرای سرویس‌های شخصی تحت systemd روی یک VPS را دنبال می‌کند.

محور 3: APIای که برنامهٔ شما با آن ارتباط برقرار می‌کند

این محور اکنون بسیار محدودتر شده است. هر دو پروژه اکنون از قالب گفت‌وگوی OpenAI استفاده می‌کنند؛ بنابراین بیشتر کتابخانه‌های client با هرکدام از آن‌ها، فقط پس از تغییر base URL، کار می‌کنند.

Ollama روی 127.0.0.1:11434 گوش می‌دهد. مسیر سازگار با OpenAI آن http://localhost:11434/v1/chat/completions است و هم‌زمان یک API بومی را در /api/chat ارائه می‌کند. یک مسیر سازگار با Anthropic نیز مستند شده است. هیچ‌یک از این مسیرها به مدل اجازه نمی‌دهد به‌تنهایی چیزی را جست‌وجو کند؛ بنابراین اگر برنامهٔ شما به پاسخ‌هایی جدیدتر از داده‌های آموزشی مدل نیاز دارد، برای اتصال جست‌وجوی وب از طریق API مربوط به Ollama، Open WebUI یا یک حلقهٔ کوتاه ابزار برنامه‌ریزی کنید.

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"}]}'

اگر با flagهای بالا اجرا شود، llama-server روی 127.0.0.1:8080 گوش می‌دهد. این سرویس در حالت پیش‌فرض اکنون از پورت 9931 استفاده می‌کند (بررسی‌شده در 27 October 2026). بنابراین اگر برنامهٔ شما انتظار پورت 8080 را دارد، --port را در خط فرمان نگه دارید. این سرویس /v1/chat/completions، /v1/completions و /v1/embeddings را ارائه می‌کند و علاوه بر آن endpoint اختصاصی /completion و یک web UI داخلی دارد. همچنین routeهای عملیاتی‌ای ارائه می‌کند که Ollama ندارد: /health برای readiness probe، /props برای تنظیمات model بارگذاری‌شده، /slots برای نمایش وضعیت هر request slot، و /metrics با قالب Prometheus پس از افزودن --metrics؛ زیرا این endpoint به‌طور پیش‌فرض غیرفعال است. اگر قصد دارید این سرویس را monitor کنید، احتمالاً همین تفاوت تصمیم‌گیرنده خواهد بود.

هیچ‌یک از این دو server برای شما authentication را فعال نمی‌کند. هر دو، به‌دلیل منطقی، به‌طور پیش‌فرض فقط روی loopback در دسترس‌اند. از طریق SSH tunnel یا پشت یک reverse proxy به آن‌ها دسترسی پیدا کنید و هرگز پورت‌های 11434 یا 8080 را در معرض اینترنت قرار ندهید.

توانایی‌های واقعی یک VPS بدون GPU

یک VPS که فقط از CPU استفاده می‌کند، مدل‌های کوچک را به‌کندی اجرا می‌کند. این خلاصهٔ صادقانه‌ای از وضعیت است و بخش مفید ماجرا، دانستن حد و مرز آن است. پیش از طراحی هر سیستمی بر پایه آن، ابتدا اندازه‌گیری کنید:

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

ستون pp نشان‌دهنده سرعت پردازش پرامپت و ستون tg نشان‌دهنده سرعت تولید توکن است که هر دو با واحد توکن در ثانیه اندازه‌گیری می‌شوند. در یک پلن vCPU اشتراکی، یک مدل 8B با کوانتایز Q4_K_M معمولاً در بخش tg به سرعت‌های تک‌رقمی پایین می‌رسد. پردازش پرامپت بخشی است که بیشترین فشار را وارد می‌کند: کل پرامپت باید پیش از ظاهر شدن اولین توکن خروجی پردازش شود، بنابراین یک پرامپت سیستمی طولانی، به هر درخواست یک زمان انتظار اضافه می‌کند. طول پاسخ بخشی از هزینه است که می‌توانید کنترل کنید، زیرا با سرعت سه توکن در ثانیه، مدلی که 600 توکن تولید می‌کند، سرور را برای 200 ثانیه درگیر می‌کند؛ یعنی بیش از سه دقیقه فقط برای تولید متن. بنابراین محدود کردن خروجی با num_predict ارزان‌ترین راه برای جلوگیری از تبدیل شدن یک پاسخ طولانی به timeout است.

موارد قابل استفاده روی CPU: مدل‌های 1B تا 4B برای کارهایی مثل دسته‌بندی، استخراج داده، خلاصه‌سازی‌های کوتاه یا مسیریابی. پاسخ‌ها در عرض چند ثانیه می‌رسند و حافظه مورد نیاز در پلن‌های معمولی جا می‌شود. برای یک نمونه عملی در این ابعاد به‌جای یک بازه کلی، بررسی و اندازه‌گیری Nemotron 3.5 Lightning روی یک VPS تگ دقیق، میزان RAM مورد نیاز و سرعتی که بدون GPU حفظ می‌کند را نشان می‌دهد. موارد غیرقابل استفاده روی CPU: چت تعاملی با سرعت خواندن انسانی، دستیارهای کدنویسی، کار با اسناد طولانی یا هر چیزی که شامل یک حلقه عامل (agent loop) با فراخوانی‌های متوالی باشد. حلقه‌ای که دوازده فراخوانی چهار ثانیه‌ای انجام می‌دهد، یک دقیقه زمان می‌برد تا خروجی تولید کند. اگر قصد استفاده از دستیار کدنویسی دارید، اتصال یک عامل به مدلی که خودتان میزبانی می‌کنید مشخص می‌کند کدام کارها برای یک مدل محلی کوچک مناسب است و کدام‌ها باید روی یک API میزبانی‌شده باقی بمانند.

وقتی اعداد پاسخگو نیستند، دو راه خروج وجود دارد. اگر مشکل از هم‌زمانی (concurrency) و تعداد زیاد کاربران در لحظه است، انتخاب موتور تغییر می‌کند و مقایسه Ollama با vLLM برای سرویس‌دهی هم‌زمان این موضوع را پوشش می‌دهد. اگر مشکل از سرعت خام است، پاسخ استفاده از یک VPS مجهز به GPU است، جایی که -ngl معنا پیدا می‌کند. پیش از هر اقدامی، یک خط مبنا (baseline) برای سخت‌افزار خود به دست آورید، زیرا پهنای باند دیسک و حافظه به اندازه CPU در زمان بارگذاری تأثیرگذارند. یک بنچمارک تکرارپذیر برای VPS ارزش یک ساعت وقت گذاشتن را دارد.

نصب llama.cpp با نسخه ثابت (pinned)

هر دو پروژه به‌صورت هفتگی به‌روزرسانی می‌شوند، بنابراین نسخه‌ای که مستقر می‌کنید را ثبت کنید. دستور تک‌خطی بالادستی، نسخه فعلی را نصب می‌کند:

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

برای ثابت نگه‌داشتن یک نسخه خاص، به‌جای آن از فایل tarball پیش‌ساخته در صفحه releases استفاده کنید. این پروژه اکنون نسخه‌هایی با شماره‌گذاری معنایی (semantic versioning) نیز منتشر می‌کند: نسخه v0.7.0 در تاریخ 27 October 2026 آخرین نسخه بود و صفحه انتشار آن به نسخه شبانه b11669 برای فایل‌های باینری اشاره دارد. نسخه v0.8.0 در تاریخ 28 October 2026 منتشر شد و صفحه انتشار آن به نسخه شبانه b11960 برای فایل‌های باینری اشاره می‌کند. دستورات زیر از 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 با نسخه ثابت (pinned)

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

روش دستی، unit مربوط به systemd یا کاربر سرویس را ایجاد نمی‌کند، بنابراین باید خودتان آن‌ها را اضافه کنید. راهنمای کامل نصب Ollama روی VPS این مرحله از تنظیم سرویس را گام‌به‌گام پوشش می‌دهد.

حالت‌های شکست و پیام‌هایی که مشاهده خواهید کرد

Ollama از بارگذاری مدل خودداری می‌کند. نسخه‌های قدیمی‌تر Ollama پیش از بارگذاری، اندازه را بررسی می‌کردند و ollama run خطی با این شکل برمی‌گرداند:

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

سورس‌کد فعلی Ollama دیگر این پیام را ندارد (بررسی‌شده در 27 اکتبر 2026). Ollama اکنون بارگذاری را به llama-server می‌سپارد، بنابراین مدلی که در حافظه جا نمی‌شود، به عنوان خطای runner ظاهر می‌شود و با خطاهایی شبیه به موارد زیر شروع می‌شود:

llama-server reported out-of-memory during startup
llama-server process has terminated

در هر دو حالت، راه‌حل یکسان است. یک ردیف کوانتیزاسیون پایین‌تر بروید، طول context را کاهش دهید یا مدل کوچک‌تری انتخاب کنید.

llama.cpp شکست نمی‌خورد، بلکه بسیار کند عمل می‌کند. برنامه llama.cpp به‌طور پیش‌فرض فایل GGUF را memory-map می‌کند، بنابراین فایلی که از RAM بزرگ‌تر است همچنان اجرا می‌شود. در این حالت، هسته سیستم‌عامل (kernel) در هر توکن، وزن‌ها را از دیسک به حافظه و بالعکس منتقل می‌کند (paging) و سرعت تولید به چند ثانیه برای هر توکن کاهش می‌یابد، در حالی که استفاده از دیسک روی 100 درصد قفل می‌شود. برای غیرفعال کردن memory mapping از --load-mode none استفاده کنید. این گزینه جایگزین --no-mmap شده است که در build شماره b10224 به عنوان منسوخ (deprecated) ثبت شده و در buildهای فعلی دیگر وجود ندارد (بررسی‌شده در 29 اکتبر 2026). وقتی هسته سیستم‌عامل وارد عمل می‌شود، dmesg دلیل آن را نشان می‌دهد:

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

فایل مدل اصلاً بارگذاری نمی‌شود. یک فایل GGUF که برای خانواده‌ای از مدل‌ها ساخته شده که جدیدتر از موتور (engine) شماست، خطایی می‌دهد که نام معماری ناشناخته را ذکر می‌کند؛ جایی که <arch> نام ذخیره‌شده در متادیتای فایل است:

llama_model_load: error loading model: unknown model architecture: '<arch>'

راه‌حل، ارتقای موتور است، نه استفاده از فایلی متفاوت. این بهای ثابت نگه‌داشتن نسخه‌ها (pinning) است و به همین دلیل باید شماره build را یادداشت کنید. شما باید بدانید از چه نسخه‌ای در حال ارتقا هستید.

API به‌صورت محلی پاسخ می‌دهد اما از طریق برنامه شما خیر. Ollama روی 127.0.0.1:11434 گوش می‌دهد، بنابراین میزبان‌های دیگر با خطای connection refused مواجه می‌شوند. متغیر OLLAMA_HOST=0.0.0.0:11434 را فقط زمانی روی systemctl edit ollama تنظیم کنید که پورت پشت یک فایروال یا شبکه خصوصی قرار دارد، زیرا API هیچ لایه احراز هویتی در مقابل خود ندارد.

اولین پاسخ پس از یک وقفه بسیار کند است. تخلیه مدل (unload) پس از 5 دقیقه بیکاری رخ داده است و مدل دوباره در حال بارگذاری از دیسک است (اگر در page cache باقی نمانده باشد). اجرای ollama ps درست پیش از درخواست، نشان می‌دهد که چیزی بارگذاری نشده است که این موضوع را تأیید می‌کند. مقدار OLLAMA_KEEP_ALIVE را افزایش دهید.

پس کدام‌یک را باید اجرا کنید؟

زمانی که می‌خواهید مدل‌ها برای شما مدیریت شوند و بدون صرف وقت، یک endpoint با ساختار OpenAI داشته باشید، Ollama را اجرا کنید. این گزینه برای اولین استقرار و هر سناریویی که در آن انتخاب مدل دائماً تغییر می‌کند، انتخاب پیش‌فرض مناسبی است.

زمانی که محدودیت حافظه به قدری زیاد است که باید ردیف کوانتیزاسیون (quantisation) را خودتان انتخاب کنید، یا زمانی که برای مانیتورینگ به /health، /slots و /metrics نیاز دارید، یا وقتی به فلگی نیاز دارید که Ollama آن را ارائه نمی‌دهد، llama.cpp را مستقیماً اجرا کنید. این انتخاب صادقانه‌ای برای یک VPS است که مدل به‌سختی در آن جا می‌شود، زیرا تنظیماتی که باعث اجرای مدل در این شرایط می‌شود، دقیقاً همان تنظیماتی است که Ollama از طرف شما انتخاب می‌کند.

اجرای همزمان هر دو امری عادی است. از Ollama برای آزمایش‌ها و از llama.cpp برای مدلی که در محیط production قرار داده‌اید و نمی‌خواهید تغییری در آن ایجاد شود، استفاده کنید.

FAQ

آیا Ollama فقط یک wrapper برای llama.cpp است؟

تا حد زیادی، اما این wrapper کارهای واقعی انجام می‌دهد. README مربوط به Ollama، llama.cpp را به‌عنوان backend مربوط به inference معرفی می‌کند (بررسی‌شده در 27 October 2026). Ollama علاوه بر آن، یک model registry، prompt template برای تبدیل پیام‌های chat به prompt، مجموعه‌ای از sampling parameterهای پیش‌فرض، یک daemon با قابلیت unload کردن مدل در زمان idle، و یک HTTP API اضافه می‌کند. وقتی tokens per second را با تنظیمات یکسان مقایسه می‌کنید، در واقع همان engine را با خودش مقایسه می‌کنید. تفاوت واقعی این پروژه‌ها در management layer است.

کدام‌یک روی یک VPS فقط با CPU سریع‌تر است؟

هر دو از یک engine استفاده می‌کنند؛ بنابراین با یک model file، quantisation، context size و thread count یکسان، نتایج آن‌ها به هم نزدیک است. تفاوت‌هایی که کاربران گزارش می‌کنند معمولاً از defaultهای متفاوت، به‌ویژه context length و thread count، ناشی می‌شود، نه از engine. آن را با 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 آن را در کنار هر چیزی که از registry دریافت کرده‌اید فهرست می‌کند. به این ترتیب می‌توانید از quantisationی استفاده کنید که registry آن را ارائه نمی‌دهد.

برای یک مدل 8B به چه مقدار RAM نیاز دارم؟

اندازه فایل، به‌علاوه KV cache و runtime را در برآورد خود لحاظ کنید. یک build از Llama 3.1 8B با Q4_K_M حدود 4.58 GiB روی دیسک اشغال می‌کند و context با اندازه 4096 token تقریباً 512 MiB cache اضافه می‌کند؛ بنابراین 8 GiB RAM مقدار مناسبی است و 4 GiB کافی نیست. اندازه cache با context مقیاس می‌گیرد: همان مدل با context برابر با 32,768 token، به‌تنهایی حدود 4 GiB cache نیاز دارد. در Ollama، به خاطر داشته باشید که این نیاز با OLLAMA_NUM_PARALLEL نیز مقیاس می‌گیرد.