VPS वर Ollama मध्ये Qwen 27B GPU शिवाय चालवा

VPS वर GPU नसताना Qwen 3.8 27B चालवता येईल का?

Qwen 3.8 27B चालवण्यासाठी प्रथम अस्तित्वात असलेला model tag आवश्यक आहे. 4 August 2026 पर्यंत Ollama library मध्ये qwen3.8 ही नोंदच नाही. उपलब्ध 27B पैकी सर्वात जवळचा tag qwen3.6:27b आहे: 27.8 billion parameters, Q4_K_M quantisation आणि Apache 2.0 licence. खालील प्रत्येक command आणि number Ollama v0.32.5 वरील या tag साठी आहे. ही आवृत्ती 27 July 2026 रोजी प्रकाशित झाली.

थोडक्यात, 32 GB किंवा त्याहून अधिक RAM असलेल्या VPS वर हे शक्य आहे; मात्र ते संथ चालेल. Q4 मधील 27B dense model ला weights साठीच सुमारे 17 GB RAM लागते. Context मधील एकही token साठवण्यापूर्वी ही RAM आवश्यक असते. त्यामुळे 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 चा tag आहे. कोणतीही command copy करण्यापूर्वी live list तपासा: Ollama qwen3.6 tag page. पुढे खरा qwen3.8 release झाला तरी येथील गणित लागू राहील, कारण ते version number वर नव्हे, तर parameter count आणि प्रत्येक weight साठी वापरलेल्या bits वर अवलंबून आहे.

कोणता Ollama tag pull करायचा आणि तो कसा तपासायचा

अस्तित्वात नसलेला tag pull केल्यास स्पष्ट error मिळतो. त्यामुळे ही बाब थेट त्याच मशीनवर लवकर निश्चित करता येते. अस्तित्वात असलेला tag स्थानिक पातळीवर चालवता येईलच असे नाही. library मध्ये सूचीबद्ध असलेला, परंतु Ollama च्या cloud मधूनच serve केला जाणारा GLM 5.2 वापरताना हीच अडचण येते.

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 हे tags देखील आहेत. याशिवाय 35b-a3b tags चा संच आहे. हे MoE (mixture of experts) models आहेत आणि CPU वर त्यांचे वर्तन लक्षणीयरीत्या वेगळे असते. त्याबद्दल खाली अधिक माहिती दिली आहे.

प्रति weight parameter संख्येला 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 * प्रति 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 nominal width वर साठवत नाहीत. Compression मुळे ज्या tensors च्या गुणवत्तेवर सर्वाधिक परिणाम होतो, ते 5 किंवा 6 bits वर ठेवले जातात. Token embedding आणि output layers साधारणपणे Q6_K किंवा Q8_0 वर ठेवले जातात. Format वरील नाव हे सरासरी दर्शवते आणि ती सरासरी जवळपास 4.9 वर येते. Scale च्या दुसऱ्या टोकालाही हाच परिणाम दिसतो: BF16 साठी 56 GB म्हणजे flat 16 ऐवजी 16.1 bits प्रति weight. याचे कारण 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 असलेल्या मशीनवर या दुप्पट आकारामुळे प्रत्येक token साठी memory traffic दुप्पट होतो. त्यामुळे tokens per second देखील साधारण निम्मे होतात. केवळ या कारणासाठी Q4_K_M हा येथे योग्य default आहे. या निर्णयातील memory पेक्षा quality परिणाम समजून घ्यायचे असल्यास, Q4, Q8 आणि fp16 यांची अधिक सविस्तर तुलना output प्रत्यक्षात कुठे खराब होऊ लागतो हे दाखवते.

संदर्भ वाढत असताना 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
  }
]

या आकडेवारीत या आकारमानाच्या अलीकडील dense models मध्ये Qwen ने वापरलेली रचना गृहीत धरली आहे: 64 layers, GQA (grouped-query attention) अंतर्गत 8 key/value heads आणि 128 इतका head dimension. f16 मध्ये प्रत्येक token साठी 256 KiB लागतात. त्यामुळे 32k tokens साठी 8 GB आणि 128k साठी 32 GB लागतात. तुमच्या स्वतःच्या मशीनवरील गणनेपेक्षा ही गणना अंतिम मानू नका. मॉडेल load करा आणि ollama ps मधील SIZE column वाचा. त्यात weights, cache आणि overhead यांची एकत्रित किंमत दाखवली जाते.

म्हणून model card वरील 256K context हा नियोजनापेक्षा एक ठळक वैशिष्ट्य आहे. f16 मध्ये तो पूर्ण भरल्यास weights साठी आधीच 17 GB वापरणाऱ्या मशीनवर weights व्यतिरिक्त cache साठी 64 GB लागतील. Ollama default स्वरूपात पूर्ण window देत नाही. ते त्यापेक्षा खूप छोटी window load करते. OLLAMA_CONTEXT_LENGTH वापरून ती जाणीवपूर्वक वाढवावी लागते. हा server-wide variable एकमेव पर्याय नाही. individual request मध्ये num_ctx सेट केल्यास इतर सर्व विनंत्यांसाठी कमी खर्चाचा default ठेवता येतो आणि एका मोठ्या job ला मोठी window देता येते. ती टप्प्याटप्प्याने वाढवा आणि प्रत्येक बदलानंतर ollama ps तपासा.

दोन settings cache अर्ध्याने किंवा त्याहून अधिक कमी करतात. OLLAMA_KV_CACHE_TYPE=q8_0 cache 16 ऐवजी 8 bits मध्ये साठवते. त्यामुळे 32k tokens साठीचा खर्च 8 GB वरून 4 GB पर्यंत कमी होतो. यासाठी flash attention आवश्यक आहे. म्हणून OLLAMA_FLASH_ATTENTION=1 देखील सेट करा आणि ते लागू झाले असे गृहीत न धरता ollama ps मधील घट तपासा. OLLAMA_NUM_PARALLEL=1 तितकेच महत्त्वाचे आहे. Ollama एकाच वेळी अनेक विनंत्या पूर्ण करू शकते. प्रत्येक 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 करून पुन्हा वाचू लागतो. त्यानंतर प्रत्येक token साठी disk वरून gigabytes वाचावे लागतात. मशीनमध्ये iowait जास्त राहतो आणि प्रति सेकंद एकापेक्षाही कमी token तयार होतो.

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

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

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

Dense model मधून एक token तयार करण्यासाठी प्रत्येक weight मेमरीमधून एकदा वाचावा लागतो. काही weights नव्हे, तर सर्व weights. त्यामुळे वेगाची मर्यादा 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 कधीच पूर्णपणे गाठता येत नाही. दोन-channel DDR4-3200 VPS ची कमाल मर्यादा 3 tokens per second आहे; त्यामुळे साधारण 2 अपेक्षित ठेवा. दोन-channel DDR5-4800 सर्व्हरची कमाल मर्यादा 4.5 आहे; त्यामुळे साधारण 3 अपेक्षित ठेवा.

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

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

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

Dense 27B model खूपच धीमा असल्यास CPU वापरणे सोडण्यापूर्वी qwen3.6:35b-a3b tags तपासा. हे प्रत्येक token साठी सर्व 27.8 billion parameters ऐवजी साधारण 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 समायोजित करून हा फरक भरून काढता येत नाही. त्या card ची memory 1008 GB/s वेगाने चालते, तर तुमचा VPS tens GB/s वेगावर चालतो.

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

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

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

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 ओळीतील 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 ही तुम्हाला आवश्यक असलेली मोजणी आहे. 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 पेक्षा जास्त असतो. Default idle timeout पाच मिनिटे आहे. Items मधील अंतर असलेल्या batch queue मध्ये हा load cost वारंवार लागू होतो. model resident ठेवण्यासाठीचे options प्रति-request keep_alive field आणि reboot नंतरही setting कायम ठेवण्याची पद्धत, दोन्ही समाविष्ट करतात.

Model loaded असताना दुसऱ्या terminal मधून त्याचा memory footprint तपासा.

ollama ps

SIZE column मध्ये KV cache सहित प्रत्यक्ष memory footprint दिसतो. तो weights आणि KV chart मधील तुमच्या context length साठीच्या row यांच्या बेरजेजवळ असला पाहिजे. 8192 tokens आणि 8-bit cache साठी weights व्यतिरिक्त सुमारे एक gigabyte अपेक्षित आहे. Cache f16 राहिला असता हे 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 कडे निर्देश होतो. generation दरम्यान 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 पुन्हा process करावा लागतो. त्यामुळे इतर कोणतेही tuning करण्यापूर्वी system prompt लहान करा.

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

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

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

यापैकी कोणत्याही बाबीचे benchmark करण्यासाठी तुम्हाला वास्तविक structured input आवश्यक आहे. बहुतेक public data APIs मध्ये throughput मोजण्यापूर्वी account आवश्यक असते. Strasmore's demo endpoint (हे आम्ही चालवतो) 22 वर्षांच्या US market data वर read-only SQL चे उत्तर देते. यासाठी key किंवा signup आवश्यक नाही. https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 कडे GET केल्यावर JSON मिळतो, जो तुम्ही थेट prompt loop मध्ये pipe करू शकता. त्यासोबत तो JSON तयार करणारा अचूक SQL देखील मिळतो. त्यामुळे model कडे summarise करण्यासाठी असा data असतो, जो तुम्ही स्वतंत्रपणे तपासू शकता. प्रत्येक call साठी मर्यादा 500 rows आणि 20 seconds इतकी आहे. दोन tokens प्रति सेकंद वेगाच्या मशीनला हे सहज पुरेसे आहे. पूर्ण column list https://api.strasmore.com/v1/schema येथे आहे.

जर हा तुमचा पहिला Ollama install असेल, तर VPS वर Ollama चालवण्याचे संपूर्ण walkthrough या मार्गदर्शकात गृहीत धरलेली service setup, HTTP API आणि firewall rules यांची माहिती देते. Port 11434 इंटरनेटवर 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 parameter 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 model हवा असल्यास qwen3.6:27b pull करा. अस्तित्वात नसलेला tag वापरल्यास Error: pull model manifest: file does not exist error येतो.

VPS वर Qwen 27B model चालवण्यासाठी किती 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 model मला प्रति सेकंद किती tokens देईल?

तुमचा 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 share होत असल्यामुळे, ollama run qwen3.6:27b --verbose वापरून तुमच्या system वर मोजमाप करा आणि 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 model मध्ये Q4_K_M आणि Q8_0 यांमधील quality difference बहुतेक tasks साठी कमी आहे. RAM अधिक मोठ्या context साठी वापरा. त्यामुळे model काय करू शकते यात बदल होतो; ते गोष्टी कशा मांडते यात नाही.

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

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