تفاوت 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 استفاده کنید. زمانی که سرور شما کوچک است و باید فایل مدل دقیق، اندازه context دقیق و تعداد threadهای مشخص را انتخاب کنید، llama.cpp را مستقیماً اجرا کنید؛ زیرا در یک VPS کوچک، هر یک از این تنظیمات هزینه‌ای از حافظه را تحمیل می‌کند که شما در اختیار ندارید.

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

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

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

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

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

کوانتیزاسیون (Quantisation) هر وزن را از 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 رم، همین یک انتخاب تعیین می‌کند که آیا مدل اصلاً بارگذاری می‌شود یا خیر. اندازه تنها نیمی از این تصمیم است، زیرا ردیفی که توانایی خرید آن را دارید لزوماً ردیفی نیست که ارزش استفاده داشته باشد، و هزینه واقعی 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) بر حسب توکن است، -t تعداد رشته‌ها (Threads) را تعیین می‌کند و -ngl مشخص می‌کند چند لایه به GPU منتقل شوند (در سیستم‌های فقط CPU مقدار آن 0 است). هیچ چیزی به‌صورت خودکار حدس زده نمی‌شود.

در Ollama، کوانتیزاسیون همراه با تگی که pull می‌کنید اعمال می‌شود و ollama ls نشان می‌دهد که دقیقاً چه چیزی روی دیسک دارید. زمانی که رجیستری نسخه مورد نظر شما را ندارد، یک فایل GGUF را خودتان import کنید. یک 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 توکن. اگر یک سند 20,000 توکنی به آن بفرستید، توکن‌های اضافی پیش از آنکه مدل آن‌ها را ببیند حذف می‌شوند، بنابراین پاسخ مدل با اطمینان کامل درباره فایلی که فقط نیمی از آن را خوانده، اشتباه خواهد بود. آن را با OLLAMA_CONTEXT_LENGTH در daemon یا با PARAMETER num_ctx در یک Modelfile افزایش دهید. اگر فقط یک کار به پنجره بزرگ‌تری نیاز دارد، num_ctx را می‌توان به ازای هر درخواست تنظیم کرد نه در سطح کل سرور، که باعث می‌شود حافظه کش اضافی برای سایر کارهایی که از daemon خواسته می‌شود، اشغال نشود. 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 دقیقه در حافظه باقی می‌مانند و سپس تخلیه می‌شوند. درخواست بعدی مجبور است کل فایل را دوباره از دیسک بخواند تا بتواند پاسخ دهد؛ بنابراین بارگذاری مجدد یک فایل 4.58 GiB، زمان پاسخ‌دهی را روی حافظه‌های کند از 2 ثانیه به 30 ثانیه افزایش می‌دهد. یک keep-alive طولانی، تأخیر را برطرف می‌کند و RAM را به‌طور دائم اشغال می‌نماید. هر دو مورد هزینه‌های واقعی هستند. گزینه‌ای را انتخاب کنید که آسیب کمتری می‌زند. اگر تصمیم گرفتید که مدل باید همیشه در حافظه بماند، تنظیم keep_alive به‌گونه‌ای که در دوره‌های بیکاری و پس از reboot باقی بماند تنها به چند خط نیاز دارد و شما را از گرم کردن دستی مدل پس از هر بار راه‌اندازی مجدد سرور بی‌نیاز می‌کند.

ابزار 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 برای مشاهده وضعیت هر slot درخواست، و /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 به سرعت‌های تک‌رقمی پایین می‌رسد. پردازش پرامپت بخشی است که بیشترین فشار را وارد می‌کند: کل پرامپت باید پیش از ظاهر شدن اولین توکن خروجی پردازش شود، بنابراین یک پرامپت سیستمی طولانی، به هر درخواست یک زمان انتظار اضافه می‌کند. طول پاسخ بخشی از هزینه است که می‌توانید کنترل کنید، زیرا با سرعت سه توکن در ثانیه، مدلی که 600 توکن تولید می‌کند، سرور را برای سه دقیقه درگیر نگه می‌دارد؛ بنابراین محدود کردن خروجی با 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)

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

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 است. عملیات کامپایل چندین دقیقه زمان می‌برد و به 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 run خطی با این ساختار برمی‌گرداند:

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

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

llama.cpp شکست نمی‌خورد، اما بسیار کند عمل می‌کند. llama.cpp به‌صورت پیش‌فرض GGUF را memory-map می‌کند، بنابراین فایلی که از RAM بزرگ‌تر است نیز اجرا می‌شود. در این حالت، هسته (kernel) در هر توکن، وزن‌ها را از دیسک فراخوانی و خارج می‌کند (page in/out) و سرعت تولید به چند ثانیه برای هر توکن می‌رسد، در حالی که دیسک در وضعیت 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 دقیقه بیکاری (idle unload) رخ داده و مدل دوباره در حال خوانده شدن از دیسک است. دستور 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 August 2026). Ollama علاوه بر آن، یک رجیستری مدل، قالب‌های prompt برای تبدیل پیام‌های چت به prompt، مجموعه‌ای از پارامترهای پیش‌فرض نمونه‌برداری (sampling)، یک daemon با قابلیت تخلیه خودکار حافظه در زمان بیکاری و یک HTTP API ارائه می‌دهد. وقتی تعداد توکن در ثانیه را در تنظیمات یکسان مقایسه می‌کنید، در واقع دارید یک موتور واحد را با خودش می‌سنجید. آنچه در عمل انتخاب می‌کنید، لایه مدیریتی است.

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

هر دو از یک موتور استفاده می‌کنند، بنابراین در فایل مدل، کوانتیزاسیون (quantisation)، اندازه context و تعداد thread یکسان، عملکرد آن‌ها بسیار نزدیک به هم است. تفاوت‌هایی که کاربران گزارش می‌دهند معمولاً ناشی از تنظیمات پیش‌فرض متفاوت—به‌ویژه طول context و تعداد 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 cache و به‌علاوه فضای مورد نیاز برای runtime را در نظر بگیرید. یک نسخه Q4_K_M از مدل Llama 3.1 8B حدود 4.58 گیگابایت روی دیسک فضا اشغال می‌کند و یک context با 4096 توکن، تقریباً 512 مگابایت حافظه cache اضافه می‌کند؛ بنابراین 8 گیگابایت RAM مقدار مناسبی است و 4 گیگابایت کافی نیست. حافظه cache با افزایش context مقیاس‌پذیر است: همان مدل با context 32,768 توکنی، به‌تنهایی به حدود 4 گیگابایت حافظه cache نیاز دارد. در مورد Ollama، به یاد داشته باشید که این نیاز با OLLAMA_NUM_PARALLEL نیز افزایش می‌یابد.