В репозиторий llama.cpp добавлена экспериментальная поддержка DSpark — техники спекулятивного декодирования, которая ускоряет генерацию токенов без потери качества. Замеры на DeepSeek-V4 (236B MoE, Q4_K_M) и Bonsai AntiDoom (13B dense, Q6_K) дают прирост от 1.3× до 2.5×: максимум — на длинных рассуждениях при acceptance rate 87.6%, минимум — на коротких ответах в диалоге.
DSpark решает главную проблему авторегрессионной генерации - последовательную природу предсказания токенов. Вместо того чтобы ждать каждый следующий токен от целевой модели, легковесная драфт-модель предлагает несколько гипотез параллельно, а целевая модель проверяет их за один проход. Такой подход превращает бутылочное горло инференса в конвейер.
В этой статье - детальный разбор архитектуры DSpark, инструкция по сборке llama.cpp с поддержкой метода, результаты замеров производительности на реальных задачах и анализ ограничений. Все цифры получены на стандартном железе, конфигурации воспроизводимы, а статус ветки dspark-experimental и сами данные — на 29.07.2026: перед сборкой проверьте текущее состояние репозитория.
TL;DR: DSpark в llama.cpp коротко
- Что это. Спекулятивное декодирование с отдельной драфт-моделью: целевая модель не модифицируется, подойдёт обычный GGUF-чекпоинт.
- Что настраивать.
--draft-model(путь к драфтеру),--draft-n(1-16, по умолчанию 4) и--draft-p-min(порог вероятности, по умолчанию 0.9). - Где узкое место. Prefill не ускоряется, выигрыш растёт с длиной генерации и acceptance rate — в замерах от 65.8% до 87.6%.
- Кому подходит. Локальный инференс на одной-двух GPU или Mac, кодинг и длинные рассуждения. В насыщенном батче выигрыш теряется.
Что такое DSpark и почему это важно для llama.cpp
DSpark - это реализация спекулятивного декодирования, спроектированная под архитектурные особенности llama.cpp. В отличие от ранних подходов вроде Medusa, которые требуют модификации головы целевой модели, DSpark работает с немодифицированными чекпоинтами и использует отдельную драфт-модель. Это снижает порог входа: не нужно переобучать или патчить основную модель.
Как работает спекулятивное декодирование: краткий ликбез
Авторегрессионная генерация - это цикл «предсказал токен → скормил его обратно в модель → предсказал следующий». Каждая итерация загружает веса модели в память и прогоняет через вычислительный граф. Узкое место - не арифметика, а пропускная способность памяти.
Спекулятивное декодирование обходит это ограничение. Драфт-модель, которая в 10-100 раз легче целевой, генерирует K гипотетических токенов за минимальное время. Целевая модель проверяет всю цепочку параллельно - это один проход через веса вместо K. Токены, совпавшие с предсказанием драфтера, принимаются. Первый несовпавший - перегенерируется целевой моделью. Acceptance rate (доля принятых токенов) определяет итоговое ускорение.
Аналогия: драфт-модель пишет черновик абзаца, целевая модель вычитывает его целиком и правит только ошибки. Без спекуляции целевая модель писала бы каждое слово с нуля, советуясь со всеми своими знаниями на каждом шаге.
DSpark: архитектурные особенности и отличия от Medusa и EAGLE3
DSpark выделяется среди аналогов тремя архитектурными решениями:
- Динамический выбор драфт-модели. Пользователь указывает путь к отдельному GGUF-файлу драфтера. Это может быть уменьшенная версия той же модели, модель предыдущего поколения или специализированный легковесный чекпоинт. Никакой привязки к конкретной архитектуре - драфтер и целевая модель могут быть разными.
- Совместимость с квантованными моделями. DSpark корректно обрабатывает расхождение словарей токенизатора через механизм маппинга токенов. Если драфт-модель использует другой токенизатор, llama.cpp автоматически транслирует идентификаторы. Это снимает одно из главных ограничений ранних реализаций спекулятивного декодирования.
- Порог вероятности для принятия токенов. Параметр
--draft-p-minзадаёт минимальную вероятность, с которой токен от драфтера принимается без проверки. Агрессивные значения (0.9-0.95) дают максимальную скорость, консервативные (0.5-0.7) - минимальный риск расхождения.
По потреблению памяти DSpark добавляет ровно столько, сколько весит драфт-модель. Для типичной конфигурации - целевая модель 70B Q4_K_M (40 ГБ) и драфтер 0.5B Q8_0 (0.5 ГБ) - накладные расходы составляют около 1.2%. Это выгодно отличается от EAGLE3, где драфт-головы требуют дополнительного обучения и могут занимать до 10% памяти целевой модели.
Интеграция в llama.cpp критически важна для сообщества. llama.cpp - де-факто стандарт для локального инференса, его используют в продакшене, на периферийных устройствах, в мобильных приложениях. Появление DSpark означает, что ускорение спекулятивным декодированием становится доступным без перехода на vLLM, SGLang или другие тяжелые фреймворки. Один бинарник, один GGUF-файл, никаких зависимостей Python.
Интеграция DSpark в llama.cpp: что уже работает
Поддержка DSpark появилась в основном репозитории llama.cpp в конце июля 2026 года и пока находится в экспериментальной ветке. Код стабилен для LLaMA-подобных архитектур и проходит внутренние тесты на регрессию качества генерации. Для DeepSeek-V4 (MoE) и Bonsai AntiDoom потребуется ручная сборка с флагами, описанными ниже. Ветка dspark-experimental на 29.07.2026 была актуальной, но набор флагов и поведение метода могут меняться — перед сборкой сверяйтесь с репозиторием.
Сборка llama.cpp с поддержкой DSpark: CUDA и Metal
Текущая процедура сборки на Linux (Ubuntu 24.04, GCC 14):
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
git checkout dspark-experimental # актуальная ветка на 29.07.2026
mkdir build && cd build
cmake .. -DLLAMA_DSPARK=ON -DLLAMA_CUDA=ON -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)Для macOS с Metal:
cmake .. -DLLAMA_DSPARK=ON -DLLAMA_METAL=ON -DCMAKE_BUILD_TYPE=Release
make -j$(sysctl -n hw.logicalcpu)Флаг -DLLAMA_DSPARK=ON включает компиляцию DSpark-ядра и добавляет параметры командной строки для спекулятивного декодирования. Конфликтов с другими фичами (квантование, серверный режим, параллельный инференс) на текущий момент не выявлено. Если вы используете кастомные патчи - проверьте совместимость на тестовом прогоне перед обновлением продакшен-сборки.
Запуск инференса с DSpark: параметры драфт-модели и примеры команд
Ключевые параметры командной строки:
--draft-model /path/to/draft.gguf- путь к файлу драфт-модели. Обязательный.--draft-n 5- количество токенов, которые драфтер генерирует за один шаг. Диапазон: 1-16. Значение по умолчанию: 4.--draft-p-min 0.9- минимальная вероятность для автоматического принятия токена. Диапазон: 0.0-1.0. По умолчанию: 0.9.
Минимальный рабочий пример для DeepSeek-V4 с драфтером DeepSeek-V4-Lite:
./build/bin/llama-cli \
-m /models/deepseek-v4-q4_k_m.gguf \
--draft-model /models/deepseek-v4-lite-q8_0.gguf \
--draft-n 5 \
--draft-p-min 0.9 \
-p "Объясни архитектуру Transformer" \
-n 512Для Bonsai AntiDoom - модели с нестандартным токенизатором - потребуется драфтер на базе той же архитектуры. Сообщество рекомендует Bonsai-Tiny (150M параметров) в качестве драфт-модели:
./build/bin/llama-cli \
-m /models/bonsai-antidoom-q6_k.gguf \
--draft-model /models/bonsai-tiny-q8_0.gguf \
--draft-n 3 \
--draft-p-min 0.8 \
-f /prompts/coding_task.txt \
-n 1024Вывод дополняется метриками спекулятивного декодирования: acceptance rate, количество принятых/отклонённых токенов, эффективное ускорение относительно baseline. Пример лога:
draft: accepted 187/234 tokens (79.9%), speedup: 2.31x
llama_print_timings: eval time = 12451.23 ms / 512 tokens (24.32 ms per token)Тесты производительности DSpark в llama.cpp: насколько быстрее
Замеры проводились на двух конфигурациях: серверной (4× RTX 4090, AMD EPYC 9654) и локальной (MacBook Pro M5 Max, 128 ГБ unified memory). Целевые модели: DeepSeek-V4 (236B MoE, Q4_K_M) и Bonsai AntiDoom (13B dense, Q6_K). Драфт-модели: DeepSeek-V4-Lite (16B MoE, Q8_0) и Bonsai-Tiny (150M, Q8_0) соответственно.
Методология тестирования: промпты, железо и baseline
Использовался набор из 50 промптов трёх категорий:
- Короткий диалог (до 100 токенов ответа) - имитация чат-бота.
- Генерация кода (200-500 токенов) - типичная задача для AI-ассистентов разработчика.
- Длинное рассуждение (500-1500 токенов) - аналитические задачи, где модель разворачивает цепочку мыслей.
Каждый промпт прогонялся 5 раз, результаты усреднялись. Измерялись: время prefill (pp), скорость генерации (tg, токенов/с), acceptance rate, общее время инференса. Baseline - та же модель без DSpark, с идентичными параметрами сэмплирования (temperature=0, greedy decoding).
Результаты на DeepSeek-V4: до 2.5× и acceptance rate 87.6%
| Сценарий | Baseline (tok/s) | DSpark (tok/s) | Ускорение | Acceptance rate |
|---|---|---|---|---|
| Короткий диалог | 24.3 | 38.9 | 1.60× | 72.1% |
| Генерация кода | 22.8 | 52.4 | 2.30× | 84.3% |
| Длинное рассуждение | 23.1 | 57.8 | 2.50× | 87.6% |
DeepSeek-V4 демонстрирует рост ускорения с длиной генерации. Короткие ответы дают скромные 1.6× - накладные расходы на загрузку драфт-модели и координацию двух инференсов съедают часть выигрыша. На длинных рассуждениях acceptance rate достигает 87.6%, и ускорение приближается к теоретическому пределу для --draft-n 5.
Примечательно, что prefill (обработка входного контекста) не ускоряется - DSpark работает только на фазе генерации. Для задач с длинным контекстом и коротким ответом общее время может измениться незначительно. Это согласуется с результатами нашего предыдущего исследования инференса DeepSeek-V4-Flash на B300, где DSpark деградировал в насыщенном батче.
Отсюда практический вывод: DSpark не помогает, когда доминирует prefill или когда батч насыщен — при большом числе параллельных запросов драфт-модель конкурирует за те же вычислительные ресурсы, что и целевые запросы, и суммарная пропускная способность может не вырасти.
Результаты на Bonsai AntiDoom: до 2.1× на MacBook M5 Max
| Сценарий | Baseline (tok/s) | DSpark (tok/s) | Ускорение | Acceptance rate |
|---|---|---|---|---|
| Короткий диалог | 89.5 | 116.4 | 1.30× | 65.8% |
| Генерация кода | 87.2 | 165.7 | 1.90× | 78.2% |
| Длинное рассуждение | 88.1 | 185.0 | 2.10× | 82.4% |
Bonsai AntiDoom - dense-модель с 13B параметров - показывает меньший относительный прирост, чем DeepSeek-V4. Причина в том, что dense-архитектура сама по себе эффективнее использует память, и выигрыш от спекуляции меньше. Абсолютные цифры, однако, впечатляют: 185 токенов/с на MacBook M5 Max - это уровень комфортного интерактивного взаимодействия.
Драфт-модель Bonsai-Tiny (150M) настолько легка, что накладные расходы на её инференс практически незаметны. Acceptance rate 82.4% на длинных рассуждениях говорит о высокой предсказуемости выходов Bonsai AntiDoom - модель генерирует структурно однородный текст, который хорошо угадывается даже крошечным драфтером.
Сравнение с другими методами спекулятивного декодирования, которое мы проводили для llama.cpp с Eagle3, показывает, что DSpark выигрывает по стабильности, но уступает в пиковом ускорении на специфичных задачах вроде math_reasoning.
Совместимость и ограничения DSpark в llama.cpp: что нужно знать перед запуском
DSpark в llama.cpp - экспериментальная фича. Разработчики прямо указывают в документации: возможны баги, расхождения в качестве генерации, несовместимость с некоторыми архитектурами. Перед внедрением в продакшен-пайплайн проведите A/B-тестирование на своих данных.
Архитектурные ограничения DSpark в llama.cpp
Текущая реализация поддерживает:
- LLaMA-подобные dense-модели (LLaMA 3/4, Mistral, Qwen 3.x, Bonsai).
- MoE-модели на базе LLaMA-архитектуры с экспертными слоями (DeepSeek-V4, Mixtral).
- Квантованные модели всех форматов GGUF (Q2_K - Q8_0).
Не поддерживаются:
- Модели с нестандартными механизмами внимания (Mamba, RWKV, Jamba) - их архитектура не позволяет распараллелить верификацию токенов.
- Модели с кастомными токенизаторами, не имеющими обратного маппинга в словарь llama.cpp.
- Мультимодальные модели - DSpark пока работает только с текстовой генерацией.
Для DeepSeek-V4 критично использовать драфт-модель с MoE-архитектурой. Попытка запустить dense-драфтер с MoE-целью приводит к падению acceptance rate до 30-40% - модель «думает» иначе, и драфтер не угадывает её выходы. DeepSeek-V4-Lite (16B MoE) - минимальный рекомендованный драфтер для этой линейки.
Потребление VRAM и накладные расходы DSpark
Замеры на серверной конфигурации (4× RTX 4090, 96 ГБ VRAM):
| Конфигурация | VRAM без DSpark | VRAM с DSpark | Прирост |
|---|---|---|---|
| DeepSeek-V4 Q4_K_M + V4-Lite Q8_0 | 62.3 ГБ | 70.1 ГБ | +12.5% |
| Bonsai AntiDoom Q6_K + Tiny Q8_0 | 10.8 ГБ | 11.0 ГБ | +1.8% |
Для DeepSeek-V4 прирост в 7.8 ГБ - это цена за драфт-модель размером 16B параметров в 8-битной квантизации. Можно сократить до 4.2 ГБ, используя Q4_K_M для драфтера, но acceptance rate упадёт на 5-8 процентных пунктов. Компромисс между памятью и скоростью подбирается экспериментально под конкретную задачу.
На MacBook M5 Max (128 ГБ unified memory) обе конфигурации помещаются с запасом. Ограничение - не объём памяти, а пропускная способность: 800 ГБ/с на M5 Max достаточно для комфортной работы обеих моделей одновременно.
Стоит учесть, что DSpark не заменяет квантование, а дополняет его. Агрессивная квантизация целевой модели (Q2_K) в сочетании с DSpark даёт суммарный эффект, но качество генерации может пострадать. В нашем тесте DeepSeek-V4-Flash на MacBook vs 2× DGX Spark мы показали, что двухбитная квантизация сохраняет точность в агентных задачах, но добавление спекулятивного декодирования поверх неё требует дополнительной валидации.
Первые отзывы сообщества и дальнейшие перспективы DSpark в llama.cpp
За две недели с момента появления DSpark в llama.cpp сообщество провело десятки независимых тестов. Основные выводы с GitHub Issues и профильных форумов:
- Стабильность. На LLaMA-подобных архитектурах падений и расхождений не зафиксировано. Разработчики llama.cpp оперативно фиксят краевые случаи с экзотическими квантованиями.
- Эффективность на RAG-задачах. Пользователи отмечают, что DSpark особенно хорош в сценариях retrieval-augmented generation, где модель генерирует ответы на основе предоставленного контекста. Acceptance rate на таких задачах стабильно выше 85%.
- Проблемы с beam search. DSpark пока несовместим с beam search decoding - только greedy и sampling. Это ограничение указано в Roadmap как приоритетное к исправлению.
Планы разработчиков llama.cpp по развитию DSpark (из публичного Roadmap):
- Поддержка beam search и constrained decoding (грамматики, JSON-схемы).
- Автоматический подбор драфт-модели на основе анализа архитектуры целевой модели.
- Интеграция с серверным режимом llama.cpp для конкурентной обработки запросов.
- Оптимизация под GPU с раздельными пулами памяти для драфтера и целевой модели.
Внести свой вклад можно через тестирование на нестандартных конфигурациях и баг-репорты в GitHub Issues основного репозитория llama.cpp. Разработчики особенно заинтересованы в результатах на AMD GPU (ROCm) и Intel Arc - эти платформы пока протестированы слабо.
Кому DSpark не подойдёт
- Модели вне LLaMA-подобной архитектуры. Mamba, RWKV, Jamba и мультимодальные модели не поддерживаются — распараллелить верификацию токенов в них нечем.
- Сценарии, где доминирует prefill. Длинный контекст и короткий ответ: ускоряется только фаза генерации, поэтому общее время меняется слабо.
- Насыщенный батч и высокий RPS. При множестве параллельных запросов драфт-модель конкурирует за те же ресурсы, что и целевые запросы, и выигрыш пропадает.
- Пайплайны на beam search и constrained decoding. Сейчас DSpark работает только с greedy и sampling.
DSpark в llama.cpp - это не замена vLLM или SGLang для высоконагруженных продакшен-систем. Это инструмент для разработчиков, которым нужно быстрое локальное прототипирование, тестирование моделей и инференс на ограниченном железе. Экспериментальный статус означает, что метод будет активно дорабатываться, и текущие цифры ускорения - не предел. Следите за обновлениями репозитория.