Ollama बनाम vLLM: आपके लिए कौन सा LLM सर्वर सही है?

Ollama बनाम vLLM, एक पैराग्राफ में

Ollama एक मॉडल मैनेजर है जिसके साथ एक सर्वर जुड़ा होता है: यह quantized weights को डाउनलोड करता है, उन्हें लोड करता है, और 127.0.0.1:11434 पर जवाब देता है, भले ही मशीन में केवल CPU उपलब्ध हो। vLLM एक थ्रूपुट इंजन है: यह एक साथ कई requests को प्रोसेस करके GPU का पूर्ण उपयोग सुनिश्चित करता है, और बिना GPU वाली मशीन पर इसका उपयोग करना गलत है। निर्णय का आधार केवल यही है। यदि कोई व्यक्ति स्थानीय स्तर पर किसी असिस्टेंट का उपयोग कर रहा है, तो Ollama सही विकल्प है। यदि कोई एप्लिकेशन किसी पूरी टीम को सेवा दे रही है, तो vLLM का उपयोग करना चाहिए।

दोनों ही OpenAI-compatible HTTP API का समर्थन करते हैं, इसलिए बेस URL बदलकर क्लाइंट कोड को आसानी से एक से दूसरे पर स्विच किया जा सकता है। अंतर API में नहीं है। मुख्य अंतर तब स्पष्ट होता है जब पहली request के टोकन जनरेट होने के दौरान ही दूसरी request आ जाती है।

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

Ollama एक सुविधा परत (convenience layer) है। यह एक ही install कमांड के माध्यम से आपको एक मॉडल रजिस्ट्री (ollama pull llama3.1:8b), वेट्स (weights) का लोकल स्टोर, एक चैट प्रॉम्प्ट, एक systemd सर्विस और एक HTTP API प्रदान करता है। यह जिन मॉडल्स को सर्व करता है, वे GGUF फाइलें होती हैं, जो आमतौर पर 4-bit क्वांटाइज्ड (quantized) होती हैं। यही कारण है कि 7B या 8B मॉडल डिस्क पर 16 GB के बजाय लगभग 5 GB का होता है। क्वांटाइजेशन ही वह तकनीक है जो CPU पर इन्फरेंस (inference) को संभव बनाती है।

इसका रनर llama.cpp पर आधारित है, जो कि वह C++ इन्फरेंस लाइब्रेरी है जिसने सामान्य हार्डवेयर पर GGUF क्वांटाइजेशन को व्यावहारिक बनाया। Ollama ने तब से कुछ नए मॉडल परिवारों के लिए अपना इंजन जोड़ लिया है, लेकिन llama.cpp अभी भी इसके द्वारा सर्व किए जाने वाले अधिकांश मॉडल्स का आधार है। इसलिए जब लोग Ollama की तुलना llama.cpp से करते हैं, तो वे वास्तव में एक एर्गोनॉमिक्स लेयर की तुलना उस चीज़ से कर रहे होते हैं जिसे वह रैप (wrap) करती है।

इसका डिज़ाइन लक्ष्य एक उपयोगकर्ता है। जुलाई 2026 तक OLLAMA_NUM_PARALLEL के लिए डिफ़ॉल्ट मान 1 है, जिसका अर्थ है कि एक मॉडल एक समय में एक अनुरोध को प्रोसेस करता है और बाकी सब एक कतार में प्रतीक्षा करते हैं, जिसमें डिफ़ॉल्ट रूप से 512 प्रविष्टियाँ होती हैं (OLLAMA_MAX_QUEUE)। आप पैरेलल सेटिंग को बढ़ा सकते हैं, और नीचे दिया गया अनुभाग बताता है कि इसकी क्या कीमत चुकानी पड़ती है। यदि आपने पहले Ollama नहीं चलाया है, तो VPS पर Ollama होस्ट करने और पोर्ट 11434 को बंद रखने से शुरुआत करें, क्योंकि API में किसी भी प्रकार का प्रमाणीकरण (authentication) नहीं होता है।

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

vLLM केवल एक inference server है और कुछ नहीं। यह model library को manage नहीं करता, इसमें कोई chat prompt नहीं है, और यह अनुरोध (request) किए जाने पर आपके लिए model को pull नहीं करेगा। launch के समय आप एक Hugging Face repository का नाम देते हैं, यह उस एक model को load करता है, और जब तक आप process को stop नहीं करते, यह उसे 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 scenario के लिए एक बड़े contiguous reservation की आवश्यकता नहीं होती, इसलिए जो memory पहले reserved और unused रहती थी, वह अब अधिक concurrent requests के लिए उपलब्ध हो जाती है। Continuous batching एक नए request को current batch के समाप्त होने का इंतज़ार करने के बजाय, अगले decoding step पर ही running batch में शामिल होने की अनुमति देता है। एक पूर्ण sequence तुरंत batch से बाहर निकल जाता है और उसका slot भर दिया जाता है।

व्यावहारिक परिणाम यह है: एक single GPU पर, एक concurrent user से तीस users तक जाने पर total tokens per second में भारी वृद्धि होती है, जबकि per-user speed में गिरावट उम्मीद से बहुत कम होती है। Ollama के default settings के तहत, एक user से तीस users तक जाने पर केवल उन उनतीस लोगों को इंतज़ार करना पड़ता है।

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

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

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

vLLM एक ही फॉरवर्ड पास (forward pass) में पांचों को डिकोड करता है। पांच सीक्वेंस के लिए एक टोकन जनरेट करने की लागत एक सीक्वेंस के लिए एक टोकन जनरेट करने से बहुत कम अधिक होती है, क्योंकि सबसे महंगा हिस्सा मेमोरी से मॉडल वेट्स (model weights) को पढ़ना है, और यह रीड (read) पूरे बैच में साझा किया जाता है। यह वही मेमोरी-बैंडविड्थ का तथ्य है जो CPU इन्फरेंस (inference) को धीमा बनाता है: आप वेट्स को मूव करने की कीमत चुकाते हैं, न कि गणितीय गणना की।

आप OLLAMA_NUM_PARALLEL=4 सेट करके इसका कुछ लाभ प्राप्त कर सकते हैं। इसकी कीमत मेमोरी है। प्रत्येक पैरेलल स्लॉट को अपने स्वयं के KV cache की आवश्यकता होती है, और Ollama कॉन्टेक्स्ट विंडो को स्लॉट्स के बीच विभाजित करता है, इसलिए 8192 टोकन के लिए कॉन्फ़िगर किए गए मॉडल पर चार पैरेलल requests प्रत्येक request के लिए 2048 टोकन का कॉन्टेक्स्ट छोड़ती हैं। वह 8192 स्वयं एक विकल्प है न कि कोई निश्चित सीमा, इसलिए num_ctx बढ़ाना और इसके लिए आवश्यक RAM का निर्धारण करना वह कदम है जो यह तय करता है कि चार स्लॉट बिल्कुल उपयोग करने योग्य हैं या नहीं। vLLM का paged cache वह तकनीक है जो इस ट्रेड-ऑफ से बचाती है, क्योंकि ब्लॉक्स को request के वास्तविक रूप से बढ़ने पर ही आवंटित किया जाता है। किसी भी स्थिति में, एक बॉक्स एक बार में कितने लोगों को सर्व कर सकता है, इसकी सीमा KV cache साइज, प्रीफिल कॉस्ट (prefill cost) और क्यू डेप्थ (queue depth) पर निर्भर करती है, जो कि इसका कारण है कि जो सर्वर एक व्यक्ति के लिए ठीक काम कर रहा था, वह पांच लोगों के आने पर धीमा क्यों हो जाता है।

Install and serve with 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."

The install script creates an ollama system user, installs the binary, and registers ollama.service bound to 127.0.0.1:11434. The eval rate line printed by --verbose is your real tokens per second on that box. Trust it over any published figure. One reading from one prompt is a starting point rather than a capacity number, so timing tokens per second across a concurrency sweep is what tells you whether the box holds up at the load you actually expect, and whether renting a GPU beats paying per token.

To raise concurrency, use a systemd drop-in so an upgrade does not overwrite the change:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps shows what is loaded, and its PROCESSOR column tells the truth. 100% CPU means no GPU is involved, which is the honest explanation for most reports that Ollama is slow. The OLLAMA_KEEP_ALIVE=30m line in that drop-in matters just as much on a quiet box, because the default unloads the model after five minutes without a request, and keeping the model resident between requests is what stops the first prompt after an idle hour from paying the full load time again.

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

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

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 धीमा होता है, क्योंकि यह weights को डाउनलोड करता है और फिर यह तय करने के लिए GPU को profile करता है कि कितने KV cache blocks फिट होंगे। यह port 8000 पर listen करता है। कोई भी 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 पहले से ही box पर मौजूद है, तो 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 shared memory के माध्यम से processes के बीच tensors को pass करता है, और default Docker shared-memory allocation tensor-parallel inference के लिए बहुत छोटा होता है।

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

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

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

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

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

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

Hardware: प्रत्येक को किसकी आवश्यकता है

Ollama CPU पर चलता है। 4-bit quantized मॉडल के लिए प्रति बिलियन पैरामीटर लगभग आधा गीगाबाइट RAM की आवश्यकता होती है, साथ ही लगभग एक गीगाबाइट रनटाइम ओवरहेड और कॉन्टेक्स्ट के लिए अतिरिक्त मेमोरी चाहिए। इसलिए, 3B मॉडल के लिए लगभग 4 GB खाली RAM और 8B मॉडल के लिए लगभग 8 GB की आवश्यकता होती है। साझा vCPU पर गति सिंगल डिजिट से लेकर लो-डबल डिजिट टोकन प्रति सेकंड तक होती है। यह मेमोरी बैंडविड्थ की सीमा है, न कि कोई गलत कॉन्फ़िगरेशन, और कोई भी फ्लैग इसे ठीक नहीं कर सकता। सामान्य अनुमान के बजाय किसी विशिष्ट रिलीज़ पर इस गणित को देखने के लिए, running Nemotron 3.5 Lightning on a VPS यह स्पष्ट करता है कि कौन सा सटीक टैग खींचना है, लोड होने के बाद यह कितनी RAM लेता है, और क्या केवल CPU पर चलना आपके उपयोग के लिए पर्याप्त तेज़ है।

vLLM के लिए GPU की आवश्यकता होती है। इसका डिफ़ॉल्ट पाथ 16-bit प्रिसिजन पर unquantized वेट्स सर्व करता है, जो प्रति बिलियन पैरामीटर लगभग 2 GB होता है: 8B मॉडल को केवल वेट्स के लिए लगभग 16 GB वीडियो मेमोरी चाहिए, और यह KV कैश से पहले की आवश्यकता है जो आपको वह कॉन्करेंसी देता है जिसके लिए आपने vLLM इंस्टॉल किया है। 24 GB के कार्ड पर यह एक काम करने योग्य कैश छोड़ता है। 16 GB के कार्ड पर ऐसा नहीं होता, इसलिए आपको या तो छोटा मॉडल चुनना होगा या quantized चेकपॉइंट के साथ --quantization पास करना होगा। एक CPU बैकएंड मौजूद है, लेकिन मानक व्हील्स इसके लिए नहीं बने हैं, और यह vLLM चलाने के मुख्य उद्देश्य को ही समाप्त कर देता है।

इसलिए, हार्डवेयर का प्रश्न अधिकांश समय सॉफ़्टवेयर के प्रश्न का उत्तर दे देता है। यदि GPU नहीं है, तो Ollama का उपयोग करें। यदि किराए पर लिया गया GPU 5 प्रतिशत उपयोग पर बैठा है क्योंकि अनुरोधों को सीरियलाइज़ किया जा रहा है, तो vLLM का उपयोग करें।

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

• एक व्यक्ति, एक CPU VPS, ड्राफ्टिंग और सारांश (summarising) के लिए: Ollama। इसकी गति स्वीकार्य है और इससे सरल कुछ भी नहीं है।
• एक कोडिंग असिस्टेंट, या एक MCP सर्वर जो आपके टूल्स को लोकल मॉडल से जोड़ता है, जिसे केवल आप इस्तेमाल करते हैं: Ollama। एक समय में एक ही काम (concurrency of one) ही वास्तविक वर्कलोड है।
• इस सप्ताह पांच मॉडलों की तुलना करने के लिए: Ollama। टैग किए गए मॉडलों को पुल और डिलीट करना इसका मुख्य काम है, जबकि vLLM को हर मॉडल के लिए प्रोसेस रीस्टार्ट की आवश्यकता होती है।
• एक इंटरनल ऐप, चैट प्रोडक्ट, या वास्तविक उपयोगकर्ताओं के साथ रिट्रीवल पाइपलाइन के लिए: vLLM। यहीं पर बैचिंग GPU के खर्च को सार्थक बनाती है।
• रात भर में एक लाख दस्तावेजों को स्कोर करने वाला बैच जॉब: vLLM, उच्च --max-num-seqs के साथ। यहाँ केवल थ्रूपुट (throughput) मायने रखता है, प्रति-दस्तावेज़ लेटेंसी नहीं।
• एक एजेंट प्लेटफॉर्म जहाँ कई self-hosted AI agents एक साथ मॉडल का उपयोग करते हैं: vLLM, क्योंकि एजेंट ट्रैफिक स्वभाव से बर्स्टी (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 लोड करने के बाद बची हुई मेमोरी से अधिक है। इसे --max-model-len 8192 के साथ कम करें, या यदि कार्ड का उपयोग कोई अन्य नहीं कर रहा है तो --gpu-memory-utilization को बढ़ाएं। उपयोग को 0.95 से अधिक बढ़ाने पर यह स्टार्टअप त्रुटि बाद में लोड के दौरान CUDA out-of-memory क्रैश में बदल सकती है, जो कि दोनों में से अधिक खराब स्थिति है।

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

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

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

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

दोनों को एक साथ चलाना एक उचित समाधान है

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

FAQ

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

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

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

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

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

llama.cpp एक inference लाइब्रेरी है, और GGUF इसका quantized वेट फॉर्मेट है। Ollama का रनर इसी पर बना है और उन हिस्सों को जोड़ता है जिन्हें llama.cpp आप पर छोड़ देता है: एक मॉडल रजिस्ट्री, ऑटोमैटिक डाउनलोड, एक रेजिडेंट सर्वर, एक systemd यूनिट, और एक OpenAI-compatible एंडपॉइंट। Ollama ने कुछ नए मॉडल परिवारों के लिए अपना खुद का इंजन जोड़ा है, इसलिए अब दोनों अंदरूनी तौर पर पूरी तरह समान नहीं हैं।

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

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

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

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