Навіть попри те, що геополітична дискусія навколо ШІ стає все більш напруженою після дій уряду США, спрямованих на обмеження нових моделей від Anthropic та OpenAI, китайський відкритий проєкт DeepSeek знову випустив ще одне відкриття, яке може докорінно змінити розвиток ШІ у світі.
У вихідні компанія випустила DSpark – нову систему з ліцензією MIT, розроблену для прискорення роботи великих мовних моделей без зміни суті того, що намагається сказати базова модель.
Найпростіше уявити це так: більшість чат-ботів зі штучним інтелектом пишуть, наче хтось переходить річку, стрибаючи з каменя на камінь. Вони обирають один маленький фрагмент тексту, потім наступний, потім наступний.
DSpark надає системі “розвідника”, який біжить на кілька кроків уперед, вгадує ймовірний шлях і дозволяє більшій моделі швидко перевірити, які кроки є безпечними. Коли здогадки правильні, модель працює швидше. Коли здогадки невдалі, DSpark намагається не витрачати час на їхню перевірку.
DeepSeek опублікував роботу разом із технічним документом, чекпойнтами моделі та DeepSpec – кодовою базою для тренування та оцінки систем спекулятивного декодування. Реліз доступний через публічні сторінки DeepSeek на GitHub та Hugging Face, і він розповсюджується за дозвільною, дружньою та поширеною ліцензією MIT, що робить цю нову техніку широко доступною для розробників, дослідників та комерційних підприємств, які бажають вивчати або адаптувати цей підхід.
Система спрямована на вирішення однієї з найдорожчих проблем розгортання ШІ: забезпечення швидкої роботи великих моделей для реальних користувачів, ефективно використовуючи апаратні ресурси для досягнення економічної доцільності. Це важливо для споживчих чат-ботів, помічників програмування, агентських робочих процесів та корпоративних систем ШІ, де користувачі очікують, що довгі відповіді будуть надходити швидко, а не виповзати слово за словом.
DeepSeek застосовує DSpark до своєї останньої передової відкритої моделі – DeepSeek-V4.
Зокрема, DeepSeek використав свою нову рамку DSpark на DeepSeek-V4-Flash, своїй вже оптимізованій за швидкістю моделі mixture-of-experts з 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% ближчі до того, “наскільки більше трафіку все ще може нести дорога”, коли стара система вже стає вузьким місцем.
Чому спекулятивне декодування має значення
Великі мовні моделі (LLMs) зазвичай генерують текст по одному токену за раз. Токен – це може бути слово, частина слова, розділовий знак або інший невеликий шматок тексту. Кожен новий токен залежить від уже створеного тексту, тому модель повинна постійно зупинятися, перевіряти повний контекст і вибирати наступну частину.
Це точно, але повільно. Це схоже на те, як старший редактор схвалює кожне слово, перш ніж автор зможе перейти до наступного. Редактор може бути чудовим, але процес створює вузьке місце.
Спекулятивне декодування, розроблене на ранніх етапах ери Transformer, намагається виправити це вузьке місце. Замість того, щоб просити велику модель генерувати кожен токен по одному, система використовує менший або легший “чернетковий” компонент для пропозиції кількох ймовірних наступних токенів. Потім велика модель паралельно перевіряє цю групу здогадок. Якщо чернетка вгадала правильно, система рухається вперед на кілька токенів одночасно. Якщо чернетка зробила невдалу здогадку, система відкидає невдалий токен і все, що за ним, додає виправлений токен і пробує знову.
Мета – швидкість без зміни бажаного виведення більшої моделі. У стандартній конфігурації спекулятивного декодування чернеткова модель не замінює цільову. Вона діє радше як помічник, який готує чернетку наступного речення для схвалення або відхилення старшим редактором.
Ідея з’явилася не раптово з появою сучасних великих мовних моделей. Ключовим попередником був 2018 рік, коли Мітчелл Стерн, Ноам Шазір та Якоб Ушзкорейт запропонували блоково-паралельне декодування для глибоких авторегресивних моделей. Їхній метод передбачав паралельне прогнозування кількох майбутніх кроків, а потім зберігав найдовший префікс, перевірений основною моделлю. Ця робота заклала значну частину інтуїції “чернетка-та-перевірка”, що лежить в основі подальших робіт зі спекулятивного декодування.
Лінія досліджень стала більш чіткою у 2022 році. Хемінг Ся, Тао Ге та співавтори представили SpecDec, підхід “чернетка-та-верифікація” для генерації послідовностей. Пізніше того ж року Янів Левіатан, Матан Калман та Йосі Матіас опублікували роботу “Fast Inference from Transformers via Speculative Decoding”, яка допомогла визначити сучасну версію техніки для мовних моделей на базі Transformer. Дослідники DeepMind у 2023 році представили тісно пов’язаний метод під назвою “speculative sampling” (спекулятивна вибірка).
Ці роботи 2022 та 2023 років є найчіткішими попередниками того, як спекулятивне декодування обговорюється в сучасних дослідженнях інференсу LLM: швидший процес чернетки пропонує токени, а більша цільова модель перевіряє їх таким чином, щоб зберегти розподіл виведення цільової моделі.
З того часу галузь швидко рухалася через кілька варіантів, включаючи окремі чернеткові моделі, багатотокенні голови прогнозування, деревоподібну верифікацію, методи на рівні ознак, такі як EAGLE, самоспекуляцію, додаткові голови стилю Medusa та паралельні/блокові драфтери, як-от DFlash.
Ключовим показником є не те, скільки токенів може вгадати чернеткова модель. Важливо, скільки з цих здогадок цільова модель насправді приймає. Довгі спекулятивні блоки допомагають лише тоді, коли достатня кількість запропонованих токенів проходить верифікацію. Інакше система витрачає ресурси на перевірку здогадок, які потім відкидаються.
Це контекст для DSpark. Спекулятивне декодування вже є встановленою технікою інференсу до випуску DeepSeek, з підтримкою у основних стеках розгортання та кількома конкуруючими дослідницькими підходами. Але це все ще не вирішена проблема. Прискорення значно залежать від чернеткової моделі, робочого навантаження, конфігурації розгортання та поточного рівня трафіку. Внесок DSpark полягає у вдосконаленні обох сторін компромісу: система намагається створювати більш зв’язні блоки токенів, а потім перевіряє лише ті частини цих блоків, які, ймовірно, будуть ефективними в реальних умовах обслуговування.
Що змінює DSpark
DSpark вирішує дві пов’язані проблеми: невдалі здогадки та марні перевірки.
По-перше, система використовує те, що DeepSeek називає напів-авторегресивною генерацією. Простими словами, це означає, що DSpark намагається поєднати швидкість із більшою увагою до послідовності.
Повністю паралельний драфтер може вгадувати кілька токенів одночасно, що швидко, але його пізніші здогадки можуть стати менш зв’язними, оскільки кожна позиція передбачається занадто незалежно. Чисто покроковий драфтер може краще відстежувати, як один токен веде до наступного, але він втрачає значну частину переваги у швидкості.
DSpark намагається зберегти найкраще з обох підходів. Він використовує паралельний “хребет” для більшої частини роботи з чернетками, а потім додає легку послідовну “голову”, яка дозволяє чернетці враховувати взаємозв’язки сусідніх токенів. У прикладі з роботи, паралельний драфтер може плутати ймовірні закінчення фраз, як-от “звичайно” та “без проблем”, створюючи незграбні комбінації, оскільки він вгадує позиції занадто окремо. Послідовний компонент DSpark допомагає системі робити так, щоб пізніші токени відповідали попереднім.
По-друге, DSpark додає верифікацію за рівнем впевненості (confidence-scheduled verification). Замість того, щоб постійно просити цільову модель перевіряти однакову кількість чернеткових токенів, DSpark оцінює, який префікс чернетки, ймовірно, буде прийнятий. Апаратний планувальник (hardware-aware scheduler) потім регулює, яка частина кожної чернетки повинна бути перевірена, базуючись як на впевненості моделі, так і на поточному навантаженні сервера.
Проста аналогія: коли ресторан порожній, шеф-кухар може перевірити більше роботи помічника кухаря. Коли на кухні ажіотаж, шеф приділяє увагу лише стравам, які, ймовірно, будуть готові. 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 не тільки на власних моделях V4, а й на Gemma та Qwen. Я б включив коментар Хана як реакцію спільноти, а не як єдиний доказ цього твердження. Сильнішою підтримкою є власні бенчмарки DeepSeek та випущені чекпоінти.
Результати офлайн-тестування також показують, чому робоче навантаження має значення. Структуровані завдання, такі як математика та код, як правило, мають вищу прийняту довжину, ніж відкриті діалоги. Це інтуїтивно зрозуміло: завершення коду або математичний крок часто мають менше розумних наступних кроків, ніж вільна розмова.
Для підприємств це означає, що методи, подібні до DSpark, можуть бути особливо привабливими для помічників програмування, агентів аналізу даних, автоматизації структурованих робочих процесів та інших сценаріїв, де виведення відповідає більш передбачуваним шаблонам.
Як підприємства можуть використовувати DSpark без DeepSeek-V4
Одне з найважливіших питань: чи є DSpark оптимізацією лише для DeepSeek, чи це ширший метод, який можна застосувати до інших моделей? Відповідь: це ширший метод, але не автоматичний плагін.
Для моделей з відкритими вагами шлях є відносно чітким. Підприємство, яке використовує Qwen, Gemma, Llama, Mistral, Granite, Command-style з відкритими вагами або іншу модель, яку воно розміщує самостійно, може тренувати або доналаштовувати чернетковий модуль стилю DSpark для цієї цільової моделі.
Потім команда вимірює коефіцієнт прийняття на своїх робочих навантаженнях та інтегрує планувальник верифікації у свій стек інференсу.
Це відрізняється від простого завантаження модуля DSpark від DeepSeek та приєднання його до будь-якої моделі. Спекулятивне декодування залежить від узгодженості між чернетковим модулем та цільовою моделлю. Чернетка повинна вивчити, що цільова модель, ймовірно, прийме. Драфтер, навчений для DeepSeek-V4, не буде автоматично правильним драфтером для іншої моделі, особливо якщо вона доналаштована на внутрішніх даних компанії або налаштована для іншої поведінки міркування.
Робочий процес DeepSpec відображає це. Він включає підготовку даних, регенерацію відповідей цільової моделі, побудову кешу цільової моделі, тренування чернеткової моделі та оцінку спекулятивного декодування. Для специфічного домену, чернеткова модель може потребувати додаткового доналаштування, особливо якщо цільова модель працює в режимі мислення чи міркування.
Для пропрієтарних моделей відповідь залежить від того, що контролює підприємство. Якщо компанія володіє або повністю розміщує ваги моделі та стек розгортання, вона теоретично може тренувати та розгортати драфтер стилю DSpark. Якщо модель доступна лише через розміщений API від постачальника, клієнт не може безпосередньо додати DSpark ззовні. Постачальник API міг би реалізувати подібну оптимізацію внутрішньо, але клієнт, як правило, не має доступу до циклу верифікації токенів, логітів, поведінки пакетної обробки або планувальника обслуговування, необхідних для роботи DSpark.
Це розходження має значення для корпоративних покупців. DSpark посилює аргументи на користь відкритої або самостійно розміщеної інфраструктури ШІ, оскільки надає передовим командам ще один важіль для підвищення швидкості та зниження витрат. Але це також показує, чому обслуговування моделей стає спеціалізованою дисципліною. Цінність полягає не лише у виборі моделі, а й у тому, наскільки інтелектуально ця модель працює.
Що розробники отримують від DeepSpec
Для розробників DeepSpec надає конкретний шлях реалізації для тренування та оцінки чернеткових моделей спекулятивного декодування. Він включає кроки з підготовки даних, тренування та оцінки на бенчмарках, разом із випущеними чекпоінтами для кількох сімейств відкритих моделей. Це робить реліз корисним не тільки для роботи DeepSeek-V4 з DSpark, але й для дослідників та команд інфраструктури, які вивчають, як додати швидше декодування до інших відкритих моделей.
Існують реальні застереження щодо розгортання. Власний README DeepSpec стверджує, що стандартна конфігурація підготовки даних для Qwen3-4B може вимагати приблизно 38 ТБ сховища кешу цільової моделі, а стандартні скрипти розраховані на один вузол з вісьмома GPU. Це робить реліз більш безпосередньо актуальним для лабораторій ШІ, хмарних команд та передових груп корпоративної інфраструктури ШІ, ніж для звичайних розробників додатків.
Тим не менш, випуск конвеєра тренування має значення. Багато оптимізацій інференсу з’являються лише у вигляді статей, нечітких бенчмарків або закритих виробничих звітів. DeepSpec надає розробникам щось ближче до набору креслень: не готовий корпоративний продукт, а спосіб відтворити, адаптувати та оцінити метод.
Раннє тестування спільнотою
Реліз вже привернув швидку увагу розробників. Розробник Рафаель Карісіо опублікував запит на злиття в GitHub, документуючи роботу DSpark для однопотокового DeepSeek-V4-Flash, повідомляючи про теплі результати: 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 є примітним, оскільки він поєднує виробничо-тестований метод, відкритий код, публічні чекпоінти та детальний документ. Головне нововведення – це не просто створення більшої кількості токенів. Це змушує систему більш вибірково визначати, яку спекулятивну роботу варто перевіряти.
Для корпоративних команд ширший урок полягає в тому, що наступна хвиля підвищення продуктивності ШІ надходитиме не лише від більших моделей. Вона також буде результатом розумніших способів роботи з моделями, які компанії вже мають – особливо коли ці компанії контролюють достатньою частиною стеку, щоб налаштувати модель, тренувати сумісний чернетковий модуль та оптимізувати рушій розгортання під реальні робочі навантаження.
Як захиститися (Порада CryptoDom): Щоб уникнути сповільнення роботи ваших систем через неоптимальне декодування, переконайтеся, що ваша інфраструктура розгортання ШІ регулярно оновлюється та оптимізується. Для корпоративних користувачів, це може включати розгляд використання відкритих моделей з можливістю кастомізації чернеткових модулів, а для всіх – постійне підвищення обізнаності щодо новітніх технік оптимізації інференсу, таких як спекулятивне декодування.
Джерело новини: venturebeat.com