اجرای مدل Muse Glimmer 30B روی VPS بدون GPU

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

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

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

کدام تگ muse-glimmer را باید 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 تعداد 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 هستند و حجم هر کدام از نسخه مشابه و سادهٔ خود بیشتر است. 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 را فیلتر کنید و سپس از میان موارد باقی‌مانده، گزینه مناسب را بر اساس حجم انتخاب کنید.

واقعاً به چه مقدار RAM و دیسک نیاز است؟

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

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

ollama ps
free -h

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

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

نصب 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 نزدیک‌ترین مقایسه در این کلاس وزنی است. اگر اعدادی که اندازه‌گیری می‌کنید برای استفاده روزمره بیش از حد کند هستند، Nemotron 3.5 Lightning on a VPS همان پرسش‌های مربوط به RAM و توکن در ثانیه را برای مدلی که برای سرعت ساخته شده تا اندازه، مطرح می‌کند.

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

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

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

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

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

هر توکن اضافه در کانتکست، علاوه بر وزن‌های مدل، حافظه مصرف می‌کند. اگر درخواست 128K کامل را روی سیستمی ارسال کنید که فقط برای بارگذاری وزن‌ها ظرفیت دارد، فرآیند با خطا مواجه شده یا به حالت کندتری بازمی‌گردد. مقدار را به‌صورت مرحله‌ای افزایش دهید و پس از هر مرحله 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 قرار دهید. طول پاسخ نیز نیازمند دقت مشابهی است؛ بنابراین به‌جای اجازه دادن به یک پاسخ طولانی برای اشغال کردن یک سیستم کند به مدت چندین دقیقه، پاسخ را با num_predict محدود کنید.

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

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

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

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

Ollama یک API سازگار با OpenAI در http://127.0.0.1:11434/v1 ارائه می‌دهد، بنابراین اکثر ابزارهای ایجنت با یک URL پایه و هر کلید API غیرخالی به آن متصل می‌شوند. صفحه 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 به گونه‌ای که بتوانید از لپ‌تاپ خود به آن دسترسی داشته باشید، یک اجراکننده مدل بدون احراز هویت را در معرض اینترنت عمومی قرار می‌دهد. در این حالت، هر کسی که آن را پیدا کند می‌تواند مدل‌ها را روی دیسک شما بارگذاری کرده و هر آنچه را که ایجنت شما از طریق آن ارسال می‌کند، بخواند. آن را روی localhost محدود نگه دارید و به جای آن از تونل استفاده کنید.

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

آیا تگ‌های 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 معمولی می‌تواند مدلی که عامل (agent) شما روی آن اجرا می‌شود را تغییر دهد. در اسکریپت‌ها، unit fileها و پیکربندی عامل، muse-glimmer:30b را بنویسید. پیش از ثابت کردن تگ، لیست تگ‌ها را در صفحه مدل بررسی کنید، زیرا تگ‌های منتشرشده تغییر می‌کنند.