Meta випустила Muse Glimmer — це багатомодальна модель агента з приблизно 30 мільярдами параметрів, яка підтримує контекст до 128K і працює на пристроях з 24 ГБ відеопам’яті. Модель відкрита за ліцензією Apache 2.0, використовує GQA для зменшення обсягу KV Cache, поєднує гібридну архітектуру Local та Global Attention для зниження обчислювальних витрат при довгих контекстах і надає дві версії квантування для різних об’ємів відеопам’яті. Візуальний модуль оснащений окремим ViT Perception Encoder для обробки скріншотів та інформації з екрана; на етапі навчання застосовується On Policy Distillation для покриття відхилень у довгих завданнях. Компонент DFlash для прискорення висновку використовує Block Diffusion для паралельного прогнозування токенів, забезпечуючи приблизно трикратне збільшення швидкості декодування на RTX 5090. Модель демонструє відмінні результати на бенчмарках Agent, таких як MCP Atlas та DeepSearch QA, але все ще має простір для покращення у чисто GUI-сценаріях, наприклад, OSWorld Verified.

Автор статті, джерело: LeFeng.com

Вчора Meta випустила Muse Glimmer. Це багатомодальна модель агента з приблизно 30 мільярдами параметрів, яка підтримує контекст до 128K, може викликати інструменти, виконувати код, а також обробляти зображення та інформацію з екрана.

Ця модель відкрита за ліцензією Apache 2.0, а також надає дві версії з квантуванням 4bit, окремий візуальний кодек та компонент прискорення висновків DFlash, і підтримує локальне розгортання через llama.cpp, MLX, ExecuTorch тощо.

Хоча параметричний розмір 30 млрд і контекст 128K сьогодні не виглядають надзвичайними, проблема в тому, що Meta хоче, щоб він виконував не звичайний чат, а створював цілу локальну модель роботи агента.

Muse Glimmer, призначений для довгострокового виконання локальних агентів, стикається з жорсткими інженерними обмеженнями: він повинен обробляти постійно генеровані знімки екрана та одночасно підтримувати завдання, що складаються з десятків кроків, в межах обмежених 24 ГБ відеопам’яті. Після виконання завдання з десятками кроків, попередні результати інструментів, журнали коду, стан сторінки та процес міркувань постійно залишаються в контексті.

Зараз багато проблем, які не були помітні в чат-сценаріях, швидко посилюються. Як вмістити 128K контексту в обмежену пам’ять GPU? Як керувати історією стану, коли знімків стає все більше? Як модель продовжує роботу після невдалого виклику інструменту? І наскільки сильно велика кількість Reasoning Token сповільнює Decode?

Технічний дизайн Muse Glimmer заснований на розв’язанні саме цих питань. Він не спирається на якусь одну особливо помітну нову архітектуру, щоб вирішити всі проблеми, а замість цього робить радикальні компроміси в Attention, KV Cache, способах навчання, квантуванні та Decode.

Якщо ранішні локальні моделі були «просто працездатними», то мета Muse Glimmer — бути «також зручними у використанні й працювати неперервно, як хмарні».

Дивлячись на ці частини разом, легше зрозуміти, чому Meta зробила її саме такою, ніж розглядати 30B або 128K окремо.

Як вмістити 128K контексту в 24 ГБ відеопам’яті?

Muse Glimmer використовує 52 шари Dense Transformer, розмір прихованого шару 6656, 32 головки запитів, але лише 2 головки KV.

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

Local Attention обробляє лише близькі 2048 токенів, а Global Attention відповідає за обмін інформацією на більш віддалених відстанях.

Обидва ці дизайни одночасно збільшують вартість довгого контексту. Під час генерації нових токенів модель кешує Key і Value попередніх токенів, тобто KV Cache. Чим довший контекст, тим більше пам’яті він займає.

У Muse Glimmer на кожному рівні лише 2 KV-головки, розмір кожної головки — 128. За наближеним розрахунком у BF16, один токен на рівні займає приблизно 1024 байти KV.

Якщо всі 52 шари зберігають повний контекст 128K, KV Cache приблизно потребує 6,5 ГіБ. Але Muse Glimmer фактично має 39 локальних шарів і 13 глобальних шарів. Локальні шари повинні зберігати лише ковзаюче вікно приблизно з 2048 токенів, лише глобальні шари потребують збереження повного довгого контексту.

За тим самим методом оцінки KV-кеш може зменшитися до рівня приблизно 1,7 ГіБ. Це не офіційно опубліковані дані про використання пам’яті під час виконання, а лише теоретична оцінка на основі відкритих архітектурних параметрів, але вона вже пояснює, чому ця структура була спроектована саме так.

Якщо він не використовує 2 KV-головки, а зберігає окремі KV для всіх 32 головок, як у традиційній MHA, то за тих самих умов KV Cache теоретично збільшиться ще приблизно в 16 разів, досягнувши понад 20 ГіБ.

Один лише KV Cache вже перевищує обсяг відеокарти на 24 ГБ. Тут використовуються два підходи. GQA зменшує кількість KV, які потрібно зберігати для кожного токена, а Local Attention зменшує кількість шарів, для яких потрібно довгостроково зберігати повні KV.

Після виконання цього кроку квантування ваг має сенс. Вага Muse Glimmer з K Quant 17GB становить приблизно 16,8 ГБ, візуальний модуль — близько 1,4 ГБ, DFlash — 1,6 ГБ, разом ці частини вже наближаються до 20 ГБ. Ця версія призначена для пристроїв з 24 ГБ відеопам’яті, а інша версія з Dynamic K Quant об’ємом близько 20 ГБ — для пристроїв з 32 ГБ.

Дві квантові системи відрізняються не лише розміром файлів. Середній втрати точності з 15 тестів Benchmark від Meta: Dynamic K Quant становить приблизно 0,2%, а K Quant 17 ГБ — приблизно 1,0%.

Тобто версія з 24 ГБ додатково зменшує обсяг відеопам’яті, займаючи менше місця, але вимагає прийняття трохи більш помітної втрати продуктивності. Версія з 32 ГБ намагається зберегти початкову продуктивність моделі.

Контекст 128K Muse Glimmer досягається саме такою комбінацією. Спочатку Attention зменшує обчислювальну навантаженість, потім GQA зменшує KV Cache, а на останньому етапі застосовується квантування для зменшення ваг моделі.

Цей підхід також має свої витрати. 39 шарів Local можуть безпосередньо отримувати доступ лише до сусідніх 2048 токенів; інформація на великих відстанях повинна поширюватися через шар Global. Тому здатність вводити 128K і здатність стабільно використовувати весь обсяг у 128K — це не одне й те саме.

Результати Meta Beam128K показують, що гібридна структура Local і Global все ще добре використовує довгострокову інформацію, але вона вирішує проблему Long Context, а не довгострокової пам’яті. Яка інформація повинна зберігатися, яка вже застаріла та коли оновлювати стан, все це все ще потребує обробки Agent Runtime.

Ця проблема буде ще більш помітною на візуальному агенті.

128K — це не безмежний простір

Muse Glimmer також має ViT G 14 Perception Encoder з приблизно 1,8 мільярда параметрів, який обробляє знімки екрана, веб-сторінки, діаграми та документи. Один зображення може бути перетворено на максимальну кількість 4096 візуальних токенів.

Зараз це текстовий та зображення вхід, текстовий вихід, а не всі модальності в одній генераційній моделі.

У робочому потоці агента ця візуальна здатність відповідає за читання стану середовища. Агент Computer Use спочатку бачить поточний екран, визначає розташування сторінки, кнопок і тексту, а потім виконує одну дію. Після зміни сторінки він знову читає новий знімок і продовжує вирішувати наступний крок.

Отже, візуальні вхідні дані постійно надходять до контексту. Якщо зберігати всі знімки екрана з десятків кроків, навіть при 128K контекст швидко заповниться візуальними токенами. Старі знімки можуть суперечити поточному стану. Сторінка вже змінилася, але попередні кнопки та вікна все ще залишаються в контексті, і модель повинна додатково визначати, який із них є найновішим станом.

Meta також не зберігає історію скріншотів безмежно в оцінці OSWorld Verified, а лише останні частини скріншотів. Це свідчить про те, що Perception Encoder та Context Management — це дві різні проблеми.

Перший відповідає за перетворення поточного екрану на інформацію, зрозумілу моделлю, а другий — визначає, які історичні стани ще мають цінність, а які слід видалити. Тому 128K більше схоже на надання агенту більшого робочого простору, ніж на скасування управління станом.

А коли агент постійно взаємодіє з оточенням, питання починають зміщуватися з того, що бачить модель, на те, що модель лише що зробила.

Тепер переходимо до тренувальної частини Muse Glimmer.

Як продовжити, після того як агент відхилився

Muse Glimmer відфільтровано з більшого Muse Spark.

Meta розділяє навчання на Pre Training, Mid Training і Post Training. Pre Training використовує Logit Distillation, Mid Training додає більше даних з довгим контекстом, ланцюжками міркувань та агентів, а Post Training додає SFT, On Policy Distillation і RL.

Logit Distillation відрізняється від звичайного навчання малої моделі за допомогою відповідей великої моделі. Коли вчитель прогнозує наступний токен, він надає ймовірнісний розподіл по всьому словнику. Студент вивчає не лише остаточно вибраний токен, а й відносні оцінки вчителя щодо інших кандидатів.

Це корисно для агента, оскільки багато сценаріїв не мають єдиного дії. Перед веб-сторінкою модель може продовжити пошук, відкрити певний результат або використати інший інструмент. Розподіл ймовірностей вчителя містить його уподобання щодо цих дій, а не лише остаточний вивід тексту.

На етапі Mid Training навчання переходить від одиночних відповідей до повних траєкторій завдань. Після виконання інструменту середовище змінюється: пошук повертає нові результати, виконання коду зазнає невдачі і виводить помилки, неправильне клікнення у GUI змінює сторінку. Іншими словами, вихід агента безпосередньо змінює наступний вхід.

Припустимо, що правильна траєкторія вчителя — це A до B, потім до C, і нарешті до D. Якщо учень завжди вчиться лише на даних вчителя, він постійно бачитиме A до B, B до C. Але під час реального виконання учень може на першому кроці потрапити в інше стан B.

З цього моменту середовище змінилося, і те, що було навчено в тренувальному наборі від B до C, не може безпосередньо підказати йому, як зараз діяти. On Policy Distillation саме тут відіграє свою роль. Студент спочатку виконує Rollout самостійно, потрапляючи в ті стани, які він справді згенерує, а потім отримує нагляд від більш потужної моделі саме в цих станах.

Тому в тренувальних даних з’являються не лише ідеальні маршрути вчителя, а й помилкові стани, які сам студент може створити. Це пов’язано з акцентом Muse Glimmer на відновленні після невдач.

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

Тому здатності агента не можна оцінювати лише за тим, чи був правильно виконаний окремий виклик інструменту, але й за тим, чи вдається завершити всю задачу в цілому, а також чи здатний агент відновитися після помилок на проміжних етапах. Це пояснює, чому Muse Glimmer показує кращі результати на деяких довгих бенчмарках агентів.

Проте здатність завершити завдання не означає, що локальний запуск не має проблем. Якщо складне завдання має генерувати велику кількість Reasoning Token, новим обмеженням швидко стане Decode.

Два питання одне за одним

Muse Glimmer підтримує чотири рівні сили міркувань: low, medium, high, xhigh. Цю налаштування можна розуміти як бюджет міркувань під час виконання.

Вищі рівні зазвичай призводять до генерації більшої кількості Reasoning Token, що може підвищити успішність у складних завданнях з кодування та агентів, але це має прямі витрати: контекст зростає швидше, а час декодування збільшується.

Meta використовує high Reasoning Strength у публічному Benchmark. Це призвело до появи DFlash.

Декодування Transformer є авторегресивним. Другий токен повинен чекати на перший токен, третій залежить від другого. Для відповідей з кількома сотнями токенів це прийнятно, але агент під час однієї задачі може накопичити тисячі або навіть десятки тисяч токенів.

Підхід speculative decoding полягає у додаванні меншої моделі-чернетки. Модель-чернетка спочатку передбачає наступний рядок токенів, а потім основна модель перевіряє їх одразу. Якщо кілька кандидатів можуть бути послідовно прийняті, це зменшує кількість кроків декодування, які виконує основна модель розміром 30B.

Проблема традиційних підходів полягає в тому, що сам Drafter зазвичай є автогрегресивною моделлю. Якщо він має сгенерувати 16 токенів, все одно повинен робити це по одному.

DFlash замінив цей фрагмент на Block Diffusion.

Розмір блоку DFlash у Muse Glimmer становить 16, що дозволяє паралельно передбачати групу кандидатів у токенах. Але Drafter однієї швидкості замало. Якщо передбачення неточні, основна модель відхилятиме багато кандидатів, і попередня перевага у швидкості швидко зникне.

Тому DFlash також безпосередньо читає Hidden Feature з 1-, 13-, 25-, 37- та 49-го рівнів Muse Glimmer і передає ці проміжні представлення Drafter, який має лише 5 рівнів. Таким чином, Drafter не повинен самостійно заново розуміти повний контекст, а просто використовує внутрішні представлення, сформовані основною моделлю на 30B.

Ці функції використовуються не лише один раз на вхідному етапі, а постійно ін'єкціюються в ключі та значення всіх шарів Drafter, щоб уникнути поступового ослаблення зі збільшенням глибини мережі.

Під час навчання є ще один нюанс. У 16-токенному блоку ранні токени важливіші за пізні. Якщо перший токен помилковий, навіть якщо подальші вгадано правильно, довжина послідовного прийняття буде дуже короткою.

Тому DFlash надає більший Loss Weight токенам перед Block, а потім поступово зменшує його. Він оптимізує максимально довгий прийнятний префікс, а не просто прагне до середньої точності на 16 позиціях. У наборі даних K Quant 17 ГБ від Meta швидкість декодування на RTX 5090 зросла з приблизно 74,9 токена/с до 233,4 токена/с.

Якщо агентське завдання накопичує 10 000 токенів, то при використанні лише Decode перше займе приблизно 134 секунди, а друге — близько 43 секунд. У реальних завданнях також враховуються Prefill, виконання інструментів та очікування мережі, але для агентів з високою Reasoning Strength ця різниця вже суттєво впливає на загальний досвід виконання завдання.

Висока сила міркувань збільшує кількість згенерованих токенів, DFlash відповідає за скорочення цього часу. Довгий контекст збільшує KV Cache, GQA та Local Attention зменшують використання пам’яті. Квантування продовжує утримувати ваги моделі в межах, які підходять для споживчих відеокарт.

Крім того, Muse Glimmer добре впоралася з такими бенчмарками агентів, як MCP Atlas, DeepSearch QA та Gaia2. Ці завдання вимагають довгих ланцюжків виконання.

MCP Atlas має моделі вибирати та викликати інструменти між кількома MCP-серверами. DeepSearch QA потребує постійного пошуку, відкриття сторінок, пошуку інформації та продовження виконання на основі нових результатів. Gaia2 імітує станові додатки, такі як пошта, календар та контакти, а середовище саме змінюється в процесі виконання завдання.

Ці завдання добре відповідають методам навчання Muse Glimmer. Однак у OSWorld Verified, TerminalBench та SWE Bench Verified він не зберігає такої ж переваги. Наприклад, у OSWorld Verified Muse Glimmer набрав 65,9, а Qwen3.6 27B — 75,6. У TerminalBench 2.1 Muse Glimmer має 51,7, тоді як суперник досяг 60,7.

Тому розподіл її здібностей досить чіткий. Research Agent, співпраця з інструментами та завдання з довгими процесами мають вищу продуктивність, тоді як сценарії з чистим GUI, терміналом та частиною Coding Agent ще мають значний потенціал для покращення. Ці бали не слід розуміти строго за традиційними рейтингами моделей.

Результати Agent Benchmark також можуть впливати System Prompt, визначення інструментів, Scaffold, максимальна кількість кроків виконання, параметри вибірки навіть Judge Model. Meta сама зазначає, що інструменти Agent та System Prompt, використовувані сторонніми моделями, можуть не бути оптимізовані саме для них.

Тоже саме стосується етапу Agent — порівнювати окремі checkpoint’и все складніше, щоб повністю оцінити ситуацію. Безпека — це аналогічна проблема.

Локальне виконання дійсно зменшує частоту надсилання файлів, скріншотів та приватного контексту до хмари, але це вирішує лише шлях даних. Ризики, пов’язані з ін’єкцією запитів, помилковими викликами інструментів, перевищенням прав та незворотними операціями залишаються. Meta також окремо оцінила агентні ризики, конфіденційність та ін’єкції запитів і рекомендує при реальному розгортанні продовжувати додавати захисні механізми та необхідний Human in the Loop.

Чітка доріжна карта здібностей

Повний технічний шлях Muse Glimmer в кінцевому підсумку може бути об’єднаний у досить чітку ланцюжок.

Розмір моделі обмежено приблизно 30 млрд, GQA та Local Attention зменшують витрати пам’яті GPU для контексту 128K, квантування дозволяє запускати модель на пристроях з 24 ГБ та 32 ГБ пам’яті, Perception Encoder відповідає за читання візуального середовища, On-Policy Distillation виправляє відхилення станів у довгих завданнях, Reasoning Strength надає розробникам контроль над бюджетом міркувань, а DFlash обробляє затримки декодування, спричинені великою кількістю токенів міркувань.

Muse Glimmer не довела, що локальна модель на 30 млрд може замінити хмарні Frontier Model, але вона продемонструвала, що фінальна мета локальної моделі на 30 млрд — не просто масштаб, а системне інженерне рішення, що комплексно компенсує різні жорсткі обмеження. Вона вже об’єднала в одній системній архітектурі чотири найскладніші обмеження локального агента: пам’ять GPU, контекст, сприйняття стану середовища та швидкість міркування.

Muse Glimmer, хоча ще не може повністю замінити хмарні флагманські моделі, вже проклали шлях до промислового впровадження мети «кожен має власний агент».