Muse Glimmer 30B на VPS: RAM, диск і CPU

Що потрібно Muse Glimmer на VPS

Muse Glimmer працює на звичайному Linux VPS без GPU, а вибраний tag визначає, чи поміститься модель у пам’ять. Meta Superintelligence Labs опублікувала модель 10 August 2026 за ліцензією Apache 2.0: 30 billion параметрів, вікно контексту 128K і спеціальний perception encoder на 1.8B параметрів, який дає змогу обробляти зображення разом із текстом. Meta позиціонує її для постійно активних локальних агентів, а не для чатів; рівень reasoning задається для кожного запиту.

Опубліковані Ollama tags, перевірені 16 August 2026, мають розмір від 17 GB до 59 GB. Саме цей діапазон визначає всі вимоги до ресурсів. Для default tag вказано приблизно 18 GB, тому найменший придатний сервер має мати помітно більше ніж 18 GB вільної RAM. Додатково потрібні місце на диску для завантаження та пам’ять для вікна контексту.

Який тег muse-glimmer слід завантажити?

[
  {
    "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 мільярдів ваг, збережених із різною числовою точністю. Зазначений розмір — це обсяг завантаження. Приблизно стільки ж пам’яті потрібно утримувати до додавання будь-якого контексту.

Дві збірки з 4-бітним квантуванням є найменшими: 30b-nvfp4 обсягом 17 GB і 30b-q4_K_M обсягом 18 GB. Тег за замовчуванням 30b має такий самий розмір, як збірка q4_K_M. Збірки з 8-бітним квантуванням, 30b-q8_0 і 30b-mxfp8, мають розмір близько 31 GB. 30b-bf16 — це невантована 16-бітна версія обсягом 57 GB. Це більше RAM, ніж пропонує більшість орендованих серверів за прийнятну для побічного проєкту ціну.

Теги -dflash містять ті самі збірки з підтримкою DFlash. Кожен із них має більший розмір, ніж відповідна звичайна збірка. Ollama описує DFlash як функцію прискорення та демонструє її роботу на Apple Silicon і desktop GPU. На VPS лише з CPU ви витрачатимете додаткову реальну пам’ять на функцію, виміряну на іншому обладнанні. Тому почніть зі звичайного тегу та змінюйте лише один параметр за раз.

Почніть із 4-бітної версії, якщо немає конкретної причини цього не робити. Перехід від 4-бітної до 8-бітної версії приблизно вдвічі збільшує обсяг даних, який CPU має прочитати для кожного згенерованого токена. Через це пропускна здатність зменшується, а використання пам’яті зростає. Цей компроміс розглянуто в матеріалі яку фактичну ціну для вас мають квантування q4, q8 і fp16, а на сервері лише з CPU коротка відповідь така: починати варто лише з 4-бітної версії.

Чому теги MLX нічого не роблять на Linux-сервері

MLX — це фреймворк Apple для роботи з масивами, а рушій MLX в Ollama — його бекенд для Apple Silicon. Будь-який тег із mlx у назві призначений для цього рушія та відповідного обладнання. На x86 Linux VPS це десятки гігабайтів завантаження, які неможливо запустити. Вони лише займатимуть місце на диску. Показники швидкості в оголошенні, виміряні на Mac, стосуються саме цих тегів, тому вони також не описують роботу вашого сервера. Переглядаючи список тегів на сторінці моделі, спочатку відфільтруйте всі назви з mlx, а потім оцінюйте розмір за списком, що залишився.

Скільки RAM і дискового простору йому насправді потрібно?

Пам’ять займають дві складові, і лише одна з них залежить від розміру tag. Обсяг weights визначається tag, який ви завантажуєте. KV cache, тобто стан для кожного token, який модель зберігає під час діалогу, зростає разом із налаштованою довжиною context. У власній документації Ollama зазначено, що обслуговування паралельних запитів множить context на кількість запитів у роботі. Тому сервер, який одночасно відповідає двом агентам, потребує більше пам’яті, ніж той самий сервер для одного агента.

Не покладайтеся на значення RAM з будь-якого посібника, зокрема з цього. Завантажте tag, надішліть йому один prompt і, поки модель залишається завантаженою, виконайте ці дві команди.

ollama ps
free -h

ollama ps показує, що саме зараз завантажено і як навантаження розподіляється між CPU та GPU. free -h показує, скільки ресурсів залишилося. Ці два результати на вашому сервері точніші за будь-яку опубліковану таблицю, оскільки вони вже враховують ваші налаштування context, quantisation і все інше, що запущено на сервері.

З диском усе простіше. На Linux Ollama зберігає моделі в /usr/share/ollama/.ollama/models. У більшості образів VPS цей шлях розташований у root filesystem. Root volume на 40GB не вмістить збірку bf16 розміром 57 GB. Він також не вмістить два tag із 8-bit quantisation одночасно. Якщо ви ще не перевіряли, які файли фактично записує 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 повинен бути власником цього каталогу, оскільки service працює від імені ollama і записує туди blobs від свого імені. Якщо pull завершується помилкою прав доступу, причина буде в journalctl -u ollama -n 50.

Щодо swap потрібно чітко зазначити одне: swap не дає змоги запустити більший tag. Під час генерації система звертається до weights для кожного створеного token. Тому weights, розміщені у swap, знову й знову зчитуються з диска, vmstat 1 показує активні стовпці si та so, а швидкість виведення знижується до секунд на token. Залиште невеликий swap file як захист від OOM killer. Обсяг RAM розраховуйте для tag, який фактично плануєте використовувати.

Встановлення Ollama і фіксація іменованого тегу

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

Скрипт встановлення налаштовує службу systemd, тому сервер знову запускає її після перезавантаження. Якщо ви не хочете запускати Ollama як системну службу, якою керує root, дивіться запуск Ollama без root у Podman. Після цього завантажте явний тег.

ollama pull muse-glimmer:30b
ollama list

Самостійно прочитайте стовпчик розміру в ollama list і порівняйте його з поточним списком тегів на сторінці моделі. Опубліковані теги додаються, перейменовуються та видаляються, а розмір у посібнику є знімком стану на певний день.

Ніколи не записуйте ollama pull muse-glimmer на сервері, від якого ви залежите. Назва моделі без тегу розгортається в тег latest, а latest є вказівником, який видавець може перемістити на іншу збірку. Під час звичайного завантаження модель під вашим агентом непомітно замінюється. Вона може мати інші вимоги до пам’яті та іншу поведінку, і в журналах це не буде явно зазначено. Записуйте тег у своїх скриптах, unit-файлах і конфігурації агента. У матеріалі Самостійне розгортання LLM з Ollama на VPS описано решту налаштування сервера.

Чи можна запускати Muse Glimmer без GPU?

Так, але варто чітко розуміти обмеження. Генерація одного токена потребує зчитування ваг моделі з пам’яті, тому швидкість визначається пропускною здатністю пам’яті, а не кількістю vCPU, заявленою в тарифі. Після кількох ядер додаткові ядра майже не дають приросту. На shared VPS цією пропускною здатністю користуються всі інші орендарі хоста, тому модель 30B у форматі 4-bit генерує лише невелику кількість токенів за секунду.

Не покладайтеся на чиїсь показники, зокрема й на мої. Виміряйте кількість токенів за секунду на власному сервері і приймайте рішення за отриманими результатами.

У результаті модель має чіткий поділ за сценаріями використання. Інтерактивний чат працює незручно: ви читаєте швидше, ніж сервер виводить текст, а кожна відповідь починається з тривалої паузи. Фонові агентні завдання підходять краще, оскільки завданню, яке виконується без нагляду протягом десяти хвилин, низька швидкість не заважає. Саме такий сценарій використання Meta описує для цієї моделі.

Якщо потрібна інтерактивна швидкість, є два чесні варіанти: GPU або hosted API. Розрахуйте точку беззбитковості між GPU VPS і API-токенами до оренди сервера, а в матеріалі Що насправді дає GPU VPS описано, що саме ви купуєте. Щоб зрозуміти, яку модель може вмістити певний сервер, почніть із матеріалу Які моделі можна розгорнути на власному сервері, а Запуск моделі Qwen подібного розміру на VPS є найближчим порівнянням у цьому класі розмірів. Якщо виміряні показники виявляться надто низькими для комфортної роботи, у матеріалі Nemotron 3.5 Lightning на VPS розглянуто ті самі питання щодо RAM і кількості токенів за секунду для моделі, створеної з пріоритетом на швидкість, а не на розмір.

Чому він забуває інформацію задовго до 128K токенів?

Тому що стандартне контекстне вікно Ollama становить 4096 токенів незалежно від того, який обсяг підтримує модель. Станом на August 2026 це значення вказане у власному FAQ Ollama. Тег повідомляє про підтримку 128K, але сервер передає моделі лише 4096 токенів, доки ви не вкажете інше. Тому довгий transcript агента втрачає ранні повідомлення, і здається, що модель має амнезію.

Збільшіть це значення на сервері для кожного запиту:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

В інтерактивній сесії /set parameter num_ctx 32768 змінює значення лише для цієї сесії. Через API передайте num_ctx у параметрах запиту.

Кожен додатковий токен контексту збільшує споживання пам’яті поверх пам’яті під weights. Якщо запитати повні 128K на сервері, розрахованому лише на weights, завантаження завершиться помилкою або система перейде на повільніший режим. Збільшуйте значення поетапно та після кожного кроку запускайте ollama ps. У розділі Як працюють num_ctx і довжина контексту в Ollama наведено відповідні розрахунки.

Сила міркування: low, medium, high і xhigh

Meta документує чотири рівні сили міркування для Muse Glimmer: від low до xhigh, і рекомендує два найвищі рівні для складних завдань із написання коду та агентів. В 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, цей параметр суттєво впливає на час відповіді. Вищий рівень означає, що перед появою першого слова відповіді буде згенеровано більше токенів міркування. Токен міркування займає стільки ж реального часу, скільки токен відповіді. Для звичайних завдань залишайте рівень low. Довжина відповіді також потребує контролю, тому обмежуйте відповідь параметром num_predict, щоб одна надто довга відповідь не займала повільний сервер кілька хвилин.

Залиште модель завантаженою для агента, який працює постійно

Ollama за замовчуванням вивантажує неактивну модель через п’ять хвилин. Для агента, який запускається кожні десять хвилин, це означає повне завантаження 18 GB з диска під час кожного запуску. На VPS із мережевим сховищем це займає багато часу. Натомість зафіксуйте модель у пам’яті.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Від’ємне значення залишає модель у пам’яті, доки її не буде вивантажено іншим процесом або командою, а keep_alive в API-запиті перевизначає значення сервера лише для цього виклику. Компроміс очевидний: RAM залишається зайнятою, навіть коли нічого не відбувається. Тому цей параметр призначений для сервера, виділеного під агента. У розділі Як залишити модель Ollama завантаженою описано варіанти налаштування.

Налаштуйте coding agent для роботи з ним

Ollama надає OpenAI-сумісний API за адресою http://127.0.0.1:11434/v1, тому більшість інструментів для agent підключаються за допомогою базової URL-адреси та будь-якого непорожнього API key. На сторінці Ollama Muse Glimmer також описано скорочену команду запуску, яка підключає сумісний agent до локальної моделі однією командою. У цій команді також слід явно вказати tag.

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

Agents надсилають великі prompt. Вміст файлів, результати роботи інструментів і transcript, що постійно збільшується, надходять як input tokens. На CPU-сервері саме обробка prompt створює найбільше навантаження ще до початку генерації. Зменште параметр context настільки, наскільки це дозволяє завдання. У матеріалі Підключення coding agent до Ollama описано налаштування на стороні клієнта, у матеріалі Запуск coding agent на VPS — сервер, на якому він працює, а у матеріалі Контроль витрат agent на VPS — наслідки його роботи протягом усього дня.

Введення зображень працює так само. Ollama API приймає зображення в полі images повідомлення, тому клієнт, який працює лише з текстом, ніколи не надішле зображення, незалежно від можливостей perception encoder.

Не відкривайте порт 11434

API Ollama не має автентифікації. Якщо встановити OLLAMA_HOST=0.0.0.0:11434, щоб підключатися до нього з ноутбука, у публічному інтернеті опиниться runner моделей без автентифікації. Будь-хто, хто його знайде, зможе завантажувати моделі на ваш диск і читати все, що ваш агент надсилає через нього. Залиште його прив’язаним до localhost і використовуйте тунель.

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

Захист кінцевої точки API Ollama описує належні варіанти, зокрема reverse proxy, який запитує облікові дані.

Що може зламатися і що ви побачите

Завантаження зупиняється посередині. Причина — нестача дискового простору. Виконайте df -h для каталогу моделі. Збірка bf16 обсягом 57 GB не поміститься на кореневому томі 40GB. Так само не помістяться поруч два теги у 8-бітному форматі.

Модель завантажується, а потім процес завершується. Причина — нестача пам’яті. dmesg -T фіксує, який процес обрав kernel out of memory 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

Скільки RAM потребує Muse Glimmer на VPS?

Почніть із розміру tag і додайте розмір контекстного вікна. Станом на 16 August 2026 default tag має розмір приблизно 18 GB, тому на сервері з 16GB він взагалі не поміститься, а на сервері з 24GB залишиться мало місця для контексту. Вважайте це початковою оцінкою, а не остаточною відповіддю. Завантажте tag, один раз завантажте його в пам’ять, потім виконайте ollama ps і free -h на власному сервері та перегляньте отримані значення. Довший контекст і паралельні запити додатково збільшують споживання пам’яті поверх обсягу weights.

Чи можна запускати Muse Glimmer без GPU?

Так. Модель завантажується та генерує відповіді лише на CPU VPS. Швидкість генерації обмежена пропускною здатністю пам’яті, а не кількістю ядер. На shared host ця пропускна здатність є спільною, тому для 4-bit очікуйте невелику кількість tokens per second. Цього достатньо для фонової роботи agent, яка виконується без нагляду, але для інтерактивного чату швидкість буде незручною. Виконайте ollama ps під час запиту та перегляньте стовпець processor, щоб перевірити, де саме виконується обробка.

Чи придатні MLX tags для Linux VPS?

Ні. Кожен tag, у назві якого є mlx, створено для MLX engine Ollama, тобто його бекенду для Apple Silicon. На x86 Linux server такі tags є великим завантаженням, яке неможливо запустити. Використовуйте звичайний 30b tag або інший tag без MLX і не зважайте на benchmarks для Apple hardware, що стосуються MLX builds.

Чому модель забуває інформацію задовго до 128K tokens?

Тому що default context window Ollama дорівнює 4096 tokens незалежно від того, який обсяг підтримує модель. Через це server обрізає довгі розмови ще до того, як модель їх побачить. Установіть OLLAMA_CONTEXT_LENGTH на server, /set parameter num_ctx для одного session або передайте num_ctx в options API request. Споживання пам’яті зростає разом із context window, тому збільшуйте його поетапно та щоразу перевіряйте ollama ps.

Чи потрібно зафіксувати tag або достатньо використовувати latest?

Зафіксуйте tag. muse-glimmer без tag розгортається в latest. Це pointer, який publisher може будь-коли перемістити на інший build, тому звичайний pull може змінити модель, яку запускає ваш agent. Записуйте muse-glimmer:30b у scripts, unit files і agent config. Перед фіксацією перевірте список tags на сторінці моделі, оскільки опубліковані tags змінюються.