Liquid AI выпустила DSpark: ускорение инференса LFM2.5 до 3,2 раза
Liquid AI выпустила DSpark, семейство черновых моделей для спекулятивного декодирования, ускоряющих инференс всей линейки LFM2.5: LFM2.5-1.2B-Instruct, LFM2.5-2.6B и MoE-модели (Mixture-of-Experts, «смесь экспертов») LFM2.5-8B-A1B. Чекпоинты для всех трёх моделей выложены на Hugging Face в форматах Safetensors и GGUF, а интеграция DSpark с моделями LFM открыта в основных репозиториях (апстриме) движков llama.cpp и SGLang, правда, пока в виде отдельных PR, ещё не вошедших в стандартные релизы (подробнее, в разделе «Как это применить»).
Фаза декодирования у языковых моделей обычно упирается не в вычисления, а в память: основное время уходит на то, чтобы прогнать веса модели из DRAM в SRAM, а не на саму арифметику. Спекулятивное декодирование решает эту проблему так: лёгкая черновая модель предлагает несколько токенов-кандидатов подряд, а целевая (основная) модель проверяет их все за один проход, распределяя стоимость загрузки весов сразу на несколько токенов. Среди известных подходов такого рода в посте называют EAGLE-3, DFlash и, самый свежий, DSpark, который сочетает три компонента: параллельную базовую архитектуру в стиле DFlash, обусловленную контекстными признаками целевой модели и выдающую скрытые состояния для всех черновых токенов за один проход; лёгкую последовательную «голову», устроенную как цепь Маркова между соседними токенами, она добавляет зависимость между токенами и повышает долю принятых предложений на более поздних позициях; и верификатор, который заранее прогнозирует вероятность того, что каждый токен «выживет» при проверке, и отсекает участки с низкой уверенностью там, где их проверка обошлась бы дороже, чем дала бы экономии.
Черновые модели обучены по рецепту DSpark на более крупной и разнообразной смеси данных, охватывающей SFT (дообучение с учителем), диалоги, код и вызовы функций. Первые версии, упрощённые модели только с механизмом внимания, с 5 слоями и размером блока 9; для каждой черновой модели прогнали 15 эпох по всему датасету и выбрали не эпоху с наименьшей ошибкой, а эпоху с наибольшей долей принятых токенов. Итоговые черновые модели получились небольшими, около 300 млн параметров каждая. При этом качество не страдает: при жадном декодировании черновой токен принимается, только если он совпадает с распределением целевой модели, а при несовпадении его место занимает токен самой целевой модели, то есть итоговая последовательность по построению идентична обычному жадному декодированию без черновика, а значит точность по бенчмаркам (pass@1 или точное совпадение) не меняется вовсе.
Скорость проверяли на двух видах оборудования: пропускную способность на GPU замеряли через SGLang на одной видеокарте H100 (80 ГБ, BF16), а на устройстве, через llama.cpp с экспериментальными ядрами Metal на MacBook Pro с чипом M4 Max (веса FP16 GGUF, до 256 выходных токенов); в обоих случаях размер блока DSpark, 9, размер батча, 1, температура, 0, оценка велась на пяти бенчмарк-датасетах. Все три черновые модели дали заметный прирост пропускной способности и на GPU, и на устройстве: заголовок поста называет пиковое ускорение на GPU «до 3,2 раза» (в теле та же цифра приведена как «3,18», без явного знака «×»), а пик на устройстве, «до 2,87 раза». Результаты по моделям заметно различаются. Для LFM2.5-2.6B ускорение на MacBook особенно заметно, интерактивность выходит за пределы того, что предлагает большинство проприетарных облачных моделей (около 140 токенов в секунду, в зависимости от датасета), а в сценариях с несколькими вызовами функций задержка падает в среднем на 57%. Для LFM2.5-1.2B-Instruct доля принятых токенов куда сильнее зависит от датасета, поэтому ускорение колеблется, разброс достигает 52% в зависимости от распределения текста. А у MoE-модели LFM2.5-8B-A1B доля принятых токенов выше, чем у двух плотных моделей линейки, но прирост на устройстве в среднем составляет всего 18%, авторы объясняют это текущей реализацией MoE в бэкенде Metal у llama.cpp и тем, что проверка k токенов задействует больше экспертов и, соответственно, больше трафика весов, чем один обычный шаг декодирования.
Чтобы использовать DSpark с SGLang, нужна отдельная сборка с поддержкой DSpark для моделей LFM2 (PR #31041): целевая модель запускается с флагом --speculative-algorithm DSPARK и путём к черновой модели, а размер блока считывается прямо из config.json черновой модели; базовый вариант без ускорения, та же команда без спекулятивных флагов. Для llama.cpp нужна своя сборка (PR #27383) и флаг --spec-type draft-dspark; в этом режиме декодирование точное, целевая модель проверяет каждый предложенный токен, поэтому жадный вывод совпадает с выводом одной только целевой модели, а в логах по каждому ответу видно число предложенных и принятых токенов (draft_n / draft_n_accepted). Чекпоинты черновых моделей для всех трёх размеров, LFM2.5-2.6B-DSpark, LFM2.5-1.2B-Instruct-DSpark и LFM2.5-8B-A1B-DSpark, доступны на Hugging Face и в Safetensors, и в GGUF.
Ключевые факты
- Liquid AI выпустила DSpark, черновые модели (~300 млн параметров каждая) для спекулятивного декодирования, ускоряющие инференс всей линейки LFM2.5: LFM2.5-1.2B-Instruct, LFM2.5-2.6B и MoE-модель LFM2.5-8B-A1B.
- Пик ускорения, до 3,2 раза на GPU (H100 80 ГБ, SGLang, BF16; в теле поста та же цифра дана как 3,18, без знака «×») и до 2,87 раза на устройстве (MacBook Pro на чипе M4 Max, llama.cpp); оба замера, при размере блока DSpark 9, батче 1 и температуре 0 на пяти бенчмарк-датасетах.
- У LFM2.5-2.6B задержка при нескольких вызовах функций падает в среднем на 57%, у LFM2.5-1.2B-Instruct ускорение сильно зависит от датасета (разброс до 52%), а у MoE-модели LFM2.5-8B-A1B прирост на устройстве, в среднем лишь 18% из-за особенностей реализации MoE в бэкенде Metal у llama.cpp.
- Качество не страдает: при жадном декодировании черновой токен принимается, только если совпадает с распределением целевой модели, иначе его заменяет токен самой целевой модели, поэтому итоговый вывод и точность по бенчмаркам (pass@1, точное совпадение) в точности такие же, как без черновика.
- Поддержка DSpark добавлена в llama.cpp и SGLang (нужны отдельные сборки, PR #27383 и PR #31041), а чекпоинты всех трёх черновых моделей в форматах Safetensors и GGUF уже доступны на Hugging Face.
Почему это важно
Фаза декодирования у языковых моделей упирается не в вычисления, а в память, большую часть времени съедает перекачка весов из DRAM в SRAM, а не сама арифметика. Спекулятивное декодирование, один из главных способов обойти это ограничение: лёгкая черновая модель предлагает токены наперёд, а целевая модель проверяет их пачкой за один проход, распределяя стоимость загрузки весов сразу на несколько токенов. DSpark, версия этого подхода для линейки LFM2.5 от Liquid AI, которая сочетает параллельную генерацию токенов, зависимость между соседними токенами через цепь Маркова и верификатор, отсекающий заведомо слабые продолжения до полной проверки. Важно, что ускорение здесь не платится точностью: при жадном декодировании итоговый вывод по построению идентичен варианту без черновика, поэтому пропускная способность растёт, до 3,2 раза на GPU и до 2,87 раза на устройстве, а качество ответов не меняется вовсе.
Кому это важно
В первую очередь, тем, кто уже развернул или планирует развернуть модели LFM2.5 через llama.cpp или SGLang: на локальном железе (тот же MacBook на чипе M4 Max) или на GPU вроде H100. Отдельно полезно тем, кто строит агентные сценарии с частыми вызовами функций, именно там, по данным поста, задержка у LFM2.5-2.6B падает сильнее всего, в среднем на 57%. Разработчикам других семейств моделей DSpark в этом виде не пригодится: черновые модели обучены специально под LFM2.5 и с другими моделями не совместимы.
Как это применить
Чекпоинты черновых моделей, LFM2.5-2.6B-DSpark, LFM2.5-1.2B-Instruct-DSpark и LFM2.5-8B-A1B-DSpark, выложены на Hugging Face в Safetensors и GGUF. Для SGLang нужна отдельная сборка с поддержкой DSpark для моделей LFM2 (PR #31041): целевая модель запускается с флагом --speculative-algorithm DSPARK и путём к черновой модели, размер блока подтягивается из config.json черновой модели, а сравнить с базовым вариантом можно, просто убрав спекулятивные флаги из той же команды. Для llama.cpp нужна своя сборка (PR #27383) и флаг --spec-type draft-dspark; в этом режиме декодирование точное, целевая модель проверяет каждый предложенный токен, а в логах по каждому ответу видно число предложенных и принятых токенов.
Можно ли доверять
Источник, блог самой Liquid AI на её странице на Hugging Face; ни в посте, ни в фактуре нет независимого стороннего замера, все цифры это собственные измерения авторов на выбранных ими пяти бенчмарк-датасетах. При этом заявление о точности устроено сильнее, чем обычный маркетинговый тезис: раз черновой токен подставляется только при совпадении с целевой моделью, а при расхождении используется токен именно целевой модели, итоговый вывод при жадном декодировании идентичен базовому по самой конструкции метода, а не по отдельному замеру точности. Есть и техническая деталь: заголовок поста округляет пиковое ускорение на GPU до «3,2 раза», тогда как в теле та же цифра дана как «3,18» без явного знака «×», то есть кратность именно этого числа сам источник явно не подписывает. Абсолютных цифр пропускной способности «до» DSpark пост не приводит, результаты по каждой модели даны только как множители и проценты, что не позволяет проверить исходные значения самостоятельно. Ни один конкретный исследователь в посте не назван, только организация Liquid AI.
Риски и подводные камни
Заявленное ускорение сильно разнится между тремя моделями: если для LFM2.5-2.6B цифры близки к заголовочным, то у LFM2.5-1.2B-Instruct ускорение колеблется в зависимости от датасета (разброс до 52%), а MoE-модель LFM2.5-8B-A1B получает на устройстве в среднем лишь 18%, заметно меньше заявленных «до 3,2 раза». Причина для MoE-модели, не сам DSpark, а нынешняя реализация MoE в бэкенде Metal у llama.cpp: проверка нескольких токенов задействует больше экспертов и больше трафика весов, чем один обычный шаг декодирования, так что прирост может отличаться на другом железе или в других движках инференса. Использовать DSpark нельзя «из коробки» на стандартных релизах, нужны отдельные, ещё не вошедшие в стандартные релизы сборки llama.cpp и SGLang (PR #27383 и PR #31041 соответственно), а сами черновые модели работают только с LFM2.5 и не переносятся на другие семейства моделей.