Ускорение локальных LLM на Apple Silicon: Разбор работы движка Splash и специфичность технологии DFlash 2
Разработка Inco AI представила новый инференсный движок Splash, оптимизированный для работы с языковыми моделями на процессорах Apple Silicon. Ключевым элементом ускорения здесь выступает механизм спекулятивного декодирования DFlash 2, позволяющий существенно повысить скорость генерации текста. В статье рассматриваются технические принципы работы, результаты независимых тестов, требования к оборудованию и особенности использования технологии квантования.
# Как Splash ускоряет локальные LLM на Mac: анализ инфраструктуры и результатов тестов
В экосистеме локальных языковых моделей (LLM) выбор движка для инференса часто сводится к одной метрике: количеству сгенерированных токенов в секунду. Однако такая цифра является упрощенным показателем. Она не учитывает различий между обработкой нового запроса, продолжением длинной истории переписки или обслуживанием нескольких одновременных сессий. Движок Splash от компании Inco AI предлагает подход, связывающий эти сценарии через специализированную архитектуру на базе Apple Silicon.
Специализированный движок и механизм DFlash 2
Splash переводит методологию специализированных вычислений, ранее использовавшуюся компанией для крупномасштабных инфраструктур, на уровень потребительского оборудования Apple. Для пользователей предусмотрены как встроенный интерфейс чата, так и API, совместимый с протоколами OpenAI и Anthropic, что позволяет интеграцию с внешними клиентами.
Техническая основа ускорения в Splash строится на методе спекулятивного декодирования. В классическом авторегрессионном процессе модель последовательно выбирает один следующий токен, что создает «узкое горлышко» в вычислениях. Спекулятивное декодирование вводит вспомогательную модель, которая генерирует блок из нескольких кандидатов параллельно. Основная, большая модель проверяет этот блок за один проход, принимая правильные токены и отвергая неточные. В реализации Splash роль вспомогательной модели выполняет DFlash 2.
Уникальной чертой DFlash 2 является предсказание черновика блока, что сокращает последовательные вычисления при подготовке предложений. Однако сам механизм имеет стоимость: подготовка черновика и его проверка также требуют ресурсов. Эффективность зависит от баланса между стоимостью операций и количеством принятых предсказаний. Splash решает эту задачу, используя вычислительные ядра Metal, специализированные под размеры и операции конкретных поддерживаемых моделей, при этом серверная часть, планировщик и кэш остаются общими.
*Важно отметить, что эта специализация имеет обратную сторону: появление нового семейства моделей требует от разработчиков создания отдельной поддержки в коде движка.*
Интерпретация результатов производительности
Оценивая эффективность Splash, необходимо сопоставлять его показатели с аналогичными конфигурациями на других движках, в частности, llama.cpp. Разработчики Inco AI провели тесты на моделях Qwen3.8-27B с квантованием Unsloth UD-Q4_K_M. Ниже приведены результаты генерации на различных конфигурациях GPU (от M5 Pro до M3 Max с 40 и 48 ядрами):
| Движок и режим | M5 Pro (20 ядер GPU) | M3 Max (40 ядер GPU) | M3 Max (48 ядер GPU) | | :--- | :--- | :--- | :--- | | llama.cpp (без спекулятивного декодирования) | 16 токенов/с | 17 токенов/с | 20 токенов/с | | llama.cpp (с MTP) | 27 токенов/с | 27 токенов/с | 20 токенов/с | | Splash | 74 токена/с | 92 токена/с | 74 токена/с |
На примере конфигурации M5 Pro отношение скорости Splash (74) к llama.cpp без спекулятивного декодирования (27) составляет примерно 2,7 раза. Важно понимать, что этот множитель не является универсальным гарантом ускорения любой задачи. Общее время выполнения запроса также зависит от обработки входного контекста, запуска инструментов и ожидания их результатов. Кроме того, показатели для квантования Q8_0 не линейно переносятся с других типов.
Существует также метрика кэширования. Для модели Qwen3.8-27B-Splash зафиксировано время до первого токена (TTFT) всего 282 мс при повторном запросе длиной 32K токенов. Для нового запроса такой же длины время составило 96 секунд. Это демонстрирует критическую важность разделения метрик задержки первого ответа и скорости последующей генерации, особенно для длинных диалогов, где повторное использование префикса позволяет сократить вычислительную нагрузку.
Практический опыт: перевод текстов на M3 Max
Тестирование было проведено на оборудовании Apple M3 Max с 40 ядрами GPU и 128 ГБ объединенной памяти под управлением macOS 27.0.0. В качестве модели использовалась сборка unsloth/Qwen3.8-27B-GGUF с квантованием Q8_0. Целью был перевод текстов различного объема на русский язык. Результаты четырех завершённых запросов показали следующую динамику:
| № запроса | Входных токенов | Из кэша (токенов) | Выходных токенов | Время до первого токена (TTFT) | Скорость генерации | | :--- | :--- | :--- | :--- | :--- | :--- | | 1 | 53 | 0 | 48 | 1,8 с | 52,8 токена/с | | 2 | 120 | 32 | 109 | 0,9 с | 36,3 токена/с | | 3 | 457 | 96 | 1 747 | 2,6 с | 43,0 токена/с | | 4 | 13 | 5 954 | 448 | 28 704 | 29,8 токена/с |
Заметно снижение скорости в запросе №4, что может быть связано с особенностями обработки超长кого контекста из кэша или ограничениями пропускной способности при работе с высокоплотным квантованием Q8_0.
Требования к системе и поддерживаемые модели
Актуальная версия Splash 1.1.0 поддерживает модели Qwen3.8-27B и Qwen3.6-35B-A3B. Доступны сборки в формате GGUF (включая варианты от UD-IQ1_S до Q8_0) и 4-битные сборки MLX. Исключения составляют веса основной модели в формате BF16 и специфическая точность UD-Q8_K_XL.
Минимальные системные требования: * Процессор: Apple Silicon M3 или новее. * Операционная система: macOS 26.4 и выше. * Память: Минимум 36 ГБ объединенной памяти для 4-битных версий, рекомендуется 48 ГБ. Для компактных GGUF-вариантов возможна работа на системах с 24 ГБ памяти.
Запуск осуществляется через Homebrew. Для скачивания весов при первом запуске также потребуется дополнительное место на диске для хранения вспомогательных моделей DFlash 2 и самих весов.
Ограничения и перспективы
Подход Splash наиболее оправдан для пользователей, работающих с поддерживаемыми архитектурами на мощных MacBook Pro или Mac Studio. Главные преимущества — ускорение вывода текста благодаря спекулятивному декодированию и снижение задержек при работе с длинными контекстами за счет эффективного кэширования. Ограничения обусловлены небольшим набором поддерживаемых архитектурных моделей в текущей версии, жесткими требованиями к объему памяти и необходимости держать актуальный стек ПО.
Перспективы технологии зависят от расширения списка поддерживаемых моделей и способности сохранять выигрыш в производительности на новых архитектурах. Поддержка форматов GGUF и MLX уже расширяет выбор доступных сборок, делая движок более гибким. Насколько выгодна эта специализация для конкретного пользователя, определят только итоговые измерения на его конкретном оборудовании и в рамках его рабочих задач.