দ্বারা Matt Connor 2026-10-30

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

Ollama এক ব্যবহারকারীর জন্য CPU-সহ সহজ সমাধান, আর vLLM GPU-তে বেশি request সামলায়। workload অনুযায়ী বেছে নিন, সঙ্গে দেখুন উভয়ের বাস্তব command ও API।

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

Ollama হলো সংযুক্ত server-সহ একটি model manager: এটি quantized weights download ও load করে এবং 127.0.0.1:11434-এ উত্তর দেয়; server-এ শুধু 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 একটি সুবিধাজনক স্তর। এটি একটি install command-এর মাধ্যমে model registry (ollama pull llama3.1:8b), weights-এর local store, chat prompt, systemd service এবং HTTP API দেয়। এটি পরিবেশন করা বেশিরভাগ model হলো GGUF file, সাধারণত 4-bit quantized। এ কারণেই 7B বা 8B model disk-এ 16 GB-এর বদলে প্রায় 5 GB জায়গা নেয়। Quantization CPU inference-এর জন্য প্রয়োজনীয় memory কমায়। Apple Silicon Mac-এ এটি MLX engine-এর মাধ্যমে safetensors-ভিত্তিক model-ও চালাতে পারে। v0.40.0 (September 2026) থেকে সমর্থিত architecture স্বয়ংক্রিয়ভাবে MLX-এ চলে।

এর GGUF runner llama.cpp-এর ওপর তৈরি। llama.cpp হলো সেই C++ inference library, যা সাধারণ hardware-এ GGUF quantization ব্যবহারিক করে তুলেছে। October 2026 অনুযায়ী Ollama দুটি engine সমর্থন করে: llama.cpp এবং MLX। Linux build-এ CUDA সহ MLX inference-ও সমর্থিত। Development guide-এ cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 ব্যবহার করে এই backend সক্রিয় করা যায়। এর জন্য CUDA 13+ এবং cuDNN 9+ prerequisite। তাই Ollama এবং llama.cpp তুলনা করার সময় মূলত একটি ergonomics layer-এর সঙ্গে সেটি যে component-কে wrapper করে, তার তুলনা করা হয়।

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

vLLM আসলে কী

vLLM একটি inference server, এর বেশি কিছু নয়। এটি model library পরিচালনা করে না, একটি running server-এর জন্য vllm chat client সরবরাহ করে, এবং request আসার সময় আপনার হয়ে কোনো model pull করবে না। Launch-এর সময় আপনি একটি Hugging Face repository নির্দিষ্ট করেন, vLLM সেই একটি model load করে, এবং process বন্ধ না করা পর্যন্ত সেটি serve করে।

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

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

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

একই hardware-এ একই সময়ে প্রতিটি server-এ পাঁচটি request পৌঁছেছে—এমন পরিস্থিতি ধরুন।

Ollama-এর default settings-এ প্রথম request সম্পূর্ণ হওয়া পর্যন্ত চলে, তারপর দ্বিতীয়টি, এভাবে চলতে থাকে। পঞ্চম caller-কে চারটি সম্পূর্ণ generation-এর জন্য অপেক্ষা করতে হয়। মোট throughput মোটামুটি একটি generation-এর গতির সমান থাকে, কারণ processor একবারে কেবল একটি sequence-এ কাজ করে।

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

OLLAMA_NUM_PARALLEL=4 সেট করে এর কিছু সুবিধা পাওয়া যায়। এর মূল্য হলো memory। প্রতিটি parallel slot-এর জন্য নিজস্ব KV cache দরকার, এবং Ollama context allocation ভাগ না করে গুণ করে: এর FAQ অনুযায়ী প্রয়োজনীয় RAM OLLAMA_NUM_PARALLEL গুণ OLLAMA_CONTEXT_LENGTH অনুযায়ী বাড়ে। তাই 8192 tokens-এর জন্য configured একটি model-এর বিরুদ্ধে চারটি parallel request চালালে প্রতিটি request 8192 tokens রাখে, কিন্তু box-টিকে মোট 32768 tokens-এর cache ধারণ করতে হয়। এই 8192-ও পূর্বনির্ধারিত কোনো মান নয়; এটি একটি configuration choice। তাই num_ctx বাড়ানো এবং এর জন্য প্রয়োজনীয় RAM নির্ধারণ করাই ঠিক করে চারটি slot আদৌ fit করবে কি না। vLLM-এর paged cache প্রতিটি slot-এর জন্য শুরুতেই সম্পূর্ণ window reserve না করেই কাজ করে, কারণ request বাস্তবে যত বাড়ে, blocks তত অনুযায়ী request-এ allocate করা হয়। যেভাবেই হোক, একটি box একই সময়ে কতজনকে service দিতে পারবে, তার সীমা নির্ভর করে KV cache size, prefill cost এবং queue depth-এর ওপর। এটাই কারণ একজনের জন্য স্বাভাবিক মনে হওয়া server পাঁচজনের সময় ধীর হয়ে যায়।

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-এ bind করা ollama.service নিবন্ধন করে। --verbose যে eval rate line দেখায়, সেটিই ওই সার্ভারে প্রতি সেকেন্ডে আপনার প্রকৃত token সংখ্যা। প্রকাশিত যেকোনো পরিসংখ্যানের চেয়ে এটিকে বেশি গুরুত্ব দিন। একটি prompt থেকে পাওয়া একটি পরিমাপ capacity নির্দেশ করে না; এটি কেবল শুরুর তথ্য। তাই বিভিন্ন concurrency স্তরে প্রতি সেকেন্ডে token-এর সময় মাপা থেকে বোঝা যায়, আপনি যে load আশা করছেন তাতে সার্ভারটি স্থিতিশীল থাকে কি না এবং প্রতি token-এর খরচের চেয়ে GPU ভাড়া করা সাশ্রয়ী কি না।

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 ধীর হওয়ার অধিকাংশ রিপোর্টের সঠিক কারণ এটাই। ওই drop-in-এর OLLAMA_KEEP_ALIVE=30m line একটি কম ব্যস্ত সার্ভারেও সমান গুরুত্বপূর্ণ, কারণ কোনো request না থাকলে default হিসেবে model পাঁচ মিনিট পর unload হয়। request-এর মধ্যে model resident রাখা-ই বিরতির পর সর্বোচ্চ আধা ঘণ্টা পর্যন্ত আসা প্রথম prompt-কে আবার সম্পূর্ণ load time দিতে বাধা দেয়। আপনার বিরতি যদি এর চেয়ে দীর্ঘ হয়, তাহলে আরও দীর্ঘ value সেট করুন।

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

vLLM-এর GPU build-এর জন্য Linux প্রয়োজন (Apple Silicon-এ macOS-এ শুধু CPU সমর্থন রয়েছে; 0.32.0 release-এ prebuilt wheel দেওয়া হয়েছে। ওই Mac-গুলোতে GPU acceleration আসে vLLM-Metal থেকে, যা MLX-এর ওপর নির্মিত community-maintained একটি আলাদা plugin)। Python-এর ক্ষেত্রে বর্তমান release (0.32.0, October 2026) 3.11 থেকে 3.14 পর্যন্ত সংস্করণ গ্রহণ করে, এবং install guide-এও একই range উল্লেখ করা আছে। 0.32.0-এ Python 3.10-এর সমর্থন বাদ দেওয়া হয়েছে। তাই নিচে ব্যবহৃত 3.12 নিরাপদ পছন্দ। এটি আলাদা virtual environment-এ ইনস্টল করুন, কারণ এটি নির্দিষ্ট একটি PyTorch build ইনস্টল করে:

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

October 2026 অনুযায়ী vLLM-এর NVIDIA install guide-এ শেষের line-টি রয়েছে। এটি FlashInfer-এর precompiled kernel ইনস্টল করে। এগুলো না থাকলে vLLM startup-এর সময় kernel download ও compile করে। Guide অনুযায়ী Hopper এবং তার পরের GPU-তে এতে কয়েক মিনিট অতিরিক্ত সময় লাগতে পারে। প্রতিটি vLLM upgrade-এর পরে এটি আবার চালান, কারণ kernel-এর সঙ্গে সংস্করণ না মিললে FlashInfer import হতে অস্বীকার করে।

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

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

প্রথমবার startup ধীর হয়, কারণ vLLM প্রথমে weights download করে এবং এরপর GPU profile করে নির্ধারণ করে কতগুলি KV cache block রাখা যাবে। এটি port 8000-এ listen করে। কোনো 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?"}]}'

সার্ভারে আগে থেকেই 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 container-কে host-এর shared memory ব্যবহারের অনুমতি দেয়; --shm-size বাড়ানোও আরেকটি উপায়। বিশেষ করে tensor-parallel inference-এর সময় PyTorch shared memory ব্যবহার করে process-গুলোর মধ্যে tensor পাঠায়।

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

vLLM-এ authentication একটি flag-এর মাধ্যমে সক্রিয় হয়, Ollama-এর local API-তে তা নেই

আপনি bearer token দিলে vLLM সেটি বাধ্যতামূলক করে:

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

একই value VLLM_API_KEY environment variable থেকেও আসতে পারে। এটি ছাড়া /v1-এ পাঠানো request HTTP 401 return করে। তবে এই key পুরো server-এর ক্ষেত্রে প্রযোজ্য নয়। vLLM-এর security guide এবং 0.32.0 source-এর authentication code এটি শুধু /v1, /v2, /inference এবং /cohere path prefix-এর অধীন endpoint-গুলোর ক্ষেত্রে প্রয়োগ করে। vllm serve page-এর --api-key help text-এ শুধু প্রথম তিনটি তালিকাভুক্ত আছে। কিন্তু code চারটিই পরীক্ষা করে। Guide এবং help text উভয়েই বলা আছে যে অন্য endpoint-গুলো, বিশেষ করে /invocations, যা /v1-এর মতো একই inference প্রকাশ করে, authenticated নয়। Public interface-এ port 8000 প্রকাশ না করার জন্য এটিই যথেষ্ট কারণ। vLLM-এর security guide rate limiting-এর দায়িত্বও সামনে থাকা reverse proxy-র ওপর ছেড়ে দেয়। Plain HTTP-তে পাঠানো token transit-এর সময় পড়া যায়। তবে এই flag-এর অর্থ হলো server-এর কাছে caller শনাক্ত করার একটি ধারণা থাকে।

Ollama-এর local API-তে authentication প্রয়োজন হয় না। Cloud model, model publishing এবং private model download-এর জন্য sign-in প্রয়োজন। ollama.com-এ direct API access-এর জন্য API key প্রয়োজন। 11434-এ পৌঁছাতে পারে এমন যেকোনো process model run, pull বা delete করতে পারে। এটিকে loopback-এ রাখুন এবং নিজে host করা WireGuard VPN-এর মাধ্যমে অথবা TLS (transport layer security) terminate করা authenticating reverse proxy-র মাধ্যমে এতে পৌঁছান।

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

Ollama CPU-তে চলে। 4-bit quantized model-এর জন্য প্রতি billion parameter-এ মোটামুটি আধা gigabyte RAM লাগে। এর সঙ্গে runtime overhead হিসেবে প্রায় 1 gigabyte এবং context-এর জন্য আরও RAM লাগে। তাই 3B model-এর জন্য প্রায় 4 GB free RAM এবং 8B model-এর জন্য প্রায় 8 GB RAM দরকার। Shared vCPU-তে গতি সাধারণত single digit থেকে low double digit tokens per second। এটি memory bandwidth-এর সীমাবদ্ধতা, misconfiguration নয়। কোনো flag দিয়ে এটি ঠিক করা যায় না। Rule of thumb-এর বদলে নির্দিষ্ট release-এ এই হিসাব বাস্তবে কেমন হয় তা দেখতে VPS-এ Nemotron 3.5 Lightning চালানো দেখুন। সেখানে pull করার exact tag, model load হওয়ার পরে ব্যবহৃত RAM এবং CPU-only mode যথেষ্ট দ্রুত কি না—সব নির্দিষ্ট করা আছে।

vLLM সাধারণত GPU ধরে নিয়ে কাজ করে। এর default path 16-bit precision-এ unquantized weights serve করে। এতে প্রতি billion parameter-এ প্রায় 2 GB video memory লাগে। তাই 8B model-এর weights-এর জন্যই প্রায় 16 GB video memory দরকার। এর বাইরে KV cache-এর জন্যও memory লাগে; vLLM চালানোর সময় concurrency-এর জন্য এই cache-ই প্রয়োজন। 24 GB card-এ ব্যবহারযোগ্য cache-এর জন্য কিছু memory অবশিষ্ট থাকে। 16 GB card-এ তা থাকে না। তাই ছোট model বেছে নিন, অথবা --quantization দিন। এটি quantized checkpoint-এর সঙ্গে ব্যবহার করা যায়, কিংবা load করার সময় full-precision weights quantize করতে পারে। আরেকটি বিকল্প হলো --cpu-offload-gb দিয়ে weights-এর কিছু অংশ system RAM-এ পাঠানো। এতে weights-এর precision বজায় থাকে, কিন্তু গতি কমে যায়। কারণ প্রতিটি forward pass-এ ওই weights GPU-তে পাঠাতে হয়। CPU backend-ও আছে, তবে তার জন্য আলাদা wheels লাগে। এটি ব্যবহার করলে vLLM চালানোর মূল কারণই আর থাকে না।

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

আপনার workload-এর জন্য কোনটি

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

ব্যর্থতার ধরন এবং যে string আপনি দেখতে পাবেন

KV cache error-সহ vLLM start হতে অস্বীকার করে। Message-এ দুটি number-ই উল্লেখ থাকে:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Model এমন একটি context window ঘোষণা করে, যা weights load করার পর অবশিষ্ট memory-এর চেয়ে বড়। --max-model-len 8192 দিয়ে এটি কমান। Card-এ অন্য কিছু ব্যবহার না হলে --gpu-memory-utilization বাড়ান।

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

একা চালালে Ollama ঠিকভাবে উত্তর দেয়, কিন্তু load-এর অধীনে আটকে যায়। কোথাও কোনো error দেখা যায় না। Caller-এর সংখ্যা বাড়লে request-গুলো শুধু বেশি সময় নেয়, কারণ OLLAMA_NUM_PARALLEL=1 সেগুলো serialise করছে। দীর্ঘ উত্তর queue-র সমস্যা বাড়ায়। কারণ একমাত্র slot-টি দখল করা caller model থামার সিদ্ধান্ত না নেওয়া পর্যন্ত slot ধরে রাখে এবং তার পেছনের সবাইকে অপেক্ষা করায়। তাই num_predict দিয়ে reply-এর সীমা নির্ধারণ করলে একটি turn কতক্ষণ server ধরে রাখতে পারবে, তার ceiling তৈরি হয়। Parallel setting বাড়িয়ে প্রতিটি slot-এর context-এর জন্য অতিরিক্ত RAM গ্রহণ করুন, অথবা workload vLLM-এ সরিয়ে নিন।

প্রতিটি /v1 call-এ vLLM 401 return করে। আপনি --api-key দিয়ে এটি start করেছেন, কিন্তু client কোনো Authorization header পাঠাচ্ছে না। বেশিরভাগ OpenAI client library key হিসেবে আপনি যে value পাঠান, সেটিই পাঠায়। তাই flag বাদ না দিয়ে client-এ সেই value set করুন।

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

দুটিই চালানো একটি যুক্তিসঙ্গত সমাধান

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

FAQ

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

একই GPU-তে একটি request-এর জন্য পার্থক্য কম, কারণ উভয়ই একই arithmetic সম্পন্ন করে। একসঙ্গে অনেক request চললে vLLM অনেক এগিয়ে থাকে, কারণ continuous batching প্রতিটি active sequence-কে একটি forward pass-এ decode করে, যেখানে Ollama-এর default এগুলো একটির পর একটি চালায়। শুধু CPU-ভিত্তিক মেশিনে উভয়েরই supported inference path আছে; vLLM-এর জন্য আলাদা CPU wheels ব্যবহার করতে হয়।

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

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

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

llama.cpp হলো inference library, আর GGUF হলো এর quantized weight format। Ollama GGUF inference-এর জন্য এটি ব্যবহার করে এবং এর সঙ্গে model registry, tagged downloads, model management ও একটি systemd unit যোগ করে। Ollama একটি MLX engine-ও সরবরাহ করে, যা Apple Silicon-এ safetensors-ভিত্তিক model চালায় এবং Linux-এ CUDA build সমর্থন করে। তাই অভ্যন্তরীণভাবে দুটির আচরণ সব সময় অভিন্ন নয়।

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

16-bit precision-এ শুধু weights-এর জন্য প্রায় 16 GB লাগে, অর্থাৎ প্রতি billion parameter-এ আনুমানিক 2 GB। এর সঙ্গে KV cache-এর জন্যও অতিরিক্ত জায়গা প্রয়োজন। 24 GB card স্বচ্ছন্দে যথেষ্ট। 16 GB card হলে quantized model, ছোট model, অথবা --cpu-offload-gb ব্যবহার করে weights-এর একটি অংশ system RAM-এ সরাতে হবে; এতে speed কমবে। vLLM card-এর যে অংশ ব্যবহার করবে তা --gpu-memory-utilization নির্ধারণ করে; October 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 সেট করলে তার /v1 route-গুলোতে সেটি বাধ্যতামূলক করে। Model name-এর বিন্যাসও ভিন্ন: Ollama-এর জন্য llama3.1:8b, আর vLLM-এর জন্য Qwen/Qwen2.5-1.5B-Instruct-এর মতো পূর্ণ repository id।

এই লেখাটি কি কাজে লেগেছে?

#ollama #vllm #llm #inference #self-hosting