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, а также включает две версии с квантованием 4-bit, отдельный визуальный энкодер и компонент ускорения вывода DFlash, с поддержкой локального развертывания через llama.cpp, MLX, ExecuTorch и другие инструменты.

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

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

В этот момент многие проблемы, которые ранее не были очевидны в чат-сценариях, быстро усиливаются. Как вписать 128K контекста в ограниченную видеопамять? Как управлять историей состояний, когда скриншотов становится все больше? Как модель должна продолжать работу после неудачного вызова инструмента? И насколько сильно大量 Reasoning Token замедляют декодирование?

Технический дизайн Muse Glimmer в основном сосредоточен на этих вопросах. Он не полагается на какую-либо одну особенно заметную новую архитектуру для решения всех задач, а вместо этого делает радикальные компромиссы в Attention, KV Cache, методах обучения, квантовании и декодировании.

Если раньше локальные модели были просто «работоспособными», то цель 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-кэш потребует примерно 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 ГБ видеопамяти, а другая версия с весом около 20 ГБ Dynamic K Quant — для устройств с 32 ГБ.

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

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

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

Этот подход также имеет свои издержки. 39 локальных слоев могут напрямую обращаться только к ближайшим 2048 токенам; информация на больших расстояниях должна передаваться через глобальный слой. Следовательно, возможность ввода 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 разделяет обучение на предварительное обучение, среднее обучение и последующее обучение. Предварительное обучение использует логит-дистилляцию, среднее обучение добавляет больше данных с длинным контекстом, следами рассуждений и агентами, а последующее обучение включает SFT, он-политик дистилляцию и 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 показывает лучшие результаты на некоторых долгих бенчмарках агентов.

Однако выполнение задачи не означает, что локальный запуск не имеет проблем. Если сложная задача требует генерации большого количества токенов рассуждений, новым узким местом быстро станет декодирование.

Два вопроса один за другим

Muse Glimmer поддерживает четыре уровня силы рассуждений: low, medium, high, xhigh. Эта настройка может быть понята как бюджет рассуждений во время выполнения.

Более высокий уровень обычно заставляет модель генерировать больше токенов рассуждений, что может повысить成功率 в сложных задачах по программированию и агентных задачах, но цена также прямая: контекст растет быстрее, а время декодирования увеличивается.

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

Декодирование Transformer является авторегрессивным. Второй токен должен ждать первый, третий зависит от второго. Для ответа в несколько сотен токенов это приемлемо, но один запрос агента может накопить тысячи или даже десятки тысяч токенов.

Метод спеулятивного декодирования заключается в добавлении более мелкой модели-черновика. Черновик сначала предсказывает следующую последовательность токенов, после чего основная модель проверяет их все сразу. Если несколько кандидатов могут быть последовательно приняты, это снижает количество шагов декодирования, выполняемых основной моделью размером 30 млрд.

Проблема традиционных подходов заключается в том, что сам Drafter обычно также является авторегрессивной моделью. Если ему нужно сгенерировать 16 токенов, он всё равно должен создавать их по одному.

DFlash заменил это на Block Diffusion.

Размер блока DFlash у Muse Glimmer составляет 16, что позволяет параллельно предсказывать группу кандидатов в токенах. Но Drafter должен быть не только быстрее — если предсказания неточны, основная модель будет отклонять большое количество кандидатов, и преимущество в скорости быстро исчезнет.

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

Эти функции используются не только один раз на входе, а постоянно встраиваются в ключи и значения всех слоев Drafter, чтобы избежать ослабления по мере углубления сети.

Еще один нюанс при обучении: в блоке из 16 токенов первые токены важнее, чем последующие. Если первый токен неверен, даже если последующие угаданы правильно, длина последовательности, принимаемой подряд, будет очень короткой.

Следовательно, DFlash присваивает более высокий вес потерь токенам, расположенным перед Block, и постепенно снижает его для последующих. Он оптимизирует максимально длинный приемлемый префикс, а не просто стремится к средней точности на 16 позициях. В наборе данных K Quant 17 ГБ от Meta скорость декодирования на RTX 5090 увеличилась с примерно 74,9 токена/с до 233,4 токена/с.

Если агентская задача в совокупности генерирует 10 000 токенов, то при просмотре только декодирования первая занимает примерно 134 секунды, а вторая — около 43 секунд. В реальных задачах также присутствуют префилл, выполнение инструментов и сетевые ожидания, но для агентов с высокой силой рассуждений эта разница уже значительно влияет на общий опыт выполнения задачи.

Высокая сила рассуждений увеличивает генерацию токенов, DFlash отвечает за сокращение этого времени. Длинный контекст увеличивает KV Cache, GQA и локальное внимание снижают потребление памяти. Квантование продолжает удерживать веса модели в пределах, приемлемых для потребительских видеокарт.

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

MCP Atlas требует от модели выбора и вызова инструментов между несколькими MCP Server. 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, максимального количества шагов выполнения, параметров выборки и даже модели оценки. Сама Meta отмечает, что инструменты Agent и System Prompt, используемые сторонними моделями, могут не быть оптимизированы специально для них.

Таким образом, на этапе Agent отдельное сравнение Checkpoint все труднее позволяет оценить полную картину. То же самое относится и к безопасности.

Локальное выполнение действительно снижает частоту отправки файлов, скриншотов и приватного контекста в облако, но это решает только проблему пути данных. Риски, связанные с инъекцией запросов, ошибочными вызовами инструментов, превышением прав доступа и необратимыми операциями, остаются. Meta также отдельно оценила агентные риски, конфиденциальность и инъекции запросов и рекомендует при реальном развертывании продолжать усиливать защитные механизмы и включать обязательное участие человека.

Четкий путь развития

Полный технологический путь Muse Glimmer в конечном итоге может быть объединен в достаточно четкую цепочку.

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

Muse Glimmer не доказала, что локальная модель на 30 млрд параметров может заменить облачные Frontier Model, но она продемонстрировала, что конечная цель локальной модели на 30 млрд параметров заключается не просто в масштабе, а в системном инжиниринге, обеспечивающем комплексное хеджирование различных жестких ограничений. Она уже объединила в одной системной архитектуре четыре самых сложных ограничения локального агента: память видеопамяти, контекст, восприятие состояния среды и скорость вывода.

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