Как Splash ускоряет локальные LLM на Mac

При выборе движка для локальной языковой модели хочется получить простой ответ: сколько токенов в секунду она выдаст на моём компьютере? Но за одной цифрой скрываются разные задачи: обработать новый запрос, продолжить длинный диалог, обслужить несколько обращений одновременно. Ускорение в одном сценарии не обязательно означает такой же выигрыш в остальных.

Splash от Inco AI интересен тем, как связывает эти задачи. Движок специализируется на нескольких моделях: под них подготовлены вычислительные ядра Metal, вспомогательные модели для генерации и правила управления памятью. Разберём этот подход, его ограничения и запуск на macOS. Возможности и требования приведены для версии 1.1.0 показатели скорости взяты из тестов разработчиков.

Что именно делает Splash

Inco AI разрабатывает инфраструктуру для выполнения языковых моделей. Splash переносит её подход к специализации вычислений на Apple silicon. Это движок, который загружает веса модели и выполняет вычисления на Mac.

Для пользователя предусмотрены встроенный чат и API, совместимые с OpenAI и Anthropic. Поэтому к серверу можно подключить совместимый клиент или программирующего агента. Код движка открыт под Apache 2.0, а лицензии весов моделей действуют отдельно. Возможности и условия распространения перечислены в репозитории проекта.

Как вспомогательная модель ускоряет генерацию

При обычном авторегрессионном декодировании модель последовательно выбирает следующий токен. Спекулятивное декодирование добавляет небольшую вспомогательную модель, которая предлагает продолжение заранее. Основная модель проверяет предложенный блок за один проход и принимает подходящую часть.

В Splash эту роль выполняет DFlash 2. Его особенность в том, что черновик блока тоже предсказывается параллельно. Это сокращает последовательную работу на этапе подготовки предложений.

Практический смысл можно представить так: вместо отдельного прохода основной модели для каждого следующего токена один проверочный проход может дать сразу несколько принятых токенов. Однако подготовка и проверка черновика тоже требуют вычислений. Поэтому размер блока сам по себе не показывает ускорение: важны стоимость этих операций и количество принятых предложений.

Splash сочетает этот механизм с ядрами Metal, рассчитанными на размеры и операции поддерживаемых моделей. Общими остаются сервер, планировщик и кэш. Цена такой специализации понятна: появление нового семейства моделей требует отдельной поддержки со стороны движка. Этот принцип описан в материале об архитектуре Splash.

Как читать показатели скорости

В документации производительности разработчики сравнивают Splash с llama.cpp на одинаковых весах Unsloth UD-Q4_K_M. Для Qwen3.8-27B опубликованы следующие результаты генерации:

Например, на M5 Pro отношение 74 к 27 даёт примерно 2,7 раза. Это сравнение с конкретной конфигурацией llama.cpp на конкретной нагрузке. Из таблицы нельзя заключить, что любой агент завершит задачу в 2,7 раза быстрее: он также обрабатывает входной контекст, запускает инструменты и ожидает их результаты. На Q8_0 эти показатели тоже автоматически не переносятся.

Ещё одна отдельная метрика связана с кэшем. В карточке первоначального пакета Qwen3.8-27B-Splash указаны 282 мс до первого токена при точном повторе закэшированного запроса длиной 32K. Для нового запроса такой длины приведены 96 секунд. Эти измерения относятся к первоначальному пакету и M5 Pro с 16 ядрами GPU и 48 ГБ памяти, то есть к другой серии тестов.

Для длинного диалога это существенное различие. Повторно используемый префикс позволяет сократить уже выполненную работу, но новый текст всё равно нужно обработать. Поэтому при выборе движка полезно отдельно сравнивать задержку первого ответа и скорость дальнейшей генерации.

Перевод текстов на моём M3 Max

Проверил Splash 1.1.0 на Apple M3 Max с 40 ядрами GPU и 128 ГБ объединённой памяти под macOS 27.0.0. Использовал unsloth/Qwen3.8-27B-GGUF:Q8_0 и переводил тексты разного размера с английского на русский.

Ниже показатели четырёх завершённых запросов из журнала Splash. Для каждого запроса приведён один результат.

Эти результаты относятся к переводу в Q8_0.

Какие модели и квантования поддерживаются

В Splash 1.1.0 доступны Qwen3.8-27B и Qwen3.6-35B-A3B в GGUF-сборках Unsloth и поддерживаемых 4-битных сборках MLX. Для GGUF поддерживаются варианты от UD-IQ1_S до Q8_0, включая смешанную точность. Исключения: UD-Q8_K_XL и веса основной модели в BF16.

Поддержку GGUF здесь следует понимать в пределах перечисленных моделей и типов весов. Само расширение файла не делает произвольную архитектуру совместимой со Splash.

Требования к Mac и месту на диске

По инструкции проекта, нужны M3 или новее и macOS 26.4+. Для 4-битных примеров указаны минимум 36 ГБ объединённой памяти и рекомендуемые 48 ГБ. Более компактные GGUF-варианты рассчитаны в том числе на Mac с 24 ГБ.

Установка и первая загрузка

Если Homebrew уже установлен, установка и запуск 4-битного варианта Qwen3.8-27B выполняются командами из описания релиза:

brew install incoai/tap/splash
splash serve --model 'unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M'

Для Q8_0 команда запуска выглядит так:

splash serve --model 'unsloth/Qwen3.8-27B-GGUF:Q8_0'

Во время первого запуска скачивается также подходящая DFlash2. После скачивания Splash подготавливает веса; последующие запуски используют подготовленные файлы.

В каких задачах подход имеет смысл

По устройству движка и опубликованным тестам Splash представляет интерес прежде всего для работы с поддерживаемыми моделями на подходящем Mac. Спекулятивное декодирование ускоряет выдачу текста, повторное использование контекста помогает в продолжительных диалогах.

Ограничения тоже следуют из устройства системы: небольшой набор архитектур, требования к памяти и дополнительное место для подготовки весов. При выборе стоит сопоставлять весь сценарий работы: модель и квантование, длину нового запроса, повторное использование контекста и время выполнения задачи целиком.

Перспектива Splash зависит от расширения списка моделей и сохранения выигрыша на новых архитектурах. Поддержка GGUF и MLX уже расширяет выбор доступных сборок. Насколько выгодна специализация для конкретного пользователя, определят измерения на его Mac и его задачах.