VPS-এ Ollama host করে নিরাপদে LLM চালাবেন যেভাবে

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

আপনার মালিকানাধীন একটি সার্ভারে চলা একটি open-weight language model। এটি HTTP API-এর মাধ্যমে উত্তর দেবে এবং চাইলে আপনার browser-এ একটি chat page-ও চালানো যাবে। Ollama model download করে, সেটিকে memory-তে load করে এবং http://127.0.0.1:11434-এ request গ্রহণ করে। Installation একটি command-এই করা যায়। এই ব্যবস্থার কঠিন অংশ অন্যত্র: আপনার VPS-এর RAM-এ বাস্তবে ধরে এমন একটি model বেছে নেওয়া এবং অসাবধানতাবশত authentication-বিহীন inference server পুরো Internet-এ প্রকাশ না করা।

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

আকারের বাস্তবতা: সহজ সংখ্যায়

একটি model-এর memory footprint মোটামুটি তার file size-এর সমান, এর সঙ্গে প্রায় 1 gigabyte runtime overhead এবং context window-এর জন্য আরও কিছু memory যোগ হয়। Ollama-এর default model-গুলো 4-bit quantized, যেগুলোকে Q4 হিসেবে চিহ্নিত করা হয়। প্রতি 1 billion parameter-এর জন্য এতে প্রায় আধা gigabyte RAM লাগে। তাই হিসাবটি সহজ এবং এটিই সবকিছু নির্ধারণ করে। শেষের অংশটি আপনি নিজেই নির্ধারণ করেন: Ollama-এর ছোট default-এর চেয়ে num_ctx বাড়ালে বড় prompt-এর জন্য বেশি জায়গা পাওয়া যায়, কিন্তু RAM-এ KV cache বড় হয়। তাই কোনো model আপনার system-এ চলবে কি না বিচার করার আগে context length নির্ধারণ করুন।

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

এবার speed-এর কথা বলা যাক, কারণ এই বিষয়টি অনেকে কম গুরুত্ব দেন। CPU inference clock speed-এর চেয়ে memory bandwidth দ্বারা বেশি সীমাবদ্ধ হয়, আর shared vCPU VPS-এ bandwidth সাধারণত সীমিত। প্রতি second-এ এক অঙ্কের সংখ্যা থেকে কম দুই অঙ্কের tokens পাওয়ার আশা করুন: একটি 7-8B Q4 model প্রতি second-এ 4 থেকে 10 tokens দিতে পারে, আর একটি 3B model 10 থেকে 25 tokens দিতে পারে। GPU মোটামুটি এক order of magnitude দ্রুত। এগুলো ইচ্ছাকৃতভাবে আনুমানিক সংখ্যা। নিজের system-এ মাপাই সঠিক পদ্ধতি; নিচের run ধাপে তা কীভাবে করতে হয় দেখানো হয়েছে। কোনো article-এর সংখ্যার ওপর নয়, এই article-এর সংখ্যার ওপরও নয়, আপনার eval rate-এর ওপর নির্ভর করুন।

বাস্তব সিদ্ধান্ত হলো: CPU-তে ছোট quantized model ব্যবহার করে drafting, summarizing এবং classification-এর কাজ সত্যিই করা যায়, যদি আপনি এর গতি মেনে নিতে পারেন। আরও বড় বা দ্রুত model-এর জন্য GPU instance-এর budget রাখুন। নির্দিষ্ট একটি model নিয়ে এই হিসাব শুরু থেকে শেষ পর্যন্ত দেখতে চাইলে, VPS-এ Nemotron 3.5 Lightning চালানো কোন tag pull করতে হবে, বাস্তবে কত RAM দরকার এবং CPU-only ব্যবহারে গতি যথেষ্ট কি না—এসব ব্যাখ্যা করে।

একটি নির্দিষ্ট model-কে একটি নির্দিষ্ট system-এর সঙ্গে তুলনা করতে, এখানে তার memory footprint অনুমান করুন:

Ollama ইনস্টল করুন

দুটি পরিষ্কার পদ্ধতি আছে। bare VPS-এ official script ব্যবহার করাই সবচেয়ে সহজ:

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

এটি ollama নামে একটি system user তৈরি করে, binary-টি /usr/local/bin/ollama-এ ইনস্টল করে এবং 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: লক্ষ্য করুন। এটি port-টিকে শুধু localhost-এ bind করে। এর পরিবর্তে -p 11434:11434 লিখলে port-টি সব interface-এ publish হয়। security section-এ এই ভুলটির ব্যাপারে সতর্ক করা হয়েছে। একটি install method বেছে নিন। একই সময়ে script এবং container চালাবেন না, কারণ দুটি process port দখলের জন্য পরস্পরের সঙ্গে সংঘাতে জড়াবে।

প্রথম model pull করে চালান

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

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

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

ollama ps

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

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

শেষে মুদ্রিত eval rate line-টি এই hardware-এ প্রতি সেকেন্ডে আপনার token সংখ্যা। পরিকল্পনা করার সময় এই সংখ্যাটিই ভিত্তি হিসেবে ব্যবহার করুন।

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

স্ক্রিপ্ট দিয়ে ইনস্টল করে service হিসেবে চালালে, মডেলগুলো ollama ব্যবহারকারীর home directory-তে থাকে:

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

নিজের ব্যবহারকারী হিসেবে ইন্টার‌্যাক্টিভভাবে চালালে, মডেলগুলো ~/.ollama/models-এ থাকে। Container-এ এগুলো ollama নামের volume-এ থাকে। এটি গুরুত্বপূর্ণ, কারণ quantized weight দ্রুত জমা হয়: 3B মডেল প্রায় 2 GB, 7-8B মডেল প্রায় 5 GB এবং 14B মডেল প্রায় 9 GB জায়গা নেয়। তুলনা করার জন্য চারটি মডেল pull করলে অজান্তেই 20 GB ব্যবহার হয়ে যায়। যেসব মডেল রাখতে চান, সেগুলোর জন্য যথেষ্ট ডিস্ক নির্ধারণ করুন এবং বাকিগুলো ollama rm <model> দিয়ে মুছে ফেলুন। একই VPS-এ যদি আগে থেকেই নিজস্ব অনেক storage ব্যবহার করা কোনো service চলে, যেমন photo library ধরে রাখা PhotoPrism বা Immich, তাহলে প্রথমে free space থেকে সেই ব্যবহার বাদ দিন। অবশিষ্ট জায়গাকেই আপনার প্রকৃত model budget হিসেবে ধরুন।

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

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

sudo systemctl edit ollama.service

Editor যে [Service] header দেখায়, তার অধীনে এটি যোগ করুন:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

সর্বশেষ request-এর পর model কতক্ষণ memory-তে থাকবে, তা OLLAMA_KEEP_ALIVE নির্ধারণ করে। Default হলো 5 minutes। সারাদিন যে box-এ query চালানো হয়, সেখানে প্রতিবার weights reload এড়াতে সময় বাড়ান। RAM সীমিত হলে request শেষ হওয়ার সঙ্গে সঙ্গে RAM খালি করতে এটি 0 সেট করুন। নির্দিষ্ট সময়ের পরিবর্তে কোনো model অনির্দিষ্টকাল resident রাখতে চাইলে, Ollama model স্থায়ীভাবে loaded রাখার নির্দেশনায় প্রতি-request-এর keep_alive field এবং reboot-এর পরে প্রথম ধীর request-এর সময় নয়, তার আগেই weights আবার warm করার পদ্ধতি ব্যাখ্যা করা হয়েছে। systemctl edit নিজে unit files reload করে। তাই পরিবর্তন প্রয়োগ করতে restart করুন:

sudo systemctl restart ollama

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

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

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

একটি ভুল কখনো করবেন না: OLLAMA_HOST=0.0.0.0 সেট করে firewall-এ 11434 খুলবেন না। এতে কোনো authentication ছাড়াই inference server-টি সম্পূর্ণ Internet-এর কাছে প্রকাশিত হয়। raw 11434-on-0.0.0.0-কে কোনো configuration-ই নিরাপদ করতে পারে না, কারণ Ollama-তে configuration করার মতো কোনো authentication ব্যবস্থা নেই; authentication আদৌ বিদ্যমান নয়। এটি এই নির্দিষ্ট service-এর জন্য একটি নিয়ম, কখনো কোনো port খোলা যাবে না—এমন নিষেধাজ্ঞা নয়: remote desktop-এর জন্য self-hosted RustDesk relay-কে কাজ করার জন্যই public traffic গ্রহণ করতে হয়। এর বৈধতা আসে নিজস্ব key-based authentication এবং সংক্ষিপ্ত, documented port তালিকা ব্যবহারের মাধ্যমে। Ollama-তে এই দুটির কোনোটিই নেই।

বক্সটি ছাড়া অন্য কোনো স্থান থেকে model-এ পৌঁছানোর 3টি নিরাপদ উপায় আছে:

• লোকাল রাখুন। যদি একমাত্র caller একই VPS-এর অন্য কোনো program, একটি cron script, একটি bot বা আপনার tool-গুলোকে model-এর সঙ্গে সংযুক্ত করা MCP server হয়, তাহলে bind 127.0.0.1-এ রাখুন এবং সেই program-কে http://127.0.0.1:11434 call করান। কিছুই উন্মুক্ত হবে না এবং অতিরিক্ত কিছু প্রয়োজন হবে না।
• একটি private tunnel ব্যবহার করে পৌঁছান। VPS-টিকে আপনার নিজস্ব পরিচালিত WireGuard VPN-এ যুক্ত করুন, OLLAMA_HOST-কে tunnel address হিসেবে সেট করুন, যেমন 10.8.0.1, 0.0.0.0 নয়। তাহলে শুধু VPN peer-গুলো সংযোগ করতে পারবে। Public Internet এখনও 11434-এ কিছু দেখতে পাবে না।
• সামনে authentication-সমর্থিত reverse proxy বসান। nginx, Traefik বা Caddy-তে TLS termination করুন এবং password বা token আবশ্যক করুন। এরপর 127.0.0.1:11434-এ proxy করুন। Ollama তার localhost bind বজায় রাখবে। Public port-এ listening করবে শুধু proxy। যেকোনো local service-এর সামনে nginx-এ একটি Let's Encrypt certificate বসানোর মতোই এটি কাজ করে।

পরবর্তী ধাপে chat 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 হিসেবে কাজ করে এবং container 127.0.0.1:11434 ঠিকানায় Ollama-তে পৌঁছাতে পারে, অথচ Ollama-কে অন্য কোনো interface-এ listen করতে হয় না। অন্যত্র যে bridge-network পদ্ধতিটি দেখবেন, --add-host=host.docker.internal:host-gateway-এর সঙ্গে OLLAMA_BASE_URL=http://host.docker.internal:11434, সেটি এখানে কাজ করে না। ওই নামটি Docker bridge gateway-তে resolve হয়। Host-এ 127.0.0.1-এ bind করা service bridge-এর মাধ্যমে পৌঁছানো যায় না। তাই Open WebUI শুধু Ollama-তে connect করতে না পারার বার্তা দেখাতে থাকে।

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

Laptop থেকে HTTPS-এর মাধ্যমে chat খুলতে 127.0.0.1:8080-এর সামনে একটি TLS reverse proxy বসান। যদি এই server-এ ইতিমধ্যে একাধিক Docker app route করে থাকেন, তাহলে অনেক app-এ automatic TLS-সহ Traefik সবচেয়ে উপযুক্ত। একটি label block certificate জারি করে এবং chat.example.com-কে Open WebUI-তে route করে। একই label-per-app routing এই server-এর অন্যান্য browser front-end-ও ব্যবহার করবে। সেটি status dashboard হোক বা 90s-এর rental store হিসেবে Jellyfin library দেখানো Halcyon-এর মতো অপেক্ষাকৃত বিনোদনধর্মী কিছু হোক, প্রতিটি নিজস্ব login-সহ আলাদা hostname-এ চলবে। Security section-এর নিয়ম এখানেও প্রযোজ্য: public port এবং login proxy নিয়ন্ত্রণ করবে, আর 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 সংযুক্ত করার পদ্ধতিও এটি। আপনি যদি ইতিমধ্যে এই মেশিনে development করেন, তাহলে একটি local model tmux-এর ভেতরে VPS-এ চলা Claude Code-এর পাশাপাশি scripts এবং plugins চালাতে পারে। এতে কম খরচের private drafting কাজ paid API-এর বাইরে রাখা যায়, আর জটিল reasoning hosted model-এ করা যায়।

ব্যর্থতার ধরন এবং আপনি যে সঠিক string দেখতে পাবেন

Generation চলার মাঝখানে process "Killed" হয়ে যায়। আপনি একটি বড় model চালু করলে terminal-এ Killed দেখা যায়, অথবা server log-এ llama runner process has terminated: signal: killed দেখা যায়। Linux OOM killer process-টি বন্ধ করেছে, কারণ modelটির যত RAM দরকার ছিল, server-এ তার চেয়ে কম RAM আছে। sudo dmesg | grep -i oom দিয়ে কারণ নিশ্চিত করুন। সেখানে Out of memory: Killed process ... (ollama)-এর মতো একটি line দেখতে পাবেন। সমাধান হলো ছোট বা আরও বেশি quantized model ব্যবহার করা, 13B-এর পরিবর্তে llama3.2:3b ব্যবহার করা, অথবা swap যোগ করা। এতে physical RAM সামান্য অতিক্রম করা load ধীরে সম্পন্ন হবে, বন্ধ হয়ে যাবে না। Swap তাৎক্ষণিক crash-কে ধীর response-এ পরিবর্তন করে; 4 GB RAM-এ 70B model চালানোর উপযোগী করে না। আপনি terminal দেখার সময় না থাকলে এই kill নীরবে ঘটে। তাই অন্য স্থান থেকে query করা server-এ OnFailure= unit যুক্ত করে ollama.service-এ এমন notification পাঠান, যা push alert-এর জন্য আপনার পরিচালিত ntfy server-এ post করে। এতে পরবর্তী request-এর সময় নিজে আবিষ্কার করার বদলে process বন্ধ হওয়ার সঙ্গে সঙ্গেই জানতে পারবেন।

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

প্রথম token আসতে অনেক সময় লাগে, তারপর স্বাভাবিক থাকে। Cold model প্রথমবার 5 থেকে 30 সেকেন্ড পর্যন্ত কিছুই দেখায় না, তারপর স্বাভাবিকভাবে stream করে। এই বিরতি প্রথমবার disk থেকে weights RAM-এ load হওয়ার কারণে হয়। ধীর storage হলে সময় আরও বাড়ে। Load হওয়ার পর model OLLAMA_KEEP_ALIVE-এর সময়সীমা পর্যন্ত memory-তে resident থাকে। তাই দ্বিতীয় prompt-এর উত্তর সঙ্গে সঙ্গে আসে। প্রথম load-এর সময় call path-এর কোনো timeout অতিক্রম করলে ধীর উত্তর পাওয়ার বদলে error আসে। কোন layer context deadline exceeded রিপোর্ট করেছে তা নির্ণয় করা থেকে বোঝা যায় client, proxy অথবা load process—কোনটির অপেক্ষার সময় শেষ হয়েছে। বিরতি বিরক্তিকর হলে ওই value বাড়ান। কোনো model বর্তমানে load করা আছে কি না দেখতে ollama ps ব্যবহার করুন।

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

অন্য machine থেকে connection refused। আপনার laptop থেকে curl: (7) Failed to connect to <ip> port 11434: Connection refused পান। এটি প্রত্যাশিত আচরণ। Ollama শুধু localhost-এ bind করে। 0.0.0.0-এ bind করে এটি "ঠিক" করবেন না, কারণ সেটিই আগের exposure mistake। এর বদলে VPN অথবা authentication করা proxy-এর মাধ্যমে model-এ পৌঁছান।

আপনি 11434 Internet-এ উন্মুক্ত করেছেন। আপনি যদি OLLAMA_HOST=0.0.0.0 সেট করে firewall খুলে দিয়ে থাকেন এবং এখন এমন model pull দেখতে পান যা আপনি শুরু করেননি, অথবা অজানা client-এর কারণে CPU 100%-এ আটকে থাকে, তাহলে অন্যরা serverটি খুঁজে ব্যবহার করেছে। এটি প্রধান ভুল, কোনো বিরল edge case নয়। 127.0.0.1 অথবা VPN address-এ পুনরায় bind করুন, firewall-এ 11434 বন্ধ করুন এবং সামনে authentication যুক্ত করুন। addressটি খোলা থাকা অবস্থায় সেখানে পৌঁছানো যেকোনো service অপরিচিতরা query করেছে বলে ধরে নিন।

ব্যাকআপ এবং আপগ্রেড

হারানোর মতো state খুব কম। মডেলগুলো আবার download করা যায়। তাই ব্যাকআপ করার মতো মূল জিনিস হলো Open WebUI-এর data volume, accounts, chat history, settings এবং আপনার তৈরি করা যেকোনো systemd drop-in। একটি অস্থায়ী container ব্যবহার করে volume-এর ব্যাকআপ নিন:

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

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

FAQ

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

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

প্রতিটি model-এর কত RAM প্রয়োজন?

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

Ollama API কি authenticated?

না। Ollama-তে built-in authentication, API key বা rate limit নেই। port 11434-এ পৌঁছাতে পারে এমন যে কেউ এর উপর সম্পূর্ণ নিয়ন্ত্রণ পায়। এই কারণেই Ollama default হিসেবে 127.0.0.1-এ bind করে এবং 0.0.0.0-এ 11434 কখনো Internet-এ expose করা উচিত নয়। এটি local network থেকে, private VPN-এর মাধ্যমে, অথবা login যোগ করা reverse proxy-এর মাধ্যমে ব্যবহার করুন।

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

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

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

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