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

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

VPS पर Qwen 3.8 27B चलाने के लिए आपको सबसे पहले एक ऐसे मॉडल टैग की आवश्यकता है जो मौजूद हो, और 4 August 2026 तक Ollama लाइब्रेरी में qwen3.8 नाम की कोई एंट्री नहीं है। सबसे निकटतम रिलीज्ड 27B टैग qwen3.6:27b है: 27.8 बिलियन पैरामीटर्स, Q4_K_M क्वांटाइजेशन, Apache 2.0 लाइसेंस। नीचे दिए गए प्रत्येक कमांड और प्रत्येक संख्या में Ollama v0.32.5 पर उस टैग का उपयोग किया गया है, जिसे 27 July 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 मिलता है, इसलिए इसे server पर ही तय करना आसान है। जो tag मौजूद है, वह भी स्थानीय स्तर पर न चलने योग्य हो सकता है, और यही वह बात है जो लोगों को GLM 5.2, जो library में सूचीबद्ध है लेकिन केवल Ollama के cloud से serve किया जाता है के साथ उलझाती है।

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 को print करता है। यदि parameter line 27.8B पढ़ती है और quantisation line Q4_K_M पढ़ती है, तो आपके पास वही build है जिसके आधार पर यह guide लिखी गई है। Library में समान weights के लिए उच्च precision पर 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 फॉर्मेट हर टेंसर को नाममात्र की चौड़ाई (nominal width) पर स्टोर नहीं करते हैं। जो टेंसर कंप्रेशन के दौरान सबसे अधिक गुणवत्ता खोते हैं, उन्हें 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 यहाँ सही डिफॉल्ट है। यदि आप मेमोरी के बजाय गुणवत्ता के आधार पर निर्णय लेना चाहते हैं, तो Q4, Q8 और fp16 की विस्तृत तुलना दिखाती है कि आउटपुट वास्तव में कहाँ से खराब होना शुरू होता है।

Context बढ़ने पर KV cache की लागत

Model weights एक निश्चित लागत हैं। KV cache (key and 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 केवल एक मुख्य आकर्षण है, न कि कोई व्यावहारिक योजना। f16 पर इसे भरने के लिए weights के ऊपर 64 GB cache की आवश्यकता होगी, जबकि एक ऐसी मशीन पर जिसने पहले ही weights पर 17 GB खर्च कर दिए हैं। Ollama डिफ़ॉल्ट रूप से आपको पूरी window नहीं देता है। यह बहुत छोटी window load करता है, और आप इसे OLLAMA_CONTEXT_LENGTH के माध्यम से जानबूझकर बढ़ाते हैं। यह server-wide variable ही एकमात्र विकल्प नहीं है, और individual request पर num_ctx सेट करना आपको बाकी सभी चीजों के लिए एक सस्ता डिफ़ॉल्ट रखने की अनुमति देता है, जबकि एक लंबे कार्य को बड़ी window मिल जाती है। इसे चरणों में बढ़ाएं और प्रत्येक बदलाव के बाद ollama ps की जाँच करें।

दो सेटिंग्स 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 को भी सेट करें, और यह मानने के बजाय कि यह लागू हो गया है, ollama ps में गिरावट की पुष्टि करें। OLLAMA_NUM_PARALLEL=1 भी उतना ही महत्वपूर्ण है। Ollama एक साथ कई requests को serve कर सकता है, और प्रत्येक slot को context का अपना हिस्सा मिलता है, इसलिए parallelism को डिफ़ॉल्ट पर छोड़ने से आपके द्वारा बजट की गई cache चुपचाप गुणा हो जाती है। यदि एक से अधिक व्यक्ति इस बॉक्स का उपयोग करेंगे, तो वह गुणा ही समस्या की जड़ है, और एक 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) के हजारों टोकन के रूप में पढ़ें, जो f16 कैश पर, एक headless Linux VPS पर weights के साथ फिट होते हैं। इसमें ऑपरेटिंग सिस्टम के लिए लगभग 1.5 GB जगह और थोड़ा अतिरिक्त मार्जिन सुरक्षित रखा गया है। शून्य का अर्थ है कि weights ही फिट नहीं होते, इसलिए कुछ भी फिट नहीं होगा।

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

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

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

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 के कारण आप कभी भी सैद्धांतिक शिखर (theoretical peak) तक नहीं पहुँच पाते। एक 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 की bandwidth और 27.1 tokens प्रति सेकंड की अधिकतम सीमा होती है, लेकिन आप पूरा EPYC किराए पर नहीं लेते। Memory bandwidth एक host-wide संसाधन है जिसे उस machine के सभी tenants साझा करते हैं, इसलिए 8 vCPU slice के साथ बारह channels की exclusive bandwidth नहीं मिलती। GPU-केंद्रित guides इस तथ्य को पूरी तरह छोड़ देते हैं, और यही कारण है कि समान vCPU count वाले दो VPS plans एक ही model पर तीन गुना तक भिन्न हो सकते हैं।

इसी कारण से, अधिक vCPUs का होना भी जल्दी ही बेअसर हो जाता है। जब cores memory controller द्वारा डेटा प्रदान करने की क्षमता से अधिक तेजी से डेटा का अनुरोध करते हैं, तो अतिरिक्त threads केवल scheduling overhead बढ़ाते हैं और कुछ नहीं। OLLAMA_NUM_THREAD को अपने physical core count पर set करें, मापें, और फिर उस संख्या का आधा उपयोग करके देखें। कई shared plans पर कम setting अधिक तेज होती है।

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

यदि dense 27B बहुत धीमा है, तो CPU पर हार मानने से पहले qwen3.6:35b-a3b tags को देखें। वे सभी 27.8 billion parameters के बजाय प्रति token लगभग 3 billion parameters को सक्रिय करते हैं, इसलिए disk पर file बड़ी होने के बावजूद प्रति token memory traffic लगभग दस गुना कम हो जाता है। आप गति के लिए RAM footprint का समझौता करते हैं। यहाँ runtime का चुनाव भी मायने रखता है, और Ollama और llama.cpp एक ही underlying 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 इसे केवल कुछ दसियों GB/s पर चलाता है।

इसलिए प्राथमिकता के बजाय workload के आधार पर निर्णय लें। जब काम asynchronous हो और कोई उसका इंतज़ार न कर रहा हो, तो CPU inference सही विकल्प है: जैसे दस्तावेज़ों के ढेर का रात भर में summarisation, या रात में चलने वाला classification job। जिस क्षण कोई व्यक्ति output का इंतज़ार कर रहा हो, या requests हर 30 सेकंड में एक से अधिक की दर से आ रही हों, तो GPU किराए पर लें। इसका कारण यह है कि केवल CPU वाले 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 का ऐसा मॉडल पुल करना जिसे आप चला नहीं सकते, एक घंटा और काफी डिस्क स्पेस बर्बाद करेगा।

रनटाइम विकल्पों को अपने शेल के बजाय 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 जनरेशन के दौरान आपके टोकन प्रति सेकंड की गति है। prompt eval rate आपकी प्रीफिल स्पीड है। load duration वह समय है जो डिस्क से वेट्स (weights) पढ़ने में लगा, और यही कारण है कि OLLAMA_KEEP_ALIVE=60m सेट किया गया है: CPU पर, हर रिक्वेस्ट पर डिस्क से 17 GB को रिलोड करने की लागत रिक्वेस्ट से अधिक होती है। डिफ़ॉल्ट आइडल टाइमआउट पांच मिनट है, जो इतना कम है कि आइटम के बीच अंतराल वाली बैच क्यू बार-बार वह लोड लागत चुकाती है, और मॉडल को रेजिडेंट रखने के विकल्प प्रति-रिक्वेस्ट keep_alive फील्ड और सेटिंग को रीबूट के बाद भी बनाए रखने, दोनों को कवर करते हैं।

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

ollama ps

SIZE कॉलम वास्तविक मेमोरी फुटप्रिंट है जिसमें KV कैश शामिल है, और इसे वेट्स के साथ-साथ KV चार्ट में आपके कॉन्टेक्स्ट लेंथ के लिए दी गई रो के करीब होना चाहिए। 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 ने कर्नल को इसे सुलझाने देने के बजाय आवंटन से पहले ही जांच कर ली। कॉन्टेक्स्ट की लंबाई कम करें, छोटे टैग पर आएं, या बड़े प्लान पर शिफ्ट हों।

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

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

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

पहला टोकन 30 सेकंड लेता है और फिर आउटपुट की गति बढ़ जाती है। यह प्रीफिल (prefill) है, और यह सामान्य है। एक लंबे सिस्टम प्रॉम्प्ट की कीमत हर उस अनुरोध पर चुकानी पड़ती है जो कैश में नहीं मिलता, इसलिए कुछ भी और ट्यून करने से पहले सिस्टम प्रॉम्प्ट को छोटा करें।

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

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

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

इनमें से किसी भी चीज़ को बेंचमार्क करने के लिए आपको वास्तविक स्ट्रक्चर्ड इनपुट की आवश्यकता होती है, और अधिकांश सार्वजनिक डेटा API थ्रूपुट मापने से पहले ही अकाउंट मांगते हैं। Strasmore का डेमो एंडपॉइंट (जिसे हम चलाते हैं) बिना किसी key या साइनअप के 22 वर्षों के अमेरिकी बाजार डेटा पर read-only SQL का उत्तर देता है: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 पर एक GET अनुरोध JSON लौटाता है जिसे आप सीधे प्रॉम्प्ट लूप में पाइप कर सकते हैं, साथ ही वह सटीक SQL भी जो इसे उत्पन्न करता है, ताकि मॉडल के पास सारांशित करने के लिए कुछ ऐसा हो जिसे आप स्वतंत्र रूप से जांच सकें। सीमाएं 500 पंक्तियाँ और प्रति कॉल 20 सेकंड हैं, जो दो-टोकन-प्रति-सेकंड वाले बॉक्स की खपत से काफी अधिक है। कॉलम की पूरी सूची https://api.strasmore.com/v1/schema पर उपलब्ध है।

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

FAQ

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

नहीं। 4 अगस्त 2026 तक Ollama लाइब्रेरी में कोई qwen3.8 नामस्थान (namespace) नहीं है। जो 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 को पुल (pull) करें। जो टैग मौजूद नहीं है, वह Error: pull model manifest: file does not exist त्रुटि के साथ विफल हो जाएगा।

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

Q4_K_M के लिए 32 GB व्यावहारिक न्यूनतम आवश्यकता है। वेट्स (weights) 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 बेहतर होता है।