क्या vLLM GGUF चला सकता है? हाँ — सिर्फ़ GPU पर

पिछले हफ़्ते एक पाठक ने पूछा कि उनकी GGUF फ़ाइल बिना GPU वाली मशीन पर vLLM में क्यों विफल हो जाती है, जबकि वही फ़ाइल Ollama में बिना झिझक चलती है। पहले छोटा जवाब: हाँ, vLLM GGUF चला सकता है — आधिकारिक प्लगइन के ज़रिए, सिर्फ़ GPU पर। प्लगइन का नाम vllm-gguf-plugin है, सिंटैक्स repo:quant_type है, और CPU पर कोशिश करते ही आप समर्थित हार्डवेयर तालिका से बाहर निकल जाते हैं। नीचे सब कुछ vLLM दस्तावेज़ों और vllm-project/vllm रिपॉज़िटरी के रिकॉर्ड (फ़रवरी 2023 से 92,000+ स्टार) से है — दस्तावेज़ों से, मेरी टेस्ट रिग से नहीं।

GGUF मॉडल को vLLM से कैसे serve करें?

दो क़दम: प्लगइन इंस्टॉल करें, फिर vLLM को मॉडल की ओर इंगित करें। GGUF समर्थन अब vLLM के कोर में नहीं रहता — दस्तावेज़ कहते हैं कि यह «vllm-gguf-plugin में स्थानांतरित हो गया है», इसलिए खालिदा pip install vllm काफ़ी नहीं:

uv pip install vllm-gguf-plugin

# सीधे Hugging Face से, repo_id:quant_type फ़ॉर्मैट में:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# या पहले से डाउनलोड की गई लोकल फ़ाइल:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

--tokenizer फ़्लैग सजावट नहीं है। आधिकारिक दस्तावेज़ बेस मॉडल का tokenizer इस्तेमाल करने की सिफ़ारिश करते हैं, क्योंकि GGUF tokenizer रूपांतरण «समय लेने वाला और अस्थिर है, ख़ासकर बड़े शब्दभंडार वाले मॉडलों पर»। इसे छोड़ना मतलब एक-लाइन के फ़्लैग को लंबी, मनमौजी स्टार्टअप से बदलना।

दो GPU, एक मॉडल: --tensor-parallel-size 2 जोड़ें और वही GGUF दोनों कार्ड में बँट जाएगा — tensor parallelism GGUF के साथ वैसे ही काम करता है जैसे किसी और फ़ॉर्मैट के साथ।

vLLM CPU पर GGUF क्यों ठुकराता है?

यही हिस्सा चौंकाता है। GGUF की पहचान पहले CPU है — llama.cpp ने ठीक इसी फ़ॉर्मैट पर लैपटॉप और Raspberry Pi में अपना नाम बनाया। लेकिन vLLM के भीतर स्थिति उलट जाती है। आधिकारिक हार्डवेयर संगतता तालिका GGUF को ऐसे दर्शाती है:

हार्डवेयर	vLLM में GGUF
NVIDIA Volta / Turing / Ampere / Ada / Hopper	समर्थित
AMD GPU	समर्थित
Intel GPU	असमर्थित
x86 CPU	असमर्थित
Arm CPU	असमर्थित

स्रोत: vLLM quantization दस्तावेज़। कारण आर्किटेक्चरल है: vLLM का GGUF रास्ता ब्लॉकों को बैच सर्विंग के लिए बने GPU कर्नेल में dequantize करता है। पीछे कोई CPU कर्नेल नहीं — क्योंकि vLLM सर्विंग इंजन है, लैपटॉप का खिलौना नहीं। मशीन में GPU न हो तो कोई फ़्लैग नहीं बचाता — llama.cpp इस्तेमाल करें।

क्या टूटता है: सीमाओं की ईमानदार सूची

उसी दस्तावेज़ पृष्ठ पर एक चेतावनी है जो शब्दशः उद्धृत करने लायक है: «vLLM में GGUF समर्थन अत्यंत प्रायोगिक और कम-अनुकूलित है»। ठोस रूप में:

• Quantization कवरेज llama.cpp से सँकरी है। जो K-quant सब डाउनलोड करते हैं (Q4_K_M वर्ग) वे चलते हैं; विलक्षण स्कीम हमेशा नहीं। फ़ॉर्मैट का संदर्भ कार्यान्वयन llama.cpp ही है।
• आर्किटेक्चर समर्थन पीछे आता है। नए मॉडल परिवार पहले llama.cpp में उतरते हैं; प्लगइन बाद में।
• mmap-शैली का lazy loading नहीं। llama.cpp फ़ाइल को मेमोरी में मैप करता है; vLLM उसे किसी और checkpoint की तरह लोड करता है।
• यह सबसे पहले मेमोरी-फ़ुटप्रिंट सुविधा है। दस्तावेज़ GGUF को VRAM खपत घटाने का तरीका बताते हैं, थ्रूपुट का दाँव नहीं।

इनमें से कुछ भी छिपा नहीं है। सब आधिकारिक GGUF पृष्ठ के पहले पैराग्राफ़ में है — ज़्यादातर प्रायोगिक सुविधाओं से ज़्यादा ईमानदारी।

GGUF के लिए vLLM या llama.cpp: कौन जीतता है?

एक ही फ़ाइल पढ़ने वाले अलग औज़ार:

	vLLM + GGUF	llama.cpp
CPU इन्फ़रेंस	नहीं	हाँ, पहली दर्जे का
साथ उपयोगकर्ता	continuous batching, इसी के लिए बना	सीमित
Quant कवरेज	उपसमुच्चय, प्रायोगिक	संदर्भ मानक
इंस्टॉलेशन	vLLM + प्लगइन	एक बाइनरी
सबसे उपयुक्त	एक GPU, कई उपयोगकर्ता	एक उपयोगकर्ता, कोई भी हार्डवेयर

अगर आप एक GPU से टीम को मॉडल serve करते हैं, तो vLLM + GGUF से आप local-LLM दुनिया की वही Q4_K_M फ़ाइलें दोबारा इस्तेमाल कर सकते हैं — और विकल्प हमारी GGUF quantization गाइड में। पूरे इंजन की तुलना के लिए देखें llama.cpp vs Ollama और GGUF मॉडल लोकल कैसे चलाएँ।

एक-पंक्ति नियम: एक ही फ़ाइल, उलटे स्वभाव — llama.cpp GGUF को मूल फ़ॉर्मैट मानता है, vLLM एक विकल्प।