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

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 হিসেবে উল্লেখ করা আছে (2 August 2026 তারিখে পরীক্ষা করা হয়েছে)। তাই আসল প্রশ্ন হলো, আপনার VPS-এ কোন স্তরটি পরিচালনা করতে চান; কোনটি দ্রুততর, তা নয়।

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

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

llama.cpp হলো ggml library-এর ওপর তৈরি transformer inference-এর C ও C++ implementation। এটি GGUF file পড়ে। GGUF (GGML universal file format) হলো একটি single-file container, যাতে model চালানোর জন্য engine-এর প্রয়োজনীয় weights, tokeniser এবং metadata থাকে। প্রকল্পটি আলাদা কাজের জন্য আলাদা binary release করে। llama-server হলো একটি HTTP server, llama-cli হলো একটি interactive prompt, এবং llama-bench throughput মাপে। Release-গুলো semantic version-এর পরিবর্তে build number দিয়ে চিহ্নিত করা হয়। বর্তমান tag হলো b10224, যা 2 August 2026-এ প্রকাশিত হয়েছে, এবং বেশিরভাগ কর্মদিবসে একটি নতুন tag প্রকাশিত হয়।

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-এ প্রকাশিত হয়েছে। ollama pull একটি GGUF-এর সঙ্গে prompt template এবং default parameter-এর একটি সেট download করে, তারপর Linux-এ সেটিকে /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 দেয়।

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

Quantisation প্রতিটি weight-কে 16 বা 32 bit থেকে 4, 5 বা 8 bit-এ ছোট করে। এর ফলে 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-এ নেওয়া এবং bytes থেকে GiB-তে রূপান্তর করা হয়েছে। একটি model-এর 6টি build আছে। সবচেয়ে ছোটটির size 2.96 GiB, আর সবচেয়ে বড়টির size 7.95 GiB। প্রচলিত default Q4_K_M-এর size 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 থাকা box-এ 0)। কোনো কিছু আপনাকে না জানিয়ে অনুমান করা হয় না।

Ollama-তে আপনি যে tag pull করেন, তার সঙ্গে quantisation যুক্ত থাকে। ollama ls ব্যবহার করে disk-এ বাস্তবে কী আছে তা দেখুন। 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 না থাকা box সবচেয়ে ছোট bucket-এ পড়ে: 4096 tokens। এতে 20,000 token-এর document পাঠালে model সেটি দেখার আগেই অতিরিক্ত token বাদ পড়ে। ফলে model যে 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 করে। আপনাকে নিজে lifecycle management লিখতে হয় না। 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-টি disk থেকে আবার পড়তে হয়। তাই ধীর storage-এ 4.58 GiB reload হলে দুই সেকেন্ডের reply ত্রিশ সেকেন্ডে পৌঁছে যেতে পারে। দীর্ঘ keep-alive latency কমায়, কিন্তু RAM স্থায়ীভাবে ব্যবহার করে। দুটিই বাস্তব খরচ। যে বিকল্পে কম অসুবিধা হয়, সেটি বেছে নিন। Model-টি যদি সব সময় memory-তে রাখতে চান, keep_alive সেট করে idle period এবং reboot-এর পরেও model চালু রাখা কয়েকটি line-এই করা যায়। এতে প্রতিবার server restart হলে আপনাকে হাতে model warm করতে হয় না।

llama.cpp কোনো daemon দেয় না। তাই /etc/systemd/system/llama-server.service হিসেবে unit নিজেকেই লিখতে হবে:

[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 হয় না। ফলে reload-এর অপ্রত্যাশিত delay থাকে না, কিন্তু service stop না করা পর্যন্ত memory পুনরুদ্ধার করার কোনো উপায়ও থাকে না। Unit লেখা আপনার জন্য নতুন হলে, এটি VPS-এ systemd-এর অধীনে নিজস্ব service চালানোর একই pattern।

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

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

Ollama 127.0.0.1:11434-এ listen করে। এর OpenAI-compatible route হলো http://localhost:11434/v1/chat/completions, এবং পাশাপাশি এটি /api/chat-এ একটি native API-ও রাখে। Anthropic-compatible route-ও documented আছে।

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"}]}'

llama-server 127.0.0.1:8080-এ listen করে এবং /v1/chat/completions, /v1/completions ও /v1/embeddings serve করে। এর নিজস্ব /completion endpoint এবং built-in web UI-ও আছে। এটি এমন operational route-ও প্রকাশ করে, যা Ollama-তে নেই: readiness probe-এর জন্য /health, loaded model-এর settings-এর জন্য /props, প্রতিটি request slot কী করছে তা দেখার জন্য /slots, এবং Prometheus format-এ metrics-এর জন্য /metrics। আপনি যদি এই service monitor করার পরিকল্পনা করেন, তাহলে সম্ভবত এই পার্থক্যই সিদ্ধান্ত নির্ধারণ করবে।

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

CPU-only VPS বাস্তবে কী করতে পারে

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

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

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

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

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

একটি নির্দিষ্ট build-এ 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 নিন। 2 August 2026 অনুযায়ী build 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 প্রয়োজন হয়। তাই বড় machine-এ build করুন। ছোট machine-এ পর্যাপ্ত 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 run এই ধরনের একটি লাইন ফেরত দেয়:

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

লোড করার আগে Ollama মডেলের আকার পরীক্ষা করে। তাই এটি দ্রুত ব্যর্থ হয় এবং কারণ জানায়। quantisation-এর তালিকায় নিচের সারিতে যান, context length কমান, অথবা ছোট মডেল বেছে নিন।

llama.cpp ব্যর্থ হয় না, ধীরগতিতে চলে। llama.cpp ডিফল্টভাবে GGUF-কে memory-map করে। তাই RAM-এর চেয়ে বড় ফাইলও চালু হতে পারে। এরপর kernel প্রতিটি token-এর সময় disk থেকে weights বারবার পড়ে এবং disk 100 percent ব্যবহৃত থাকায় generation প্রতি token-এ কয়েক সেকেন্ডে নেমে আসে। প্রকৃত allocation বাধ্যতামূলক করতে --no-mmap দিন। এতে ধীরগতিতে চলার বদলে সঙ্গে সঙ্গে ব্যর্থ হবে। kernel হস্তক্ষেপ করলে dmesg কারণটি দেখায়:

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

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

error loading model architecture: unknown model architecture: 'qwen3next'

সমাধান হলো engine upgrade করা, অন্য ফাইল নেওয়া নয়। pinning-এর জন্য এটিই মূল্য দিতে হয়। তাই build number লিখে রাখা জরুরি। কোন সংস্করণ থেকে 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 হয়েছে এবং আবার disk থেকে পড়া হচ্ছে। request পাঠানোর ঠিক আগে ollama ps চালালে কিছু 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-টি বাস্তব কাজও করে। 2 August 2026 তারিখে যাচাই করা Ollama-এর README-তে llama.cpp-কে inference backend হিসেবে উল্লেখ করা হয়েছে। এর ওপর Ollama একটি model registry, chat message-কে prompt-এ রূপান্তরকারী prompt template, কিছু default sampling parameter, idle unloading-সহ একটি daemon এবং একটি HTTP API যোগ করে। একই setting-এ প্রতি সেকেন্ডে 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—সবগুলোর জন্য RAM ধরুন। Llama 3.1 8B-এর একটি Q4_K_M build disk-এ প্রায় 4.58 GiB জায়গা নেয়। 4096 token context-এ আরও প্রায় 512 MiB cache লাগে। তাই 8 GiB RAM স্বাচ্ছন্দ্যজনক, কিন্তু 4 GiB যথেষ্ট নয়। Context বাড়লে cache-ও বাড়ে। একই model 32,768 token context-এ একাই প্রায় 4 GiB cache ব্যবহার করে। Ollama-এর ক্ষেত্রে মনে রাখুন, এই প্রয়োজনীয়তা OLLAMA_NUM_PARALLEL-এর সঙ্গেও বাড়ে।