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 प्रदान करता है। यह जिन अधिकांश models को serve करता है, वे GGUF files होती हैं, जो आमतौर पर 4-bit quantized होती हैं। यही कारण है कि 16 GB के बजाय 7B या 8B model डिस्क पर लगभग 5 GB की होती है। Quantization CPU inference के लिए आवश्यक memory को कम करता है। Apple Silicon Macs पर यह MLX engine के माध्यम से safetensors-आधारित models को भी चला सकता है, और v0.40.0 (सितंबर 2026) के बाद से समर्थित architectures वहां स्वचालित रूप से MLX पर चलते हैं।

इसका GGUF runner llama.cpp पर आधारित है, जो कि वह C++ inference library है जिसने सामान्य hardware पर GGUF quantization को व्यावहारिक बनाया। अक्टूबर 2026 तक, Ollama दो engines, llama.cpp और MLX को support करता है, और Linux builds CUDA के साथ MLX inference को भी support करती हैं। development guide उस backend को cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 के साथ सक्षम करती है, जिसके लिए CUDA 13+ और cuDNN 9+ की आवश्यकता होती है। इसलिए जब लोग Ollama की तुलना llama.cpp से करते हैं, तो वे मुख्य रूप से एक ergonomics layer की तुलना उस चीज़ से कर रहे होते हैं जिसे वह wrap करती है।

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

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

vLLM केवल एक inference server है और कुछ नहीं। यह model library को manage नहीं करता है, यह चल रहे server के लिए एक vllm chat client प्रदान करता है, और यह अनुरोध (request) के समय आपके लिए model pull नहीं करेगा। आप launch के समय एक Hugging Face repository का नाम देते हैं, यह उस एक model को load करता है, और जब तक आप process को रोकते नहीं हैं, तब तक यह उसे serve करता है।

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

व्यावहारिक परिणाम: एक single GPU पर, एक concurrent user से तीस पर जाने पर प्रति सेकंड कुल tokens की संख्या तेजी से बढ़ती है, जबकि प्रति-user गति आपकी अपेक्षा से बहुत कम गिरती है। Ollama के default के तहत, एक user से तीस पर जाने का मतलब केवल उन उनतीस लोगों का इंतजार करना है।

Continuous batching ही मुख्य अंतर है

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

डिफ़ॉल्ट सेटिंग्स के साथ Ollama पहली request को पूरा होने तक चलाता है, फिर दूसरी को, और इसी तरह आगे बढ़ता है। पांचवें कॉलर को चार पूर्ण generations का इंतज़ार करना पड़ता है। कुल throughput लगभग एक generation की गति के बराबर होता है, क्योंकि प्रोसेसर एक समय में केवल एक sequence पर काम कर रहा होता है।

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

आप OLLAMA_NUM_PARALLEL=4 सेट करके इसका कुछ लाभ प्राप्त कर सकते हैं। इसकी कीमत मेमोरी है। प्रत्येक parallel slot को अपने स्वयं के KV cache की आवश्यकता होती है, और Ollama context allocation को विभाजित करने के बजाय उसे multiply करता है: इसके FAQ के अनुसार आवश्यक RAM OLLAMA_NUM_PARALLEL गुना OLLAMA_CONTEXT_LENGTH के अनुपात में बढ़ती है। इसलिए 8192 tokens के लिए कॉन्फ़िगर किए गए मॉडल के विरुद्ध चार parallel requests प्रत्येक में 8192 tokens रखती हैं, लेकिन बॉक्स को कुल मिलाकर 32768 tokens के लिए cache रखना पड़ता है। वह 8192 स्वयं एक विकल्प है न कि कोई निश्चित मान, इसलिए num_ctx बढ़ाना और इसके लिए आवश्यक RAM का निर्धारण करना वह कदम है जो यह तय करता है कि क्या चार slots फिट होंगे या नहीं। vLLM का paged cache वह तकनीक है जो हर slot के लिए पूरी window को पहले से reserve करने से बचाती है, क्योंकि blocks को request के बढ़ने के साथ ही allocate किया जाता है। किसी भी स्थिति में, एक बॉक्स एक बार में कितने लोगों को सेवा दे सकता है, इसकी सीमा KV cache size, prefill cost और queue depth पर निर्भर करती है, जो कि कारण है कि जो सर्वर एक व्यक्ति के लिए ठीक काम करता है, वह पांच लोगों के आने पर धीमा हो जाता है।

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 सिस्टम यूजर बनाती है, बाइनरी इंस्टॉल करती है, और 127.0.0.1:11434 से बाउंड ollama.service को रजिस्टर करती है। --verbose द्वारा प्रिंट की गई eval rate लाइन उस बॉक्स पर आपकी वास्तविक टोकन प्रति सेकंड की गति है। किसी भी प्रकाशित आंकड़े के बजाय इस पर भरोसा करें। एक प्रॉम्प्ट से लिया गया एक रीडिंग क्षमता संख्या के बजाय एक शुरुआती बिंदु है, इसलिए concurrency sweep के दौरान टोकन प्रति सेकंड की टाइमिंग ही आपको बताती है कि क्या बॉक्स आपके अपेक्षित लोड को संभाल सकता है, और क्या GPU किराए पर लेना प्रति टोकन भुगतान करने से बेहतर है।

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

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 के धीमे होने की अधिकांश रिपोर्टों का वास्तविक कारण है। उस drop-in में OLLAMA_KEEP_ALIVE=30m लाइन एक शांत बॉक्स पर भी उतनी ही मायने रखती है, क्योंकि डिफ़ॉल्ट सेटिंग पांच मिनट तक कोई अनुरोध न आने पर मॉडल को अनलोड कर देती है, और अनुरोधों के बीच मॉडल को रेजिडेंट रखना ही वह तरीका है जिससे आधे घंटे तक के अंतराल के बाद पहले प्रॉम्प्ट पर पूरा लोड टाइम दोबारा नहीं देना पड़ता। यदि आपके शांत रहने का समय उससे अधिक है, तो एक लंबा मान सेट करें।

vLLM को इंस्टॉल करना और सर्व करना

vLLM के GPU बिल्ड के लिए Linux की आवश्यकता होती है (Apple Silicon पर macOS में 0.32.0 release में प्रीबिल्ट व्हील के साथ केवल CPU सपोर्ट है, और उन Macs पर GPU एक्सेलेरेशन MLX पर आधारित एक अलग कम्युनिटी-मेंटेंड प्लगइन, vLLM-Metal से आता है)। Python पर, वर्तमान release (0.32.0, अक्टूबर 2026) 3.11 से 3.14 तक को स्वीकार करता है, और इंस्टॉल गाइड में भी यही रेंज दी गई है। Python 3.10 को 0.32.0 में हटा दिया गया था, इसलिए नीचे उपयोग किया गया 3.12 एक सुरक्षित विकल्प है। इसे अपने स्वयं के वर्चुअल एनवायरनमेंट में इंस्टॉल करें, क्योंकि यह एक विशिष्ट PyTorch बिल्ड को पुल करता है:

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

अंतिम लाइन अक्टूबर 2026 तक vLLM की NVIDIA इंस्टॉल गाइड में दी गई है। यह FlashInfer के प्रीकंपाइल्ड कर्नेल को इंस्टॉल करती है। इनके बिना, vLLM स्टार्टअप के समय कर्नेल को डाउनलोड और कंपाइल करता है, जो गाइड के अनुसार Hopper और नए GPU पर कई मिनट का समय ले सकता है। हर vLLM अपग्रेड के बाद इसे फिर से चलाएं, क्योंकि कर्नेल मैच न होने पर FlashInfer इम्पोर्ट होने से मना कर देता है।

फिर एक मॉडल सर्व करें। नाम एक Hugging Face रिपॉजिटरी आईडी है, न कि कोई छोटा टैग:

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

पहली बार स्टार्टअप धीमा होता है, क्योंकि यह वेट्स (weights) को डाउनलोड करता है और फिर यह तय करने के लिए GPU को प्रोफाइल करता है कि कितने KV कैश ब्लॉक फिट होंगे। यह पोर्ट 8000 पर लिसन करता है। कोई भी क्लाइंट कोड लिखने से पहले इसे चेक करें:

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 पहले से ही बॉक्स पर है, तो आधिकारिक इमेज CUDA डिपेंडेंसी के काम से बचाती है:

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 कंटेनर को होस्ट शेयर्ड मेमोरी तक एक्सेस देता है; --shm-size को बढ़ाना एक अन्य विकल्प है। PyTorch प्रोसेस के बीच टेंसर को शेयर्ड मेमोरी के माध्यम से पास करता है, विशेष रूप से टेंसर-पैरेलल इन्फरेंस के लिए।

प्रोडक्शन में सबसे महत्वपूर्ण फ्लैग्स --max-model-len (वह कॉन्टेक्स्ट विंडो जिसके लिए आप भुगतान करने को तैयार हैं), --gpu-memory-utilization (कार्ड का वह हिस्सा जिसे vLLM क्लेम कर सकता है, अक्टूबर 2026 तक डिफ़ॉल्ट रूप से 0.92), एक मॉडल को कई GPU में विभाजित करने के लिए --tensor-parallel-size, और --api-key हैं।

vLLM पर Authentication एक flag है, जबकि Ollama की local API में यह अनुपस्थित है

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

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

यही मान VLLM_API_KEY environment variable से भी आ सकता है। इसके बिना /v1 routes पर की गई request को HTTP 401 error मिलता है। हालाँकि, यह key पूरे सर्वर को सुरक्षित नहीं करती है। vLLM की security guide और 0.32.0 source code में मौजूद authentication code इसे केवल /v1, /v2, /inference, और /cohere path prefixes के अंतर्गत आने वाले endpoints पर लागू करते हैं। vllm serve page पर मौजूद --api-key help text में केवल पहले तीन का उल्लेख है, लेकिन code चारों की जाँच करता है। guide और help text दोनों का कहना है कि अन्य endpoints, विशेष रूप से /invocations, जो /v1 के समान ही inference expose करता है, authenticated नहीं हैं। यह कारण port 8000 को public interface पर publish न करने के लिए पर्याप्त है। vLLM की security guide rate limiting का कार्य भी अपने सामने स्थित reverse proxy पर छोड़ देती है, और plain HTTP पर भेजा गया token transit के दौरान पढ़ा जा सकता है, लेकिन इस flag का मतलब यह है कि सर्वर के पास caller की पहचान का एक concept मौजूद है।

Ollama की local API को किसी authentication की आवश्यकता नहीं होती है। Cloud models, model publishing, और private model downloads के लिए sign-in अनिवार्य है; ollama.com तक direct API access के लिए API key की आवश्यकता होती है। जो भी process 11434 तक पहुँच सकती है, वह models को run, pull या delete कर सकती है। इसे loopback पर रखें और स्वयं द्वारा host किए गए WireGuard VPN के माध्यम से, या TLS (transport layer security) terminate करने वाले authenticating reverse proxy के जरिए ही access करें।

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

Ollama CPU पर चलता है। 4-bit quantized मॉडल के लिए प्रति बिलियन पैरामीटर लगभग आधा gigabyte RAM की आवश्यकता होती है, साथ ही लगभग एक gigabyte runtime overhead और context के लिए अतिरिक्त जगह चाहिए। इसलिए, एक 3B मॉडल को लगभग 4 GB खाली RAM और एक 8B मॉडल को लगभग 8 GB की आवश्यकता होती है। Shared vCPU पर गति single digit से लेकर low double digit tokens प्रति सेकंड तक होती है। यह memory bandwidth की सीमा है, कोई misconfiguration नहीं, और कोई भी flag इसे ठीक नहीं कर सकता। किसी विशिष्ट release पर इस गणित को देखने के लिए, running Nemotron 3.5 Lightning on a VPS यह स्पष्ट करता है कि कौन सा tag pull करना है, लोड होने के बाद यह कितनी RAM लेता है, और क्या केवल CPU पर चलना आपके उपयोग के लिए पर्याप्त है।

vLLM के लिए GPU अनिवार्य है। इसका default path 16-bit precision पर unquantized weights का उपयोग करता है, जो प्रति बिलियन पैरामीटर लगभग 2 GB होता है: एक 8B मॉडल को केवल weights के लिए लगभग 16 GB video memory चाहिए, और यह KV cache से पहले की आवश्यकता है, जो आपको वह concurrency देता है जिसके लिए आपने vLLM इंस्टॉल किया है। 24 GB के कार्ड पर इसके लिए पर्याप्त cache बच जाती है। 16 GB के कार्ड पर ऐसा नहीं होता, इसलिए आपको या तो छोटा मॉडल चुनना होगा, --quantization पास करना होगा (quantized checkpoint के साथ, या load time पर full-precision weights को quantize करने के लिए), या --cpu-offload-gb के साथ weights का कुछ हिस्सा system RAM में डालना होगा। यह precision तो बनाए रखता है लेकिन धीमा होता है, क्योंकि हर forward pass के दौरान ये weights GPU तक पहुँचते हैं। इसका एक CPU backend भी मौजूद है, जिसके अपने अलग wheels हैं, लेकिन यह vLLM चलाने के उद्देश्य को ही समाप्त कर देता है।

इसलिए, hardware का प्रश्न अधिकांश समय software के प्रश्न का उत्तर दे देता है। यदि GPU नहीं है, तो Ollama का उपयोग करें। यदि किराए पर लिया गया GPU 5 प्रतिशत utilization पर बैठा है क्योंकि 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 होता है।

विफलता के प्रकार और दिखाई देने वाले संदेश

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

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.

मॉडल एक ऐसे context window की घोषणा करता है जो weights लोड करने के बाद बची हुई मेमोरी से बड़ा है। इसे --max-model-len 8192 के साथ कम करें, या यदि कार्ड का उपयोग कोई और नहीं कर रहा है तो --gpu-memory-utilization को बढ़ाएं।

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

Ollama अकेले सही उत्तर देता है लेकिन लोड बढ़ने पर रुक जाता है। कहीं भी कोई त्रुटि नहीं दिखाई देती। जैसे-जैसे callers की संख्या बढ़ती है, अनुरोधों में अधिक समय लगता है क्योंकि OLLAMA_NUM_PARALLEL=1 उन्हें क्रमबद्ध (serialise) कर रहा है। लंबे उत्तर कतार को और खराब कर देते हैं, क्योंकि जब तक मॉडल रुकने का निर्णय नहीं लेता, तब तक एक caller एकमात्र स्लॉट को घेरे रखता है और पीछे के सभी लोगों को ब्लॉक कर देता है। इसलिए num_predict के साथ उत्तर को सीमित करना यह तय करता है कि कोई भी एक टर्न सर्वर को कितनी देर तक रोक सकता है। समानांतर (parallel) सेटिंग बढ़ाएं और प्रत्येक स्लॉट के context के लिए आवश्यक अतिरिक्त RAM को स्वीकार करें, या वर्कलोड को vLLM पर ले जाएं।

vLLM हर /v1 कॉल पर 401 लौटाता है। आपने इसे --api-key के साथ शुरू किया था और क्लाइंट कोई Authorization हेडर नहीं भेज रहा है। अधिकांश OpenAI क्लाइंट लाइब्रेरी वही भेजती हैं जो आप key के रूप में पास करते हैं, इसलिए फ्लैग को हटाने के बजाय उसे वहीं सेट करें।

vLLM कहता है कि मॉडल नहीं मिला। Ollama मांग पर (on demand) पुल करता है, vLLM ऐसा नहीं करता। अनुरोध बॉडी में model फ़ील्ड उस रिपॉजिटरी आईडी से मेल खाना चाहिए जिसके साथ आपने इसे लॉन्च किया था, या यदि आपने कोई मान सेट किया है तो --served-model-name के मान से मेल खाना चाहिए। सटीक स्ट्रिंग की पुष्टि 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 पर एक सिंगल रिक्वेस्ट के लिए अंतर मामूली है, क्योंकि दोनों एक ही गणितीय गणना कर रहे होते हैं। कई concurrent requests के लिए vLLM काफी आगे है, क्योंकि continuous batching हर सक्रिय sequence को एक ही forward pass में decode करती है, जबकि Ollama का डिफ़ॉल्ट उन्हें एक के बाद एक चलाता है। केवल CPU वाली मशीन पर दोनों के पास समर्थित inference paths हैं, जिसमें vLLM अलग CPU wheels का उपयोग करता है।

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

हाँ, इसके CPU backend के माध्यम से। स्टैंडर्ड wheels NVIDIA या AMD GPUs को टारगेट करते हैं, और vLLM के अस्तित्व का मुख्य कारण—batched requests के साथ accelerator को saturated रखना—CPU पर समाप्त हो जाता है। एक CPU backend मौजूद है, जिसमें x86 और Arm के लिए अलग wheels हैं। वास्तविक CPU inference के लिए सीधे Ollama या llama.cpp का उपयोग करें।

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

llama.cpp एक inference लाइब्रेरी है, और GGUF इसका quantized weight फॉर्मेट है। Ollama इसका उपयोग GGUF inference के लिए करता है और साथ ही एक मॉडल रजिस्ट्री, टैग किए गए डाउनलोड, मॉडल मैनेजमेंट और एक systemd यूनिट जोड़ता है। Ollama एक MLX इंजन भी प्रदान करता है जो Apple Silicon पर safetensors-आधारित मॉडल चलाता है और Linux पर CUDA बिल्ड्स को सपोर्ट करता है, इसलिए दोनों अंदरूनी तौर पर हमेशा एक जैसे नहीं होते।

8B मॉडल के लिए vLLM को कितनी GPU मेमोरी चाहिए?

16-bit precision पर केवल weights लगभग 16 GB के होते हैं, जो प्रति बिलियन पैरामीटर लगभग 2 GB है, और KV cache के लिए इसके ऊपर अतिरिक्त जगह की आवश्यकता होती है। 24 GB का कार्ड पर्याप्त है। 16 GB के कार्ड के लिए एक quantized मॉडल, एक छोटा मॉडल, या weights के कुछ हिस्से को सिस्टम RAM में ले जाने के लिए --cpu-offload-gb की आवश्यकता होती है, जिसकी कीमत गति में चुकानी पड़ती है। vLLM कार्ड का एक हिस्सा --gpu-memory-utilization द्वारा निर्धारित करता है, जो अक्टूबर 2026 तक डिफ़ॉल्ट रूप से 0.92 रहता है।

क्या मुझे इनके बीच स्विच करने के लिए अपने एप्लिकेशन कोड को बदलने की आवश्यकता है?

आमतौर पर केवल base URL, API key और मॉडल का नाम बदलना होता है। Ollama अपनी OpenAI-compatible सर्विस http://127.0.0.1:11434/v1 पर प्रदान करता है और key को अनदेखा करता है, जबकि vLLM http://localhost:8000/v1 पर सर्विस देता है और यदि आप कोई key सेट करते हैं तो यह अपने /v1 रूट्स पर उसे लागू करता है। मॉडल के नाम के प्रारूप अलग-अलग होते हैं: Ollama के लिए llama3.1:8b, और vLLM के लिए पूरा रिपॉजिटरी आईडी जैसे कि Qwen/Qwen2.5-1.5B-Instruct।