Пока геополитические баталии вокруг ИИ накаляются — особенно после того, как правительство США взялось ограничивать новые модели Anthropic и OpenAI — китайский open-source любимец DeepSeek снова ворвался в игру. На этот раз с открытым релизом, который может перекроить глобальную разработку ИИ. В минувшие выходные компания выпустила DSpark — новую систему под лицензией MIT, которая заставляет большие языковые модели отвечать быстрее, не меняя сути их ответов.
Проще всего представить это так: большинство AI-чатботов пишут текст, как человек, переходящий реку по камням — один шаг за раз. Сначала один маленький кусочек текста, потом следующий, потом ещё один. DSpark даёт системе «разведчика», который бежит на несколько шагов вперёд, угадывает вероятный путь и позволяет основной модели быстро проверить, какие шаги безопасны. Если догадки верны — модель движется быстрее. Если слабы — DSpark старается не тратить время на их проверку.
DeepSeek опубликовал работу вместе с технической статьёй, контрольными точками модели и DeepSpec — кодовой базой для обучения и оценки спекулятивных систем декодирования. Релиз доступен на публичных GitHub и Hugging Face страницах DeepSeek под либеральной лицензией MIT, что делает новую технику широко доступной для разработчиков, исследователей и коммерческих предприятий, желающих изучить или адаптировать подход.
Система нацелена на одну из самых дорогих проблем развёртывания ИИ: обслуживать большие модели достаточно быстро для реальных пользователей, используя оборудование достаточно эффективно, чтобы экономика сошлась. Это критично для потребительских чатботов, ассистентов кода, агентных рабочих процессов и корпоративных AI-систем, где пользователи ожидают, что длинные ответы будут стримиться быстро, а не вылезать слово за словом.
DeepSeek применяет DSpark к своей собственной последней frontier open-модели — DeepSeek-V4. Конкретно: новый фреймворк DSpark натянут на DeepSeek-V4-Flash — уже оптимизированную по скорости 284-миллиардную модель со смесью экспертов и 13 миллиардами активных параметров — и на DeepSeek-V4-Pro, более глубокую и мощную 1,6-триллионную модель с 49 миллиардами активных параметров (обе поддерживают контекстные окна до миллиона токенов). Но глобальный смысл в том, что DSpark концептуально не ограничен DeepSeek-V4. Собственные тесты и выпущенные контрольные точки DeepSeek покрывают и другие семейства открытых моделей: Alibaba Qwen и Google Gemma с открытыми весами. Это значит, что корпоративные команды, работающие с open-weight моделями, в принципе могут обучать или донастраивать DSpark-подобные модули-черновики для своих целевых моделей. Это не переключатель, который любой API-клиент может щёлкнуть снаружи, но метод, который можно перенести на другие модели, если оператор контролирует веса и стек обслуживания.
Ошеломляющий прирост скорости генерации токенов во время инференса
В живых производственных тестах DeepSeek совокупная пропускная способность DSpark выросла на 51% для DeepSeek-V4-Flash при целевом показателе 80 токенов/с на пользователя и на 52% для DeepSeek-V4-Pro при 35 токенов/с на пользователя. При одинаковой загрузке системы DeepSeek сообщает об ускорении генерации на пользователя от 60% до 85% для V4-Flash и от 57% до 78% для V4-Pro по сравнению с предыдущим производственным базовым уровнем MTP-1.
Разные цифры скорости измеряют разное. Показатели 60–85% для V4-Flash и 57–78% для V4-Pro описывают, насколько быстрее отдельные пользователи получают сгенерированные токены, когда DeepSeek сравнивает DSpark с MTP-1 при одинаковой практической загрузке системы. Это более чистые цифры «скорости генерации». DeepSeek также сообщает о гораздо бóльших значениях — 661% и 406%, но они измеряют совокупную пропускную способность при очень строгих целях: 120 токенов/с на пользователя для V4-Flash и 50 токенов/с для V4-Pro. При таких целях старый базовый MTP-1, по словам DeepSeek, подходит к операционному обрыву: он может держать лишь небольшое число параллельных запросов, сохраняя такой уровень отзывчивости. DSpark избегает такого коллапса, поэтому процентная разница в общей производительности системы становится гораздо больше. Проще говоря: цифра 85% ближе к «насколько быстрее поездка ощущается пользователем» в сопоставимых условиях, а 661% и 406% — к «сколько ещё трафика дорога может пропустить», когда старая система уже в бутылочном горлышке.
Почему спекулятивное декодирование имеет значение
LLM обычно генерируют текст по одному токену за раз. Токеном может быть слово, часть слова, знак препинания или другой маленький кусочек текста. Каждый новый токен зависит от уже созданного текста, поэтому модель вынуждена постоянно останавливаться, проверять полный контекст и выбирать следующий кусок. Это точно, но медленно. Всё равно что заставлять старшего редактора утверждать каждое слово, прежде чем писатель перейдёт к следующему. Редактор может быть отличным, но процесс создаёт бутылочное горлышко.
Спекулятивное декодирование, разработанное в раннюю эпоху Transformer'ов, пытается это исправить. Вместо того чтобы заставлять большую модель производить каждый токен по одному, система использует меньший или более лёгкий компонент-черновик, который предлагает несколько вероятных следующих токенов. Затем большая модель проверяет этот пакет догадок параллельно. Если черновик угадал правильно, система продвигается сразу на несколько токенов. Если черновик ошибся, система отвергает плохой токен и всё, что после него, добавляет исправленный и пробует снова.
Смысл — в скорости без изменения целевого вывода большой модели. В стандартной конфигурации спекулятивного декодирования модель-черновик не заменяет целевую модель. Она действует скорее как ассистент, который готовит черновой вариант следующего предложения для старшего редактора — утвердить или отвергнуть.
Эта идея не возникла на пустом месте с сегодняшними большими языковыми моделями. Ключевой предшественник появился в 2018 году, когда Митчелл Стерн, Ноам Шазир и Якоб Ушкорейт предложили блочное параллельное декодирование для глубоких авторегрессионных моделей. Их метод предсказывал несколько будущих шагов параллельно, затем сохранял самый длинный префикс, подтверждённый основной моделью. Та статья заложила основу интуиции «черновик-и-проверка», лежащей в основе более поздних работ по спекулятивному декодированию.
Исследовательская линия стала более явной в 2022 году. Хемин Ся, Тао Ге и соавторы представили SpecDec — подход «черновик-и-верификация» для генерации последовательность-в-последовательность. Позже в том же году Янив Левиатан, Матан Калман и Йоси Матиас опубликовали «Fast Inference from Transformers via Speculative Decoding», что помогло определить современную версию техники для трансформерных языковых моделей. Исследователи DeepMind в 2023 году последовали с близким методом — спекулятивной выборкой.
Те работы 2022 и 2023 годов — самые явные предки того, как спекулятивное декодирование обсуждается в современных инференсных LLM-исследованиях: более быстрый процесс-черновик предлагает токены, а большая целевая модель верифицирует их так, чтобы сохранить распределение выходов целевой модели. С тех пор область быстро продвинулась через несколько вариантов: отдельные модели-черновики, головки многотокенного предсказания, древовидная верификация, методы на уровне признаков вроде EAGLE, само-спекуляция, дополнительные головки в стиле Medusa и параллельные/блочные черновики вроде DFlash.
Ключевая метрика — не сколько токенов модель-черновик может угадать, а сколько из этих догадок большая модель на самом деле принимает. Длинные спекулятивные блоки помогают только если достаточно предложенных токенов проходят верификацию. Иначе система тратит вычисления на проверку догадок, которые выбрасывает.
Таков контекст для DSpark. Спекулятивное декодирование — уже устоявшаяся техника инференса до релиза DeepSeek, с поддержкой в основных серверных стеках и множеством конкурирующих исследовательских подходов. Но это всё ещё не решённая проблема. Ускорения сильно зависят от модели-черновика, рабочей нагрузки, серверной установки и текущего уровня трафика. Вклад DSpark — улучшить обе стороны компромисса: он пытается составлять более связные блоки токенов-черновиков, а затем проверять только те части этих блоков, которые с высокой вероятностью окупятся в реальных серверных условиях.
Что меняет DSpark
DSpark решает две связанные проблемы: плохие догадки и напрасную проверку.
Во-первых, система использует то, что DeepSeek называет полуавторегрессионной генерацией. Простыми словами: DSpark пытается объединить скорость с чуть большей осознанностью последовательности. Полностью параллельный черновик может угадать несколько токенов за раз — это быстро, но его более поздние догадки становятся менее связными, потому что каждая позиция предсказывается слишком независимо. Чисто пошаговый черновик лучше отслеживает, как один токен ведёт к следующему, но теряет большую часть преимущества в скорости.
DSpark пытается взять лучшее от обоих миров. Он использует параллельную основу для большей части работы черновика, а затем добавляет лёгкую последовательную головку, которая позволяет черновику учитывать связи между соседними токенами. В примере из статьи: параллельный черновик может перепутать вероятные окончания фраз вроде «of course» и «no problem», порождая нелепые комбинации, потому что угадывает позиции слишком обособленно. Последовательный компонент DSpark помогает системе подгонять более поздние токены под ранние.
Во-вторых, DSpark добавляет верификацию с планированием по уверенности. Вместо того чтобы всегда просить целевую модель проверять одно и то же число токенов черновика, DSpark оценивает, какой префикс черновика вероятно выживет. Аппаратно-ориентированный планировщик затем регулирует, какую часть каждого черновика стоит проверять, исходя из уверенности модели и текущей серверной нагрузки.
Простая аналогия: когда в ресторане тихо, шеф-повар может проверить больше работы помощника. Когда кухня завалена заказами, шеф уделяет внимание только тем блюдам, которые скорее всего готовы. DSpark применяет похожую идею к сервису ИИ. При меньшем трафике система может позволить себе проверять более длинные префиксы черновиков. При высокой нагрузке она отсекает малодоверительные хвостовые догадки, прежде чем они съедят ёмкость батча, которая могла бы пойти другим пользователям.
DeepSeek представляет это как ответ на распространённый производственный компромисс. Статическое многотокенное черновичество может выглядеть привлекательно изолированно, но вредит пропускной способности при высокой конкурентности, потому что система продолжает проверять токены, которые скорее всего будут отвергнуты. Планировщик DSpark делает бюджет верификации гибким, а не фиксированным.
Офлайн-результаты: лучшее принятие черновиков на Qwen и Gemma
DeepSeek протестировал DSpark в офлайне на целевых моделях Qwen3-4B, Qwen3-8B, Qwen3-14B и Gemma4-12B на бенчмарках по математике, коду и чату. В этих тестах команда сравнивала DSpark с DFlash (параллельный