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 serve করে। Installation-এর জন্য একটি command-ই যথেষ্ট। এই কাজের কঠিন অংশগুলো অন্যত্র: আপনার VPS যে model-কে RAM-এ বাস্তবে ধারণ করতে পারে সেটি বেছে নেওয়া, এবং ভুলবশত authentication ছাড়া একটি inference server পুরো Internet-এ প্রকাশ না করা।

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

বাস্তব মাপ যাচাই, সরল সংখ্যায়

কোনো model-এর memory footprint মোটামুটি তার file size-এর সমান, এর সঙ্গে runtime overhead হিসেবে প্রায় 1 gigabyte এবং context window-এর জন্য আরও কিছু memory যোগ হয়। জনপ্রিয় অধিকাংশ Ollama model-এর default tag, যার মধ্যে llama3.2:3b, llama3.1:8b এবং mistral:7b রয়েছে, 4-bit quantized (Q4_K_M হিসেবে চিহ্নিত)। এতে প্রতি 1 billion parameter-এর জন্য প্রায় আধা gigabyte RAM লাগে। সব default Q4 নয়: smollm2:135m-এর মতো ছোট model 16-bit অবস্থায় release হয়। তাই হিসাব করার আগে model-এর library page-এ quantization line পরীক্ষা করুন। হিসাবটি সরল, এবং এটিই সবকিছু নির্ধারণ করে। শেষের অংশটি আপনি নিজে নির্ধারণ করেন: Ollama-র ছোট default-এর num_ctx বাড়ালে দীর্ঘ prompt-এর জন্য বেশি জায়গা পাওয়া যায়, কিন্তু RAM-এ KV cache বড় হয়। তাই কোনো model এই box-এ চলবে কি না বিচার করার আগে 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 box বা বাস্তবে GPU দরকার। CPU VPS-এ এটি হয় fit করবে না, নয়তো এত ধীরে উত্তর দেবে যে ব্যবহার করা অকার্যকর হবে।

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

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

একটি নির্দিষ্ট box-এর সঙ্গে নির্দিষ্ট model তুলনা করতে এখানে তার 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, OLLAMA_ORIGINS, শুধু কোন browser origin থেকে API call করা যাবে তা নিয়ন্ত্রণ করে (CORS); অন্য মেশিনের curl বা script আটকানোর সঙ্গে এর কোনো সম্পর্ক নেই। যে কেউ port 11434-এ পৌঁছাতে পারলে আপনার pull করা যেকোনো model চালাতে, নতুন model pull করতে, সেগুলো delete করতে এবং অনির্দিষ্টকাল 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-এর documented settings-এর কোনোটিই local API-তে authentication যোগ করে না, আর origin allow-list কোনো login নয়। এটি এই নির্দিষ্ট service-এর ক্ষেত্রে একটি নিয়ম; কখনো কোনো port খোলা যাবে না—এমন নিষেধাজ্ঞা নয়: remote desktop-এর জন্য self-hosted RustDesk relay কাজ করার জন্য public traffic গ্রহণ করতেই হবে, এবং এর নিজস্ব key-based authentication ও সংক্ষিপ্ত, documented port-এর তালিকা থাকার কারণে তা গ্রহণযোগ্য। Ollama-তে এর কোনোটিই নেই।

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

• এটি local রাখুন। যদি একমাত্র 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-গুলোকে connect করতে দিন। Public Internet এখনও 11434-এ কিছু দেখতে পাবে না।
• সামনে authentication-যুক্ত reverse proxy বসান। TLS termination করুন এবং nginx, Traefik বা Caddy-তে 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-সহ 404 response পাওয়া যায়। সাধারণ 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 যুক্ত করার পদ্ধতিও এটি। আপনি যদি ইতিমধ্যে এই box-এ development করেন, তাহলে একটি local model script এবং plugin-এর পাশাপাশি tmux-এর ভেতরে VPS-এ চলা Claude Code-কেও চালাতে পারে। এতে কম খরচের private drafting কাজ paid API-এর বাইরে রাখা যায়, আর জটিল reasoning hosted model-এ করা যায়।

ব্যর্থতার ধরন এবং আপনি যে নির্দিষ্ট বার্তাগুলো দেখবেন

Generation চলাকালে process "Killed" হয়। আপনি একটি বড় model চালু করলে terminal-এ Killed মুদ্রিত হয়, অথবা server log-এ (journalctl -u ollama) llama-server process has terminated দিয়ে শুরু হওয়া একটি line দেখা যায়। এটি Ollama 0.40.7-এর বার্তা, যা 21 October 2026-এ যাচাই করা হয়েছে; পুরোনো release-গুলোতে llama runner process has terminated: signal: killed লেখা থাকত। Modelটির প্রয়োজনীয় RAM সার্ভারের মোট RAM-এর চেয়ে বেশি হওয়ায় Linux OOM killer processটি বন্ধ করেছে। sudo dmesg | grep -i oom দিয়ে কারণ নিশ্চিত করুন; সেখানে Out of memory: Killed process ...-এর মতো একটি 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-এর সঙ্গে যুক্ত করে push alert পাঠানোর জন্য আপনার পরিচালিত ntfy server-এ notification পাঠান। এতে পরবর্তী request-এর সময় আবিষ্কার করার বদলে process বন্ধ হওয়ার সঙ্গে সঙ্গে জানতে পারবেন।

Ollama model load করতে অস্বীকৃতি জানায়। Crash না করে request সঙ্গে সঙ্গে error দিয়ে ব্যর্থ হয় এবং server log-এ model is too large for system memory লেখা হয় (Ollama 0.40.7, 21 October 2026-এ যাচাই করা)। পুরোনো release-গুলো prompt-এই Error: model requires more system memory (X GiB) than is available (Y GiB) মুদ্রণ করত। এটি আগের crash-এর নিয়ন্ত্রিত সংস্করণ। Ollama হিসাব করে OOM killer-এর জন্য অপেক্ষা না করে নিজেই থেমেছে। আপনার free RAM-এর চেয়ে কম প্রয়োজন এমন model বেছে নিন (free -h দিয়ে পরীক্ষা করুন), context length কমান, অথবা বড় VPS ব্যবহার করুন। কোনো flag model-কে জোর করে RAM-এ fit করাতে পারে না; প্রয়োজনীয় memory বাস্তব।

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

সবকিছুই শুধু ধীর। কোনো error ছাড়াই প্রতি সেকেন্ডে দশটি বা তার কম token পাওয়া যায়। এটি CPU inference-এর স্বাভাবিক আচরণ। ollama ps-এ 100% CPU দেখা গেলে বোঝায় যে কোনো GPU নেই। এটি bug নয়। কোনো setting CPU-কে GPU বানাতে পারে না, কারণ প্রধান সীমাবদ্ধতা memory bandwidth। তবে VM-এ একটি setting পরীক্ষা করা যায়। Ollama শনাক্ত করা physical core-এর সংখ্যা থেকে thread count বেছে নেয়, আর hypervisor কখনও তা ভুলভাবে জানাতে পারে। ollama run --verbose session-এ /set parameter num_thread 4 চেষ্টা করুন (অথবা আপনার vCPU count ব্যবহার করুন), একই prompt আবার চালান, এবং যে value-তে eval rate সবচেয়ে ভালো হয় সেটি রাখুন। এর বাইরে ছোট model ব্যবহার করুন, এই গতি মেনে নিন, অথবা GPU instance ব্যবহার করুন। কিছু নষ্ট হয়েছে ধরে নেওয়ার আগে --verbose দিয়ে প্রকৃত rate মাপুন। অপেক্ষার কারণ rate নয়, উত্তরের দৈর্ঘ্য হলে num_predict দিয়ে reply-এর সর্বোচ্চ দৈর্ঘ্য নির্ধারণ করুন। এতে বেশি কথা বলার প্রবণতা থাকা model এমন token-এ কয়েক মিনিট ব্যয় করবে না যা আপনি পড়বেনই না।

অন্য machine থেকে connection refused হয়। আপনার laptop থেকে current curl (8.23.0, 21 October 2026-এ যাচাই করা) curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server মুদ্রণ করে, আর Ubuntu 24.04-এর সঙ্গে থাকা curl 8.5.0 curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server মুদ্রণ করে। "Connection refused" শব্দগুলো কেবল -v যোগ করলে দেখা যায়; line-টি হবে connect to <ip> port 11434 from ... failed: 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 খোলা থাকা অবস্থায় সেখানে পৌঁছানো যেকোনো request অচেনা ব্যবহারকারীরা query করেছে ধরে নিন।

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

হারানোর মতো state খুব কম। Model আবার download করা যায়। তাই ব্যাকআপ করার মতো একমাত্র জিনিস হলো Open WebUI-এর data volume, account, chat history, setting এবং আপনার তৈরি করা 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 আপগ্রেড করুন। 0.40 line-এর জন্য disk-সংক্রান্ত একটি বিষয় মনে রাখুন: Ollama 0.40.2 আগের version দিয়ে pull করা model-গুলোর background upgrade শুরু করেছিল এবং original copy-গুলো backup হিসেবে রেখে দেয়। তাই সেগুলো মুছে না ফেলা পর্যন্ত অতিরিক্ত disk space ব্যবহার করে। 0.40.3 (11 October 2026) সেই background upgrade স্থগিত করেছে। আপগ্রেডের পরে df -h পরীক্ষা করুন এবং ওই backup মুছে ফেলার command জানতে release notes পড়ুন। দীর্ঘমেয়াদে কোনো version pin করে রাখবেন না। Model quality এবং runtime দুটিই দ্রুত পরিবর্তিত হয়। তাই release notes পড়ুন এবং নিজের server-এ আবার benchmark চালান। গত quarter-এর সংখ্যার ওপর নির্ভর করবেন না।

FAQ

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

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

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

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

Ollama API কি authenticated?

না। Ollama-তে built-in authentication, API key বা rate limit নেই। যে কেউ port 11434-এ পৌঁছাতে পারলে সেটির উপর পূর্ণ নিয়ন্ত্রণ পায়। এর OLLAMA_ORIGINS setting শুধু কোন browser origin থেকে API call করা যাবে তা সীমিত করে; কে connect করতে পারবে তা নির্ধারণ করে না। এই কারণেই এটি ডিফল্টভাবে 127.0.0.1-এ bind করে এবং 0.0.0.0-এ 11434 কখনো Internet-এ expose করা যাবে না। এটি localভাবে, private VPN-এর মাধ্যমে অথবা login যোগ করা reverse proxy দিয়ে ব্যবহার করুন।

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

--network=host ব্যবহার করে Docker-এ Open WebUI চালান। এতে এটি host-এর loopback share করবে এবং native Ollama-তে http://127.0.0.1:11434-এর মাধ্যমে পৌঁছাতে পারবে। এরপর আপনার laptop থেকে access করার জন্য এর port 8080-এর সামনে একটি TLS reverse proxy রাখুন। Firewall-এ 8080 বন্ধ রাখুন, যাতে proxy-ই একমাত্র public access 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 সাধারণত কোনো পরিবর্তন ছাড়াই চলে।