DeepSeek публикует исходный код DSpark, новой платформы, позволяющей ускорить вывод LLM-данных до 85%.
Карл Франзен
Несмотря на то, что геополитическая дискуссия вокруг ИИ становится все более напряженной после действий правительства США по ограничению новых моделей от Anthropic и OpenAI, китайский проект DeepSeek, пользующийся популярностью благодаря открытому исходному коду, возвращается с еще одним открытым релизом, который может вновь изменить развитие ИИ во всем мире.
В минувшие выходные компания выпустила DSpark, новую систему, лицензированную MIT, предназначенную для ускорения обработки больших языковых моделей без изменения основной идеи модели.
Проще всего это представить так: большинство чат-ботов с искусственным интеллектом пишут текст, как человек, переходящий реку по одному камню за раз. Они выбирают один небольшой фрагмент текста, затем следующий, затем следующий.
DSpark предоставляет системе разведчика, который движется на несколько шагов вперед, угадывает вероятный путь и позволяет более крупной модели быстро проверить, какие шаги безопасны. Когда предположения верны, модель работает быстрее. Когда предположения неверны, DSpark старается не тратить время на их проверку.
Компания DeepSeek опубликовала результаты своей работы в виде технической статьи, контрольных точек модели и DeepSpec — кодовой базы для обучения и оценки систем спекулятивного декодирования. Релиз доступен на общедоступных страницах DeepSeek в GitHub и Hugging Face под свободной, дружелюбной и общепринятой лицензией MIT, что делает новую методику широко применимой для разработчиков, исследователей и коммерческих предприятий, желающих изучить или адаптировать этот подход.
Система направлена на решение одной из самых дорогостоящих проблем внедрения ИИ: быстрая обработка больших моделей для реальных пользователей при одновременном эффективном использовании оборудования для обеспечения экономической целесообразности. Это важно для потребительских чат-ботов, помощников по программированию, агентных рабочих процессов и корпоративных систем ИИ, где пользователи ожидают быстрой передачи длинных ответов, а не их пословного вывода.
Компания DeepSeek применяет DSpark в своей новейшей открытой модели DeepSeek-V4.
В частности, DeepSeek использовала свою новую платформу DSpark на DeepSeek-V4-Flash, своей уже оптимизированной по скорости модели, объединяющей 284 миллиарда параметров и 13 миллиардов активных параметров, а также на DeepSeek-V4-Pro, своей более продуманной и мощной модели с 1,6 триллионами параметров и 49 миллиардами активных параметров (обе модели поддерживают контекстные окна до одного миллиона токенов).
Однако более широкое значение имеет то, что DSpark концептуально не ограничивается DeepSeek-V4. Собственные тесты DeepSeek и выпущенные контрольные точки охватывают другие открытые семейства моделей, включая открытые веса Qwen от Alibaba и открытые веса Gemma от Google.
Это означает, что корпоративные команды, использующие модели с открытыми весами, в принципе, могут обучать или дорабатывать черновые модули в стиле 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.
По данным DeepSeek, при достижении этих целевых показателей её старая базовая версия MTP-1 приближается к операционному пределу, то есть она может поддерживать работу лишь небольшого количества одновременных запросов, сохраняя при этом необходимый уровень быстродействия.
DSpark предотвращает дальнейшие подобные сбои, поэтому процентная разница в общей производительности системы становится намного больше. Проще говоря: показатель 85% ближе к тому, «насколько быстрее ощущается поездка для пользователя» в сопоставимых условиях, в то время как показатели 661% и 406% ближе к тому, «сколько еще трафика может проехать дорога», когда старая система уже создает узкое место.
Почему важна спекулятивная декодировка
Модели LLM обычно генерируют текст по одному токену за раз. Токен может представлять собой слово, часть слова, знак препинания или другой небольшой фрагмент текста. Каждый новый токен зависит от уже сгенерированного текста, поэтому модели приходится постоянно делать паузы, проверять полный контекст и выбирать следующий фрагмент.
Это верно, но медленно. Это как если бы старший редактор утверждал каждое слово, прежде чем автор сможет перейти к следующему. Редактор может быть превосходным, но этот процесс создает узкое место.
Спекулятивное декодирование, разработанное в начале эпохи Трансформеров, пытается устранить это узкое место. Вместо того чтобы просить большую модель генерировать каждый токен по отдельности, система использует меньший или более лёгкий компонент черновика, чтобы предложить несколько вероятных следующих токенов. Затем большая модель проверяет эту группу предположений параллельно. Если черновик угадал правильно, система переходит к следующему токену сразу на несколько позиций. Если черновик сделал неверное предположение, система отклоняет неверный токен и все, что следует за ним, добавляет исправленный токен и пытается снова.
Суть в скорости без изменения предполагаемого результата работы более крупной модели. В стандартной схеме спекулятивного декодирования черновая модель не заменяет целевую модель. Она скорее выступает в роли помощника, который готовит черновой вариант следующего предложения для утверждения или отклонения старшим редактором.
Эта идея не возникла на пустом месте в контексте современных больших языковых моделей. Ключевым предшественником стало предложение Митчелла Стерна, Ноама Шазира и Якоба Ушкорейта в 2018 году о блочном параллельном декодировании для глубоких авторегрессивных моделей. Их метод предсказывал несколько будущих шагов параллельно, а затем сохранял самый длинный префикс, подтвержденный основной моделью. Эта статья заложила основу для большей части интуиции метода «черновика и проверки», лежащей в основе более поздних работ по спекулятивному декодированию.
В 2022 году направление исследований стало более четким. Хеминг Ся, Тао Ге и их соавторы представили SpecDec — подход, основанный на предварительном тестировании и проверке, для генерации последовательностей. Позже в том же году Янив Левиафан, Матан Калман и Йосси Матиас опубликовали статью «Быстрый вывод из трансформеров с помощью спекулятивного декодирования», которая помогла определить современную версию этой техники для языковых моделей на основе трансформеров. В 2023 году исследователи DeepMind представили тесно связанный метод, называемый спекулятивной выборкой.
Статьи 2022 и 2023 годов являются наиболее четкими предшественниками того, как спекулятивное декодирование обсуждается в современных работах по выводу на основе LLM: более быстрый процесс создания черновика предлагает токены, а более крупная целевая модель проверяет их способом, разработанным для сохранения распределения выходных данных целевой модели.
С тех пор эта область быстро развивалась, претерпевая множество изменений, включая отдельные модели черновиков, многотокеновые генераторы прогнозов, проверку на основе деревьев, методы на уровне признаков, такие как EAGLE, самоспекуляцию, дополнительные генераторы в стиле Medusa и параллельные/блочные генераторы черновиков, такие как DFlash.
Ключевым показателем является не количество токенов, которые может угадать черновая модель, а то, сколько из этих предположений фактически принимает более крупная модель. Длинные спекулятивные блоки помогают только в том случае, если достаточное количество предложенных токенов проходит проверку. В противном случае система тратит вычислительные ресурсы на проверку предположений, которые затем отбрасываются.
Именно в таком контексте работает DSpark. Спекулятивное декодирование уже было устоявшейся техникой вывода до выхода DeepSeek, поддерживаемой основными стеками обслуживания и множеством конкурирующих исследовательских подходов. Но это всё ещё не решённая проблема. Ускорение в значительной степени зависит от модели создания черновиков, рабочей нагрузки, конфигурации обслуживания и текущего уровня трафика. Вклад DSpark заключается в улучшении обеих сторон компромисса: он пытается создавать более согласованные блоки токенов, а затем проверять только те части этих блоков, которые, вероятно, принесут результат в реальных условиях обслуживания.
Какие изменения вносит DSpark?
DSpark решает две взаимосвязанные проблемы: неверные предположения и ненужные проверки.
Во-первых, система использует то, что DeepSeek называет полуавторегрессивной генерацией. Проще говоря, это означает, что DSpark пытается сочетать скорость с большей осведомленностью о последовательности.
Полностью параллельный алгоритм может угадывать несколько жетонов одновременно, что быстро, но его последующие предположения могут стать менее согласованными, поскольку каждая позиция предсказывается слишком независимо. Чисто пошаговый алгоритм может лучше отслеживать, как один жетон ведет к следующему, но теряет значительную часть преимущества в скорости.
DSpark стремится объединить лучшие стороны обоих подходов. Для большей части работы по составлению черновика используется параллельная архитектура, а затем добавляется облегченный последовательный компонент, позволяющий учитывать взаимосвязи между соседними токенами. В приведенном в статье примере параллельный редактор может перепутать вероятные окончания фраз, такие как «конечно» и «нет проблем», создавая неудобные комбинации, поскольку он слишком сильно различает позиции. Последовательный компонент DSpark помогает системе согласовывать более поздние токены с более ранними.
Во-вторых, DSpark добавляет проверку по принципу планирования на основе уверенности. Вместо того чтобы всегда запрашивать у целевой модели проверку одного и того же количества черновых токенов, DSpark оценивает, какой префикс чернового варианта, скорее всего, останется в игре. Затем планировщик, учитывающий аппаратные характеристики, корректирует объем проверяемых черновых вариантов в зависимости от уверенности модели и текущей нагрузки на сервер.
Простая аналогия: когда в ресторане тихо, шеф-повар может больше времени уделять проверке работы помощников повара. Когда кухня переполнена, шеф-повар уделяет внимание только тем блюдам, которые, скорее всего, уже готовы. DSpark применяет аналогичную идею к системе автоматического обслуживания с использованием ИИ. При меньшей нагрузке система может позволить себе проверять более длинные префиксы черновиков. При большей нагрузке она отсеивает ненадежные предположения, прежде чем они займут ресурсы пакета, которые могли бы быть использованы для других пользователей.
DeepSeek позиционирует это как решение распространенной проблемы при производстве. Статическая многотокенная обработка может выглядеть привлекательно сама по себе, но может снизить пропускную способность при высокой параллельности, поскольку система постоянно проверяет токены, которые, скорее всего, будут отклонены. Планировщик DSpark делает бюджет проверки гибким, а не фиксированным.
Результаты в офлайн-режиме: лучшее принятие черновиков среди пользователей Qwen и Gemma.
Компания DeepSeek провела тестирование DSpark в автономном режиме на целевых моделях Qwen3-4B, Qwen3-8B, Qwen3-14B и Gemma4-12B по математическим, программным и чат-тестам.
В ходе этих тестов команда сравнила DSpark с DFlash, параллельным генератором токенов, и Eagle3, авторегрессивным генератором токенов. В статье сообщается о допустимой длине на один раунд декодирования — показателе того, сколько токенов в среднем проходят проверку.
В трех вариантах размеров Qwen3, DSpark улучшил макросреднюю допустимую длину по сравнению с Eagle3 на 30,9%, 26,7% и 30,0% соответственно. По сравнению с DFlash, он улучшил допустимую длину на 16,3%, 18,4% и 18,3%. В статье также говорится, что эти улучшения распространяются и на Gemma4-12B.
Это подтверждает точку зрения разработчика Даниэля Хана, который отметил на форуме X, что DeepSeek продемонстрировал работоспособность DSpark за пределами собственных моделей DeepSeek V4, включая Gemma и Qwen. Я бы отнёс мнение Хана к реакции сообщества, а не к единственному доказательству этого утверждения. Более убедительные доказательства исходят из собственных тестов DeepSeek и выпущенных контрольных точек.
Результаты, полученные в офлайн-режиме, также показывают, почему важна рабочая нагрузка. Структурированные задачи, такие как математические вычисления и программирование, как правило, имеют более высокую допустимую продолжительность, чем открытый чат. Это интуитивно понятно: при выполнении автозавершения кода или математического задания часто бывает меньше разумных дальнейших шагов, чем в свободном разговоре.
Для предприятий это означает, что методы в стиле DSpark могут быть особенно привлекательны для помощников в программировании, агентов анализа данных, автоматизации структурированных рабочих процессов и других областей, где результаты следуют более предсказуемым закономерностям.
Как предприятия могут использовать DSpark без DeepSeek-V4
Один из важнейших вопросов заключается в том, является ли DSpark оптимизацией, применимой только к DeepSeek, или это более широкий метод, который можно применять и к другим моделям. Ответ: более широкий метод, но не автоматическая интеграция.
Для моделей с открытыми весами путь относительно ясен. Предприятие, использующее модели с открытыми весами типа Qwen, Gemma, Llama, Mistral, Granite, Command или другую модель, размещенную на его собственном сервере, может обучить или доработать модуль-шаблон в стиле DSpark для этой целевой модели.
Затем команда проведет оценку качества на собственных рабочих нагрузках и интегрирует планировщик верификации в свой стек обработки данных для вывода результатов.
Это отличается от простой загрузки модуля DSpark от DeepSeek и его подключения к любой модели. Спекулятивное декодирование зависит от соответствия между черновым модулем и целевой моделью. Черновик должен научиться тому, что целевая модель, скорее всего, примет. Черновик, обученный для DeepSeek-V4, не будет автоматически подходящим для другой модели, особенно для той, которая была доработана на внутренних данных компании или настроена на другое поведение при рассуждениях.
Рабочий процесс DeepSpec отражает это. Он включает в себя подготовку данных, повторную генерацию ответов целевой модели, создание целевого кэша, обучение черновой модели и оценку приемлемости спекулятивного декодирования. Для использования в конкретных предметных областях черновая модель может потребовать дополнительной тонкой настройки, особенно если целевая модель работает в режиме мышления или рассуждения.
В случае с проприетарными моделями ответ зависит от того, что контролирует предприятие. Если компания владеет или полностью размещает веса модели и стек обслуживания, она теоретически может обучить и развернуть инструмент для создания моделей в стиле DSpark. Если модель доступна только через размещенный API от поставщика, клиент не может напрямую добавить DSpark извне. Поставщик API может реализовать аналогичную оптимизацию внутри компании, но клиент, как правило, не имеет доступа к циклу проверки токенов, логикам, поведению пакетной обработки или планировщику обслуживания, необходимым для работы DSpark.
Это различие имеет значение для корпоративных покупателей. DSpark усиливает аргументы в пользу открытой или самостоятельно размещаемой инфраструктуры ИИ, поскольку предоставляет опытным командам еще один рычаг для повышения скорости и снижения затрат. Но это также показывает, почему развертывание моделей становится специализированной дисциплиной. Ценность заключается не только в выборе модели, но и в том, насколько интеллектуально эта модель управляется.
Что получают разработчики от DeepSpec
Для разработчиков DeepSpec предоставляет конкретный путь реализации для обучения и оценки черновых моделей спекулятивного декодирования. Он включает этапы подготовки данных, обучения и оценки производительности, а также выпущенные контрольные точки для нескольких открытых семейств моделей. Это делает релиз полезным не только для запуска DeepSeek-V4 с DSpark, но и для исследователей и групп, занимающихся инфраструктурой, изучающих способы добавления более быстрого декодирования в другие открытые модели.
Существуют реальные нюансы развертывания. В собственном файле README компании DeepSpec указано, что для стандартной настройки подготовки данных на Qwen3-4B может потребоваться примерно 38 ТБ целевого кэш-хранилища, а стандартные скрипты предполагают наличие одного узла с восемью графическими процессорами. Это делает данный релиз более актуальным для лабораторий ИИ, облачных команд и сложных корпоративных групп по созданию инфраструктуры ИИ, чем для обычных разработчиков приложений.
Тем не менее, публикация конвейера обучения имеет значение. Многие оптимизации вывода появляются только в виде статей, расплывчатых бенчмарков или утверждений о завершении разработки. DeepSpec предоставляет разработчикам нечто большее, чем просто набор чертежей: не готовый корпоративный продукт, а способ воспроизвести, адаптировать и оценить метод.
Раннее тестирование в сообществе
Релиз уже быстро привлек внимание разработчиков. Разработчик Рафаэль Карисио опубликовал запрос на слияние в GitHub, документирующий работу с однопотоковым DeepSeek-V4-Flash DSpark, сообщив о результатах бенчмарка: 26,33 токена в секунду без спекулятивного декодирования, 39,88 токена в секунду с MTP-1 и примерно 60 токенов в секунду с DSpark — примерно в 1,5 раза выше, чем с MTP-1, и в 2,3 раза выше, чем без спекулятивного декодирования.
В более позднем сообщении в той же ветке обсуждения было зафиксировано среднее значение за пять запусков — 60,31 токенов в секунду, что в 1,51 раза выше, чем у MTP-1, и в 2,29 раза выше, чем у неспекулятивного декодирования.
В той же работе также указывается на важное практическое ограничение: в реальных многоэтапных сессиях кодирования производительность может снижаться по мере уменьшения количества принятых черновиков с ростом контекста. Другими словами, DSpark может ускорить декодирование, но качество принятых черновиков по-прежнему определяет, насколько быстро система сможет это сделать на практике.
Это полезная проверка реальности. DSpark — это не волшебство. Всё по-прежнему зависит от того, насколько предсказуемы следующие токены и насколько хорошо разработчик придерживается целевой модели. Но ранние этапы реализации показывают, что заявления DeepSeek не являются чисто академическими. Разработчики уже тестируют метод в практических средах обслуживания и сообщают о результатах, близких к ожиданиям, изложенным в статье для однопотоковой обработки.
Итог
DSpark демонстрирует, какой объем производительности остается доступным на уровне вывода, даже если базовая архитектура модели остается неизменной. Поскольку компании, занимающиеся ИИ, конкурируют по качеству моделей, длине контекста и цене, эффективность декодирования становится еще одним важным полем битвы.
Более быстрая генерация означает меньшую задержку для пользователей, более высокую пропускную способность для поставщиков и лучшие экономические показатели для команд, внедряющих открытые модели в масштабах предприятия.
Выпуск DeepSeek примечателен тем, что он сочетает в себе проверенный в производственной среде метод, открытый код, публичные контрольные точки и подробную статью. Главное нововведение заключается не просто в увеличении количества токенов, а в повышении избирательности системы в отношении того, какие спекулятивные разработки заслуживают проверки.
Для корпоративных команд более важный вывод заключается в том, что следующая волна повышения производительности ИИ будет обусловлена не только увеличением размеров моделей. Она также будет связана с более эффективными способами запуска уже имеющихся у компаний моделей — особенно когда эти компании контролируют достаточный объем стека для настройки модели, обучения совместимого чернового модуля и оптимизации механизма развертывания под реальные рабочие нагрузки.
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Оцените материал:
