Что известно о запуске Muse Spark на Mac Studio
Автор эксперимента сообщает: Muse Spark запущена на одном Mac Studio и достигла 18 токенов в секунду на декодировании. В посте на r/LocalLLaMA это сформулировано коротко: «18 t/s decode was hit». Речь именно о скорости генерации, а не о полной скорости ответа.
Сейчас цифра не актуальна. Тот же автор пишет о небольшом регрессе, который появился при переносе наработок из других рабочих веток проекта ds4. Код не опубликован: его выложат после того, как просадка на этапе prefill будет устранена и прежние 18 т/с вернутся. Веса Muse Spark закрыты на Hugging Face, поэтому автор пока выбирает между публикацией самих весов и публикацией рецепта воспроизведения.
Деталей источник не даёт. Неизвестны чип и объём объединённой памяти Mac Studio, размер и архитектура модели, квантизация, длина контекста при замере и способ подсчёта токенов. Поэтому 18 т/с стоит читать как сообщение о результате одного эксперимента, а не как характеристику платформы Apple Silicon.
18 токенов в секунду: что именно измерено, а что нет
Декодирование - это генерация токенов после обработки промпта. Цифра 18 т/с отвечает на вопрос «как быстро модель печатает», но молчит о том, «как быстро она начинает отвечать». Для честного сравнения с другими конфигурациями нужны как минимум семь параметров:
- чип и объём unified memory в Mac Studio;
- размер и архитектура модели (плотная или MoE, сколько параметров активно на токен);
- квантизация весов и KV-кэша;
- длина контекста в момент замера;
- batch size и число параллельных запросов;
- что считали: только decode или весь цикл ответа целиком;
- чем измеряли: логи движка, собственный скрипт или секундомер.
Ни одного из этих пунктов в источнике нет. Модель чипа важна потому, что от неё зависят и пропускная способность памяти, и вычислительные блоки. Квантизация меняет не только скорость, но и качество вывода. Длина контекста определяет размер KV-кэша, а он занимает ту же память, что и веса, и напрямую влияет на то, сколько останется на генерацию.
Формулировка «decode» отделяет генерацию от prefill. Если считать end-to-end, скорость ответа на длинный промпт окажется ниже. Насколько ниже, из поста понять нельзя, и это главный пробел в данных.
Почему код пока не опубликован
Условие названо прямо: сначала устранить просадку prefill, потом вернуть 18 т/с, и только затем выложить код. Логика понятна. Промежуточное состояние с регрессом даёт читателям цифру, которую они не смогут воспроизвести, и репозиторий, который работает хуже заявленного.
Сроков нет. Для исследовательского проекта это обычная ситуация: перенос наработок между рабочими ветками ds4 почти всегда ломает уже отлаженные участки, и починка занимает непредсказуемое время. Практический вывод один: строить планы на Muse Spark прямо сейчас рискованно, пока не появились код или веса.
Почему prefill важен не меньше декодирования
Просадка prefill задержала публикацию, и это показательно. Декодирование отвечает за плавность вывода. Prefill отвечает за время до первого токена и за то, во сколько обходится длинный контекст. Когда prefill медленный, модель с хорошим decode всё равно ощущается тормозной.
Prefill vs decode простыми словами
Prefill - это чтение промпта. Модель обрабатывает все входные токены разом, заполняет KV-кэш и готовит состояние для генерации. Decode - ответ: токен за токеном, и каждый следующий шаг требует полного прохода по весам.
| Этап | Что делает | Что ограничивает | На что влияет |
|---|---|---|---|
| Prefill | Обрабатывает весь промпт и заполняет KV-кэш | Вычисления и пропускная способность памяти | Время до первого токена, стоимость длинного контекста |
| Decode | Генерирует по одному токену | Пропускная способность памяти | Плавность вывода, токены в секунду |
Разница в узких местах определяет стратегию ускорения. Prefill хорошо параллелизуется по токенам промпта, поэтому его ускоряют батчингом и более эффективными ядрами для матричных операций. Decode почти не параллелизуется: на каждом шаге рождается один токен, и всё упирается в то, как быстро память отдаёт веса. Методы, которые помогают одному этапу, второму часто не дают ничего.
Как prefill влияет на реальную работу с моделью
В чате с коротким вопросом prefill почти незаметен. В рабочих сценариях он доминирует. Длинный системный промпт, RAG-контекст на десятки тысяч токенов, агентная цепочка с вызовами инструментов: каждый шаг добавляет новый промпт, и prefill выполняется заново для всей накопленной истории, если её не кэшируют.
При 18 т/с генерация выглядит бодро. Если prefill просел, первый токен приходит позже, а в агенте, где таких шагов десять, задержки складываются. Отсюда и осторожность автора: цифра decode без метрик prefill не описывает пользовательский опыт.
Проблема не уникальна для Muse Spark. Разбор экспериментальных ядер для предзаполнения Gemma4 на чипах M5 показывает: выигрыш на prefill измеряют отдельно, и на скорость генерации он автоматически не переносится.
Что значит «веса закрыты на Hugging Face» и почему это проблема
Gated-доступ на Hugging Face означает, что файлы не лежат в открытом виде. Чтобы получить веса, нужно отправить запрос и дождаться одобрения владельца репозитория. Он же задаёт условия использования.
Веса или рецепт: чем отличаются два варианта публикации
Два варианта, которые рассматривает автор, дают разный результат для читателя.
- Публикация весов: пользователь скачивает модель и запускает её сам, с поправкой на условия доступа и лицензию.
- Публикация рецепта: инструкция по окружению, настройкам и параметрам запуска. Методику по ней повторить можно, запустить модель нельзя, если весов нет.
Для исследовательского проекта вроде ds4 рецепт выглядит компромиссом: он показывает, как получены 18 т/с, и не передаёт саму модель. Минус в том, что независимая проверка остаётся неполной. Пока решение не принято, любые утверждения о скорости Muse Spark опираются на слова автора эксперимента. Это не повод не доверять, это повод не переносить цифру на своё железо без проверки.
Только текст, но стабильные tool calls: кому это подходит
Модель работает только с текстом. Заявленные свойства: связный вывод и стабильные вызовы инструментов. Для агентных задач второй пункт важнее первого.
Агент постоянно вызывает функции: поиск, чтение файлов, запросы к API, запись результатов. Если вызовы срываются, цепочка разваливается, и скорость генерации уже не имеет значения. Стабильные tool calls означают, что модель можно ставить в автоматизацию без постоянного присмотра, а связный вывод снижает число повторных попыток.
Ограничение простое: нет изображений, аудио и видео. Сценарии со сканами документов, скриншотами интерфейсов и разбором видео отпадают. Для текстовых задач (агенты, обработка логов, работа с API, извлечение данных) этого достаточно. Мультимодальность здесь не заявлена, и приписывать модели её не стоит.
Потенциал и ограничения Apple Silicon для локальных LLM
Mac Studio интересен объёмом объединённой памяти. Модель, которая не влезает в VRAM потребительской видеокарты, помещается в общую RAM и работает без выгрузки на диск. Плюс энергоэффективность и тихая работа: для домашнего сервера это заметные аргументы.
Как это устроено при запуске на нескольких машинах, разбираем в статье про локальный и распределённый инференс больших LLM на Mac Studio: MLX, объединённая память, RDMA и реальные ограничения схемы.
Где Apple Silicon выигрывает, а где упирается в потолок
Потолок тоже понятен. Пропускная способность памяти у Apple Silicon ниже, чем у топовых дискретных GPU, а decode упирается именно в неё. Prefill ограничен вычислениями, и там разрыв заметнее. Длинный контекст и агентные циклы проявляют оба ограничения одновременно.
Экосистема уже: MLX, llama.cpp, Metal-ядра. Готовых ускорений под конкретную модель меньше, и часть работы приходится делать самому, что в истории с Muse Spark и произошло. Экономика тоже считается: замеры на Mac Studio M3 Ultra показывают, как стоимость миллиона токенов зависит от размера модели и квантизации.
Один результат на одной конфигурации - сигнал, а не доказательство универсального преимущества. Для самопроверки смотрите на объём памяти, пропускную способность и поддержку бэкенда, а не только на имя чипа.
Как читать такие анонсы и что делать сейчас
Практическая линия простая. Следить за публикацией кода в ds4 и за решением по весам или рецепту на Hugging Face. Параллельно проверять на своём Mac доступные модели через MLX или llama.cpp, замеряя prefill и decode раздельно, чтобы не путать эти метрики в собственных выводах.
Чек-лист для оценки анонсов локального запуска
- Железо и объём памяти, включая модель чипа.
- Размер и архитектура модели, число активных параметров.
- Квантизация весов и KV-кэша.
- Длина контекста при замере и размер batch.
- Что измеряли: prefill, decode, время до первого токена или всё вместе.
- Доступность весов и кода: открытые, gated или только описание.
- Кто проверял результат и по какой методике.
Отсутствие любого пункта - повод для осторожности, а не для выводов. Один пропущенный пункт обычно и стоит между «интересным экспериментом» и «готовым решением для продакшна».
Как измерить скорость на своём железе и не запутаться в метриках, разбираем в материале про ускорение Qwen3.8 Flash на M2 Ultra через oMLX: там же описано, как корректно замерять генерацию токенов.
18 т/с на одном Mac Studio - сигнал о том, что Apple Silicon тянет модели, которые ещё недавно требовали серверной видеопамяти. Пока нет кода, весов и деталей замера, это история про один эксперимент с закрытыми комплектующими результата. Смотрите на публикацию в ds4 и на решение по Muse Spark, а своё железо проверяйте собственными замерами prefill и decode.