
Если вы когда-нибудь смотрели на HF и не понимали, что такое DFlash, квантизация и почему одна и та же модель лежит в десяти репозиториях от десяти разных людей — или давно собирались поднять LLM у себя, но всё не находили повода — выход Muse Glimmer 30B буквально лучший момент начать.
Есть особый сорт растерянности, который накрывает вас при первой попытке запустить модель локально.
Вы находите модель на Hugging Face. Там пять репозиториев с одинаковым названием. Один весит 59 ГБ, другой 39 ГБ, третий называется GGUF, четвёртый MLX, пятый принадлежит организации, о которой вы никогда не слышали. Внутри GGUF-репозитория четырнадцать файлов. Они называются что-то вроде UD-IQ3_XXS и Q5_K_M. Никто не объясняет, какой качать. В README написано «18 ГБ RAM», у вас 32 — значит, подойдёт любой?
Не подойдёт. И самое забавное, что ничего сложного здесь нет. Это история про пропускную способность памяти, арифметическую интенсивность и горстку инженерных компромиссов, которые никто не удосуживается объяснить, потому что все считают, что вы и так в курсе. Вам не хватает буквально четырёх вопросов, чтобы понять происходящее целиком. Но, как обычно, совершенно непонятно, с какого конца заходить.
К концу статьи этот разрыв мы закроем. Вы будете понимать каждое из тех четырнадцати имён файлов, почему ваш Mac медленнее игрового ПК именно в этой задаче, и почему техника ускорения, обещавшая трёхкратный прирост, уронила производительность моей машины на 60%.
А главное — мы развернём новую модель Meta сами, подключим её к настоящему кодинг-агенту, за десять минут.
Если вы никогда не пробовали локальные модели, то скорее всего поймете о чем речь только после прочтения
Инференс при batch size 1 упирается в пропускную способность памяти, а не в вычисления. Скорость генерации ≈ пропускная способность ÷ размер модели. Из этого уравнения следует почти всё остальное.
Замерил семь квантизаций Muse Glimmer 30B на базовом MacBook Air M5. Оптимум — UD-IQ3_M: самый быстрый из замеренных и самый крупный среди быстрых.
IQ3_XXS (13,1 ГБ) оказался медленнее IQ3_M (14,1 ГБ). Ниже ~13 ГБ вы перестаёте быть bandwidth-bound, и распаковка кодбука начинает съедать экономию.
DFlash — спекулятивное декодирование от Meta — вместо заявленных 3,1× дал мне –60%. Это не баг, это машинный баланс.
32 ГБ унифицированной памяти достаточно чтобы начать. Рассказы про необходимость 128-гигабайтного M4 Max вредят распространению технологии и просто неверны.

Когда лаборатория выкладывает открытую модель, она публикует референсные веса — обычно BF16 safetensors, сырой результат обучения. Для Muse Glimmer это репозиторий на 59,6 ГБ. Дома такое никто не запускает. Он существует, чтобы исследователи могли дообучать модель, а все остальные — конвертировать.
Обе половины названия стоит разобрать, они будут попадаться постоянно.
BF16 — это «brain float 16», 16-битный формат числа. Не единственный: FP16 тоже существует и занимает те же 16 бит. Разница в том, как эти биты поделены. FP16 отдаёт 5 бит под экспоненту и 10 под мантиссу, BF16 — 8 под экспоненту и 7 под мантиссу. Проще говоря, FP16 точнее, а BF16 покрывает существенно более широкий диапазон величин.
При обучении выигрывает диапазон. Градиенты — сигналы коррекции, подправляющие веса — разбросаны по огромным масштабам, и FP16 при экстремальных значениях молча уходит в бесконечность или в ноль, тихо ломая обучение. BF16 сохраняет ту же экспоненту, что и полноценный 32-битный float, поэтому просто работает. Именно поэтому практически все современные большие модели обучаются в BF16.
Вот что означает «сырой результат обучения»: эти числа — не конвертация и не приближение чего-то другого. Они и есть модель, ровно в том виде, в каком её посчитал процесс обучения. Любой другой файл, который вы когда-либо скачаете — GGUF, MLX, любая квантизация — получен из этого путём сознательного выбрасывания информации.
Safetensors — контейнер, в котором эти числа лежат. Название буквальное. Раньше модели ездили в виде Python-pickle (.bin, .pth), а загрузка pickle может выполнить произвольный код — то есть скачать модель у незнакомца означало запустить его код у себя. Safetensors нарочито туп по сравнению: JSON-заголовок с формами тензоров, дальше сырые байты. Там просто нечему выполняться. Бонусом такая раскладка нормально ложится в mmap, поэтому загрузка быстрая.
Meta также опубликовала две квантизованные сборки GGUF — совсем другой формат контейнера, к которому мы вернёмся в следующем разделе. Пока достаточно знать, что GGUF — это формат, сделанный для того, чтобы модели реально крутить локально. Обратите внимание на именование:
Full Precision | K-Quant-Dynamic | K-Quant-17GB | |
|---|---|---|---|
Деградация | — | 0,2% | 1,0% |
Целевая память | 64 ГБ VRAM | 32 ГБ VRAM | 24 ГБ VRAM |
Не по разрядности. По бюджету памяти. Это продуктовое мышление: они выбрали две конфигурации под железо, вокруг которого проектировали модель, замерили каждую на 15 бенчмарках и опубликовали цифры. Две протестированные рабочие точки, а не меню.
Unsloth — да, те самые ребята с милым ленивцем на логотипе — опубликовали четырнадцать.
Ребята, которые начали с опенсорсной библиотеки для файнтюна, а сейчас звери в упихивании моделей в меньшее железо — вероятно, самые эффективные на рынке.
Поэтому когда выходит большая модель, Unsloth обычно одни из первых выкладывают рабочие квантизации — пока просто считайте это сжатием модели, подробно разберём в третьей части — и одни из первых замечают, что что-то не так. Их имя будет мелькать по всей статье.
Противоречия тут нет — это разделение труда, ставшее стандартом для всей экосистемы:
Лаборатория публикует референсные веса плюс пару благословлённых конфигов, лицензирует их пермиссивно и ставит на кон репутацию таблицы бенчмарков, которую только что анонсировала. Опубликовать восемь вариантов означает восемь провалидировать, а неаккуратная 2-битная сборка выставит модель дурой.
Сообщество — Unsloth, bartowski, mradermacher, mlx-community — за часы достраивает всю лестницу. Их пайплайн квантизации автоматизирован, их пользователи — от 8-гигабайтных ноутбуков до 96-гигабайтных воркстейшенов, и покрытие этого разброса и есть их продукт.
Так что когда вы видите одну модель пять раз, вы смотрите на: референсные веса, валидированные конфиги лаборатории и три проекта сообщества, закрывающие железо, под которое лаборатория не целилась.
Практическое правило: если лаборатория выпустила сборку под ваш объём памяти — начинайте с неё, к ней прилагаются измеренные цифры деградации. Если нужно встать между уровнями лаборатории — для этого и существует лестница от сообщества.
А для некоторых конфигураций — привет, владельцы Mac — сборка сообщества теоретически может выжать больше, чем всё, что выпустила лаборатория. Теоретически. Но «реальность часто разочаровывает». Насколько именно — замерим в четвёртой части.

Форматы хранят одну и ту же модель. Упакованы они под совершенно разные задачи, и разница объясняет немалую часть боли, которая вас ждёт.
Safetensors — контейнер тензоров (спасибо, кэп). Как я упоминал в первой части, это JSON-заголовок плюс сырые байты: он хранит веса и больше ничего. Чтобы это запустить, нужны файлы-соседи: config.json с гиперпараметрами, chat_template.jinja для форматирования промпта, файлы токенизатора. И нужен Python, потому что сама архитектура живёт там — в коде моделирования transformers, а не в чекпоинте. Файл инертен без экосистемы вокруг.
GGUF — самодостаточный рантайм-артефакт. Всё в одном файле: веса, гиперпараметры, словарь токенизатора, ID специальных токенов, чат-шаблон — всё в виде key-value метаданных. Никаких файлов-соседей, никакого Python. Вместо этого нужен рантайм, говорящий на GGUF — llama.cpp или что-то на его основе вроде Ollama или LM Studio. Скармливаете llama-server один путь, и оно работает.
То есть по-настоящему автономен ни один из форматов; они просто зависят от разного. Safetensors опирается на Python-экосистему, которая ставится через pip. GGUF опирается на скомпилированный C++ бинарник. Это различие сейчас доставит мне немало проблем.
Одно следствие, с которым вы точно столкнётесь:
Новым архитектурам нужен C++. В transformers новая модель приезжает как Python, который импортируется. В llama.cpp кто-то должен реализовать граф вычислений на C++ и зарегистрировать строку архитектуры. Поэтому в день релиза я получил:
error loading model: unknown model architecture: 'muse-glimmer'
Последний тегированный релиз llama.cpp был старше ровно на день, так что пришлось клонировать репозиторий и собирать из исходников — что, да, добавляет ещё один пререквизит к «просто запустить модель локально». А у всех на актуальном transformers не было ни малейшего трения.
Safetensors | GGUF | |
|---|---|---|
Содержимое | Только тензоры | Тензоры + токенизатор + шаблон + метаданные |
Точность | Обычно BF16/FP16 | Здесь живёт весь зоопарк квантов |
Загрузка | Читает в RAM/VRAM | mmap — подгружает страницы по требованию |
Поддержка новых моделей | Приезжает с Python-кодом | Нужен смерженный C++ |
Мультимодальность | Один чекпоинт | Зрение вынесено в отдельный |
Обучение | Да | Нет — только инференс |
Последняя строка — настоящий водораздел. GGUF обменял обучаемость и универсальность фреймворка на один переносимый файл, который нормально мапится в память и крутится квантизованным на ноутбуке. Вся экосистема k-квантов существует только в GGUF, потому что именно там эти форматы и проектировались.
MLX — третий вариант, актуальный конкретно на Mac: файлы safetensors с раскладкой под Apple, только Apple silicon, в целом быстрее Metal-бэкенда llama.cpp.

На этом спотыкаются почти все, поэтому убьём сразу.
«30B» считает параметры, а не байты.
Что такое параметр? Представьте простейшую нейросеть: несколько кружочков (нейронов), выстроенных в колонки, и линии, соединяющие каждый кружок одной колонки с каждым кружком следующей. Каждая линия несёт число — насколько сильно проходящий по ней сигнал усиливается или гасится. Это число и есть параметр. Обучение — процесс подкручивания всех этих чисел до тех пор, пока выход сети не перестанет быть мусором.
Их же называют весами, и на практике слова используются взаимозаменяемо. (Строго говоря, в «параметры» входят ещё некоторые обучаемые величины вроде смещений, но на таком масштабе разница — погрешность округления.)
В модели «30B» тридцать миллиардов таких сил связи. Это и есть вся модель — гигантская куча чисел, разложенная в определённую структуру.
И вот ключевой ход: число вроде 0.7182818 можно записать и как 0.72. Значение примерно то же, а цифр хранить сильно меньше. Сколько места на диске займёт модель, зависит целиком от того, насколько точно вы записываете каждое число:
Точность | Байт на параметр | Модель 30B |
|---|---|---|
FP32 | 4 | ~120 ГБ |
BF16 / FP16 | 2 | ~60 ГБ |
8 бит | 1 | ~30 ГБ |
4 бита | 0,5 | ~15 ГБ |
2 бита | 0,25 | ~7,5 ГБ |
То есть одна и та же модель весит 120 ГБ или 7,5 ГБ исключительно в зависимости от точности записи. Обучение идёт в 16 или 32 битах, инференсу столько не нужно и близко.
И очевидно: меньше точность — глупее модель. Вы выбрасываете информацию, и в какой-то момент модель это замечает. Интересное — к чему мы скоро придём — в том, что зависимость совершенно нелинейная. Переход с 16 бит на 4 стоит почти ничего измеримого. Переход с 4 на 2 обрывается в пропасть.
Полезное правило: на 4 битах размер файла в гигабайтах примерно вдвое меньше числа параметров в миллиардах. Модель 30B → ~15 ГБ. Модель 7B → ~3,5 ГБ. Для планирования достаточно.
Реальные файлы никогда не совпадают с таблицей точно, по двум причинам. Динамические кванты смешивают точности по тензорам, поэтому эффективное число бит на параметр оказывается между уровнями: 29,6 млрд параметров Muse Glimmer в UD-Q4_K_XL дают 15,9 ГБ, то есть около 4,3 бита на параметр, а не 4,0. Плюс каждый GGUF тащит словарь токенизатора и метаданные — ещё несколько сотен мегабайт.
Вторая половина заблуждения. Скачать файл на 15,9 ГБ не значит, что 15,9 ГБ RAM хватит. Вы также платите за:
KV-кэш — память модели о текущем разговоре, растущая с длиной контекста
Вычислительные буферы — рабочее пространство для прямого прохода
Энкодер зрения (mmproj), если модель мультимодальна — здесь ~2 ГБ
Вашу операционную систему, которая на Mac ещё и ограничивает адресуемую GPU память примерно 75% от общего объёма RAM
Закладывайте размер файла плюс 20–30%, потом проверяйте, что влезает в тот самый потолок в 75%. На 32-гигабайтном Mac это около 24 ГБ пространства для манёвра — вот почему 15,9 ГБ работают комфортно, а 21,8 ГБ нет. Урок, усвоенный на собственной шкуре в седьмой части.
Обученная модель хранит каждый вес как 16-битный float. Квантизация сжимает веса до меньшего числа бит — но как именно вы это делаете, имеет огромное значение.
Наивный вариант: найти минимум и максимум весов, поделить диапазон на 16 корзин, хранить 4 бита на вес. Это уничтожает модель, потому что распределения весов имеют длинные хвосты — горстка огромных выбросов растягивает диапазон, и всё остальное схлопывается в две-три корзины.
Сначала — что мы, собственно, делим? Эти тридцать миллиардов чисел не бесформенная куча, они организованы в прямоугольные сетки. Вернёмся к картинке с кружочками и линиями: если в одной колонке 4000 нейронов, а в следующей 11 000, то связи между ними образуют сетку 4000 × 11 000. Эта сетка называется тензором. Слово означает просто «массив чисел с каким-то числом измерений»: список — 1D, сетка — 2D, стопка сеток — 3D.
Модель 30B — это несколько сотен таких сеток, у каждой имя и работа: blk.12.attn_q.weight — проекция запросов в 12-м слое, blk.12.ffn_down.weight — выход feed-forward того же слоя. Квантизация работает с этими сетками по одной — и внутри каждой, по коротким пробегам соседних чисел.
K-кванты решают проблему выбросов поблочным масштабированием. Разбиваем каждый тензор на блоки примерно по 32 числа и даём каждому блоку собственный масштаб и смещение. Представьте это как измерение линейками: одна линейка с делениями от нуля до километра бесполезна и для рисового зерна, и для здания. Поэтому вместо одной линейки на всю сетку каждый блок из 32 получает линейку под своё содержимое. Блок из крошечных значений получает мелкие деления, блок с выбросом — крупные. Среднее число бит то же, точность драматически выше.
Динамическая квантизация поднимается на уровень выше: не каждый тензор заслуживает одинакового обращения. Проекции внимания, эмбеддинги, первый и последний слои непропорционально чувствительны к ошибке округления — повреждение там расходится вниз по всей цепочке. Поэтому эти сетки держим на 5–6 битах, а основную массу feed-forward опускаем ниже. То же среднее число бит по файлу, гораздо более удачное размещение точности, за которую вы платите. Именно это означают и «K-Quant-Dynamic» у Meta, и префикс UD- у Unsloth — разные реализации одной идеи.
imatrix (importance matrix) — шаг калибровки: прогоняем текст через модель, замеряем, какие веса реально влияют на выход, и взвешиваем ошибку квантизации соответственно.
Берём Muse-Glimmer-30B-UD-IQ3_M.gguf. Три компонента:
UD- — Unsloth Dynamic. Смешанная точность плюс калибровка imatrix.
Q против IQ — Q это классический k-квант: поблочные масштаб и смещение, дёшево декодируется. IQ это i-квант с кодбуком/решётчатой схемой, упаковывающий больше качества в те же биты ценой реальной арифметики на каждый вес при деквантизации.
Суффикс — XXS < XS < S < M < L < XL, позиция внутри битового уровня. Выше означает, что больше тензоров удерживается над номинальной разрядностью.
Поэтому размеры перекрываются между уровнями, а список выглядит хаотично. IQ2_M на 12,3 ГБ и Q2_K_XL на 12,4 ГБ приходят к одному размеру разными путями.
Meta замерила: 0,2% средней деградации для сборки под 32 ГБ и 1,0% для сборки под 24 ГБ на 15 бенчмарках. Для трёхкратного сжатия это поразительно мало.
Но среднее прячет главное. Ущерб от квантизации распределяется по способностям неравномерно. В моих тестах низкобитные сборки продолжали выдавать вполне читаемую прозу, при этом их структурированный вывод разваливался: битые tool calls, потерянные закрывающие теги, выдуманные поля схемы.
Это критично, если вы гоняете агентную модель. Вы протестируете её в чате, решите «на 3 битах вроде норм», подключите к кодинг-агенту и будете смотреть, как оно падает способом, неотличимым от ошибки конфигурации.
Тестируйте квантизацию на той способности, которая вам реально нужна. Для агентов это tool calls и код, а не разговоры.

Это самая полезная ментальная модель в локальном инференсе, и почти никто её не объясняет.
Генерация одного токена требует прочитать из памяти каждый вес модели.
Не часть. Все. При batch size 1 — один пользователь, один разговор — модель делает полный проход по своим параметрам, чтобы выдать один токен, выполняет примерно две операции с плавающей точкой на параметр, а потом выбрасывает веса и читает их заново для следующего токена.
Значит, у скорости генерации есть жёсткий потолок:
У моего MacBook Air M5 153 ГБ/с пропускной способности унифицированной памяти. 4-битная модель 30B — это ~16 ГБ. Итого:
Это потолок. Никакая настройка его не пробьёт. Вот что я реально намерил на семи квантизациях:
Квант | Размер | Замеренные т/с |
|---|---|---|
UD-Q5_K_L | 19,8 ГБ | 6,3 |
Meta kquant-17gb | 16,8 ГБ | 7,4 |
UD-Q4_K_XL | 15,9 ГБ | 7,6 |
UD-IQ3_M | 14,1 ГБ | 8,5 |
UD-Q3_K_XL | 13,4 ГБ | 8,4 |
UD-IQ3_XXS | 13,1 ГБ | ~8,0 |
Кривая отслеживает размер файла почти идеально, на уровне примерно 80% от теоретического — это признак хорошо реализованного Metal-бэкенда, а не кривой конфигурации. Ваша скорость — функция от количества гигабайт, читаемых на токен. И всё.
Я предполагал, что i-кванты будут медленнее на Metal из-за накладных расходов на деквантизацию. IQ3_M обошёл Q3_K_XL, будучи при этом более крупным файлом. Неверно.
Интереснее другое: IQ3_XXS на 13,1 ГБ оказался медленнее IQ3_M на 14,1 ГБ. Это ломает bandwidth-модель напрочь — меньший файл должен быть быстрее.
Объяснение в том, что в районе 13 ГБ вы перестаёте быть чисто bandwidth-bound. Более тяжёлая распаковка кодбука XXS начинает стоить дороже, чем даёт экономия на чтении памяти. У сжатия есть пол, и на этом железе он в районе 13–14 ГБ.
Практическое следствие: IQ3_M — оптимум. Он самый быстрый из замеренных и самый крупный среди быстрых, то есть лучшее доступное качество на этой скорости. Всё, что меньше, строго доминируется.
А если вам хочется размахнуться, потому что памяти вроде хватает — забудьте. Потратив запас на более крупный квант, вы получите более медленную модель, а не более умную. Если IQ3_M реально не тянет на вашей задаче, запасной вариант Q4_K_XL, но я удивлюсь, если он понадобится.
Определим машинный баланс B = пиковые FLOP/с ÷ пропускная способность памяти, в FLOP на байт. Это сколько арифметики чип успевает сделать за время чтения одного байта.
Пропускная способность | ~Пик FP16 | B (FLOP/байт) | |
|---|---|---|---|
MacBook Air M5 (10-ядерный GPU) | 153 ГБ/с | ~5 TFLOP/с | ~33 |
RTX 5080 | ~960 ГБ/с | ~400+ TFLOP/с | ~450 |
Порядок разницы. У потребительских карт Nvidia гигантские вычислительные мощности относительно пропускной способности, Apple silicon сбалансирован куда ровнее. Запомните это число — оно вот-вот объяснит кое-что неожиданное.
(Ремарка: сторона Nvidia заслуживает отдельной статьи. Напишите в комментариях, если нужен гайд по локальным LLM на 5080 с выгрузкой в RAM — Qwen3.8-27B будет очевидным подопытным, как только выйдут веса.)

Теперь, когда мы знакомы со всеми движущимися частями — параметры, тензоры, квантизация, пропускная способность — пустим их в дело и посмотрим на мои реальные эксперименты.
Раз декодирование упирается в память, арифметические блоки простаивают. Спекулятивное декодирование эксплуатирует ровно это.
Ключевая идея: проверка K токенов стоит того же трафика памяти, что генерация одного. Веса вы читаете один раз в обоих случаях. Значит, если получится угадать следующие несколько токенов, можно проверить все догадки за один проход и получить несколько токенов по цене одного.
Цикл:
Маленькая черновая модель (drafter) предлагает блок токенов.
Полная модель делает один прямой проход по всему блоку, сравнивая то, что выдала бы сама, с предложенным.
Всё совпавшее до первого расхождения принимается. В точке расхождения берётся собственный токен целевой модели, остальное отбрасывается.
Худший случай: первый же токен не совпал — работа черновика потрачена зря, но вы всё равно получили ровно один токен, как обычно. Меньше базового уровня получить нельзя.
Корректность точная, а не приближённая. При жадном декодировании это сравнение строк. При семплировании шаг accept/reject использует rejection sampling, доказуемо воспроизводящий распределение целевой модели: принимаем черновой токен с вероятностью min(1, p/q), а при отклонении семплируем из скорректированного остатка. Выход статистически неотличим от запуска одной целевой модели.
Muse Glimmer поставляется с черновиком под названием DFlash, и его трюк — реальная инженерия. Классическое спекулятивное декодирование использует маленькую авторегрессионную модель, которая всё равно выдаёт токены по одному: 16 маленьких проходов, чтобы предложить 16 токенов.
DFlash использует блочно-диффузионную голову, выдающую все 16 позиций за один проход, причём слоты смотрят друг на друга двунаправленно, а не каузально. Это даже не отдельная модель: 5 слоёв, читающих остаточный поток целевой модели на слоях {1, 13, 25, 37, 49} и разделяющих с ней эмбеддинги, так что не хранит ни того, ни другого. Поэтому квантизованный черновик весит всего 1,63 ГБ.
Опубликованные цифры Meta:
Железо | База | С DFlash | Ускорение |
|---|---|---|---|
RTX 5090 | 74,9 т/с | 233,4 | 3,1× |
Apple M5 Max | 26,6 т/с | 50,2 | 1,8× |
Apple M4 Max | 23,7 т/с | 37,8 | 1,5× |
Конфигурация | Результат |
|---|---|
A: без спекуляции | 7,41 т/с |
B: DFlash, temp 1.0 | 3,0 т/с |
C: DFlash, temp 0.6 | 4,5 т/с |
DFlash сделал мою машину на 60% медленнее.
Это не баг. Возвращаемся к машинному балансу. Проверка K токенов имеет арифметическую интенсивность порядка 4K FLOP на байт при 4-битной точности. Проверка остаётся практически бесплатной, пока 4K < B:
Мой Air: B ≈ 33 → бесплатно до K ≈ 8
RTX 5080: B ≈ 450 → бесплатно до K ≈ 100
DFlash использует блок в 16. На 5090 это глубоко внутри бесплатной зоны — почти все принятые токены превращаются в чистое ускорение. На моём Air я уже за точкой перегиба, поэтому 16-широкая проверка стоит примерно двух однотокенных проходов. Точка безубыточности — около 2,5 принятых токенов на блок, и я до неё не дотягивал.
Результат C подтверждает механизм, а не только исход: снижение температуры повышает согласие черновика, что отыграло половину потерь — ровно то, что предсказывает теория acceptance rate.
Любая опубликованная цифра ускорения привязана к железу, и эта привязка обычно не в заголовке. «1,8× на M5 Max» не означает 1,8× на Apple silicon. Это означает 1,8× на том чипе, с тем соотношением пропускной способности к вычислениям, при том размере блока.
Прежде чем внедрять любую оптимизацию инференса, спросите: какой ресурс она меняет на какой, и есть ли у меня избыток нужного? Спекулятивное декодирование меняет вычисления на пропускную способность. Если вы бедны на вычисления — это налог.

Теперь кое-что забавное: почему две модели ровно одного размера файла могут работать с совершенно разной скоростью.
Если коротко: любую модель нужно целиком загрузить в память — но не каждая модель реально использует всю себя на каждый токен. Некоторые да. Некоторые трогают малую долю, а остальное пропускают. У этой разницы есть название, и это, пожалуй, самое важное, что нужно понимать при выборе модели для дома.
Плотная (dense) модель: каждый параметр участвует в каждом токене. Модель 30B dense читает 30 млрд параметров на токен.
Mixture of Experts (MoE): feed-forward слои разбиты на множество «экспертов», и роутер выбирает небольшое подмножество на каждый токен. У Qwen3-30B-A3B 30 млрд параметров всего, но активируется 3 млрд на токен.
Вот что здесь важно:
Объём занимаемой памяти масштабируется с общим числом параметров. Скорость генерации — с активным.
Держать резидентными нужно всех экспертов: маршрутизация меняется на каждом токене, подгружать с диска не выйдет. Но читаете вы на каждом шаге только активных. Раз декодирование упирается в память, это прямой множитель: модель 30B-A3B может генерировать в 3–5 раз быстрее, чем dense-модель 30B того же размера файла.
Посмотрите, что у Mac есть и чего нет:
В избытке: унифицированная память. 32, 64, 128 ГБ, и всё адресуемо GPU.
В дефиците: пропускная способность памяти. 153 ГБ/с на базовом M5 против ~960 у RTX 5080.
MoE меняет память (которая у Mac есть) на пропускную способность (которой у Mac нет). Это почти сшито по мерке под такое железо. Dense 30B — худшая возможная форма для Mac, MoE того же суммарного размера — одна из лучших.
MoE не бесплатен, и если вы на него рассчитываете, стоит знать подвохи:
Никакой экономии памяти. Вы храните всех экспертов. При одинаковой квантизации MoE-модели нужно чуть больше памяти, чем dense-модели сопоставимых способностей, потому что параметров всего больше.
Ниже качество на общий параметр. Внутри одного семейства dense-модель с бо́льшим числом активных параметров обычно бьёт MoE с меньшим. Компромисс намеренный: вы жертвуете частью потолка качества ради сильно лучшей эффективности инференса.
Префилл выигрывает меньше. Обработка промпта батчит много токенов сразу, поэтому задействуется гораздо большая доля экспертов. Ваши 3–5× относятся к генерации, а не к первичному чтению контекста — что очень важно в агентных циклах.
Зрелость рантаймов разная. Маршрутизацию MoE сложнее реализовать хорошо, и качество поддержки по бэкендам менее однородно, чем для dense.
Квантизация ведёт себя иначе. Отдельные эксперты уже, чем плотные FFN-слои, поэтому на низких разрядностях есть повод быть аккуратнее. Тестируйте, а не предполагайте.
Урок обобщается за пределы одного релиза: выбирая локальную модель, смотрите на активные параметры, а не на общие. Читайте строчку про архитектуру раньше таблицы бенчмарков.

Теперь та самая модель, с которой всё началось.
Что это: dense vision-language модель на 29,6 млрд параметров от Meta Superintelligence Labs, дистиллированная из более крупной Muse Spark, под лицензией Apache 2.0. 52-слойный текстовый декодер со скрытой размерностью 6656 плюс перцептивный энкодер ViT-G/14 на ~1,8 млрд. Контекст 128K. Обучена на 100+ языках. Cutoff знаний — 4 января 2026.
Почему релиз важен помимо характеристик. Это первая значимая открытая модель Meta со времён Llama 4 в апреле 2025 — разрыв в шестнадцать месяцев, за которые Llama 4 встретили знаменито смешанно, большинство авторов исходной статьи по Llama ушли, главный ИИ-учёный Ян Лекун в конце 2025 отбыл строить собственный проект, а весь ИИ-отдел реструктурировали в Meta Superintelligence Labs. Muse Glimmer — первое, что вышло с другой стороны.
И это Apache 2.0 — на этом стоит остановиться. Каждая предыдущая Llama выходила под самописной Community License с ограничениями использования, до такой степени, что формулировки самой Meta тихо сместились с «open source» для Llama 2 и 3 на «open-weight» для Llama 4. По-настоящему пермиссивная лицензия на флагманскую модель — это реальная смена позиции, а не сноска.
В архитектуре есть одна по-настоящему изящная деталь. Внимание чередуется по повторяющемуся паттерну [Local, Local, Local, Global] — три слоя со скользящим окном в 2048 токенов, затем один слой полного внимания, и так 13 раз. В сочетании с агрессивным grouped-query attention (32 головы запросов на 2 KV-головы, соотношение 16:1) с длиной контекста масштабируются только 13 слоёв из 52.
Практический эффект драматичен. KV-кэш стоит примерно 13 КБ на токен, то есть:
контекст 32K ≈ 0,5 ГБ
контекст 128K ≈ 1,8 ГБ
Полные 128K контекста меньше чем за два гигабайта. Большинству моделей понадобилось бы в десять раз больше. Если вы ограничены по памяти — эта архитектура подарок.
Где сильна: бенчмарки Meta показывают лидерство над Gemma4-31B и Qwen3.6-27B на общих агентных задачах — MCP Atlas (75,5 против 54,2 и 62,5), DeepSearch QA, Gaia2 — плюс AIME 2026 на 94,7 и сильные результаты на длинном контексте.
Где нет: Qwen3.6-27B обошла её на SWE-Bench Verified, TerminalBench и OSWorld-Verified. Чистой победы не вышло, и модель, которую она бьёт увереннее всего — это Gemma, а не Qwen.
На 32-гигабайтном Mac моя рекомендация по замеренным данным:
Начните с UD-Q4_K_XL (15,9 ГБ, 7,6 т/с). Лучшее качество из комфортно работающего, собственная рекомендуемая отправная точка Unsloth, и остаётся место под KV-кэш и энкодер зрения.
Переходите на UD-IQ3_M (14,1 ГБ, 8,5 т/с), если убедитесь, что качество держится на вашей задаче — конкретно на tool calls и коде, а не в чате.
Жёсткий верхний предел: ~19 ГБ. Я пробовал UD-Q5_K_XL на 21,8 ГБ. Она выдала hi WeWe и дальше выродилась. macOS ограничивает wired-память GPU примерно 75% от RAM (~24 ГБ на 32-гигабайтной машине), и как только добавляются энкодер зрения и KV-кэш, вы за пределом. Даже работая, Q5 идёт на 25% медленнее Q4. Купить качество памятью, которой у вас нет, нельзя.
Жёсткий нижний предел: ~13 ГБ. Ниже 3-битного уровня вы платите реальным качеством за скорость, которую вычислительный пол всё равно не отдаст.
Muse Glimmer сделана под долгую агентную работу — многошаговое планирование, последовательные вызовы инструментов, восстановление после ошибок, сессии длиной в часы. Это её заглавная способность.
И это ровно та нагрузка, которую моё железо не тянет.
На 7,6 т/с ответ в чате нормален — модель обгоняет скорость вашего чтения. Но агентный цикл платит префилл на каждом ходу по растущему контексту, и двадцать ходов превращаются в вечер. Архитектура dense 30B, которая делает её хорошей в агентных рассуждениях — это то же самое, что делает её медленной на ноутбуке со 153 ГБ/с.
Отсюда честный сигнал: агентные локальные модели пока не готовы для повседневной работы на обычном железе. Чтобы гонять такой класс моделей в реальном агентном цикле на комфортной скорости, вам нужен максимально прокачанный Mac Studio, DGX Spark или многокарточная сборка — машины, стоящие в несколько раз дороже ноутбука. Если ваш план был «заменить Claude Code на что-то локальное», честный ответ на сегодня: не на этом железе и не dense-моделью на 30B.
Но это утверждение об одной нагрузке, а не о локальном ИИ вообще — и стоит быть точным, о какой именно. Агентные циклы — дорогой случай, потому что перечитывают растущий контекст на каждом ходу. Всё остальное, что делает эта модель, вполне достижимо.
В чём она локально по-настоящему хороша: интерактивный чат и Q&A, ревью и объяснение кода, перевод, черновики, одноразовая генерация функций, понимание скриншотов и документов. Это немало! Просто не то, что написано на коробке.
Из-за чего мне не даёт покоя гибридный сценарий. При правильной обвязке локальная модель могла бы брать на себя дешёвую массовую работу — суммаризацию файлов, черновики коммит-месседжей, первый проход ревью, определение того, какие файлы вообще релевантны — и эскалировать к фронтир-модели вроде Claude только там, где это реально нужно. Вы платите задержкой там, где сейчас платите токенами. Я такого не строил, и логика роутинга — то место, где подобные идеи обычно умирают, но при 7,6 т/с и $0 за миллион токенов арифметика выглядит достаточно интересно, чтобы кто-то попробовал.

Хочу быть конкретным, потому что «экосистема была сырой в день релиза» — слишком расплывчато, чтобы с этим что-то делать.
llama.cpp. Поддержку смержили в день релиза. Но свежайший тегированный релиз был вчерашним, а формула Homebrew отслеживала именно тег. Так что brew upgrade бодро сообщил, что у меня всё актуально, а каждый преднастроенный бинарник с GitHub выдавал unknown model architecture. Единственный путь — клонировать master и компилировать. В комментарии ревьюера к мержу отмечено, что вошедшая версия — необходимый минимум для работы tool calling; поддержка зрения и спекулятивного декодирования отложена на потом.
mlx-vlm. Здесь хуже. Конверсия mlx-community на Hugging Face заявляет, что сделана на mlx-vlm 0.6.12. Публичная ветка main на GitHub — 0.6.10. Кода, загружающего эти веса, не существует за пределами чьей-то рабочей копии. Пользователь не может сделать ничего — ни pip install -U, ни установка из git, ни сборка из исходников. Веса опубликованы, загрузчик — нет.
Решение простое, и вендоры его знают. Дайте мейнтейнерам llama.cpp, MLX, Ollama и основным квантизаторам веса и документацию по архитектуре за неделю под NDA. Meta делала это для части партнёров — Unsloth прямо благодарит Meta за доступ в нулевой день, и это видно. Проблема в том, что любезность распространили неравномерно, и экосистема въехала в день максимального внимания в разобранном, частично сломанном состоянии.
Если это читает лаборатория: разработчики сообщества — это ваш канал дистрибуции. Неделя эмбарго не стоит вам ничего и превращает день релиза из археологической экспедиции в рабочий опыт.
Выше я мягко покритиковал производительность Unsloth Studio — она выдавала 5–7 т/с там, где llama.cpp давал 7,6. Это правда. Но остальное, что они сделали в день релиза, стоит сказать прямо:
Четырнадцать квантизаций в нулевой день. Каждый уровень от 2 до 8 бит, плюс i-кванты, плюс сборки MLX, плюс NVFP4 под Blackwell. Такого покрытия не было ни у кого.
Работающий GUI в нулевой день. Пока я собирал llama.cpp из исходников, Studio просто… запустила модель. Для большинства людей это разница между «попробовал» и «забил».
Самоисправляющийся tool calling, который, по их заявлению, снижает количество битых вызовов инструментов на 50%. Для модели, выдающей tool calls в XML-стиле, парсеру которых несколько часов от роду, это не маркетинг — для агентных задач это может реально перевесить разницу в скорости.
unsloth start, автоматически настраивающий эндпоинт, API-ключ, провайдера, модель и длину контекста для Claude Code, Codex, OpenCode, Hermes и Pi. Одна команда вместо ручного написания JSON.
Документация, вышедшая вместе с моделью, включая разбор квантизаций и таблицу по железу, в тот же день.
Честное резюме: llama.cpp быстрее, Unsloth проще и надёжнее. Используйте Studio, чтобы исследовать и сравнивать модели; используйте llama.cpp, когда определились и хотите последние 20%.

Где-то по дороге в разговоре о локальном ИИ завелась дурная привычка. Любое обсуждение запуска моделей дома скатывается к 128-гигабайтным M4 Max, паре 4090 или DGX Spark на столе.
Это активно вредит распространению технологии, и это неверно.
Вот что я запустил на MacBook Air. Не Pro. Не Max. Безвентиляторный 13-дюймовый ноутбук, стартующий с $1099:
Модель на 30 млрд параметров, околофронтирную, вышедшую тем же утром
На 7,6–8,5 токенах в секунду
С контекстом 32K
Со зрением
Подключённую к настоящему терминальному кодинг-агенту
Полностью офлайн
Это не игрушка. Это рабочая конфигурация.
Две вещи чуть меня не остановили, и обе — конфигурация, а не железо:
Ловушка контекста. Я подключил OpenCode и немедленно получил:
Message too long: 8289 tokens exceeds the 4096-token context window.
Контекст в 4096 токенов на модели, нативно поддерживающей 131 072. Рантайм консервативно подогнал размер и никому не сказал. Кодинг-агенты отправляют 8000+ токенов системного промпта до вашего первого сообщения — поэтому оно упало мгновенно, на этапе плана, не сделав ни единой полезной работы.
Новичок видит эту ошибку и решает, что его машина не тянет модель. Ещё как тянет. Благодаря гибридной схеме внимания контекст 32K стоит примерно полгигабайта.
Лимит памяти GPU. macOS ограничивает wired-память GPU примерно 75% от RAM. На 32-гигабайтной машине это ~24 ГБ. Об этом вам тоже никто не говорит, а это разница между работающей моделью и hi WeWe. Чинится одной командой:
sudo sysctl iogpu.wired_limit_mb=27000
32 ГБ унифицированной памяти — золотая середина для локального ИИ в 2026, и именно это число сообществу стоит повторять:
16 ГБ — реально, но ограниченно. Модели 8–14B на Q4. По-настоящему полезно, заметно тесно.
32 ГБ — золотая середина. Модели класса 30B на 4 битах с местом под контекст и зрение. Всё, что в этой статье.
64 ГБ+ — лучше, и вы поймёте, когда это понадобится. На чипах Pro/Max пропускная способность значит не меньше объёма.
128 ГБ — околопродакшен-воркстейшен. Прекрасно. Но это не входной билет, и притворяться, что это он, отпугивает как раз тех, кому технология принесла бы больше всего пользы.
Запускать продакшен-модели на железе, которое у вас уже есть — вот путь. Не потому что дешевле, хотя и это тоже. Потому что данные не покидают машину, потому что работает в самолёте, потому что нет ни рейт-лимита, ни счётчика за токены, тикающего, пока вы думаете, и потому что штука, стоящая у вас на столе, через пять лет будет крутить сегодняшние фронтир-модели так же, как сегодняшний ноутбук крутит модель 2023 года.
Разрыв между «тем, что лаборатория отдаёт из дата-центра» и «тем, что крутится на вашем ноутбуке» сокращается со скоростью, от которой должно становиться неуютно всем, кто строит чисто облачные пайплайны. Meta выпустила агентную модель на 30 млрд параметров, спроектированную специально под потребительское железо, в тот же день, когда анонсировала флагман на 2,4 трлн. Это не благотворительность. Это ставка на то, куда движется инференс.

Всё ниже копипастится. Проверено на macOS с Apple silicon; части про llama.cpp работают на Linux и Windows с соответствующим флагом бэкенда.
В день релиза нужен master. Позже хватит brew install llama.cpp.
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=OFF
cmake --build build --config Release -j --clean-first \
--target llama-cli llama-mtmd-cli llama-server llama-gguf-split
Поставьте -DGGML_CUDA=ON, если у вас GPU Nvidia. На Mac оставьте OFF — Metal включён по умолчанию.
Прежде чем компилировать поддержку совсем новой модели, убедитесь, что она реально есть в вашей копии:
grep -r "muse-glimmer" src/ | head -3
Пустой вывод означает, что мерж ещё не доехал. Лучше подождать, чем собирать.
sudo sysctl iogpu.wired_limit_mb=27000
Сбрасывается при перезагрузке. Экспериментировать безопасно. Берите ~85% от общего объёма RAM в мегабайтах.
./build/bin/llama-server \
-hf unsloth/Muse-Glimmer-30B-GGUF:UD-Q4_K_XL \
--alias muse-glimmer \
-c 32768 -np 1 --port 8080 \
--temp 1.0 --top-p 0.95 --top-k 64 \
--jinja --reasoning-preserve
Флаги, которые имеют значение:
Флаг | Зачем |
|---|---|
| Явный контекст. Не пропускайте — автоподбор выдаст 4096, и вы упрётесь в стену немедленно. |
| Один слот. По умолчанию 4, что учетверяет выделение под KV без всякой пользы для одиночного пользователя. |
| Загружает собственный чат-шаблон модели. Без него tool calls не распарсятся, и ваш агент не будет делать ничего. |
| Именует модель в API, чтобы конфиг клиента мог на неё ссылаться. |
| Сохраняет вывод канала рассуждений для моделей с канальной разметкой вывода. |
Проверить, что применилось:
curl -s http://127.0.0.1:8080/props | jq '.default_generation_settings.n_ctx'
curl -s http://127.0.0.1:8080/v1/models | jq '.data[].id'
Должно вывести 32768 и muse-glimmer.
mkdir -p ~/.config/opencode && cat > ~/.config/opencode/opencode.json << 'EOF'
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"llamacpp": {
"npm": "@ai-sdk/openai-compatible",
"name": "llama-server (local)",
"options": {
"baseURL": "http://127.0.0.1:8080/v1",
"apiKey": "sk-dummy"
},
"models": {
"muse-glimmer": {
"name": "Muse Glimmer 30B Q4",
"limit": { "context": 32000, "output": 8000 },
"tools": true
}
}
}
},
"model": "llamacpp/muse-glimmer",
"instructions": ["Reasoning strength: medium"]
}
EOF
Затем в директории проекта:
opencode
Выбрать модель через /models.
cat >> ~/.zshrc << 'EOF'
glimmer() {
cd ~/path/to/llama.cpp && ./build/bin/llama-server \
-hf unsloth/Muse-Glimmer-30B-GGUF:UD-Q4_K_XL \
--alias muse-glimmer -c 32768 -np 1 --port 8080 \
--temp 1.0 --top-p 0.95 --top-k 64 --jinja --reasoning-preserve
}
EOF
source ~/.zshrc
Теперь это glimmer в одной вкладке терминала и opencode в другой.
Если всё это показалось перебором, Unsloth Studio делает то же за три команды:
curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -p 8888
# загрузить модель в браузерном UI, выставить контекст 32768, затем:
unsloth start opencode
Медленнее llama.cpp, но автоматически настраивает эндпоинт, API-ключ, провайдера и длину контекста — а самоисправляющийся tool calling для агентной работы может стоить больше, чем разница в скорости.
Симптом | Причина | Решение |
|---|---|---|
| Бинарник старше модели | Собрать из master |
| Автоподобранный контекст слишком мал | Задать |
Модель отвечает мусором или зацикливается | Квант слишком крупный для wired-памяти GPU | Меньший квант или поднять |
Агент описывает правки вместо того, чтобы их делать | Tool calls не парсятся | Добавить |
Агент зависает после ответа | Не зарегистрирован стоп-токен |
|
Скачивается неожиданный лишний файл | Автоматически тянется | Нормально — это ~2 ГБ, а не вторая модель |
Локальный инференс при batch size 1 упирается в пропускную способность памяти. Скорость генерации — это пропускная способность, делённая на размер модели, и почти любое решение следует из этого одного уравнения. Берите самую крупную квантизацию, комфортно влезающую в ~75% вашей RAM, предпочитайте MoE-архитектуры, если есть запас унифицированной памяти, и относитесь глубоко скептически к любой опубликованной цифре ускорения, пока не поймёте, какой ресурс она меняет. Машины на 32 ГБ достаточно. Дефолты будут с вами воевать, и они неправы.
А потом просто запустите что-нибудь. Разрыв между тем, что вам отдаёт дата-центр, и тем, на что способен ваш ноутбук, сокращается быстрее, чем большинство успело заметить.
Все бенчмарки в статье сняты на MacBook Air M5 (10-ядерный GPU, 32 ГБ унифицированной памяти, 153 ГБ/с) 10 августа 2026 — в день релиза Muse Glimmer 30B. Поддержке в экосистеме на тот момент было несколько часов от роду, и с тех пор она почти наверняка улучшилась. Перепроверяйте, возможно вышло что-то, что солидно облегчит вам жизнь или увеличит производительность
Сырые логи замеров, конфиги и то, что не влезло в статью — включая провалившиеся попытки с Q5 и полный вывод по всем четырнадцати квантизациям — выкладываю в @techn0danya. Там же разбираю новые релизы по мере выхода.