Ollama की vLLM: LLM server कोणता वापरावा?

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

Ollama हे त्याला सर्व्हर जोडलेले मॉडेल व्यवस्थापक आहे: ते quantized weights डाउनलोड करून लोड करते आणि 127.0.0.1:11434 वर उत्तर देते; मशीनमध्ये CPU एवढेच उपलब्ध असल्यास ते CPU वापरते. vLLM हे throughput engine आहे: ते एकाच वेळी चालणाऱ्या अनेक विनंत्यांद्वारे GPU सतत पूर्ण क्षमतेने वापरते. GPU नसलेल्या मशीनवर vLLM हे चुकीचे साधन आहे. निर्णय इतकाच आहे. एखादी व्यक्ती स्थानिक assistant शी संवाद साधत असल्यास ते Ollama चे काम आहे. एखादे application टीमसाठी सेवा देत असल्यास ते vLLM चे काम आहे.

दोन्ही OpenAI-compatible HTTP API वापरतात. त्यामुळे base URL बदलून client code एका साधनातून दुसऱ्यात हलवता येतो. API हा फरक नाही. पहिली विनंती tokens तयार करत असताना दुसरी विनंती आल्यावर काय होते, हा फरक आहे.

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 quantization केलेले असते. त्यामुळे 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 आणि तो ज्या घटकाला wrap करतो त्यांची तुलना केली जाते.

ही रचना एका 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 आणत नाही. सुरू करताना तुम्ही Hugging Face repository निर्दिष्ट करता. vLLM तोच एक model load करतो आणि तुम्ही process थांबवेपर्यंत तो serve करतो.

या मर्यादित कार्यक्षेत्राचा लाभ म्हणजे throughput. हे काम दोन यंत्रणा करतात. PagedAttention KV cache (key-value cache; प्रत्येक active request साठी model जतन करत असलेली प्रत्येक token ची attention state) निश्चित आकाराच्या blocks मध्ये साठवते. ही पद्धत operating system memory ला pages मध्ये व्यवस्थापित करते त्यासारखी आहे. आता 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 मध्ये users ची संख्या एकवरून तीस केली, तर फक्त एकोणतीस जणांना प्रतीक्षा करावी लागते.

सतत बॅचिंग हाच संपूर्ण फरक आहे

समान हार्डवेअरवर प्रत्येक server वर एकाच वेळी पाच requests येत आहेत, अशी कल्पना करा.

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

vLLM एकाच forward pass मध्ये सर्व पाच sequences decode करते. पाच sequences साठी एक token generate करण्याचा खर्च एका sequence साठी एक token generate करण्यापेक्षा फारसा जास्त नसतो. याचे कारण म्हणजे महागडा भाग model weights memory मधून वाचणे हा असतो आणि हा read संपूर्ण batch मध्ये share केला जातो. CPU inference slow होण्यामागे हेच 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 उरतो. vLLM चे paged cache हा trade टाळते, कारण request प्रत्यक्षात वाढत जाईल तसे 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 ला bind केलेली ollama.service नोंदवते. --verbose ने दाखवलेली eval rate ओळ त्या संगणकावरील प्रत्यक्ष tokens per second दर्शवते. प्रकाशित केलेल्या कोणत्याही आकडेवारीपेक्षा या मूल्यावर विश्वास ठेवा.

समांतर विनंत्यांची संख्या वाढवण्यासाठी 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 ची सेवा सुरू करा. येथे दिलेले नाव हे Hugging Face repository id आहे, लघु tag नाही:

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

पहिल्यांदा startup होण्यास वेळ लागतो, कारण vLLM प्रथम 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?"}]}'

सिस्टमवर 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 (vLLM वापरू शकणाऱ्या card च्या memory चा अंश; 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 सार्वजनिक interface वर उघडण्याचे हे कारण नाही, कारण vLLM मध्ये rate limiting नाही आणि साधा HTTP token वाहतुकीदरम्यान वाचता येतो. मात्र, यामुळे server ला विनंती करणाऱ्या घटकाची संकल्पना मिळते.

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

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

Ollama CPU वर चालते. 4-bit quantized model साठी प्रति billion parameters साधारण अर्धा gigabyte RAM लागतो. याशिवाय runtime overhead साठी सुमारे 1 gigabyte आणि 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 ही समस्या दूर करू शकत नाही.

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

म्हणून hardware संबंधी प्रश्न बहुतेक वेळा software संबंधी प्रश्नाचे उत्तर देतो. GPU नसेल तर Ollama वापरा. Requests serialised असल्यामुळे rented GPU केवळ 5 percent utilisation वर चालत असेल तर vLLM वापरा.

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

• एक वापरकर्ता, CPU VPS, मसुदे तयार करणे आणि सारांश बनवणे: Ollama. वेग स्वीकारार्ह आहे आणि यापेक्षा सोपे काहीही नाही.
• कोडिंग सहाय्यक किंवा तुमची साधने स्थानिक मॉडेलशी जोडणारा MCP server, ज्याला फक्त तुम्ही कॉल करता: Ollama. एकाच वेळी एकच विनंती हा वास्तविक कार्यभार आहे.
• या आठवड्यात पाच मॉडेलची तुलना करायची असल्यास: Ollama. टॅग केलेली मॉडेल्स डाउनलोड करून हटवणे हे त्याचे मुख्य सामर्थ्य आहे, तर vLLM मध्ये प्रत्येक मॉडेलसाठी process restart आवश्यक असतो.
• अंतर्गत app, chat product किंवा वास्तविक वापरकर्ते असलेली retrieval pipeline: vLLM. batching मुळे GPU bill खर्च करणे येथे योग्य ठरते.
• रात्रीच्या वेळी एक लाख documents चे मूल्यमापन करणारे batch job: उच्च --max-num-seqs सह vLLM. Throughput हाच महत्त्वाचा निकष आहे; प्रत्येक document साठी latency महत्त्वाची नाही.
• एकाच वेळी अनेक self-hosted AI agents मॉडेलला विनंती करणारे 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 लोड केल्यानंतर उपलब्ध राहिलेल्या मेमरीपेक्षा model ने घोषित केलेली context window मोठी आहे. --max-model-len 8192 वापरून ती कमी करा किंवा card वर दुसरे कोणतेही काम चालू नसल्यास --gpu-memory-utilization वाढवा. Utilisation सुमारे 0.95 पेक्षा जास्त केल्यास ही startup त्रुटी टाळली जाऊन नंतर 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 अंतर्गत थांबतो. कुठेही त्रुटी दिसत नाही. Call करणाऱ्यांची संख्या वाढत गेल्यावर requests अधिक वेळ घेतात, कारण OLLAMA_NUM_PARALLEL=1 त्यांना serialise करत आहे. ते वाढवा आणि प्रत्येक request साठी उपलब्ध context कमी होईल हे स्वीकारा, किंवा workload vLLM वर हलवा.

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

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

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

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

FAQ

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

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

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

व्यावहारिकदृष्ट्या नाही. मानक wheels NVIDIA किंवा AMD GPUs साठी असतात. Batched requests द्वारे accelerator सतत कार्यरत ठेवणे हा vLLM चा मुख्य उद्देश आहे; CPU वर हा उद्देश साध्य होत नाही. विकासकामांसाठी CPU backend उपलब्ध आहे. प्रत्यक्ष CPU inference साठी Ollama किंवा llama.cpp थेट वापरा.

Ollama आणि llama.cpp मध्ये काय फरक आहे?

llama.cpp ही inference library आहे आणि GGUF हे तिचे quantized weight format आहे. Ollama चा runner तिच्यावर आधारित आहे. त्यासोबत llama.cpp मध्ये तुम्हाला स्वतः हाताळावी लागणारी काही कार्ये Ollama देते: 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 card पुरेसा असतो. 16 GB card साठी quantized checkpoint किंवा त्यापेक्षा लहान model आवश्यक आहे. vLLM card च्या --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.