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

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

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

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

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

میزان مصرف حافظه یک مدل تقریباً برابر با حجم فایل آن، به‌علاوه حدود یک گیگابایت سربار زمان اجرا (runtime overhead) و مقداری فضای اضافه برای context window است. مدل‌های پیش‌فرض Ollama به‌صورت 4-bit کوانتیزه شده‌اند (با برچسب Q4) که به ازای هر یک میلیارد پارامتر، حدود نیم گیگابایت رم اشغال می‌کنند. بنابراین محاسبات ساده است و تعیین‌کننده همه چیز خواهد بود.

یک مدل 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 تقریباً یک مرتبه بزرگی سریع‌تر است. این ارقام به‌صورت عمدی تقریبی بیان شده‌اند؛ رویکرد صادقانه این است که سرور خود را بسنجید، که در مرحله اجرای زیر نحوه انجام آن نشان داده شده است. به eval rate خود اعتماد کنید، نه به عددی که در هر مقاله‌ای، از جمله همین مقاله، آمده است.

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

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

نصب 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 دقیقه است). اگر در طول روز مدام از سیستم پرس‌وجو می‌کنید، این مقدار را افزایش دهید تا از بارگذاری مجدد وزن‌ها در هر بار جلوگیری شود؛ در سیستمی با محدودیت منابع، آن را روی 0 تنظیم کنید تا بلافاصله پس از پایان درخواست، RAM آزاد شود. systemctl edit فایل‌های unit را برای شما بازخوانی می‌کند، بنابراین برای اعمال تغییرات، سرویس را ری‌استارت کنید:

sudo systemctl restart ollama

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

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

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

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

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

• آن را محلی نگه دارید. اگر تنها فراخواننده، برنامه دیگری روی همان VPS، یک اسکریپت cron، یک بات یا یک سرور MCP که ابزارهای شما را به مدل متصل می‌کند است، bind را روی 127.0.0.1 نگه دارید و آن برنامه را وادار کنید که http://127.0.0.1:11434 را فراخوانی کند. هیچ چیزی در معرض دید قرار نمی‌گیرد و به هیچ چیز دیگری نیاز نیست.
• از طریق یک تونل خصوصی به آن دسترسی پیدا کنید. VPS را روی یک شبکه WireGuard VPN که خودتان میزبانی می‌کنید قرار دهید، OLLAMA_HOST را روی آدرس تونل تنظیم کنید (برای مثال 10.8.0.1، نه 0.0.0.0) و فقط همتایان VPN می‌توانند متصل شوند. اینترنت عمومی همچنان هیچ چیزی روی پورت 11434 نمی‌بیند.
• یک reverse proxy با قابلیت احراز هویت در مقابل آن قرار دهید. TLS را در nginx، Traefik یا Caddy خاتمه دهید (terminate) و یک رمز عبور یا توکن درخواست کنید، سپس درخواست‌ها را به 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 متصل شود.

نکته منفی استفاده از شبکه میزبان (host networking) این است که 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 هدایت می‌کند. قانون بخش امنیتی همچنان پابرجاست؛ پروکسی مالک پورت عمومی و ورود به سیستم است، در حالی که 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 کرده‌اید؛ نام ناشناخته منجر به بازگشت model "x" not found, try pulling it first می‌شود. یک فراخوانی ساده با 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های پولی دور بمانند، در حالی که استدلال‌های سنگین همچنان توسط یک مدل میزبانی‌شده انجام می‌شود.

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

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

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

اولین token بسیار دیر تولید می‌شود، اما پس از آن عملکرد عادی است. یک مدل cold ممکن است به‌مدت 5 تا 30 ثانیه هیچ خروجی‌ای تولید نکند و سپس به‌طور عادی خروجی را به‌صورت جریانی ارسال کند. این مکث به بارگذاری weights از دیسک در RAM برای نخستین بار مربوط است و storage کند آن را طولانی‌تر می‌کند. پس از بارگذاری، مدل به‌مدت OLLAMA_KEEP_ALIVE در حافظه باقی می‌ماند؛ بنابراین prompt دوم بلافاصله پاسخ می‌گیرد. اگر نخستین بارگذاری از timeout در بخشی از مسیر فراخوانی طولانی‌تر شود، به‌جای پاسخی کند با error مواجه می‌شوید. بررسی این‌که کدام لایه خطای context deadline exceeded را گزارش کرده است مشخص می‌کند که client، proxy یا خود فرایند بارگذاری دیگر منتظر نمانده است. اگر این فاصله‌ها آزاردهنده‌اند، آن مقدار را افزایش دهید و برای بررسی بارگذاری فعلی یک model از ollama ps استفاده کنید.

همه چیز به‌سادگی کند است. ده توکن در ثانیه یا کمتر، بدون هیچ خطایی. این همان کاری است که inference روی CPU انجام می‌دهد. ollama ps مقدار 100% CPU را نشان می‌دهد که به معنای نبود GPU است. این یک باگ نیست و هیچ تنظیمی آن را اصلاح نمی‌کند، زیرا محدودیت اصلی، پهنای باند حافظه است، نه یک پیکربندی اشتباه. از مدل کوچک‌تری استفاده کنید، سرعت فعلی را بپذیرید، یا به یک instance دارای GPU مهاجرت کنید و پیش از آنکه نتیجه بگیرید چیزی خراب است، نرخ واقعی خود را با --verbose اندازه‌گیری کنید.

خطای Connection refused از یک ماشین دیگر. از لپ‌تاپ خود با curl: (7) Failed to connect to <ip> port 11434: 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 را دوباره ایجاد کنید. هیچ موردی را برای طولانی‌مدت ثابت (Pin) نکنید: کیفیت مدل‌ها و محیط اجرا (runtime) به‌سرعت تغییر می‌کنند، بنابراین یادداشت‌های انتشار (release notes) را مطالعه کرده و به‌جای اعتماد به اعداد و ارقام فصل گذشته، بنچمارک‌ها را روی سیستم خودتان انجام دهید.

FAQ

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

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

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

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

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

خیر. Ollama فاقد احراز هویت داخلی، کلید API یا محدودیت نرخ (rate limit) است؛ هر کسی که به پورت 11434 دسترسی داشته باشد، کنترل کامل آن را در اختیار خواهد داشت. دقیقاً به همین دلیل است که به‌صورت پیش‌فرض روی 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 ارسال کنید (چون نادیده گرفته می‌شود) و model را روی نام مدلی که دانلود کرده‌اید تنظیم کنید. کدهای موجود OpenAI معمولاً بدون تغییر، به‌جز در بخش base URL و کلید، اجرا می‌شوند.