Форк движка Splash от Incoai научился работать с нативными несжатыми 8-битными весами и получил скомпилированные Metal-ядра под Apple Silicon. На M5 Pro с 64 ГБ объединённой памяти он выдаёт в среднем 36,9 tok/s против 26,5 tok/s у MTPLX-Q8 на тех же 8-битных весах и 9,9 tok/s у обычного MLX или llama.cpp.
Поводом для форка стал «обрыв рассуждений»: 4-битная и сжатая 8-битная квантизация дают числовой дрейф на сложных алгебраических выкладках, и модель срывается на многошаговых выводах. Полный несжатый 8-бит или 8-бит только в последних 8 слоях (56-63) эти ошибки убирает. Контекст в тестах автора доводили до 190 016 токенов: скорость декодирования держится в диапазоне 21-33 tok/s, а узким местом становится холодный prefill, до 4-5 минут на 180k+ токенов.
Практический вывод короткий. Форк закрывает конкретный сценарий: тяжёлую математику и длинный контекст на Mac с большим объёмом объединённой памяти. Официальный 4-битный Splash он не заменяет там, где хватает его качества и скорости, зато сохраняет совместимость с уже скачанными Q4-моделями. Все замеры сделаны только на Apple Silicon.
Что такое Splash и зачем понадобился форк с нативным 8-битом
Splash - скомпилированный движок спекулятивного декодирования на C++ и Metal, который Incoai сделала специально для Apple Silicon (описание форка на r/LocalLLaMA). Upstream Splash 1.0 разогнал спекулятивное декодирование 4-битных моделей примерно до 60 tok/s, но проверку пакетов жёстко привязал к 4-битным схемам: splash-packed-q4, schema 3/4. Загрузить что-то более точное движок отказывался.
Модель в тестах - Qwen3.8-27B, нативная vision-language модель с гибким управлением режимом размышления, построенная на архитектурной основе Qwen3.5 (карточка модели на Hugging Face). Она рассчитана на кодинг, профессиональные задачи, исследования и длинные агентные сценарии, поэтому точность на многошаговых выводах здесь рабочий параметр, а не абстракция.
Почему 4-бит перестал устраивать на сложных задачах
Проблема не в среднем качестве ответов. Агрессивная 4-битная квантизация упирается в «обрыв рассуждений»: на соревновательной математике и многошаговых выводах модель срывается в середине цепочки. Механика такая. Сжатие сглаживает логиты, а сглаженные логиты снижают acceptance rate драфтера. Чем чаще верификация откатывает предложенные токены, тем больше вычислений уходит впустую и тем выше шанс, что цепочка рассуждений свернёт не туда.
На однократных вопросах с коротким ответом это почти незаметно. Ломается именно вывод из нескольких шагов, где ошибка на одном шаге меняет условие следующего.
Что именно добавил форк: схема 5 и Metal Q8-ядра
Форк добавляет загрузку схемы 5 (splash-packed-q8, MDFL0008) и скомпилированные Metal Q8 tiled decode kernels. Валидация пакетов расширяется на splash-packed-q8, при этом 100% обратная совместимость с официальными Q4-моделями upstream Splash сохраняется. Старые 4-битные пакеты продолжают грузиться ровно как раньше.
Заявленный результат автора форка: 37-55 tok/s без деградации от квантизации. Держите в голове, что это заявление разработчика, а не независимо подтверждённое измерение. Схема 5 хранит веса в несжатом 8-битном виде, поэтому ядрам не нужно распаковывать блоки на каждом шаге декодирования.
Скорость и качество: сравнение Splash-HQ, Splash-Q8, MTPLX-Q8 и обычного MLX
Замеры шли на Apple Silicon, конкретно на M5 Pro с 64 ГБ объединённой памяти, при temperature=0.0 и на пяти стандартизированных доменах задач (данные бенчмарка). Условия важны: нулевая температура убирает случайность сэмплирования, а значит цифры описывают не типичный чат, а повторяемый прогон одной и той же задачи.
| Домен | Splash-Q4 | Splash-HQ (нативный 8-бит) | Splash-Q8 (сжатый) | MTPLX-Q8 | MLX / llama.cpp |
|---|---|---|---|---|---|
| Математика и логика | 83,3 | 54,8 | 52,7 | 28,5 | 9,9 |
| Кодинг и алгоритмы | 75,5 | 34,7 | 40,3 | 28,8 | 9,9 |
| Ограничения и перестановки | 59,3 | 39,3 | 37,4 | 27,7 | 9,9 |
| Предметные знания | 39,0 | 21,9 | 22,8 | 23,8 | 9,9 |
| Тонкий текст | 46,2 | 33,7 | 29,5 | 23,4 | 9,9 |
| Среднее | 60,7 | 36,9 | 36,5 | 26,5 | 9,9 |
Единицы - токены в секунду. Расклад по средним: Splash-Q4 (официальный 4-бит) 60,7 tok/s, Splash-HQ (нативный 8-бит) 36,9 tok/s, Splash-Q8 (сжатый 8-бит) 36,5 tok/s, MTPLX-Q8 (MTP D3) 26,5 tok/s, обычное авторегрессивное декодирование на MLX или llama.cpp 9,9 tok/s.
Главное сравнение - Splash-HQ против MTPLX-Q8: одинаковые 8-битные базовые веса, +39% по среднему и +92% на математике. Веса одни и те же, разница в бэкенде. Скомпилированный C++ Metal-путь тратит заметно меньше накладных расходов на диспетчеризацию, чем Python/MLX DraftCore.
У обычного стека другая логика: настройка llama.cpp для Qwen 3.6 27B на RTX 5090 даёт много простора для ручной подгонки параметров, но в этом замере базовый авторегрессивный путь упирается в 9,9 tok/s и проигрывает спекулятивному движку в разы.
Почему несжатый 8-бит обгоняет сжатый: механика acceptance rate
В спекулятивном декодировании итоговая скорость равна Draft Speed × Acceptance Rate. Сжатие весов ускоряет драфт, но сглаживает логиты и роняет acceptance rate, поэтому верификация чаще откатывает предложенные токены. Нативный 8-бит даёт более резкие логиты, меньше откатов и в сумме большую пропускную способность, хотя из памяти читается больше байт.
Отсюда «парадокс точности и скорости»: несжатый 8-бит занимает 27 ГБ и в среднем работает чуть быстрее сжатого, у которого 17 ГБ. 36,9 против 36,5 tok/s. Разница небольшая, но она показывает, что пропускная способность памяти в этой схеме не главный ограничитель.
Где форк особенно выигрывает: математика и структурированные рассуждения
На структурированной математике Splash-HQ выдаёт 54,8 tok/s, а преимущество над MTPLX достигает +92%. Причина в том, что здесь драфтер чаще угадывает: логиты резкие, шаги вывода предсказуемы, верификация редко откатывает блоки.
Честная оговорка: не на всех доменах нативный 8-бит впереди сжатого. В кодинге Splash-Q8 показал 40,3 tok/s против 34,7 у Splash-HQ, а в предметных знаниях 22,8 против 21,9. Там, где ответ менее структурирован, лёгкие веса иногда выигрывают за счёт скорости чтения и драфта. Форк целенаправленно закрывает математику и длинные выводы; универсального выигрыша во всех доменах нет.
«Обрыв рассуждений»: почему квантизация ломает сложную математику
«Обрыв рассуждений» проявляется как срыв конкретного вывода на многошаговой задаче. Среднее качество ответов при этом может оставаться приемлемым, и именно это делает проблему коварной: общие замеры её не ловят.
Как числовой дрейф накапливается в многошаговых выводах
Квантизация меняет веса, а вместе с ними значения логитов на каждом шаге генерации. Сдвиг по отдельности крошечный. В многошаговой алгебре каждый следующий шаг опирается на результат предыдущего, поэтому отклонения складываются, и на каком-то шаге модель выбирает неверную ветку, от которой уже не возвращается. На простом вопросе такой дрейф невидим, на соревновательной математике он превращается в неверный ответ при уверенном тоне изложения.
В замерах это видно косвенно: сжатая 8-битная версия на математике даёт 52,7 tok/s против 54,8 у несжатой, а ошибки автор форка фиксирует именно на сложных выкладках в 4-битном и сжатом режимах.
Частичное решение: 8-бит только в последних 8 слоях
Сэкономить память можно: 8-бит только в последних 8 слоях (56-63) устраняет ошибки так же, как полный несжатый 8-бит. Логика в том, что поздние слои сильнее влияют на итоговый выбор токена, поэтому их точность критичнее. Это эмпирическое наблюдение автора форка, а не формальное исследование, и переносить его на другие модели без проверки не стоит.
Выбор между полным 8-битом и частичным упирается в доступную память и характер задач. Для длинных алгебраических выводов логично брать максимальную точность, которую тянет конфигурация.
Контекст до 190 016 токенов: скорость декодирования и узкое место prefill
В тестах автора форка контекст доводили до 190 016 токенов, и скорость декодирования не падала: она держалась в диапазоне 21-33 tok/s (замеры контекстного масштабирования). Qwen3.8 архитектурно специфицирован с нативным контекстным окном 256k, то есть 262 144 токена, так что 190k - примерно три четверти заявленного лимита. Данные о масштабировании в обсуждении обрываются на 190k, поэтому поведение между 190k и 256k остаётся непроверенным.
Почему гибридная архитектура Qwen3.8 держит скорость на длинном контексте
Автор форка объясняет стабильность гибридной архитектурой модели: 48 линейных DeltaNet-слоёв и 16 полных attention-слоёв. Линейные слои обрабатывают длинную последовательность с меньшими вычислительными затратами, полные attention-слои отвечают за качество. На коротком контексте выигрыш незаметен, на длинном именно он не даёт скорости провалиться.
Оговорка по источникам: расклад по слоям и связь с узким местом prefill взяты из описания форка. В предоставленном фрагменте обсуждения эти детали явно не подтверждаются, поэтому воспринимайте их как объяснение автора, а не как независимо проверенный факт.
Холодный prefill: почему 180k+ токенов обрабатываются 4-5 минут
Холодный prefill - первичная обработка всего контекста перед генерацией первого токена. На 180k+ токенов он занимает до 4-5 минут, и узким местом становится именно он, а не декодирование. Разница между prefill и decode на длинном контексте подробно разбиралась на примере запуска Qwen 3.8 27B на одной RTX 5090: это два режима с разной нагрузкой на память и вычисления.
Практический смысл простой. Для интерактивной работы с длинным контекстом пятиминутная пауза перед первым ответом критична. Для пакетной обработки, где запрос запускается один раз и дальше идёт длинная генерация, она терпима.
Требования к железу и совместимость: что нужно для запуска
Все замеры сделаны только на Apple Silicon, конкретно на M5 Pro с 64 ГБ объединённой памяти. Другие платформы в этих тестах не участвовали.
Сколько памяти нужно для нативного 8-бита
Splash-HQ с нативными несжатыми 8-битными весами занимает 27 ГБ, Splash-Q8 со сжатым 8-битом 17 ГБ. Официальный 4-битный вариант требует меньше всех. Тестовая конфигурация с 64 ГБ объединённой памяти оставляет заметный запас, но данных о запуске на меньшем объёме в описанных тестах нет, поэтому назвать минимальный порог нельзя.
Для сравнения, в 12 ГБ VRAM укладывается Qwen3.8-Flash-Next в квантовании IQ3_XXS с 14-15 токенами в секунду, но это другой класс точности, другая модель и другая платформа.
Обратная совместимость с официальными Q4-моделями
Форк сохраняет 100% обратную совместимость с официальными Q4-моделями upstream Splash. Если у вас уже лежат 4-битные пакеты, они продолжат загружаться: валидация расширена на splash-packed-q8, а не заменена. Гарантий на все будущие версии upstream это не даёт, но текущие пакеты не ломаются.
Отдельная линия - форки под Apple Silicon для других моделей, например ds4 для GLM-5.3-Flash Q4 на M3 Ultra с ускорением декодирования и prefill. Принцип там тот же: выжать больше из Metal и объединённой памяти.
Стоит ли использовать форк Splash-HQ: практические выводы
Кому форк даст максимальную пользу
Форк попадает в конкретные сценарии: соревновательная математика, многошаговые алгебраические выводы, задачи с контекстом до 190k токенов, работа на Apple Silicon с большим объёмом объединённой памяти. Если вы гоняете сложные выкладки локально и уже видели, как 4-битная модель срывается в середине цепочки, смысл прямой: 54,8 tok/s на математике против 28,5 у MTPLX-Q8.
Если «обрыв рассуждений» вам незнаком и качества 4-битного Splash хватает, форк избыточен. Официальный Splash-Q4 в среднем быстрее, 60,7 tok/s, и занимает меньше памяти.
Ограничения и риски, о которых стоит знать
- Тестирование только на Apple Silicon, конкретно на M5 Pro с 64 ГБ объединённой памяти. Работа на других платформах и конфигурациях не проверялась.
- Холодный prefill до 4-5 минут на 180k+ токенов: для интерактивных задач с длинным контекстом это ощутимая задержка.
- Повышенные требования к памяти: 27 ГБ для Splash-HQ против 17 ГБ у сжатого варианта.
- Форк - энтузиастская разработка, а не официальный продукт Incoai.
- Цифры взяты из бенчмарков автора форка, независимого подтверждения нет. То же касается заявления о нулевой деградации от квантизации.
- Замеры идут при temperature=0.0, поведение при других настройках сэмплирования не описано.
- Данные по контексту обрываются на 190 016 токенов, хотя модель рассчитана на 256k.
Практический шаг: определите, упираетесь ли вы в ошибки на многошаговых выводах. Если да и памяти хватает, начните с несжатого 8-бита и сравните его с режимом 8-бит только в последних 8 слоях (56-63) на своих задачах. Если ошибок нет, оставайтесь на официальном 4-битном Splash и не платите памятью за точность, которая вам не нужна.