Ollama विरुद्ध vLLM: कोणता LLM server वापरावा?

Ollama विरुद्ध vLLM, एका परिच्छेदात

Ollama हे server जोडलेले model manager आहे: ते quantized weights डाउनलोड करून load करते आणि 127.0.0.1:11434 वर उत्तर देते; मशीनमध्ये CPU शिवाय दुसरे काही नसेल, तरी ते CPU वर चालते. vLLM हे throughput engine आहे: ते एकाच वेळी चालणाऱ्या अनेक requests द्वारे GPU चा पूर्ण उपयोग करून घेते. GPU नसलेल्या मशीनवर vLLM हे योग्य साधन नाही. निर्णय इतकाच आहे. स्थानिक assistant शी संवाद साधणाऱ्या एका व्यक्तीचे काम Ollama साठी योग्य आहे. एखाद्या team ला सेवा देणारे 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 जागा घेतो. CPU inference शक्य होण्यामागे quantization हेच कारण आहे.

त्याचा runner हा llama.cpp वर आधारित आहे. llama.cpp ही C++ inference library आहे. तिने सामान्य hardware वर GGUF quantization व्यावहारिक केले. त्यानंतर Ollama ने काही नवीन model families साठी स्वतःचे engine जोडले आहे. तरीही तो उपलब्ध करून देत असलेल्या बहुतांश गोष्टींच्या पायाभूत स्तरावर llama.cpp अजूनही आहे. त्यामुळे Ollama आणि llama.cpp यांची तुलना करताना प्रत्यक्षात ergonomics layer आणि तो ज्या घटकाभोवती wrapper म्हणून काम करतो त्या घटकाची तुलना केली जाते.

ही रचना एका user साठी उद्दिष्टित आहे. July 2026 पर्यंत OLLAMA_NUM_PARALLEL साठी default 1 आहे. याचा अर्थ एक model एका वेळी एक request process करतो आणि इतर सर्व requests default नुसार 512 entries असलेल्या queue मध्ये प्रतीक्षा करतात (OLLAMA_MAX_QUEUE). तुम्ही parallel setting वाढवू शकता. त्याची किंमत काय असेल हे पुढील section मध्ये स्पष्ट केले आहे. तुम्ही यापूर्वी Ollama चालवले नसेल, तर VPS वर Ollama host करणे आणि port 11434 बंद ठेवणे यापासून सुरुवात करा. कारण API मध्ये कोणत्याही प्रकारचे authentication नाही.

vLLM नेमके काय आहे

vLLM हा केवळ inference server आहे. तो model library व्यवस्थापित करत नाही, त्यामध्ये chat prompt नाही आणि request येताना तो तुमच्यासाठी model download करणार नाही. सुरू करताना तुम्ही Hugging Face repository चे नाव देता. vLLM तो एकच model load करतो आणि process थांबवेपर्यंत तो उपलब्ध करून देतो.

या मर्यादित कार्यक्षेत्राचा फायदा म्हणजे throughput. हे काम दोन mechanisms करतात. PagedAttention KV cache (key-value cache; प्रत्येक active request साठी model जतन करत असलेली प्रत्येक token ची attention state) fixed-size blocks मध्ये साठवते. ही पद्धत operating system memory page करण्यासारखी आहे. आता request साठी worst case नुसार आकाराची एक मोठी सलग memory reservation आवश्यक राहत नाही. त्यामुळे आधी reserved पण वापरात नसलेली memory अधिक concurrent requests साठी उपलब्ध होते. Continuous batching मुळे नवीन request ला सध्या चालू असलेल्या batch मध्ये पुढील decoding step वेळी सहभागी होता येते. सध्याचा batch पूर्ण होण्याची प्रतीक्षा करावी लागत नाही. एखादी sequence पूर्ण झाल्यावर ती त्वरित batch मधून बाहेर पडते आणि तिची जागा पुन्हा भरली जाते.

याचा व्यावहारिक परिणाम असा होतो: single GPU वर concurrent users ची संख्या एकवरून तीस केली, तर एकूण tokens per second लक्षणीयरीत्या वाढतात; मात्र प्रत्येक user साठीचा वेग अपेक्षेपेक्षा खूपच कमी घटतो. Ollama च्या default वर्तनात user ची संख्या एकवरून तीस केली, तर उर्वरित एकोणतीस जणांना फक्त प्रतीक्षा करावी लागते.

Continuous batching हाच संपूर्ण फरक आहे

समान हार्डवेअरवर प्रत्येक सर्व्हरकडे एकाच वेळी पाच विनंत्या आल्याची कल्पना करा.

Ollama च्या default settings मध्ये पहिली विनंती पूर्ण होईपर्यंत चालवली जाते. त्यानंतर दुसरी, आणि पुढे अशीच प्रक्रिया सुरू राहते. पाचव्या caller ला चार पूर्ण generations पूर्ण होईपर्यंत प्रतीक्षा करावी लागते. एकूण throughput साधारणपणे एका generation च्या वेगाइतकीच असते, कारण processor एका वेळी फक्त एकाच sequence वर काम करत असतो.

vLLM सर्व पाच sequences चा decode एकाच forward pass मध्ये करतो. एका sequence साठी एक token generate करण्यापेक्षा पाच sequences साठी एक token generate करण्याचा खर्च फारसा जास्त नसतो. कारण महागडा भाग म्हणजे model weights memory मधून वाचणे, आणि हा read संपूर्ण batch मध्ये share केला जातो. CPU inference मंद का असते हे स्पष्ट करणारा हाच memory-bandwidth संबंध आहे: खर्च arithmetic साठी नव्हे, तर weights हलवण्यासाठी होतो.

तुम्ही OLLAMA_NUM_PARALLEL=4 सेट करून यातील काही फायदा मिळवू शकता. मात्र त्यासाठी memory लागते. प्रत्येक parallel slot साठी स्वतंत्र KV cache आवश्यक असतो. तसेच Ollama context window slots मध्ये विभागतो. त्यामुळे 8192 tokens साठी configured केलेल्या model विरुद्ध चार parallel requests चालवल्यास प्रत्येक request ला 2048 tokens चे context मिळते. हे 8192 देखील निश्चित मर्यादा नसून निवड आहे. त्यामुळे num_ctx वाढवणे आणि त्यासाठी लागणारी RAM ठरवणे हे चार slots प्रत्यक्षात वापरता येतील की नाही हे ठरवणारे पाऊल आहे. vLLM मधील paged cache हा trade-off टाळतो, कारण request प्रत्यक्षात वाढत जाईल तसे blocks त्या request ला allocate केले जातात. कोणत्याही परिस्थितीत, एकाच box कडून एकाच वेळी किती लोकांना सेवा देता येईल याची कमाल मर्यादा 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 इन्स्टॉल करते आणि ollama.service ची नोंदणी करते. हे 127.0.0.1:11434 शी bound असते. --verbose ने छापलेली eval rate ओळ त्या मशीनवरील तुमचा प्रत्यक्ष tokens per second दर दर्शवते. प्रकाशित केलेल्या कोणत्याही आकडेवारीपेक्षा या मूल्यावर विश्वास ठेवा. एका prompt वरचे एक मोजमाप ही सुरुवात आहे; ते क्षमतेचे अंतिम मोजमाप नाही. त्यामुळे वेगवेगळ्या concurrency स्तरांवर tokens per second मोजणे यामुळे मशीन अपेक्षित 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 मध्ये कोणते configuration load झाले आहे ते दिसते आणि त्यातील PROCESSOR column प्रत्यक्ष स्थिती दाखवतो. 100% CPU म्हणजे GPU वापरला जात नाही. Ollama धीमे असल्याच्या बहुतेक अहवालांचे हेच वास्तव कारण असते. त्या drop-in मधील OLLAMA_KEEP_ALIVE=30m ओळ शांतपणे वापरल्या जाणाऱ्या मशीनवरही तितकीच महत्त्वाची आहे. Request नसल्यास default configuration पाच मिनिटांनंतर model unload करते. त्यामुळे requests दरम्यान model memory मध्ये ठेवणे आवश्यक आहे. यामुळे तासभर idle राहिल्यानंतरच्या पहिल्या prompt वेळी model पुन्हा पूर्णपणे load करण्याचा वेळ लागत नाही.

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 करा. येथील नाव हे short tag नसून Hugging Face repository id आहे:

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

पहिल्यांदा सुरू होण्यास वेळ लागतो, कारण vLLM प्रथम weights डाउनलोड करते आणि त्यानंतर किती KV cache blocks उपलब्ध GPU memory मध्ये बसतील हे ठरवण्यासाठी GPU चे profiling करते. ते 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?"}]}'

सर्व्हरवर Docker आधीपासून असल्यास, अधिकृत 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 वापरते आणि tensor-parallel inference साठी default Docker shared-memory allocation अपुरी असते.

Production मध्ये सर्वाधिक महत्त्वाचे flags म्हणजे --max-model-len (तुम्ही देय असलेली context window), --gpu-memory-utilization (vLLM वापरू शकणाऱ्या GPU memory चा भाग; July 2026 नुसार default 0.92), --tensor-parallel-size (एक model अनेक GPUs वर विभाजित करण्यासाठी) आणि --api-key.

vLLM मध्ये authentication साठी एक flag आहे, पण Ollama मध्ये ते उपलब्ध नाही

vLLM ला bearer token दिल्यास तो token अनिवार्य करते:

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

हीच value VLLM_API_KEY environment variable मधूनही देता येते. हा token नसलेली request HTTP 401 मिळवते. तरीही port 8000 public interface वर publish करण्याचे हे कारण नाही, कारण vLLM मध्ये rate limiting नाही आणि plain HTTP token नेटवर्कमधून प्रवास करताना वाचता येतो. मात्र, यामुळे server कडे caller ची संकल्पना आहे.

Ollama मध्ये अशी कोणतीही सुविधा नाही. Key नाही, login नाही आणि allow-list नाही. 11434 पर्यंत पोहोचू शकणारी कोणतीही process models run, pull किंवा delete करू शकते. ते loopback वरच ठेवा आणि तुम्ही स्वतः host केलेल्या WireGuard VPN द्वारे, किंवा TLS (transport layer security) terminate करणाऱ्या authentication असलेल्या reverse proxy द्वारे त्याच्यापर्यंत पोहोचा.

हार्डवेअर: प्रत्येकाला कशाची आवश्यकता आहे

Ollama CPU वर चालते. 4-bit quantized model साठी प्रत्येक billion parameters मागे साधारण अर्धा gigabyte RAM लागतो. याशिवाय सुमारे एक gigabyte runtime overhead आणि context साठी अधिक RAM लागते. त्यामुळे 3B model साठी सुमारे 4 GB मोकळी RAM आणि 8B model साठी सुमारे 8 GB मोकळी RAM आवश्यक असते. Shared vCPU वर वेग single digit ते low double digit tokens per second इतका असतो. हे memory bandwidth मुळे होते; ही misconfiguration नाही. कोणताही flag याची दुरुस्ती करू शकत नाही. अंदाजावर अवलंबून न राहता एखाद्या विशिष्ट release वर ही गणना प्रत्यक्ष पाहायची असल्यास, VPS वर Nemotron 3.5 Lightning चालवणे यात pull करण्यासाठीचा अचूक tag, model load झाल्यानंतर तो व्यापणारी RAM आणि CPU-only वापर पुरेसा जलद आहे का हे स्पष्ट केले आहे.

vLLM साठी GPU गृहीत धरला जातो. त्याचा default path 16-bit precision मधील unquantized weights serve करतो. यासाठी प्रत्येक billion parameters मागे साधारण 2 GB video memory लागते. त्यामुळे 8B model साठी केवळ weights साठी सुमारे 16 GB video memory आवश्यक असते. तुम्ही vLLM साठी concurrency मिळवण्यासाठी install केलेल्या KV cache साठीची memory यामध्ये समाविष्ट नाही. 24 GB card वर cache साठी वापरता येईल इतकी memory उरते. 16 GB card वर ती उरत नाही. त्यामुळे तुम्हाला smaller model निवडावा लागतो किंवा quantized checkpoint सोबत --quantization द्यावे लागते. CPU backend उपलब्ध आहे. मात्र standard wheels त्यासाठी build केलेले नाहीत. तसेच vLLM चालवण्यामागील मुख्य कारणच त्यामुळे नष्ट होते.

त्यामुळे बहुतांश वेळा hardware चा प्रश्नच software च्या निवडीचे उत्तर देतो. GPU नसेल तर Ollama वापरा. भाड्याने घेतलेला GPU requests serialise होत असल्यामुळे 5 percent utilisation वर असेल, तर vLLM वापरा.

तुमच्या workload साठी कोणता पर्याय

• एका व्यक्तीसाठी, CPU VPS वर drafting आणि summarising करण्यासाठी: Ollama. त्याचा वेग स्वीकारार्ह आहे आणि यापेक्षा सोपे काहीही नाही.
• coding assistant किंवा तुमची साधने local model शी जोडणारा MCP server, जो फक्त तुम्ही वापरता: 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: उच्च --max-num-seqs सह vLLM. येथे throughput हेच महत्त्वाचे metric आहे; प्रत्येक document साठीची latency महत्त्वाची नाही.
• एकाच वेळी अनेक self-hosted AI agents model ला requests पाठवणारे 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.

weights लोड केल्यानंतर उरलेल्या memory पेक्षा model ने घोषित केलेली context window मोठी आहे. --max-model-len 8192 वापरून ती कमी करा किंवा card वर इतर कोणतीही प्रक्रिया memory वापरत नसेल, तर --gpu-memory-utilization वाढवा. utilisation सुमारे 0.95 पेक्षा जास्त वाढवल्यास हा startup error टाळला जाऊ शकतो, पण load असताना नंतर CUDA out-of-memory crash होण्याची शक्यता वाढते. या दोनपैकी तो अधिक गंभीर प्रकार आहे.

Ollama generation सुरू असताना Killed दाखवतो. Linux out-of-memory killer ने process थांबवला, कारण model ला या box मध्ये उपलब्ध RAM पेक्षा जास्त RAM आवश्यक होती. sudo dmesg | grep -i oom वापरून याची खात्री करा. यावर उपाय म्हणजे कमी आकाराचे किंवा अधिक quantized model वापरणे. ही setting बदलण्याची समस्या नाही.

एकट्याने चालवताना Ollama नीट उत्तर देतो, पण load असताना अडकतो. कुठेही error दिसत नाही. अधिक callers असतील, तसतसा प्रत्येक request ला जास्त वेळ लागतो, कारण OLLAMA_NUM_PARALLEL=1 त्यांना serialise करतो. मोठी उत्तरे queue अधिक लांब करतात. model थांबण्याचा निर्णय घेईपर्यंत एक caller एकमेव slot वापरत राहतो आणि त्यामागील सर्व callers थांबतात. त्यामुळे num_predict वापरून उत्तराची कमाल लांबी निश्चित करणे यामुळे एकाच turn मध्ये server किती वेळ व्यापला जाऊ शकतो यावर मर्यादा येते. parallel setting वाढवा आणि प्रत्येक request साठी कमी context स्वीकारा किंवा workload vLLM कडे हलवा.

vLLM प्रत्येक call वर 401 परत करतो. तुम्ही ते --api-key सह सुरू केले, पण client कोणतेही Authorization header पाठवत नाही. बहुतेक OpenAI client libraries तुम्ही key म्हणून दिलेली कोणतीही value पाठवतात. त्यामुळे flag काढून टाकण्याऐवजी key तिथेच set करा.

vLLM model सापडत नसल्याचे सांगतो. Ollama मागणीनुसार model pull करतो; vLLM तसे करत नाही. Request body मधील model field तुम्ही launch केलेल्या repository id शी जुळला पाहिजे किंवा --served-model-name set केले असल्यास त्याच्या value शी जुळला पाहिजे. curl http://localhost:8000/v1/models वापरून अचूक string तपासा.

दोन्ही चालवणे हा व्यवहार्य पर्याय आहे

हे परस्परविरोधी पर्याय नाहीत. एक सामान्य रचना अशी असते: अॅप्लिकेशनला सेवा देण्यासाठी GPU instance वर vLLM चालवणे आणि त्याच्याजवळील सामान्य VPS वर स्थानिक scripts, cron jobs आणि नवीन model releases तपासण्यासाठी Ollama चालवणे. दोन्ही endpoints OpenAI-compatible आहेत. त्यामुळे एकच client library आणि base-URL बदल पुरेसा असतो. येथे कोणतेही engine निवडण्यापेक्षा खर्च नियंत्रण अधिक महत्त्वाचे आहे, कारण निष्क्रिय GPU साठीही व्यस्त GPU इतकाच billing होतो. तसेच agent आणि inference costs अंदाजे व नियंत्रणात ठेवणे ही server निवडण्यापेक्षा वेगळी शिस्त आहे.

FAQ

vLLM हे Ollama पेक्षा जलद आहे का?

समान GPU वर एकच विनंती असल्यास फरक मर्यादित असतो, कारण दोन्ही समान गणिती प्रक्रिया करतात. अनेक समांतर विनंत्यांसाठी vLLM बरेच पुढे आहे, कारण continuous batching प्रत्येक सक्रिय sequence चे decoding एका forward pass मध्ये करते, तर Ollama चे default त्यांना एकामागोमाग एक चालवते. फक्त CPU असलेल्या मशीनवर हा प्रश्न लागू होत नाही: Ollama तेथे चालते, पण vLLM प्रत्यक्षात चालत नाही.

vLLM GPU शिवाय चालू शकते का?

उपयुक्त पद्धतीने नाही. Standard wheels NVIDIA किंवा AMD GPU साठी तयार केलेली असतात. Batched requests द्वारे accelerator सतत व्यस्त ठेवणे हे vLLM चे मुख्य उद्दिष्ट आहे; CPU वर ते उद्दिष्ट साध्य होत नाही. Development कामासाठी 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. काही नवीन model families साठी Ollama ने स्वतःचे engine जोडले आहे. त्यामुळे अंतर्गत रचनेत दोन्ही आता पूर्णपणे समान नाहीत.

8B model साठी vLLM ला किती GPU memory आवश्यक आहे?

16-bit precision मध्ये केवळ weights साठी सुमारे 16 GB लागतात, म्हणजे प्रत्येक billion parameters साठी साधारण 2 GB. याव्यतिरिक्त KV cache साठीही जागा आवश्यक असते. 24 GB कार्ड पुरेसे असते. 16 GB कार्डसाठी quantized checkpoint किंवा त्यापेक्षा लहान model आवश्यक आहे. vLLM कार्डच्या 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 वापरला जातो.