Ollama बनाम vLLM: कौन सा LLM server चलाएँ?

Ollama बनाम vLLM, एक अनुच्छेद में

Ollama एक model manager है, जिसके साथ server जुड़ा होता है: यह quantized weights download करके load करता है और 127.0.0.1:11434 पर उत्तर देता है; यदि मशीन में केवल CPU है, तो उसी पर चलता है। vLLM throughput engine है: यह एक साथ चलने वाली कई requests के साथ GPU को लगातार व्यस्त रखता है, इसलिए GPU के बिना मशीन पर यह सही tool नहीं है। पूरा निर्णय इतना ही है। किसी local assistant से बात करने वाला एक व्यक्ति Ollama का उपयोग करता है। किसी team को service देने वाला application vLLM का उपयोग करता है।

दोनों OpenAI-compatible HTTP API उपलब्ध कराते हैं, इसलिए base URL बदलकर client code को एक से दूसरे पर ले जाया जा सकता है। अंतर API में नहीं है। अंतर इस बात में है कि पहली request के tokens generate होते समय दूसरी request आने पर क्या होता है।

Ollama वास्तव में क्या है

Ollama एक सुविधा-परत है। एक ही install command से यह आपको model registry (ollama pull llama3.1:8b), weights का local store, chat prompt, systemd service और HTTP API देता है। इसके द्वारा serve किए जाने वाले models GGUF files होते हैं, जो आम तौर पर 4-bit quantized होते हैं। इसी कारण 7B या 8B model disk पर 16 GB के बजाय लगभग 5 GB जगह लेता है। Quantization के कारण ही CPU inference संभव हो पाता है।

इसका runner llama.cpp पर आधारित है। llama.cpp वह C++ inference library है जिसने सामान्य hardware पर GGUF quantization को व्यावहारिक बनाया। बाद में Ollama ने कुछ नए model families के लिए अपना engine भी जोड़ा है, लेकिन इसके द्वारा serve की जाने वाली अधिकांश चीजों के पीछे अभी भी llama.cpp ही आधार है। इसलिए जब लोग Ollama की तुलना llama.cpp से करते हैं, तो वे मुख्य रूप से एक ergonomics layer की तुलना उस component से कर रहे होते हैं जिसे वह wrap करती है।

इसका design target एक user है। July 2026 तक OLLAMA_NUM_PARALLEL का default 1 है। इसका अर्थ है कि एक model एक समय में एक request process करता है और बाकी सभी requests उस queue में प्रतीक्षा करती हैं, जिसमें default रूप से 512 entries होती हैं (OLLAMA_MAX_QUEUE)। आप parallel setting बढ़ा सकते हैं। नीचे वाला section बताता है कि इसकी लागत क्या होगी। यदि आपने पहले Ollama नहीं चलाया है, तो VPS पर Ollama host करना और port 11434 को बंद रखना से शुरुआत करें, क्योंकि API में किसी भी प्रकार का authentication नहीं है।

vLLM वास्तव में क्या है

vLLM केवल एक inference server है। यह model library manage नहीं करता, इसमें chat prompt नहीं होता और request के समय यह आपके लिए कोई model pull नहीं करेगा। Launch के समय आप Hugging Face repository का नाम देते हैं। यह उसी एक model को load करता है और process बंद होने तक उसे serve करता है।

इस सीमित दायरे का लाभ throughput है। इसके लिए दो mechanisms काम करते हैं। PagedAttention KV cache (key-value cache; हर active request के लिए model द्वारा रखी जाने वाली per-token attention state) को fixed-size blocks में store करता है, ठीक वैसे ही जैसे operating system memory को pages में बाँटता है। अब किसी request के लिए worst case के अनुसार एक बड़े contiguous reservation की आवश्यकता नहीं होती। इसलिए पहले reserved लेकिन unused रहने वाली memory अधिक concurrent requests के लिए उपलब्ध हो जाती है। Continuous batching किसी नए request को current batch पूरा होने की प्रतीक्षा कराने के बजाय अगले decoding step पर running batch में शामिल होने देता है। कोई sequence पूरा होते ही batch से निकल जाता है और उसका slot तुरंत भर दिया जाता है।

व्यावहारिक परिणाम यह है: single GPU पर one concurrent user से thirty users तक जाने पर total tokens per second तेज़ी से बढ़ता है, जबकि प्रत्येक user की speed आपकी अपेक्षा से बहुत कम घटती है। Ollama के default व्यवहार में one user से thirty users तक जाने पर केवल twenty-nine लोग इंतज़ार करते हैं।

Continuous batching ही पूरा अंतर पैदा करती है

कल्पना करें कि एक ही hardware पर प्रत्येक server को एक ही समय में पांच requests मिलती हैं।

Ollama की default settings में पहली request पूरी होने तक चलती है, फिर दूसरी, और इसी क्रम में आगे। पांचवां caller चार पूरी generations का इंतजार करता है। कुल throughput लगभग एक generation की speed जितना रहता है, क्योंकि processor एक समय में केवल एक sequence पर काम करता है।

vLLM सभी पांचों को एक ही forward pass में decode करता है। पांच sequences के लिए एक token generate करने की लागत, एक sequence के लिए एक token generate करने की लागत से बहुत अधिक नहीं होती, क्योंकि महंगा हिस्सा model weights को memory से पढ़ना है और यह read पूरे batch में share होता है। यही memory-bandwidth तथ्य CPU inference को slow बनाता है: लागत weights को move करने की होती है, arithmetic की नहीं।

आप OLLAMA_NUM_PARALLEL=4 सेट करके इसका कुछ लाभ ले सकते हैं। इसकी लागत memory है। प्रत्येक parallel slot को अपना KV cache चाहिए, और Ollama context window को slots के बीच बांटता है। इसलिए 8192 tokens के लिए configured model के विरुद्ध चार parallel requests में प्रत्येक request को 2048 tokens का context मिलता है। यह 8192 भी कोई तय मान नहीं है, बल्कि एक choice है। इसलिए num_ctx बढ़ाना और उसके लिए आवश्यक RAM का sizing करना यह तय करने वाला कदम है कि चार slots वास्तव में उपयोग किए जा सकते हैं या नहीं। vLLM का paged cache इस trade-off से बचाता है, क्योंकि blocks request के वास्तविक रूप से बढ़ने पर उसे allocate किए जाते हैं। दोनों स्थितियों में, एक box एक समय में कितने लोगों को serve कर सकता है, इसकी सीमा KV cache size, prefill cost और queue depth पर निर्भर करती है। यही कारण है कि एक व्यक्ति के लिए ठीक लगने वाला server पांच लोगों पर बहुत slow हो जाता है।

Ollama के साथ install करें और serve करें

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

Install script एक ollama system user बनाती है, binary install करती है और 127.0.0.1:11434 से bound ollama.service register करती है। --verbose द्वारा print की गई eval rate उस box पर आपका वास्तविक tokens per second है। किसी भी published figure की तुलना में इस पर अधिक भरोसा करें। एक prompt से मिली एक reading केवल शुरुआती संकेत है, capacity number नहीं। इसलिए concurrency sweep के दौरान tokens per second का समय मापना यह बताता है कि आपकी अपेक्षित load पर box स्थिर रहता है या नहीं, और GPU rent करना per-token payment से बेहतर है या नहीं।

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 के slow होने की अधिकांश reports के लिए यही सही कारण है। उस drop-in में OLLAMA_KEEP_ALIVE=30m line quiet box पर भी उतनी ही महत्वपूर्ण है, क्योंकि default किसी request के बिना पांच मिनट बाद model unload कर देता है। इसलिए requests के बीच model को resident रखना यह सुनिश्चित करता है कि idle hour के बाद पहला prompt फिर से पूरा load time न ले।

vLLM install करें और serve करें

vLLM के लिए Linux और Python 3.10 से 3.13 आवश्यक हैं। इसे अपने अलग virtual environment में install करें, क्योंकि यह एक विशिष्ट PyTorch build install करता है:

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

अब कोई model serve करें। नाम Hugging Face repository id होता है, कोई छोटा tag नहीं:

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

पहली बार startup धीमा होता है, क्योंकि यह पहले weights download करता है और फिर GPU की profiling करके तय करता है कि कितने KV cache blocks उपलब्ध हैं। यह 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?"}]}'

यदि इस host पर 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 processes के बीच tensors भेजने के लिए shared memory का उपयोग करता है, और default Docker shared-memory allocation tensor-parallel inference के लिए बहुत छोटा होता है।

Production में सबसे महत्वपूर्ण flags --max-model-len हैं, जो उस context window को निर्धारित करता है जिसके लिए आप संसाधन देना चाहते हैं; --gpu-memory-utilization, यानी card का वह fraction जिसे vLLM उपयोग कर सकता है, जो July 2026 तक default रूप से 0.92 है; एक model को कई GPUs पर बाँटने के लिए --tensor-parallel-size; और --api-key।

vLLM में authentication एक flag है, जबकि Ollama में यह उपलब्ध नहीं है

यदि आप vLLM को bearer token देते हैं, तो वह उसे अनिवार्य करता है:

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

यही value VLLM_API_KEY environment variable से भी दी जा सकती है। इसके बिना भेजी गई request का उत्तर HTTP 401 मिलता है। फिर भी port 8000 को public interface पर expose करने का यह कारण नहीं है, क्योंकि vLLM में rate limiting नहीं है और plain HTTP token को network traffic में पढ़ा जा सकता है। हालांकि, इससे यह स्पष्ट होता है कि server में caller की पहचान की एक अवधारणा मौजूद है।

Ollama में ऐसी कोई सुविधा नहीं है। इसमें key, login या allow-list नहीं है। 11434 तक पहुंच रखने वाली कोई भी process models को run, pull या delete कर सकती है। इसे loopback पर रखें और अपने द्वारा host किए गए WireGuard VPN के माध्यम से, या TLS (transport layer security) समाप्त करने वाले authentication-enabled reverse proxy के जरिए पहुंचें।

Hardware: हर एक को क्या चाहिए

Ollama CPU पर चलता है। 4-bit quantized model में प्रति billion parameters लगभग आधा gigabyte RAM लगता है। इसके अलावा runtime overhead के लिए लगभग 1 gigabyte और context के लिए अतिरिक्त memory चाहिए। इसलिए 3B model के लिए लगभग 4 GB free memory और 8B model के लिए लगभग 8 GB चाहिए। Shared vCPU पर speed single digit से low double digit tokens per second रहती है। यह memory bandwidth की सीमा है, misconfiguration नहीं। कोई flag इसे ठीक नहीं कर सकता। सामान्य नियम के बजाय किसी specific release पर यही गणना देखनी हो तो VPS पर Nemotron 3.5 Lightning चलाना exact tag, load होने के बाद इस्तेमाल होने वाली RAM और CPU-only mode की व्यावहारिक speed स्पष्ट करता है।

vLLM में GPU मानकर चला जाता है। इसका default path unquantized weights को 16-bit precision में serve करता है। इसमें प्रति billion parameters लगभग 2 GB memory लगती है। इसलिए 8B model के weights के लिए अकेले लगभग 16 GB video memory चाहिए। इसमें उस KV cache की memory शामिल नहीं है जिसके लिए आपने vLLM में concurrency स्थापित की है। 24 GB card पर usable cache के लिए पर्याप्त जगह बचती है। 16 GB card पर ऐसा नहीं होता। इसलिए या तो छोटा model चुनें या quantized checkpoint के साथ --quantization pass करें। CPU backend उपलब्ध है, लेकिन standard wheels उसके लिए built नहीं हैं। इसके अलावा CPU पर vLLM चलाने से vLLM इस्तेमाल करने का मूल कारण ही समाप्त हो जाता है।

इसलिए अधिकतर मामलों में hardware का उत्तर ही software का उत्तर तय करता है। GPU नहीं है तो Ollama चुनें। यदि rented GPU केवल 5 percent utilisation पर चल रहा है क्योंकि requests serialise हो रही हैं, तो vLLM चुनें।

आपके workload के लिए कौन-सा विकल्प

• एक व्यक्ति, CPU VPS, drafting और summarising के लिए: Ollama। इसकी गति स्वीकार्य है और इससे सरल कोई विकल्प नहीं है।
• Coding assistant या आपके tools को local model से जोड़ने वाला MCP server, जिसे केवल आप call करते हैं: Ollama। वास्तविक workload में concurrency एक ही है।
• इस सप्ताह पांच models की तुलना करनी है: Ollama। Tagged models को pull और delete करना इसका मुख्य उपयोग है, जबकि vLLM में हर model के लिए process restart करना पड़ता है।
• Internal app, chat product या वास्तविक users वाली retrieval pipeline के लिए: vLLM। यहीं batching का लाभ GPU bill को उचित ठहराता है।
• रात भर में एक लाख documents का scoring करने वाले batch job के लिए: vLLM, high --max-num-seqs के साथ। Throughput ही एकमात्र महत्वपूर्ण metric है; प्रत्येक document की latency महत्वपूर्ण नहीं है।
• ऐसा agent platform जिसमें कई self-hosted AI agents एक साथ model को hit करते हैं: vLLM, क्योंकि agent traffic स्वभाव से bursty और parallel होता है।

विफलता के प्रकार और दिखाई देने वाली strings

vLLM KV cache error के साथ start होने से मना करता है। Message में दोनों numbers दिए होते हैं:

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.

Model ऐसा context window घोषित करता है जो weights load करने के बाद बची memory से बड़ा है। इसे --max-model-len 8192 से कम करें, या यदि card पर कोई और process memory उपयोग नहीं कर रहा है तो --gpu-memory-utilization बढ़ाएँ। utilisation को लगभग 0.95 से ऊपर ले जाने पर अक्सर यह startup error बाद में load के दौरान CUDA out-of-memory crash में बदल जाता है। दोनों में crash अधिक गंभीर है।

Ollama generation के बीच में Killed print करता है। Linux out-of-memory killer ने process रोक दिया, क्योंकि model को host पर उपलब्ध RAM से अधिक memory चाहिए थी। sudo dmesg | grep -i oom से इसकी पुष्टि करें। समाधान छोटा या अधिक heavily quantized model उपयोग करना है, कोई setting बदलना नहीं।

Ollama अकेले ठीक उत्तर देता है, लेकिन load में stall हो जाता है। कहीं कोई error दिखाई नहीं देता। Callers की संख्या बढ़ने पर requests केवल अधिक समय लेने लगती हैं, क्योंकि OLLAMA_NUM_PARALLEL=1 उन्हें serialise कर रहा है। लंबे answers से queue और बढ़ती है, क्योंकि किसी एक caller द्वारा model के रुकने तक एकमात्र slot रोककर रखने से उसके पीछे के सभी requests रुकते हैं। इसलिए num_predict से reply की सीमा तय करना यह सीमा निर्धारित करता है कि कोई एक turn server का slot कितनी देर तक रोक सकता है। Parallel setting बढ़ाएँ और प्रति-request context छोटा होने को स्वीकार करें, या workload को vLLM पर ले जाएँ।

vLLM हर call पर 401 लौटाता है। आपने इसे --api-key के साथ start किया है, लेकिन client कोई Authorization header नहीं भेजता। अधिकांश OpenAI client libraries key के रूप में वही value भेजती हैं जो आप उन्हें देते हैं। इसलिए flag हटाने के बजाय key वहीं set करें।

vLLM कहता है कि model नहीं मिला। Ollama आवश्यकता पड़ने पर model pull करता है, vLLM ऐसा नहीं करता। Request body का model field उस repository id से match होना चाहिए जिसके साथ आपने इसे launch किया था, या यदि आपने --served-model-name set किया है तो उसकी value से match होना चाहिए। Exact string की पुष्टि curl http://localhost:8000/v1/models से करें।

दोनों चलाना एक उचित विकल्प है

ये विकल्प एक-दूसरे के लिए अनन्य नहीं हैं। एक सामान्य व्यवस्था में application को serve करने के लिए GPU instance पर vLLM चलता है और उसके साथ ordinary VPS पर local scripts, cron jobs और नए model releases आज़माने के लिए Ollama चलता है। दोनों endpoints OpenAI-compatible हैं, इसलिए एक ही client library और base-URL बदलना पर्याप्त होता है। यहां किसी भी engine की तुलना में cost control अधिक महत्वपूर्ण है, क्योंकि idle GPU का billing busy GPU जितना ही होता है और agent और inference की लागत को अनुमानित बनाए रखना server चुनने से अलग discipline है।

FAQ

क्या vLLM, Ollama से तेज है?

एक ही GPU पर एकल request के लिए अंतर सीमित होता है, क्योंकि दोनों समान गणना करते हैं। कई concurrent requests के लिए vLLM काफी तेज है, क्योंकि continuous batching हर active sequence को एक ही forward pass में decode करता है, जबकि Ollama का default उन्हें एक-एक करके चलाता है। केवल CPU वाली machine पर यह प्रश्न लागू नहीं होता: Ollama वहां चलता है, जबकि vLLM व्यावहारिक रूप से नहीं चलता।

क्या vLLM, GPU के बिना चल सकता है?

उपयोगी रूप से नहीं। standard wheels का लक्ष्य NVIDIA या AMD GPUs हैं। vLLM के अस्तित्व का मुख्य कारण, यानी batched requests के साथ accelerator को लगातार व्यस्त रखना, CPU पर समाप्त हो जाता है। Development work के लिए CPU backend उपलब्ध है। वास्तविक CPU inference के लिए सीधे Ollama या llama.cpp का उपयोग करें।

Ollama और llama.cpp में क्या अंतर है?

llama.cpp inference library है और GGUF इसका quantized weight format है। Ollama का runner इसी पर आधारित है और वे हिस्से जोड़ता है जिन्हें llama.cpp आपके लिए नहीं संभालता: model registry, automatic download, resident server, systemd unit और OpenAI-compatible endpoint। Ollama ने कुछ नए model families के लिए अपना engine भी जोड़ा है, इसलिए अब दोनों अंदर से पूरी तरह समान नहीं हैं।

8B model के लिए vLLM को कितनी GPU memory चाहिए?

16-bit precision पर केवल weights के लिए लगभग 16 GB चाहिए, यानी करीब 2 GB प्रति billion parameters। इसके अतिरिक्त KV cache के लिए भी जगह चाहिए। 24 GB का card पर्याप्त रहता है। 16 GB के card के लिए quantized checkpoint या छोटा model चाहिए। vLLM card की memory का उतना ही अंश उपयोग करता है, जितना --gpu-memory-utilization से निर्धारित होता है। July 2026 तक इसका default 0.92 है।

इनके बीच switch करने के लिए क्या मुझे 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 set करते हैं तो उसे लागू करता है। Model names का format अलग होता है: Ollama के लिए llama3.1:8b और vLLM के लिए Qwen/Qwen2.5-1.5B-Instruct जैसे पूरा repository id।