VPS پر Muse Glimmer 30B چلانے کا طریقہ

VPS پر Muse Glimmer کے لیے درکار چیزیں

Muse Glimmer ایک عام Linux VPS پر GPU کے بغیر چلتا ہے، اور آپ جو tag pull کرتے ہیں وہ طے کرتا ہے کہ یہ 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 کا size تقریباً 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، جس کا size 17 GB ہے، اور 30b-q4_K_M، جس کا size 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 ہے، جس کا size 57 GB ہے۔ یہ اتنی RAM ہے جو زیادہ تر rented servers کسی side project کے لیے قابلِ قبول قیمت پر فراہم نہیں کرتے۔

-dflash tags وہی builds ہیں جن میں DFlash support شامل ہے، اور ہر ایک plain twin سے بڑا درج ہے۔ Ollama، DFlash کو speed feature کے طور پر بیان کرتا ہے اور اسے Apple Silicon اور desktop GPUs پر دکھاتا ہے۔ صرف CPU والے VPS پر آپ اس extra size کی قیمت حقیقی memory میں ایک ایسی feature کے لیے ادا کریں گے جس کی پیمائش دوسرے hardware پر کی گئی ہے۔ اس لیے 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 server پر MLX tags کام کیوں نہیں کرتے

MLX، Apple کا array framework ہے، جبکہ Ollama کا MLX engine اسی platform کے Apple Silicon backend کے طور پر کام کرتا ہے۔ نام میں mlx رکھنے والا ہر tag اسی engine اور hardware کے لیے بنایا گیا ہے۔ x86 Linux VPS پر یہ کئی دسیوں GB کا download ہوتا ہے جسے آپ چلا نہیں سکتے، اور یہ disk پر بے کار پڑا رہتا ہے۔ اعلان میں دی گئی speed figures، جو 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، آپ کی configure کردہ context length کے ساتھ بڑھتی ہے۔ Ollama کی دستاویزات کے مطابق parallel requests چلانے سے context، زیرِ عمل requests کی تعداد کے لحاظ سے کئی گنا بڑھ جاتا ہے۔ اس لیے ایک ہی وقت میں دو agents کو جواب دینے والے سرور کو، ایک agent کو جواب دینے والے اسی سرور سے زیادہ memory درکار ہوتی ہے۔

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

ollama ps
free -h

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

Disk معاملے کا آسان حصہ ہے۔ Ollama Linux پر models کو /usr/share/ollama/.ollama/models کے تحت محفوظ کرتا ہے، اور اکثر VPS images میں یہ root filesystem پر ہوتا ہے۔ 40GB کا root volume، 57 GB کے bf16 build کو محفوظ نہیں کر سکے گا، اور نہ ہی دو 8-bit tags کو ساتھ ساتھ رکھ سکے گا۔ اگر آپ نے کبھی نہیں دیکھا کہ pull command حقیقت میں کون سی 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

اس directory کا مالک ollama user ہونا چاہیے، کیونکہ 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 کی رفتار چند seconds فی token تک کم ہو جاتی ہے۔ Out of memory killer سے بچاؤ کے لیے ایک چھوٹی swap file رکھیں۔ RAM کی مقدار اس tag کے مطابق مقرر کریں جسے آپ واقعی چلانا چاہتے ہیں۔

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

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

انسٹال اسکرپٹ ایک systemd سروس ترتیب دیتا ہے، اس لیے reboot کے بعد سرور دوبارہ دستیاب ہو جاتا ہے۔ اگر آپ اسے root کے زیر انتظام system service کے طور پر نہیں چلانا چاہتے تو Podman کے تحت Ollama کو rootless چلانے کا طریقہ دیکھیں۔ اس کے بعد واضح tag pull کریں۔

ollama pull muse-glimmer:30b
ollama list

ollama list میں size column خود پڑھیں اور اس کا موجودہ tag list سے model page پر موازنہ کریں۔ شائع شدہ tags شامل، rename یا حذف کیے جاتے ہیں، اور کسی guide میں دیا گیا size صرف ایک دن کی snapshot ہوتا ہے۔

کسی ایسے سرور پر 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-hosting میں سرور setup کی باقی تفصیل موجود ہے۔

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

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

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

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

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

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

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

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

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

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

Context کے ہر اضافی token کے لیے weights کے علاوہ مزید memory درکار ہوتی ہے۔ صرف weights کے لیے مختص box پر مکمل 128K طلب کرنے سے load ناکام ہو سکتا ہے یا کوئی سست متبادل استعمال ہو سکتا ہے۔ اسے مرحلہ وار بڑھائیں اور ہر مرحلے کے بعد 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 دستیاب بلند ترین سطح کے لیے max بھی قبول کرتے ہیں۔ یہ model کن exact strings کو قبول کرتا ہے، اس کا تعین اس کے model page سے کریں۔ اندازہ لگانے کے بجائے پہلے اسے دستی طور پر آزمائیں، پھر agent میں شامل کریں۔

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

ہمیشہ چلنے والے agent کے لیے model کو loaded رکھیں

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

[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 لے کر مربوط ہو جاتے ہیں۔ Ollama کے Muse Glimmer صفحے پر ایک launch shortcut بھی درج ہے، جو ایک ہی command سے supported agent کو local model کے ساتھ مربوط کرتا ہے۔ وہاں tag بھی واضح طور پر pin کریں۔

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

Agents بڑے prompts بھیجتے ہیں۔ فائل کا مواد، tool output اور بڑھتا ہوا transcript سب input tokens کے طور پر شامل ہوتے ہیں۔ CPU-based machine پر generation شروع ہونے سے پہلے prompt processing ہی زیادہ وقت لیتی ہے۔ context setting کو کام کی ضرورت کے مطابق کم سے کم رکھیں۔ coding agent کو Ollama سے مربوط کرنا client side کا احاطہ کرتا ہے، VPS پر coding agent چلانا اس machine کا احاطہ کرتا ہے جہاں agent چلتا ہے، جبکہ VPS پر agent کے اخراجات کو کنٹرول کرنا اس صورت حال کا احاطہ کرتا ہے جب agent سارا دن چلتا رہے۔

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

پورٹ 11434 نہ کھولیں

Ollama API میں authentication موجود نہیں ہے۔ OLLAMA_HOST=0.0.0.0:11434 setting کرنے سے آپ اپنے laptop سے اس تک رسائی تو حاصل کر لیتے ہیں، لیکن اس طرح ایک ایسا غیر مستند 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 کو محفوظ بنانا میں درست options بیان کیے گئے ہیں، جن میں ایسا reverse proxy بھی شامل ہے جو credentials طلب کرتا ہے۔

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

Pull درمیان میں رک جاتا ہے۔ مسئلہ disk کا ہے۔ 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 کی جانب سے دکھاتا ہے۔ حل چھوٹا tag یا چھوٹا num_ctx استعمال کرنا ہے۔ مزید swap شامل کرنا حل نہیں ہے۔

یہ ہر token پر کئی seconds لیتا ہے۔ vmstat 1 چلائیں اور si اور so columns کو monitor کریں۔ مسلسل swap activity کا مطلب ہے کہ weights RAM میں فٹ نہیں ہو رہے اور box کام کے دوران انہیں 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 کا box اسے بالکل رکھ نہیں سکتا، جبکہ 24GB کا box اسے context کے لیے بہت کم اضافی گنجائش کے ساتھ رکھتا ہے۔ اسے حتمی جواب نہیں بلکہ ابتدائی اندازہ سمجھیں۔ Tag pull کریں، اسے ایک بار load کریں، پھر اپنے box پر ollama ps اور free -h چلائیں اور اپنے اعداد پڑھیں۔ زیادہ طویل context اور متوازی requests، دونوں weights کے علاوہ مزید memory استعمال کرتے ہیں۔

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

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

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

کیونکہ Ollama کی default context window، ماڈل کی support سے قطع نظر، 4096 tokens ہوتی ہے۔ اس لیے server ماڈل کو دکھانے سے پہلے ہی طویل conversations کو 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 لکھیں۔ Pin کرنے سے پہلے model page پر tag list چیک کریں، کیونکہ published tags تبدیل ہوتے رہتے ہیں۔