Что изменилось: GLM-5.3-Flash Q4 на M3 Ultra стала быстрее без заявленной потери точности
Проект ds4 представил форк GLM-5.3-Flash Q4, настроенный под Apple M3 Ultra. На коротком контексте скорость декодирования выросла с 29 до 40 токенов/с, примерно на 38%. На контексте объёмом 62 тыс. токенов модель генерировала 38 токенов/с вместо прежних 24 токенов/с.
Префилл ускорился с 366 до 550 токенов/с. В результате обработка 62 тыс. входных токенов заняла 113 секунд вместо 170 секунд. Пользователь получает первый токен примерно на 57 секунд раньше, если его запрос, история диалога и подключённые материалы вместе занимают такой объём.
По данным ds4, ускорение не снизило точность модели. Проверка охватила 100 промптов, однако состав запросов, метрики и подробная методика сравнения не раскрыты. Поэтому корректная формулировка звучит так: проект сообщает об отсутствии расхождений в своей проверке, но доступных сведений недостаточно для полноценной независимой оценки качества.
Ключевые цифры в сравнении скорости LLM
| Сценарий | Исходная версия | Форк ds4 | Практический результат |
|---|---|---|---|
| Декодирование, короткий контекст | 29 токенов/с | 40 токенов/с | Рост примерно на 38% |
| Декодирование, контекст 62 тыс. токенов | 24 токена/с | 38 токенов/с | Более быстрый вывод после обработки длинного контекста |
| Префилл | 366 токенов/с | 550 токенов/с | Рост пропускной способности примерно на 50% |
| Префилл 62 тыс. токенов | 170 секунд | 113 секунд | Ожидание сократилось на 57 секунд |
Показатели декодирования и префилла описывают разные этапы инференса. Значение 40 токенов/с показывает темп генерации ответа, а 550 токенов/с отражает скорость обработки уже переданного ввода. Смешивать эти метрики при сравнении моделей нельзя. Разница подробно проявляется и в "https://ai-manual.ru/article/qwen-38-27b-na-odnoj-rtx-5090-ninfer-nvfp4-i-chestnoe-sravnenie-lokalnogo-zapuska/"методике честного сравнения prefill и decode на примере Qwen 3.8 27B.
Почему 550 токенов в секунду важнее, чем кажется
Длинный запрос сначала целиком проходит через этап префилла. Модель обрабатывает системную инструкцию, пользовательский текст, историю сообщений и приложенные документы. Лишь после этого начинается последовательная генерация ответа.
При объёме 62 тыс. токенов новая скорость сокращает подготовку с 170 до 113 секунд. Разница составляет 57 секунд, или почти минуту ожидания перед началом ответа. Эффект особенно заметен при повторяющейся работе с крупными документами, репозиториями и большими подборками данных для RAG.
Префилл со скоростью 550 токенов/с не означает, что модель печатает ответ с таким же темпом. После обработки ввода скорость ограничивается показателем декодирования: 40 токенов/с на коротком контексте или 38 токенов/с в приведённом сценарии с 62 тыс. токенов.
Декодирование и префилл: какие задачи локальных LLM на M3 Ultra ускорятся
Декодирование начинается после подготовки контекста. Модель последовательно выбирает и добавляет новые токены, поэтому этот показатель напрямую влияет на темп появления текста в интерфейсе.
Префилл выполняется раньше. На этом этапе модель читает весь вход: инструкции, вопрос, историю чата, фрагменты базы знаний и другие переданные материалы. Чем больше ввод, тем сильнее задержка префилла влияет на время до первого токена.
Быстрый отклик в чате зависит от декодирования
Рост с 29 до 40 токенов/с заметен в локальном чате, помощнике для программирования и при генерации длинных ответов. Текст появляется быстрее, а создание ответа на несколько сотен токенов занимает меньше времени после завершения префилла.
Цифра относится к GLM-5.3-Flash Q4 на Apple M3 Ultra и к условиям измерения ds4. Она не описывает скорость других квантов, рантаймов и конфигураций Apple Silicon. Даже на одном компьютере результат может зависеть от длины контекста и параметров запуска.
RAG и большие документы упираются в префилл
RAG-конвейер может передавать модели десятки фрагментов из базы знаний. Похожая нагрузка возникает при анализе документации, истории переписки или файлов репозитория. Все эти токены нужно обработать до появления первого фрагмента ответа.
В примере ds4 контекст на 62 тыс. токенов обрабатывается за 113 секунд вместо 170. Это заявленный результат проекта, а не тест AI-Manual. Конкретный RAG-конвейер может показать другую скорость из-за шаблона промпта, размера найденных фрагментов, настроек модели и используемого рантайма.
При сравнении локальных систем полезно фиксировать отдельно время до первого токена и последующую скорость генерации. Пиковая цифра tok/s не описывает весь пользовательский опыт, что хорошо видно в "https://ai-manual.ru/article/dgx-spark-prakticheskie-rezultatyi-testov-deepseek-v4-flash-qwen38-flash-next-i-qwen38-27b/"разборе latency, p50 и p95 на DGX Spark.
За счёт чего ds4 ускорила инференс на Apple M3 Ultra
В описании форка названы три направления изменений: фьюзинг мелких ядер, более эффективная работа с памятью и переработанный поиск позиций в длинном контексте. Подробности реализации не опубликованы в предоставленных материалах, поэтому технический эффект можно объяснить лишь на уровне общих принципов.
Фьюзинг мелких ядер уменьшает накладные расходы
Инференс состоит из множества вычислительных операций. Если несколько небольших операций запускаются по отдельности, система тратит время на каждый запуск и передаёт промежуточные данные между этапами.
Фьюзинг объединяет часть таких операций в более крупный вычислительный блок. Число запусков сокращается, уменьшается объём промежуточного обмена. Этот подход способен дать заметный выигрыш при декодировании, где похожая последовательность повторяется для каждого нового токена.
Из доступных сведений нельзя определить, какие именно ядра объединила ds4 и как устроен их код. Подтверждён только общий тип изменения, поэтому приписывать форку конкретные API, компиляторы или низкоуровневые приёмы нельзя.
Работа с памятью важна для квантованной модели
Q4-квантование уменьшает объём представления весов по сравнению с форматами более высокой разрядности. Однако скорость всё равно зависит от того, как быстро система получает веса, читает промежуточные состояния и передаёт данные между вычислительными этапами.
ds4 сообщает об изменениях в работе с памятью с учётом M3 Ultra. Более рациональное движение данных уменьшает паузы, когда вычислительные блоки ждут следующую порцию информации. На генерации токенов даже небольшая экономия повторяется много раз.
Такая формулировка не означает подтверждённого снижения потребления памяти. В исходных сведениях нет замеров RAM, размера KV-кэша или поддержки других форматов квантования.
Поиск позиций в длинном контексте стал отдельной точкой ускорения
Проект переработал алгоритм поиска позиций в длинном контексте. При росте последовательности вспомогательные операции и обращения к состояниям начинают занимать ощутимую долю общего времени.
Контекст на 62 тыс. токенов создаёт гораздо более тяжёлую нагрузку, чем короткий чат. Ускоренный поиск позиций согласуется с результатом на длинном вводе: префилл достигает 550 токенов/с, а последующее декодирование идёт со скоростью 38 токенов/с.
Точная структура алгоритма не раскрыта. Нельзя утверждать, какие структуры данных используются, как меняется вычислительная сложность и насколько отдельное изменение повлияло на общий прирост.
Результаты на коротком и длинном контексте: где прирост заметнее
Одна цифра ускорения не описывает все режимы. Короткий диалог и обработка 62 тыс. токенов создают разную нагрузку на вычисления, память и вспомогательные операции.
Короткий контекст: 29 против 40 токенов в секунду
Заявление о росте декодирования на 38% основано на переходе с 29 до 40 токенов/с. Эта метрика ближе всего к повседневному локальному чату, где история ещё невелика и модель быстро переходит к генерации.
Темп 40 токенов/с позволяет получать текст плотным потоком после первого токена. Итоговая задержка всё равно складывается из префилла и декодирования, поэтому короткий запрос с длинной прикреплённой документацией нельзя оценивать только по этой цифре.
Контекст 62 тыс. токенов: 24 против 38 токенов в секунду
На длинном контексте исходная версия декодировала 24 токена/с, а форк ds4 достиг 38 токенов/с. Этот показатель относится к генерации после обработки всех 62 тыс. входных токенов.
По данным проекта, форк выигрывает на обоих этапах. Подготовка ввода занимает 113 секунд вместо 170, затем ответ генерируется со скоростью 38 токенов/с вместо 24. Это делает изменение особенно интересным для пользователей, которые регулярно держат в контексте крупные документы или длинную историю сессии.
Условия нагрузки нужно сохранять при сравнении. Если одна версия тестируется с коротким запросом, а другая получает десятки тысяч токенов, итоговые значения не показывают реальную разницу между движками. Похожая проблема возникает при оценке streaming-режима, о чём подробнее рассказано в "https://ai-manual.ru/article/qwen38-next-na-mac-m5-air-kak-moe-model-vedet-sebya-v-streaming-steke/"разборе Qwen3.8-Next на Mac M5 Air.
Насколько можно доверять цифрам и заявлению о точности
Цифры дают конкретную исходную точку, но пока опираются на сведения самого проекта. Независимых замеров в предоставленных материалах нет. Не раскрыты точные параметры среды, версия рантайма, настройки генерации и способ фиксации скорости.
Что подтверждает проверка на 100 промптах
ds4 сообщает, что изменения не привели к потере точности при проверке на 100 промптах. Такой тест полезен для поиска расхождений после переработки вычислительного пути, особенно если ускорение должно сохранять прежние результаты модели.
Проверку нельзя считать полным бенчмарком качества без списка промптов и критериев оценки. Неизвестно, сравнивались ли токены, итоговые ответы, численные отклонения или результаты выполнения задач. Не указано, охватывал ли набор код, рассуждения, многоязычные запросы и длинный контекст.
Каких данных не хватает для полного сравнения
- Независимых результатов на той же конфигурации M3 Ultra.
- Точных параметров тестовой среды и настроек запуска.
- Состава 100 промптов и метрик точности.
- Описания способа сравнения исходной версии и форка.
- Сведений о статусе изменений относительно основного репозитория GLM.
Эти пробелы не отменяют заявленный прирост. Они ограничивают строгость вывода и мешают заранее оценить воспроизводимость результата на другом локальном стеке.
Ограничения: это ускорение для M3 Ultra, а не универсальный рецепт
Изменения привязаны к архитектуре Apple M3 Ultra. Подтверждённых результатов для других поколений Apple Silicon, процессоров x86 или дискретных GPU в предоставленных сведениях нет.
Почему результаты нельзя автоматически переносить на M1, M2 и x86
M1, M2 и M3 Ultra различаются аппаратными характеристиками и поведением вычислительных задач. Форк, настроенный под конкретную платформу, может получить другой прирост или не получить его вовсе на другом чипе.
Та же граница относится к x86-системам и дискретным GPU. Пользователям таких платформ нужны отдельные тесты с тем же форматом GLM-5.3-Flash Q4 и подходящим рантаймом. Цифры 40 и 550 токенов/с нельзя использовать как прогноз для другого компьютера.
Что проверить перед подключением форка к локальному стеку
- Уточнить совместимость форка с используемым рантаймом и конкретным файлом GLM-5.3-Flash Q4.
- Измерить префилл и декодирование раздельно на типичных рабочих промптах.
- Повторить тест с длинным контекстом, если система обрабатывает документы, историю чата или RAG-выдачу.
- Сравнить ответы на собственном наборе задач, а не ограничиваться показателем tok/s.
- Проверить стабильность нескольких последовательных запусков и зафиксировать одинаковые параметры генерации.
Команды установки, поддерживаемые инструменты и статус форка следует брать из материалов проекта, когда такая информация доступна. В имеющихся данных этих инструкций нет, поэтому придумывать конкретную процедуру запуска было бы некорректно.
Вывод: кому имеет смысл следить за форком ds4
Форк ds4 представляет практический интерес для владельцев Apple M3 Ultra, которые запускают GLM-5.3-Flash Q4 локально. На коротком контексте декодирование выросло с 29 до 40 токенов/с. При 62 тыс. токенов модель обрабатывает ввод за 113 секунд вместо 170 и продолжает генерацию со скоростью 38 токенов/с вместо 24.
Особенно заметный эффект ожидается в задачах с большими документами, длинной историей диалога и RAG-контекстом. Заявление об отсутствии потери точности опирается на 100 промптов, но без опубликованной методики его следует трактовать осторожно.
Владельцам M1, M2, других конфигураций Apple Silicon и x86-систем пока рано ждать такого же прироста. Практическое решение состоит из трёх шагов: проверить доступность и совместимость форка, повторить замеры на своей нагрузке, затем сравнить качество ответов на рабочих задачах.