VPS पर Meta Muse Glimmer 30B कैसे चलाएं

VPS पर Muse Glimmer के लिए आवश्यक संसाधन

Muse Glimmer बिना GPU वाले सामान्य Linux VPS पर चलता है। आप कौन सा tag pull करते हैं, यह तय करता है कि वह memory में फिट होगा या नहीं। Meta Superintelligence Labs ने 10 August 2026 को Apache 2.0 लाइसेंस के तहत यह model जारी किया था: इसमें 30 billion parameters, 128K context window और 1.8B parameter का एक समर्पित perception encoder है, ताकि यह text के साथ-साथ images को भी पढ़ सके। Meta इसे chat के बजाय 'always on local agents' के लिए लक्षित करता है, जिसमें reasoning strength को आप प्रत्येक request के अनुसार सेट कर सकते हैं।

16 August 2026 को देखे गए प्रकाशित Ollama tags का आकार 17 GB से लेकर 59 GB तक है। यह रेंज ही पूरी sizing समस्या का आधार है। डिफ़ॉल्ट tag लगभग 18 GB का है, इसलिए सबसे छोटे उपयुक्त सर्वर में स्पष्ट रूप से 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 के लिए 11 tags सूचीबद्ध किए हैं जो Apple builds नहीं हैं। इनमें समान 30 billion weights अलग-अलग numeric precisions पर संग्रहीत हैं। जो size आप देखते हैं, वही आपको download करना होता है, और किसी भी context को जोड़ने से पहले आपको लगभग इतनी ही memory की आवश्यकता होती है।

दो 4-bit builds छोटे हैं: 17 GB पर 30b-nvfp4 और 18 GB पर 30b-q4_K_M। डिफ़ॉल्ट 30b tag को q4_K_M build के समान size पर सूचीबद्ध किया गया है। 8-bit builds, 30b-q8_0 और 30b-mxfp8, 31 GB के आसपास हैं। 30b-bf16 unquantised 16-bit release है जो 57 GB की है, जिसके लिए अधिकांश किराए के servers द्वारा प्रदान की जाने वाली RAM से अधिक की आवश्यकता होती है, और इसकी कीमत किसी भी side project के लिए बहुत अधिक है।

-dflash tags DFlash support वाले समान builds हैं, और प्रत्येक को उसके साधारण twin से बड़ा सूचीबद्ध किया गया है। Ollama, DFlash को एक speed feature के रूप में वर्णित करता है और इसे Apple Silicon तथा desktop GPUs पर प्रदर्शित करता है। केवल CPU वाले VPS पर आप अन्य hardware पर मापी गई सुविधा के लिए वास्तविक memory में वह अतिरिक्त size खर्च कर रहे होंगे, इसलिए साधारण tag से शुरुआत करें और एक बार में एक ही बदलाव करें।

जब तक आपके पास ऐसा न करने का कोई विशिष्ट कारण न हो, 4-bit से शुरुआत करें। 4-bit से 8-bit पर जाने से CPU को प्रत्येक token generate करने के लिए पढ़े जाने वाले bytes लगभग दोगुने हो जाते हैं, जिससे throughput कम हो जाता है और memory का उपयोग बढ़ जाता है। यह trade-off q4, q8 और fp16 quantisation की वास्तविक लागत क्या है का विषय है, और CPU box पर संक्षिप्त उत्तर यह है कि 4-bit build ही एकमात्र ऐसा build है जिससे शुरुआत करना उचित है।

Linux सर्वर पर MLX टैग्स काम क्यों नहीं करते हैं

MLX, Apple का array framework है और Ollama का MLX engine विशेष रूप से Apple Silicon के लिए बनाया गया backend है। जिस भी टैग के नाम में mlx होता है, वह केवल उसी hardware और engine के लिए बनाया गया है। x86 Linux VPS पर इसे डाउनलोड करने का अर्थ है कई gigabytes का ऐसा डेटा डाउनलोड करना जिसे आप चला ही नहीं सकते, और यह केवल आपकी disk पर जगह घेरेगा। घोषणा में दिए गए गति के आंकड़े (speed figures) Mac पर मापे गए थे और वे उन्हीं टैग्स के लिए हैं, इसलिए वे आपके सर्वर की क्षमता को नहीं दर्शाते। जब आप model page पर टैग सूची देखें, तो सबसे पहले सभी mlx नामों को हटा दें, और उसके बाद बचे हुए विकल्पों में से आकार (size) के आधार पर चुनाव करें।

इसे वास्तव में कितनी RAM और डिस्क की आवश्यकता है?

दो चीजें मेमोरी का उपयोग करती हैं, और उनमें से केवल एक tag का आकार है। weights उस tag द्वारा निर्धारित होते हैं जिसे आप pull करते हैं। KV cache, जो कि conversation के लिए model द्वारा रखा गया प्रति-token state है, आपके द्वारा कॉन्फ़िगर की गई context length के साथ बढ़ता है। Ollama का अपना documentation बताता है कि parallel requests को serve करने से context, flight में मौजूद requests की संख्या से गुणा हो जाता है। इसलिए, एक ही समय में दो agents को जवाब देने वाले सर्वर को एक agent को जवाब देने वाले सर्वर की तुलना में अधिक मेमोरी की आवश्यकता होती है।

किसी भी गाइड से RAM का आंकड़ा न लें, जिसमें यह गाइड भी शामिल है। tag को pull करें, उसे एक prompt भेजें, और जब model अभी भी memory में हो, तो ये दो commands चलाएँ।

ollama ps
free -h

ollama ps दिखाता है कि अभी क्या load है और काम CPU और GPU के बीच कैसे विभाजित है। free -h दिखाता है कि क्या बचा है। आपके अपने सर्वर पर ये दो outputs किसी भी प्रकाशित तालिका से बेहतर हैं, क्योंकि इनमें पहले से ही आपकी context setting, आपकी quantisation और सर्वर पर चल रही बाकी सभी चीजें शामिल हैं।

डिस्क का हिस्सा आसान है। Ollama models को Linux पर /usr/share/ollama/.ollama/models के अंतर्गत store करता है, जो अधिकांश VPS images पर root filesystem पर स्थित होता है। 40GB का root volume 57 GB वाले bf16 build को नहीं रख पाएगा, और यह दो 8-bit tags को भी साथ-साथ नहीं रख पाएगा। यदि आपने कभी यह नहीं देखा है कि pull वास्तव में क्या लिखता है, तो Ollama models को कहाँ store करता है और उन्हें कैसे move करें उस directory के बारे में विस्तार से बताता है। कुछ भी pull करने से पहले store को एक mounted volume पर move करें।

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 को वहीं लिखती है। यदि permissions के कारण pull विफल हो जाता है, तो journalctl -u ollama -n 50 में कारण दिखाई देता है।

Swap के बारे में एक स्पष्ट बात: swap आपको बड़ा tag चलाने की अनुमति नहीं देता है। generation हर उस token के लिए weights को touch करता है जिसे वह produce करता है, इसलिए swap में रहने वाले weights को बार-बार disk से पढ़ा जाता है। vmstat 1 में si और so columns व्यस्त दिखाई देते हैं, और output की गति प्रति token कई seconds तक धीमी हो जाती है। out of memory killer से सुरक्षा के लिए एक छोटी swap file रखें। RAM का आकार उस tag के लिए रखें जिसे आप वास्तव में चलाना चाहते हैं।

Ollama इंस्टॉल करें और एक named tag पिन करें

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

Install script एक systemd service सेटअप करता है, जिससे reboot के बाद सर्वर अपने आप चालू हो जाता है। यदि आप इसे root द्वारा प्रबंधित system service के रूप में नहीं चलाना चाहते हैं, तो Podman के अंतर्गत Ollama को rootless चलाना उस विकल्प को कवर करता है। इसके बाद एक स्पष्ट tag pull करें।

ollama pull muse-glimmer:30b
ollama list

ollama list में size कॉलम को स्वयं पढ़ें और model page पर वर्तमान tag सूची के साथ इसकी तुलना करें। प्रकाशित tags जोड़े, नाम बदले और हटाए जाते हैं, और गाइड में दी गई size केवल एक दिन का snapshot होती है।

जिस सर्वर पर आप निर्भर हैं, उस पर कभी भी ollama pull muse-glimmer न लिखें। एक bare model name, latest tag को resolve करता है, और latest एक ऐसा pointer है जिसे publisher किसी अलग build पर ले जा सकता है। एक routine pull आपके agent के नीचे model को बदल देता है, जिसकी memory आवश्यकताएं और व्यवहार अलग हो सकते हैं, और आपके logs में इसकी कोई सूचना नहीं मिलती है। अपने scripts, unit files और agent config में tag लिखें। Ollama के साथ VPS पर LLM को self-host करना सर्वर सेटअप के बाकी हिस्सों को कवर करता है।

क्या आप बिना GPU के Muse Glimmer चला सकते हैं?

हाँ, और इसकी सीमाओं के बारे में स्पष्ट रहना उचित है। एक token generate करने का अर्थ है memory से model weights को पढ़ना, इसलिए गति vCPUs की संख्या के बजाय memory bandwidth द्वारा निर्धारित होती है। कुछ cores के बाद, अधिक cores से बहुत कम लाभ मिलता है। एक shared VPS पर वह bandwidth host के अन्य सभी tenants के साथ साझा की जाती है, इसलिए 4-bit पर 30B model प्रति सेकंड बहुत कम tokens उत्पन्न करता है।

इसके लिए किसी और के आंकड़ों पर भरोसा न करें, मेरे आंकड़ों पर भी नहीं। अपने सिस्टम पर tokens प्रति सेकंड मापें और जो आप देखते हैं उसके आधार पर निर्णय लें।

परिणाम यह है कि model किस काम के लिए उपयुक्त है, इसमें स्पष्ट अंतर है। Interactive chat कष्टदायक है, क्योंकि आप सर्वर की लिखने की गति से तेज पढ़ते हैं और हर उत्तर एक लंबे विराम के साथ शुरू होता है। Background agent का काम ठीक रहता है, क्योंकि जो कार्य दस मिनट तक बिना निगरानी के चलता है, उसे इस बात से फर्क नहीं पड़ता कि वह धीमा है। वह दूसरा workload वही है जिसका वर्णन Meta ने इस model के लिए किया है।

यदि आपको interactive गति चाहिए, तो दो ईमानदार उत्तर हैं: एक GPU या एक hosted API। कुछ भी किराए पर लेने से पहले GPU VPS और API tokens के बीच break even point का हिसाब लगाएँ, और एक GPU VPS वास्तव में आपको क्या देता है यह बताता है कि आप क्या खरीद रहे हैं। इस व्यापक प्रश्न के लिए कि एक निश्चित सिस्टम क्या संभाल सकता है, आप कौन से models self-host कर सकते हैं से शुरुआत करें, और VPS पर समान आकार का Qwen model चलाना इस आकार वर्ग में सबसे सटीक तुलना है। यदि आपके द्वारा मापे गए आंकड़े इतने धीमे हैं कि आप उनके साथ काम नहीं कर सकते, तो VPS पर Nemotron 3.5 Lightning उन models के लिए समान RAM और tokens प्रति सेकंड के प्रश्न उठाता है जिन्हें आकार के बजाय गति के लिए बनाया गया है।

यह 128K tokens से काफी पहले ही चीजें क्यों भूल जाता है?

इसका कारण यह है कि Ollama की डिफ़ॉल्ट context window 4096 tokens की है, चाहे मॉडल कितना भी सपोर्ट क्यों न करता हो। अगस्त 2026 तक, यह डिफ़ॉल्ट मान Ollama के अपने FAQ में दिया गया है। टैग 128K का विज्ञापन करता है, लेकिन जब तक आप निर्देश न दें, सर्वर मॉडल को केवल 4096 tokens ही देता है। इस वजह से, एक लंबी एजेंट ट्रांसक्रिप्ट अपनी शुरुआती बातें खो देती है और मॉडल ऐसा व्यवहार करता है जैसे उसे भूलने की बीमारी (amnesia) हो।

इसे हर request के लिए सर्वर पर बढ़ाएं:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

एक interactive session के भीतर, /set parameter num_ctx 32768 इसे केवल उस session के लिए बदलता है। API के माध्यम से, request options में num_ctx भेजें।

context का हर अतिरिक्त token weights के अलावा मेमोरी की खपत करता है। यदि आप केवल weights के लिए बने सिस्टम पर पूरे 128K की मांग करेंगे, तो लोड विफल हो जाएगा या सिस्टम धीमी गति पर आ जाएगा। इसे चरणों में बढ़ाएं और हर चरण के बाद ollama ps चलाएं। Ollama में num_ctx और context length कैसे काम करते हैं लेख में इसकी गणना विस्तार से समझाई गई है।

Reasoning strength: low, medium, high और xhigh

Meta ने Muse Glimmer के लिए चार reasoning strengths का दस्तावेजीकरण किया है, जो low से लेकर xhigh तक हैं। जटिल कोडिंग और एजेंट कार्यों के लिए Meta उच्च स्तर की दो सेटिंग्स का उपयोग करने की अनुशंसा करता है। Ollama में यह think पैरामीटर पर निर्भर करता है। कमांड लाइन पर --think= का उपयोग करें, या API बॉडी में think भेजें।

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

एक इंटरैक्टिव सत्र के भीतर, /set think और /set nothink इसे टॉगल करते हैं। Ollama का दस्तावेजीकरण कहता है कि अधिकांश मॉडल या तो boolean या low, medium, या high जैसे स्तर को स्वीकार करते हैं, और कुछ सबसे उच्च उपलब्ध स्तर के लिए max स्वीकार करते हैं। यह मॉडल किन सटीक स्ट्रिंग्स को स्वीकार करता है, यह इसके मॉडल पेज पर दिया गया है, इसलिए अनुमान लगाने के बजाय उसे पढ़ें, और किसी एजेंट में इसे जोड़ने से पहले स्वयं एक बार प्रयास करें।

केवल CPU वाले बॉक्स पर यह सेटिंग काफी प्रभाव डालती है। उच्च strength का अर्थ है कि उत्तर का पहला शब्द आने से पहले अधिक thinking tokens उत्पन्न होंगे, और एक thinking token में उतना ही समय लगता है जितना कि एक उत्तर token में। नियमित कार्यों को low सेटिंग पर ही छोड़ दें। उत्तर की लंबाई के लिए भी समान सावधानी बरतें, इसलिए num_predict के साथ उत्तर को सीमित करें बजाय इसके कि एक लंबी प्रतिक्रिया धीमी मशीन को कई मिनटों तक व्यस्त रखे।

मॉडल को हमेशा चालू एजेंट के लिए लोड रखें

Ollama डिफ़ॉल्ट रूप से पांच मिनट के बाद निष्क्रिय मॉडल को अनलोड कर देता है। ऐसे एजेंट के लिए जो हर दस मिनट में चलता है, इसका मतलब है कि हर बार 18 GB डेटा को डिस्क से लोड करना, और नेटवर्क अटैच्ड स्टोरेज वाले VPS पर यह लोडिंग प्रक्रिया धीमी होती है। इसके बजाय इसे मेमोरी में पिन करें।

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

एक नकारात्मक मान मॉडल को तब तक मेमोरी में रखता है जब तक कि कोई अन्य प्रक्रिया उसे अनलोड न कर दे, और API अनुरोध में keep_alive उस एक कॉल के लिए सर्वर के डिफ़ॉल्ट मान को ओवरराइड कर देता है। इसकी लागत स्पष्ट है: जब कोई कार्य नहीं हो रहा होता है तब भी RAM व्यस्त रहती है, इसलिए यह सेटिंग केवल उस सर्वर के लिए है जो विशेष रूप से एजेंट के लिए समर्पित है। Ollama मॉडल को लोड रखना इसमें उपलब्ध विभिन्न विकल्पों को कवर करता है।

Coding agent को इससे जोड़ना

Ollama, http://127.0.0.1:11434/v1 पर एक OpenAI-compatible API प्रदान करता है, इसलिए अधिकांश agent tools एक base URL और किसी भी non-empty API key के साथ कनेक्ट हो जाते हैं। Ollama का Muse Glimmer पेज एक launch shortcut के बारे में भी बताता है जो एक समर्थित agent को एक ही command में local model से जोड़ देता है, और आपको वहां tag को भी pin करना चाहिए।

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

Agents बड़े prompts भेजते हैं। File contents, tool output और बढ़ती हुई transcript, सभी input tokens के रूप में आते हैं, और CPU box पर generation शुरू होने से पहले prompt processing ही सबसे अधिक समय लेने वाली प्रक्रिया होती है। Context setting को उतना ही छोटा रखें जितना कार्य के लिए आवश्यक हो। Ollama पर coding agent को जोड़ना client side को कवर करता है, VPS पर coding agent चलाना उस box को कवर करता है जिस पर वह चलता है, और VPS पर agent की लागत को नियंत्रित करना यह बताता है कि जब यह पूरे दिन चलता है तो क्या होता है।

Image input भी इसी तरह काम करता है। Ollama API एक message के images field पर images लेता है, इसलिए एक text-only client कभी भी image नहीं भेजेगा, चाहे perception encoder कितना भी सक्षम क्यों न हो।

Port 11434 को open न करें

Ollama API में कोई authentication नहीं होता है। OLLAMA_HOST=0.0.0.0:11434 को set करने से ताकि आप इसे अपने laptop से access कर सकें, एक unauthenticated model runner public internet पर आ जाता है। कोई भी व्यक्ति जो इसे ढूँढ लेता है, वह आपके disk पर models load कर सकता है और आपका agent जो भी data भेजता है उसे पढ़ सकता है। इसे localhost पर ही bind रहने दें और इसके बजाय tunnel का उपयोग करें।

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

Ollama API endpoint को सुरक्षित करना में उचित विकल्प शामिल हैं, जिसमें एक reverse proxy भी है जो credentials की मांग करता है।

क्या खराब होता है और आपको क्या दिखाई देगा

पुल (pull) बीच में ही रुक जाता है। डिस्क। मॉडल डायरेक्टरी पर df -h चलाएं। एक 57 GB bf16 बिल्ड 40GB के रूट वॉल्यूम पर फिट नहीं होता है, और न ही दो 8-bit टैग एक साथ आ सकते हैं।

मॉडल लोड होता है और फिर प्रोसेस बंद हो जाता है। मेमोरी खत्म हो गई (Out of memory)। dmesg -T रिकॉर्ड करता है कि कर्नल का आउट ऑफ मेमोरी किलर किसी प्रोसेस को चुन रहा है, और journalctl -u ollama -n 100 उसी घटना का सर्विस-साइड दृश्य दिखाता है। इसका समाधान एक छोटा टैग या छोटा num_ctx है। यह अधिक स्वैप (swap) नहीं है।

यह प्रति टोकन सेकंड के हिसाब से चलता है। vmstat 1 चलाएं और si तथा so कॉलम पर नजर रखें। निरंतर स्वैप गतिविधि का मतलब है कि वेट्स (weights) RAM में फिट नहीं हो रहे हैं और बॉक्स काम करते समय उन्हें डिस्क से वापस पढ़ रहा है।

एक टैग जो पिछले हफ्ते काम कर रहा था, वह गायब है। टैग लिस्ट बदलती रहती है। मॉडल पेज को दोबारा पढ़ें, जो भी वर्तमान में उपलब्ध हो उसे पिन करें, और टैग का नाम कहीं ऐसी जगह नोट करें जहाँ आप उसे दोबारा देख सकें।

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

FAQ

Muse Glimmer को VPS पर कितनी RAM की आवश्यकता होती है?

टैग के आकार से शुरुआत करें और उसमें कॉन्टेक्स्ट विंडो को जोड़ें। 16 अगस्त 2026 को डिफ़ॉल्ट टैग का आकार लगभग 18 GB बताया गया है, इसलिए 16GB वाला बॉक्स इसे बिल्कुल भी लोड नहीं कर पाएगा और 24GB वाले बॉक्स में कॉन्टेक्स्ट के लिए बहुत कम जगह बचेगी। इसे केवल एक शुरुआती बिंदु मानें, अंतिम उत्तर नहीं। टैग को पुल करें, उसे एक बार लोड करें, फिर अपने बॉक्स पर ollama ps और free -h चलाएं और स्वयं अपने आंकड़े देखें। लंबा कॉन्टेक्स्ट और समानांतर अनुरोध (parallel requests) दोनों ही वेट्स (weights) के ऊपर अतिरिक्त मेमोरी का उपयोग करते हैं।

क्या मैं बिना GPU के Muse Glimmer चला सकता हूँ?

हाँ। यह केवल CPU वाले VPS पर लोड और उत्तर दे सकता है। जनरेशन की गति कोर की संख्या के बजाय मेमोरी बैंडविड्थ द्वारा सीमित होती है, और शेयर्ड होस्ट पर वह बैंडविड्थ भी साझा की जाती है, इसलिए 4-bit पर बहुत कम टोकन प्रति सेकंड की उम्मीद रखें। यह उन बैकग्राउंड एजेंट कार्यों के लिए उपयोगी है जो बिना किसी निगरानी के चलते हैं, लेकिन इंटरैक्टिव चैट के लिए यह बहुत धीमा है। अनुरोध के दौरान ollama ps चलाएं और यह पुष्टि करने के लिए प्रोसेसर कॉलम देखें कि कार्य कहाँ चल रहा है।

क्या Linux VPS पर MLX टैग किसी काम के हैं?

नहीं। mlx नाम वाले प्रत्येक टैग को Ollama के MLX इंजन के लिए बनाया गया है, जो इसका Apple Silicon बैकएंड है। x86 Linux सर्वर पर वे टैग एक बड़ी डाउनलोड फाइल हैं जिन्हें आप चला नहीं सकते। साधारण 30b टैग या अन्य नॉन-MLX टैग का उपयोग करें, और MLX बिल्ड्स के साथ आने वाले Apple हार्डवेयर बेंचमार्क को अनदेखा करें।

मॉडल 128K टोकन से बहुत पहले ही चीजें क्यों भूल जाता है?

क्योंकि Ollama की डिफ़ॉल्ट कॉन्टेक्स्ट विंडो 4096 टोकन है, चाहे मॉडल कितना भी सपोर्ट क्यों न करता हो, इसलिए सर्वर लंबी बातचीत को मॉडल द्वारा देखे जाने से पहले ही काट (truncate) देता है। सर्वर पर OLLAMA_CONTEXT_LENGTH सेट करें, या एक सेशन के लिए /set parameter num_ctx का उपयोग करें, या API अनुरोध विकल्पों में num_ctx भेजें। इसके साथ मेमोरी का उपयोग बढ़ता है, इसलिए इसे चरणों में बढ़ाएं और हर बार ollama ps की जाँच करें।

क्या मुझे टैग को पिन करना चाहिए या केवल latest का उपयोग करना चाहिए?

इसे पिन करें। बिना टैग के muse-glimmer का मतलब latest होता है, जो एक ऐसा पॉइंटर है जिसे प्रकाशक किसी भी समय किसी अलग बिल्ड पर ले जा सकता है, इसलिए एक रूटीन पुल उस मॉडल को बदल सकता है जिस पर आपका एजेंट चल रहा है। स्क्रिप्ट, यूनिट फाइल्स और एजेंट कॉन्फ़िगरेशन में muse-glimmer:30b लिखें। पिन करने से पहले मॉडल पेज पर टैग सूची की जाँच करें, क्योंकि प्रकाशित टैग बदलते रहते हैं।