Ollama বনাম llama.cpp: VPS-এ কোনটি চালাবেন?

Ollama বনাম llama.cpp: আপনি কোন স্তরটি চালাতে চান?

প্রশ্নটিতে যেভাবে বোঝানো হয়েছে, Ollama এবং llama.cpp সেভাবে পরস্পরের প্রতিদ্বন্দ্বী নয়। llama.cpp হলো inference engine: এটি একটি model file লোড করে এবং prompt-কে token-এ রূপান্তর করে। Ollama হলো model manager, background daemon এবং HTTP API, যা ওই engine-এর ওপর কাজ করে। Ollama-এর README-তে এখনও llama.cpp-কে inference backend হিসেবে উল্লেখ করা আছে (27 October 2026 তারিখে পরীক্ষা করা হয়েছে)। তাই প্রকৃত প্রশ্ন হলো, আপনার VPS-এ কোন স্তরটি পরিচালনা করতে চান; কোনটি দ্রুততর, তা নয়।

আপনি যখন নাম দিয়ে model fetch করে এবং অতিরিক্ত নজরদারি ছাড়াই চলতে থাকা একটি service চান, তখন Ollama চালান। VPS-এর resource সীমিত হলে সরাসরি llama.cpp চালান এবং নির্দিষ্ট model file, নির্দিষ্ট context size ও নির্দিষ্ট thread count বেছে নিন। কারণ ছোট VPS-এ এই প্রতিটি setting এমন memory ব্যবহার করে, যা আপনার কাছে নাও থাকতে পারে।

আসলে প্রতিটি project কী

llama.cpp হলো ggml library-এর ওপর তৈরি transformer inference-এর C এবং C++ implementation। এটি GGUF file পড়ে। GGUF (GGML universal file format) হলো single-file container, যেখানে model চালানোর জন্য engine-এর প্রয়োজনীয় weights, tokeniser এবং metadata থাকে। Project-টি আলাদা কাজের জন্য আলাদা binary সরবরাহ করে। llama-server হলো HTTP server, llama-cli হলো interactive prompt, এবং llama-bench throughput মাপে। Project-টি এখন semantic-versioned release (MAJOR.MINOR.PATCH) প্রকাশ করে। 15 October 2026-এ প্রকাশিত v0.7.0, 27 October 2026 অনুযায়ী, সর্বশেষ release ছিল। Build-number-সহ nightly tag-ও পাশাপাশি প্রকাশিত হয়, প্রতিদিন একাধিক। 27 October 2026-এর সর্বশেষটি ছিল b11913।

Ollama হলো Go program। ollama serve দিয়ে চালু করা একটি background daemon model load করে এবং HTTP request-এর উত্তর দেয়। একটি command line client ওই daemon-এর সঙ্গে যোগাযোগ করে। উভয়ের পেছনে ollama.com-এর একটি registry রয়েছে, যেখানে আগে থেকে package করা model থাকে। Ollama semantic version ব্যবহার করে। v0.32.5 27 July 2026-এ প্রকাশিত হয়েছিল। v0.40.12 27 October 2026-এ 00:07 UTC-তে প্রকাশিত হয়। ollama pull একটি GGUF file-এর সঙ্গে prompt template এবং default parameter-এর একটি set fetch করে। Linux-এ এটি file-গুলো /usr/share/ollama/.ollama/models-এর অধীনে সংরক্ষণ করে। File-গুলো root disk-এ থাকে এবং প্রতিটির আকার কয়েক gigabyte পর্যন্ত হয়। তাই 25 GB root volume-সহ VPS-এ তৃতীয় download সেটি পূর্ণ করে ফেলার আগে pull-এর পরে কী থাকে এবং model directory অন্যত্র কীভাবে সরাবেন জানা উপযোগী।

Packaging-এর পার্থক্য মূলত এটিই। Ollama আপনার হয়ে quantisation, template এবং context length নির্ধারণ করে। মনে রাখার জন্য এটি একটি মাত্র নাম দেয়। llama.cpp এই পছন্দগুলো flag হিসেবে প্রকাশ করে। আপনি কোনো setting নির্ধারণ না করলে এটি স্বয়ংক্রিয় default ব্যবহার করে।

অক্ষ 1: মডেল ও quantisation নিয়ন্ত্রণ

Quantisation মূল মডেলের 16 বা 32 bit-এর তুলনায় ওজনগুলোকে কম bit-এ সংরক্ষণ করে। প্রচলিত GGUF build-গুলোতে প্রতি weight-এ গড়ে প্রায় 4, 5 বা 8 bit ব্যবহৃত হয়। পুরো ফাইলে precision সমান থাকে না। llama.cpp-এর quantiser source-এ (27 October 2026 তারিখে দেখা) Q4_K_M build অধিকাংশ tensor-কে 4-bit রাখে। তবে output layer এবং প্রায় অর্ধেক layer-এর attention value ও feed-forward down tensor-কে তার পরিবর্তে 6-bit Q6_K করা হয়। Norm-এর মতো ছোট tensor একেবারেই quantise করা হয় না। এ কারণেই 8 billion parameter-এর একটি model সাধারণ VPS-এর RAM-এ চালানো যায়। Pattern জানা থাকলে GGUF naming সহজে বোঝা যায়: Q4_K_M অর্থ 4-bit K-quant, medium size। সংখ্যা বেশি হলে precision বেশি থাকে এবং memory-ও বেশি লাগে।

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

এগুলো Hugging Face-এর bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository-তে প্রকাশিত file size। এগুলো 2 August 2026 তারিখে দেখা এবং byte থেকে GiB-তে রূপান্তর করা হয়েছে। একটি model-এর 6টি build আছে। সবচেয়ে ছোটটির আকার 2.96 GiB, আর সবচেয়ে বড়টির আকার 7.95 GiB। প্রচলিত default Q4_K_M-এর আকার 4.58 GiB। 4 GiB VPS-এ এই একটিমাত্র পছন্দই ঠিক করে দেয় model আদৌ load হবে কি না। তবে এই সিদ্ধান্তের মাত্র অর্ধেক হলো size। কারণ যে row-এর আকার আপনার সামর্থ্যের মধ্যে আছে, সেটি ব্যবহারযোগ্য হবে এমন নয়। Q4, Q8 এবং fp16 উত্তরমানের জন্য আসলে কী খরচ তৈরি করে—এটি দেখায় অতিরিক্ত gigabyte-এ এমন কোনো সুবিধা পাওয়া যাবে কি না যা আপনি বাস্তবে বুঝতে পারবেন।

llama.cpp-এ file-এর নাম নির্দিষ্ট করতে হয়। তাই row-টি আপনাকেই বেছে নিতে হয়।

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c হলো token-এ context size, -t হলো thread count, এবং -ngl নির্ধারণ করে কতটি layer GPU-তে যাবে (শুধু CPU-যুক্ত machine হলে 0)। কোনো setting নির্ধারণ না করলে default ব্যবহার হয়। Device memory অনুযায়ী unset argument সামঞ্জস্য করার জন্য --fit default হিসেবে চালু থাকে।

Ollama-তে pull করা tag-এর সঙ্গে quantisation নির্ধারিত থাকে। Disk-এ বাস্তবে কোন build আছে তা ollama ls দেখায়। Registry-তে প্রয়োজনীয় build না থাকলে নিজে একটি GGUF import করুন। একটি Modelfile লিখুন:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

এরপর সেটি build করে ফলাফল যাচাই করুন:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Context length এমন একটি setting যা অনেকের সমস্যা তৈরি করে। Ollama available VRAM দেখে default বেছে নেয়। GPU না থাকা machine সবচেয়ে ছোট bucket-এ পড়ে: 4096 token। 20,000 token-এর document পাঠালে model document দেখার আগেই অতিরিক্ত token বাদ পড়ে। ফলে model document-এর অর্ধেক পড়ে পুরো file সম্পর্কে আত্মবিশ্বাসের সঙ্গে ভুল উত্তর দিতে পারে। Daemon-এ OLLAMA_CONTEXT_LENGTH দিয়ে অথবা Modelfile-এ PARAMETER num_ctx দিয়ে এটি বাড়ান। শুধু একটি job-এর জন্য বড় window প্রয়োজন হলে server জুড়ে নয়, প্রতি request-এ num_ctx নির্ধারণ করা যায়। এতে daemon-এর অন্য কাজগুলোর জন্য অতিরিক্ত cache তৈরি হয় না। llama.cpp-এর default-ও নির্ভর করার মতো নয়। -c স্পষ্টভাবে সেট করুন এবং কী সেট করেছেন তা নিশ্চিতভাবে জানুন।

যে memory হিসাবটি কেউ দেখায় না

শুধু model file-এর আকারই মোট খরচ নয়। KV cache (key/value cache) context-এর প্রতিটি token-এর জন্য প্রতিটি layer-এ একটি entry ধরে রাখে। Conversation বড় হওয়ার সঙ্গে এটি বাড়তে থাকে।

Llama 3.1 8B-এর হিসাবটি দেখুন। Model-এ 32টি layer, 8টি key/value head এবং 128-এর head dimension আছে। f16-এ প্রতিটি token প্রতি key এবং value-এর জন্য 2 bytes করে সংরক্ষণ করে। তাই 2 x 8 x 128 x 2 = 4096 bytes প্রতি layer। 32টি layer জুড়ে এটি প্রতি token-এ 128 KiB। 4096 token-এর context-এর জন্য 512 MiB এবং 32,768 token-এর context-এর জন্য 4 GiB লাগে।

তাই Q4_K_M 8B model-এর 4k context চালাতে weights-এর জন্য প্রায় 4.58 GiB, cache-এর জন্য প্রায় 0.5 GiB এবং runtime-এর জন্য অতিরিক্ত memory প্রয়োজন। এটি 4 GiB RAM-এ চলবে না। কাজ করার মতো অবকাশসহ 8 GiB RAM-এ চলবে। একই 8 GiB machine-এ context 32k করলে cache একাই অবশিষ্ট memory দখল করে নেবে। Model load থাকা অবস্থায় free -h দিয়ে live memory usage দেখুন। মাপেননি এমন কোনো estimate-এর ওপর নির্ভর করবেন না। 8B-এর তুলনায় অনেক বড় model-এর জন্য capacity নির্ধারণ করলে CPU-only VPS-এ 27B model-এর হিসাব দেখায়, 8 থেকে 64 GB-এর প্রতিটি tier-এ বাস্তবে কতটা model রাখা যায়।

Ollama এই খরচ আরও বাড়ায়। OLLAMA_NUM_PARALLEL-এর default মান 1। Model-এর প্রয়োজনীয় memory এই মান এবং context length—উভয়ের গুণফল অনুযায়ী বাড়ে। দুটিই একসঙ্গে বাড়ালে daemon নীরবে আপনার প্রত্যাশার তুলনায় কয়েক গুণ বেশি RAM চাইতে পারে। একই হিসাব একসঙ্গে কতজন user চালানো যাবে তার সীমাও নির্ধারণ করে। কারণ প্রতিটি concurrent request-এর জন্য KV cache-এর আলাদা অংশ দরকার। এটাই একজনের জন্য স্বাভাবিক চলা server পাঁচজন হলে থেমে যাওয়ার কারণ।

অক্ষ 2: আপনাকে যে daemon পরিচালনা করতে হবে

Ollama install script একটি systemd unit লেখে, একটি ollama system user তৈরি করে এবং service enable করে। আপনাকে এগুলোর কোনোটি নিজে লিখতে হয় না। Configuration systemd-এর মাধ্যমে পরিচালনা করা হয়:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

CPU VPS-এ OLLAMA_KEEP_ALIVE-এর গুরুত্ব অন্য যেকোনো পরিবেশের চেয়ে বেশি। ডিফল্টভাবে model 5 মিনিট memory-তে রাখা হয়, তারপর unload করা হয়। পরের request-এর উত্তর দেওয়ার আগে পুরো file আবার load করতে হয়। kernel যদি file-টি এখনও page cache-এ ধরে রাখে, তাহলে কাজটি দ্রুত হয়। তবে সেটি ধরে রাখার জন্য spare RAM থাকতে হবে। অন্য কাজ page cache থেকে file-টি সরিয়ে দিলে file আবার disk থেকে পড়তে হয়। ফলে ধীর storage-এ 4.58 GiB reload দুই সেকেন্ডের reply-কে ত্রিশ সেকেন্ডে পরিণত করতে পারে। দীর্ঘ keep-alive latency কমায়, কিন্তু RAM স্থায়ীভাবে ব্যবহার করে। দুটিই বাস্তব খরচ। যেটির প্রভাব কম, সেটি বেছে নিন। model-কে সব সময় memory-তে রাখতে চাইলে keep_alive সেট করে idle period এবং reboot-এর পরেও model ধরে রাখা কয়েকটি line-এই করা যায়। এতে প্রতিবার machine restart হওয়ার পর আপনাকে হাতে model warm করতে হয় না।

llama.cpp কোনো daemon বা service user দেয় না। তাই দুটিই আপনাকে নিজে সেট up করতে হবে। আপনি যে llama.cpp directory-তে build করেছেন, সেখান থেকে binary ও এর library /usr/local-এ install করুন, একটি llama user তৈরি করুন এবং তাকে model-এর একটি copy দিন:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

build করার পরিবর্তে release archive ব্যবহার করলে ExecStart-কে archive-এর ভেতরের llama-server-এর দিকে নির্দেশ করুন। কারণ archive binary-র পাশে library রাখে। এরপর unit-টি /etc/systemd/system/llama-server.service হিসেবে লিখুন:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now llama-server দিয়ে এটি enable করুন। এরপর process তার পুরো lifetime জুড়ে model ধরে রাখবে। ডিফল্টভাবে idle অবস্থায় কিছু unload হবে না। তবে --sleep-idle-seconds যোগ করলে service বন্ধ না করেই স্বয়ংক্রিয় unloading এবং reloading চালু করা যায়। unit লেখা আপনার জন্য নতুন হলে এটি VPS-এ systemd-এর অধীনে নিজের service চালানোর একই pattern।

অক্ষ 3: আপনার app যে API-র সঙ্গে যোগাযোগ করবে

এই অক্ষটি এখন অনেকটাই সংকুচিত হয়েছে। উভয় project এখন OpenAI chat format-এ কথা বলে, তাই শুধু base URL পরিবর্তন করলেই অধিকাংশ client library যেকোনো একটির সঙ্গে কাজ করে।

Ollama 127.0.0.1:11434-এ সংযোগের জন্য অপেক্ষা করে। এর OpenAI-compatible route হলো http://localhost:11434/v1/chat/completions, এবং পাশাপাশি এটি /api/chat-এ একটি native API চালু রাখে। Anthropic-compatible route-ও নথিভুক্ত আছে। এই route-গুলোর কোনোটি মডেলকে নিজে থেকে কোনো তথ্য খুঁজে দেখার সুযোগ দেয় না। তাই আপনার অ্যাপের এমন উত্তর প্রয়োজন হলে, যা মডেলের training data-এর চেয়ে নতুন, Ollama's API, Open WebUI অথবা একটি সংক্ষিপ্ত tool loop-এর মাধ্যমে web search সংযুক্ত করার পরিকল্পনা করুন।

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

উপরের flag দিয়ে শুরু করলে llama-server 127.0.0.1:8080-এ listen করে। একা চালালে এটি এখন port 9931-এ default হয় (27 October 2026 তারিখে যাচাই করা হয়েছে)। তাই আপনার app যদি 8080 প্রত্যাশা করে, command line-এ --port রাখুন। এটি /v1/chat/completions, /v1/completions এবং /v1/embeddings পরিবেশন করে। এছাড়া এর নিজস্ব /completion endpoint এবং একটি built-in web UI আছে। এটি Ollama-তে না থাকা operational route-ও প্রকাশ করে: readiness probe-এর জন্য /health, loaded model-এর settings-এর জন্য /props, প্রতিটি request slot কী করছে তা দেখার জন্য /slots, এবং Prometheus format-এ /metrics। শেষের endpoint-টি default অবস্থায় বন্ধ থাকে, তাই আগে --metrics যোগ করতে হবে। আপনি যদি এই service monitor করার পরিকল্পনা করেন, তাহলে এই পার্থক্যটিই সম্ভবত সিদ্ধান্ত নির্ধারণ করবে।

কোনো server-ই আপনার হয়ে authentication চালু করে না। যথার্থ কারণেই উভয়টির default হলো loopback। SSH tunnel-এর মাধ্যমে অথবা reverse proxy-এর পেছন থেকে এগুলোতে পৌঁছান। কখনো 11434 বা 8080 internet-এর জন্য উন্মুক্ত করবেন না।

CPU-শুধু VPS বাস্তবে কী করতে পারে

CPU-শুধু VPS ছোট মডেল ধীরে চালাতে পারে। এটিই সৎ সারসংক্ষেপ। গুরুত্বপূর্ণ বিষয় হলো সীমাটি কোথায়, তা জানা। VPS-কে কেন্দ্র করে কিছু নকশা করার আগে পরিমাপ করুন:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp কলামটি prompt processing speed এবং tg কলামটি token generation speed নির্দেশ করে; উভয়ের একক tokens per second। Shared vCPU plan-এ Q4_K_M-এ 8B model সাধারণত tg-এর জন্য প্রতি সেকেন্ডে খুব কম সংখ্যক token-এ সীমাবদ্ধ থাকে। Prompt processing-ই বেশি সময় নেয়। প্রথম output token আসার আগে সম্পূর্ণ prompt process করা হয়। তাই দীর্ঘ system prompt প্রতিটি request-এর আগে অপেক্ষার সময় বাড়ায়। Reply length হলো এমন ব্যয়ের অংশ, যেটি আপনি সরাসরি নিয়ন্ত্রণ করতে পারেন। প্রতি সেকেন্ডে 3 token গতিতে 600 token-এর দীর্ঘ উত্তর দিলে VPS 200 seconds ব্যস্ত থাকে। শুধু generation-এই 3 minutes-এর বেশি সময় লাগে। তাই num_predict দিয়ে output সীমিত করা একটি chatty উত্তরকে timeout-এ পরিণত হওয়া ঠেকানোর সবচেয়ে সস্তা উপায়।

CPU-তে ব্যবহারযোগ্য: classification, extraction, short summary বা routing-এর জন্য 1B থেকে 4B model। উত্তর কয়েক seconds-এর মধ্যে আসে এবং memory সাধারণ plan-এ ধরে। এই size range-এর বদলে একই আকারের একটি নির্দিষ্ট উদাহরণ দেখতে VPS-এ Nemotron 3.5 Lightning download ও পরিমাপ করুন। সেখানে exact tag, model-টি বাস্তবে যত RAM চায় এবং GPU ছাড়া যে speed ধরে—সবই দেওয়া আছে। CPU-তে ব্যবহারযোগ্য নয়: পড়ার গতিতে interactive chat, coding assistant, দীর্ঘ document নিয়ে কাজ, অথবা agent loop-সহ এমন কাজ যেখানে ধারাবাহিকভাবে অনেক call করা হয়। প্রতি call-এ 4 seconds ধরে 12টি call-এর loop কিছু output দেওয়ার আগেই 1 minute নেয়। পরিকল্পনায় coding assistant থাকলে নিজের host করা model-এর দিকে agent নির্দেশ করা দেখায়, ছোট local model কোন কাজ সত্যিই ভালো করে এবং কোন কাজ hosted API-তে রাখতেই হবে।

সংখ্যাগুলো কার্যকর না হলে দুটি বিকল্প আছে। সমস্যা যদি concurrency হয়—অর্থাৎ একই সময়ে অনেক user একটি model-এ request পাঠায়—তাহলে engine নির্বাচন গুরুত্বপূর্ণ হয়ে ওঠে। concurrent serving-এর জন্য Ollama ও vLLM-এর তুলনা এই বিষয়টি ব্যাখ্যা করে। সমস্যা যদি raw speed হয়, তাহলে উত্তর হলো সংযুক্ত GPU-সহ VPS। সেখানে -ngl-এর মান বাস্তব অর্থ পেতে শুরু করে। তবে তার আগে hardware-এর baseline নিন। কারণ CPU-এর মতো disk এবং memory bandwidth-ও load time-এ প্রভাব ফেলে। পুনরাবৃত্তিযোগ্য VPS benchmark চালাতে 1 hour ব্যয় করা সার্থক।

একটি নির্দিষ্ট build-এ pinned করে llama.cpp ইনস্টল করুন

উভয় project-এ প্রতি সপ্তাহে পরিবর্তন আসে। তাই আপনি যে version deploy করেছেন, সেটি নথিভুক্ত করুন। Upstream one-liner বর্তমান build ইনস্টল করে:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

নির্দিষ্ট build pin করতে releases page থেকে prebuilt tarball নিন। Project এখন semantic-versioned release-ও প্রকাশ করে: 27 October 2026-এ v0.7.0 সর্বশেষ ছিল এবং সেই release page binary-গুলোর জন্য nightly b11669-এ নির্দেশ করেছিল। 28 October 2026-এ v0.8.0 প্রকাশিত হয় এবং তার release page binary-গুলোর জন্য nightly b11960-এ নির্দেশ করে। নিচের command-গুলো 2 August 2026-এ বর্তমান tag b10224 ব্যবহার করে; আপনি পরীক্ষা করেছেন এমন tag দিয়ে এটি বদলান:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

অথবা source থেকে একই tag build করুন:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

HTTPS feature-গুলোর জন্য libssl-dev নথিভুক্ত dependency। Compile হতে কয়েক মিনিট লাগে এবং সবচেয়ে ছোট plan-গুলোর চেয়ে বেশি RAM প্রয়োজন। তাই বড় box-এ build করুন এবং ছোট box-এ RAM কম পড়লে binary-গুলো copy করুন।

একটি নির্দিষ্ট সংস্করণে Ollama ইনস্টল করুন

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

স্ক্রিপ্টটি OLLAMA_VERSION পড়ে। তাই আজ সকালে প্রকাশিত যেকোনো সংস্করণ নেওয়ার পরিবর্তে আপনি পরীক্ষিত নির্দিষ্ট release ব্যবহার করতে পারেন। v0.32.5 27 July 2026-এ প্রকাশিত হয়েছিল। আপনি যদি কোনো script shell-এ pipe করতে না চান, তবে manual পদ্ধতিও ব্যবহার করতে পারেন:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Manual পদ্ধতিটি systemd unit বা service user তৈরি করে না। তাই এগুলো আপনাকেই তৈরি করতে হবে। VPS-এ Ollama চালানোর সম্পূর্ণ নির্দেশিকা-তে service setup ধাপে ধাপে দেখানো হয়েছে।

ব্যর্থতার ধরন এবং যে বার্তাগুলো দেখবেন

Ollama মডেল লোড করতে অস্বীকার করে। পুরোনো Ollama release-গুলো লোড করার আগে আকার পরীক্ষা করত, এবং ollama run এই ধরনের একটি লাইন দেখাত:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

বর্তমান Ollama source-এ এই বার্তাটি আর নেই (27 October 2026 তারিখে পরীক্ষা করা হয়েছে)। এখন Ollama লোড করার কাজ llama-server-এর কাছে হস্তান্তর করে। তাই মডেলটি মেমরিতে না ধরলে runner failure হিসেবে দেখা যায়। ত্রুটিগুলো সাধারণত এভাবে শুরু হয়:

llama-server reported out-of-memory during startup
llama-server process has terminated

উভয় ক্ষেত্রেই সমাধান একই। একটি quantisation row নিচে যান, context length কমান, অথবা ছোট মডেল বেছে নিন।

llama.cpp ব্যর্থ হয় না, কিন্তু অত্যন্ত ধীর হয়ে যায়। llama.cpp ডিফল্টভাবে GGUF-কে memory-map করে। তাই RAM-এর চেয়ে বড় ফাইলও শুরু হতে পারে। এরপর kernel প্রতিটি token-এর সময় disk থেকে weights আনা-নেওয়া করে। ফলে প্রতি token তৈরি হতে কয়েক সেকেন্ড লাগে এবং disk usage 100 percent-এ স্থির থাকে। memory mapping বন্ধ করতে --load-mode none দিন। এই optionটি --no-mmap-এর পরিবর্তে এসেছে। pinned b10224 build-এ --no-mmap-কে deprecated হিসেবে উল্লেখ করা হয়েছে এবং বর্তমান build-গুলোতে এটি আর নেই (29 October 2026 তারিখে পরীক্ষা করা হয়েছে)। kernel হস্তক্ষেপ করলে dmesg কারণটি দেখায়:

Out of memory: Killed process 1234 (llama-server)

মডেল ফাইল একেবারেই লোড হয় না। আপনার engine-এর চেয়ে নতুন model family-এর জন্য তৈরি GGUF ব্যবহার করলে engine যে architecture চেনে না, তার নামসহ একটি error দেখায়। এখানে <arch> হলো ফাইলের metadata-তে সংরক্ষিত নাম:

llama_model_load: error loading model: unknown model architecture: '<arch>'

সমাধান হলো engine upgrade করা, অন্য ফাইল নেওয়া নয়। নির্দিষ্ট version-এ pin করে রাখার এটাই মূল্য। এ কারণেই build number লিখে রাখা হয়। কোন version থেকে upgrade করছেন তা জানা দরকার।

API স্থানীয়ভাবে উত্তর দেয়, কিন্তু আপনার app থেকে দেয় না। Ollama 127.0.0.1:11434-এ bind করে। তাই অন্য host থেকে connection refused পাওয়া যায়। systemctl edit ollama-এর মাধ্যমে OLLAMA_HOST=0.0.0.0:11434 সেট করুন কেবল তখনই, যখন portটি firewall বা private network-এর পেছনে থাকে। কারণ API-এর সামনে কোনো authentication নেই।

বিরতির পর প্রথম reply খুব ধীর হয়। 5 minute idle-এর পরে model unload হয়েছে এবং আবার লোড হচ্ছে। page cache-এ এটি না থাকলে disk থেকে লোড হবে। request পাঠানোর ঠিক আগে ollama ps চালালে কোনো model loaded নেই—এটি বিষয়টি নিশ্চিত করে। OLLAMA_KEEP_ALIVE-এর মান বাড়ান।

তাহলে কোনটি চালাবেন?

মডেল আপনার হয়ে পরিচালিত হোক এবং কোনো অতিরিক্ত কাজ ছাড়াই OpenAI-সদৃশ endpoint পান—এমনটি চাইলে Ollama চালান। প্রথম deployment-এর জন্য এটি উপযুক্ত default। মডেল নির্বাচন বারবার পরিবর্তিত হতে পারে—এমন ক্ষেত্রেও এটি ভালো পছন্দ।

যখন memory এত সীমিত যে নিজেকেই quantisation row নির্বাচন করতে হয়, monitoring-এর জন্য /health, /slots এবং /metrics প্রয়োজন হয়, অথবা Ollama যে flag প্রকাশ করে না সেটি দরকার হয়, তখন সরাসরি llama.cpp চালান। VPS-এ মডেলটি যখন খুব সামান্য memory margin-এ fit করে, তখন এটিই বাস্তবসম্মত পছন্দ। কারণ মডেলটি fit করানোর জন্য যে settings দরকার, Ollama সেগুলো আপনার হয়ে নির্বাচন করে।

দুটিই চালানো স্বাভাবিক। পরীক্ষার জন্য Ollama ব্যবহার করুন। আর production-এ রাখা নির্দিষ্ট একটি মডেলের জন্য llama.cpp ব্যবহার করুন, যাতে সেটি পরিবর্তিত না হয়।

FAQ

Ollama কি শুধু llama.cpp-এর একটি wrapper?

পুরোপুরি নয়, তবে wrapper-টি বাস্তবে গুরুত্বপূর্ণ কাজ করে। Ollama-এর README-তে llama.cpp-কে inference backend হিসেবে উল্লেখ করা হয়েছে (27 October 2026-এ পরীক্ষা করা হয়েছে)। এর ওপর Ollama একটি model registry, chat message-কে prompt-এ রূপান্তরকারী prompt template, default sampling parameter-এর একটি সেট, idle model unload করার সুবিধাসহ daemon এবং একটি HTTP API যোগ করে। একই settings-এ প্রতি সেকেন্ডে token-এর সংখ্যা তুলনা করলে আপনি একই engine-কে নিজের সঙ্গেই তুলনা করছেন। বাস্তবে আপনার পছন্দের বিষয় হলো management layer।

শুধু CPU-চালিত VPS-এ কোনটি দ্রুততর?

উভয়ই একই engine ব্যবহার করে। তাই একই model file, quantisation, context size এবং thread count হলে ফলাফল কাছাকাছি হবে। মানুষ যে পার্থক্যের কথা জানায়, তা সাধারণত engine-এর কারণে নয়; বরং ভিন্ন default, বিশেষ করে context length এবং thread count-এর কারণে হয়। নিজের server-এ llama-bench -m <file> -p 512 -n 128 ব্যবহার করে মাপুন এবং কোনো প্রকাশিত সংখ্যাকে বিশ্বাস করার আগে tg column তুলনা করুন।

আমি কি Ollama-তে নিজের GGUF file ব্যবহার করতে পারি?

হ্যাঁ। File-টি server-এ রাখুন। এমন একটি Modelfile লিখুন যার প্রথম line হলো FROM ./your-model.gguf। এরপর প্রয়োজনীয় PARAMETER line যোগ করুন, যেমন num_ctx। তারপর ollama create your-name -f ./Modelfile চালান। ollama ls registry থেকে pull করা অন্য file-এর পাশে এটিও দেখাবে। Registry-তে নেই এমন quantisation ব্যবহার করার এটাই পদ্ধতি।

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

File size, KV cache এবং runtime-এর জন্য আলাদা করে হিসাব করুন। Llama 3.1 8B-এর একটি Q4_K_M build disk-এ প্রায় 4.58 GiB জায়গা নেয়। 4096 token context-এর জন্য আরও প্রায় 512 MiB cache লাগে। তাই 8 GiB RAM স্বাচ্ছন্দ্যজনক, কিন্তু 4 GiB যথেষ্ট নয়। Cache-এর আকার context-এর সঙ্গে বাড়ে। একই model-কে 32,768 token context-এ চালালে শুধু cache-এর জন্যই প্রায় 4 GiB প্রয়োজন হয়। Ollama ব্যবহার করলে মনে রাখুন, এই প্রয়োজনীয়তাও OLLAMA_NUM_PARALLEL-এর সঙ্গে বাড়ে।