VPS वर Meta Muse Glimmer 30B कसे चालवावे

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

Muse Glimmer GPU नसलेल्या सामान्य Linux VPS वर चालतो. तुम्ही pull केलेला tag तो memory मध्ये बसेल की नाही हे ठरवतो. Meta Superintelligence Labs ने हे model 10 August 2026 रोजी Apache 2.0 अंतर्गत प्रकाशित केले. यात 30 billion parameters, 128K context window आणि स्वतंत्र 1.8B parameter 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 सूचीबद्ध केले आहेत. त्यामध्ये वेगवेगळ्या numeric precisions मध्ये साठवलेले तेच 30 billion weights आहेत. दिसणारा 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 साठी कोणीही देईल अशा किमतीत मिळणारे बहुतेक rented 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 ला निर्माण होणाऱ्या प्रत्येक token साठी वाचावे लागणारे bytes साधारणपणे दुप्पट होतात. त्यामुळे memory वापर वाढतो आणि throughput कमी होतो. या trade-off चे स्पष्टीकरण 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 वर तो दहापट GB चा download असतो, तो चालवता येत नाही आणि डिस्कवर निष्क्रिय पडून राहतो. Announcement मध्ये दिलेले speed figures Mac वर मोजलेले असतात आणि ते tags शी संबंधित असतात. त्यामुळे ते तुमच्या सर्व्हरची कामगिरी दर्शवत नाहीत. Model page वरील tag list वाचताना प्रथम प्रत्येक mlx नाव वगळा. त्यानंतर उरलेल्या tags नुसार आवश्यक storage size ठरवा.

याला प्रत्यक्षात किती RAM आणि डिस्कची आवश्यकता आहे?

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

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

ollama ps
free -h

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

डिस्क हा तुलनेने सोपा भाग आहे. Linux वर Ollama models /usr/share/ollama/.ollama/models अंतर्गत साठवते. बहुतेक VPS images मध्ये हा root filesystem वर असतो. 40GB root volume मध्ये 57 GB आकाराचा bf16 build बसणार नाही. दोन 8-bit tags शेजारी ठेवणेही शक्य होणार नाही. काहीही 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 ची मालकी असणे आवश्यक आहे, कारण service ollama म्हणून चालते आणि blobs तेथे स्वतःच्या user म्हणून लिहिते. permissions मुळे pull अयशस्वी झाल्यास, कारण journalctl -u ollama -n 50 येथे दिसेल.

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

नावाचा tag निश्चित करून Ollama स्थापित करा

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

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

ollama pull muse-glimmer:30b
ollama list

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

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

तुम्ही GPU शिवाय Muse Glimmer चालवू शकता का?

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

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

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

तुम्हाला 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 चालवणे.

128K tokens पेक्षा खूप आधी हे का विसरते?

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

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

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

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

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

तर्कशक्ती: low, medium, high आणि xhigh

Meta दस्तऐवजांमध्ये Muse Glimmer साठी low ते xhigh अशा चार तर्कशक्ती पातळी दिल्या आहेत. जटिल coding आणि agent कामांसाठी त्यांपैकी उच्च दोन पातळी वापरण्याची शिफारस केली आहे. Ollama मध्ये ही setting 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 च्या दस्तऐवजानुसार, बहुतेक models boolean किंवा low, medium आणि high यांसारखी पातळी स्वीकारतात. काही models सर्वोच्च उपलब्ध पातळीसाठी max स्वीकारतात. हे model नेमके कोणते strings स्वीकारते, हे त्याच्या model page वर दिलेले असते. त्यामुळे अंदाज न लावता तेथे तपासा आणि agent मध्ये वापरण्यापूर्वी एकदा manually वापरून पाहा.

फक्त CPU असलेल्या मशीनवर या setting चा परिणाम स्पष्ट दिसतो. उच्च strength निवडल्यास उत्तरातील पहिला शब्द दिसण्यापूर्वी अधिक thinking tokens तयार केले जातात. Thinking token साठी लागणारा wall clock time हा answer token साठी लागणाऱ्या वेळेइतकाच असतो. नियमित कामासाठी low setting वापरा.

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

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Negative value दिल्यास काहीतरी ते unload करेपर्यंत model memory मध्ये 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 पृष्ठावर समर्थित एजंटला एका command मध्ये local model शी जोडणारा launch shortcut देखील दिला आहे. त्या ठिकाणी tag निश्चित करा.

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

एजंट मोठे prompts पाठवतात. फाइलमधील मजकूर, 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 सार्वजनिक internet वर उपलब्ध होतो. तो शोधणारा कोणीही तुमच्या 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 अपुरी आहे. Kernel ने कोणता process बंद करण्यासाठी out of memory killer वापरला हे dmesg -T मध्ये नोंदले जाते. याच घटनेची service-side नोंद journalctl -u ollama -n 100 मध्ये दिसते. उपाय म्हणजे लहान tag किंवा लहान num_ctx वापरणे. अधिक swap जोडणे हा उपाय नाही.

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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