От 12 до 38 токенов в секунду: как M3 Ultra раскрывает потенциал больших языковых моделей

# Дело о 38 токенах в секунду: почему M3 Ultra начинал с двенадцати

В мире локальных больших языковых моделей (LLM) ожидание часто превосходит реальность. Пользователи, обладающие мощным «железом», полагают, что новые процессоры мгновенно обеспечат молниеносный ответ от нейросети. Однако недавний эксперимент на аппаратуре Apple Silicon показал, что физические ограничения архитектуры памяти могут сдерживать даже самую передовую технику.

Физический предел памяти и миф вычислительной мощности

Эксперимент проводился на Mac Studio 2025 года (заказной номер Z1CE001BMZP/A). Машина оснащена процессором Apple M3 Ultra, который включает 24 производительных ядра CPU, 80 ядер GPU, 512 ГБ объединённой памяти и SSD на 2 ТБ. Заявленная Apple пропускная способность памяти составляет 819 ГБ/с. Это не обычный ноутбук, на котором случайно заставили считать сложную модель, а эталонная система.

Задача стояла амбициозная: запустить модель Qwen3.8-27B в формате BF16 (биполярная плавающая точка с 16-битной мантиссой). Формат BF16 выбран приоритетно за максимальную точность для сложных рассуждений и работы с кодом, без использования агрессивной 8-битной или 4-битной квантизации.

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

Memory-bound, а не Compute-bound

Многие ошибочно полагают, что скорость работы LLM зависит от количества вычислительных ядер (FLOPS). Это справедливо для фазы предобработки запроса, когда можно распараллелить вычисления. Но генерация ответа устроена иначе: каждый новый токен полностью зависит от предыдущего.

Модель Qwen3.8-27B содержит около 27 миллиардов параметров. В формате BF16 на каждый параметр приходится два байта, что требует почти 54 ГБ памяти только для хранения весов модели. При генерации каждого нового слова модель должна последовательно пройти через все слои нейросети, считывая огромный массив данных из оперативной памяти.

Режим работы называется memory-bound (ограничен памятью). Здесь скорость не определяет количество арифметических блоков GPU, а то, насколько быстро данные успевают доставить к ним. Грубая арифметика подсказывает предел: при пропускной способности 819 ГБ/с и весе модели 54 ГБ, теоретический максимум составляет около 15–16 токенов в секунду. Реальные 12 токенов в секунду лишь незначительно отстают от этого физического потолка из-за накладных расходов системы.

Таким образом, проблема не в том, что приложение «не видело» мощь M3 Ultra. Проблема была в самой механике генерации: 80 ядер GPU вычисляли быстрее, чем 512 ГБ памяти могли их кормить данными.

Прорыв через спекулятивное декодирование

Чтобы обойти ограничение памяти, нельзя сделать память быстрее. Нужно изменить стратегию обработки. Решение лежало в технологии speculative decoding (спекулятивное декодирование).

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

Для эксперимента использовалась реализация DFlash2 (Block Diffusion Draft) в среде oMLX. DFlash2 выступает в роли «напарника», который параллельно генерирует блок кандидатов для проверки. В отличие от традиционных методов, где небольшая модель предлагает токены по одному, здесь используется блочная диффузия для более эффективного предсказания контекста.

Настройка и первые результаты

Интеграция проводилась с использованием библиотеки oMLX, которая предоставляет полный цикл работы: от генерации (draft) до проверки (verify) и принятия решений (accept). При этом веса исходной модели Qwen3.8-27B оставались неизменными, а каталог LM Studio использовался как хранилище.

Ключевые настройки, давшие наилучший результат без квантования draft-модели: * Target модель: Qwen3.8-27B-bf16 (полная точность). * Draft модель: Qwen3.8-27B-DFlash2. * Draft Window: 2048 (сокращение окна до 1024 ухудшило точность предсказаний). * Draft Quantization: OFF (квантование помощника снизило качество его подсказок). * Verify Mode: adaptive.

При таких настройках скорость выросла с 12 до 17,9 токенов в секунду при уровне принятия предсказаний (acceptance) 68,3%. Это ускорение в 1,5 раза уже является значимым шагом, хотя для комфортной работы с длинными ответами требовалось больше.

Парадокс квантования: кто должен быть легким?

Поскольку квантовать «напарника» нельзя, исследователи попробовали квантовать саму главную модель (target). Логика была следующей: уменьшение размера весов основной модели снизит объем данных, которые нужно считать с памяти, даже если она останется в высоком разрешении.

Была переключена модель на 8-битный формат: mlx-community/Qwen3.8-27B-8bit.

Результат был ошеломляющим: * Без DFlash2 8-битная модель давала 21,4 токена в секунду (быстрее BF16). * С активацией DFlash2 скорость достигла 38,0 токенов в секунду.

Это ускорение в 3,17 раза по сравнению с исходной точной моделью. Приемлемость предсказаний (acceptance) осталась на высоком уровне — 66,8%.

Почему это работает

Казалось бы, зачем квантовать модель, если мы хотим максимальную точность? Ответ кроется в балансе. Квантование основной модели с 16 до 8 бит снижает стоимость проверки гипотез «напарника». В то же время, DFlash2 сохраняет высокую способность к предсказанию, не требуя идеальной математической точности весов. Один компонент связки становится дешевле по объему данных, второй продолжает эффективно работать с упрощенными входными данными. Именно этот симбиоз дал наилучшую производительность.

Выводы о локальном инференсе

Эксперимент на Mac Studio с M3 Ultra доказал несколько важных тезисов для сообщества разработчиков LLM:

1. Ограничение памяти жесткое. Даже на системе с 512 ГБ памяти и пропускной способностью 819 ГБ/с, генерация в точном формате BF16 для модели на 27 млрд параметров будет медленной. Это фундаментальное свойство архитектуры, которое невозможно обойти только заменой процессора. 2. Качество draft важнее его скорости. Попытка ускорить вспомогательную модель через квантование (W8A16, W4A16) привела к падению точности её предсказаний и общей скорости работы. Помощник, который часто ошибается, замедляет работу главного. 3. Оптимизация требует системного подхода. Лучший результат (38 токенов/сек) был получен не путем «накрутки» настроек, а подбором компромисса: точная, но легкая для проверки модель + мощный предсказатель контекста.

Для пользователей, ищущих баланс между скоростью и качеством, связка 8-битной модели с DFlash2 представляет собой текущий максимум эффективности на оборудовании Apple Silicon. Однако вопросы влияния квантования на сложные рассуждения и работу с кодом требуют дальнейшего изучения, что планируется в следующих исследованиях.

*Уmine Nagi: Иногда самая громкая цифра в спецификациях не означает максимальную производительность в реальной задаче. Истинная эффективность рождается в гармонии компонентов, а не в их индивидуальной мощи.*