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

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

VPS पर Qwen 3.8 27B चलाने के लिए आपको qwen3.8:27b टैग की आवश्यकता है, और 21 October 2026 तक Ollama लाइब्रेरी में यह स्थानीय रूप से pull किए जाने योग्य टैग के रूप में उपलब्ध है: 27.3 बिलियन पैरामीटर्स, Q4_K_M क्वांटाइजेशन, Apache 2.0 लाइसेंस, 256K कॉन्टेक्स्ट विंडो, और 18 GB का डाउनलोड जिसमें लगभग 0.9 GB का विजन प्रोजेक्टर शामिल है। Ollama ने 14 August 2026 को जारी v0.32.12 में Qwen 3.8 27B सपोर्ट जोड़ा था, इसलिए पुराने इंस्टॉलेशन को पहले अपग्रेड करने की आवश्यकता है। 29 October 2026 तक नवीनतम स्टेबल रिलीज v0.40.13 है, जिसे 28 October 2026 को प्रकाशित किया गया था।

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

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

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

ऐसा tag pull करने पर जो मौजूद नहीं है, एक स्पष्ट error मिलता है, इसलिए सर्वर पर इसे तय करना आसान है। जो tag मौजूद है, वह भी स्थानीय स्तर पर न चल पाने वाला हो सकता है, और यही वह बात है जो लोगों को GLM 5.2, जो library में तो सूचीबद्ध है लेकिन केवल Ollama के cloud से serve किया जाता है के मामले में उलझाती है।

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show आपके पास मौजूद tag के लिए architecture, parameter count, context length और quantisation को print करता है। यदि parameter लाइन 27.3B पढ़ती है और quantisation लाइन Q4_K_M पढ़ती है, तो आपके पास वही build है जिसके आधार पर यह guide लिखी गई है। Library में समान weights के लिए उच्च precision पर qwen3.8:27b-q8_0 और qwen3.8:27b-bf16, 27b-mtp variants, और 27b-nvfp4, 27b-mxfp8, 27b-mlx तथा 27b-mlx-bf16 tags भी मौजूद हैं जिन्हें tags पेज MLX के रूप में लेबल करता है; यह एक ऐसा format है जो Linux VPS के बजाय Apple Silicon के लिए लक्षित है। qwen3.6 के विपरीत, qwen3.8 entry में कोई 35b-a3b tags नहीं हैं। वे MoE (mixture of experts) models अभी भी qwen3.6 के अंतर्गत आते हैं और CPU पर बहुत अलग तरह से व्यवहार करते हैं। इनके बारे में अधिक जानकारी नीचे दी गई है।

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

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

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

यह अंतर कोई त्रुटि नहीं है। K-quant फॉर्मेट हर टेंसर को नाममात्र चौड़ाई (nominal width) पर स्टोर नहीं करते हैं। जिन टेंसरों की क्वालिटी कंप्रेशन के दौरान सबसे ज्यादा घटती है, उन्हें अधिक बिट्स दिए जाते हैं। शिप की गई qwen3.8:27b फाइल के लिए Ollama की टेंसर लिस्टिंग Q6_K पर इन्हें दिखाती है: आउटपुट लेयर, फीड-फॉरवर्ड डाउन प्रोजेक्शन का लगभग आधा हिस्सा, फुल-अटेंशन लेयर्स में अटेंशन V प्रोजेक्शन का लगभग आधा हिस्सा, और लीनियर-अटेंशन लेयर्स में फ्यूज्ड QKV प्रोजेक्शन का लगभग आधा हिस्सा। छोटे नॉर्मलाइजेशन टेंसर पूरी 32-बिट प्रिसिजन पर रहते हैं। टोकन एम्बेडिंग, अटेंशन Q और K प्रोजेक्शन, और फीड-फॉरवर्ड गेट और अप प्रोजेक्शन मॉडल के अधिकांश हिस्सों की तरह Q4_K पर रहते हैं। फॉर्मेट का नाम एक औसत है, और यह औसत 5 के करीब आता है। यही प्रभाव स्केल के दूसरे छोर पर भी दिखता है: BF16 के लिए 55 GB का मतलब 16 के बजाय 16.1 बिट्स प्रति वेट है। वहाँ टोकन एम्बेडिंग बाकी सब की तरह BF16 है, और छोटा सा अतिरिक्त हिस्सा फाइल के मेटाडेटा, 32-बिट पर रखे गए नॉर्मलाइजेशन टेंसर और लिस्ट किए गए साइज के निकटतम गीगाबाइट में राउंड होने के कारण आता है।

पूरे टैग के लिए बजट रखें, न कि केवल लैंग्वेज मॉडल फाइल के लिए। qwen3.8:27b का हर GGUF टैग लगभग 0.9 GB का विजन प्रोजेक्टर भी साथ लाता है, इसीलिए Q4_K_M टैग 18 GB का लिस्ट किया गया है।

आधिकारिक qwen3.8 लाइब्रेरी एंट्री में Q5_K_M का कोई प्रकाशित टैग नहीं है, इसलिए 19.5 GB वाली पंक्ति को मापे जाने के बजाय उस फॉर्मेट के लिए सामान्य 5.7 बिट्स प्रति वेट पर कैलकुलेट किया गया है। Q8_0, Q4 को लगभग दोगुना करके 29 GB कर देता है। केवल CPU वाले बॉक्स पर, यह दोगुना मेमोरी ट्रैफिक प्रति टोकन को भी दोगुना कर देता है, जिससे आपके टोकन प्रति सेकंड भी लगभग आधे हो जाते हैं। केवल इसी कारण से Q4_K_M यहाँ सही डिफॉल्ट है। यदि आप मेमोरी के बजाय उस निर्णय के क्वालिटी वाले पहलू को देखना चाहते हैं, तो Q4, Q8 और fp16 की तुलना दिखाती है कि आउटपुट वास्तव में कहाँ खराब होना शुरू होता है।

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

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

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

ये आंकड़े model की अपनी config file से आते हैं। Qwen3.8-27B, Qwen3.6-27B की तरह, एक hybrid-attention model है। इसकी 64 में से केवल 16 layers full attention का उपयोग करती हैं और एक ऐसा cache रखती हैं जो हर token के साथ बढ़ता है, और उन layers में GQA (grouped-query attention) के तहत 4 key/value heads और 256 का head dimension होता है। अन्य 48 layers linear attention (Gated DeltaNet) का उपयोग करती हैं और इसके बजाय एक निश्चित आकार का state रखती हैं, जो मेरी गणना के अनुसार प्रति conversation slot लगभग 150 MB होता है, चाहे context कितना भी लंबा क्यों न हो। यह f16 पर प्रति token 64 KiB होता है, इसलिए 32k tokens पर 2 GB और 128k पर 8 GB होता है। मेरी गणना पर भरोसा करने के बजाय अपने सिस्टम की जाँच करें। Model को load करें और ollama ps के SIZE column को पढ़ें, जो weights, cache और overhead को एक ही आंकड़े के रूप में दिखाता है।

Model card पर दिया गया 256K context इस architecture पर संभव है, लेकिन यह मुफ्त नहीं है। f16 पर इसे भरने के लिए weights के अलावा लगभग 16 GB cache की लागत आती है, एक ऐसी machine पर जिसने पहले ही weights पर 17 GB खर्च कर दिए हैं। Ollama डिफ़ॉल्ट रूप से आपको पूरी window नहीं देता है। इसका context-length documentation VRAM के आधार पर डिफ़ॉल्ट तय करता है: 24 GiB से कम पर 4k tokens, 24 से 48 GiB के बीच 32k, और 48 GiB या उससे अधिक पर 256k। केवल CPU वाले VPS में कोई VRAM नहीं होती है, इसलिए यह 4k tier पर रहता है, और आप इसे OLLAMA_CONTEXT_LENGTH के साथ जानबूझकर बढ़ाते हैं। वह server-wide variable ही एकमात्र विकल्प नहीं है, और individual request पर num_ctx सेट करना आपको बाकी सब चीजों के लिए एक सस्ता डिफ़ॉल्ट रखने की अनुमति देता है, जबकि एक लंबे job को बड़ी window मिल जाती है। इसे चरणों में बढ़ाएं और प्रत्येक बदलाव के बाद ollama ps की जाँच करें।

दो settings cache को कम रखती हैं। OLLAMA_KV_CACHE_TYPE=q8_0 cache को 16 के बजाय 8 bits पर store करता है, जिससे 32k tokens की खपत 2 GB से घटकर 1 GB हो जाती है। इसके लिए flash attention की आवश्यकता होती है, इसलिए OLLAMA_FLASH_ATTENTION=1 को भी set करें, और यह मान लेने के बजाय कि यह लागू हो गया है, ollama ps में गिरावट की पुष्टि करें। यदि आपने पहले cache type को नहीं बदला है, तो Ollama के KV cache के लिए q8_0 बनाम f16 का विवरण दोनों variables को set करने और पहले और बाद के आंकड़ों को पढ़ने की प्रक्रिया को कवर करता है। OLLAMA_NUM_PARALLEL=1 भी उतना ही महत्वपूर्ण है। Ollama एक साथ कई requests को serve कर सकता है, और प्रत्येक slot को context का अपना हिस्सा मिलता है, इसलिए parallelism बढ़ाने से आपके द्वारा बजट में रखे गए cache का गुणात्मक रूप से बढ़ना तय है। वर्तमान डिफ़ॉल्ट पहले से ही 1 है, और नीचे दिया गया override इसे वहीं स्थिर करता है। यदि एक से अधिक व्यक्ति इस box का उपयोग करेंगे, तो वह गुणा (multiplication) ही परेशानी की जड़ है, और एक 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": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

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

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 प्रवेश बिंदु (entry point) है। Weights 17 GB लेते हैं, vision projector लगभग 0.9 GB जोड़ता है, और आपके पास लगभग 12.5 GB बचते हैं। यह मार्जिन के साथ लगभग 128k टोकन के f16 संदर्भ को कवर करता है। 29 GB पर Q8_0 weights 32 GB के भीतर फिट हो जाते हैं, लेकिन उपयोगी संदर्भ vision projector, cache, ऑपरेटिंग सिस्टम और runtime मेमोरी पर भी निर्भर करता है। इस tier पर Q8 को चलाने योग्य मानने से पहले अपने बॉक्स पर कुल footprint की जाँच करें।

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

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

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

[
  {
    "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
  }
]

ये अधिकतम सीमाएँ हैं, वास्तविक माप नहीं। वास्तविक output दिखाए गए आँकड़े का लगभग 50 से 70 प्रतिशत होता है, क्योंकि memory latency और अपूर्ण prefetching के कारण आप कभी भी सैद्धांतिक चरम सीमा तक नहीं पहुँच पाते। एक two-channel DDR4-3200 VPS की अधिकतम सीमा 3 tokens प्रति सेकंड है, इसलिए लगभग 2 की अपेक्षा रखें। एक two-channel DDR5-4800 box की अधिकतम सीमा 4.5 है, इसलिए लगभग 3 की अपेक्षा रखें।

बड़े server rows के साथ एक चेतावनी जुड़ी है। एक twelve-channel EPYC platform में 460.8 GB/s और 27.1 tokens प्रति सेकंड की अधिकतम सीमा होती है, लेकिन आप पूरा EPYC किराए पर नहीं लेते। Memory bandwidth एक host-व्यापी संसाधन है जिसे उस machine के हर tenant के साथ साझा किया जाता है, इसलिए 8 vCPU slice के साथ बारह चैनलों की विशेष bandwidth नहीं मिलती। GPU-केंद्रित guides इसे पूरी तरह से छोड़ देते हैं, और यही कारण है कि समान vCPU count वाली दो VPS plans एक ही model पर तीन गुना तक भिन्न हो सकती हैं।

इसी कारण से अधिक vCPUs का होना जल्दी ही मदद करना बंद कर देता है। एक बार जब cores memory controller द्वारा प्रदान की जा सकने वाली गति से अधिक तेजी से data का अनुरोध करते हैं, तो अतिरिक्त threads केवल scheduling overhead बढ़ाते हैं और कुछ नहीं। Ollama में thread count के लिए कोई server-व्यापी environment variable नहीं है, इसलिए request options में num_thread को अपने physical core count पर सेट करें, मापें, और फिर उस संख्या का आधा प्रयास करें। कई shared plans पर निचली setting तेज होती है।

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

यदि dense 27B बहुत धीमा है, तो CPU पर हार मानने से पहले qwen3.6:35b-a3b tags को देखें। वे सभी 27.3 billion के बजाय प्रति token लगभग 3 billion parameters को सक्रिय करते हैं, इसलिए प्रति token memory traffic लगभग एक order of magnitude कम हो जाता है, भले ही disk पर file का आकार बड़ा हो। आप गति के लिए RAM footprint का समझौता करते हैं। यहाँ runtime का चुनाव भी मायने रखता है, और Ollama और llama.cpp समान अंतर्निहित inference code पर अलग-अलग CPU tuning controls प्रदान करते हैं।

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 को ट्यून करके कम किया जा सके। कार्ड अपनी memory को 1008 GB/s पर चलाता है, जबकि आपका VPS इसे केवल कुछ दसियों (tens) पर चलाता है।

इसलिए प्राथमिकता के बजाय workload के आधार पर निर्णय लें। जब काम asynchronous हो और कोई उसका इंतज़ार न कर रहा हो, तो CPU inference सही विकल्प है: जैसे दस्तावेज़ों के ढेर का रात भर में summarisation, या रात में चलने वाला classification job जो आपके सोते समय पूरा हो जाए। जिस क्षण कोई व्यक्ति output के लिए इंतज़ार कर रहा हो, या जिस क्षण requests आपके सर्वर की क्षमता से तेज़ आने लगें, उस समय GPU किराए पर लें। CPU runtimes एक समय में केवल एक request तक सीमित नहीं हैं: llama.cpp server के दस्तावेज़ CPU पर भी parallel decoding और continuous batching का उल्लेख करते हैं, और Ollama भी अधिक cache की कीमत पर parallel requests को serve कर सकता है। निर्णय इस बात पर निर्भर करता है कि आपकी मापी गई serving rate क्या है और requests के आने की दर क्या है, इसलिए अपने बॉक्स पर एक वास्तविक batch का समय मापें। एक बार जब requests उस दर से तेज़ आने लगती हैं, तो queue बढ़ने लगती है।

लागत की तुलना उतनी स्पष्ट नहीं है जितनी दिखती है। एक 64 GB VPS महीने के हर घंटे का बिल लेता है, चाहे model loaded हो या न हो, जबकि hourly GPU rental में compute charges को storage charges से अलग रखा जाता है, जो काम रुकने के बाद भी जारी रह सकते हैं। यदि आपका वास्तविक उपयोग दिन में दो घंटे है, तो किराए का GPU तेज़ और सस्ता दोनों हो सकता है। पहले अपना duty cycle निकालें, फिर उसकी कीमत तय करें। GPU के साथ VPS चुनना इस बात को कवर करता है कि instance पर क्या जाँचें, और vLLM, Ollama से आगे निकल जाता है जब आप GPU पर concurrent requests serve करते हैं क्योंकि यह उन्हें बेहतर तरीके से 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.12 या बाद का वर्जन प्रिंट करना चाहिए, जो Qwen 3.8 27B सपोर्ट वाला पहला रिलीज है। कुछ भी पुल करने से पहले free -g चेक करें। यह GiB में रिपोर्ट करता है, इसलिए 32 GB RAM वाला प्लान total कॉलम में लगभग 29 दिखा सकता है; उपलब्ध मेमोरी की तुलना ऊपर दिए गए वेट्स और कैश बजट से करें।

रनटाइम ऑप्शंस को अपने शेल के बजाय 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

--verbose आउटपुट वह माप है जिसके लिए आप आए थे। eval rate जनरेशन के दौरान आपके टोकन प्रति सेकंड हैं। prompt eval rate आपकी प्रीफिल स्पीड है। load duration वह समय है जो डिस्क से वेट्स को पढ़ने में लगा, और इसीलिए OLLAMA_KEEP_ALIVE=60m सेट किया गया है: CPU पर, हर रिक्वेस्ट पर डिस्क से 17 GB को रिलोड करना रिक्वेस्ट से ज्यादा महंगा पड़ता है। डिफॉल्ट आइडल टाइमआउट पांच मिनट है, जो इतना कम है कि आइटम्स के बीच गैप वाली बैच क्यू को बार-बार वह लोड कॉस्ट चुकानी पड़ती है, और मॉडल को रेजिडेंट रखने के विकल्प प्रति-रिक्वेस्ट keep_alive फील्ड और सेटिंग को रीबूट के बाद भी बनाए रखने, दोनों को कवर करते हैं।

जब मॉडल लोड हो, तो दूसरे टर्मिनल से फुटप्रिंट चेक करें।

ollama ps

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

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

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

प्रक्रिया उत्तर के बीच में ही गायब हो जाती है। 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 में नहीं है। एक version number जो अभी तक release नहीं हुआ है, ठीक यही परिणाम देता है, और tag में कोई भी typo भी यही करता है। qwen3.8:27b स्वयं वास्तविक है, इसलिए यदि वह सटीक tag विफल हो जाता है, तो पहले typo की जाँच करें। अपने network को दोष देने से पहले library page पर tag की पुष्टि करें, और यदि कोई वास्तविक tag pull हो जाता है लेकिन run नहीं होता है, तो 0.32.12 के मुकाबले ollama --version की जाँच करें।

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

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

CPU-only 27B मॉडल वास्तव में किस काम के लिए उपयोगी है

उम्मीदों के बजाय आंकड़ों के आधार पर अपेक्षाएं तय करें। दो से चार tokens प्रति सेकंड की गति पर, 500 tokens का उत्तर आने में दो से चार मिनट का समय लगता है। यह chat के लिए अनुपयोगी है, लेकिन queue-आधारित कार्यों के लिए पूरी तरह से काम करने योग्य है। जो मॉडल उत्तर देने से पहले सोचता है, वह इस गणित को और खराब कर देता है, क्योंकि छिपे हुए reasoning tokens भी उसी धीमी गति से उत्पन्न होते हैं जिस गति से उत्तर। इसलिए reasoning effort को कार्य के स्तर के अनुसार समायोजित करना उन कुछ तरीकों में से एक है जो मॉडल को बदले बिना उत्तर की अवधि को छोटा कर सकता है। दस्तावेज़ों का सारांश (summarisation), बल्क टैगिंग, फाइलों के बैकलॉग से डेटा निकालना और बिना निगरानी के कोड की समीक्षा करना, ये सभी कार्य इस गति को सहन कर सकते हैं, क्योंकि इनके उत्तर की प्रतीक्षा में कोई बैठा नहीं होता। कोडिंग सहायता इसी सीमा पर स्थित है, इसलिए एक कोडिंग एजेंट को अपने होस्ट किए गए मॉडल से जोड़ना commit messages और test scaffolding जैसे बैकग्राउंड कार्यों के लिए फायदेमंद है, न कि उन इनलाइन सुझावों के लिए जिनके लिए आप प्रतीक्षा करते हैं।

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

इनमें से किसी भी चीज़ को बेंचमार्क करने के लिए आपको वास्तविक संरचित इनपुट की आवश्यकता होती है, और अधिकांश सार्वजनिक डेटा API थ्रूपुट मापने से पहले ही अकाउंट की मांग करते हैं। Strasmore का डेमो स्कीमा (जिसे हम चलाते हैं) बिना किसी key या साइनअप के US equities और options डेटा पर read-only SQL को प्रलेखित करता है, जिसमें database-qualified table names का उपयोग किया जाता है: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5। डेमो की सीमाएं प्रति कॉल 500 rows और 20 सेकंड हैं, जिसमें 1 January 2025 से आगे का इतिहास उपलब्ध है, जो दो-tokens-प्रति-सेकंड वाले बॉक्स की क्षमता से काफी अधिक है। पूर्ण कॉलम सूची https://ai.strasmore.com/api/demo/schema पर उपलब्ध है।

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

FAQ

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

हाँ। 21 October 2026 तक Ollama लाइब्रेरी में एक qwen3.8 प्रविष्टि है, और qwen3.8:27b (जिसे latest टैग भी किया गया है) 27.3 बिलियन पैरामीटर वाले डेंस मॉडल का 18 GB का Q4_K_M बिल्ड है, जिसमें विजन प्रोजेक्टर और 256K कॉन्टेक्स्ट विंडो है। यह स्थानीय रूप से चलता है और इसके लिए Ollama v0.32.12 या बाद का संस्करण आवश्यक है। पुराने qwen3.6:27b और qwen3.5:27b टैग अभी भी सूचीबद्ध हैं। वर्तमान सूची के लिए https://ollama.com/library/qwen3.8/tags देखें। यदि कोई टैग मौजूद नहीं है, तो वह Error: pull model manifest: file does not exist के साथ विफल हो जाता है।

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

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

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

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

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

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

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

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