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 চালান। এতে exact model file, exact context size এবং exact thread count বেছে নিতে পারবেন। ছোট 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 সরবরাহ করে। llama-server হলো একটি HTTP server, llama-cli হলো একটি interactive prompt, এবং llama-bench throughput মাপে। Release-গুলো semantic version-এর পরিবর্তে build number দিয়ে tag করা হয়। বর্তমান 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-এ রাখা যায়। 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-তে রূপান্তর করা হয়েছে। একটি মডেলের 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-only 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 document-এর মাত্র অর্ধেক পড়ে একটি file সম্পর্কে আত্মবিশ্বাসের সঙ্গে ভুল উত্তর দিতে পারে। Daemon-এ OLLAMA_CONTEXT_LENGTH ব্যবহার করে এটি বাড়ান, অথবা Modelfile-এ PARAMETER num_ctx ব্যবহার করুন। llama.cpp-এর default-ও অন্ধভাবে নির্ভর করার মতো নয়। -c স্পষ্টভাবে সেট করুন এবং কী set করেছেন তা নিশ্চিতভাবে জানুন.

যে 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 করে সংরক্ষণ করা হয়। তাই প্রতি layer-এ হিসাবটি হলো 2 x 8 x 128 x 2 = 4096 byte। 32টি layer জুড়ে এটি প্রতি token-এ 128 KiB। 4096 token-এর context-এর জন্য তাই 512 MiB এবং 32,768 token-এর context-এর জন্য 4 GiB memory লাগে।

সুতরাং 4k context-এ একটি Q4_K_M 8B model-এর weights-এর জন্য আনুমানিক 4.58 GiB, cache-এর জন্য প্রায় 0.5 GiB এবং runtime-এর জন্য অতিরিক্ত memory দরকার। এটি 4 GiB RAM-এ চলবে না। কাজ করার মতো অতিরিক্ত memory-সহ 8 GiB RAM-এ এটি চলবে। একই 8 GiB-এর system-এ context 32k করলে শুধু cache-ই অবশিষ্ট headroom ব্যবহার করে ফেলবে। Model loaded থাকা অবস্থায় free -h দিয়ে memory usage সরাসরি monitor করুন। যে estimate মেপে নিশ্চিত করা হয়নি, সেটির ওপর নির্ভর করবেন না।

Ollama এই প্রভাব আরও বাড়ায়। OLLAMA_NUM_PARALLEL-এর default মান 1। Model-এর প্রয়োজনীয় memory এই মান এবং context length-এর গুণফল অনুযায়ী বাড়ে। দুটিই একসঙ্গে বাড়ালে daemon নীরবে আপনার প্রত্যাশার তুলনায় কয়েক গুণ বেশি RAM চেয়ে বসে।

অক্ষ 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

OLLAMA_KEEP_ALIVE CPU VPS-এ অন্য যেকোনো পরিবেশের তুলনায় বেশি গুরুত্বপূর্ণ। ডিফল্টভাবে model 5 মিনিট memory-তে রাখা হয়, তারপর unload করা হয়। পরের request-এর উত্তর দেওয়ার আগে পুরো file-টি disk থেকে আবার পড়তে হয়। তাই ধীর storage-এ 4.58 GiB reload-এর কারণে দুই সেকেন্ডের reply ত্রিশ সেকেন্ডে পৌঁছাতে পারে। দীর্ঘ 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 দিয়ে এটি enable করুন। এরপর process তার সম্পূর্ণ lifetime জুড়ে model ধরে রাখে। idle অবস্থায় কিছু unload হয় না। ফলে reload-এর অপ্রত্যাশিত বিলম্ব থাকে না, তবে service বন্ধ করা ছাড়া memory পুনরুদ্ধারের কোনো উপায়ও থাকে না। unit লেখা আপনার জন্য নতুন হলে, এটি VPS-এ systemd-এর অধীনে নিজের service চালানোর একই পদ্ধতি।

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

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

Ollama 127.0.0.1:11434-এ listening করে। এর 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-এ listening করে এবং /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 loopback-এ থাকে। SSH tunnel-এর মাধ্যমে অথবা reverse proxy-এর পেছন থেকে এগুলোতে সংযোগ করুন। কখনো 11434 বা 8080 Internet-এ উন্মুক্ত করবেন না।

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

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

CPU-তে ব্যবহারযোগ্য: classification, extraction, short summary বা routing-এর জন্য 1B থেকে 4B model। Reply কয়েক সেকেন্ডে আসে এবং memory সাধারণ plan-এ যথেষ্ট থাকে। CPU-তে ব্যবহার অনুপযোগী: reading speed-এ interactive chat, coding assistant, দীর্ঘ document নিয়ে কাজ, অথবা agent loop-যুক্ত যেকোনো কাজ যেখানে ধারাবাহিকভাবে অনেক call করা হয়। একটি loop যদি প্রতিটি 4 সেকেন্ডে 12টি call করে, তাহলে কোনো output দেওয়ার আগেই 1 মিনিট লাগে।

সংখ্যাগুলো কার্যকর না হলে দুটি বিকল্প থাকে। সমস্যা যদি 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 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 প্রয়োজন হয়। তাই বড় server-এ build করুন। ছোট server-এ 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-এ প্রকাশিত হয়েছে। স্ক্রিপ্টটি 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-এর চেয়ে বড় ফাইলও চালু হতে পারে। এরপর প্রতিটি token-এর সময় kernel disk থেকে weights বারবার memory-তে আনে এবং memory-র বাইরে সরিয়ে দেয়। ফলে generation প্রতি token-এ কয়েক সেকেন্ড সময় নেয় এবং disk usage 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 লোকালভাবে উত্তর দেয়, কিন্তু আপনার 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 নেই।

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

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

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

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

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

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 যোগ করে। একই 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—এই তিনটির জন্য 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 ব্যবহার করলে মনে রাখুন, প্রয়োজনীয় RAM OLLAMA_NUM_PARALLEL-এর সঙ্গেও বাড়ে।