SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor

اجرای مدل Muse Glimmer 30B روی VPS لینوکسی

برای اجرای Muse Glimmer با حجم 17GB تا 59GB روی VPS چه مقدار RAM و دیسک نیاز دارید؟ بررسی دقیق هزینه‌های استنتاج CPU و انتخاب تگ مناسب برای جلوگیری از خطای کمبود حافظه.

نیازمندی‌های Muse Glimmer روی یک VPS

برنامه Muse Glimmer روی یک VPS لینوکسی معمولی و بدون GPU اجرا می‌شود و تگی که برای دریافت (pull) انتخاب می‌کنید، تعیین‌کننده میزان حافظه مورد نیاز است. آزمایشگاه Meta Superintelligence در تاریخ 10 August 2026 این مدل را تحت مجوز Apache 2.0 منتشر کرد: مدلی با 30 میلیارد پارامتر، پنجره متنی 128K و یک انکودر ادراکی اختصاصی با 1.8 میلیارد پارامتر که امکان خواندن تصاویر در کنار متن را فراهم می‌کند. متا این مدل را نه برای چت، بلکه برای استفاده در عامل‌های (agents) محلی همیشه روشن با قدرت استدلالی که در هر درخواست تنظیم می‌کنید، عرضه کرده است.

تگ‌های منتشرشده در Ollama که در تاریخ 16 August 2026 بررسی شدند، از 17 گیگابایت تا 59 گیگابایت متغیر هستند. این بازه، کل مسئله تعیین اندازه را تشکیل می‌دهد. تگ پیش‌فرض حدود 18 گیگابایت ذکر شده است، بنابراین کوچک‌ترین سرور منطقی باید به‌وضوح بیش از 18 گیگابایت رم آزاد داشته باشد. فضای دیسک برای دانلود و حافظه مورد نیاز برای پنجره متنی نیز علاوه بر این مقدار باید در نظر گرفته شود.

کدام تگ muse-glimmer را باید pull کنید؟

ChartPublished muse-glimmer tag sizes on 16 August 2026 (Linux tags only)
The data behind this chart
[
  {
    "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 تعداد 11 تگ برای این مدل لیست کرده است که نسخه‌های Apple نیستند. این تگ‌ها همگی شامل وزن‌های 30 میلیاردی یکسانی هستند که با دقت‌های عددی متفاوت ذخیره شده‌اند. حجمی که مشاهده می‌کنید، همان مقداری است که دانلود می‌کنید و تقریباً همان میزانی است که باید پیش از اضافه شدن هرگونه context، در حافظه (RAM) در دسترس باشد.

دو نسخه 4-bit، نسخه‌های کوچک‌تر هستند: 30b-nvfp4 با حجم 17 GB و 30b-q4_K_M با حجم 18 GB. تگ پیش‌فرض 30b حجمی مشابه نسخه q4_K_M دارد. نسخه‌های 8-bit، یعنی 30b-q8_0 و 30b-mxfp8، در حدود 31 GB هستند. 30b-bf16 نسخه 16-bit بدون کوانتیزاسیون (unquantised) با حجم 57 GB است که به RAM بسیار بیشتری از آنچه اکثر سرورهای اجاره‌ای با قیمت مناسب برای پروژه‌های جانبی ارائه می‌دهند، نیاز دارد.

تگ‌های -dflash همان نسخه‌ها با پشتیبانی از DFlash هستند و حجم هر کدام از نسخه مشابه خود بدون DFlash بیشتر است. Ollama از DFlash به عنوان یک قابلیت افزایش سرعت یاد می‌کند و عملکرد آن را روی Apple Silicon و GPUهای دسکتاپ نشان می‌دهد. در یک VPS که فقط از CPU استفاده می‌کند، شما هزینه این حجم اضافی را به صورت حافظه واقعی پرداخت می‌کنید، در حالی که این قابلیت برای سخت‌افزارهای دیگری بهینه‌سازی شده است؛ بنابراین با تگ معمولی شروع کنید و تغییرات را یکی‌یکی اعمال کنید.

مگر دلیل خاصی داشته باشید، با نسخه 4-bit شروع کنید. انتقال از 4-bit به 8-bit تقریباً تعداد بایت‌هایی را که CPU باید برای تولید هر توکن بخواند دو برابر می‌کند؛ در نتیجه throughput کاهش یافته و مصرف حافظه افزایش می‌یابد. این مبادله موضوع اصلی هزینه واقعی کوانتیزاسیون q4، q8 و fp16 است و در یک سرور مبتنی بر CPU، پاسخ کوتاه این است که نسخه 4-bit تنها گزینه‌ای است که ارزش شروع کار را دارد.

چرا تگ‌های MLX روی سرور لینوکسی کار نمی‌کنند

MLX فریم‌ورک آرایه‌ای اپل است و موتور MLX در Ollama، بک‌اند اختصاصی آن برای Apple Silicon محسوب می‌شود. هر تگی که در نام خود mlx دارد، برای آن موتور و آن سخت‌افزار خاص ساخته شده است. روی یک VPS لینوکسی با معماری x86، این تگ‌ها ده‌ها گیگابایت حجم دانلود دارند که قابل اجرا نیستند و تنها فضای دیسک شما را اشغال می‌کنند. ارقام مربوط به سرعت که در اطلاعیه‌ها ذکر شده و روی سیستم‌های Mac اندازه‌گیری شده‌اند، مختص همان تگ‌ها هستند و عملکرد سرور شما را نشان نمی‌دهند. هنگام بررسی لیست تگ‌ها در صفحه مدل، ابتدا تمام نام‌های شامل mlx را فیلتر کنید و سپس از میان موارد باقی‌مانده، گزینه مناسب را بر اساس حجم انتخاب نمایید.

میزان رم و دیسک مورد نیاز چقدر است؟

دو عامل حافظه را اشغال می‌کنند که تنها یکی از آن‌ها اندازه تگ (tag) است. وزن‌ها توسط تگی که دریافت می‌کنید تعیین می‌شوند. کش KV، یعنی وضعیتی که مدل برای هر توکن در طول گفتگو نگه می‌دارد، با افزایش طول کانتکستی که تنظیم می‌کنید، رشد می‌کند. مستندات رسمی Ollama اشاره می‌کند که پاسخ‌دهی به درخواست‌های موازی، کانتکست را در تعداد درخواست‌های در حال اجرا ضرب می‌کند؛ بنابراین سروری که همزمان به دو عامل (agent) پاسخ می‌دهد، به حافظه بیشتری نسبت به همان سرور در حالت پاسخ‌دهی به یک عامل نیاز دارد.

به عدد رم ذکر شده در هیچ راهنمایی، از جمله همین متن، اکتفا نکنید. تگ را دریافت کنید، یک پرامپت به آن بفرستید و در حالی که مدل هنوز در حافظه مقیم است، این دو دستور را اجرا کنید:

ollama ps
free -h

دستور ollama ps نشان می‌دهد چه چیزی در حال حاضر بارگذاری شده و کار چگونه بین CPU و GPU تقسیم شده است. دستور free -h میزان باقی‌مانده را نمایش می‌دهد. این دو خروجی در سرور شخصی شما، از هر جدول منتشرشده‌ای دقیق‌تر هستند، زیرا تنظیمات کانتکست، کوانتیزاسیون و سایر سرویس‌های در حال اجرای شما را نیز لحاظ کرده‌اند.

دیسک بخش ساده‌تر ماجراست. Ollama مدل‌ها را در مسیر /usr/share/ollama/.ollama/models در لینوکس ذخیره می‌کند که در اکثر ایمیج‌های VPS روی فایل‌سیستم ریشه (root) قرار دارد. یک پارتیشن ریشه 40 گیگابایتی، نسخه bf16 با حجم 57 گیگابایت را در خود جای نمی‌دهد و دو تگ 8-بیتی را نیز نمی‌تواند همزمان نگهداری کند. پیش از دریافت هر فایلی، محل ذخیره‌سازی را به یک 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 باید مالک آن دایرکتوری باشد، زیرا سرویس با نام کاربری ollama اجرا می‌شود و blobها را با همان دسترسی می‌نویسد. اگر عملیات pull به دلیل مجوزها با شکست مواجه شد، دلیل آن در journalctl -u ollama -n 50 قابل مشاهده است.

در مورد Swap باید یک نکته صریح را در نظر داشت: Swap به شما اجازه نمی‌دهد تگ بزرگ‌تری را اجرا کنید. فرآیند تولید متن (Generation) برای هر توکنی که تولید می‌کند، وزن‌ها را فراخوانی می‌کند؛ بنابراین وزن‌هایی که در Swap قرار دارند، دائماً از روی دیسک خوانده می‌شوند. در این حالت vmstat 1 ستون‌های si و so را مشغول نشان می‌دهد و سرعت خروجی به چند ثانیه برای هر توکن کاهش می‌یابد. یک فایل Swap کوچک به عنوان بیمه در برابر OOM Killer (قاتل حافظه) داشته باشید. رم را متناسب با تگی که واقعاً قصد استفاده از آن را دارید، انتخاب کنید.

نصب Ollama و پین کردن یک تگ مشخص

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

اسکریپت نصب، یک سرویس systemd ایجاد می‌کند تا سرور پس از reboot به‌طور خودکار بالا بیاید. اگر ترجیح می‌دهید آن را به‌عنوان یک سرویس تحت مدیریت root اجرا نکنید، اجرای Ollama به‌صورت rootless با Podman این مسیر را پوشش می‌دهد. سپس یک تگ مشخص را pull کنید.

ollama pull muse-glimmer:30b
ollama list

ستون اندازه را در ollama list شخصاً بررسی کنید و آن را با لیست تگ‌های فعلی در صفحه مدل مقایسه نمایید. تگ‌های منتشرشده اضافه، تغییر نام یا حذف می‌شوند و اندازه ذکرشده در راهنما، تنها تصویری از وضعیت در یک روز خاص است.

هرگز از ollama pull muse-glimmer روی سروری که به آن وابسته‌اید استفاده نکنید. نام خام مدل به تگ latest اشاره می‌کند و latest اشاره‌گری است که ناشر می‌تواند آن را به build متفاوتی تغییر دهد. در این صورت، یک pull معمولی باعث می‌شود مدل زیر پای agent شما عوض شود، که ممکن است نیازهای حافظه و رفتار متفاوتی داشته باشد؛ بدون آنکه در لاگ‌های شما تغییری ثبت شود. تگ را در اسکریپت‌ها، فایل‌های unit و پیکربندی agent خود بنویسید. میزبانی شخصی LLM با Ollama روی VPS سایر مراحل راه‌اندازی سرور را پوشش می‌دهد.

آیا می‌توان Muse Glimmer را بدون GPU اجرا کرد؟

بله، و باید در مورد محدودیت‌های آن صریح بود. تولید هر توکن به معنای خواندن وزن‌های مدل از حافظه است، بنابراین سرعت توسط پهنای باند حافظه تعیین می‌شود، نه تعداد vCPUهایی که در پلن تبلیغ شده است. فراتر از چند هسته، افزایش تعداد هسته‌ها تأثیر بسیار ناچیزی دارد. در یک VPS اشتراکی، این پهنای باند با سایر مستأجران روی میزبان مشترک است، بنابراین یک مدل 30B با کوانتایز 4-bit، تعداد کمی توکن در ثانیه تولید می‌کند.

عدد هیچ‌کس را برای این موضوع نپذیرید، حتی عدد من را. تعداد توکن در ثانیه را روی سیستم خودتان اندازه‌گیری کنید و بر اساس آنچه می‌بینید تصمیم بگیرید.

نتیجه، شکافی واقعی در کاربرد این مدل است. چت تعاملی آزاردهنده است، زیرا سرعت خواندن شما از سرعت نوشتن سرور بیشتر است و هر پاسخ با یک وقفه طولانی شروع می‌شود. کارهای پس‌زمینه (agent work) مشکلی ندارند، زیرا برای وظیفه‌ای که ده دقیقه بدون نظارت اجرا می‌شود، کند بودن اهمیتی ندارد. این نوع دوم از بار کاری، دقیقاً همان چیزی است که Meta برای این مدل توصیف می‌کند.

اگر به سرعت تعاملی نیاز دارید، دو پاسخ صادقانه وجود دارد: استفاده از GPU یا یک API میزبانی‌شده. پیش از اجاره هر چیزی، نقطه سربه‌سر بین یک VPS دارای GPU و توکن‌های API را محاسبه کنید و آنچه یک VPS دارای GPU واقعاً به شما می‌دهد را مطالعه کنید تا بدانید دقیقاً چه چیزی خریداری می‌کنید. برای پرسش کلی‌تر درباره اینکه یک سیستم خاص چه مدلی را می‌تواند پشتیبانی کند، از مدل‌هایی که می‌توانید خودتان میزبانی کنید شروع کنید و اجرای یک مدل Qwen با اندازه مشابه روی VPS نزدیک‌ترین مقایسه در این کلاس اندازه است.

چرا مدل خیلی زودتر از 128 هزار توکن، مطالب را فراموش می‌کند؟

دلیل این است که پنجره کانتکست پیش‌فرض در Ollama، صرف‌نظر از ظرفیت مدل، 4096 توکن است. این مقدار پیش‌فرض طبق FAQ رسمی Ollama تا اوت 2026 همچنان معتبر است. اگرچه تگ مدل عدد 128 هزار را تبلیغ می‌کند، اما سرور تا زمانی که شما دستور دیگری ندهید، تنها 4096 توکن به مدل تحویل می‌دهد؛ در نتیجه، در یک گفتگوی طولانی با ایجنت، بخش‌های ابتدایی از حافظه خارج شده و مدل دچار فراموشی می‌شود.

برای هر درخواست، این مقدار را در سمت سرور افزایش دهید:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

در یک نشست تعاملی، دستور /set parameter num_ctx 32768 این مقدار را فقط برای همان نشست تغییر می‌دهد. در صورت استفاده از API، باید num_ctx را در گزینه‌های درخواست (request options) ارسال کنید.

هر توکن اضافه در کانتکست، علاوه بر وزن‌های مدل، حافظه اشغال می‌کند. اگر درخواست 128 هزار توکن کامل را روی سیستمی ارسال کنید که فقط برای بارگذاری وزن‌ها ظرفیت دارد، فرآیند با خطا مواجه شده یا به حالت کندتری سوئیچ می‌کند. مقدار را به‌صورت مرحله‌ای افزایش دهید و پس از هر مرحله ollama ps را اجرا کنید. مطلب نحوه عملکرد num_ctx و طول کانتکست در Ollama محاسبات مربوط به این موضوع را به‌طور کامل توضیح می‌دهد.

سطوح قدرت استدلال: low، medium، high و xhigh

متا چهار سطح قدرت استدلال برای Muse Glimmer تعریف کرده است که از low تا xhigh متغیر هستند و برای وظایف پیچیده کدنویسی و عاملیت (agent)، دو سطح بالاتر را توصیه می‌کند. در Ollama، این قابلیت از طریق پارامتر think کنترل می‌شود. از --think= در خط فرمان استفاده کنید یا think را در بدنه API ارسال نمایید.

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

در یک نشست تعاملی، /set think و /set nothink این قابلیت را تغییر می‌دهند. مستندات Ollama بیان می‌کند که اکثر مدل‌ها یک مقدار بولی یا سطحی مانند low، medium یا high را می‌پذیرند و برخی نیز برای بالاترین سطح موجود، max را قبول می‌کنند. رشته‌های دقیقی که این مدل می‌پذیرد در صفحه اختصاصی همان مدل ذکر شده است؛ بنابراین به‌جای حدس زدن، آن را مطالعه کنید و پیش از پیاده‌سازی در یک عامل، ابتدا به‌صورت دستی آن را آزمایش کنید.

در سیستمی که فقط از CPU استفاده می‌کند، این تنظیم تأثیر قابل‌توجهی دارد. قدرت بالاتر به معنای تولید توکن‌های تفکر بیشتر پیش از ظاهر شدن اولین کلمه پاسخ است و هر توکن تفکر، همان مقدار زمان واقعی (wall clock time) را نسبت به یک توکن پاسخ مصرف می‌کند. کارهای روتین را روی تنظیم low قرار دهید.

نگه داشتن مدل در حافظه برای یک عامل همیشه فعال

Ollama به‌صورت پیش‌فرض مدل‌های غیرفعال را پس از پنج دقیقه از حافظه خارج می‌کند. برای عاملی که هر ده دقیقه اجرا می‌شود، این یعنی در هر بار اجرا باید حجم کامل 18 گیگابایت از دیسک بارگذاری شود؛ در یک VPS با حافظه متصل به شبکه (NAS)، این بارگذاری سریع نیست. به‌جای آن، مدل را در حافظه ثابت (Pin) کنید.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

یک مقدار منفی باعث می‌شود مدل تا زمانی که عاملی دیگر آن را خارج نکند، در حافظه باقی بماند و استفاده از keep_alive در یک درخواست API، مقدار پیش‌فرض سرور را برای همان یک فراخوانی نادیده می‌گیرد. هزینه این کار مشخص است: RAM در حالی که هیچ پردازشی انجام نمی‌شود اشغال می‌ماند، بنابراین این تنظیم برای سروری مناسب است که به آن عامل اختصاص داده شده است. مطلب نگه داشتن مدل Ollama در حافظه به بررسی حالت‌های مختلف این موضوع می‌پردازد.

اتصال یک ایجنت برنامه‌نویسی به آن

Ollama یک API سازگار با OpenAI در http://127.0.0.1:11434/v1 ارائه می‌دهد، بنابراین اکثر ابزارهای ایجنت با یک base URL و هر API key غیرخالی به آن متصل می‌شوند. صفحه Muse Glimmer در Ollama همچنین یک میان‌بر راه‌اندازی را مستند کرده است که یک ایجنت پشتیبانی‌شده را با یک دستور به مدل محلی متصل می‌کند؛ شما باید تگ مربوطه را نیز در آنجا پین کنید.

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

ایجنت‌ها پرامپت‌های بزرگی ارسال می‌کنند. محتوای فایل‌ها، خروجی ابزارها و متن در حال رشد گفتگو، همگی به عنوان توکن‌های ورودی وارد می‌شوند و در یک سیستم مبتنی بر CPU، پردازش پرامپت بخشی است که پیش از شروع تولید متن، باعث کندی می‌شود. تنظیمات context را تا حد امکان برای وظیفه مورد نظر کوچک نگه دارید. اتصال یک ایجنت برنامه‌نویسی به Ollama سمت کلاینت را پوشش می‌دهد، اجرای یک ایجنت برنامه‌نویسی روی VPS به سروری که ایجنت روی آن قرار دارد می‌پردازد و کنترل هزینه‌های ایجنت روی VPS توضیح می‌دهد که وقتی ایجنت در تمام طول روز اجرا می‌شود چه اتفاقی می‌افتد.

ورودی تصویر نیز به همین صورت عمل می‌کند. API مربوط به Ollama تصاویر را در فیلد images از یک پیام دریافت می‌کند، بنابراین یک کلاینت فقط متنی هرگز تصویری ارسال نخواهد کرد، فارغ از اینکه انکودر ادراکی (perception encoder) چقدر توانمند باشد.

پورت 11434 را باز نکنید

API مربوط به Ollama فاقد احراز هویت است. تنظیم OLLAMA_HOST=0.0.0.0:11434 برای دسترسی به آن از طریق لپ‌تاپ، یک مدل‌اجراگر (model runner) بدون احراز هویت را در معرض اینترنت عمومی قرار می‌دهد. در این حالت، هر کسی که آن را پیدا کند می‌تواند مدل‌ها را روی دیسک شما بارگذاری کرده و هر داده‌ای را که عامل (agent) شما از طریق آن ارسال می‌کند، بخواند. آن را روی localhost محدود نگه دارید و به جای آن از تونل استفاده کنید.

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

ایمن‌سازی نقطه پایانی API Ollama گزینه‌های مناسب، از جمله استفاده از یک reverse proxy که درخواست اعتبارنامه می‌کند را پوشش می‌دهد.

چه چیزی از کار می‌افتد و چه چیزی مشاهده خواهید کرد

عملیات pull در میانه راه متوقف می‌شود. دیسک. دستور df -h را روی دایرکتوری مدل اجرا کنید. یک build با فرمت bf16 و حجم 57 گیگابایت روی یک پارتیشن root با حجم 40 گیگابایت جا نمی‌شود؛ همچنین دو tag با فرمت 8-bit در کنار هم نیز در این فضا قرار نمی‌گیرند.

مدل بارگذاری می‌شود و سپس پردازش متوقف می‌گردد. کمبود حافظه (Out of memory). دستور dmesg -T ثبت می‌کند که kernel out of memory killer یک پردازش را انتخاب کرده است و journalctl -u ollama -n 100 سمت سرویس همان رویداد را نشان می‌دهد. راه‌حل، استفاده از یک tag کوچک‌تر یا یک num_ctx کوچک‌تر است. افزایش swap راه‌حل این مشکل نیست.

مدل با سرعت چند ثانیه برای هر توکن اجرا می‌شود. دستور vmstat 1 را اجرا کنید و ستون‌های si و so را زیر نظر بگیرید. فعالیت مداوم swap به این معناست که وزن‌های مدل در RAM جا نمی‌شوند و سیستم در حین کار، آن‌ها را از روی دیسک می‌خواند.

تگی که هفته گذشته کار می‌کرد، دیگر وجود ندارد. لیست تگ‌ها تغییر می‌کند. صفحه مدل را دوباره بخوانید، نسخه فعلی را pin کنید و نام تگ را در جایی یادداشت کنید که دوباره به آن دسترسی داشته باشید.

پیش از pull کردن، حجم‌ها را شخصاً دوباره بررسی کنید

حجم‌های موجود در جدول در تاریخ 16 August 2026 از صفحه تگ‌های مدل خوانده شده‌اند و لیست تگ‌های منتشرشده، تضمینی برای ثبات نیستند. لیست فعلی را در صفحه مدل بخوانید و سپس تأیید کنید که چه حجمی واقعاً روی دیسک شما قرار گرفته است:

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

نرم‌افزار Ollama لایه‌های مدل را به صورت blobهای اشتراکی ذخیره می‌کند، بنابراین دو تگ که یک لایه مشترک دارند، دو برابر فضای دیسک اشغال نمی‌کنند. آنچه du گزارش می‌دهد را با حجم منتشرشده مقایسه کنید و فضای دیسک خود را بر اساس مقدار بزرگ‌تر برنامه‌ریزی کنید.

FAQ

Muse Glimmer روی یک VPS به چه مقدار RAM نیاز دارد؟

از اندازه تگ شروع کنید و پنجره context را به آن اضافه کنید. تگ پیش‌فرض در تاریخ 16 August 2026 حدود 18 GB ذکر شده است، بنابراین یک سرور 16GB اصلاً نمی‌تواند آن را بارگذاری کند و یک سرور 24GB نیز فضای بسیار کمی برای context باقی می‌گذارد. این مقدار را به عنوان نقطه شروع در نظر بگیرید، نه پاسخ نهایی. تگ را دریافت کنید، یک بار آن را بارگذاری کنید، سپس ollama ps و free -h را روی سرور خود اجرا کرده و اعداد واقعی را مشاهده کنید. context طولانی‌تر و درخواست‌های همزمان، هر دو باعث افزایش مصرف حافظه علاوه بر وزن‌های مدل می‌شوند.

آیا می‌توانم Muse Glimmer را بدون GPU اجرا کنم؟

بله. این مدل روی یک VPS که فقط CPU دارد بارگذاری شده و پاسخ می‌دهد. سرعت تولید متن توسط پهنای باند حافظه محدود می‌شود، نه تعداد هسته‌ها؛ و در یک هاست اشتراکی این پهنای باند مشترک است، بنابراین در حالت 4-bit انتظار تعداد کمی توکن در ثانیه را داشته باشید. این سرعت برای کارهای پس‌زمینه که بدون نظارت اجرا می‌شوند قابل استفاده است، اما برای چت تعاملی کند و آزاردهنده خواهد بود. در حین انجام درخواست، ollama ps را اجرا کنید و ستون پردازنده را بررسی کنید تا تأیید شود پردازش در کجا انجام می‌شود.

آیا تگ‌های MLX روی یک VPS لینوکسی کاربردی دارند؟

خیر. هر تگی که در نام خود mlx دارد، برای موتور MLX در Ollama ساخته شده است که backend مخصوص Apple Silicon است. روی یک سرور لینوکسی x86، این تگ‌ها فایل‌های حجیمی هستند که نمی‌توانید اجرا کنید. از تگ ساده 30b یا سایر تگ‌های غیر MLX استفاده کنید و بنچمارک‌های سخت‌افزاری اپل که همراه با نسخه‌های MLX ارائه می‌شوند را نادیده بگیرید.

چرا مدل قبل از رسیدن به 128K توکن، مطالب را فراموش می‌کند؟

زیرا پنجره context پیش‌فرض در Ollama صرف‌نظر از آنچه مدل پشتیبانی می‌کند، 4096 توکن است؛ بنابراین سرور مکالمات طولانی را پیش از آنکه مدل آن‌ها را ببیند، کوتاه می‌کند. مقدار OLLAMA_CONTEXT_LENGTH را در سرور تنظیم کنید، یا برای یک نشست از /set parameter num_ctx استفاده کنید، یا num_ctx را در گزینه‌های درخواست API ارسال کنید. مصرف حافظه با افزایش این مقدار بالا می‌رود، بنابراین آن را مرحله‌به‌مرحله افزایش دهید و هر بار ollama ps را بررسی کنید.

آیا باید تگ را ثابت (Pin) کنم یا فقط از latest استفاده کنم؟

آن را ثابت کنید. muse-glimmer بدون تگ به latest اشاره می‌کند که یک اشاره‌گر است و ناشر می‌تواند هر لحظه آن را به نسخه دیگری تغییر دهد؛ بنابراین یک pull معمولی می‌تواند مدلی که ایجنت شما روی آن اجرا می‌شود را تغییر دهد. در اسکریپت‌ها، unit fileها و تنظیمات ایجنت، muse-glimmer:30b را بنویسید. پیش از ثابت کردن تگ، لیست تگ‌ها را در صفحه مدل بررسی کنید، زیرا تگ‌های منتشر شده تغییر می‌کنند.