VPS پر Meta Muse Glimmer 30B کیسے چلائیں؟

VPS پر Muse Glimmer کے تقاضے

Muse Glimmer عام Linux VPS پر GPU کے بغیر چلتا ہے، اور آپ جو tag حاصل کرتے ہیں وہ طے کرتا ہے کہ یہ دستیاب memory میں فٹ ہوگا یا نہیں۔ Meta Superintelligence Labs نے یہ model 10 August 2026 کو Apache 2.0 کے تحت جاری کیا۔ اس میں 30 billion parameters، 128K context window، اور 1.8B parameters کا dedicated perception encoder شامل ہے، اس لیے یہ text کے ساتھ images بھی پڑھ سکتا ہے۔ Meta اسے chat کے بجائے ہمیشہ فعال local agents کے لیے پیش کرتا ہے، جبکہ reasoning strength آپ ہر request کے لیے مقرر کرتے ہیں۔

16 August 2026 کو پڑھے گئے published Ollama tags کا حجم 17 GB سے 59 GB تک ہے۔ sizing کا پورا مسئلہ اسی 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 کے لیے 11 ایسے tags درج کیے ہیں جو Apple builds نہیں ہیں۔ ان میں وہی 30 billion weights مختلف numeric precisions میں محفوظ ہیں۔ دکھائی گئی size وہی ہے جو آپ download کریں گے، اور 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 غیر quantised 16-bit release ہے، جس کا حجم 57 GB ہے۔ یہ اتنی RAM استعمال کرتی ہے جو زیادہ تر rented servers میں ایسے نرخ پر دستیاب نہیں ہوتی جسے کوئی side project کے لیے ادا کرے۔

-dflash tags وہی builds ہیں جن میں DFlash support شامل ہے، اور ہر ایک plain twin سے بڑی درج ہے۔ Ollama، DFlash کو speed feature کے طور پر بیان کرتا ہے اور اسے Apple Silicon اور desktop GPUs پر دکھاتا ہے۔ صرف CPU والے VPS پر آپ دوسرے hardware پر ناپی گئی feature کے لیے اضافی size کی real memory ادا کریں گے۔ اس لیے plain tag سے شروع کریں اور ایک وقت میں صرف ایک چیز تبدیل کریں۔

جب تک اس کے خلاف کوئی مخصوص وجہ نہ ہو، 4-bit سے شروع کریں۔ 4-bit سے 8-bit پر جانے سے CPU کو ہر generated token کے لیے تقریباً دو گنا bytes پڑھنے پڑتے ہیں۔ اس سے throughput کم اور memory use زیادہ ہوتا ہے۔ اس 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 پر یہ دسیوں gigabytes کی ایسی download ہے جسے آپ چلا نہیں سکتے، اور یہ disk پر بے مصرف پڑی رہے گی۔ اعلان میں دیے گئے speed کے اعداد، جو Mac پر ناپے گئے تھے، انہی tags سے متعلق ہیں۔ اس لیے وہ آپ کے server کی کارکردگی بیان نہیں کرتے۔ Model page پر tag list پڑھتے وقت پہلے ہر mlx نام کو خارج کریں، پھر باقی tags کی بنیاد پر disk space کا اندازہ لگائیں۔

اسے حقیقت میں کتنی RAM اور disk درکار ہوتی ہے؟

Memory پر دو چیزیں اثر انداز ہوتی ہیں، اور ان میں سے صرف ایک tag size ہے۔ Weights کا حجم اس tag سے متعین ہوتا ہے جسے آپ pull کرتے ہیں۔ KV cache، یعنی model کی conversation کے لیے محفوظ کردہ فی token state، آپ کی مقرر کردہ context length کے ساتھ بڑھتی ہے۔ Ollama کی documentation کے مطابق parallel requests چلانے سے context کا حجم زیرِ عمل requests کی تعداد کے مطابق کئی گنا بڑھ جاتا ہے۔ اس لیے ایک ہی وقت میں دو agents کو جواب دینے والے server کو ایک agent کو جواب دینے والے اسی server سے زیادہ memory درکار ہوتی ہے۔

کسی بھی guide، بشمول اس guide، میں دی گئی RAM کی مقدار پر انحصار نہ کریں۔ Tag pull کریں، اسے ایک prompt بھیجیں، اور model کے memory میں موجود رہنے کے دوران یہ دو commands چلائیں۔

ollama ps
free -h

ollama ps اس وقت memory میں loaded چیزیں اور CPU اور GPU کے درمیان کام کی تقسیم دکھاتا ہے۔ free -h دستیاب باقی resources دکھاتا ہے۔ آپ کے اپنے server پر حاصل ہونے والے یہ دونوں outputs کسی بھی published table سے زیادہ قابلِ اعتماد ہیں، کیونکہ ان میں آپ کی context setting، quantisation اور server پر چلنے والی دیگر تمام چیزیں پہلے ہی شامل ہوتی ہیں۔

Disk معاملے کا آسان حصہ ہے۔ Linux پر Ollama models کو /usr/share/ollama/.ollama/models کے تحت محفوظ کرتا ہے، اور زیادہ تر VPS images میں یہ root filesystem پر ہوتا ہے۔ 40GB کا root volume 57 GB کے bf16 build کے لیے کافی نہیں ہوگا، اور نہ ہی اس میں دو 8-bit tags بیک وقت رکھے جا سکیں گے۔ کچھ بھی pull کرنے سے پہلے model 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 کا owner ہونا چاہیے، کیونکہ service ollama کے طور پر چلتی ہے اور اپنے blobs اسی user کے طور پر وہاں لکھتی ہے۔ اگر pull permissions کی وجہ سے ناکام ہو تو وجہ journalctl -u ollama -n 50 میں نظر آئے گی۔

Swap کے بارے میں ایک بات واضح ہے: swap آپ کو بڑا tag چلانے کے قابل نہیں بناتا۔ Generation کے دوران model ہر پیدا کیے جانے والے token کے لیے weights کو access کرتا ہے۔ اس لیے swap میں موجود weights بار بار disk سے پڑھے جاتے ہیں، vmstat 1 میں si اور so columns مصروف نظر آتے ہیں، اور output کی رفتار کم ہو کر فی token کئی seconds ہو جاتی ہے۔ Out of memory killer سے بچاؤ کے لیے چھوٹی swap file رکھیں۔ RAM کا سائز اسی tag کی ضرورت کے مطابق مقرر کریں جسے آپ حقیقت میں چلانا چاہتے ہیں۔

Ollama انسٹال کریں اور نامزد tag مقرر کریں

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

انسٹال اسکرپٹ 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 سے ملائیں۔ شائع شدہ tags شامل، rename یا حذف ہوتے رہتے ہیں، اور guide میں دیا گیا size صرف ایک دن کی snapshot ہوتا ہے۔

جس server پر آپ انحصار کرتے ہیں، وہاں کبھی ollama pull muse-glimmer نہ لکھیں۔ سادہ model name latest tag پر resolve ہوتا ہے، جبکہ latest ایسا pointer ہے جسے publisher کسی مختلف build کی طرف منتقل کر سکتا ہے۔ معمول کے pull سے آپ کے agent کے نیچے model تبدیل ہو جاتا ہے۔ اس کے نتیجے میں memory کی ضروریات اور behavior مختلف ہو سکتے ہیں، اور logs میں اس تبدیلی کا کوئی اعلان نہیں ہوتا۔ اپنے scripts، unit files اور agent config میں tag واضح طور پر لکھیں۔ VPS پر Ollama کے ساتھ LLM کو self-host کرنا server setup کے باقی حصے کی وضاحت کرتا ہے۔

کیا آپ Muse Glimmer کو GPU کے بغیر چلا سکتے ہیں؟

ہاں، لیکن اس کی عملی حد واضح طور پر سمجھنا ضروری ہے۔ ایک token generate کرنے کے لیے model weights کو memory سے پڑھنا پڑتا ہے، اس لیے رفتار کا تعین plan میں بتائے گئے vCPUs کی تعداد کے بجائے memory bandwidth کرتی ہے۔ چند cores سے زیادہ cores شامل کرنے سے بہت کم فائدہ ہوتا ہے۔ Shared VPS پر یہ bandwidth host کے ہر دوسرے tenant کے ساتھ مشترک ہوتی ہے، اس لیے 4-bit میں 30B model فی سیکنڈ صرف چند tokens پیدا کرتا ہے۔

اس بارے میں کسی کے بتائے ہوئے number پر انحصار نہ کریں، میرے بتائے ہوئے پر بھی نہیں۔ اپنے box پر فی سیکنڈ tokens کی رفتار ناپیں اور جو نتیجہ ملے، اسی کی بنیاد پر فیصلہ کریں۔

اس کا نتیجہ یہ ہے کہ model کی افادیت دو مختلف صورتوں میں تقسیم ہو جاتی ہے۔ Interactive chat دشوار ہے، کیونکہ آپ server کے لکھنے سے زیادہ تیزی سے پڑھتے ہیں اور ہر reply کے آغاز میں طویل وقفہ آتا ہے۔ Background agent کا کام مناسب رہتا ہے، کیونکہ unattended طور پر دس منٹ چلنے والے task کے لیے سست رفتار ہونا اہم نہیں ہوتا۔ Meta اس model کے لیے بالکل اسی workload کی وضاحت کرتا ہے۔

اگر آپ کو interactive رفتار درکار ہے تو دو دیانت دارانہ جواب ہیں: GPU یا hosted API۔ کچھ بھی rent کرنے سے پہلے GPU VPS اور API tokens کے درمیان break-even point معلوم کریں، اور GPU VPS آپ کو حقیقت میں کیا فراہم کرتا ہے میں بتایا گیا ہے کہ آپ کیا خرید رہے ہیں۔ یہ جاننے کے لیے کہ کوئی مخصوص box کون سے models چلا سکتا ہے، آپ کون سے models self-host کر سکتے ہیں سے شروع کریں، جبکہ VPS پر اسی سائز کا Qwen model چلانا اس size class کا سب سے قریب comparison ہے۔

یہ 128K tokens سے بہت پہلے چیزیں کیوں بھول جاتا ہے؟

اس کی وجہ یہ ہے کہ Ollama کی default context window 4096 tokens ہے، چاہے model اس سے زیادہ tokens کو support کرتا ہو۔ August 2026 تک یہ default Ollama کے اپنے FAQ میں درج ہے۔ Tag میں 128K درج ہوتا ہے، لیکن server model کو 4096 tokens ہی دیتا ہے، جب تک آپ اسے تبدیل نہ کریں۔ اسی لیے طویل agent transcript میں ابتدائی turns ضائع ہو جاتے ہیں اور model کو amnesia جیسا مسئلہ محسوس ہوتا ہے۔

Server پر ہر request کے لیے اسے بڑھائیں:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Interactive session کے اندر /set parameter num_ctx 32768 صرف اسی session کے لیے context window تبدیل کرتا ہے۔ API کے ذریعے request options میں num_ctx بھیجیں۔

Context کا ہر اضافی token weights کے علاوہ memory استعمال کرتا ہے۔ اگر box صرف weights کے لیے sized ہو اور آپ مکمل 128K طلب کریں تو load ناکام ہو سکتا ہے یا system کسی سست متبادل پر fallback کر سکتا ہے۔ اسے مرحلہ وار بڑھائیں اور ہر مرحلے کے بعد ollama ps چلائیں۔ Ollama میں num_ctx اور context length کیسے کام کرتے ہیں میں اس حساب کی تفصیل دی گئی ہے۔

استدلال کی مضبوطی: low، medium، high اور xhigh

Meta نے Muse Glimmer کے لیے استدلال کی چار مضبوطیاں، low سے xhigh تک، بیان کی ہیں اور پیچیدہ coding اور agent tasks کے لیے آخری دو کی تجویز دی ہے۔ 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 اسے فعال یا غیر فعال کرتے ہیں۔ Ollama کی documentation کے مطابق زیادہ تر models boolean یا low، medium اور high جیسی level قبول کرتے ہیں، جبکہ کچھ models دستیاب اعلیٰ ترین level کے لیے max بھی قبول کرتے ہیں۔ یہ model کن exact strings کو قبول کرتا ہے، اس کی تصدیق اس کے model page پر کریں۔ اندازہ نہ لگائیں، اور اسے agent میں شامل کرنے سے پہلے ایک بار خود آزما لیں۔

صرف CPU والے system پر اس setting کا نمایاں اثر ہوتا ہے۔ زیادہ مضبوطی کا مطلب ہے کہ جواب کا پہلا لفظ ظاہر ہونے سے پہلے زیادہ thinking tokens generate ہوں گے، اور ہر thinking token اتنا ہی wall clock time لیتا ہے جتنا ایک answer token۔ معمول کے کام کے لیے low setting برقرار رکھیں۔

ہمیشہ فعال agent کے لیے model کو loaded رکھیں

Ollama غیر فعال model کو default طور پر پانچ منٹ بعد unload کر دیتا ہے۔ ہر دس منٹ بعد چلنے والے agent کے لیے اس کا مطلب ہے کہ ہر run پر disk سے پورے 18 GB کو دوبارہ load کرنا پڑتا ہے۔ Network attached storage والے VPS پر یہ load فوری نہیں ہوتا۔ اس کے بجائے model کو memory میں موجود رکھیں۔

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

منفی value model کو اس وقت تک resident رکھتی ہے جب تک کوئی اسے unload نہ کرے، جبکہ API request میں keep_alive صرف اسی call کے لیے server default کو override کرتا ہے۔ اس کی لاگت واضح ہے: جب کوئی کام نہیں ہو رہا ہوتا تب بھی RAM استعمال ہوتی رہتی ہے۔ اس لیے یہ setting ایسے box کے لیے ہے جو agent کے لیے مخصوص ہو۔ Ollama model کو loaded رکھنا میں مختلف صورتوں کی وضاحت کی گئی ہے۔

اسے coding agent سے منسلک کریں

Ollama، http://127.0.0.1:11434/v1 پر OpenAI compatible API فراہم کرتا ہے، اس لیے زیادہ تر agent tools صرف base URL اور کوئی non empty API key استعمال کر کے connect ہو جاتے ہیں۔ Ollama کے Muse Glimmer صفحے پر launch shortcut بھی درج ہے، جو ایک supported agent کو ایک ہی command سے local model سے connect کرتا ہے۔ وہاں 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 کو task کی ضرورت کے مطابق ممکنہ حد تک کم رکھیں۔ coding agent کو Ollama سے منسلک کرنا client side کا احاطہ کرتا ہے، VPS پر coding agent چلانا اس box کا احاطہ کرتا ہے جہاں یہ agent چلتا ہے، اور VPS پر agent کے اخراجات قابو میں رکھنا یہ بتاتا ہے کہ agent کے سارا دن چلنے پر کیا ہوتا ہے۔

Image input بھی اسی طرح کام کرتا ہے۔ Ollama API کسی message کے images field میں images قبول کرتی ہے۔ اس لیے text only client کبھی image نہیں بھیجے گا، چاہے perception encoder کتنا ہی قابل کیوں نہ ہو۔

11434 port کھولیں نہیں

Ollama API میں authentication موجود نہیں ہے۔ OLLAMA_HOST=0.0.0.0:11434 کو set کرنے سے آپ اپنے laptop سے اس تک پہنچ سکتے ہیں، لیکن اس کے نتیجے میں ایک ایسا unauthenticated model runner public internet پر آ جاتا ہے جسے تلاش کرنے والا کوئی بھی شخص آپ کی disk پر models load کر سکتا ہے اور آپ کا agent اس کے ذریعے جو کچھ بھی بھیجتا ہے اسے پڑھ سکتا ہے۔ اسے localhost پر bound رہنے دیں اور اس کے بجائے tunnel استعمال کریں۔

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

Ollama API endpoint کو محفوظ بنانا میں درست طریقے بیان کیے گئے ہیں، جن میں credentials طلب کرنے والا reverse proxy بھی شامل ہے۔

کیا خراب ہوتا ہے، اور آپ کو کیا نظر آئے گا

Pull درمیان میں رک جاتی ہے۔ وجہ disk ہے۔ Model directory پر df -h چلائیں۔ 57 GB کا bf16 build 40GB کے root volume میں نہیں سما سکتا، اور نہ ہی دو 8-bit tags ساتھ ساتھ سما سکتے ہیں۔

Model load ہونے کے بعد process بند ہو جاتا ہے۔ وجہ out of memory ہے۔ dmesg -T میں kernel کے out of memory killer کی جانب سے منتخب کیے گئے process کا ریکارڈ ہوتا ہے، جبکہ journalctl -u ollama -n 100 اسی واقعے کو service کی جانب سے دکھاتا ہے۔ حل چھوٹا tag یا چھوٹا num_ctx استعمال کرنا ہے۔ زیادہ swap شامل کرنا حل نہیں ہے۔

یہ فی token کئی seconds لیتا ہے۔ vmstat 1 چلائیں اور si اور so columns کو monitor کریں۔ مسلسل swap activity کا مطلب ہے کہ weights RAM میں نہیں سما رہے اور 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

VPS پر Muse Glimmer کو کتنی RAM درکار ہوتی ہے؟

tag کے حجم سے آغاز کریں اور اس میں context window شامل کریں۔ default tag کا حجم 16 August 2026 کو تقریباً 18 GB درج تھا، اس لیے 16GB کا server اسے مکمل طور پر رکھ ہی نہیں سکتا، جبکہ 24GB کا server اسے context کے لیے بہت کم گنجائش کے ساتھ رکھتا ہے۔ اسے حتمی جواب نہیں بلکہ ابتدائی اندازہ سمجھیں۔ tag کو pull کریں، اسے ایک بار load کریں، پھر اپنے server پر ollama ps اور free -h چلائیں اور اپنے اعداد پڑھیں۔ زیادہ طویل context اور متوازی requests، دونوں weights کے علاوہ مزید memory استعمال کرتے ہیں۔

کیا میں GPU کے بغیر Muse Glimmer چلا سکتا ہوں؟

ہاں۔ یہ صرف CPU والے VPS پر load ہو کر جواب دیتا ہے۔ generation speed کا انحصار core count کے بجائے memory bandwidth پر ہوتا ہے، اور shared host پر یہ bandwidth مشترک ہوتی ہے، اس لیے 4-bit پر چند tokens فی second کی توقع رکھیں۔ یہ unattended background agent work کے لیے قابل استعمال ہے، لیکن 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 کو نظر انداز کریں۔

model 128K tokens سے بہت پہلے چیزیں کیوں بھول جاتا ہے؟

کیونکہ Ollama کی default context window model کی supported حد سے قطع نظر 4096 tokens ہوتی ہے، اس لیے server طویل conversations کو model تک پہنچنے سے پہلے truncate کر دیتا ہے۔ server پر OLLAMA_CONTEXT_LENGTH set کریں، یا ایک session کے لیے /set parameter num_ctx استعمال کریں، یا API request options میں num_ctx بھیجیں۔ اس کے ساتھ memory use بڑھتا ہے، اس لیے اسے مرحلہ وار بڑھائیں اور ہر بار ollama ps چیک کریں۔

کیا مجھے tag pin کرنا چاہیے یا صرف latest استعمال کرنا چاہیے؟

اسے pin کریں۔ بغیر tag کے muse-glimmer، latest پر resolve ہوتا ہے۔ یہ ایسا pointer ہے جسے publisher کسی بھی وقت مختلف build کی طرف منتقل کر سکتا ہے، اس لیے معمول کا pull آپ کے agent کے چلانے والے model کو تبدیل کر سکتا ہے۔ scripts، unit files اور agent config میں muse-glimmer:30b لکھیں۔ tag pin کرنے سے پہلے model page پر tag list چیک کریں، کیونکہ published tags تبدیل ہوتے رہتے ہیں۔