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

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

Ollama و llama.cpp آن‌طور که در این پرسش مطرح شده، رقیب یکدیگر نیستند. llama.cpp موتور استنتاج (inference engine) است: یک فایل مدل را بارگذاری کرده و prompt را به توکن تبدیل می‌کند. Ollama یک مدیر مدل، یک daemon پس‌زمینه و یک API مبتنی بر HTTP است که روی آن موتور قرار می‌گیرد. در فایل README مربوط به Ollama، همچنان از llama.cpp به عنوان backend استنتاج آن یاد شده است (بررسی‌شده در تاریخ 2 August 2026). بنابراین پرسش اصلی این است که می‌خواهید در کدام لایه روی VPS خود کار کنید، نه اینکه کدام‌یک سریع‌تر است.

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

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

پروژه llama.cpp یک پیاده‌سازی C و C++ از استنتاج (inference) مدل‌های ترنسفورمر است که بر پایه کتابخانه ggml ساخته شده است. این پروژه فایل‌های GGUF را می‌خواند. فرمت GGUF (مخفف GGML universal file format) یک کانتینر تک‌فایلی است که وزن‌ها، توکنایزر و متادیتای مورد نیاز موتور برای اجرای مدل را در خود جای می‌دهد. این پروژه برای وظایف مختلف، باینری‌های جداگانه‌ای ارائه می‌دهد. llama-server یک سرور HTTP است، llama-cli یک محیط تعاملی (prompt) است و llama-bench نرخ پردازش (throughput) را اندازه‌گیری می‌کند. نسخه‌های منتشر شده (Releases) به جای استفاده از نسخه‌سازی معنایی (semantic versioning)، با شماره ساخت (build number) برچسب‌گذاری می‌شوند. برچسب فعلی b10224 است که در تاریخ 2 اوت 2026 منتشر شده و تقریباً در تمامی روزهای کاری، یک برچسب جدید ارائه می‌شود.

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

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

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

کوانتیزاسیون، هر وزن را از 16 یا 32 بیت به 4، 5 یا 8 بیت کاهش می‌دهد. همین فرآیند باعث می‌شود یک مدل 8 میلیارد پارامتری در RAM یک VPS معمولی جای بگیرد. نام‌گذاری GGUF پس از درک الگو، خوانا است: Q4_K_M به معنای کوانتیزاسیون 4 بیتی از نوع K و اندازه متوسط (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 رم، همین یک انتخاب تعیین می‌کند که آیا مدل اصلاً بارگذاری می‌شود یا خیر.

در 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 است). هیچ‌چیز به‌صورت خودکار حدس زده نمی‌شود.

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

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

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

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

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

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

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

این محاسبات را برای Llama 3.1 8B انجام دهید. این مدل دارای 32 لایه، 8 هد کلید/مقدار و ابعاد هد 128 است. هر توکن هم یک کلید و هم یک مقدار را با فرمت f16 و هر کدام با حجم 2 بایت ذخیره می‌کند، بنابراین به ازای هر لایه 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 مشاهده کنید و به تخمینی که خودتان اندازه‌گیری نکرده‌اید، اعتماد نکنید.

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

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

llama.cpp هیچ دیمونی ارائه نمی‌دهد، بنابراین باید 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 فعال کنید. سپس این پردازش، مدل را در تمام طول عمر خود در حافظه نگه می‌دارد. هیچ‌چیز در حالت بیکاری تخلیه نمی‌شود، که به این معنی است که غافلگیری ناشی از بارگذاری مجدد وجود ندارد و راهی برای بازپس‌گیری حافظه جز متوقف کردن سرویس وجود ندارد. اگر نوشتن unit برای شما تازگی دارد، این کار دقیقاً از الگوی اجرای سرویس‌های شخصی تحت systemd روی یک VPS پیروی می‌کند.

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

این محور بسیار محدودتر شده است. هر دو پروژه اکنون از فرمت چت OpenAI پشتیبانی می‌کنند، بنابراین اکثر کتابخانه‌های کلاینت تنها با تغییر base 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 را ارائه می‌دهد؛ علاوه بر این، دارای endpoint اختصاصی /completion و یک رابط کاربری وب داخلی است. این سرویس همچنین مسیرهای عملیاتی را ارائه می‌دهد که Ollama فاقد آن‌هاست: /health برای بررسی آمادگی (readiness probe)، /props برای تنظیمات مدل بارگذاری‌شده، /slots برای مشاهده وضعیت هر اسلات درخواست، و /metrics با فرمت Prometheus. اگر قصد مانیتورینگ این سرویس را دارید، احتمالاً همین تفاوت تعیین‌کننده خواهد بود.

هیچ‌کدام از این سرورها به‌طور پیش‌فرض احراز هویت را برای شما فعال نمی‌کنند. هر دو به دلایل امنیتی به‌صورت پیش‌فرض روی 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 به سرعت‌های تک‌رقمی پایین می‌رسد. پردازش پرامپت بخشی است که بیشترین تأخیر را ایجاد می‌کند: کل پرامپت باید پیش از تولید اولین توکن خروجی پردازش شود، بنابراین یک پرامپت سیستمی طولانی، به هر درخواست یک زمان انتظار اضافه می‌کند.

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

وقتی اعداد پاسخگو نیستند، دو راه خروج وجود دارد. اگر مشکل از هم‌زمانی (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 استفاده کنید. نسخه 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 است. عملیات کامپایل چندین دقیقه زمان می‌برد و به رم بیشتری نسبت به کوچک‌ترین پلن‌های سرور نیاز دارد؛ بنابراین اگر سرور کوچک شما با کمبود حافظه مواجه شد، عملیات ساخت را روی یک سرور بزرگ‌تر انجام داده و فایل‌های باینری را منتقل کنید.

نصب 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 run خطی با این شکل برمی‌گرداند:

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

Ollama پیش از بارگذاری، اندازه را بررسی می‌کند، بنابراین سریعاً شکست می‌خورد و دلیل آن را اعلام می‌کند. یک ردیف کوانتیزاسیون پایین‌تر بروید، طول کانتکست (context length) را کاهش دهید یا مدل کوچک‌تری انتخاب کنید.

llama.cpp شکست نمی‌خورد، اما بسیار کند عمل می‌کند. برنامه llama.cpp به‌صورت پیش‌فرض فایل GGUF را memory-map می‌کند، بنابراین فایلی که از RAM بزرگ‌تر است همچنان اجرا می‌شود. در این حالت، هسته (kernel) در هر توکن وزن‌ها را از دیسک فراخوانی و خارج می‌کند و سرعت تولید به چند ثانیه برای هر توکن کاهش می‌یابد، در حالی که دیسک در وضعیت 100 درصد درگیری قرار دارد. برای اجبار به تخصیص واقعی حافظه و شکست خوردن فوری به‌جای افت عملکرد، از --no-mmap استفاده کنید. هنگامی که هسته مداخله می‌کند، dmesg دلیل آن را نشان می‌دهد:

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

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

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

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

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

اولین پاسخ پس از یک وقفه بسیار کند است. تخلیه مدل از حافظه پس از 5 دقیقه بیکاری رخ داده و مدل دوباره در حال خوانده شدن از دیسک است. اجرای 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) یاد شده است (بررسی‌شده در تاریخ 2 اوت 2026). Ollama علاوه بر آن، یک مخزن مدل (model registry)، قالب‌های prompt برای تبدیل پیام‌های چت به فرمت قابل‌فهم برای مدل، مجموعه‌ای از پارامترهای پیش‌فرض نمونه‌برداری (sampling)، یک daemon با قابلیت تخلیه خودکار مدل‌های بلااستفاده از حافظه، و یک HTTP API ارائه می‌دهد. وقتی تعداد توکن در ثانیه را در تنظیمات یکسان مقایسه می‌کنید، در واقع دارید همان موتور را با خودش می‌سنجید. آنچه در عمل انتخاب می‌کنید، لایه مدیریتی است.

کدام‌یک روی VPS بدون GPU سریع‌تر است؟

هر دو از موتور یکسانی استفاده می‌کنند؛ بنابراین در فایل مدل، کوانتیزاسیون (quantisation)، اندازه کانتکست و تعداد thread یکسان، عملکرد آن‌ها بسیار نزدیک به هم است. تفاوت‌هایی که کاربران گزارش می‌دهند معمولاً ناشی از تنظیمات پیش‌فرض متفاوت (به‌ویژه طول کانتکست و تعداد thread) است، نه خود موتور. پیش از باور کردن هر آمار منتشرشده، آن را با 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 مدل شما را در کنار مدل‌هایی که از مخزن اصلی دریافت کرده‌اید، فهرست می‌کند. این روشی است که می‌توانید از طریق آن از کوانتیزاسیون‌هایی که در مخزن اصلی موجود نیستند، استفاده کنید.

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

باید حجم فایل، به علاوه حافظه کش KV و فضای مورد نیاز برای runtime را در نظر بگیرید. نسخه Q4_K_M از مدل Llama 3.1 8B حدود 4.58 گیگابایت روی دیسک فضا اشغال می‌کند و یک کانتکست 4096 توکنی حدود 512 مگابایت حافظه کش اضافه می‌کند؛ بنابراین 8 گیگابایت RAM مقدار مناسبی است و 4 گیگابایت کافی نیست. حافظه کش با افزایش کانتکست مقیاس‌پذیر است: همان مدل با کانتکست 32768 توکنی، به‌تنهایی به حدود 4 گیگابایت حافظه کش نیاز دارد. در Ollama به یاد داشته باشید که این نیاز با OLLAMA_NUM_PARALLEL نیز افزایش می‌یابد.