Ollama বনাম vLLM: কোন LLM server চালাবেন?

Ollama বনাম vLLM, এক অনুচ্ছেদে

Ollama হলো সংযুক্ত server-সহ একটি model manager: এটি quantized weights download করে, সেগুলো load করে এবং 127.0.0.1:11434-এ উত্তর দেয়; machine-এ শুধু CPU থাকলেও এটি CPU ব্যবহার করে। vLLM হলো throughput engine: এটি একই সময়ে চলা অনেক request-এর মাধ্যমে GPU-কে পূর্ণ সক্ষমতায় ব্যবহার করে, তাই GPU-হীন machine-এ এটি উপযুক্ত নয়। সিদ্ধান্তটি এতটুকুই। একজন ব্যক্তি local assistant-এর সঙ্গে কথা বললে সেটি Ollama-এর কাজ। একটি application কোনো team-এর জন্য service দিলে সেটি vLLM-এর কাজ।

উভয়ই OpenAI-compatible HTTP API ব্যবহার করে। তাই base URL পরিবর্তন করলেই client code একটির থেকে অন্যটিতে নেওয়া যায়। API তাদের পার্থক্য নয়। পার্থক্য হলো, প্রথম request এখনও token generate করার সময় দ্বিতীয় request এলে কী ঘটে।

Ollama আসলে কী

Ollama একটি সুবিধা-স্তর। একটি ইনস্টল কমান্ডের মাধ্যমে এটি আপনাকে একটি মডেল রেজিস্ট্রি (ollama pull llama3.1:8b), ওজন সংরক্ষণের জন্য একটি স্থানীয় স্টোর, একটি চ্যাট প্রম্পট, একটি systemd সার্ভিস এবং একটি HTTP API দেয়। এটি যে মডেল পরিবেশন করে, সেগুলো GGUF ফাইল। এগুলো সাধারণত 4-bit quantized হয়। তাই 7B বা 8B মডেল ডিস্কে 16 GB-এর পরিবর্তে প্রায় 5 GB জায়গা নেয়। Quantization-এর কারণেই CPU-তে inference চালানো সম্ভব হয়।

এর runner llama.cpp-এর ওপর তৈরি। llama.cpp হলো C++ inference library, যা সাধারণ হার্ডওয়্যারে GGUF quantization ব্যবহারিক করে তুলেছে। পরে Ollama কিছু নতুন model family-এর জন্য নিজস্ব engine যোগ করেছে। তবে এটি যে অধিকাংশ মডেল পরিবেশন করে, তার অন্তর্নিহিত ভিত্তি এখনও llama.cpp। তাই Ollama এবং llama.cpp তুলনা করার সময় মূলত একটি ergonomics layer-এর সঙ্গে সেটি যে উপাদানকে wrap করে, তার তুলনা করা হয়।

এর নকশার লক্ষ্য একজন ব্যবহারকারী। July 2026 অনুযায়ী OLLAMA_NUM_PARALLEL-এর ডিফল্ট মান 1। এর অর্থ, একটি মডেল এক সময়ে একটি request প্রক্রিয়া করে এবং বাকি সব request একটি queue-তে অপেক্ষা করে। সেই queue-তে ডিফল্টভাবে 512টি entry রাখা যায় (OLLAMA_MAX_QUEUE)। আপনি parallel setting-এর মান বাড়াতে পারেন। নিচের বিভাগে এর জন্য কী খরচ হয় তা ব্যাখ্যা করা হয়েছে। আপনি আগে Ollama চালিয়ে না থাকলে VPS-এ Ollama host করা এবং port 11434 বন্ধ রাখা দিয়ে শুরু করুন। কারণ API-তে কোনো ধরনের authentication নেই।

vLLM আসলে কী

vLLM একটি inference server, এর বাইরে আর কিছু নয়। এটি model library পরিচালনা করে না, এতে কোনো chat prompt নেই, এবং request চলাকালীন এটি আপনার জন্য কোনো model ডাউনলোড করবে না। চালুর সময় আপনি একটি Hugging Face repository নির্দিষ্ট করেন। এটি সেই একটি model লোড করে এবং আপনি process বন্ধ না করা পর্যন্ত সেটি পরিবেশন করে।

এই সীমাবদ্ধতার বিনিময়ে আপনি পান উচ্চ throughput। এর পেছনে দুটি প্রক্রিয়া কাজ করে। PagedAttention KV cache (key-value cache; প্রতিটি সক্রিয় request-এর জন্য model যে প্রতি-token attention state সংরক্ষণ করে) fixed-size block-এ রাখে, যেভাবে operating system memory-কে page করে। ফলে কোনো request-কে worst case অনুযায়ী আকার নির্ধারিত একটি বড় contiguous reservation নিতে হয় না। আগে reserved কিন্তু অব্যবহৃত থাকা memory এখন আরও বেশি concurrent request-এর জন্য ব্যবহার করা যায়। Continuous batching নতুন request-কে বর্তমান batch শেষ হওয়ার অপেক্ষা না করিয়ে পরবর্তী decoding step-এ চলমান batch-এ যোগ করতে দেয়। কোনো sequence শেষ হলে সেটি সঙ্গে সঙ্গে batch ছেড়ে যায় এবং তার slot পুনরায় পূরণ হয়।

বাস্তব ফলাফল হলো: একটি GPU-তে concurrent user-এর সংখ্যা 1 থেকে 30 করলে মোট tokens per second দ্রুত বাড়ে, অথচ প্রতি user-এর speed আপনার প্রত্যাশার তুলনায় অনেক কম হারে কমে। Ollama-র default ব্যবহারে user-এর সংখ্যা 1 থেকে 30 করলে শুধু 29 জনকে অপেক্ষা করতে হয়।

Continuous batching-ই মূল পার্থক্য

একই হার্ডওয়্যারে একই সময়ে প্রতিটি সার্ভারে পাঁচটি অনুরোধ আসছে—এমন পরিস্থিতি বিবেচনা করুন।

Ollama-এর ডিফল্ট সেটিংসে প্রথম অনুরোধটি সম্পূর্ণ হওয়া পর্যন্ত চালানো হয়, তারপর দ্বিতীয়টি, এবং এভাবে চলতে থাকে। পঞ্চম কলকারীকে চারটি সম্পূর্ণ জেনারেশন শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয়। মোট থ্রুপুট প্রায় একটি জেনারেশনের গতির সমান থাকে, কারণ প্রসেসর একসঙ্গে কখনও একটির বেশি sequence নিয়ে কাজ করে না।

vLLM একই forward pass-এ পাঁচটিকেই decode করে। পাঁচটি sequence-এর জন্য একটি token তৈরি করতে একটি sequence-এর জন্য একটি token তৈরির চেয়ে সামান্যই বেশি সময় লাগে, কারণ ব্যয়বহুল অংশ হলো মডেলের weights মেমরি থেকে পড়া, আর সেই পড়ার কাজটি পুরো batch-এর মধ্যে ভাগ হয়ে যায়। CPU inference ধীর হওয়ার পেছনেও একই memory-bandwidth বিষয়টি কাজ করে: arithmetic-এর জন্য নয়, weights স্থানান্তরের জন্য আপনাকে খরচ করতে হয়।

আপনি OLLAMA_NUM_PARALLEL=4 সেট করে এর কিছু সুবিধা পেতে পারেন। এর বিনিময়ে মেমরি লাগে। প্রতিটি parallel slot-এর নিজস্ব KV cache প্রয়োজন, আর Ollama context window-টি slotগুলোর মধ্যে ভাগ করে দেয়। তাই 8192 tokens-এর জন্য configured একটি model-এর বিপরীতে চারটি parallel request চালালে প্রতিটি request-এর context থাকে 2048 tokens। vLLM-এর paged cache এই trade-off এড়ায়, কারণ request যত বাড়তে থাকে, blocks তত request-টির জন্য বরাদ্দ করা হয়।

Ollama দিয়ে ইনস্টল ও পরিবেশন

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

ইনস্টল স্ক্রিপ্ট একটি ollama system user তৈরি করে, binary ইনস্টল করে এবং 127.0.0.1:11434-এর সঙ্গে bound থাকা ollama.service নিবন্ধন করে। --verbose যে eval rate line প্রিন্ট করে, সেটিই ওই মেশিনে প্রতি সেকেন্ডে আপনার প্রকৃত token সংখ্যা। প্রকাশিত যেকোনো পরিসংখ্যানের চেয়ে এটিকে বেশি নির্ভরযোগ্য ধরুন।

concurrency বাড়াতে একটি systemd drop-in ব্যবহার করুন, যাতে upgrade করলে পরিবর্তনটি overwrite না হয়:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps কী loaded আছে তা দেখায়, আর এর PROCESSOR column প্রকৃত অবস্থা জানায়। 100% CPU মানে কোনো GPU ব্যবহৃত হচ্ছে না। Ollama ধীর—এমন অধিকাংশ রিপোর্টের সঠিক ব্যাখ্যা এটিই।

vLLM দিয়ে ইনস্টল ও পরিবেশন

vLLM-এর জন্য Linux এবং Python 3.10 থেকে 3.13 প্রয়োজন। এটি নিজস্ব virtual environment-এ ইনস্টল করুন, কারণ এটি নির্দিষ্ট PyTorch build ইনস্টল করে:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

এরপর একটি model পরিবেশন করুন। নামটি কোনো সংক্ষিপ্ত tag নয়; এটি একটি Hugging Face repository id:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

প্রথমবার চালু হতে বেশি সময় লাগে, কারণ এটি প্রথমে weights ডাউনলোড করে এবং পরে GPU profile করে নির্ধারণ করে কতগুলি KV cache block রাখা যাবে। এটি port 8000-এ listening করে। কোনো client code লেখার আগে এটি পরীক্ষা করুন:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

যদি ওই server-এ Docker আগে থেকেই থাকে, official image ব্যবহার করলে CUDA dependency ইনস্টল করার কাজ এড়ানো যায়:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host প্রয়োজনীয়; এটি শুধু দেখানোর জন্য নয়। PyTorch process-গুলোর মধ্যে tensor পাঠাতে shared memory ব্যবহার করে, আর Docker-এর default shared-memory allocation tensor-parallel inference-এর জন্য খুব ছোট।

Production-এ সবচেয়ে গুরুত্বপূর্ণ flag-গুলো হলো --max-model-len (আপনি যে context window-এর জন্য অর্থ দিতে প্রস্তুত), --gpu-memory-utilization (vLLM যে পরিমাণ GPU memory ব্যবহার করতে পারবে; July 2026 অনুযায়ী default হলো 0.92), একটি model কয়েকটি GPU-তে ভাগ করার জন্য --tensor-parallel-size, এবং --api-key।

vLLM-এ প্রমাণীকরণ একটি flag, Ollama-এ তা অনুপস্থিত

আপনি token দিলে vLLM bearer token প্রয়োগ করে:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

একই মান VLLM_API_KEY environment variable থেকেও আসতে পারে। এই token ছাড়া কোনো request করলে HTTP 401 পাওয়া যায়। তবুও public interface-এ port 8000 প্রকাশ করার এটি কোনো কারণ নয়, কারণ vLLM-এ rate limiting নেই এবং সাধারণ HTTP token নেটওয়ার্কে চলাচলের সময় পড়া যায়। তবে এর অর্থ হলো, server-এর কাছে caller শনাক্ত করার একটি ধারণা আছে।

Ollama-এ এমন কোনো ব্যবস্থা নেই। কোনো key, login বা allow-list নেই। 11434-এ পৌঁছাতে পারে এমন যেকোনো process model চালাতে, pull করতে বা মুছে ফেলতে পারে। এটিকে loopback-এ রাখুন এবং নিজে host করা একটি WireGuard VPN ব্যবহার করে, অথবা TLS (transport layer security) সমাপ্ত করে এমন প্রমাণীকরণ-সমর্থিত reverse proxy-এর মাধ্যমে এতে সংযোগ করুন।

হার্ডওয়্যার: প্রতিটির কী প্রয়োজন

Ollama CPU-তে চলে। 4-bit quantized model-এর জন্য প্রতি বিলিয়ন parameter-এ প্রায় আধা গিগাবাইট RAM লাগে। এর সঙ্গে runtime overhead হিসেবে প্রায় 1 গিগাবাইট এবং context-এর জন্য আরও RAM প্রয়োজন। তাই 3B model-এর জন্য প্রায় 4 GB এবং 8B model-এর জন্য প্রায় 8 GB খালি RAM দরকার। Shared vCPU-তে গতি প্রতি সেকেন্ডে এক অঙ্ক থেকে নিম্ন দুই অঙ্কের token-এ সীমাবদ্ধ থাকে। এটি memory bandwidth-এর সীমাবদ্ধতা, misconfiguration নয়। কোনো flag দিয়ে এটি ঠিক করা যায় না।

vLLM ধরে নেয় যে GPU আছে। এর default path 16-bit precision-এ unquantized weights পরিবেশন করে। এতে প্রতি বিলিয়ন parameter-এ প্রায় 2 GB video memory লাগে। তাই 8B model-এর শুধু weights-এর জন্যই প্রায় 16 GB video memory দরকার। এর বাইরে KV cache-এর জন্য আরও memory লাগে, যার concurrency ব্যবহারের জন্য আপনি vLLM ইনস্টল করেছেন। 24 GB card-এ এতে ব্যবহারযোগ্য cache-এর জন্য যথেষ্ট memory অবশিষ্ট থাকে। 16 GB card-এ তা থাকে না। তাই আপনাকে ছোট model বেছে নিতে হবে অথবা quantized checkpoint-এর সঙ্গে --quantization পাস করতে হবে। CPU backend আছে। তবে standard wheels এর জন্য তৈরি নয়। তাছাড়া এতে vLLM চালানোর মূল কারণই আর থাকে না।

তাই বেশিরভাগ ক্ষেত্রে hardware-এর প্রশ্নই software-এর উত্তর নির্ধারণ করে। GPU না থাকলে Ollama ব্যবহার করুন। ভাড়া করা GPU-তে requests serialise হওয়ার কারণে utilisation 5 percent-এ আটকে থাকলে vLLM ব্যবহার করুন।

আপনার কাজের জন্য কোনটি

• একজন ব্যবহারকারী, একটি CPU VPS, খসড়া তৈরি ও সারসংক্ষেপ: Ollama। গতি গ্রহণযোগ্য, আর এর চেয়ে সহজ কিছু নেই।
• একটি coding assistant, অথবা আপনার টুলগুলোকে একটি local model-এর সঙ্গে সংযুক্ত করা MCP server, যা শুধু আপনিই ব্যবহার করেন: Ollama। একজন ব্যবহারকারীর concurrency-ই প্রকৃত workload।
• এই সপ্তাহে পাঁচটি model তুলনা করা: Ollama। tagged model pull ও delete করা এর উপযোগিতার মূল দিক, যেখানে vLLM-এর ক্ষেত্রে প্রতিটি model-এর জন্য process restart প্রয়োজন।
• প্রকৃত ব্যবহারকারীসহ একটি internal app, chat product, অথবা retrieval pipeline: vLLM। এখানেই batching-এর জন্য GPU খরচ সার্থক হয়।
• রাতভর এক লাখ document-এর scoring করা একটি batch job: উচ্চ --max-num-seqs সহ vLLM। এখানে throughput-ই একমাত্র গুরুত্বপূর্ণ metric; প্রতি document-এর latency গুরুত্বপূর্ণ নয়।
• একই সময়ে একাধিক self-hosted AI agent model-এ অনুরোধ পাঠায় এমন একটি agent platform: vLLM, কারণ agent traffic স্বভাবতই bursty এবং parallel।

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

KV cache-সংক্রান্ত ত্রুটির কারণে vLLM চালু হতে অস্বীকার করে। বার্তাটিতে উভয় সংখ্যার নাম থাকে:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

ওজন লোড করার পর অবশিষ্ট মেমরির তুলনায় মডেলটি বড় context window ঘোষণা করে। --max-model-len 8192 দিয়ে এর মান কমান, অথবা GPU-তে অন্য কোনো প্রক্রিয়া মেমরি ব্যবহার না করলে --gpu-memory-utilization বাড়ান। ব্যবহার 0.95-এর বেশি করলে সাধারণত এই startup ত্রুটির বদলে পরে load-এর সময় CUDA out-of-memory crash দেখা যায়। এই দুটি সমস্যার মধ্যে পরেরটি বেশি গুরুতর।

Generation চলাকালে Ollama Killed দেখায়। Linux out-of-memory killer প্রক্রিয়াটি বন্ধ করেছে, কারণ মডেলটির প্রয়োজনীয় RAM সিস্টেমে থাকা RAM-এর চেয়ে বেশি। sudo dmesg | grep -i oom দিয়ে নিশ্চিত করুন। সমাধান হলো ছোট বা আরও বেশি quantized মডেল ব্যবহার করা; কোনো setting পরিবর্তন করা নয়।

একা চালালে Ollama ঠিকভাবে উত্তর দেয়, কিন্তু load-এর সময় থেমে থাকে। কোথাও কোনো ত্রুটি দেখা যায় না। Caller-এর সংখ্যা বাড়ার সঙ্গে request-এর সময়ও বাড়ে, কারণ OLLAMA_NUM_PARALLEL=1 request-গুলোকে serialise করছে। এটি বাড়ালে প্রতি request-এ ব্যবহারযোগ্য context ছোট হবে। অথবা workload vLLM-এ সরান।

প্রতিটি call-এ vLLM 401 ফেরত দেয়। আপনি এটি --api-key দিয়ে চালু করেছেন, কিন্তু client কোনো Authorization header পাঠাচ্ছে না। অধিকাংশ OpenAI client library key হিসেবে আপনি যে মান পাঠান, সেটিই পাঠায়। তাই flag বাদ না দিয়ে client-এ key সেট করুন।

vLLM জানায় যে মডেলটি পাওয়া যায়নি। Ollama প্রয়োজন অনুযায়ী মডেল pull করে, কিন্তু vLLM তা করে না। Request body-এর model field-এ আপনি যে repository id দিয়ে vLLM চালু করেছেন, সেটিই থাকতে হবে। অথবা --served-model-name সেট করে থাকলে তার মান থাকতে হবে। curl http://localhost:8000/v1/models দিয়ে সঠিক string নিশ্চিত করুন।

উভয়ই চালানো একটি যুক্তিসংগত সমাধান

এগুলো পরস্পর-বিরোধী নয়। একটি প্রচলিত বিন্যাস হলো, অ্যাপ্লিকেশন পরিবেশনের জন্য GPU instance-এ vLLM চালানো এবং এর পাশাপাশি সাধারণ VPS-এ স্থানীয় script, cron job ও নতুন model release পরীক্ষা করার জন্য Ollama চালানো। উভয় endpoint-ই OpenAI-compatible। তাই একটি client library এবং base URL পরিবর্তন করলেই দুটিই ব্যবহার করা যায়। এখানে যেকোনো engine-এর চেয়ে খরচ নিয়ন্ত্রণ বেশি গুরুত্বপূর্ণ, কারণ নিষ্ক্রিয় GPU-র বিল সক্রিয় GPU-র মতোই হয়। এছাড়া agent ও inference-এর খরচ পূর্বানুমানযোগ্য রাখা server বেছে নেওয়া থেকে আলাদা একটি কাজ।

FAQ

Ollama-এর চেয়ে vLLM কি দ্রুত?

একই GPU-তে একটি অনুরোধের ক্ষেত্রে পার্থক্য খুব বেশি নয়, কারণ উভয়ই একই গাণিতিক কাজ করে। একসঙ্গে অনেক অনুরোধ চললে vLLM অনেক এগিয়ে থাকে। কারণ continuous batching একটি forward pass-এ সব সক্রিয় sequence decode করে, যেখানে Ollama-এর default সেগুলো একটির পর একটি চালায়। শুধু CPU-ভিত্তিক মেশিনে এই প্রশ্ন প্রযোজ্য নয়। Ollama সেখানে চলে, কিন্তু vLLM কার্যত চলে না।

GPU ছাড়া কি vLLM চালানো যায়?

ব্যবহারিকভাবে নয়। সাধারণ wheels NVIDIA বা AMD GPU-কে লক্ষ্য করে তৈরি, আর batched request দিয়ে accelerator-কে পূর্ণভাবে ব্যস্ত রাখা—vLLM থাকার মূল কারণ—CPU-তে প্রযোজ্য থাকে না। উন্নয়নমূলক কাজের জন্য একটি CPU backend রয়েছে। প্রকৃত CPU inference-এর জন্য সরাসরি Ollama বা llama.cpp ব্যবহার করুন।

Ollama এবং llama.cpp-এর মধ্যে পার্থক্য কী?

llama.cpp হলো inference library, আর GGUF হলো এর quantized weight format। Ollama-এর runner llama.cpp-এর ওপর তৈরি এবং llama.cpp যেসব কাজ আপনার ওপর ছেড়ে দেয়, সেগুলো যোগ করে: একটি model registry, স্বয়ংক্রিয় download, একটি resident server, একটি systemd unit এবং একটি OpenAI-compatible endpoint। কিছু নতুন model family-এর জন্য Ollama নিজস্ব engine যোগ করেছে। তাই অভ্যন্তরীণভাবে দুটির আচরণ আর অভিন্ন নয়।

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

16-bit precision-এ শুধু weights-এর জন্য প্রায় 16 GB লাগে, অর্থাৎ প্রতি billion parameter-এ আনুমানিক 2 GB। এর ওপর KV cache-এর জন্যও জায়গা প্রয়োজন। 24 GB card স্বাচ্ছন্দ্যে যথেষ্ট। 16 GB card হলে quantized checkpoint অথবা ছোট model প্রয়োজন। vLLM card-এর যে ভগ্নাংশ ব্যবহার করে, তা --gpu-memory-utilization নির্ধারণ করে। July 2026 অনুযায়ী এর default মান 0.92।

এগুলোর মধ্যে পরিবর্তন করতে কি application code বদলাতে হবে?

সাধারণত শুধু base URL, API key এবং model name বদলাতে হয়। Ollama তার OpenAI-compatible surface http://127.0.0.1:11434/v1-এ সরবরাহ করে এবং key উপেক্ষা করে। অন্যদিকে vLLM http://localhost:8000/v1 সরবরাহ করে এবং আপনি একটি key নির্ধারণ করলে তা প্রয়োগ করে। Model name-এর গঠনও আলাদা: Ollama-এর জন্য llama3.1:8b, আর vLLM-এর জন্য Qwen/Qwen2.5-1.5B-Instruct-এর মতো একটি সম্পূর্ণ repository id।