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

সর্বোচ্চ tokens/second আর পূর্ণ নিয়ন্ত্রণ চাইলে কাঁচা llama.cpp; এক-কমান্ডের ইনস্টল আর খোলামাত্র কাজ করা API সার্ভার চাইলে Ollama। Ollama আসলে প্রতিদ্বন্দ্বী ইঞ্জিন নয় — এটি একটা Go সার্ভিস, যা llama.cpp-কে ইনফারেন্স ব্যাকএন্ড হিসেবে বান্ডল করে, মডেল ম্যানেজমেন্ট যোগ করে (ollama pull llama3.1) আর পোর্ট 11434-এ REST API সার্ভ করে। তাই আসল প্রশ্ন “কোন ইঞ্জিন দ্রুত” নয়, “ওই ইঞ্জিনের ডায়ালের ওপর কতটা নিয়ন্ত্রণ চান”। Ollama সংরক্ষণশীল ডিফল্ট পাঠায় (Q4_K_M কোয়ান্টাইজেশন, মাপজোখ context, সম্প্রতি পর্যন্ত flash attention নেই), তাই একই হার্ডওয়্যারে সংখ্যাগুলো চোখে-লাগা ভাবে আলাদা হতে পারে। নিচে: আসলে কী আলাদা, গতির ফাঁক কোথা থেকে আসে, একই মডেল দুই জায়গায় চালানো, আর একটা সিদ্ধান্ত টেবিল।

llama.cpp আর Ollama-র পার্থক্য কী?

llama.cpp হলো ইনফারেন্স ইঞ্জিন: GGUF-এর স্রষ্টা Georgi Gerganov-র একটাই C/C++ প্রজেক্ট, যা quantised মডেল CPU, GPU বা দুটোর মিশ্রণে চালায়। দেয় llama-cli — এক-বারের প্রম্পটের জন্য — আর llama-server, একটা OpenAI-কম্প্যাটিবল HTTP সার্ভার, সাথে ইঞ্জিনের সমর্থিত প্রতিটা টিউনিং ফ্ল্যাগ: GPU লেয়ার অফলোড, KV-cache quantization, speculative decoding, কাস্টম স্যাম্পলার।

Ollama হলো সেই ইঞ্জিনের ওপর বসানো একটা প্রোডাক্ট। এটি llama.cpp fork করে ভেতরে ঢুকিয়ে রাখে, তারপর জড়িয়ে দেয়:

• একটা মডেল রেজিস্ট্রি (ollama pull, ollama list) — স্বয়ংক্রিয় GGUF weight ভাগ করার ব্যবস্থাসহ,
• একটা Modelfile ব্যবস্থা (প্রম্পট টেমপ্লেট ও প্যারামিটারের Dockerfile-ঘেঁষা স্পেক),
• একটা ব্যাকগ্রাউন্ড ডেমন, যা মডেলকে VRAM-এ গরম রাখে আর নিজের REST API দেয়,
• নিরাপদ ডিফল্টসহ স্বয়ংক্রিয় হার্ডওয়্যার শনাক্তকরণ।

বাস্তব ফল: Ollama দিয়ে আপনি সামলান মডেল; llama.cpp দিয়ে সামলান ইনফারেন্স। কখনো কখনো যদি quantization ফরম্যাট বদলাতে, KV cache quantize করতে, context ডিফল্টের বাইরে নিতে, বা নির্দিষ্ট লেয়ার GPU-তে পিন করতে ইচ্ছে করে — সেটা llama.cpp-র ভূখণ্ড। Ollama বেশিরভাগ ডায়াল লুকিয়ে রাখে — ইচ্ছা করেই।

	llama.cpp	Ollama
এটা কী	ইনফারেন্স ইঞ্জিন (C/C++)	llama.cpp-কে মুড়ে রাখা সার্ভিস
ইনস্টল	সোর্স থেকে বিল্ড বা প্যাকেজ	এক-লাইনের ইনস্টলার, এক বাইনারি
মডেল চালানো	llama-cli -m model.gguf + ফ্ল্যাগ	ollama run llama3.1
API	OpenAI-কম্প্যাটিবল (llama-server)	নিজস্ব REST + OpenAI-কম্প্যাটিবল এন্ডপয়েন্ট
মডেল ম্যানেজমেন্ট	GGUF ফাইল নিজে আনতে হয়	রেজিস্ট্রি: pull/list/rm
ডিফল্ট	সব আপনি বাছেন	নিরাপদ: Q4_K_M, মাপজোখ context
ইঞ্জিন আপডেট	প্রথম দিনেই (upstream)	Upstream release-এর পেছনে থাকে
টিউনিং গভীরতা	পূর্ণ (KV quant, spec decode, স্যাম্পলার)	সীমিত passthrough
সবচেয়ে ভালো যেখানে	পারফরম্যান্স কাজ, সার্ভার, এজ ডিভাইস	শুরু করা, ডেভ ল্যাপটপ

llama.cpp কি Ollama-র চেয়ে দ্রুত?

একই GGUF ফাইল, একই quantization, একই context, একই llama.cpp ভার্সনে — না, দুটো গোলমালের মধ্যে সমান, কারণ হিসাবটা করে Ollama-র ভেতরের llama.cpp-ই। “Ollama 30% ধীর” — আপনি যেসব বেঞ্চমার্ক দেখেন, সেগুলো আসলে ডিফল্টের তুলনা। ফাঁকটা তিন জায়গা থেকে আসে:

1. Quantization পছন্দ। Ollama-র রেজিস্ট্রি ডিফল্ট দেয় Q4_K_M। একই মডেল llama.cpp থেকে Q5_K_M বা Q6_K হিসেবে চালান — একই ঘরের গতিতে ভালো কোয়ালিটি; কাঁচা গতি চাইলে Q4_0/IQ4 নিন।
2. Flash attention আর KV-cache quantization। --flash-attn প্লাস -ctk q8_0 -ctv q8_0 KV cache প্রচণ্ড ছোট করে, যা লম্বা context-এ tokens/second বাড়ায় আর একই VRAM-এ বড় context ঢোকায়। Ollama এর কিছু অংশই ঢেকে দেয়।
3. ভার্সনের দূরত্ব। llama.cpp-তে কার্নেল অপ্টিমাইজেশন সাপ্তাহে আসে; Ollama upstream merge করে নিজের সময়সূচিতে। একই বক্সে টাটকা llama.cpp বিল্ড মাস-পুরোনো Ollama বাইনারিকে মাপা-যায় এমন ভাবে হারাতে পারে — Ollama ধরে ফেলা পর্যন্ত।

দ্রুত বেঞ্চমার্ক কমান্ড, ইঞ্জিন-নিরপেক্ষ — প্রম্পট ইভালুয়েশন ও জেনারেশন গতি দুটোই জানায়:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Ollama-র নিজের মডেল ফাইলেই চালান (~/.ollama/models/blobs/..., .gguf নামে রূপান্তর করে) — সাধারণত Ollama-র সংখ্যার সাথে হুবহু মিলবে — তারপর 16k context-এ -ctk q8_0 যোগ করে ছাড়িয়ে যান।

একই মডেল দুই জায়গায় কীভাবে চালাব?

দুটোই GGUF খায়। প্রতিটির ন্যূনতম এন্ড-টু-এন্ড:

# --- Ollama পথ: ইনস্টল, পুল, সার্ভ ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # Q4_K_M নামায়, VRAM-এ লোড করে, চ্যাট খোলে

# এর API, OpenAI-কম্প্যাটিবল ধাঁচে:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cpp পথ: বিল্ড, GGUF নামান, সার্ভ ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # অথবা -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server OpenAI Chat Completions স্কিমা মেনে চলে, তাই http://localhost:8080/v1/chat/completions-এ সেই একই curl হুবহু চলে। OpenAI API-র জন্য বানানো যেকোনো টুল — স্ক্রিপ্ট, এডিটর, RAG পাইপলাইন — দুই দিকেই তাক করানো যায়। আসল কাজ ফ্ল্যাগগুলোই করে: -ngl 99 প্রতিটা লেয়ার GPU-তে পাঠায়, --flash-attn আর -ctk/-ctv জুটি 8 GB কার্ডেও 16k context রেখে দেয় — যেখানে Ollama-র ডিফল্ট ভেতরে ঢুকতেই রাজি হয় না।

GGUF ফাইল বাছাই আর quant লেবেলের মানে জানতে দেখুন GGUF মডেল লোকালি চালানোর গাইড।

Ollama কবে বেশি যুক্তিসঙ্গত?

বেশিরভাগ মানুষ Ollama দিয়েই শুরু করা উচিত, আর সেটা কোনো সান্ত্বনা-পুরস্কার নয়:

• আজ রাতেই কাজে লাগাতে চান। এক কমান্ড, মডেল পুলড, API চালু। llama.cpp মানে ব্যাকএন্ড বাছা (CUDA/Vulkan/HIP/Metal), বিল্ড, আর হাতে weights আনা।
• অনেক মডেল ম্যানেজ করেন। রেজিস্ট্রি, স্বয়ংক্রিয় আনলোড আর Modelfile GGUF-ফাইলের ডিরেক্টরি হাতে গেঁথে ম্যানেজ করার চেয়ে ভালো।
• মেশিনটা মামুলি। Ollama-র ডিফল্ট সংরক্ষণশীল, কারণ সেটাই দরকার — প্রায় সবসময়ই ঢোকে আর চলে।
• স্থিতিশীল API-পৃষ্ঠ চান। Ollama-র ডেমন মডেলের জীবনচক্র সামলায়, তাই দীর্ঘদিন চলা সার্ভিসকে নিজে করতে হয় না।

কাঁচা llama.cpp বাছুন যখন বেঞ্চমার্ক করছেন, যেকোনো মাপে সার্ভ করছেন, ফোন বা Raspberry Pi-তে চালাচ্ছেন, ছোট VRAM-এ লম্বা context দরকার, বা upstream-এ merge হওয়া মাত্রই কোনো ফিচার লাগবে। পাওয়ার ইউজাররা প্রায়ই দুটোই চালান: রোজকার মডেলে Ollama, আর যে এক কাজে শেষ 20%-টা লাগে সেজন্য পিন করা একটা llama.cpp বিল্ড।

তুলনাটা আসলে ডেস্কটপ GUI অ্যাপের মধ্যে সীমাবদ্ধ হলে সেটা আলাদা অক্ষ — দেখুন Ollama vs LM Studio — আর প্রতি কাজে ইঞ্জিন-পছন্দের মডেল-দিকটা কভার করে কোডিংয়ের সেরা লোকাল LLM।

কোনটি ব্যবহার করবেন?

গতিতে নয়, নিয়ন্ত্রণে সিদ্ধান্ত নিন। ইঞ্জিন একই; ডিফল্ট নয়। “চলে আর API দেয়” — এটাই লক্ষ্য হলে Ollama ইনস্টল করুন — কয়েকটা ডায়াল হারাবেন, যেগুলোতে তবু হাত দেওয়াতেন। tokens/second, context দৈর্ঘ্য বা quantization নিয়ন্ত্রণই লক্ষ্য হলে llama.cpp বিল্ড করুন — প্রতিটা ডায়াল পাবেন, দাম হলো মডেল নিজে সামলানো। যেকোনো পথেই চালাচ্ছেন একই GGUF ফাইল, আর পরে দল বদলানোর খরচ একটা বিকেল, রিরাইট নয়।