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 tag qwen3.6:27b आहे: 27.8 billion parameters, Q4_K_M quantisation आणि Apache 2.0 licence. खालील प्रत्येक command आणि संख्या Ollama v0.32.5 वर या tag साठी आहे. ही आवृत्ती 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 पेजवर 27.8B parameters असल्याचे नमूद आहे. 27.8 हा आकडा नंतर 3.8 असा सहज लक्षात राहू शकतो. तसेच qwen3.5:27b देखील आहे. हा मागील release मधील तोच Q4_K_M build आहे. कोणताही command copy करण्यापूर्वी Ollama qwen3.6 tag पेजवरील live list तपासा. पुढे खरा qwen3.8 release झाला, तरी येथील गणित लागू राहील. कारण ते version number ऐवजी parameter count आणि प्रत्येक weight साठी लागणाऱ्या bits वर आधारित आहे.

कोणता 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 line मध्ये 27.8B आणि quantisation line मध्ये Q4_K_M दिसत असल्यास, या मार्गदर्शकात आधार घेतलेला build तुमच्याकडे आहे. त्याच weights साठी library मध्ये अधिक precision असलेले qwen3.6:27b-q8_0 आणि qwen3.6:27b-bf16 देखील उपलब्ध आहेत. याशिवाय 35b-a3b tags चा संच आहे. हे MoE (mixture of experts) models आहेत आणि CPU वर त्यांचे वर्तन लक्षणीयरीत्या वेगळे असते. त्याबद्दल पुढे अधिक माहिती दिली आहे.

वजनाच्या प्रत्येक बिटनुसार parameters ची संख्या

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

सूत्र एका ओळीत मांडता येते. वजनांचे bytes = parameters * प्रत्येक weight मधील bits / 8. अचूक 4 bits धरल्यास, 27.8 billion parameters साठी 13.9 GB लागतील. वितरित केलेल्या Q4_K_M tag चा आकार 17 GB आहे. प्रत्यक्षात हे 4.89 bits प्रति weight इतके होते.

हा फरक त्रुटी नाही. K-quant formats प्रत्येक tensor ला नाममात्र width वर साठवत नाहीत. Compression मुळे ज्या tensors च्या गुणवत्तेवर सर्वाधिक परिणाम होतो, ते 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 प्रति weight दर वापरून काढलेली आहे. Q8_0 मुळे Q4 च्या तुलनेत आकार जवळपास दुप्पट होऊन 30 GB होतो. केवळ CPU वापरणाऱ्या system मध्ये या दुप्पट आकारामुळे प्रत्येक token साठी memory traffic देखील दुप्पट होते. त्यामुळे तुमचा tokens per second दर साधारण निम्मा होतो. या कारणामुळेच येथे Q4_K_M हा योग्य default आहे.

संदर्भ वाढत असताना KV cache ची किंमत

Weights हा स्थिर खर्च आहे. KV cache (key आणि value cache; मॉडेलने आधी पाहिलेल्या प्रत्येक token साठी जतन केलेली attention state) संदर्भाच्या लांबीसोबत सरळ प्रमाणात वाढतो. बहुतेक वेळा 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 ने या आकारमानाच्या अलीकडील 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 लोड करा आणि ollama ps मधील SIZE column वाचा. त्यात weights, cache आणि overhead यांची एकत्रित आकडेवारी दिलेली असते.

म्हणून model card वरील 256K context ही योजना नसून केवळ ठळक कमाल मर्यादा आहे. f16 वर तो पूर्ण भरल्यास weights व्यतिरिक्त cache साठी 64 GB लागतील. त्या मशीनने weights साठी आधीच 17 GB वापरलेले असतात. Ollama default नुसार तुम्हाला पूर्ण window देत नाही. ते त्यापेक्षा लहान window लोड करते आणि OLLAMA_CONTEXT_LENGTH वापरून ती जाणीवपूर्वक वाढवावी लागते. ती टप्प्याटप्प्याने वाढवा आणि प्रत्येक बदलानंतर ollama ps तपासा.

दोन settings मुळे cache निम्मा किंवा त्याहून कमी होतो. OLLAMA_KV_CACHE_TYPE=q8_0 cache 16 ऐवजी 8 bits मध्ये साठवते. त्यामुळे 32k tokens साठी cache 8 GB वरून 4 GB पर्यंत कमी होतो. यासाठी flash attention आवश्यक आहे. त्यामुळे OLLAMA_FLASH_ATTENTION=1 देखील सेट करा आणि बदल लागू झाला आहे असे गृहीत न धरता ollama ps मध्ये झालेली घट पडताळा. OLLAMA_NUM_PARALLEL=1 तितकेच महत्त्वाचे आहे. Ollama एकाच वेळी अनेक requests हाताळू शकते आणि प्रत्येक slot ला context चा स्वतःचा भाग मिळतो. त्यामुळे parallelism default वर ठेवले तर तुम्ही नियोजित केलेला cache शांतपणे अनेक पटींनी वाढतो. या मशीनचा वापर एकापेक्षा अधिक व्यक्ती करणार असतील, तर अडचण याच वाढीतून सुरू होते. self-hosted model एकाच वेळी किती वापरकर्त्यांना सेवा देऊ शकते हे 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."
  }
]

ही दोन संख्या weights सोबत, f16 cache वापरून, headless Linux VPS वर बसणाऱ्या context च्या हजारो tokens दर्शवतात. या VPS वर operating system साठी सुमारे 1.5 GB आणि थोडी अतिरिक्त मोकळी जागा ठेवलेली आहे. शून्य म्हणजे weights स्वतःच बसत नाहीत. त्यामुळे कोणतेही context बसत नाही.

8 GB आणि 16 GB हे जवळचे पर्याय नाहीत. 17 GB चे weights 16 GB RAM मध्ये बसत नाहीत. कोणतीही context setting हे बदलत नाही. Swap जोडल्यानेही समस्या सुटत नाही. Ollama GGUF file ला memory-map करते. त्यामुळे resident pages RAM पेक्षा जास्त झाल्यावर kernel त्या pages evict करून पुन्हा read करू लागतो. त्यानंतर प्रत्येक token साठी disk वरून gigabytes वाचावे लागतात. मशीनमध्ये iowait जास्त राहतो आणि प्रति सेकंद एक token पेक्षाही कमी output मिळतो.

32 GB हा किमान व्यवहार्य पर्याय आहे. Weights 17 GB घेतात आणि सुमारे 13 GB शिल्लक राहतात. ही जागा margin ठेवून सुमारे 32k tokens च्या f16 context साठी पुरेशी आहे. 30 GB आकाराचे Q8_0 weights या tier मध्ये अजिबात बसत नाहीत.

64 GB मध्ये पुरेशी मोकळीक असते. Q4 वापरल्यास सुमारे 128k tokens च्या context साठी जागा उरते. Q8_0 weights बसतात आणि त्यांच्यानंतर सुमारे 64k tokens साठी जागा उरते. Q8 मिळवण्यासाठी 64 GB साठी पैसे देण्यापूर्वी तुम्ही नेमके काय घेत आहात हे स्पष्ट असू द्या: output किंचित चांगला मिळतो, पण वेग निम्मा असतो, आणि आधीच धीम्या मशीनवर हा बदल होतो. जवळजवळ सर्वांसाठी मोठा context असलेला Q4 हा अधिक चांगला पर्याय आहे.

VPS वर CPU inference किती वेगाने होते?

Dense model मधून एक token तयार करण्यासाठी प्रत्येक weight memory मधून एकदा वाचावा लागतो. त्यातील काही नाही. सर्व weights वाचावे लागतात. त्यामुळे वेगाची मर्यादा core count नसून, weights च्या आकाराने भागलेली memory bandwidth आहे. Q4 मध्ये प्रत्येक token साठी memory traffic 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 टक्के दराने प्रत्यक्ष output मिळतो. याचे कारण memory latency आणि अपूर्ण prefetching आहे. त्यामुळे theoretical peak गाठता येत नाही. दोन-channel DDR4-3200 VPS ची कमाल मर्यादा 3 tokens per second आहे. त्यामुळे प्रत्यक्ष वेग साधारण 2 असेल. दोन-channel DDR5-4800 मशीनची कमाल मर्यादा 4.5 आहे. त्यामुळे प्रत्यक्ष वेग साधारण 3 असेल.

मोठ्या server rows सोबत एक महत्त्वाची सूचना आहे. बारा-channel EPYC platform मध्ये 460.8 GB/s memory bandwidth आणि 27.1 tokens per second ची कमाल मर्यादा आहे. मात्र तुम्ही संपूर्ण EPYC भाड्याने घेत नसता. त्या मशीनवरील प्रत्येक tenant memory bandwidth सामायिक करतो. त्यामुळे 8 vCPU slice सोबत बारा channel ची exclusive bandwidth मिळत नाही. GPU-केंद्रित मार्गदर्शक हा मुद्दा पूर्णपणे वगळतात. याच कारणामुळे समान model वर समान vCPU count असलेल्या दोन VPS plans च्या वेगात तीन पट फरक असू शकतो.

याच कारणामुळे अधिक vCPUs लवकरच उपयोगी पडेनासे होतात. Cores memory controller पुरवू शकतो त्यापेक्षा जलद data मागू लागले की अतिरिक्त threads मुळे scheduling overhead वाढतो; त्यापेक्षा अधिक फायदा होत नाही. OLLAMA_NUM_THREAD मध्ये तुमच्या physical core count ची value सेट करा आणि मोजमाप घ्या. त्यानंतर त्या संख्येच्या निम्म्या value ची चाचणी करा. अनेक shared plans वर कमी setting अधिक वेगवान ठरते.

Prompt processing वेगळ्या पद्धतीने कार्य करते. पहिला token दिसण्यापूर्वी input वर चालणारा pass म्हणजे prefill. तो bandwidth bound नसून compute bound असतो. त्यामुळे तो cores वाढवल्यावर वेगाने scale होतो. प्रत्यक्ष परिणाम असा दिसतो: मोठ्या prompt वर output सुरू होण्यापूर्वी दीर्घ pause येतो. त्यानंतर वरीलप्रमाणे स्थिर पण कमी दराने output मिळतो. --verbose वापरून या दोन्ही टप्प्यांचा स्वतंत्र वेळ मोजा. हे प्रत्येक request साठी prompt eval rate आणि eval rate दाखवते.

Dense 27B model खूपच धीमा असल्यास CPU सोडण्यापूर्वी qwen3.6:35b-a3b tags तपासा. हे सर्व 27.8 billion parameters ऐवजी प्रत्येक token साठी साधारण 3 billion parameters सक्रिय करतात. त्यामुळे disk वरील file मोठी असली तरी प्रत्येक token साठीचा memory traffic जवळपास एका order of magnitude ने कमी होतो. यासाठी RAM footprint च्या बदल्यात speed मिळते. येथे runtime ची निवडही महत्त्वाची आहे. समान underlying inference code वर Ollama आणि llama.cpp वेगवेगळी CPU tuning controls उपलब्ध करतात.

GPU तास भाड्याने घेणे केव्हा योग्य ठरते

[
  {
    "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 per second इतकी असते. सध्याचा data centre card 197 पर्यंत पोहोचतो. Thread counts मध्ये बदल करून हा फरक भरून काढता येत नाही. तुमच्या VPS वर memory bandwidth काही tens इतकी असताना card आपली memory 1008 GB/s वेगाने चालवतो.

म्हणून निवड आवडीनुसार नव्हे, तर workload नुसार करा. काम asynchronous असेल आणि त्याच्या निकालाची कोणी वाट पाहत नसेल, तर CPU inference योग्य पर्याय आहे: दस्तऐवजांच्या संचाचे रात्रभर summarisation किंवा तुम्ही झोपेत असताना चालणारे nightly classification job. एखादी व्यक्ती output ची वाट पाहत असेल, किंवा requests दर 30 seconds पेक्षा कमी अंतराने येत असतील, तर GPU भाड्याने घ्या. CPU-only box मध्ये batching साठी पुरेशी क्षमता नसते आणि queue वाढतच जाते.

खर्चाची तुलना दिसते तितकी सरळ नाही. 64 GB VPS मध्ये model loaded असो वा नसो, महिन्यातील प्रत्येक तासाचे billing होते. GPU instance मध्ये तो चालू ठेवलेल्या तासांचेच billing होते. तुमचा प्रत्यक्ष वापर दररोज दोन तासांचा असेल, तर rented GPU अधिक वेगवान आणि स्वस्त दोन्ही ठरू शकतो. आधी तुमचा duty cycle मोजा आणि त्यानंतर किंमत ठरवा. GPU असलेला VPS निवडणे instance वरच कोणत्या गोष्टी तपासाव्यात हे स्पष्ट करते. तसेच GPU वर concurrent requests serve केल्यावर concurrent requests serve केल्यावर vLLM Ollama पेक्षा पुढे का जाते हे समजते, कारण ते requests चे योग्य प्रकारे batching करते.

लोक विसरतात असा तिसरा पर्यायही आहे. Batch work साठी 27B CPU वर ठेवा आणि interactive path समोर hosted API model ठेवा. दोन्ही कामांसाठी एकच model वापरण्याची आवश्यकता नाही.

Ollama स्थापित करा आणि तुमच्या मशीनचे मोजमाप करा

ही install script अधिकृत आहे. ती स्वतंत्र ollama user म्हणून चालणारी systemd service तयार करते.

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

ollama --version ने 0.32.5 किंवा त्यानंतरची आवृत्ती दाखवली पाहिजे. काहीही pull करण्यापूर्वी free -g तपासा. Mem line मधील total column 32 पेक्षा कमी असल्यास येथेच थांबा आणि लहान model निवडा. तुम्ही चालवू शकत नसलेले 17 GB डाउनलोड केल्यास एक तास आणि मोठ्या प्रमाणात 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 हे तुम्हाला हवे असलेले मोजमाप आहे. Generation दरम्यानचा तुमचा tokens per second म्हणजे eval rate. Prefill speed म्हणजे prompt eval rate. Disk वरून weights वाचण्यासाठी लागलेला वेळ म्हणजे load duration. म्हणून OLLAMA_KEEP_ALIVE=60m सेट केले आहे: CPU वर प्रत्येक request वेळी disk वरून 17 GB पुन्हा load करण्यासाठी लागणारा वेळ request पूर्ण करण्यापेक्षा जास्त असतो.

Model load असताना दुसऱ्या terminal मधून त्याचा 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 वर राहिला असता हीच अतिरिक्त memory 2 GB असती. PROCESSOR column मध्ये 100% CPU दिसले पाहिजे. त्याऐवजी दुसरे काही दिसत असल्यास, एखाद्या प्रक्रियेने GPU वापरात घेतला आहे. या मार्गदर्शकातील speed numbers तुमच्या मशीनला लागू होत नाहीत.

अपयशाच्या स्थिती आणि तुम्हाला दिसणारे अचूक strings

मॉडेल लोड होत नाही. Ollama दोन्ही आकडे असलेली एक ओळ model requires more system memory (18.6 GiB) than is available (15.2 GiB) या स्वरूपात दाखवते. हे चांगले अपयश आहे, कारण kernel ला निर्णय घेऊ देण्याऐवजी Ollama ने memory allocate करण्यापूर्वी तपासणी केली आहे. context length कमी करा, लहान tag वापरा किंवा मोठ्या plan वर जा.

उत्तराच्या मध्यात process नाहीसा होतो. client कोणतीही उपयुक्त माहिती दाखवत नाही आणि journalctl -u ollama -n 50 मध्ये service पुन्हा सुरू होत असल्याचे दिसते. dmesg -T | tail चालवा. Out of memory: Killed process ... (ollama) असलेली ओळ दिसल्यास kernel OOM killer ने तो process बंद केला आहे. pre-load तपासणी यशस्वी झाली, पण दीर्घ संभाषणादरम्यान cache अंदाजापेक्षा मोठा झाला, तेव्हा असे होते. context length कमी करा.

pull लगेच अपयशी ठरतो. Error: pull model manifest: file does not exist याचा अर्थ हा tag library मध्ये उपलब्ध नाही. qwen3.8:27b टाइप केल्यास हाच परिणाम मिळतो. version number मध्ये केलेल्या कोणत्याही चुकीमुळेही असेच होते. तुमच्या network ला दोष देण्यापूर्वी library page वर tag ची खात्री करा.

सर्व काही चालते, पण वेग असह्यपणे कमी आहे. पुरेशी RAM असलेल्या मशीनवर प्रति सेकंद एक token पेक्षा कमी वेग असल्यास compute ऐवजी paging कडे निर्देश होतो. generate करताना vmstat 1 चालवा. si किंवा so या column पैकी कोणत्याहीमध्ये शून्येतर मूल्य असल्यास kernel swapping करत आहे. यावर उपाय म्हणजे context कमी करणे किंवा कमी models लोड करणे. swap activity नसताना wa सतत जास्त असल्यास memory-mapped weights disk वरून पुन्हा वाचले जात आहेत. याचा अर्थ ते प्रत्यक्षात memory मध्ये बसत नाहीत.

पहिला token येण्यासाठी 30 seconds लागतात आणि त्यानंतर output वेगाने येतो. ही prefill प्रक्रिया आहे आणि ती सामान्य आहे. cache वापरता न येणाऱ्या प्रत्येक request साठी लांब system prompt ची किंमत पुन्हा मोजावी लागते. त्यामुळे इतर कोणतेही tuning करण्यापूर्वी system prompt लहान करा.

CPU-only 27B प्रत्यक्षात कशासाठी उपयुक्त आहे

आशेवर नव्हे, तर आकडेवारीवरून अपेक्षा ठरवा. प्रति सेकंद दोन ते चार tokens या वेगाने 500 tokens चे उत्तर तयार होण्यासाठी दोन ते चार मिनिटे लागतात. Chat साठी हा वेग अनुपयोगी आहे, पण queue साठी पूर्णपणे व्यवहार्य आहे. Document summarisation, मोठ्या प्रमाणावर tagging, अनेक files मधून fields काढणे आणि unattended code review ही कामे हा विलंब सहन करतात, कारण उत्तराची वाट पाहणारा कोणीही नसतो. Coding assistance या मर्यादेवरच येते. त्यामुळे तुम्ही host केलेल्या model कडे coding agent वळवणे commit messages आणि test scaffolding यांसारख्या background jobs साठी फायदेशीर ठरते; पण तुम्ही बसून वाट पाहता त्या inline suggestions साठी नाही.

Privacy हा खरा मुद्दा आहे. Model तुम्ही भाड्याने घेतलेल्या आणि नियंत्रित केलेल्या hardware वर चालतो. कोणतीही request त्या machine बाहेर जात नाही आणि प्रति-token bill नसते. प्रति सेकंद तीन tokens चा वेग असला तरी regulated data साठी हे मोठे फायदे आहेत. मात्र पर्यायाशी प्रामाणिकपणे तुलना करा: frontier-scale model self-host करण्यासाठी hardware ची एक order of magnitude अधिक गरज असते, आणि 27B CPU वर चालवणे ही त्या श्रेणीतील सर्वात स्वस्त पायरी आहे, जिथे output अजूनही वाचण्यासारखा असतो.

हा तुमचा पहिला Ollama install असल्यास, VPS वर Ollama चालवण्याचे संपूर्ण मार्गदर्शन या guide मध्ये गृहीत धरलेल्या service setup, HTTP API आणि firewall rules स्पष्ट करते. Port 11434 इंटरनेटवर expose करू नका. Ollama मध्ये स्वतःचे authentication नसते. त्यामुळे या port पर्यंत पोहोचणारी कोणतीही व्यक्ती तुमचा model वापरू शकते आणि तुमचे prompts वाचू शकते.

FAQ

Ollama वर Qwen 3.8 27B मॉडेल आहे का?

नाही. 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 हे बहुधा 27.8B parameter count version number म्हणून लक्षात राहिल्यामुळे आले आहे. सध्याची यादी पाहण्यासाठी https://ollama.com/library/qwen3.6/tags तपासा. सर्वात नवीन released 27B मॉडेल हवे असल्यास qwen3.6:27b pull करा. अस्तित्वात नसलेला tag वापरल्यास Error: pull model manifest: file does not exist मुळे प्रक्रिया अपयशी ठरते.

VPS वर Qwen 27B मॉडेल चालवण्यासाठी किती 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 मावणारच नाहीत. Swap उपयोगी ठरत नाही, कारण file memory-mapped असते आणि kernel प्रत्येक token वेळी ती disk वरून पुन्हा वाचते. 64 GB मुळे मोठा context किंवा 30 GB आकाराचे Q8_0 weights वापरण्यासाठी पुरेशी जागा मिळते.

CPU वर 27B मॉडेल किती tokens per second देईल?

तुमचा memory bandwidth weights च्या आकाराने भागा. त्यानंतर मिळालेल्या मूल्याच्या 50 ते 70 टक्के इतका वेग अपेक्षित धरा. दोन-channel DDR4-3200 VPS ची कमाल मर्यादा जवळपास 3 tokens per second असते आणि प्रत्यक्ष वेग सुमारे 2 असतो. दोन-channel DDR5-4800 box ची कमाल मर्यादा जवळपास 4.5 असते आणि प्रत्यक्ष वेग सुमारे 3 असतो. अधिक channels असलेले server platforms कागदावर चांगले दिसतात. मात्र host वरील प्रत्येक tenant memory bandwidth सामायिक करतो. त्यामुळे ollama run qwen3.6:27b --verbose वापरून तुमच्या प्रणालीचा वेग मोजा आणि eval rate line वाचा.

CPU-only VPS वर Q4 वापरावे की Q8?

जवळपास प्रत्येक बाबतीत Q4_K_M वापरा. Q8_0 चा आकार 30 GB आहे, तर Q4_K_M चा आकार 17 GB आहे. त्यामुळे Q8_0 साठी 64 GB plan आवश्यक आहे. तसेच प्रत्येक token साठी जवळपास दुप्पट memory हलवावी लागते, त्यामुळे tokens per second साधारण निम्म्यावर येतात. 27B मॉडेलवर बहुतेक कामांसाठी Q4_K_M आणि Q8_0 यांतील quality difference कमी असतो. अधिक RAM लांब context साठी वापरा. त्यामुळे मॉडेलची क्षमता बदलते; ते वाक्यरचना कशी करते हे मात्र बदलत नाही.

मोठ्या RAM VPS पेक्षा GPU भाड्याने घेणे कधी स्वस्त पडते?

तुमचा duty cycle कमी असेल किंवा एखादी व्यक्ती output ची वाट पाहत असेल तेव्हा. 24 GB memory असलेला GPU या weights वर साधारण 59 tokens per second देतो. Typical VPS वर हा वेग 2 किंवा 3 असतो. GPU फक्त तो चालू असलेल्या तासांसाठीच bill होतो. 64 GB VPS वर मॉडेल loaded असो वा नसो, संपूर्ण महिन्याचे billing होते. तुम्ही प्रत्यक्षात दररोज किती तास tokens generate करता हे मोजा. दोन किंवा तीन तासांपेक्षा कमी वापर असल्यास hourly GPU rental सहसा वेग आणि खर्च या दोन्ही बाबतीत फायदेशीर ठरते. सतत चालणारे low-priority batch work असल्यास always-on VPS अधिक फायदेशीर ठरतो.