VPS वर Meta Muse Glimmer 30B चालवण्यासाठी RAM व डिस्क

VPS वर Muse Glimmer साठी आवश्यक बाबी

Muse Glimmer GPU नसलेल्या सामान्य Linux VPS वर चालतो. मात्र कोणता tag pull करता त्यावर तो उपलब्ध memory मध्ये बसेल की नाही हे ठरते. Meta Superintelligence Labs ने हे model 10 August 2026 रोजी Apache 2.0 परवान्याखाली प्रकाशित केले. यात 30 billion parameters, 128K context window आणि 1.8B parameters असलेला स्वतंत्र perception encoder आहे. त्यामुळे ते text सोबत images देखील वाचू शकते. Meta ने हे chat साठी नव्हे, तर नेहमी सुरू असलेल्या local agents साठी तयार केले आहे. प्रत्येक request साठी reasoning strength निश्चित करता येते.

16 August 2026 रोजी पाहिलेल्या प्रकाशित Ollama tags चा आकार 17 GB ते 59 GB इतका आहे. संपूर्ण sizing problem या range वर अवलंबून आहे. Default tag चा आकार सुमारे 18 GB असा दिला आहे. त्यामुळे व्यवहार्य किमान VPS मध्ये 18 GB पेक्षा स्पष्टपणे अधिक free RAM असणे आवश्यक आहे. Download साठी लागणारी disk space आणि context window साठी लागणारी memory याव्यतिरिक्त आवश्यक असतात.

तुम्ही कोणता muse-glimmer tag pull करावा?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama ने या model साठी Apple builds नसलेले 11 tags सूचीबद्ध केले आहेत. त्यामध्ये समान 30 billion weights वेगवेगळ्या numeric precisions मध्ये साठवलेले आहेत. दिसणारा size म्हणजे तुम्ही download करणार असलेला size आहे. Context जोडण्यापूर्वी memory मध्ये साधारणपणे तेवढीच जागा आवश्यक असते.

दोन 4-bit builds लहान आहेत: 30b-nvfp4, 17 GB, आणि 30b-q4_K_M, 18 GB. Default 30b tag ची नोंद q4_K_M build इतक्याच size ने केली आहे. 8-bit builds, 30b-q8_0 आणि 30b-mxfp8, सुमारे 31 GB आहेत. 30b-bf16 हा 57 GB आकाराचा unquantised 16-bit release आहे. Side project साठी कोणी देईल अशा किमतीत भाड्याने मिळणाऱ्या बहुतेक servers पेक्षा यासाठी अधिक RAM लागते.

-dflash tags हे DFlash support असलेले त्याच builds आहेत. प्रत्येकाची नोंद त्याच्या plain twin पेक्षा मोठ्या size ने केली आहे. Ollama DFlash चे वर्णन speed feature म्हणून करते आणि ते Apple Silicon तसेच desktop GPUs वर दाखवते. केवळ CPU असलेल्या VPS वर इतर hardware वर मोजलेल्या feature साठी ती अतिरिक्त size प्रत्यक्ष memory मध्ये द्यावी लागेल. त्यामुळे plain tag पासून सुरुवात करा आणि एका वेळी एकच बदल करा.

तुमच्याकडे तसे न करण्याचे विशिष्ट कारण नसल्यास 4-bit पासून सुरुवात करा. 4-bit वरून 8-bit कडे गेल्यास CPU ला प्रत्येक generated token साठी वाचावे लागणारे bytes साधारणपणे दुप्पट होतात. त्यामुळे memory वापर वाढतो आणि throughput कमी होतो. हा trade q4, q8 आणि fp16 quantisation ची प्रत्यक्ष किंमत याचा विषय आहे. CPU box वर थोडक्यात सांगायचे तर 4-bit build पासून सुरुवात करणेच योग्य आहे.

Linux सर्व्हरवर MLX tags काहीही का करत नाहीत

MLX हे Apple चे array framework आहे आणि Ollama चे MLX engine हे Apple Silicon साठीचे backend आहे. नावात mlx असलेला प्रत्येक tag त्या engine आणि त्या hardware साठी तयार केलेला असतो. x86 Linux VPS वर तो अनेक gigabytes इतका download असतो, पण तुम्ही तो चालवू शकत नाही. त्यामुळे तो disk वर पडून राहतो आणि काहीही करत नाही. Mac वर मोजलेले announcement मधील speed figures त्या tags साठी लागू असतात. त्यामुळे ते तुमच्या सर्व्हरसाठी लागू होत नाहीत. Model page वरील tag list पाहताना प्रथम प्रत्येक mlx नाव वगळा. त्यानंतर उरलेल्या tags वरून size निवडा.

खरोखर किती RAM आणि disk आवश्यक आहे?

Memory वापरणाऱ्या दोन गोष्टी आहेत आणि त्यापैकी फक्त एक tag च्या size वर अवलंबून असते. तुम्ही pull केलेल्या tag नुसार weights निश्चित असतात. KV cache म्हणजे model conversation साठी ठेवत असलेली प्रति-token state. तुम्ही configure केलेल्या context length नुसार ती वाढते. Ollama च्या documentation नुसार parallel requests serve केल्यास context ची गरज in-flight requests च्या संख्येने वाढते. त्यामुळे एकाच वेळी दोन agents ना उत्तर देणाऱ्या box ला एकाच agent ला उत्तर देणाऱ्या box पेक्षा अधिक memory आवश्यक असते.

कोणत्याही guide मधील RAM ची आकडेवारी गृहीत धरू नका, या guide मधीलही नाही. Tag pull करा, त्याला एक prompt पाठवा आणि model अजून resident असताना हे दोन commands चालवा.

ollama ps
free -h

ollama ps सध्या काय loaded आहे आणि काम CPU व GPU मध्ये कसे विभागले आहे ते दाखवते. free -h मध्ये किती memory शिल्लक आहे ते दिसते. तुमच्या स्वतःच्या box वरील हे दोन outputs कोणत्याही published table पेक्षा अधिक अचूक आहेत, कारण त्यात तुमची context setting, तुमचे quantisation आणि server चालवत असलेली इतर सर्व कामे आधीच समाविष्ट असतात.

Disk हा तुलनेने सोपा भाग आहे. Linux वर Ollama models /usr/share/ollama/.ollama/models अंतर्गत साठवते. बहुतेक VPS images मध्ये हा root filesystem वर असतो. 57 GB चा bf16 build 40GB root volume मध्ये बसणार नाही. दोन 8-bit tags देखील एकाच वेळी ठेवता येणार नाहीत. Pull केल्यावर प्रत्यक्षात कोणत्या files लिहिल्या जातात हे तुम्ही कधी पाहिले नसेल, तर Ollama models कुठे साठवते आणि ते कसे हलवायचे या directory ची प्रक्रिया समजावते. काहीही pull करण्यापूर्वी store mounted volume वर हलवा.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

ollama user कडे त्या directory ची ownership असणे आवश्यक आहे, कारण service ollama म्हणून चालते आणि blobs तिथे त्याच user म्हणून लिहिते. Pull permissions मुळे fail झाल्यास, कारण journalctl -u ollama -n 50 मध्ये दिसते.

Swap बाबत एक स्पष्ट मुद्दा लक्षात ठेवा: swap मुळे मोठा tag चालवता येत नाही. Generation दरम्यान model तयार करत असलेल्या प्रत्येक token साठी weights वाचावे लागतात. त्यामुळे swap मध्ये असलेले weights वारंवार disk वरून read back केले जातात, vmstat 1 मध्ये si आणि so columns सतत busy दिसतात आणि output चा वेग seconds per token इतका कमी होतो. out of memory killer पासून संरक्षणासाठी लहान swap file ठेवा. तुम्हाला प्रत्यक्षात हवा असलेल्या tag नुसार RAM चे sizing करा.

Ollama स्थापित करा आणि नामांकित tag निश्चित करा

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

Install script systemd service सेट करते, त्यामुळे reboot नंतर server पुन्हा सुरू होते. root द्वारे व्यवस्थापित system service म्हणून ते चालवायचे नसल्यास, Podman अंतर्गत Ollama rootless चालवणे हा पर्याय समाविष्ट आहे. त्यानंतर स्पष्ट tag pull करा.

ollama pull muse-glimmer:30b
ollama list

ollama list मधील size column स्वतः वाचा आणि model page वरील सध्याच्या tag list शी त्याची तुलना करा. Published tags जोडले, rename आणि remove केले जातात; तसेच guide मधील size हा एका दिवसाचा snapshot असतो.

तुम्ही अवलंबून असलेल्या server वर ollama pull muse-glimmer कधीही लिहू नका. रिकामे model name latest tag कडे resolve होते आणि latest हा publisher वेगळ्या build कडे हलवू शकणारा pointer आहे. त्यानंतर routine pull तुमच्या agent खालील model बदलतो. त्याच्या memory requirements आणि behaviour मध्ये बदल होऊ शकतो, आणि तुमच्या logs मध्ये याची कोणतीही सूचना दिसत नाही. तुमच्या scripts, unit files आणि agent config मध्ये tag स्पष्टपणे लिहा. VPS वर Ollama वापरून LLM self-host करणे उर्वरित server setup स्पष्ट करते.

GPU शिवाय Muse Glimmer चालवता येते का?

होय. मात्र त्याची कमाल मर्यादा स्पष्टपणे समजून घ्या. एक token तयार करण्यासाठी model weights memory मधून वाचावे लागतात. त्यामुळे वेग हा plan मध्ये नमूद केलेल्या vCPU च्या संख्येपेक्षा memory bandwidth वर अधिक अवलंबून असतो. काही cores पेक्षा जास्त cores दिल्यानंतर वेगात फारशी वाढ होत नाही. Shared VPS वर ही bandwidth host वरील इतर सर्व tenants सोबत सामायिक केली जाते. त्यामुळे 4-bit मधील 30B model दर सेकंदाला मोजकेच tokens तयार करतो.

याबाबत कोणाच्याही आकड्यांवर, माझ्या आकड्यांवरही, अवलंबून राहू नका. तुमच्या स्वतःच्या box वर दर सेकंदाला तयार होणारे tokens मोजा आणि प्रत्यक्ष मोजमापावरून निर्णय घ्या.

यामुळे model कशासाठी उपयुक्त आहे यात स्पष्ट फरक दिसतो. Interactive chat त्रासदायक ठरते, कारण server लिहितो त्यापेक्षा तुम्ही वेगाने वाचता आणि प्रत्येक उत्तर सुरू होण्यापूर्वी मोठा विलंब होतो. Background agent work योग्य ठरते, कारण दहा मिनिटे unattended चालणाऱ्या task साठी वेग कमी असणे महत्त्वाचे नसते. Meta ने या model साठी वर्णन केलेले कामाचे स्वरूप नेमके हेच आहे.

तुम्हाला interactive speed हवी असल्यास, दोन प्रामाणिक पर्याय आहेत: GPU किंवा hosted API. काहीही rent करण्यापूर्वी GPU VPS आणि API tokens यांच्यातील break-even point ठरवा, आणि GPU VPS प्रत्यक्षात काय देते यात तुम्ही नेमके काय खरेदी करत आहात हे स्पष्ट केले आहे. एखाद्या box मध्ये कोणते models ठेवता येतील या व्यापक प्रश्नासाठी तुम्ही कोणते models self-host करू शकता येथून सुरुवात करा. या size class मधील सर्वात जवळची तुलना VPS वर समान आकाराचे Qwen model चालवणे ही आहे. तुम्ही मोजलेले आकडे वापरण्यासाठी खूप कमी वेग दाखवत असल्यास, VPS वर Nemotron 3.5 Lightning आकारापेक्षा वेगासाठी तयार केलेल्या model बाबत RAM आणि दर सेकंदाला तयार होणाऱ्या tokens चे तेच प्रश्न तपासते.

128K tokens येण्यापूर्वीच ते गोष्टी का विसरते?

Ollama ची default context window 4096 tokens आहे; model कितीही tokens समर्थित करत असला तरी हेच लागू होते. August 2026 पर्यंत ही default value Ollama च्या स्वतःच्या FAQ मध्ये नमूद आहे. Tag मध्ये 128K असल्याचे दर्शवले जाते, परंतु तुम्ही वेगळे सांगितल्याशिवाय server model ला 4096 tokens देतो. त्यामुळे दीर्घ agent transcript मधील सुरुवातीचे turns गमावले जातात आणि model ला amnesia असल्यासारखे दिसते.

प्रत्येक request साठी server वर ही value वाढवा:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Interactive session मध्ये /set parameter num_ctx 32768 केल्यास ती value फक्त त्या session साठी बदलते. API वापरताना request options मध्ये num_ctx पाठवा.

Context मधील प्रत्येक अतिरिक्त token साठी weights व्यतिरिक्त memory लागते. फक्त weights साठी पुरेसा असलेल्या server वर पूर्ण 128K मागितल्यास load अयशस्वी होऊ शकतो किंवा अधिक धीम्या पर्यायावर fallback होऊ शकतो. ही value टप्प्याटप्प्याने वाढवा आणि प्रत्येक टप्प्यानंतर ollama ps चालवा. Ollama मध्ये num_ctx आणि context length कसे कार्य करतात यामध्ये हे गणित सविस्तर दिले आहे.

तर्काची तीव्रता: low, medium, high आणि xhigh

Meta कागदपत्रांमध्ये Muse Glimmer साठी low ते xhigh अशा चार reasoning strengths दिल्या आहेत. जटिल coding आणि agent tasks साठी त्यांपैकी higher two वापरण्याची शिफारस केली आहे. Ollama मध्ये हे think parameter द्वारे नियंत्रित होते. Command line वर --think= वापरा किंवा API body मध्ये think पाठवा.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

Interactive session मध्ये /set think आणि /set nothink वापरून ही setting बदलता येते. Ollama च्या documentation नुसार बहुतेक models boolean किंवा low, medium आणि high यांसारखी level values स्वीकारतात. काही models सर्वाधिक उपलब्ध स्तरासाठी max स्वीकारतात. या model ला कोणते exact strings स्वीकार्य आहेत, हे त्याच्या model page वर दिलेले असते. त्यामुळे अंदाज न बांधता तेथे तपासा आणि agent मध्ये वापरण्यापूर्वी एक value manually वापरून पाहा.

फक्त CPU असलेल्या संगणकावर या setting चा मोठा परिणाम होतो. जास्त strength निवडल्यास उत्तराचा पहिला शब्द दिसण्यापूर्वी अधिक thinking tokens तयार होतात. Thinking token साठी लागणारा wall-clock time उत्तराच्या token इतकाच असतो. नियमित कामासाठी low setting ठेवा. उत्तराची लांबीही तितक्याच काळजीपूर्वक नियंत्रित करा. त्यामुळे एक लांबलचक response slow box ला अनेक मिनिटे व्यस्त ठेवण्याऐवजी num_predict वापरून reply ची कमाल लांबी ठरवा.

नेहमी सुरू असलेल्या agent साठी model loaded ठेवा

Ollama idle model डीफॉल्टनुसार पाच मिनिटांनंतर unload करते. दर दहा मिनिटांनी चालणाऱ्या agent साठी याचा अर्थ प्रत्येक run वेळी disk वरून पूर्ण 18 GB load करणे असा होतो. Network-attached storage असलेल्या VPS वर हे load पटकन होत नाही. त्याऐवजी ते memory मध्ये pin करा.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Negative value दिल्यास कोणीतरी model unload करेपर्यंत तो resident राहतो. API request मधील keep_alive त्या एका call साठी server default override करते. याची किंमत स्पष्ट आहे: काहीही सुरू नसतानाही RAM व्यापलेली राहते. त्यामुळे ही setting agent साठी समर्पित केलेल्या box साठी योग्य आहे. Ollama model loaded ठेवणे यातील विविध पर्याय स्पष्ट करते.

कोडिंग एजंटकडे निर्देश करा

Ollama http://127.0.0.1:11434/v1 येथे OpenAI-सुसंगत API उपलब्ध करून देते. त्यामुळे बहुतेक एजंट साधने base URL आणि रिकामी नसलेली कोणतीही API key वापरून जोडली जातात. Ollama च्या Muse Glimmer पृष्ठावर समर्थित एजंटला स्थानिक model शी एका command मधून जोडण्यासाठी launch shortcut देखील दिलेला आहे. तेथे tag देखील निश्चित करा.

ollama launch claude --model muse-glimmer:30b

एजंट मोठे prompts पाठवतात. File contents, tool output आणि वाढत जाणारा transcript हे सर्व input tokens म्हणून येतात. CPU box वर generation सुरू होण्यापूर्वी prompt processing मुळेच सर्वाधिक विलंब होतो. कार्यासाठी शक्य तितकी लहान context setting ठेवा. कोडिंग एजंटला Ollama कडे निर्देश करणे client side समजावते, VPS वर कोडिंग एजंट चालवणे तो ज्या box वर चालतो त्याबद्दल सांगते, आणि VPS वरील एजंटचा खर्च नियंत्रित करणे तो दिवसभर चालू ठेवल्यावर काय होते ते स्पष्ट करते.

Image input देखील याच प्रकारे कार्य करते. Ollama API संदेशाच्या images field मध्ये images स्वीकारते. त्यामुळे perception encoder कितीही सक्षम असला तरी text-only client image कधीही पाठवणार नाही.

11434 पोर्ट उघडू नका

Ollama API मध्ये authentication नाही. तुमच्या laptop वरून त्याला पोहोचता यावे म्हणून OLLAMA_HOST=0.0.0.0:11434 सेट केल्यास authentication नसलेला model runner सार्वजनिक इंटरनेटवर उपलब्ध होतो. तो सापडल्यास कोणतीही व्यक्ती तुमच्या disk वर models load करू शकते आणि तुमचा agent त्यामधून पाठवतो ते सर्व वाचू शकते. तो localhost वरच bind ठेवा आणि त्याऐवजी tunnel वापरा.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Ollama API endpoint सुरक्षित करणे मध्ये योग्य पर्याय दिले आहेत. त्यामध्ये credentials विचारणारा reverse proxy देखील समाविष्ट आहे.

काय बिघडते आणि तुम्हाला काय दिसेल

Pull प्रक्रियेचे काम मध्येच थांबते. डिस्कची जागा अपुरी आहे. Model directory वर df -h चालवा. 57 GB bf16 build 40GB root volume मध्ये बसत नाही. दोन 8-bit tags एकाच वेळी ठेवताही येत नाहीत.

Model load होते आणि त्यानंतर process बंद पडतो. Memory अपुरी आहे. dmesg -T मध्ये kernel out of memory killer ने process निवडल्याची नोंद होते. journalctl -u ollama -n 100 मध्ये याच घटनेची service-side नोंद दिसते. यावरील उपाय म्हणजे smaller tag किंवा smaller num_ctx वापरणे. अधिक swap देणे हा उपाय नाही.

Process चालतो, परंतु प्रत्येक token साठी अनेक seconds लागतात. vmstat 1 चालवा आणि si व so columns वर लक्ष ठेवा. सतत swap activity दिसत असल्यास weights RAM मध्ये बसत नाहीत. Process चालू असताना system ती disk वरून पुन्हा वाचत असते.

गेल्या आठवड्यात चाललेला tag आता उपलब्ध नाही. Tag lists बदलतात. Model page पुन्हा तपासा, सध्या उपलब्ध tag pin करा आणि tag name पुन्हा पाहता येईल अशा ठिकाणी नोंदवा.

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

Muse Glimmer ला VPS वर किती RAM आवश्यक आहे?

Tag च्या आकारापासून सुरुवात करा आणि त्यात context window जोडा. 16 August 2026 रोजी default tag चा आकार सुमारे 18 GB असल्याचे नमूद आहे. त्यामुळे 16GB मशीनवर तो अजिबात बसत नाही आणि 24GB मशीनवर तो context साठी फारच कमी जागा शिल्लक ठेवून बसतो. हा फक्त प्रारंभबिंदू आहे; अंतिम उत्तर नाही. Tag pull करा, तो एकदा load करा, त्यानंतर आपल्या मशीनवर ollama ps आणि free -h चालवून प्रत्यक्ष आकडे तपासा. अधिक मोठा context आणि समांतर requests यांमुळे weights व्यतिरिक्त आणखी memory लागते.

GPU शिवाय Muse Glimmer चालवता येतो का?

होय. तो केवळ CPU असलेल्या VPS वर load होऊन उत्तर देतो. Generation speed ही core count पेक्षा memory bandwidth मुळे अधिक मर्यादित असते. Shared host वर ही bandwidth इतर workload सोबत वाटली जाते. त्यामुळे 4-bit मध्ये प्रति सेकंद कमी tokens मिळण्याची अपेक्षा ठेवा. unattended पद्धतीने चालणाऱ्या background agent कामासाठी हे वापरण्यायोग्य आहे; interactive chat साठी मात्र अनुभव त्रासदायक असेल. Request चालू असताना ollama ps चालवा आणि काम कुठे चालू आहे हे निश्चित करण्यासाठी processor column तपासा.

Linux VPS वर MLX tags काही उपयोगी आहेत का?

नाही. नावात mlx असलेला प्रत्येक tag Ollama च्या MLX engine साठी तयार केलेला असतो. हे Apple Silicon चे backend आहे. x86 Linux server वर हे tags मोठे download ठरतात आणि चालवता येत नाहीत. साधा 30b tag किंवा इतर non-MLX tags वापरा. MLX builds सोबत दिलेले Apple hardware benchmarks दुर्लक्षित करा.

128K tokens च्या खूप आधी model गोष्टी का विसरतो?

Ollama ची default context window model किती tokens समर्थित करतो याची पर्वा न करता 4096 tokens असते. त्यामुळे model ला ती दिसण्यापूर्वीच server मोठ्या conversations मधील सुरुवातीचा भाग कापतो. Server वर OLLAMA_CONTEXT_LENGTH सेट करा, किंवा एका session साठी /set parameter num_ctx वापरा, किंवा API request options मध्ये num_ctx पाठवा. यामुळे memory वापर वाढतो. म्हणून हे टप्प्याटप्प्याने वाढवा आणि प्रत्येक वेळी ollama ps तपासा.

Tag pin करावा का, की फक्त latest वापरावे?

Tag pin करा. कोणताही tag न देता muse-glimmer वापरल्यास ते latest कडे resolve होते. हा असा pointer आहे, जो publisher कधीही वेगळ्या build कडे हलवू शकतो. त्यामुळे routine pull मुळे तुमचा agent चालवत असलेला model बदलू शकतो. Scripts, unit files आणि agent config मध्ये muse-glimmer:30b लिहा. Pin करण्यापूर्वी model page वरील tag list तपासा, कारण published tags बदलू शकतात.