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

Ollama और vLLM, एक अनुच्छेद में

Ollama एक मॉडल मैनेजर है, जिसके साथ सर्वर भी जुड़ा होता है। यह quantized weights डाउनलोड करके लोड करता है और 127.0.0.1:11434 पर उत्तर देता है। यदि मशीन में केवल CPU है, तो यह उसी का उपयोग करता है। vLLM एक throughput engine है। यह एक साथ चल रहे कई requests के माध्यम से GPU को पूरी क्षमता पर उपयोग करता है। जिस मशीन में GPU नहीं है, उस पर यह सही टूल नहीं है। निर्णय इतना ही है। किसी स्थानीय assistant से बात करने वाला एक व्यक्ति Ollama का उपयोग करता है। किसी टीम को सेवा देने वाला 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 मिलते हैं। इसके द्वारा उपलब्ध कराए जाने वाले 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 जोड़ा है। फिर भी, इसके द्वारा उपलब्ध कराई जाने वाली अधिकांश सुविधाओं के नीचे llama.cpp ही आधार है। इसलिए जब लोग Ollama और llama.cpp की तुलना करते हैं, तो वे मुख्यतः एक ergonomics layer की तुलना उस software से कर रहे होते हैं जिसे वह wrap करती है।

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

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

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

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

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

सतत बैचिंग ही पूरा अंतर है

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

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

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

आप OLLAMA_NUM_PARALLEL=4 सेट करके इसका कुछ लाभ प्राप्त कर सकते हैं। इसकी लागत memory है। प्रत्येक parallel slot को अपना KV cache चाहिए। Ollama context window को slots में विभाजित करता है। इसलिए 8192 tokens के लिए configured model के विरुद्ध चार parallel requests चलाने पर प्रत्येक request के लिए context के 2048 tokens बचते हैं। vLLM का paged cache इस trade-off से बचाता है, क्योंकि blocks request के वास्तव में बढ़ने पर उसी के लिए allocate किए जाते हैं।

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 से बंधी हुई ollama.service रजिस्टर करती है। --verbose द्वारा प्रिंट की गई eval rate लाइन उस मशीन पर आपके वास्तविक tokens per second को दिखाती है। प्रकाशित किसी भी आंकड़े की तुलना में इस पर अधिक भरोसा करें।

Concurrency बढ़ाने के लिए systemd drop-in का उपयोग करें, ताकि upgrade इस बदलाव को ओवरराइट न करे:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps दिखाता है कि क्या लोड किया गया है, और उसका PROCESSOR कॉलम वास्तविक स्थिति बताता है। 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 serve करें। इसका नाम Hugging Face repository id होता है, कोई छोटा tag नहीं:

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

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

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

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

vLLM में प्रमाणीकरण एक flag है और Ollama में अनुपस्थित है

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

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

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

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

हार्डवेयर: प्रत्येक को क्या चाहिए

Ollama CPU पर चलता है। 4-bit quantized model के लिए प्रति billion parameters लगभग आधा gigabyte RAM चाहिए। इसके अतिरिक्त runtime overhead के लिए लगभग एक gigabyte और context के लिए उससे अधिक RAM चाहिए। इसलिए 3B model के लिए लगभग 4 GB free memory और 8B model के लिए लगभग 8 GB free memory चाहिए। साझा vCPU पर गति single digit से low double digit tokens per second तक होती है। इसका कारण memory bandwidth है, misconfiguration नहीं। कोई flag इसे ठीक नहीं कर सकता।

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 पर इससे workable cache के लिए पर्याप्त memory बचती है। 16 GB card पर ऐसा नहीं होता। इसलिए आपको छोटा model चुनना होगा या quantized checkpoint के साथ --quantization pass करना होगा। CPU backend उपलब्ध है, लेकिन standard wheels इसके लिए built नहीं हैं। इससे vLLM चलाने का मूल कारण भी समाप्त हो जाता है।

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

आपके वर्कलोड के लिए कौन-सा चुनें

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

विफलता की स्थितियाँ और दिखाई देने वाले संदेश

vLLM KV cache त्रुटि के साथ शुरू होने से इनकार करता है। संदेश में दोनों संख्याएँ दी जाती हैं:

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 घोषित करता है जो weights लोड करने के बाद बची memory से बड़ी है। इसे --max-model-len 8192 से कम करें, या यदि card पर कोई अन्य प्रक्रिया memory का उपयोग नहीं कर रही है तो --gpu-memory-utilization बढ़ाएँ। उपयोग को लगभग 0.95 से अधिक करने पर startup त्रुटि की जगह बाद में load के दौरान CUDA out-of-memory crash होने की संभावना बढ़ जाती है। यह दोनों में अधिक गंभीर समस्या है।

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

Ollama अकेले ठीक उत्तर देता है, लेकिन load के दौरान रुक जाता है। कहीं कोई त्रुटि दिखाई नहीं देती। Callers की संख्या बढ़ने पर requests अधिक समय लेती हैं, क्योंकि OLLAMA_NUM_PARALLEL=1 उन्हें serialise करता है। इसे बढ़ाएँ और प्रत्येक request के लिए छोटी context स्वीकार करें, या workload को vLLM पर ले जाएँ।

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

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

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

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

FAQ

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

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

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

व्यावहारिक रूप से नहीं। मानक wheels NVIDIA या AMD GPUs के लिए बनाए जाते हैं। CPU पर accelerator को batched requests से पूरी तरह व्यस्त रखने का vLLM का मुख्य लाभ समाप्त हो जाता है। विकास कार्य के लिए 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 चाहिए, यानी प्रति billion parameters लगभग 2 GB। इसके अतिरिक्त KV cache के लिए भी स्थान चाहिए। 24 GB का card पर्याप्त है। 16 GB के card के लिए quantized checkpoint या छोटा model आवश्यक है। vLLM card की memory का वह अंश उपयोग करता है जो --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 names का स्वरूप अलग होता है: Ollama के लिए llama3.1:8b और vLLM के लिए Qwen/Qwen2.5-1.5B-Instruct जैसे पूरा repository id।