راهنمای نصب و اجرای Ollama روی VPS با امنیت بالا

آنچه در حال ساخت آن هستید

یک مدل زبانی با وزن‌های باز (open-weight) که روی سروری تحت مالکیت شما اجرا می‌شود و پاسخ‌ها را از طریق یک API با پروتکل HTTP و در صورت تمایل، یک صفحه چت در مرورگر ارائه می‌دهد. Ollama ابزاری است که مدل را دانلود کرده، در حافظه بارگذاری می‌کند و درخواست‌ها را روی http://127.0.0.1:11434 پاسخ می‌دهد. نصب آن تنها با یک دستور انجام می‌شود. بخش‌های دشوار این کار در جای دیگری نهفته است: انتخاب مدلی که VPS شما واقعاً توانایی نگهداری آن در RAM را داشته باشد و عدم انتشار تصادفی یک سرور استنتاج (inference) بدون احراز هویت در کل اینترنت.

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

واقعیت‌سنجی ابعاد مدل با اعداد ساده

میزان حافظه مورد نیاز یک مدل تقریباً برابر است با حجم فایل آن، به‌علاوه حدود یک گیگابایت سربار زمان اجرا و مقداری فضای بیشتر برای پنجره متن (context window). تگ‌های پیش‌فرض اکثر مدل‌های محبوب Ollama، از جمله llama3.2:3b، llama3.1:8b و mistral:7b، از نوع 4-bit quantized (با برچسب Q4_K_M) هستند که به ازای هر یک میلیارد پارامتر، حدود نیم گیگابایت رم اشغال می‌کنند. همه مدل‌های پیش‌فرض Q4 نیستند: مدل‌های بسیار کوچک مانند smollm2:135m با دقت 16-bit عرضه می‌شوند، بنابراین پیش از انجام محاسبات، خط مربوط به quantization را در صفحه کتابخانه مدل بررسی کنید. محاسبات ساده است و تعیین‌کننده همه چیز خواهد بود. عبارت آخر همان چیزی است که خودتان تنظیم می‌کنید: افزایش num_ctx فراتر از مقدار پیش‌فرض کوچک Ollama فضای بیشتری برای پرامپت‌های طولانی‌تر فراهم می‌کند، اما حافظه کش KV را در رم افزایش می‌دهد؛ پس پیش از قضاوت درباره اینکه آیا مدل در سیستم شما جا می‌شود یا خیر، طول context را مشخص کنید.

یک مدل 3B مانند llama3.2:3b حدود 2 گیگابایت حجم دانلود دارد و برای اجرا به حدود 4 گیگابایت رم آزاد نیاز دارد. یک مدل 7B یا 8B مانند mistral:7b یا llama3.1:8b حدود 5 گیگابایت روی دیسک فضا می‌گیرد و به حدود 8 گیگابایت رم نیاز دارد (16 گیگابایت برای عملکرد مطلوب توصیه می‌شود). یک مدل 13B یا 14B تقریباً به 16 گیگابایت رم نیاز دارد. هر مدلی در محدوده 30B تا 70B به سیستمی با رم بالا یا در واقعیت به یک GPU نیاز دارد؛ روی یک VPS مبتنی بر CPU، این مدل‌ها یا اجرا نمی‌شوند یا آن‌قدر کند پاسخ می‌دهند که عملاً غیرقابل استفاده هستند.

حالا نوبت سرعت است، بخشی که معمولاً دست‌کم گرفته می‌شود. استنتاج (inference) روی CPU محدود به پهنای باند حافظه است، نه سرعت کلاک؛ و یک VPS با vCPU اشتراکی پهنای باند محدودی دارد. انتظار سرعتی بین تک‌رقمی تا دو‌رقمی پایین (تعداد توکن در ثانیه) را داشته باشید: یک مدل 7-8B با کوانتایز Q4 ممکن است 4 تا 10 توکن در ثانیه و یک مدل 3B حدود 10 تا 25 توکن در ثانیه تولید کند. سرعت GPU تقریباً یک مرتبه بزرگی بیشتر است. این ارقام به‌صورت تقریبی ارائه شده‌اند؛ رویکرد صادقانه این است که سیستم خودتان را اندازه‌گیری کنید که در مرحله run در ادامه نشان داده شده است. به eval rate خود اعتماد کنید، نه به عددی که در هیچ مقاله‌ای، از جمله همین مقاله، آمده است.

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

برای سنجش یک مدل خاص در برابر یک سیستم خاص، میزان حافظه مورد نیاز آن را در اینجا تخمین بزنید:

نصب Ollama

دو روش تمیز برای این کار وجود دارد. استفاده از اسکریپت رسمی در یک VPS خام، ساده‌ترین راه است:

curl -fsSL https://ollama.com/install.sh | sh

curl -fsSL https://ollama.com/install.sh | sh

این کار یک کاربر سیستمی به نام ollama ایجاد می‌کند، فایل باینری را در /usr/local/bin/ollama نصب کرده و یک سرویس systemd با نام ollama.service ثبت می‌کند که در زمان بوت اجرا شده و روی 127.0.0.1:11434 گوش می‌دهد. فعال بودن آن را تأیید کنید:

systemctl status ollama
ollama --version

systemctl status ollama

اگر از قبل Docker را اجرا می‌کنید، از کانتینر استفاده کنید:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

به پیشوند 127.0.0.1: در نگاشت پورت دقت کنید. این کار پورت را فقط به localhost محدود می‌کند. نوشتن -p 11434:11434 به جای آن، سرویس را روی تمام اینترفیس‌ها منتشر می‌کند که همان اشتباهی است که در بخش امنیت نسبت به آن هشدار داده شده است. یکی از روش‌های نصب را انتخاب کنید؛ اسکریپت و کانتینر را هم‌زمان اجرا نکنید، زیرا دو پردازش بر سر تصاحب پورت با یکدیگر تداخل پیدا می‌کنند.

دریافت و اجرای اولین مدل

ollama pull llama3.2:3b
ollama run llama3.2:3b

دستور pull لایه‌های مدل را روی دیسک دانلود می‌کند (حدود 2 گیگابایت برای این مدل). دستور run آن‌ها را در حافظه بارگذاری کرده و شما را به یک اعلان >>> می‌برد. یک پرسش تایپ کنید. تولید اولین توکن ممکن است چند ثانیه طول بکشد، زیرا وزن‌ها از دیسک به RAM منتقل می‌شوند؛ پس از آن، پاسخ به‌صورت جریانی نمایش می‌یابد. برای خروج از محیط چت، /bye را تایپ کنید؛ Ollama در پس‌زمینه به اجرای خود ادامه می‌دهد.

مشاهده مدل‌های بارگذاری‌شده و نحوه قرارگیری آن‌ها در حافظه:

ollama ps

ستون PROCESSOR واقعیت را نشان می‌دهد. مقدار 100% CPU به این معناست که هیچ GPU درگیر نیست و کندی سرعت دقیقاً به همین دلیل است. برای اندازه‌گیری سرعت واقعی، از فلگ verbose استفاده کنید:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

خط eval rate که در پایان چاپ می‌شود، نشان‌دهنده تعداد توکن در ثانیه روی این سخت‌افزار است. این عددی است که باید برای برنامه‌ریزی‌های خود در نظر بگیرید.

محل ذخیره‌سازی مدل‌ها و میزان فضای دیسک مورد نیاز

مدل‌هایی که توسط اسکریپت نصب شده و به‌عنوان سرویس اجرا می‌شوند، در دایرکتوری خانگی کاربر ollama قرار دارند:

sudo du -sh /usr/share/ollama/.ollama/models

اگر مدل‌ها را به‌صورت تعاملی و با کاربر خودتان اجرا کنید، در مسیر ~/.ollama/models ذخیره می‌شوند. در داخل کانتینر، این مدل‌ها در volume نام‌گذاری‌شده ollama قرار می‌گیرند. این موضوع اهمیت دارد زیرا حجم وزن‌های کوانتایز شده (quantized weights) به‌سرعت افزایش می‌یابد: یک مدل 3B حدود 2 GB، یک مدل 7-8B حدود 5 GB و یک مدل 14B حدود 9 GB فضا اشغال می‌کند. اگر چهار مدل را برای مقایسه دانلود کنید، بدون اینکه متوجه شوید 20 GB از فضای دیسک خود را مصرف کرده‌اید. ظرفیت دیسک را متناسب با مدل‌هایی که قصد نگهداری آن‌ها را دارید در نظر بگیرید و بقیه را با دستور ollama rm <model> حذف کنید. اگر همان VPS در حال حاضر سرویس دیگری با مصرف دیسک بالا اجرا می‌کند، مانند PhotoPrism یا Immich که کتابخانه‌ای از عکس‌ها را نگهداری می‌کنند، ابتدا آن مقدار را از فضای خالی کسر کنید و باقی‌مانده را به‌عنوان بودجه واقعی فضای دیسک برای مدل‌ها در نظر بگیرید.

اجرای آن به عنوان سرویسی که تحت کنترل شماست

اسکریپت نصب قبلاً ollama.service را ثبت کرده است، بنابراین سرویس بدون نیاز به اقدام اضافی در زمان بوت دوباره راه‌اندازی می‌شود. تنظیمی که ارزش تغییر دارد، مدت زمان ماندگاری مدل در حافظه (resident) است و در برخی پیکربندی‌ها، آدرس bind؛ هر دو مورد باید در یک فایل drop-in مربوط به systemd قرار گیرند تا با ارتقای Ollama بازنویسی نشوند:

sudo systemctl edit ollama.service

این موارد را زیر سرتیتر [Service] که ویرایشگر به شما نشان می‌دهد، اضافه کنید:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE مشخص می‌کند که یک مدل پس از آخرین درخواست، چه مدت در حافظه باقی بماند (مقدار پیش‌فرض 5 دقیقه است). اگر سیستمی دارید که در طول روز مدام از آن کوئری می‌گیرید، این مقدار را افزایش دهید تا از بارگذاری مجدد وزن‌ها (weights) در هر بار جلوگیری شود؛ در سیستمی با منابع محدود، آن را روی 0 تنظیم کنید تا بلافاصله پس از پایان درخواست، RAM آزاد شود. اگر می‌خواهید یک مدل به‌جای یک بازه زمانی مشخص، به‌طور نامحدود در حافظه بماند، نگه داشتن دائمی مدل Ollama در حافظه فیلد keep_alive در هر درخواست و نحوه گرم نگه داشتن وزن‌ها پس از reboot (به‌جای مواجهه با اولین درخواست کند) را پوشش می‌دهد. systemctl edit فایل‌های unit را برای شما بارگذاری مجدد می‌کند، بنابراین برای اعمال تغییرات، سرویس را restart کنید:

sudo systemctl restart ollama

مهم‌ترین نکته امنیتی

به‌صورت پیش‌فرض، Ollama روی 127.0.0.1:11434 گوش می‌دهد، بنابراین فقط پردازش‌های موجود روی همان VPS می‌توانند به آن دسترسی داشته باشند. این رفتار پیش‌فرض صحیح است. آن را تغییر ندهید.

این API هیچ‌گونه احراز هویتی ندارد. هیچ. نه کلید API، نه ورود به سیستم و نه محدودیت نرخ (rate limit) وجود دارد. تنها لیست مجاز (allow-list) موجود، یعنی OLLAMA_ORIGINS، فقط کنترل می‌کند که کدام مبدأهای مرورگر (CORS) اجازه فراخوانی آن را دارند؛ این تنظیم هیچ تأثیری در جلوگیری از curl یا اسکریپت‌های موجود در ماشین‌های دیگر ندارد. هر کسی که بتواند به پورت 11434 دسترسی پیدا کند، می‌تواند هر مدلی که دانلود کرده‌اید را اجرا کند، مدل‌های جدید دانلود کند، آن‌ها را حذف کند و CPU یا GPU شما را برای مدت نامحدود در بار کاری کامل قرار دهد. اسکنرهایی مانند Shodan هزاران نمونه Ollama را فهرست می‌کنند و یک نمونه در معرض دید، ظرف چند ساعت پیدا و مورد سوءاستفاده قرار می‌گیرد.

بنابراین، این تنها اشتباهی است که هرگز نباید مرتکب شوید: OLLAMA_HOST=0.0.0.0 را تنظیم نکنید و پورت 11434 را در فایروال خود باز نکنید. این کار یک سرور استنتاج (inference) بدون احراز هویت را در کل اینترنت منتشر می‌کند. هیچ مقدار پیکربندی نمی‌تواند 11434 خام روی 0.0.0.0 را ایمن کند، زیرا هیچ‌کدام از تنظیمات مستند Ollama احراز هویت به API محلی اضافه نمی‌کنند و لیست مجاز مبدأ، به معنای ورود به سیستم نیست. این یک قانون در مورد این سرویس خاص است، نه ممنوعیت همیشگی باز کردن پورت: یک relay خودمیزبان RustDesk برای دسکتاپ از راه دور برای انجام وظیفه خود باید ترافیک عمومی را بپذیرد، و این امتیاز را با داشتن احراز هویت مبتنی بر کلید و لیست کوتاهی از پورت‌های مستند کسب می‌کند؛ چیزی که Ollama فاقد آن است.

سه روش ایمن برای دسترسی به مدل از خارج از سرور وجود دارد:

• آن را محلی نگه دارید. اگر تنها فراخواننده، برنامه دیگری روی همان VPS، یک اسکریپت cron، یک ربات یا یک سرور MCP که ابزارهای شما را به مدل متصل می‌کند است، bind را روی 127.0.0.1 بگذارید و آن برنامه را وادار کنید که http://127.0.0.1:11434 را فراخوانی کند. هیچ‌چیز در معرض دید قرار نمی‌گیرد و به چیز دیگری نیاز نیست.
• از طریق یک تونل خصوصی به آن دسترسی پیدا کنید. VPS را روی یک شبکه خصوصی WireGuard که خودتان میزبانی می‌کنید قرار دهید، OLLAMA_HOST را روی آدرس تونل تنظیم کنید (برای مثال 10.8.0.1، نه 0.0.0.0) و فقط همتایان VPN می‌توانند متصل شوند. اینترنت عمومی همچنان هیچ‌چیز را روی پورت 11434 نمی‌بیند.
• یک reverse proxy با قابلیت احراز هویت در مقابل آن قرار دهید. TLS را در nginx، Traefik یا Caddy خاتمه دهید و یک رمز عبور یا توکن درخواست کنید، سپس درخواست را به 127.0.0.1:11434 پروکسی کنید. Ollama همچنان روی localhost باقی می‌ماند؛ پروکسی تنها چیزی است که روی پورت عمومی گوش می‌دهد. این همان ساختاری است که برای قرار دادن یک گواهی Let’s Encrypt روی nginx در مقابل هر سرویس محلی استفاده می‌شود.

گزینه reverse proxy دقیقاً همان چیزی است که رابط کاربری چت در مرحله بعد به شما ارائه می‌دهد، همراه با یک ورود به سیستم واقعی.

افزودن رابط کاربری چت با Open WebUI در پشت TLS

Open WebUI یک رابط کاربری چت برای میزبانی شخصی است. آن را در Docker اجرا کنید و به Ollama محلی متصل نمایید:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

فلگ --network=host جزئیات مهمی در یک VPS لینوکسی است. این فلگ کانتینر را در فضای نام شبکه میزبان قرار می‌دهد، بنابراین 127.0.0.1 در داخل کانتینر همان loopback خود میزبان است و کانتینر بدون نیاز به گوش دادن Ollama روی هیچ رابط دیگری، به آن در 127.0.0.1:11434 دسترسی پیدا می‌کند. دستورالعمل شبکه bridge که در جاهای دیگر می‌بینید، یعنی --add-host=host.docker.internal:host-gateway با OLLAMA_BASE_URL=http://host.docker.internal:11434، در اینجا کار نمی‌کند: آن نام به gateway شبکه bridge داکر اشاره دارد و سرویسی که روی 127.0.0.1 در میزبان bind شده باشد، از طریق bridge قابل دسترسی نیست؛ بنابراین Open WebUI فقط منتظر می‌ماند و گزارش می‌دهد که نمی‌تواند به Ollama متصل شود.

نکته منفی استفاده از شبکه میزبان این است که Open WebUI اکنون روی پورت 8080 میزبان در تمام رابط‌ها گوش می‌دهد؛ هرگونه نگاشت -p نادیده گرفته می‌شود و داکر هشداری در این مورد چاپ می‌کند. بنابراین پورت 8080 را هم در میزبان و هم در فایروال ارائه‌دهنده ببندید و اجازه دهید reverse proxy با TLS تنها درگاه عمومی باشد. در اولین بازدید، Open WebUI از شما می‌خواهد یک حساب کاربری مدیر ایجاد کنید؛ آن حساب لایه احراز هویت شماست، پس یک رمز عبور قوی انتخاب کنید.

برای باز کردن چت از لپ‌تاپ خود از طریق HTTPS، یک reverse proxy با TLS در مقابل 127.0.0.1:8080 قرار دهید. اگر قبلاً چندین برنامه داکر را روی سرور مسیریابی کرده‌اید، Traefik با TLS خودکار برای چندین برنامه تمیزترین گزینه است: یک بلوک label گواهی صادر می‌کند و chat.example.com را به Open WebUI هدایت می‌کند. همان مسیریابی label-per-app چیزی است که هر رابط کاربری مرورگر دیگری روی سرور از آن استفاده خواهد کرد، چه یک داشبورد وضعیت باشد یا چیزی سرگرم‌کننده‌تر مانند Halcyon که کتابخانه Jellyfin را به شکل یک فروشگاه اجاره فیلم دهه 90 نمایش می‌دهد، که هر کدام روی نام دامنه خود و پشت لاگین اختصاصی خود قرار دارند. قانون بخش امنیت همچنان پابرجاست؛ پروکسی مالک پورت عمومی و لاگین است، در حالی که Ollama روی localhost باقی می‌ماند و پورت 8080 خودِ Open WebUI توسط فایروال مسدود می‌ماند.

استفاده از endpoint سازگار با OpenAI در کد خود

Ollama زیرمجموعه‌ای از API چت OpenAI را در /v1 ارائه می‌دهد، بنابراین اکثر کتابخانه‌های کلاینت OpenAI با تغییر دو مورد کار می‌کنند: آدرس پایه (base URL) و یک کلید (key) صوری.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

مقدار api_key توسط کتابخانه کلاینت الزامی است اما توسط Ollama نادیده گرفته می‌شود، بنابراین هر رشته‌ای (string) کار می‌کند. model باید نام مدلی باشد که قبلاً آن را pull کرده‌اید؛ نام ناشناخته منجر به خطای 404 با model 'x' not found می‌شود. یک فراخوانی ساده با curl نیز از همین منطق پیروی می‌کند:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

این همان روشی است که مدل را به ابزارهای agent و ویرایشگر متصل می‌کنید. اگر قبلاً روی این سیستم توسعه می‌دهید، یک مدل محلی می‌تواند پشتیبان اسکریپت‌ها و افزونه‌ها در کنار اجرای Claude Code روی VPS داخل tmux باشد. این کار باعث می‌شود پیش‌نویس‌های ارزان و خصوصی خارج از APIهای پولی انجام شوند، در حالی که استدلال‌های سنگین همچنان توسط یک مدل میزبانی‌شده (hosted) پردازش می‌شوند.

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

فرآیند در میانهٔ تولید متن «Killed» می‌شود. شما یک مدل بزرگ را اجرا می‌کنید و ترمینال عبارت Killed را چاپ می‌کند، یا لاگ سرور (journalctl -u ollama) خطی را نشان می‌دهد که با llama-server process has terminated شروع می‌شود. این متن در Ollama نسخه 0.40.7، که در تاریخ 21 اکتبر 2026 بررسی شد، وجود دارد؛ نسخه‌های قدیمی‌تر عبارت llama runner process has terminated: signal: killed را نمایش می‌دادند. مکانیزم OOM killer در لینوکس آن را متوقف کرده است، زیرا مدل به RAM بیشتری نسبت به آنچه سیستم در اختیار دارد، نیاز داشته است. علت را با sudo dmesg | grep -i oom تأیید کنید، جایی که خطی شبیه به Out of memory: Killed process ... خواهید دید. راه‌حل، استفاده از یک مدل کوچک‌تر یا با کوانتیزاسیون (quantization) سنگین‌تر، مثلاً llama3.2:3b به‌جای مدل 13B، یا افزودن swap است تا باری که فقط کمی از RAM فیزیکی فراتر می‌رود، به‌جای مرگ، به‌کندی اجرا شود. Swap یک کرش آنی را به یک پاسخ کند تبدیل می‌کند؛ اما باعث نمی‌شود یک مدل 70B روی 4 گیگابایت RAM قابل استفاده شود. این توقف (kill) بی‌صدا است، مگر اینکه اتفاقی در حال تماشای ترمینال باشید؛ بنابراین روی سیستمی که از راه دور به آن کوئری می‌فرستید، متصل کردن یک unit از نوع OnFailure= به ollama.service که به یک سرور ntfy که برای هشدارهای push میزبانی می‌کنید ارسال می‌شود، به شما کمک می‌کند تا لحظه مرگ سرویس را بفهمید و مجبور نباشید در درخواست بعدی متوجه آن شوید.

Ollama از بارگذاری مدل خودداری می‌کند. درخواست به‌جای کرش کردن، بلافاصله با خطا مواجه می‌شود و لاگ سرور عبارت model is too large for system memory را ثبت می‌کند (Ollama 0.40.7، بررسی‌شده در 21 اکتبر 2026). نسخه‌های قدیمی‌تر در همان لحظه درخواست، عبارت Error: model requires more system memory (X GiB) than is available (Y GiB) را چاپ می‌کردند. این نسخه مؤدبانه‌ترِ کرش بالاست: Ollama محاسبات را انجام داده و به‌جای اجازه دادن به OOM killer برای متوقف کردن آن، خودش متوقف شده است. مدلی را انتخاب کنید که نیاز آن کمتر از RAM آزاد شما باشد (با free -h بررسی کنید)، طول context را کاهش دهید، یا به یک VPS بزرگ‌تر مهاجرت کنید. هیچ فلگی باعث نمی‌شود مدل در حافظه جا شود، محدودیت حافظه واقعی است.

اولین توکن زمان زیادی می‌برد، سپس همه چیز عادی است. یک مدل سرد برای پنج تا سی ثانیه هیچ چیزی چاپ نمی‌کند و سپس به‌طور عادی شروع به استریم می‌کند. این وقفه به دلیل بارگذاری وزن‌ها از دیسک به RAM برای اولین بار است و ذخیره‌سازی کند، وضعیت را بدتر می‌کند. پس از بارگذاری، مدل به مدت OLLAMA_KEEP_ALIVE در حافظه باقی می‌ماند، بنابراین پاسخ به درخواست دوم آنی خواهد بود. اگر آن بارگذاری اولیه از زمان timeout در مسیر فراخوانی فراتر رود، به‌جای پاسخ کند، خطا دریافت می‌کنید و بررسی اینکه کدام لایه خطای context deadline exceeded را گزارش کرده است به شما می‌گوید که آیا کلاینت، پروکسی یا خودِ بارگذاری دچار کمبود صبر شده‌اند. اگر این وقفه‌ها شما را آزار می‌دهد، آن مقدار را افزایش دهید و از ollama ps استفاده کنید تا ببینید آیا مدل در حال حاضر بارگذاری شده است یا خیر.

همه چیز به‌سادگی کند است. ده توکن در ثانیه یا کمتر، بدون هیچ خطایی. این همان کاری است که استنتاج (inference) روی CPU انجام می‌دهد. ollama ps عبارت 100% CPU را نشان می‌دهد، به این معنی که GPU وجود ندارد. این یک باگ نیست و هیچ تنظیمی CPU را به GPU تبدیل نمی‌کند، زیرا محدودیت اصلی، پهنای باند حافظه است. با این حال، یک تنظیم ارزش تست کردن روی VM را دارد: Ollama تعداد تردها را بر اساس هسته‌های فیزیکی که تشخیص می‌دهد انتخاب می‌کند و یک هایپروایزر ممکن است آن‌ها را اشتباه گزارش کند. در یک نشست ollama run --verbose، مقدار /set parameter num_thread 4 (یا تعداد vCPU خود) را امتحان کنید، همان پرامپت را دوباره اجرا کنید و هر مقداری که بهترین eval rate را می‌دهد، حفظ کنید. فراتر از آن، از یک مدل کوچک‌تر استفاده کنید، سرعت را بپذیرید یا به یک نمونه GPU منتقل شوید و قبل از اینکه نتیجه بگیرید چیزی خراب است، نرخ واقعی خود را با --verbose اندازه‌گیری کنید. وقتی انتظار به دلیل طولانی بودن پاسخ است و نه نرخ تولید، محدود کردن پاسخ با num_predict باعث می‌شود مدلی که تمایل به پرحرفی دارد، دقایق زیادی را صرف توکن‌هایی نکند که قرار نیست آن‌ها را بخوانید.

اتصال از دستگاه دیگر رد می‌شود (Connection refused). از لپ‌تاپ شما، یک دستور curl فعلی (8.23.0، بررسی‌شده در 21 اکتبر 2026) عبارت curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server را چاپ می‌کند و curl نسخه 8.5.0 که در Ubuntu 24.04 موجود است، عبارت curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server را چاپ می‌کند. عبارت "Connection refused" تنها در صورتی نمایش داده می‌شود که -v را اضافه کنید، در خطی که connect to <ip> port 11434 from ... failed: Connection refused را می‌خواند. این رفتار طبق طراحی است: Ollama فقط روی localhost گوش می‌دهد. آن را با bind کردن روی 0.0.0.0 «اصلاح» نکنید، که دقیقاً همان اشتباهِ در معرض قرار دادن (exposure) است که در بالا ذکر شد. از طریق VPN یا پروکسی احراز هویت‌شده به مدل دسترسی پیدا کنید.

شما پورت 11434 را در معرض اینترنت قرار دادید. اگر OLLAMA_HOST=0.0.0.0 را تنظیم کرده‌اید، فایروال را باز کرده‌اید و اکنون شاهد pull شدن مدل‌هایی هستید که خودتان شروع نکرده‌اید یا CPU توسط کلاینت‌های ناشناس 100% اشغال شده است، یعنی شما پیدا شده‌اید و مورد سوءاستفاده قرار گرفته‌اید. این یک اشتباه بزرگ و اصلی است، نه یک مورد خاص. دوباره روی 127.0.0.1 یا آدرس VPN تنظیم کنید، پورت 11434 را در فایروال ببندید و یک احراز هویت در مقابل آن قرار دهید. فرض کنید هر چیزی که در آن آدرس در زمان باز بودن قابل دسترسی بوده، توسط غریبه‌ها کوئری شده است.

پشتیبان‌گیری و ارتقا

داده‌های حساس کمی برای از دست دادن وجود دارد. مدل‌ها قابل دانلود مجدد هستند، بنابراین تنها مواردی که ارزش پشتیبان‌گیری دارند عبارتند از volume داده‌های Open WebUI، حساب‌های کاربری، تاریخچه گفتگوها، تنظیمات و هر فایل drop-in مربوط به systemd که ایجاد کرده‌اید. برای پشتیبان‌گیری از volume، از یک container موقت استفاده کنید:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

برای ارتقای Ollama، اسکریپت نصب را دوباره اجرا کنید؛ برای ارتقای Open WebUI از docker pull ghcr.io/open-webui/open-webui:main استفاده کرده و سپس container را دوباره ایجاد کنید. یک نکته در مورد دیسک برای سری 0.40: نسخه Ollama 0.40.2 شروع به ارتقای مدل‌هایی کرد که با نسخه‌های قبلی دانلود شده بودند؛ این کار در پس‌زمینه انجام می‌شود و نسخه‌های اصلی را به عنوان پشتیبان نگه می‌دارد، بنابراین تا زمانی که حذف نشوند، فضای دیسک بیشتری اشغال می‌کنند. نسخه 0.40.3 (11 اکتبر 2026) این ارتقای پس‌زمینه را متوقف کرد. پس از ارتقا، df -h را بررسی کنید و یادداشت‌های انتشار (release notes) را برای یافتن دستوری که این پشتیبان‌ها را حذف می‌کند، مطالعه کنید. هیچ موردی را برای طولانی‌مدت ثابت (Pin) نکنید: هم کیفیت مدل‌ها و هم runtime به‌سرعت تغییر می‌کنند، بنابراین به‌جای اعتماد به اعداد سه‌ماهه قبل، یادداشت‌های انتشار را بخوانید و بنچمارک را روی سیستم خودتان انجام دهید.

FAQ

آیا واقعاً می‌توانم یک LLM را روی یک VPS بدون GPU اجرا کنم؟

بله، با محدودیت‌هایی. مدل‌های کوچک کوانتایز شده در محدوده 3B تا 8B روی CPU اجرا می‌شوند و برای پیش‌نویس، خلاصه‌سازی و دسته‌بندی واقعاً مفید هستند، هرچند سرعت آن‌ها پایین است و در یک vCPU اشتراکی، نرخ تولید توکن در حد تک‌رقمی یا دو‌رقمی پایین خواهد بود. هر مدلی از 13B به بالا یا به‌شدت کند است یا اصلاً در RAM جا نمی‌شود. برای سرعت واقعی یا مدل‌های بزرگ‌تر، به یک instance دارای GPU نیاز دارید.

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

یک قاعده کلی برای مدل‌های 4-bit (Q4) که محبوب‌ترین مدل‌ها به‌صورت پیش‌فرض از آن استفاده می‌کنند: حدود 0.5 گیگابایت RAM به ازای هر میلیارد پارامتر برای وزن‌ها، به‌علاوه حدود 1 گیگابایت برای سربار (overhead) و کمی بیشتر برای context. بنابراین یک مدل 3B به حدود 4 گیگابایت فضای آزاد، یک مدل 7-8B به حدود 8 گیگابایت و یک مدل 14B به حدود 16 گیگابایت نیاز دارد. فضای خالی خود را با free -h بررسی کنید و برای سیستم‌عامل و سایر برنامه‌های موجود در سرور، فضای کافی باقی بگذارید.

آیا API مربوط به Ollama احراز هویت دارد؟

خیر. Ollama هیچ‌گونه احراز هویت داخلی، API key یا محدودیت نرخ (rate limit) ندارد؛ هر کسی که به پورت 11434 دسترسی داشته باشد، کنترل کامل آن را در اختیار خواهد داشت. تنظیم OLLAMA_ORIGINS در آن فقط محدود می‌کند که کدام مبدأهای مرورگر (browser origins) می‌توانند آن را فراخوانی کنند، نه اینکه چه کسی می‌تواند متصل شود. دقیقاً به همین دلیل است که به‌صورت پیش‌فرض روی 127.0.0.1 گوش می‌دهد و نباید هرگز پورت 11434 را روی 0.0.0.0 در معرض اینترنت قرار دهید. از طریق شبکه محلی، یک VPN خصوصی یا یک reverse proxy که لایه ورود به سیستم اضافه می‌کند، به آن دسترسی پیدا کنید.

چگونه یک رابط کاربری چت وب اضافه کنم؟

برنامه Open WebUI را در Docker با --network=host اجرا کنید تا از loopback میزبان استفاده کند و به Ollama در http://127.0.0.1:11434 دسترسی داشته باشد، سپس یک reverse proxy با TLS روی پورت 8080 آن قرار دهید تا از لپ‌تاپ خود به آن دسترسی داشته باشید. پورت 8080 را در فایروال بسته نگه دارید تا proxy تنها درگاه عمومی باشد. حساب کاربری مدیریت Open WebUI، امکان ورود را فراهم می‌کند و رمز عبور آن را در اولین اجرا تنظیم می‌کنید.

چگونه آن را از برنامه خودم فراخوانی کنم؟

از endpoint سازگار با OpenAI در http://127.0.0.1:11434/v1 استفاده کنید. هر SDK مربوط به OpenAI را به آن base URL اشاره دهید، هر رشته‌ای را به‌عنوان API key ارسال کنید (چون نادیده گرفته می‌شود) و model را روی نام مدلی که pull کرده‌اید تنظیم کنید. کدهای موجود OpenAI معمولاً بدون تغییر، به‌جز تغییر base URL و key، کار می‌کنند.