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 সীমিত হলে সরাসরি llama.cpp চালান এবং নির্দিষ্ট model file, নির্দিষ্ট context size ও নির্দিষ্ট thread count বেছে নিন। কারণ ছোট VPS-এ এসব প্রতিটি setting-এর জন্য এমন memory প্রয়োজন হয়, যা আপনার কাছে নাও থাকতে পারে।

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

llama.cpp হলো ggml লাইব্রেরির ওপর তৈরি transformer inference-এর C এবং C++ implementation। এটি GGUF ফাইল পড়ে। GGUF (GGML universal file format) হলো একটি single-file container, যাতে model চালানোর জন্য engine-এর প্রয়োজনীয় weights, tokeniser এবং metadata থাকে। প্রকল্পটি আলাদা কাজের জন্য আলাদা binary প্রকাশ করে। llama-server হলো একটি HTTP server, llama-cli হলো একটি interactive prompt, এবং llama-bench throughput মাপে। Release-গুলোর tag 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-এর অধীনে সংরক্ষণ করে।

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

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

Quantisation প্রতিটি weight-এর আকার 16 বা 32 bit থেকে 4, 5 বা 8 bit-এ কমিয়ে দেয়। এর ফলেই 8 billion parameter-এর মডেল সাধারণ VPS-এর RAM-এ চালানো সম্ভব হয়। প্যাটার্নটি জানা থাকলে 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-এ রূপান্তর করা হয়েছে। একটি মডেলের 6টি build আছে, এবং সবচেয়ে ছোটটির আকার 2.96 GiB, যেখানে সবচেয়ে বড়টির আকার 7.95 GiB। প্রচলিত default, Q4_K_M, এর আকার 4.58 GiB। 4 GiB VPS-এ এই একটিমাত্র নির্বাচনই ঠিক করে দেয় মডেলটি আদৌ load হবে কি না।

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)। কোনো কিছু আপনার হয়ে অনুমান করা হয় না।

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 না থাকা machine সবচেয়ে ছোট bucket-এ পড়ে: 4096 tokens। সেখানে 20,000 token-এর document পাঠালে model সেটি দেখার আগেই অতিরিক্ত token বাদ পড়ে। ফলে model file-টির মাত্র অর্ধেক পড়ে উত্তর দেয় এবং উত্তরটি আত্মবিশ্বাসী হলেও ভুল হয়। daemon-এ OLLAMA_CONTEXT_LENGTH ব্যবহার করে, অথবা Modelfile-এ PARAMETER num_ctx ব্যবহার করে এটি বাড়ান। 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 byte করে সংরক্ষণ করে, তাই 2 x 8 x 128 x 2 = 4096 byte প্রতি layer। 32টি layer মিলিয়ে প্রতি token-এ 128 KiB লাগে। 4096 token-এর context-এর জন্য 512 MiB এবং 32,768 token-এর context-এর জন্য 4 GiB লাগে।

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

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

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

Ollama-এর install script একটি systemd unit লেখে, একটি ollama system user তৈরি করে এবং service সক্রিয় করে। আপনাকে নিজে এসবের কোনোটি লিখতে হয় না। 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-এর কারণে দুই সেকেন্ডের উত্তর দিতে ত্রিশ সেকেন্ড লাগতে পারে। দীর্ঘ keep-alive latency কমায়, তবে RAM স্থায়ীভাবে ব্যবহার করে। দুটিই বাস্তব খরচ। যেটি কম সমস্যা তৈরি করে, সেটি বেছে নিন।

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 দিয়ে এটি সক্রিয় করুন। এরপর process-টি তার পুরো lifetime জুড়ে model ধরে রাখে। idle অবস্থায় কিছু unload হয় না। ফলে reload-এর অনাকাঙ্ক্ষিত বিলম্ব থাকে না, তবে service বন্ধ না করা পর্যন্ত 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-এর document-ও আছে।

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 সরবরাহ করে। এর নিজস্ব /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 bind address 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-এ Q4_K_M quantization-সহ 8B model সাধারণত tg-এর জন্য খুব কম single-digit মান দেয়। Prompt processing-ই প্রধান সমস্যা। প্রথম output token আসার আগে পুরো prompt প্রক্রিয়া করতে হয়। তাই দীর্ঘ system prompt প্রতিটি request-এর আগে অপেক্ষার সময় বাড়ায়।

CPU-তে ব্যবহারযোগ্য: classification, extraction, short summary বা routing-এর জন্য 1B থেকে 4B model। Reply কয়েক সেকেন্ডে আসে এবং memory সাধারণ plan-এর মধ্যে থাকে। CPU-তে ব্যবহারযোগ্য নয়: পড়ার গতির সঙ্গে তাল মিলিয়ে interactive chat, coding assistant, দীর্ঘ document নিয়ে কাজ, অথবা পরপর অনেক call করা agent loop। একটি loop প্রতি call-এ চার সেকেন্ড নিয়ে 12টি 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 চালাতে এক ঘণ্টা ব্যয় করা সার্থক।

llama.cpp ইনস্টল করুন এবং একটি নির্দিষ্ট build-এ স্থির রাখুন

উভয় 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-এ স্থির রাখতে 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 প্রয়োজন। তাই বড় server-এ build করুন। ছোট server-এ পর্যাপ্ত RAM না থাকলে binary-গুলো copy করুন।

একটি নির্দিষ্ট version-এ Ollama ইনস্টল করুন

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

স্ক্রিপ্টটি OLLAMA_VERSION পড়ে। তাই আজ প্রকাশিত যেকোনো release নেওয়ার পরিবর্তে পরীক্ষিত একটি 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 row নিচে যান, context length কমান, অথবা ছোট মডেল বেছে নিন।

llama.cpp ব্যর্থ হয় না, ধীরে ধীরে কাজ করে। llama.cpp ডিফল্টভাবে GGUF-কে memory-map করে। তাই RAM-এর চেয়ে বড় ফাইলও শুরু হয়। এরপর kernel প্রতিটি token-এর সময় disk থেকে weights বারবার page in এবং page out করে। ফলে generation প্রতি token-এ কয়েক সেকেন্ডে নেমে আসে এবং disk 100 percent ব্যবহারে আটকে থাকে। প্রকৃত 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 local-ভাবে উত্তর দেয়, কিন্তু আপনার app থেকে দেয় না। Ollama 127.0.0.1:11434-এ bind করে। তাই অন্য host connection refused পায়। OLLAMA_HOST=0.0.0.0:11434-এর মাধ্যমে systemctl edit ollama সেট করুন কেবল তখনই, যখন port-টি firewall বা private network-এর আড়ালে থাকে। কারণ API-এর সামনে কোনো authentication নেই।

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

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

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

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

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

FAQ

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

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

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

তারা একই engine ব্যবহার করে। তাই একই model file, quantisation, context size এবং thread count থাকলে ফলাফল কাছাকাছি হয়। মানুষ যে পার্থক্যের কথা জানায়, তা সাধারণত engine থেকে নয়; বরং ভিন্ন default, বিশেষ করে context length এবং thread count থেকে আসে। llama-bench -m <file> -p 512 -n 128 দিয়ে মাপুন এবং প্রকাশিত কোনো ফলাফল বিশ্বাস করার আগে নিজের server-এ 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 করা যেকোনো model-এর পাশে 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 যথেষ্ট নয়। Cache-এর আকার context-এর সঙ্গে বাড়ে। একই model-কে 32,768 token context-এ চালালে শুধু cache-এর জন্যই প্রায় 4 GiB লাগে। Ollama ব্যবহার করলে মনে রাখবেন, OLLAMA_NUM_PARALLEL-এর সঙ্গেও প্রয়োজনীয় resource বাড়ে।