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

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

Qwen 3.8 27B चलाने के लिए पहले ऐसे model tag की आवश्यकता है जो वास्तव में उपलब्ध हो। 4 August 2026 तक Ollama library में qwen3.8 की कोई entry नहीं है। उपलब्ध 27B tags में सबसे निकट का tag qwen3.6:27b है: इसमें 27.8 billion parameters, Q4_K_M quantisation और Apache 2.0 licence है। नीचे दिए गए सभी commands और numbers Ollama v0.32.5 पर इसी tag का उपयोग करते हैं। यह version 27 July 2026 को प्रकाशित हुआ था।

संक्षिप्त उत्तर है: हाँ, 32 GB या उससे अधिक RAM वाले VPS पर इसे चलाया जा सकता है, लेकिन इसकी गति कम होगी। Q4 पर चलने वाले 27B dense model को केवल weights के लिए लगभग 17 GB RAM चाहिए। इसमें context का एक भी token शामिल नहीं है। इसलिए 8 GB और 16 GB plans पूरी तरह अपर्याप्त हैं। सामान्य two-channel DDR4 VPS पर अधिकतम गति लगभग 3 tokens per second होगी। यह गति अधिकांश लोगों की पढ़ने की गति से कम है।

3.8 कहाँ से आया? सबसे संभावित कारण parameter count है। qwen3.6:27b के लिए Ollama page पर 27.8B parameters दिए गए हैं। 27.8 को बाद में 3.8 के रूप में याद रखना आसान है। इसके अलावा qwen3.5:27b भी उपलब्ध है। यह पिछले release का वही Q4_K_M build है। कोई भी command copy करने से पहले live list को Ollama qwen3.6 tag page पर जाँचें। यदि बाद में वास्तविक qwen3.8 release होता है, तो यहाँ दिए गए हिसाब फिर भी लागू होंगे, क्योंकि वे version number के बजाय parameter count और प्रति weight bits पर निर्भर करते हैं।

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

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

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 line में 27.8B और quantisation line में Q4_K_M लिखा है, तो आपके पास वही build है जिस पर यह guide आधारित है। इसी weights के लिए library में अधिक precision वाले qwen3.6:27b-q8_0 और qwen3.6:27b-bf16 भी उपलब्ध हैं। इसके अलावा 35b-a3b tags का एक समूह है, जो MoE (mixture of experts) models हैं और CPU पर इनका व्यवहार काफी अलग होता है। इनकी अधिक जानकारी नीचे दी गई है।

प्रति weight parameters की संख्या और bytes

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

सूत्र एक पंक्ति का है। Weights के bytes = parameters * bits per weight / 8। शुद्ध 4 bits पर 27.8 billion parameters का आकार 13.9 GB होगा। उपलब्ध Q4_K_M tag का आकार 17 GB है। इसका अर्थ है कि व्यवहार में प्रत्येक weight पर 4.89 bits उपयोग हो रहे हैं।

यह अंतर कोई त्रुटि नहीं है। K-quant formats प्रत्येक tensor को nominal width पर store नहीं करते। Compression से जिन tensors की quality सबसे अधिक घटती है, उन्हें 5 या 6 bits पर रखा जाता है। Token embedding और output layers को आम तौर पर Q6_K या Q8_0 पर रखा जाता है। Format का नाम औसत दर्शाता है, और यह औसत लगभग 4.9 पर आता है। यही प्रभाव scale के दूसरे सिरे पर भी दिखता है। BF16 के लिए 56 GB का अर्थ प्रति weight 16.1 bits है, न कि स्थिर 16 bits, क्योंकि file में metadata और full-precision embedding table भी होती है।

इस model के लिए Q5_K_M का कोई published tag नहीं है। इसलिए 19.8 GB वाली row को मापने के बजाय इस format के सामान्य 5.7 bits per weight के आधार पर calculate किया गया है। Q8_0 का आकार Q4 से लगभग दोगुना होकर 30 GB हो जाता है। केवल CPU वाले box पर यह दोगुना आकार प्रत्येक token के लिए memory traffic को भी दोगुना कर देता है। इसलिए tokens per second भी लगभग आधे रह जाते हैं। इसी कारण यहाँ Q4_K_M सही default है।

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

Weights की लागत स्थिर रहती है। KV cache (key और value cache, यानी model द्वारा पहले देखे गए प्रत्येक token के लिए रखा जाने वाला attention state) 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
  }
]

ये आँकड़े उस architecture पर आधारित हैं जिसे 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 लगते हैं। अपने system के लिए मेरी गणना पर निर्भर न रहें। Model load करें और ollama ps के SIZE column को पढ़ें। इसमें weights, cache और overhead का कुल आकार एक ही figure के रूप में दिया जाता है।

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

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

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."
  }
]

इन दो संख्याओं को weights के साथ उपलब्ध context के हजारों tokens के रूप में पढ़ें। यह गणना f16 cache, headless Linux VPS, operating system के लिए बचे लगभग 1.5 GB और थोड़े अतिरिक्त margin पर आधारित है। शून्य का अर्थ है कि weights स्वयं fit नहीं होते, इसलिए कुछ भी fit नहीं होगा।

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

32 GB प्रारंभिक उपयोगी स्तर है। Weights 17 GB लेते हैं और लगभग 13 GB बचते हैं। यह margin के साथ लगभग 32k tokens के f16 context के लिए पर्याप्त है। 30 GB वाले Q8_0 weights इस स्तर पर बिल्कुल fit नहीं होते।

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

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

Dense model से एक token generate करने के लिए memory से हर weight को एक बार पढ़ना पड़ता है। कुछ weights को नहीं। सभी weights को। इसलिए speed limit आपके core count पर नहीं, बल्कि memory bandwidth को weights के size से विभाजित करने पर निर्भर है। 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
  }
]

ये theoretical ceilings हैं, measurements नहीं। वास्तविक output आम तौर पर दिखाई गई संख्या के लगभग 50 से 70 प्रतिशत तक रहता है, क्योंकि memory latency और imperfect prefetching के कारण theoretical peak तक पहुँचना संभव नहीं होता। दो-channel DDR4-3200 VPS की ceiling 3 tokens per second है, इसलिए लगभग 2 की अपेक्षा रखें। दो-channel DDR5-4800 box की ceiling 4.5 है, इसलिए लगभग 3 की अपेक्षा रखें।

बड़े server rows के साथ एक चेतावनी जुड़ी है। बारह-channel EPYC platform की memory bandwidth 460.8 GB/s और ceiling 27.1 tokens per second है, लेकिन आप पूरा EPYC rent नहीं करते। Memory bandwidth उस host पर मौजूद हर tenant के बीच साझा होने वाला host-wide resource है। इसलिए 8 vCPU slice के साथ बारह channels की exclusive bandwidth नहीं मिलती। GPU-केंद्रित guides इस बात को पूरी तरह छोड़ देती हैं। यही कारण है कि समान model पर समान vCPU count वाले दो VPS plans के performance में तीन गुना अंतर हो सकता है।

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

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

यदि dense 27B बहुत धीमा है, तो CPU छोड़ने से पहले qwen3.6:35b-a3b tags देखें। ये हर token पर सभी 27.8 billion parameters के बजाय लगभग 3 billion parameters activate करते हैं। इसलिए disk पर file बड़ी होने के बावजूद प्रति token memory traffic लगभग एक order of magnitude घट जाता है। इसके बदले RAM footprint बढ़ता है और speed मिलती है। यहाँ runtime का चुनाव भी महत्वपूर्ण है। समान underlying inference code पर Ollama और llama.cpp अलग 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 पर यही formula लागू करने पर उत्तर की श्रेणी बदल जाती है। 24 GB consumer card इन weights पर अधिकतम 59 tokens per second तक पहुँचता है। मौजूदा data centre card 197 तक पहुँचता है। Thread counts को tune करके यह अंतर समाप्त नहीं किया जा सकता। आपका VPS जहाँ केवल कुछ tens की गति देता है, वहीं card अपनी memory को 1008 GB/s पर चलाता है।

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

Cost comparison देखने में जितना सरल लगता है, उतना है नहीं। 64 GB VPS में model loaded हो या नहीं, महीने के हर hour का billing होता है। इसके विपरीत, GPU instance के लिए केवल उतने hours का billing होता है जितने समय आप उसे चलाते हैं। यदि आपका वास्तविक उपयोग प्रतिदिन 2 hours है, तो rented GPU तेज़ और सस्ता दोनों हो सकता है। पहले अपना duty cycle निकालें, फिर price की तुलना करें। GPU वाला VPS चुनना instance पर जाँचने योग्य बातों को शामिल करता है, और GPU पर concurrent requests serve करने पर vLLM Ollama से आगे निकल जाता है क्योंकि वह requests को सही तरीके से batch करता है।

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

Ollama install करें और अपने सिस्टम की माप लें

Install script आधिकारिक है और यह dedicated ollama user के रूप में चलने वाली systemd service सेट करता है।

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

ollama --version में 0.32.5 या उसके बाद का version दिखना चाहिए। कोई भी चीज़ pull करने से पहले free -g जाँचें। यदि Mem line के total column में 32 से कम संख्या दिखे, तो यहीं रुकें और छोटा model चुनें, क्योंकि ऐसा 17 GB model pull करना जिसे आप चला नहीं सकते, एक घंटे और बहुत-सी disk space की बर्बादी है।

Runtime options को shell में नहीं, बल्कि systemd override में सेट करें। Model service के अंदर चलता है, इसलिए उसे आपका interactive environment दिखाई नहीं देता।

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 output वही measurement है जिसकी आपको आवश्यकता है। Generation के दौरान eval rate आपकी tokens per second गति है। prompt eval rate आपकी prefill speed है। load duration वह समय है जिसमें disk से weights पढ़े गए। इसी कारण OLLAMA_KEEP_ALIVE=60m सेट किया गया है: CPU पर हर request के लिए disk से 17 GB दोबारा पढ़ने में request पूरी करने से अधिक समय लग सकता है।

Model load रहने के दौरान दूसरे terminal से उसका memory footprint जाँचें।

ollama ps

SIZE column KV cache सहित वास्तविक memory footprint दिखाता है। यह weights और KV chart में आपकी context length वाली row के योग के करीब होना चाहिए। 8192 tokens और 8-bit cache पर weights के अतिरिक्त लगभग एक gigabyte की memory अपेक्षित है। यदि cache f16 पर रहता, तो यह 2 GB होती। PROCESSOR column में 100% CPU दिखना चाहिए। यदि कुछ और दिखे, तो किसी process ने GPU का उपयोग कर लिया है और इस guide में दिए गए speed numbers आपके सिस्टम पर लागू नहीं होते।

विफलता की स्थितियाँ और दिखाई देने वाले सटीक संदेश

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

उत्तर के बीच में process गायब हो जाती है। Client कोई उपयोगी जानकारी नहीं दिखाता और journalctl -u ollama -n 50 service के restart होने का संकेत देता है। dmesg -T | tail चलाएँ। Out of memory: Killed process ... (ollama) वाली पंक्ति का अर्थ है कि kernel के OOM killer ने process समाप्त कर दी। ऐसा तब होता है जब pre-load check सफल हो जाता है, लेकिन लंबी बातचीत के दौरान cache अनुमानित आकार से बढ़ जाती है। Context length कम करें।

Pull तुरंत विफल हो जाता है। Error: pull model manifest: file does not exist का अर्थ है कि tag library में मौजूद नहीं है। qwen3.8:27b लिखने पर यही संदेश आता है। Version number में किसी भी typo का भी यही परिणाम होता है। Network को दोष देने से पहले library page पर tag की पुष्टि करें।

सब कुछ काम करता है, लेकिन गति अत्यंत कम है। पर्याप्त RAM वाले host पर प्रति सेकंड एक token से कम की गति compute के बजाय paging की ओर संकेत करती है। Generation के दौरान vmstat 1 चलाएँ। Non-zero si या so column का अर्थ है कि kernel swapping कर रहा है। इसका समाधान कम context या कम loaded models हैं। Swap activity के बिना लगातार अधिक wa का अर्थ है कि memory-mapped weights को disk से बार-बार पढ़ा जा रहा है। इसका अर्थ है कि वे वास्तव में memory में fit नहीं होते।

पहले token में 30 seconds लगते हैं और उसके बाद output तेज हो जाता है। यह prefill है और सामान्य व्यवहार है। Cache miss वाली प्रत्येक request पर लंबे system prompt को फिर से process करना पड़ता है। किसी अन्य tuning से पहले system prompt छोटा करें।

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

आशाओं के बजाय इन संख्याओं के आधार पर अपेक्षाएँ तय करें। दो से चार tokens प्रति सेकंड की गति पर 500 tokens का उत्तर देने में दो से चार मिनट लगते हैं। यह chat के लिए अनुपयोगी है, लेकिन queue के लिए पूरी तरह व्यावहारिक है। Document summarisation, bulk tagging, files के backlog से field extraction और unattended code review में इतनी देरी स्वीकार्य है, क्योंकि उत्तर की प्रतीक्षा में कोई व्यक्ति नहीं होता।

Privacy का तर्क सबसे महत्वपूर्ण है। Model आपके किराए पर लिए और नियंत्रित किए गए hardware पर चलता है, कोई request उस machine से बाहर नहीं जाती और प्रति-token bill नहीं होता। Regulated data के लिए तीन tokens प्रति सेकंड की गति पर भी यह काफी मूल्यवान है। इसकी ईमानदारी से तुलना दूसरे विकल्प से करें: frontier-scale model को self-host करने के लिए एक order of magnitude अधिक hardware चाहिए, और CPU पर 27B उस curve का सबसे सस्ता बिंदु है जहाँ output अभी भी पढ़ने लायक रहता है।

यदि यह आपका पहला Ollama install है, तो VPS पर Ollama चलाने की पूरी walkthrough उस service setup, HTTP API और firewall rules को समझाती है जिन्हें यह guide मानकर चलती है कि आपने पहले से configure कर रखा है। Port 11434 को internet पर expose न करें। Ollama अपने साथ कोई authentication नहीं देता, इसलिए जो भी इस port तक पहुँच सकता है, वह आपके model का उपयोग कर सकता है और आपके prompts पढ़ सकता है।

FAQ

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

नहीं। 4 August 2026 तक Ollama library में कोई qwen3.8 namespace नहीं है। उपलब्ध 27B tags qwen3.5:27b और qwen3.6:27b हैं। दोनों 27.8 billion parameters वाले dense model के Q4_K_M builds हैं। Search term में 3.8 लगभग निश्चित रूप से version number समझा गया 27.8B parameter count है। वर्तमान सूची के लिए https://ollama.com/library/qwen3.6/tags देखें। सबसे नया released 27B चाहिए तो qwen3.6:27b pull करें। जो tag मौजूद नहीं है, वह Error: pull model manifest: file does not exist के साथ fail होता है।

Qwen 27B model को VPS पर चलाने के लिए कितनी RAM चाहिए?

Q4_K_M के लिए 32 GB व्यावहारिक न्यूनतम है। Weights का आकार 17 GB है। Operating system को लगभग 1.5 GB चाहिए। f16 पर context के प्रत्येक 4000 tokens के लिए KV cache लगभग 1 GB अतिरिक्त लेता है। 16 GB plan में weights के लिए पर्याप्त memory नहीं होती। Swap मदद नहीं करता, क्योंकि file memory-mapped होती है और kernel प्रत्येक token पर उसे disk से फिर पढ़ता है। 64 GB में लंबे context या 30 GB वाले Q8_0 weights के लिए पर्याप्त जगह रहती है।

CPU पर 27B model कितने tokens per second देगा?

अपनी memory bandwidth को weights के आकार से divide करें। फिर उस परिणाम का 50 से 70 प्रतिशत लें। Two-channel DDR4-3200 VPS की ceiling लगभग 3 tokens per second होती है और वह लगभग 2 deliver करता है। Two-channel DDR5-4800 box की ceiling लगभग 4.5 होती है और वह लगभग 3 deliver करता है। अधिक channels वाले server platforms कागज पर बेहतर दिखते हैं। लेकिन host के हर tenant के बीच memory bandwidth shared होती है। इसलिए ollama run qwen3.6:27b --verbose से अपने system को measure करें और eval rate line पढ़ें।

केवल CPU वाले VPS पर Q4 या Q8 का उपयोग करना चाहिए?

लगभग हर स्थिति में Q4_K_M का उपयोग करें। Q8_0 का आकार 30 GB है, जबकि 17 GB है। इसलिए इसके लिए 64 GB plan चाहिए। यह प्रत्येक token पर लगभग दोगुनी memory move करता है, जिससे tokens per second लगभग आधे हो जाते हैं। 27B model पर Q4_K_M और Q8_0 के बीच quality difference अधिकांश tasks में छोटा होता है। RAM को लंबे context के लिए उपयोग करें। इससे model की capabilities बदलती हैं, केवल phrasing नहीं।

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

जब आपका duty cycle कम हो या कोई व्यक्ति परिणाम की प्रतीक्षा कर रहा हो। इन weights पर 24 GB memory वाला GPU लगभग 59 tokens per second तक पहुंचता है। Typical VPS पर यह गति 2 या 3 होती है। GPU केवल चलने वाले hours के लिए bill होता है। 64 GB VPS पर model loaded न होने पर भी पूरे महीने का bill आता है। गणना करें कि आप वास्तव में प्रतिदिन कितने hours tokens generate करते हैं। दो या तीन hours से कम उपयोग में hourly GPU rental आम तौर पर speed और cost, दोनों में बेहतर होता है। लगातार चलने वाला low-priority batch work ऐसे मामलों में always-on VPS से बेहतर होता है।