VPS-এ Ollama হোস্ট করার সঠিক নিয়ম

আপনি যা তৈরি করছেন

আপনার নিজস্ব সার্ভারে চলা একটি single open-weight language model, যা HTTP API এবং চাইলে আপনার ব্রাউজারে একটি chat page-এর মাধ্যমে ব্যবহার করা যাবে। Ollama হলো সেই অংশ যা model ডাউনলোড করে, memory-তে load করে এবং http://127.0.0.1:11434-এ request serve করে। এর installation মাত্র একটি command-এর কাজ। এর কঠিন বিষয়গুলো অন্য জায়গায় রয়েছে: আপনার VPS-এর RAM-এ জায়গা হবে এমন একটি model নির্বাচন করা, এবং ভুলবশত পুরো internet-এর জন্য একটি unauthenticated inference server উন্মুক্ত করে না দেওয়া।

শুরুতেই দুটি সততাভরা সতর্কতা। একটি CPU-only VPS ছোট model গুলো খুব ধীরগতিতে চালায়, এবং API-তে কোনো built-in authentication নেই। নিচে এই দুটি বিষয় বিস্তারিতভাবে আলোচনা করা হয়েছে, কারণ এই দুটি জায়গাতেই মানুষ ভুল করে।

সহজ সংখ্যা দিয়ে সাইজিং যাচাই করা

একটি মডেলের মেমরি ফুটপ্রিন্ট হলো মূলত এর ফাইল সাইজ, সাথে রানটাইম ওভারহেড হিসেবে প্রায় ১ GB, এবং কনটেক্সট উইন্ডোর জন্য আরও কিছু অতিরিক্ত মেমরি। Ollama-এর ডিফল্ট মডেলগুলো 4-bit quantized (Q4 হিসেবে চিহ্নিত) হিসেবে থাকে, যার ফলে প্রতি এক বিলিয়ন প্যারামিটারের জন্য প্রায় আধা গিগাবাইট RAM প্রয়োজন হয়। তাই হিসাবটি খুব সহজ এবং এটিই সবকিছু নির্ধারণ করে।

llama3.2:3b এর মতো একটি 3B মডেল ডাউনলোড করতে প্রায় 2 GB লাগে এবং এটি চালানোর জন্য প্রায় 4 GB ফ্রি RAM প্রয়োজন। mistral:7b বা llama3.1:8b এর মতো 7B বা 8B মডেল ডিস্কে প্রায় 5 GB জায়গা নেয় এবং এটি চালানোর জন্য প্রায় 8 GB RAM প্রয়োজন, তবে স্বাচ্ছন্দ্যে ব্যবহারের জন্য 16 GB প্রয়োজন। 13B বা 14B মডেলের জন্যRoughly 16 GB প্রয়োজন। 30B থেকে 70B রেঞ্জের যেকোনো মডেলের জন্য বড় RAM সম্পন্ন সিস্টেম অথবা বাস্তবিকভাবে একটি GPU প্রয়োজন — একটি CPU VPS-এ এটি হয় মেমরিতে ধরবে না অথবা এত ধীরগতিতে উত্তর দেবে যে সেটি অকেজো হয়ে পড়বে।

এবার গতি নিয়ে আলোচনা করা যাক, কারণ মানুষ এই বিষয়টি অবমূল্যায়ন করে। CPU inference মেমরি ব্যান্ডউইথের ওপর নির্ভর করে, ক্লক স্পিডের ওপর নয়; আর একটি shared vCPU VPS-এর ব্যান্ডউইথ সীমিত। প্রতি সেকেন্ডে এক অঙ্কের বা দুই অঙ্কের কম টোকেন আশা করতে পারেন: একটি 7-8B Q4 মডেল প্রতি সেকেন্ডে 4 থেকে 10টি টোকেন দিতে পারে, আর একটি 3B মডেল 10 থেকে 25টি টোকেন দিতে পারে। একটি GPU প্রায় দশ গুণ বেশি দ্রুত। এই সংখ্যাগুলো ইচ্ছাকৃতভাবে আনুমানিক রাখা হয়েছে — সঠিক পদ্ধতি হলো আপনার নিজের সিস্টেম পরিমাপ করা, যা নিচের run ধাপটিতে দেখানো হয়েছে। কোনো নিবন্ধের সংখ্যার ওপর নয়, বরং আপনার eval rate-এর ওপর ভরসা রাখুন।

বাস্তব সিদ্ধান্ত: আপনি যদি গতি মেনে নিতে পারেন, তবে CPU-তে ছোট quantized মডেলগুলো ড্রাফটিং, সামারি করা এবং ক্লাসিফিকেশনের জন্য সত্যিই উপযোগী। এর চেয়ে বড় বা দ্রুত কিছুর জন্য একটি GPU instance ব্যবহারের পরিকল্পনা করুন।

একটি নির্দিষ্ট মডেলকে একটি নির্দিষ্ট সিস্টেমের সাথে তুলনা করতে, এখানে এর মেমরি ফুটপ্রিন্ট অনুমান করুন:

Ollama Install করুন

দুটি সহজ পদ্ধতি আছে। একটি খালি VPS-এর জন্য অফিসিয়াল script সবচেয়ে সহজ:

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

এটি ollama নামে একটি system user তৈরি করে, /usr/local/bin/ollama-এ binary install করে এবং ollama.service নামে একটি systemd service রেজিস্টার করে। এই service-টি boot হওয়ার সময় চালু হয় এবং 127.0.0.1:11434-এর সাথে bind হয়। এটি সঠিকভাবে চলছে কিনা তা নিশ্চিত করতে নিচের কমান্ডটি ব্যবহার করুন:

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

Port mapping-এ 127.0.0.1: prefix-টির দিকে খেয়াল রাখুন। এটি port-টিকে শুধুমাত্র localhost-এর সাথে bind করে। যদি আপনি -p 11434:11434 ব্যবহার করেন, তবে এটি প্রতিটি interface-এ publish হয়ে যাবে; security section-এ এই ভুলটি সম্পর্কে সতর্ক করা হয়েছে। যেকোনো একটি installation পদ্ধতি বেছে নিন; script এবং container একসাথে চালাবেন না, অন্যথায় দুটি process একই port নিয়ে সংঘর্ষ (conflict) তৈরি করবে।

আপনার প্রথম model pull এবং run করুন

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

pull model layer গুলো disk-এ download করে (এইটির জন্য প্রায় 2 GB লাগবে)। run এগুলো memory-তে load করে এবং আপনাকে একটি >>> prompt প্রদান করে। একটি প্রশ্ন টাইপ করুন। Disk থেকে RAM-এ weights load হওয়ার সময় প্রথম token পেতে কয়েক সেকেন্ড সময় লাগতে পারে, এরপর উত্তরটি stream হবে। চ্যাট থেকে বের হতে /bye টাইপ করুন; Ollama background-এ চলতে থাকবে।

কী load হয়েছে এবং এটি কীভাবে fit হচ্ছে তা দেখুন:

ollama ps

PROCESSOR columnটি সঠিক তথ্য প্রদান করে। 100% CPU মানে কোনো GPU ব্যবহার করা হচ্ছে না, এবং এই কারণেই গতি ধীর হয়ে যায়। verbose flag ব্যবহার করে প্রকৃত গতি পরিমাপ করুন:

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

শেষে প্রিন্ট হওয়া eval rate লাইনটি হলো এই hardware-এ আপনার tokens per second। পরিকল্পনার জন্য এই সংখ্যাটি অনুসরণ করুন।

মডেলগুলো কোথায় থাকে এবং কতটুকু ডিস্ক কিনতে হবে

স্ক্রিপ্ট দ্বারা ইনস্টল করা এবং service হিসেবে চলা মডেলগুলো ollama ইউজারের home ডিরেক্টরিতে থাকে:

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

আপনার নিজস্ব ইউজার হিসেবে interactively চালালে, এগুলো ~/.ollama/models-এ থাকে। কন্টেইনারের ক্ষেত্রে এগুলো ollama named volume-এ থাকে। এটি গুরুত্বপূর্ণ কারণ quantized weights খুব দ্রুত জায়গা দখল করে: একটি 3B মডেলের সাইজ ~2 GB, একটি 7-8B মডেলের সাইজ ~5 GB, এবং একটি 14B মডেলের সাইজ ~9 GB। তুলনা করার জন্য চারটি মডেল ডাউনলোড করলে আপনি অজান্তেই 20 GB জায়গা ব্যবহার করে ফেলবেন। আপনি যে মডেলগুলো রাখতে চান সেই অনুযায়ী ডিস্কের সাইজ নির্ধারণ করুন, এবং বাকিগুলো ollama rm <model> দিয়ে ডিলিট করে দিন।

আপনার নিয়ন্ত্রিত একটি service হিসেবে এটি চালান

install script ইতিমধ্যে ollama.service রেজিস্টার করেছে, তাই কোনো অতিরিক্ত কাজ ছাড়াই এটি boot হওয়ার সময় নিজে থেকেই restart হবে। পরিবর্তন করার মতো গুরুত্বপূর্ণ setting হলো একটি model কতক্ষণ memory-তে থাকবে এবং কিছু setup-এর ক্ষেত্রে bind address — এই দুটি বিষয় একটি systemd drop-in ফাইলে রাখতে হয় যাতে Ollama upgrade করার সময় এগুলো মুছে না যায়:

sudo systemctl edit ollama.service

editor-এ দেখানো [Service] header-এর নিচে এটি যোগ করুন:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE হলো শেষ request-এর পর একটি model কতক্ষণ memory-তে থাকবে (default 5 minutes)। যদি আপনি সারাদিন একটি box-এ query করেন, তবে প্রতিবার weights reload হওয়া এড়াতে এই সময়টি বাড়িয়ে দিন; আর যদি RAM সীমিত থাকে, তবে request শেষ হওয়ার সাথে সাথে RAM খালি করতে এটি 0 হিসেবে সেট করুন। systemctl edit আপনার জন্য unit files গুলো reload করে দেয়, তাই পরিবর্তনটি কার্যকর করতে restart করুন:

sudo systemctl restart ollama

সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা পয়েন্ট

ডিফল্টভাবে Ollama 127.0.0.1:11434-এ bind থাকে, তাই শুধুমাত্র VPS-এর ভেতরের প্রসেসগুলো এটি ব্যবহার করতে পারে। এই ডিফল্ট সেটিংসটি সঠিক। এটি পরিবর্তন করবেন না।

API-তে কোনো authentication নেই। একদমই নেই। এখানে কোনো API key, login, rate limit বা allow-list নেই। যে কেউ যদি port 11434-এ পৌঁছাতে পারে, তবে সে আপনার ডাউনলোড করা যেকোনো model চালাতে পারবে, নতুন model ডাউনলোড করতে পারবে, সেগুলো ডিলিট করতে পারবে এবং আপনার CPU বা GPU-কে অনির্দিষ্টকালের জন্য full load-এ রাখতে পারবে। Shodan-এর মতো scanners হাজার হাজার খোলা Ollama instance ইনডেক্স করে ফেলে; একটি exposed instance কয়েক ঘণ্টার মধ্যেই খুঁজে পাওয়া যায় এবং অপব্যবহার করা হয়।

তাই একটি ভুল যা কখনোই করা উচিত নয়: OLLAMA_HOST=0.0.0.0 সেট করবেন না এবং আপনার firewall-এ 11443 পোর্টটি ওপেন করবেন না। এটি পুরো ইন্টারনেটে একটি unauthenticated inference server প্রকাশ করে দেয়। কোনো কনফিগারেশন দিয়েই 0.0.0.0-এ raw 11434 পোর্টটি নিরাপদ করা সম্ভব নয়, কারণ Ollama-তে কনফিগার করার মতো কোনো বিষয় নেই — এখানে authentication-এর ব্যবস্থা নেই।

সার্ভার বা বক্সের বাইরে থেকে মডেলটি ব্যবহার করার তিনটি নিরাপদ উপায় রয়েছে:

• লোকাল হিসেবে রাখুন। যদি একমাত্র কলিং প্রসেসটি একই VPS-এর অন্য কোনো প্রোগ্রাম হয় — যেমন কোনো cron script, bot, অথবা আপনার tools এবং model-এর মধ্যে সংযোগকারী একটি MCP server — তবে bind সেটিংসটি 127.0.0.1-এ রাখুন এবং সেই প্রোগ্রামটি দিয়ে http://127.0.0.1:11434 কল করুন। এতে কোনো কিছু expose হয় না এবং অন্য কিছুর প্রয়োজন নেই।
• একটি private tunnel-এর মাধ্যমে ব্যবহার করুন। VPS-টিকে আপনার নিজস্ব হোস্ট করা WireGuard VPN-এ যুক্ত করুন, OLLAMA_HOST সেটিংসটি tunnel address-এ সেট করুন (উদাহরণস্বরূপ 10.8.0.1, 0.0.0.0 নয়), এবং শুধুমাত্র VPN peers-দের কানেক্ট করতে দিন। পাবলিক ইন্টারনেটে 11434 পোর্টে কিছুই দেখা যাবে না।
• সামনে একটি authenticating reverse proxy ব্যবহার করুন। nginx, Traefik, অথবা Caddy ব্যবহার করে TLS terminate করুন এবং password বা token ব্যবহার বাধ্যতামূলক করুন, তারপর সেটি 127.0.0.1:11434-এ proxy করুন। Ollama তার localhost bind বজায় রাখবে; শুধুমাত্র proxy-টি পাবলিক পোর্টে শুনবে। এটি যেকোনো লোকাল সার্ভিসের সামনে nginx-এ Let's Encrypt certificate ব্যবহার করার মতোই।

পরবর্তী ধাপে চ্যাট UI-তে আপনি ঠিক এই reverse-proxy অপশনটিই পাবেন, যেখানে একটি আসল login সিস্টেম যুক্ত থাকবে।

TLS এর মাধ্যমে Open WebUI ব্যবহার করে একটি chat UI যোগ করুন

Open WebUI হলো একটি self-hosted chat interface। এটি 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

Linux VPS-এর ক্ষেত্রে --network=host flag-টি অত্যন্ত গুরুত্বপূর্ণ। এটি container-টিকে host-এর network namespace-এ স্থাপন করে। এর ফলে container-এর ভেতরে 127.0.0.1 হলো host-এর নিজস্ব loopback, এবং Ollama অন্য কোনো interface-এ listen না করলেও container সরাসরি 127.0.0.1:11434-এ Ollama-এর সাথে যোগাযোগ করতে পারে। অন্যান্য জায়গায় আপনি যে bridge-network পদ্ধতিটি দেখবেন — --add-host=host.docker.internal:host-gateway সহ OLLAMA_BASE_URL=http://host.docker.internal:11434 — তা এখানে কাজ করবে না: এই নামটি Docker bridge gateway-কে নির্দেশ করে। host-এর 127.0.0.1-এ bind করা কোনো service bridge-এর মাধ্যমে পাওয়া যায় না, তাই Open WebUI Ollama-এর সাথে কানেক্ট করতে না পেরে error দেখাবে।

Host networking ব্যবহারের একটি অসুবিধা হলো, Open WebUI এখন প্রতিটি interface-এ host-এর 8080 port-এ listen করবে; যেকোনো -p mapping বাতিল হয়ে যাবে এবং Docker একটি warning প্রিন্ট করবে। তাই host এবং provider firewall উভয় স্থানেই 8080 বন্ধ রাখুন এবং TLS reverse proxy-কে একমাত্র public door হিসেবে ব্যবহার করুন। প্রথমবার ব্যবহারের সময় Open WebUI আপনাকে একটি admin account তৈরি করতে বলবে — এই account-টিই আপনার authentication layer হিসেবে কাজ করবে, তাই একটি শক্তিশালী password নির্বাচন করুন।

আপনার laptop থেকে HTTPS-এর মাধ্যমে chat ওপেন করতে, 127.0.0.1:8080-এর সামনে একটি TLS reverse proxy ব্যবহার করুন। আপনি যদি ইতিমধ্যে ওই machine-এ একাধিক Docker app route করে থাকেন, তবে Traefik with automatic TLS across many apps সবচেয়ে সহজ সমাধান: একটি label block-এর মাধ্যমেই certificate ইস্যু করা যায় এবং chat.example.com-কে Open WebUI-তে route করা যায়। security section-এর নিয়মটি এখানেও প্রযোজ্য — proxy পাবলিক port এবং login নিয়ন্ত্রণ করবে, অন্যদিকে Ollama localhost-এ থাকবে এবং Open WebUI-এর নিজস্ব 8080 firewall-এর আড়ালে থাকবে।

আপনার কোড থেকে OpenAI-compatible endpoint ব্যবহার করুন

Ollama, /v1 পাথে OpenAI chat API-এর একটি subset ব্যবহার করে। তাই base URL এবং একটি যেকোনো key পরিবর্তন করে আপনি বেশিরভাগ OpenAI client library ব্যবহার করতে পারবেন।

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)

Client library-এর জন্য api_key প্রয়োজন, কিন্তু Ollama এটি উপেক্ষা করে; তাই যেকোনো string ব্যবহার করা যাবে। model অবশ্যই আপনার আগে থেকে pull করা একটি নাম হতে হবে; অজানা নাম দিলে model "x" not found, try pulling it first এরর আসবে। সাধারণ curl call-এর ক্ষেত্রেও একই নিয়ম প্রযোজ্য:

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 tooling-এ model কানেক্ট করার জন্য এই পদ্ধতিটিই ব্যবহৃত হয়। আপনি যদি ইতিমধ্যে ওই machine-এ ডেভেলপমেন্ট করেন, তবে একটি local model আপনার script এবং plugin-এর ব্যাকআপ হিসেবে কাজ করতে পারে। tmux-এর ভেতরে VPS-এ running Claude Code এর পাশাপাশি এটি ব্যবহার করা সম্ভব। এতে ভারী reasoning কাজের জন্য hosted model ব্যবহার করা গেলেও, সাধারণ ড্রাফটিংয়ের কাজগুলো একটি paid API ছাড়াই সাশ্রয়ী ও প্রাইভেটভাবে করা সম্ভব।

Failure modes, with the exact strings you will see

প্রক্রিয়াটি জেনারেশনের মাঝখানে "Killed" হয়ে যাচ্ছে। আপনি একটি বড় মডেল শুরু করেছেন এবং টার্মিনাল Killed প্রিন্ট করছে, অথবা সার্ভার লগ llama runner process has terminated: signal: killed দেখাচ্ছে। Linux OOM killer এটি বন্ধ করে দিয়েছে কারণ মডেলটির RAM প্রয়োজন আপনার মেশিনের উপলব্ধ RAM এর চেয়ে বেশি। sudo dmesg | grep -i oom দিয়ে কারণটি নিশ্চিত করুন, সেখানে আপনি Out of memory: Killed process ... (ollama) এর মতো একটি লাইন দেখতে পাবেন। সমাধান হলো একটি ছোট বা বেশি heavily quantized মডেল ব্যবহার করা — 13B এর পরিবর্তে llama3.2:3b — অথবা swap যোগ করা, যাতে ফিজিক্যাল RAM এর সামান্য বেশি লোডটি দ্রুত ক্রাশ না হয়ে ধীরগতিতে সম্পন্ন হয়। Swap একটি তাৎক্ষণিক ক্রাশকে ধীরগতির উত্তরের মধ্যে রূপান্তরিত করে; এটি 4 GB মেমরিতে 70B মডেল চালানো সম্ভব করে না।

"Error: model requires more system memory"। Ollama মডেলটি শুরু করতে অস্বীকার করছে এবং Error: model requires more system memory (X GiB) than is available (Y GiB) প্রিন্ট করছে। এটি উপরের ক্রাশের একটি মার্জিত সংস্করণ: Ollama হিসাব করে দেখেছে এবং OOM killer এর হাতে বিষয়টি না দিয়ে নিজেই থেমে গেছে। এটি আপনাকে দুটি সংখ্যাও প্রদান করে। এমন একটি মডেল বেছে নিন যার মেমরি প্রয়োজন আপনার free RAM এর চেয়ে কম (free -h দিয়ে চেক করুন), context length কমিয়ে দিন, অথবা একটি বড় VPS এ চলে যান। কোনো flag দিয়ে মডেলটিকে মেমরির মধ্যে ফিট করা সম্ভব নয় — মেমরি সীমাবদ্ধতা বাস্তব।

প্রথম token পেতে অনেক সময় লাগে, তারপর সব ঠিক হয়ে যায়। একটি cold model পাঁচ থেকে ত্রিশ সেকেন্ডের জন্য কিছু প্রিন্ট করে না, তারপর স্বাভাবিকভাবে stream করে। এই বিরতিটি হলো প্রথমবারের মতো disk থেকে RAM এ weights লোড হওয়ার সময়, এবং slow storage এই সমস্যাটি আরও বাড়িয়ে দেয়। একবার লোড হয়ে গেলে, মডেলটি OLLAMA_KEEP_ALIVE সময় পর্যন্ত মেমরিতে থাকে, তাই দ্বিতীয় প্রম্পটটি তাৎক্ষণিকভাবে উত্তর দেয়। এই বিরতি কমাতে আপনি ওই value বাড়িয়ে দিতে পারেন, এবং কোনো মডেল বর্তমানে লোড করা আছে কিনা তা দেখতে ollama ps ব্যবহার করুন।

সবকিছু খুব ধীরগতির। প্রতি সেকেন্ডে দশটি বা তার কম token, কোনো error ছাড়াই। এটি CPU inference এর স্বাভাবিক আচরণ। ollama ps দ্বারা 100% CPU বোঝা যায়, যার অর্থ কোনো GPU নেই। এটি কোনো bug নয় এবং কোনো setting দিয়ে এটি ঠিক করা সম্ভব নয়, কারণ সীমাবদ্ধতাটি memory bandwidth এর কারণে, কোনো misconfiguration এর কারণে নয়। একটি ছোট মডেল ব্যবহার করুন, এই গতি মেনে নিন, অথবা একটি GPU instance এ চলে যান — এবং কোনো কিছু নষ্ট হয়েছে কিনা তা সিদ্ধান্ত নেওয়ার আগে --verbose দিয়ে আপনার প্রকৃত রেট পরিমাপ করুন।

অন্য মেশিন থেকে Connection refused আসছে। আপনার ল্যাপটপ থেকে আপনি curl: (7) Failed to connect to <ip> port 11434: Connection refused পাচ্ছেন। এটি ডিজাইন অনুযায়ী কাজ করছে: Ollama শুধুমাত্র localhost এ bind হয়। 0.0.0.0 এ bind করে এটি "ঠিক" করার চেষ্টা করবেন না, কারণ এটি একটি নিরাপত্তা ঝুঁকি। এর পরিবর্তে VPN বা একটি authenticating proxy এর মাধ্যমে মডেলটি ব্যবহার করুন।

আপনি 11434 কে ইন্টারনেটে প্রকাশ করে ফেলেছেন। আপনি যদি OLLAMA_HOST=0.0.0.0 সেট করেন এবং firewall ওপেন করেন, এবং এখন দেখেন যে আপনি শুরু না করা মডেলগুলো pull হচ্ছে অথবা অজানা ক্লায়েন্টদের দ্বারা CPU 100% ব্যবহৃত হচ্ছে, তবে আপনার সিস্টেমটি শনাক্ত করা হয়েছে এবং ব্যবহার করা হচ্ছে। এটি একটি বড় ভুল, কোনো প্রান্তিক ঘটনা নয়। 127.0.0.1 বা VPN অ্যাড্রেসে rebind করুন, firewall এ 11434 বন্ধ করুন, এবং সামনে authentication যুক্ত করুন। যখন এই অ্যাড্রেসটি ওপেন ছিল, তখন অপরিচিতদের দ্বারা যেকোনো রিকোয়েস্ট করা হয়েছে বলে ধরে নিন।

Backups এবং upgrades

খুব সামান্য ডেটা হারানোর সম্ভাবনা থাকে। মডেলগুলো পুনরায় ডাউনলোড করা সম্ভব, তাই শুধুমাত্র Open WebUI-এর data volume — যেমন অ্যাকাউন্ট, চ্যাট হিস্ট্রি এবং সেটিংস — এবং আপনার তৈরি করা যেকোনো systemd drop-in ব্যাকআপ রাখা প্রয়োজন। একটি throwaway container ব্যবহার করে volume-টি ব্যাকআপ নিন:

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

install script পুনরায় রান করার মাধ্যমে Ollama upgrade করুন; Open WebUI upgrade করতে docker pull ghcr.io/open-webui/open-webui:main ব্যবহার করুন এবং এরপর container-টি পুনরায় তৈরি করুন। দীর্ঘমেয়াদী কোনো কিছু pin করে রাখবেন না: মডেলের গুণমান এবং runtime দ্রুত পরিবর্তিত হয়, তাই গত প্রান্তিকের তথ্যের ওপর নির্ভর না করে release notes পড়ুন এবং আপনার নিজস্ব সিস্টেমে পুনরায় benchmark করুন।

FAQ

আমি কি সত্যিই একটি CPU-only VPS-এ LLM চালাতে পারি?

হ্যাঁ, কিছু সীমাবদ্ধতার মধ্যে। 3B থেকে 8B রেঞ্জের ছোট quantized মডেলগুলো CPU-তে চলে এবং drafting, summarizing ও classification-এর জন্য অত্যন্ত উপযোগী — তবে shared vCPU-তে এগুলো ধীরগতিতে চলে (প্রতি সেকেন্ডে single-digit বা low-double-digit tokens)। 13B বা তার বেশি প্যারামিটারের মডেলগুলো অত্যন্ত ধীরগতির হয় অথবা RAM-এ জায়গা পায় না। দ্রুত গতি বা বড় মডেলের জন্য আপনার একটি GPU instance প্রয়োজন।

প্রতিটি মডেলের কতটুকু RAM প্রয়োজন?

ডিফল্ট 4-bit quantized মডেলের জন্য একটি সাধারণ নিয়ম হলো: প্রতি billion প্যারামিটারের জন্য প্রায় 0.5 GB RAM (weights-এর জন্য), সাথে প্রায় 1 GB overhead এবং context-এর জন্য আরও কিছুটা অতিরিক্ত জায়গা। তাই একটি 3B মডেলের জন্য প্রায় 4 GB free RAM প্রয়োজন, 7-8B মডেলের জন্য প্রায় 8 GB, এবং 14B মডেলের জন্য প্রায় 16 GB প্রয়োজন। free -h দিয়ে আপনার headroom পরীক্ষা করুন এবং operating system ও অন্যান্য কাজের জন্য পর্যাপ্ত জায়গা খালি রাখুন।

Ollama API কি authenticated?

না। Ollama-তে কোনো built-in authentication, API key বা rate limit নেই — যে কেউ যদি port 11434-এ পৌঁছাতে পারে, সে এর পূর্ণ নিয়ন্ত্রণ পাবে। এই কারণেই এটি ডিফল্টভাবে 127.0.0.1-এ bind হয় এবং আপনাকে অবশ্যই 11434 port-টি 0.0.0.0-এ ইন্টারনেটের জন্য উন্মুক্ত করা যাবে না। এটি শুধুমাত্র locally, একটি private VPN-এর মাধ্যমে, অথবা একটি reverse proxy-এর মাধ্যমে ব্যবহার করুন যা login সুবিধা প্রদান করে।

আমি কীভাবে একটি web chat interface যোগ করব?

Docker-এ --network=host সহ Open WebUI চালান যাতে এটি host-এর loopback শেয়ার করতে পারে এবং http://127.0.0.1:11434-এ native Ollama-তে পৌঁছাতে পারে। এরপর আপনার laptop থেকে অ্যাক্সেস করার জন্য এর port 8080-এর সামনে একটি TLS reverse proxy ব্যবহার করুন। Firewall-এ 8080 বন্ধ রাখুন যাতে proxy-টিই একমাত্র public door হিসেবে কাজ করে। Open WebUI-এর নিজস্ব admin account দিয়ে login করা যায় এবং প্রথমবার লঞ্চ করার সময় আপনি এর password সেট করতে পারবেন।

আমি কীভাবে আমার নিজস্ব application থেকে এটি কল করব?

http://127.0.0.1:11434/v1-এ থাকা OpenAI-compatible endpoint ব্যবহার করুন। যেকোনো OpenAI SDK-কে ওই base URL-এ পয়েন্ট করুন, API key হিসেবে যেকোনো string দিন (যেহেতু এটি ignore করা হয়), এবং model-এ আপনার ডাউনলোড করা মডেলটির নাম দিন। বিদ্যমান OpenAI কোড সাধারণত base URL এবং key পরিবর্তন করা ছাড়াই কাজ করে।