VPS पर Ollama के साथ Qwen 27B कैसे चलाएं

क्या आप बिना GPU वाले VPS पर Qwen 3.8 27B चला सकते हैं?

VPS पर Qwen 3.8 27B चलाने के लिए आपको सबसे पहले एक ऐसे मॉडल टैग की आवश्यकता है जो वास्तव में मौजूद हो, और 4 अगस्त 2026 तक Ollama लाइब्रेरी में qwen3.8 नाम की कोई एंट्री नहीं है। सबसे निकटतम रिलीज किया गया 27B टैग qwen3.6:27b है: 27.8 बिलियन पैरामीटर्स, Q4_K_M क्वांटाइजेशन, Apache 2.0 लाइसेंस। नीचे दिए गए प्रत्येक कमांड और प्रत्येक संख्या में Ollama v0.32.5 पर उस टैग का उपयोग किया गया है, जिसे 27 जुलाई 2026 को प्रकाशित किया गया था।

संक्षिप्त उत्तर यह है कि हाँ, आप इसे 32 GB या उससे बड़े VPS पर चला सकते हैं, लेकिन यह धीमा चलेगा। Q4 पर एक 27B डेंस मॉडल को केवल वेट्स (weights) के लिए लगभग 17 GB RAM की आवश्यकता होती है, इससे पहले कि कॉन्टेक्स्ट का एक भी टोकन स्टोर किया जाए। यह 8 GB और 16 GB वाले प्लान्स को पूरी तरह से बाहर कर देता है। एक सामान्य टू-चैनल DDR4 VPS पर इसकी अधिकतम गति लगभग 3 टोकन प्रति सेकंड होती है, जो अधिकांश लोगों की पढ़ने की गति से धीमी है।

3.8 कहाँ से आया? सबसे अधिक संभावना है कि यह पैरामीटर काउंट है। qwen3.6:27b के लिए Ollama पेज 27.8B पैरामीटर्स की रिपोर्ट करता है, और 27.8 को बाद में 3.8 के रूप में याद रखना आसान है। यहाँ एक qwen3.5:27b भी है, जो पिछले रिलीज का ही Q4_K_M बिल्ड है। कोई भी कमांड कॉपी करने से पहले लाइव लिस्ट देखें, Ollama qwen3.6 टैग पेज पर। यदि बाद में कोई वास्तविक qwen3.8 रिलीज होता है, तो यहाँ दी गई गणना तब भी लागू होगी, क्योंकि यह वर्जन नंबर के बजाय पैरामीटर काउंट और बिट्स प्रति वेट पर निर्भर करती है।

कौन सा Ollama tag pull करें, और इसकी जाँच कैसे करें

यदि आप ऐसा tag pull करते हैं जो मौजूद नहीं है, तो एक स्पष्ट error दिखाई देता है, इसलिए सर्वर पर इसे तय करना त्वरित है।

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show कमांड उस tag के लिए architecture, parameter count, context length और quantisation को प्रिंट करता है जो आपके पास मौजूद है। यदि parameter लाइन 27.8B दर्शाती है और quantisation लाइन Q4_K_M दर्शाती है, तो आपके पास वही build है जिसके आधार पर यह गाइड लिखी गई है। library में उच्च precision वाले समान weights के लिए qwen3.6:27b-q8_0 और qwen3.6:27b-bf16 भी उपलब्ध हैं, साथ ही 35b-a3b tags का एक सेट भी है जो MoE (mixture of experts) models हैं और CPU पर बहुत अलग तरह से व्यवहार करते हैं। इनके बारे में अधिक जानकारी नीचे दी गई है।

पैरामीटर संख्या और प्रति वेट बाइट्स

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

यह सूत्र एक पंक्ति का है। वेट के बाइट्स = पैरामीटर * प्रति वेट बिट्स / 8। 4 बिट्स के सटीक मान पर, 27.8 बिलियन पैरामीटर 13.9 GB के होंगे। शिप किया गया Q4_K_M टैग 17 GB का है, जो व्यवहार में 4.89 बिट्स प्रति वेट के बराबर है।

यह अंतर कोई त्रुटि नहीं है। K-quant फॉर्मेट हर टेंसर को नाममात्र की चौड़ाई पर स्टोर नहीं करते हैं। जो टेंसर कंप्रेशन के दौरान सबसे अधिक गुणवत्ता खोते हैं, उन्हें 5 या 6 बिट्स पर रखा जाता है, और टोकन एम्बेडिंग तथा आउटपुट लेयर्स को आमतौर पर Q6_K या Q8_0 पर छोड़ दिया जाता है। फॉर्मेट का नाम एक औसत है, और यह औसत लगभग 4.9 के करीब आता है। यही प्रभाव स्केल के दूसरे छोर पर भी दिखता है: BF16 के लिए 56 GB का मान 16 के बजाय 16.1 बिट्स प्रति वेट है, क्योंकि फाइल में मेटाडेटा और फुल-प्रिसिजन एम्बेडिंग टेबल भी शामिल होती है।

Q5_K_M के लिए इस मॉडल का कोई प्रकाशित टैग नहीं है, इसलिए 19.8 GB वाली पंक्ति की गणना उस फॉर्मेट के लिए सामान्य 5.7 बिट्स प्रति वेट के आधार पर की गई है, न कि मापन के आधार पर। Q8_0, Q4 के आकार को लगभग दोगुना करके 30 GB कर देता है। केवल CPU वाले बॉक्स पर, यह दोगुना मेमोरी ट्रैफिक प्रति टोकन की लागत को भी दोगुना कर देता है, इसलिए यह आपके टोकन प्रति सेकंड को भी लगभग आधा कर देता है। केवल इसी कारण से Q4_K_M यहाँ सही डिफॉल्ट है।

जैसे-जैसे context बढ़ता है, KV cache की लागत

Weights एक निश्चित लागत हैं। KV cache (key और value cache, वह attention state जिसे model हर उस token के लिए रखता है जिसे वह पहले ही देख चुका है) context length के साथ सीधे अनुपात में बढ़ता है, और यही वह जगह है जहाँ ज्यादातर लोगों की RAM खत्म हो जाती है।

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

ये आंकड़े उस संरचना को मानते हैं जिसका उपयोग Qwen ने इस size class के अपने हालिया dense models में किया है: 64 layers, GQA (grouped-query attention) के तहत 8 key/value heads, और 128 का head dimension। यह f16 पर प्रति token 256 KiB होता है, इसलिए 32k tokens पर 8 GB और 128k पर 32 GB बनता है। मेरी गणना के बजाय अपने सिस्टम पर भरोसा करें। Model load करें और ollama ps का SIZE column पढ़ें, जो weights, cache और overhead को एक ही आंकड़े के रूप में दिखाता है।

यही कारण है कि model card पर 256K context एक मुख्य आकर्षण (headline) है, न कि कोई योजना। f16 पर इसे भरने के लिए weights के अलावा 64 GB cache की आवश्यकता होगी, जबकि एक ऐसी मशीन पर जिसने पहले ही weights पर 17 GB खर्च कर दिए हैं। Ollama डिफ़ॉल्ट रूप से आपको पूरी window नहीं देता है। यह बहुत छोटी window load करता है, और आप इसे OLLAMA_CONTEXT_LENGTH के साथ जानबूझकर बढ़ाते हैं। इसे चरणों में बढ़ाएं और प्रत्येक बदलाव के बाद ollama ps की जाँच करें।

दो settings cache को आधा या उससे अधिक कम कर देती हैं। OLLAMA_KV_CACHE_TYPE=q8_0 cache को 16 bits के बजाय 8 bits पर store करता है, जिससे 32k tokens की खपत 8 GB से घटकर 4 GB रह जाती है। इसके लिए flash attention की आवश्यकता होती है, इसलिए OLLAMA_FLASH_ATTENTION=1 को भी set करें, और यह मानने के बजाय कि यह लागू हो गया है, ollama ps में गिरावट की पुष्टि करें। OLLAMA_NUM_PARALLEL=1 भी उतना ही महत्वपूर्ण है। Ollama एक साथ कई requests serve कर सकता है, और प्रत्येक slot को context का अपना हिस्सा मिलता है, इसलिए parallelism को डिफ़ॉल्ट पर छोड़ने से आपके द्वारा बजट की गई cache चुपचाप कई गुना बढ़ जाती है। यदि एक से अधिक व्यक्ति इस box का उपयोग करेंगे, तो वह गुणा ही परेशानी की जड़ है, और एक self-hosted model कितने concurrent users को serve कर सकता है, यह core count से बहुत पहले cache slots और queue depth द्वारा तय हो जाता है।

8, 16, 32 और 64 GB RAM में क्या समा सकता है

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

इन दो संख्याओं को संदर्भ (context) के उन हजारों टोकन के रूप में पढ़ें जो weights के साथ, f16 cache पर, एक headless Linux VPS पर समा सकते हैं, जिसमें ऑपरेटिंग सिस्टम के लिए लगभग 1.5 GB जगह छोड़ी गई है और ऊपर थोड़ा अतिरिक्त मार्जिन रखा गया है। शून्य का अर्थ है कि weights स्वयं फिट नहीं होते, इसलिए कुछ भी नहीं समा सकता।

8 GB और 16 GB के मामले में कोई संशय नहीं है। 17 GB के weights 16 GB RAM में नहीं समाते हैं, और संदर्भ (context) की कोई भी सेटिंग इसे नहीं बदल सकती। Swap जोड़ने से भी कोई लाभ नहीं होता। Ollama GGUF फाइल को memory-map करता है, इसलिए जैसे ही resident pages RAM से अधिक हो जाते हैं, kernel उन्हें हटाना (evict) और फिर से पढ़ना शुरू कर देता है, और तब प्रत्येक टोकन डिस्क से गीगाबाइट डेटा खींचता है। सिस्टम high iowait पर चला जाता है और प्रति सेकंड एक टोकन से भी कम गति देता है।

32 GB प्रवेश बिंदु है। Weights 17 GB लेते हैं और आपके पास लगभग 13 GB बचता है, जो मार्जिन के साथ लगभग 32k टोकन के f16 संदर्भ को कवर करता है। 30 GB पर Q8_0 weights इस स्तर पर बिल्कुल भी फिट नहीं होते हैं।

64 GB आरामदायक है। Q4 लगभग 128k टोकन संदर्भ के लिए जगह छोड़ता है, और Q8_0 weights लगभग 64k टोकन के साथ फिट हो जाते हैं। Q8 प्राप्त करने के लिए 64 GB पर खर्च करने से पहले, स्पष्ट रहें कि आप क्या खरीद रहे हैं: एक ऐसी मशीन पर आधी गति पर थोड़ा बेहतर आउटपुट, जो पहले से ही धीमी थी। लगभग सभी के लिए, लंबे संदर्भ (context) के साथ Q4 का उपयोग करना बेहतर सौदा है।

VPS पर CPU inference कितनी तेज है?

Dense model से एक token generate करने का अर्थ है मेमोरी से हर weight को एक बार पढ़ना। कुछ को नहीं, बल्कि सभी को। इसलिए गति की सीमा आपके core count पर नहीं, बल्कि मेमोरी बैंडविड्थ और weights के आकार के अनुपात पर निर्भर करती है। Q4 quantization पर, यह प्रति token 17 GB का मेमोरी ट्रैफिक है।

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

ये अधिकतम सीमाएँ हैं, वास्तविक माप नहीं। वास्तविक आउटपुट दर्शाए गए आँकड़े के लगभग 50 से 70 प्रतिशत तक ही पहुँच पाता है, क्योंकि मेमोरी लेटेंसी और अपूर्ण prefetching के कारण आप कभी भी सैद्धांतिक शिखर (theoretical peak) तक नहीं पहुँच पाते। एक दो-चैनल DDR4-3200 VPS की अधिकतम सीमा 3 tokens प्रति सेकंड है, इसलिए लगभग 2 tokens प्रति सेकंड की अपेक्षा रखें। एक दो-चैनल DDR5-4800 बॉक्स की सीमा 4.5 है, इसलिए लगभग 3 tokens प्रति सेकंड की अपेक्षा रखें।

बड़े सर्वर प्लान्स के साथ एक चेतावनी जुड़ी है। एक बारह-चैनल EPYC प्लेटफॉर्म में 460.8 GB/s की बैंडविड्थ और 27.1 tokens प्रति सेकंड की सीमा होती है, लेकिन आप पूरा EPYC रेंट पर नहीं लेते हैं। मेमोरी बैंडविड्थ उस मशीन पर मौजूद सभी tenants द्वारा साझा किया जाने वाला एक संसाधन है, इसलिए 8 vCPU वाले स्लाइस के साथ बारह चैनलों की एक्सक्लूसिव बैंडविड्थ नहीं मिलती। GPU-केंद्रित गाइड्स इस तथ्य को पूरी तरह नजरअंदाज कर देती हैं, और यही कारण है कि समान vCPU काउंट वाले दो VPS प्लान एक ही मॉडल पर तीन गुना तक भिन्न हो सकते हैं।

इसी कारण से अधिक vCPUs का होना भी जल्दी ही बेअसर हो जाता है। एक बार जब cores मेमोरी कंट्रोलर की क्षमता से अधिक तेजी से डेटा की मांग करने लगते हैं, तो अतिरिक्त threads केवल शेड्यूलिंग ओवरहेड बढ़ाते हैं, और कुछ नहीं। OLLAMA_NUM_THREAD को अपने फिजिकल कोर काउंट पर सेट करें, मापें, और फिर उस संख्या को आधा करके देखें। कई shared प्लान्स पर कम सेटिंग अधिक तेज होती है।

Prompt प्रोसेसिंग अलग तरह से काम करती है। Prefill, यानी पहला token आने से पहले इनपुट पर की जाने वाली प्रक्रिया, बैंडविड्थ के बजाय compute bound होती है, इसलिए यह cores के साथ स्केल करती है। इसका व्यावहारिक प्रभाव यह है कि बड़े प्रॉम्प्ट पर आउटपुट शुरू होने से पहले एक लंबा विराम होता है, जिसके बाद ऊपर बताई गई धीमी और स्थिर गति बनी रहती है। --verbose के साथ दोनों हिस्सों का समय अलग-अलग मापें, जो हर रिक्वेस्ट के लिए prompt eval rate और eval rate प्रिंट करता है।

यदि dense 27B मॉडल बहुत धीमा है, तो CPU पर हार मानने से पहले qwen3.6:35b-a3b टैग्स को देखें। ये प्रति token सभी 27.8 बिलियन पैरामीटर्स के बजाय लगभग 3 बिलियन पैरामीटर्स को ही सक्रिय करते हैं, जिससे प्रति token मेमोरी ट्रैफिक लगभग दस गुना कम हो जाता है, भले ही डिस्क पर फाइल का आकार बड़ा हो। आप यहाँ गति के बदले RAM का उपयोग बढ़ाते हैं। रनटाइम का चुनाव भी यहाँ मायने रखता है, और Ollama और llama.cpp समान अंतर्निहित inference कोड पर अलग-अलग CPU ट्यूनिंग कंट्रोल्स प्रदान करते हैं।

GPU hour किराए पर कब लेना चाहिए

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

प्रकाशित GPU memory bandwidth पर यही सूत्र लागू करने पर उत्तर की श्रेणी बदल जाती है। एक 24 GB consumer card की इन weights पर अधिकतम क्षमता 59 tokens प्रति सेकंड है। एक वर्तमान data centre card 197 तक पहुँच जाता है। यह ऐसा अंतर नहीं है जिसे thread counts को ट्यून करके कम किया जा सके। यह card अपनी memory को 1008 GB/s पर चलाता है, जबकि आपका VPS इसे केवल कुछ दसियों GB/s पर चलाता है।

इसलिए प्राथमिकता के बजाय workload के आधार पर निर्णय लें। जब काम asynchronous हो और कोई उसका इंतज़ार न कर रहा हो, तो CPU inference सही विकल्प है: जैसे दस्तावेजों के ढेर का रात भर में summarisation, या रात में चलने वाला classification job। जिस क्षण कोई व्यक्ति output का इंतज़ार कर रहा हो, या requests हर 30 सेकंड में एक से अधिक की दर से आ रही हों, तो GPU किराए पर लें। ऐसा इसलिए क्योंकि CPU-only box में batching के लिए कोई headroom नहीं होता और queue लगातार बढ़ती जाती है।

लागत की तुलना जितनी दिखती है, उतनी सीधी नहीं है। एक 64 GB VPS का बिल महीने के हर घंटे आता है, चाहे model loaded हो या न हो, जबकि GPU instance का बिल केवल उन घंटों का आता है जब आप उसे चलाते हैं। यदि आपका वास्तविक उपयोग दिन में दो घंटे है, तो किराए का GPU तेज़ और सस्ता दोनों हो सकता है। पहले अपना duty cycle निकालें, फिर उसकी कीमत तय करें। Picking a VPS with a GPU में बताया गया है कि instance पर क्या जाँचें, और vLLM pulls ahead of Ollama once you serve concurrent requests on a GPU क्योंकि यह उन्हें बेहतर तरीके से batch करता है।

एक तीसरा विकल्प भी है जिसे लोग भूल जाते हैं। Batch work के लिए 27B को CPU पर रखें और interactive path के लिए एक hosted API model का उपयोग करें। कोई भी नियम यह नहीं कहता कि एक ही model को दोनों काम करने चाहिए।

Ollama इंस्टॉल करें और अपने सिस्टम की क्षमता मापें

इंस्टॉल स्क्रिप्ट आधिकारिक है, और यह एक समर्पित ollama यूजर के रूप में चलने वाली systemd सर्विस को सेटअप करती है।

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version को 0.32.5 या बाद का वर्ज़न दिखाना चाहिए। कुछ भी पुल (pull) करने से पहले free -g की जाँच करें। यदि Mem लाइन पर total कॉलम 32 से कम है, तो यहीं रुकें और एक छोटा मॉडल चुनें, क्योंकि 17 GB डेटा पुल करना जिसे आप चला ही नहीं सकते, एक घंटा और काफी डिस्क स्पेस बर्बाद करेगा।

Runtime विकल्पों को अपने शेल के बजाय systemd ओवरराइड में सेट करें। मॉडल सर्विस के अंदर चलता है, इसलिए यह आपके इंटरैक्टिव एनवायरनमेंट को कभी नहीं देख पाता है।

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose आउटपुट वह माप है जिसके लिए आप यहाँ आए हैं। eval rate जनरेशन के दौरान आपके टोकन प्रति सेकंड (tokens per second) हैं। prompt eval rate आपकी प्रीफिल स्पीड (prefill speed) है। load duration वह समय है जो डिस्क से वेट्स (weights) पढ़ने में लगा, और इसीलिए OLLAMA_KEEP_ALIVE=60m सेट किया गया है: CPU पर, हर रिक्वेस्ट पर डिस्क से 17 GB को रिलोड करना रिक्वेस्ट की लागत से अधिक महंगा पड़ता है।

जब मॉडल लोड हो, तो दूसरे टर्मिनल से इसका फुटप्रिंट (footprint) देखें।

ollama ps

SIZE कॉलम वास्तविक मेमोरी फुटप्रिंट है जिसमें KV कैश शामिल है, और इसे वेट्स के साथ-साथ KV चार्ट में आपकी कॉन्टेक्स्ट लेंथ (context length) वाली रो के करीब होना चाहिए। 8-बिट कैश के साथ 8192 टोकन पर, वेट्स के ऊपर लगभग एक गीगाबाइट की उम्मीद करें, जबकि यदि कैश f16 पर रहता तो यह 2 GB होता। PROCESSOR कॉलम में 100% CPU लिखा होना चाहिए। यदि इसमें कुछ और लिखा है, तो किसी अन्य चीज़ ने GPU पर कब्ज़ा कर लिया है और इस गाइड में दी गई स्पीड संख्याएं आपके सिस्टम के लिए सटीक नहीं हैं।

विफलता के प्रकार और वे सटीक स्ट्रिंग्स जो आपको दिखाई देंगी

मॉडल लोड होने से मना कर देता है। Ollama दोनों आंकड़ों के नाम के साथ एक लाइन प्रिंट करता है, जो model requires more system memory (18.6 GiB) than is available (15.2 GiB) के रूप में होती है। यह एक अच्छी विफलता है, क्योंकि Ollama ने kernel द्वारा इसे संभालने देने के बजाय पहले ही जांच कर ली है। context length को कम करें, छोटे tag पर आएं, या बड़े plan पर स्विच करें।

उत्तर के बीच में ही process गायब हो जाती है। client कुछ भी उपयोगी नहीं दिखाता है, और journalctl -u ollama -n 50 सेवा के पुनरारंभ (restarting) को दर्शाता है। dmesg -T | tail चलाएं, और यदि लाइन में Out of memory: Killed process ... (ollama) लिखा है, तो इसका मतलब है कि kernel OOM killer ने इसे बंद कर दिया है। यह तब होता है जब pre-load जांच तो सफल हो जाती है, लेकिन लंबी बातचीत के दौरान cache अनुमान से अधिक बढ़ जाता है। context length को कम करें।

pull तुरंत विफल हो जाता है। Error: pull model manifest: file does not exist का मतलब है कि tag library में मौजूद नहीं है। qwen3.8:27b टाइप करने पर बिल्कुल यही परिणाम मिलता है, और version number में कोई भी typo होने पर भी ऐसा ही होता है। अपने नेटवर्क को दोष देने से पहले library page पर tag की पुष्टि करें।

सब कुछ काम कर रहा है लेकिन यह बहुत धीमा है। पर्याप्त RAM वाले बॉक्स पर एक token प्रति सेकंड से कम गति का मतलब compute के बजाय paging है। generate करते समय vmstat 1 चलाएं। si या so कॉलम में शून्य के अलावा कोई अन्य मान होने का मतलब है कि kernel swapping कर रहा है, और इसका समाधान कम context या कम लोड किए गए मॉडल हैं। बिना swap activity के लगातार उच्च wa का मतलब है कि memory-mapped weights को disk से बार-बार पढ़ा जा रहा है, जिसका अर्थ है कि वे वास्तव में फिट नहीं हो रहे हैं।

पहला token 30 सेकंड लेता है और फिर output की गति बढ़ जाती है। यह prefill है, और यह सामान्य है। प्रत्येक request पर जो cache में नहीं मिलती, एक लंबे system prompt की कीमत चुकानी पड़ती है, इसलिए कुछ भी और बदलने से पहले system prompt को छोटा करें।

CPU-only 27B मॉडल वास्तव में किस काम के लिए अच्छा है

उम्मीदों के बजाय आंकड़ों के आधार पर अपेक्षाएं तय करें। दो से चार tokens प्रति सेकंड की गति पर, 500 tokens के उत्तर में दो से चार मिनट का समय लगता है। यह chat के लिए अनुपयोगी है, लेकिन queue आधारित कार्यों के लिए पूरी तरह से काम करने योग्य है। दस्तावेज़ का सारांश (document summarisation), bulk tagging, फाइलों के backlog से field extraction, और unattended code review जैसे कार्य इसे सहन कर सकते हैं, क्योंकि उत्तर के लिए कोई प्रतीक्षा नहीं कर रहा होता है। कोडिंग सहायता इसी सीमा पर स्थित है, इसलिए किसी कोडिंग एजेंट को अपने होस्ट किए गए मॉडल पर निर्देशित करना commit messages और test scaffolding जैसे background कार्यों के लिए फायदेमंद है, न कि उन inline सुझावों के लिए जिनके लिए आप बैठकर प्रतीक्षा करते हैं।

गोपनीयता का तर्क ही वास्तविक है। मॉडल आपके द्वारा किराए पर लिए गए और नियंत्रित हार्डवेयर पर चलता है, कोई भी request बॉक्स से बाहर नहीं जाती है, और प्रति-token कोई बिल नहीं होता है। विनियमित डेटा (regulated data) के लिए तीन tokens प्रति सेकंड की गति पर भी यह बहुत मूल्यवान है। इसकी तुलना विकल्प के साथ ईमानदारी से करें: frontier-scale मॉडल को self-host करने के लिए दस गुना अधिक हार्डवेयर की आवश्यकता होती है, और CPU पर 27B उस वक्र (curve) का सबसे सस्ता बिंदु है जहाँ आउटपुट अभी भी पढ़ने योग्य है।

यदि यह आपका पहला Ollama इंस्टॉलेशन है, तो VPS पर Ollama चलाने के लिए पूर्ण वॉकथ्रू में service सेटअप, HTTP API और उन firewall नियमों को शामिल किया गया है जिनके बारे में यह गाइड मानती है कि वे आपके पास पहले से मौजूद हैं। port 11434 को इंटरनेट पर expose न करें। Ollama में अपना कोई authentication नहीं होता है, इसलिए जो भी उस port तक पहुँचता है, वह आपके मॉडल का उपयोग कर सकता है और आपके prompts को पढ़ सकता है।

FAQ

क्या Ollama पर Qwen 3.8 27B मॉडल उपलब्ध है?

नहीं। 4 अगस्त 2026 तक Ollama लाइब्रेरी में कोई qwen3.8 नेमस्पेस नहीं है। जो 27B टैग मौजूद हैं, वे qwen3.5:27b और qwen3.6:27b हैं, जो दोनों ही 27.8 बिलियन पैरामीटर वाले डेंस मॉडल के Q4_K_M बिल्ड हैं। सर्च टर्म में 3.8 संभवतः 27.8B पैरामीटर काउंट है जिसे वर्जन नंबर समझ लिया गया है। वर्तमान सूची के लिए https://ollama.com/library/qwen3.6/tags देखें, और यदि आप नवीनतम रिलीज किया गया 27B मॉडल चाहते हैं तो qwen3.6:27b पुल करें। जो टैग मौजूद नहीं है, वह Error: pull model manifest: file does not exist के साथ विफल हो जाएगा।

VPS पर Qwen 27B मॉडल चलाने के लिए मुझे कितनी RAM की आवश्यकता है?

Q4_K_M के लिए 32 GB व्यावहारिक न्यूनतम है। वेट्स 17 GB के हैं, ऑपरेटिंग सिस्टम को लगभग 1.5 GB की आवश्यकता होती है, और KV कैश f16 पर हर 4000 टोकन के कॉन्टेक्स्ट के लिए लगभग 1 GB जोड़ता है। 16 GB का प्लान वेट्स को लोड ही नहीं कर पाएगा, और स्वैप (swap) से कोई मदद नहीं मिलेगी क्योंकि फाइल मेमोरी-मैप्ड होती है और कर्नल हर टोकन पर इसे डिस्क से दोबारा पढ़ता है। 64 GB आपको लंबे कॉन्टेक्स्ट या 30 GB पर Q8_0 वेट्स के लिए जगह देता है।

CPU पर 27B मॉडल मुझे प्रति सेकंड कितने टोकन देगा?

अपनी मेमोरी बैंडविड्थ को वेट्स के आकार से विभाजित करें, फिर उसका 50 से 70 प्रतिशत लें। एक टू-चैनल DDR4-3200 VPS की सीमा 3 टोकन प्रति सेकंड के करीब होती है और यह लगभग 2 टोकन देता है। एक टू-चैनल DDR5-4800 बॉक्स की सीमा 4.5 के करीब होती है और यह लगभग 3 टोकन देता है। हायर-चैनल सर्वर प्लेटफॉर्म कागजों पर बेहतर दिखते हैं, लेकिन मेमोरी बैंडविड्थ होस्ट पर हर टेनेंट के साथ साझा की जाती है, इसलिए ollama run qwen3.6:27b --verbose के साथ अपना मापें और eval rate लाइन पढ़ें।

क्या मुझे CPU-ओनली VPS पर Q4 या Q8 का उपयोग करना चाहिए?

लगभग हर मामले में Q4_K_M का उपयोग करें। Q8_0 17 GB के मुकाबले 30 GB का है, इसलिए इसके लिए 64 GB प्लान की आवश्यकता होती है और यह प्रति टोकन लगभग दोगुनी मेमोरी का उपयोग करता है, जिससे आपके टोकन प्रति सेकंड लगभग आधे हो जाते हैं। 27B मॉडल पर Q4_K_M और Q8_0 के बीच गुणवत्ता का अंतर अधिकांश कार्यों के लिए बहुत कम है। इसके बजाय RAM को लंबे कॉन्टेक्स्ट पर खर्च करें, क्योंकि यह मॉडल के काम करने के तरीके को बदलता है, न कि केवल उसके वाक्य विन्यास को।

GPU किराए पर लेना बड़े RAM वाले VPS से सस्ता कब होता है?

जब आपका ड्यूटी साइकिल कम हो या कोई व्यक्ति प्रतीक्षा कर रहा हो। 24 GB मेमोरी वाला GPU इन वेट्स पर लगभग 59 टोकन प्रति सेकंड तक पहुँच जाता है, जबकि सामान्य VPS पर यह 2 या 3 ही रहता है, और इसका बिल केवल उन घंटों का आता है जब यह चलता है। 64 GB VPS का बिल पूरे महीने आता है, चाहे मॉडल लोड हो या न हो। गणना करें कि आप वास्तव में दिन में कितने घंटे टोकन जनरेट करते हैं। दो या तीन घंटे से कम के उपयोग के लिए, प्रति घंटा GPU रेंटल आमतौर पर गति और लागत दोनों में बेहतर होता है। निरंतर चलने वाले लो-प्रायोरिटी बैच वर्क के लिए हमेशा ऑन रहने वाला VPS ही बेहतर है।