DSpark Speculative Decoding в llama.cpp: ускорение инференса на практике

В репозиторий llama.cpp добавлена экспериментальная поддержка DSpark - техники спекулятивного декодирования, которая ускоряет генерацию токенов без потери качества. Интеграция открывает доступ к методу для тысяч разработчиков, использующих llama.cpp в продакшене и исследованиях. Первые тесты на моделях DeepSeek-V4 и Bonsai AntiDoom показывают прирост скорости от 1.5× до 3× в зависимости от конфигурации драфт-модели и типа задачи.

DSpark решает главную проблему авторегрессионной генерации - последовательную природу предсказания токенов. Вместо того чтобы ждать каждый следующий токен от целевой модели, легковесная драфт-модель предлагает несколько гипотез параллельно, а целевая модель проверяет их за один проход. Такой подход превращает бутылочное горло инференса в конвейер.

В этой статье - детальный разбор архитектуры DSpark, инструкция по сборке llama.cpp с поддержкой метода, результаты замеров производительности на реальных задачах и анализ ограничений. Все цифры получены на стандартном железе, конфигурации воспроизводимы.

Что такое DSpark и почему это важно для llama.cpp

DSpark - это реализация спекулятивного декодирования, спроектированная под архитектурные особенности llama.cpp. В отличие от ранних подходов вроде Medusa, которые требуют модификации головы целевой модели, DSpark работает с немодифицированными чекпоинтами и использует отдельную драфт-модель. Это снижает порог входа: не нужно переобучать или патчить основную модель.

Спекулятивное декодирование: краткий ликбез

Авторегрессионная генерация - это цикл «предсказал токен → скормил его обратно в модель → предсказал следующий». Каждая итерация загружает веса модели в память и прогоняет через вычислительный граф. Узкое место - не арифметика, а пропускная способность памяти.

Спекулятивное декодирование обходит это ограничение. Драфт-модель, которая в 10-100 раз легче целевой, генерирует K гипотетических токенов за минимальное время. Целевая модель проверяет всю цепочку параллельно - это один проход через веса вместо K. Токены, совпавшие с предсказанием драфтера, принимаются. Первый несовпавший - перегенерируется целевой моделью. Acceptance rate (доля принятых токенов) определяет итоговое ускорение.

Аналогия: драфт-модель пишет черновик абзаца, целевая модель вычитывает его целиком и правит только ошибки. Без спекуляции целевая модель писала бы каждое слово с нуля, советуясь со всеми своими знаниями на каждом шаге.

DSpark: особенности и отличия

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 потребуется ручная сборка с флагами, описанными ниже.

Сборка llama.cpp с поддержкой DSpark

Текущая процедура сборки на 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

Замеры проводились на двух конфигурациях: серверной (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) соответственно.

Методология тестирования

Использовался набор из 50 промптов трёх категорий:

• Короткий диалог (до 100 токенов ответа) - имитация чат-бота.
• Генерация кода (200-500 токенов) - типичная задача для AI-ассистентов разработчика.
• Длинное рассуждение (500-1500 токенов) - аналитические задачи, где модель разворачивает цепочку мыслей.

Каждый промпт прогонялся 5 раз, результаты усреднялись. Измерялись: время prefill (pp), скорость генерации (tg, токенов/с), acceptance rate, общее время инференса. Baseline - та же модель без DSpark, с идентичными параметрами сэмплирования (temperature=0, greedy decoding).

Результаты на DeepSeek-V4

DeepSeek-V4 демонстрирует рост ускорения с длиной генерации. Короткие ответы дают скромные 1.6× - накладные расходы на загрузку драфт-модели и координацию двух инференсов съедают часть выигрыша. На длинных рассуждениях acceptance rate достигает 87.6%, и ускорение приближается к теоретическому пределу для --draft-n 5.

Примечательно, что prefill (обработка входного контекста) не ускоряется - DSpark работает только на фазе генерации. Для задач с длинным контекстом и коротким ответом общее время может измениться незначительно. Это согласуется с результатами нашего предыдущего исследования инференса DeepSeek-V4-Flash на B300, где DSpark деградировал в насыщенном батче.

Результаты на Bonsai AntiDoom

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 - экспериментальная фича. Разработчики прямо указывают в документации: возможны баги, расхождения в качестве генерации, несовместимость с некоторыми архитектурами. Перед внедрением в продакшен-пайплайн проведите 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) - минимальный рекомендованный драфтер для этой линейки.

Потребление памяти и накладные расходы

Замеры на серверной конфигурации (4× RTX 4090, 96 ГБ VRAM):

Для 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 сообщество провело десятки независимых тестов. Основные выводы с 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):

1. Поддержка beam search и constrained decoding (грамматики, JSON-схемы).
2. Автоматический подбор драфт-модели на основе анализа архитектуры целевой модели.
3. Интеграция с серверным режимом llama.cpp для конкурентной обработки запросов.
4. Оптимизация под GPU с раздельными пулами памяти для драфтера и целевой модели.

Внести свой вклад можно через тестирование на нестандартных конфигурациях и баг-репорты в GitHub Issues основного репозитория llama.cpp. Разработчики особенно заинтересованы в результатах на AMD GPU (ROCm) и Intel Arc - эти платформы пока протестированы слабо.

DSpark в llama.cpp - это не замена vLLM или SGLang для высоконагруженных продакшен-систем. Это инструмент для разработчиков, которым нужно быстрое локальное прототипирование, тестирование моделей и инференс на ограниченном железе. Экспериментальный статус означает, что метод будет активно дорабатываться, и текущие цифры ускорения - не предел. Следите за обновлениями репозитория.

Подписаться на канал