نصب و میزبانی Ollama روی VPS

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

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

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

بررسی واقع‌بینانه اندازه مدل، با اعداد ساده

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

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

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

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

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

Install Ollama

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

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

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

systemctl status ollama
ollama --version

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

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

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

Pull and run your first model

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

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

مشاهده کنید چه چیزی بارگذاری شده و چگونه جای می‌گیرد:

ollama ps

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

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

خط eval rate که در انتها چاپ می‌شود، میزان tokens per second شما روی این سخت‌افزار است. این همان عددی است که باید برای برنامه‌ریزی بر اساس آن استفاده کنید.

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

مدل‌هایی که توسط اسکریپت نصب شده و به عنوان سرویس اجرا می‌شوند، در home directory کاربر 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> حذف کنید.

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

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

sudo systemctl edit ollama.service

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

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

sudo systemctl restart ollama

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

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

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

بنابراین، این تنها اشتباهی است که هرگز نباید انجام دهید: OLLAMA_HOST=0.0.0.0 را تنظیم نکنید و پورت 11434 را در فایروال خود باز نگذارید. این کار یک سرور استنتاج بدون احراز هویت را در کل اینترنت منتشر می‌کند. هیچ میزان از پیکربندی نمی‌تواند حالت خام 11434-on-0.0.0.0 را امن کند، زیرا هیچ چیزی در Ollama برای پیکربندی وجود ندارد — قابلیت احراز هویت اصلاً وجود ندارد.

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

• آن را محلی نگه دارید. اگر تنها فراخواننده، برنامه دیگری در همان VPS باشد — مانند یک اسکریپت cron، یک bot، یا یک سرور 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)، و فقط همتایان (peers) VPN اجازه اتصال دارند. اینترنت عمومی همچنان هیچ چیزی در پورت 11434 نمی‌بیند.
• یک Reverse Proxy با قابلیت احراز هویت در جلوی آن قرار دهید. اتصال TLS را در nginx، Traefik یا Caddy برقرار کرده و نیاز به رمز عبور یا توکن ایجاد کنید، سپس درخواست‌ها را به 127.0.0.1:11434 پروکسی کنید. Ollama اتصال localhost خود را حفظ می‌کند؛ پروکسی تنها چیزی است که روی پورت عمومی گوش می‌دهد. این دقیقاً مشابه قرار دادن گواهینامه Let's Encrypt روی nginx در جلوی هر سرویس محلی است.

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

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

Open WebUI یک رابط کاربری چت است که به صورت self-hosted اجرا می‌شود. آن را در 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 جزئیات مهم در یک Linux VPS است. این فلگ کانتینر را در network namespace میزبان قرار می‌دهد؛ بنابراین 127.0.0.1 در داخل کانتینر، همان loopback خودِ میزبان است و کانتینر می‌تواند بدون نیاز به گوش دادن Ollama روی سایر رابط‌ها، از طریق 127.0.0.1:11434 به آن متصل شود. روش استفاده از bridge-network که در منابع دیگر می‌بینید — یعنی --add-host=host.docker.internal:host-gateway با OLLAMA_BASE_URL=http://host.docker.internal:11434 — در اینجا کار نمی‌کند: آن نام به gateway پل Docker اشاره دارد و سرویسی که به 127.0.0.1 در میزبان محدود شده باشد، از طریق پل قابل دسترسی نیست؛ بنابراین Open WebUI فقط متوقف شده و خطای عدم اتصال به Ollama را گزارش می‌دهد.

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

برای باز کردن چت از لپ‌تاپ خود از طریق HTTPS، یک TLS reverse proxy جلوی 127.0.0.1:8080 قرار دهید. اگر قبلاً چندین اپلیکیشن Docker را روی سیستم مسیریابی کرده‌اید، استفاده از Traefik با TLS خودکار برای اپلیکیشن‌های متعدد بهترین گزینه است: یک بلوک label، گواهینامه را صادر کرده و chat.example.com را به Open WebUI مسیریابی می‌کند. قوانین بخش امنیت همچنان پابقا هستند — پروکسی مالک پورت عمومی و ورود به سیستم است، در حالی که Ollama روی localhost باقی می‌ماند و 8080 مخصوص Open WebUI در پشت فایروال می‌ماند.

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

Ollama زیرمجموعه‌ای از chat 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 و editor استفاده می‌شود. اگر از قبل روی این سیستم توسعه می‌دهید، یک مدل محلی می‌تواند در کنار 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) مشاهده خواهید کرد. راه حل، استفاده از مدلی کوچک‌تر یا با کوانتایزیشن شدیدتر است — یعنی استفاده از llama3.2:3b به جای 13B — یا اضافه کردن swap تا بار پردازشی که فقط کمی از RAM فیزیکی فراتر می‌رود، به جای توقف، به آرامی ادامه یابد. swap یک کرش آنی را به یک پاسخ کند تبدیل می‌کند؛ اما یک مدل 70B را روی 4 GB عملیاتی نمی‌کند.

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

اولین توکن بسیار طول می‌کشد، اما سپس همه چیز عادی است. یک مدل سرد (cold model) به مدت 5 تا 30 ثانیه هیچ چیزی چاپ نمی‌کند و سپس به صورت عادی استریم می‌شود. آن وقفه، زمان بارگذاری وزن‌ها از دیسک در RAM برای اولین بار است و حافظه ذخیره‌سازی کند، این وضعیت را بدتر می‌کند. پس از بارگذاری، مدل برای مدت OLLAMA_KEEP_ALIVE در حافظه باقی می‌ماند، بنابراین درخواست دوم بلافاصله پاسخ داده می‌شود. اگر این وقفه‌ها آزاردهنده هستند، آن مقدار را افزایش دهید و از ollama ps استفاده کنید تا ببینید آیا مدلی در حال حاضر بارگذاری شده است یا خیر.

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

Connection refused from another machine. از لپ‌تاپ خود با خطای curl: (7) Failed to connect to <ip> port 11434: Connection refused مواجه می‌شوید. این رفتار طبق طراحی است: Ollama فقط روی localhost bind می‌شود. آن را با bind کردن به 0.0.0.0 "اصلاح" نکنید، زیرا این دقیقاً همان اشتباه امنیتی ذکر شده در بالا است. در عوض، از طریق VPN یا یک پروکسی احراز هویت‌شده به مدل دسترسی پیدا کنید.

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

Backups and upgrades

حجم داده‌های از دست رفته بسیار کم است. مدل‌ها قابل دانلود مجدد هستند، بنابراین تنها مواردی که ارزش پشتیبان‌گیری دارند عبارتند از: volume مربوط به داده‌های Open WebUI (شامل حساب‌های کاربری، تاریخچه چت‌ها و تنظیمات) و هر فایل systemd drop-in که خودتان نوشته‌اید. برای پشتیبان‌گیری از 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) نکنید: کیفیت مدل‌ها و زمان اجرای آن‌ها به سرعت تغییر می‌کند، بنابراین به جای اعتماد به اعداد مربوط به فصل گذشته، یادداشت‌های انتشار (release notes) را بخوانید و دوباره روی سیستم خودتان تست (benchmark) انجام دهید.

FAQ

آیا واقعاً می‌توانم یک LLM را روی یک VPS فقط با CPU اجرا کنم؟

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

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

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

آیا Ollama API دارای احراز هویت است؟

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

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

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

چگونه از طریق اپلیکیشن خودم آن را فراخوانی کنم؟

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