VPS-এ Meta Muse Glimmer 30B চালাতে কত RAM লাগে

VPS-এ Muse Glimmer-এর যা প্রয়োজন

Muse Glimmer GPU ছাড়াই সাধারণ Linux VPS-এ চলে। আপনি যে tag pull করবেন, সেটিই নির্ধারণ করে এটি available memory-তে চলবে কি না। Meta Superintelligence Labs 10 August 2026-এ Apache 2.0-এর অধীনে model-টি প্রকাশ করেছে। এতে 30 billion parameter, 128K context window এবং dedicated 1.8B parameter perception encoder রয়েছে। তাই এটি text-এর পাশাপাশি image-ও পড়তে পারে। Meta এটিকে chat-এর পরিবর্তে সবসময় চালু থাকা local agent-এর জন্য তৈরি হিসেবে উপস্থাপন করেছে। প্রতিটি request-এ reasoning strength নির্ধারণ করা যায়।

16 August 2026-এ দেখা published Ollama tag-গুলোর আকার 17 GB থেকে 59 GB পর্যন্ত। এই range-ই পুরো sizing-এর মূল বিষয়। Default tag-এর আকার প্রায় 18 GB হিসেবে তালিকাভুক্ত। তাই ব্যবহারযোগ্য সর্বনিম্ন server-এ অবশ্যই 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টি tag তালিকাভুক্ত করেছে, যেগুলো Apple build নয়। এগুলোতে একই 30 billion weights ভিন্ন numeric precision-এ সংরক্ষিত আছে। প্রদর্শিত size-ই আপনি download করবেন, এবং context যোগ করার আগে প্রায় এই পরিমাণ memory-ই ধরে রাখতে হবে।

দুটি 4-bit build ছোট: 30b-nvfp4, যার size 17 GB, এবং 30b-q4_K_M, যার size 18 GB। Default 30b tag-টির size q4_K_M build-এর সমান হিসেবে তালিকাভুক্ত। 8-bit build, 30b-q8_0 এবং 30b-mxfp8, প্রায় 31 GB। 30b-bf16 হলো 57 GB-এর unquantised 16-bit release। এই পরিমাণ RAM অধিকাংশ rented server-এ থাকে না, আর side project-এর জন্য যে দামে কেউ server নেবে, সেই দামে এমন server পাওয়াও কঠিন।

-dflash tag-গুলো একই build-এর DFlash-supported সংস্করণ, এবং প্রতিটির listed size plain twin-এর চেয়ে বড়। Ollama DFlash-কে speed feature হিসেবে বর্ণনা করে এবং Apple Silicon ও desktop GPU-তে এটি দেখায়। শুধু CPU-নির্ভর VPS-এ অন্য hardware-এ পরিমাপ করা feature-এর জন্য সেই অতিরিক্ত size-কে বাস্তব memory হিসেবে দিতে হবে। তাই plain tag দিয়ে শুরু করুন এবং একবারে একটি পরিবর্তন করুন।

বিশেষ কারণ না থাকলে 4-bit দিয়ে শুরু করুন। 4-bit থেকে 8-bit-এ গেলে CPU-কে তৈরি করা প্রতিটি token-এর জন্য প্রায় দ্বিগুণ byte পড়তে হয়। ফলে throughput কমে এবং memory use বাড়ে। q4, q8 এবং fp16 quantisation-এর প্রকৃত খরচ-এ এই trade-off ব্যাখ্যা করা হয়েছে। CPU box-এ সংক্ষিপ্ত উত্তর হলো, শুরু করার জন্য 4-bit build-ই একমাত্র যুক্তিসঙ্গত পছন্দ।

Linux server-এ MLX tag কোনো কাজ করে না কেন

MLX হলো Apple-এর array framework, আর Ollama-এর MLX engine হলো Apple Silicon-এর backend। নামের মধ্যে mlx থাকা যেকোনো tag ওই engine এবং hardware-এর জন্য তৈরি। x86 Linux VPS-এ এগুলো কয়েক দশক gigabytes-এর download, কিন্তু আপনি এগুলো চালাতে পারবেন না। এগুলো disk-এ পড়ে থাকবে এবং কোনো কাজ করবে না। Announcement-এ দেওয়া speed figure Mac-এ মাপা হয়েছিল এবং ওই tag-গুলোর ক্ষেত্রে প্রযোজ্য। তাই সেগুলো আপনার server-এর performance বর্ণনা করে না। Model page-এ tag list পড়ার সময় প্রথমে প্রতিটি mlx নাম বাদ দিন। এরপর যে tag-গুলো অবশিষ্ট থাকে, সেগুলোর ভিত্তিতে disk space ও download size হিসাব করুন।

আসলে কত RAM এবং disk space প্রয়োজন?

দুটি জিনিস memory ব্যবহার করে, এবং এর মধ্যে মাত্র একটি হলো tag-এর size। আপনি যে tag pull করেন, weights-এর আকার সেটি নির্ধারণ করে। KV cache, অর্থাৎ conversation-এর জন্য model যে প্রতি-token state সংরক্ষণ করে, আপনার নির্ধারিত context length বাড়ার সঙ্গে সঙ্গে বড় হয়। Ollama-এর documentation অনুযায়ী parallel request পরিবেশন করলে in-flight request-এর সংখ্যা অনুযায়ী context বহুগুণ হয়। তাই একই সময়ে দুইটি agent-এর উত্তর দেওয়া server-এর একটিমাত্র agent-এর উত্তর দেওয়া server-এর চেয়ে বেশি memory প্রয়োজন।

কোনো guide থেকে RAM-এর পরিমাণ ধরে নেবেন না, এই guide থেকেও নয়। tag pull করুন, তাকে একটি prompt পাঠান, এবং model resident থাকা অবস্থায় এই দুটি command চালান।

ollama ps
free -h

ollama ps বর্তমানে কী loaded আছে এবং কাজ CPU ও GPU-এর মধ্যে কীভাবে ভাগ হয়েছে তা দেখায়। free -h অব্যবহৃত কতটুকু বাকি আছে তা দেখায়। আপনার নিজের box-এ পাওয়া এই দুটি output যেকোনো published table-এর চেয়ে বেশি নির্ভরযোগ্য, কারণ এতে আপনার context setting, quantisation এবং server-এ চলমান অন্যান্য সবকিছু ইতিমধ্যেই অন্তর্ভুক্ত থাকে।

Disk-এর বিষয়টি সহজ। Linux-এ Ollama model-গুলো /usr/share/ollama/.ollama/models-এর অধীনে সংরক্ষণ করে। অধিকাংশ VPS image-এ এটি root filesystem-এ থাকে। 57 GB-এর bf16 build রাখার জন্য 40GB root volume যথেষ্ট নয়। পাশাপাশি দুইটি 8-bit tag রাখার জন্যও এটি যথেষ্ট নয়। কোনো pull আসলে কী লিখছে তা যদি আগে না দেখে থাকেন, Ollama কোথায় model সংরক্ষণ করে এবং কীভাবে তা সরাতে হয় সেই 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-টির owner হতে হবে, কারণ service-টি ollama হিসেবে চলে এবং নিজস্ব account ব্যবহার করে সেখানে blob লেখে। কোনো pull permission-এর কারণে ব্যর্থ হলে, কারণটি journalctl -u ollama -n 50-এ দেখা যাবে।

Swap সম্পর্কে একটি বিষয় স্পষ্টভাবে মনে রাখুন: swap ব্যবহার করলে বড় tag চালানো যায় না। Generation প্রতিটি token তৈরি করার সময় weights-এ access করে। তাই swap-এ থাকা weights বারবার disk থেকে পড়তে হয়, vmstat 1-এ si এবং so column ব্যস্ত দেখা যায়, এবং output প্রতি token-এ কয়েক সেকেন্ড সময় নিতে পারে। Out of memory killer থেকে সুরক্ষার জন্য ছোট একটি swap file রাখুন। আপনি যে tag বাস্তবে চালাতে চান, তার জন্য প্রয়োজনীয় RAM অনুযায়ী ব্যবস্থা করুন।

Ollama ইনস্টল করুন এবং নির্দিষ্ট নামযুক্ত tag স্থির করুন

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

ইনস্টল script একটি systemd service সেট আপ করে। তাই reboot-এর পর server আবার চালু হয়। আপনি যদি root দ্বারা পরিচালিত system service হিসেবে এটি চালাতে না চান, তাহলে Podman-এর অধীনে rootless Ollama চালানো পদ্ধতিটি দেখুন। এরপর একটি নির্দিষ্ট tag pull করুন।

ollama pull muse-glimmer:30b
ollama list

ollama list-এর size column নিজে পড়ুন এবং model page-এর বর্তমান tag list-এর সঙ্গে তুলনা করুন। প্রকাশিত tag যোগ, নাম পরিবর্তন বা অপসারণ করা হয়। আর কোনো guide-এ দেওয়া size একটি নির্দিষ্ট দিনের snapshot।

আপনি যে server-এর ওপর নির্ভর করেন, সেখানে কখনও ollama pull muse-glimmer লিখবেন না। শুধু model name দিলে সেটি latest tag-এ resolve হয়। আর latest এমন একটি pointer, যেটি publisher অন্য build-এর দিকে সরিয়ে দিতে পারে। এরপর নিয়মিত pull আপনার agent-এর নিচে থাকা model বদলে দেয়। এতে memory requirement ও আচরণ পরিবর্তিত হয়, কিন্তু আপনার log-এ এ বিষয়ে কোনো ঘোষণা থাকে না। আপনার script, unit file এবং agent config-এ tag লিখে নির্দিষ্ট করে দিন। VPS-এ Ollama দিয়ে LLM self-host করা অংশে server setup-এর বাকি বিষয়গুলো দেখানো হয়েছে।

GPU ছাড়া কি Muse Glimmer চালানো যায়?

হ্যাঁ, তবে এর সীমাবদ্ধতা স্পষ্টভাবে বোঝা জরুরি। একটি token তৈরি করতে model weights memory থেকে পড়তে হয়। তাই গতি নির্ধারিত হয় memory bandwidth দিয়ে, plan-এ দেওয়া vCPU-এর সংখ্যা দিয়ে নয়। কয়েকটি core-এর বেশি হলে অতিরিক্ত core থেকে খুব সামান্যই লাভ হয়। Shared VPS-এ host-এর অন্য সব tenant-এর সঙ্গে এই bandwidth ভাগ হয়ে যায়। ফলে 4-bit-এ 30B model প্রতি সেকেন্ডে অল্পসংখ্যক token তৈরি করে।

এ বিষয়ে কারও দেওয়া সংখ্যা, এমনকি আমার দেওয়া সংখ্যাও, যাচাই না করে গ্রহণ করবেন না। নিজের box-এ প্রতি সেকেন্ডে token মাপুন এবং পরিমাপের ফল দেখে সিদ্ধান্ত নিন।

এতে model-টি কোন কাজে উপযোগী, সে বিষয়ে একটি স্পষ্ট পার্থক্য দেখা যায়। Interactive chat কষ্টকর, কারণ server লেখার চেয়ে আপনি দ্রুত পড়েন এবং প্রতিটি উত্তরের আগে দীর্ঘ অপেক্ষা করতে হয়। Background agent-এর কাজ ঠিকঠাক চলে, কারণ unattended অবস্থায় দশ মিনিট চলা কোনো task ধীরগতিকে গুরুত্ব দেয় না। Meta এই model-এর জন্য যে ব্যবহারের কথা বলেছে, সেটি ঠিক এই ধরনের workload।

Interactive speed প্রয়োজন হলে সৎভাবে বললে দুটি বিকল্প আছে: GPU অথবা hosted API। কিছু ভাড়া নেওয়ার আগে GPU VPS ও API token-এর break-even point নির্ণয় করুন। আপনি আসলে কী কিনছেন, তা GPU VPS বাস্তবে কী দেয়-এ ব্যাখ্যা করা হয়েছে। একটি নির্দিষ্ট box-এ কোন model রাখা যাবে, সে বিষয়ে বৃহত্তর প্রশ্নের জন্য কোন model আপনি self-host করতে পারবেন দিয়ে শুরু করুন। এই size class-এ সবচেয়ে কাছের তুলনাটি হলো VPS-এ একই আকারের Qwen model চালানো। আপনার মাপা সংখ্যা যদি ব্যবহারযোগ্যতার তুলনায় অতিরিক্ত ধীর হয়, তাহলে VPS-এ Nemotron 3.5 Lightning একই RAM এবং প্রতি সেকেন্ডে token-সংক্রান্ত প্রশ্ন এমন একটি model-এর ক্ষেত্রে পরীক্ষা করে, যা আকারের বদলে গতির জন্য তৈরি।

128K tokens-এর অনেক আগেই এটি কেন আগের তথ্য ভুলে যায়?

কারণ Ollama-এর default context window হলো 4096 tokens, model যতটিই support করুক না কেন। August 2026 অনুযায়ী এই default Ollama-এর নিজস্ব FAQ-তে উল্লেখ আছে। Tag-এ 128K দেখানো হলেও, আপনি অন্যথা না বলা পর্যন্ত server model-কে 4096 tokens দেয়। তাই দীর্ঘ agent transcript-এর শুরুর অংশ বাদ পড়ে এবং model-এর আচরণে amnesia-এর মতো মনে হয়।

প্রতিটি request-এর জন্য server-এ এটি বাড়ান:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Interactive session-এর মধ্যে /set parameter num_ctx 32768 শুধু সেই session-এর জন্য context length পরিবর্তন করে। API ব্যবহার করলে request options-এ num_ctx পাঠান।

Context-এর প্রতিটি অতিরিক্ত token weights-এর পাশাপাশি memory ব্যবহার করে। শুধু weights চালানোর জন্য নির্ধারিত server-এ সম্পূর্ণ 128K চাওয়া হলে load ব্যর্থ হতে পারে বা ধীর কোনো বিকল্পে fallback করতে পারে। ধাপে ধাপে মান বাড়ান এবং প্রতিটি ধাপের পরে ollama ps চালান। Ollama-তে num_ctx এবং context length কীভাবে কাজ করে-এ এই হিসাব বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

Reasoning strength: low, medium, high and xhigh

Meta Muse Glimmer-এর জন্য low থেকে xhigh পর্যন্ত চারটি reasoning strength উল্লেখ করেছে এবং জটিল coding ও agent কাজের জন্য শেষের দুটি বেশি ব্যবহারের সুপারিশ করেছে। 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 দিয়ে এটি toggle করা যায়। Ollama-এর documentation অনুযায়ী, অধিকাংশ model boolean অথবা low, medium বা high-এর মতো একটি level গ্রহণ করে। কিছু model সর্বোচ্চ উপলভ্য level-এর জন্য max গ্রহণ করে। এই model ঠিক কোন string গ্রহণ করে, তা তার model page-এ উল্লেখ থাকে। তাই অনুমান না করে সেটি পড়ুন এবং agent-এ যুক্ত করার আগে হাতে একটি মান দিয়ে পরীক্ষা করুন।

শুধু CPU-নির্ভর মেশিনে এই setting-এর প্রভাব স্পষ্ট। strength বেশি হলে উত্তরের প্রথম শব্দ দেখানোর আগে বেশি thinking token generate হয়। একটি thinking token-এর wall clock time-ও একটি answer token-এর সমান। নিয়মিত কাজের জন্য low setting ব্যবহার করুন। উত্তরের length-এর ক্ষেত্রেও একই সতর্কতা প্রযোজ্য। তাই একটি দীর্ঘ, অপ্রয়োজনীয় response ধীর মেশিনকে কয়েক মিনিট আটকে রাখার পরিবর্তে num_predict দিয়ে উত্তরের সীমা নির্ধারণ করুন।

একটি সবসময় চালু agent-এর জন্য model loaded রাখুন

Ollama ডিফল্টভাবে পাঁচ মিনিট নিষ্ক্রিয় থাকার পর model unload করে। যে agent প্রতি দশ মিনিটে চালু হয়, তার ক্ষেত্রে প্রতিবার চালানোর সময় disk থেকে সম্পূর্ণ 18 GB model load করতে হয়। network-attached storage ব্যবহার করা VPS-এ এই load দ্রুত হয় না। তাই model-টি memory-তে pin করুন।

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

ঋণাত্মক মান ব্যবহার করলে অন্য কোনো প্রক্রিয়া unload না করা পর্যন্ত model memory-তে থাকে। API request-এ keep_alive ব্যবহার করলে ওই একটি call-এর জন্য server-এর default মানটি পরিবর্তন করা যায়। এর খরচ স্পষ্ট: কোনো কাজ না চললেও RAM দখল করে থাকে। তাই agent-এর জন্য নির্দিষ্ট server-এ এই setting ব্যবহার করুন। Ollama model loaded রাখা-এ বিভিন্ন পদ্ধতি ব্যাখ্যা করা হয়েছে।

একটি coding agent-এর দিকে এটি নির্দেশ করুন

Ollama http://127.0.0.1:11434/v1-এ OpenAI compatible API সরবরাহ করে। তাই অধিকাংশ agent tool একটি base URL এবং যেকোনো non empty API key ব্যবহার করে সংযুক্ত হয়। Ollama-এর Muse Glimmer page-এ এমন একটি launch shortcut-ও নথিভুক্ত আছে, যা একটি supported agent-কে একটি local model-এর সঙ্গে একটি command-এ সংযুক্ত করে। সেখানেও tag নির্দিষ্ট করে দিন।

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

Agent বড় prompt পাঠায়। File content, tool output এবং ক্রমশ বড় হওয়া transcript সবই input token হিসেবে আসে। CPU box-এ generation শুরু হওয়ার আগেই prompt processing সবচেয়ে বেশি সময় নেয়। কাজের জন্য যতটা ছোট রাখা সম্ভব, context setting ততটাই ছোট রাখুন। Ollama-এর দিকে coding agent নির্দেশ করা client side ব্যাখ্যা করে, VPS-এ coding agent চালানো agent চলা box-টি ব্যাখ্যা করে, এবং VPS-এ agent-এর খরচ নিয়ন্ত্রণ করা এটি সারাদিন চললে কী ঘটে তা ব্যাখ্যা করে।

Image input একইভাবে কাজ করে। Ollama API একটি message-এর images field-এ image গ্রহণ করে। তাই perception encoder যত সক্ষমই হোক, text only client কখনও image পাঠাবে না।

11434 port খুলবেন না

Ollama API-তে কোনো authentication নেই। আপনার laptop থেকে এটিতে পৌঁছানোর জন্য OLLAMA_HOST=0.0.0.0:11434 সেট করলে একটি authentication-বিহীন model runner public internet-এ উন্মুক্ত হবে। যে কেউ এটি খুঁজে পেলে আপনার disk-এ model load করতে এবং আপনার agent এর মাধ্যমে পাঠানো যেকোনো তথ্য পড়তে পারবে। এটিকে localhost-এ bound রাখুন এবং 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 tag-ও ধরে না।

Model load হওয়ার পর process বন্ধ হয়ে যায়। কারণ memory শেষ হয়ে গেছে। Kernel-এর out-of-memory killer কোনো process নির্বাচন করার ঘটনা dmesg -T-এ নথিভুক্ত হয়, এবং একই ঘটনার service-side তথ্য journalctl -u ollama -n 100-এ দেখা যায়। সমাধান হলো ছোট tag অথবা ছোট num_ctx ব্যবহার করা। আরও swap যোগ করা সমাধান নয়।

এটি প্রতি token-এ কয়েক সেকেন্ড সময় নেয়। vmstat 1 চালিয়ে si এবং so column দেখুন। নিয়মিত swap activity দেখা গেলে বুঝবেন weights RAM-এ ধরে না, তাই process চলার সময় system সেগুলো disk থেকে বারবার পড়ছে।

গত সপ্তাহে কাজ করা একটি tag এখন আর নেই। Tag list পরিবর্তিত হয়। 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-এর জন্য প্রয়োজনীয় RAM যোগ করে শুরু করুন। 16 August 2026 তারিখে default tag-এর আকার প্রায় 18 GB হিসেবে তালিকাভুক্ত ছিল। তাই 16GB box-এ এটি একেবারেই রাখা যাবে না, আর 24GB box-এ context-এর জন্য খুব কম জায়গা অবশিষ্ট থাকবে। এটিকে চূড়ান্ত উত্তর নয়, প্রাথমিক হিসাব হিসেবে ধরুন। নিজের box-এ tag pull করুন, একবার load করুন, তারপর ollama ps এবং free -h চালিয়ে নিজের মান দেখুন। দীর্ঘ context এবং parallel request—দুটিই weights-এর অতিরিক্ত memory ব্যবহার করে।

GPU ছাড়া কি Muse Glimmer চালানো যায়?

হ্যাঁ। শুধু CPU ব্যবহার করা VPS-এ এটি load হয়ে উত্তর দিতে পারে। Generation speed core count-এর চেয়ে memory bandwidth দ্বারা বেশি সীমিত হয়। Shared host-এ সেই bandwidth অন্যদের সঙ্গেও ভাগ হয়। তাই 4-bit-এ প্রতি second-এ অল্প সংখ্যক token আশা করুন। Unattended background agent কাজের জন্য এটি ব্যবহারযোগ্য, কিন্তু interactive chat-এর জন্য ধীরগতির এবং অসুবিধাজনক। কোনো request চলার সময় ollama ps চালান এবং কাজটি কোথায় চলছে তা নিশ্চিত করতে processor column দেখুন।

Linux VPS-এ MLX tag কি কোনো কাজে আসে?

না। নামের মধ্যে mlx থাকা প্রতিটি tag Ollama-এর MLX engine-এর জন্য তৈরি। এটি Ollama-এর Apple Silicon backend। x86 Linux server-এ এই tag-গুলো বড় download, কিন্তু আপনি এগুলো চালাতে পারবেন না। সাধারণ 30b tag অথবা অন্য কোনো non-MLX tag ব্যবহার করুন। MLX build-এর সঙ্গে থাকা Apple hardware benchmark উপেক্ষা করুন।

128K token-এর অনেক আগেই model কেন বিষয় ভুলে যায়?

কারণ model যতটুকু সমর্থন করুক, Ollama-এর default context window 4096 token। ফলে model সেগুলো দেখার আগেই server দীর্ঘ conversation truncate করে। 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 চালায় তা বদলে যেতে পারে। Script, unit file এবং agent config-এ muse-glimmer:30b লিখুন। Pin করার আগে model page-এ tag list পরীক্ষা করুন, কারণ published tag পরিবর্তিত হতে পারে।