Liquid AI выпустила LFM2.5-DSpark: инференс ускорился до 3,2 раза

Liquid AI выпустила LFM2.5-DSpark: инференс ускорился до 3,2 раза

Liquid AI выпустила DSpark, технику спекулятивного декодирования для своего семейства моделей LFM2.5, и открыла код интеграции для llama.cpp и SGLang. Идея в том, что на этапе декодирования узкое место, не вычисления, а перекачка весов модели из DRAM в SRAM, поэтому лёгкая черновая модель предлагает несколько токенов подряд, а основная модель проверяет их все за один проход, деля стоимость загрузки весов на все проверенные токены. DSpark сочетает три компонента: параллельный блок в стиле DFlash, который строит скрытые состояния для всех токенов-кандидатов за один проход с учётом контекста основной модели; лёгкую последовательную головку, устроенную как цепь Маркова между соседними токенами, она повышает долю принятых токенов на поздних позициях; и верификатор с порогом уверенности, который оценивает вероятность того, что токен переживёт проверку, и заранее отбрасывает маловероятные хвосты, если их проверка обошлась бы дороже выигрыша.

Черновые модели обучены на расширенном наборе данных (SFT, диалоги, код, вызовы функций) по рецепту DSpark; первые версии, упрощённые модели только с механизмом внимания, 5 слоёв, блок размером 9, каждая обучена 15 эпох с отбором эпохи по доле принятых токенов, а не по минимуму функции потерь. Каждая черновая модель весит около 300 млн параметров. Поскольку жадное декодирование остаётся точным по построению, при отклонении токена его место занимает токен основной модели, итоговая последовательность идентична базовому жадному декодированию, и точность на бенчмарках (pass@1, exact match) не меняется.

Замеры проводились на пяти бенчмарк-наборах: throughput на устройстве измеряли с llama.cpp и Metal на MacBook Pro с чипом M4 Max (веса FP16 GGUF, до 256 токенов на выходе), throughput на GPU, с SGLang на одном H100 80 ГБ в BF16; везде блок DSpark размером 9, батч 1, температура 0. Для всех трёх черновых моделей результат, заметный прирост и на H100, и на M4 Max. Для LFM2.5-2.6B ускорение на MacBook особенно заметно: оно выводит интерактивность за пределы того, что дают большинство проприетарных облачных моделей (около 140 токенов/с). В сценариях с несколькими вызовами инструментов DSpark в среднем на 57% снижает задержку вызова функций для LFM2.5-2.6B. Для LFM2.5-1.2B-Instruct разброс доли принятых токенов между датасетами больше, поэтому ускорение колеблется, разница доходит до 52% в зависимости от распределения текста. Для LFM2.5-8B-A1B доля принятых токенов выше, чем у двух плотных моделей, но прирост на устройстве, всего 18% в среднем: причина в текущей реализации MoE в бэкенде Metal у llama.cpp и в том, что проверка k токенов за раз активирует больше экспертов и, соответственно, гоняет больше данных через память, чем один обычный шаг декодирования.

Чекпойнты черновых моделей для всех трёх размеров LFM2.5 (2.6B, 1.2B-Instruct, 8B-A1B) выложены на Hugging Face в форматах Safetensors и GGUF. Запуск с SGLang требует сборки с поддержкой DSpark для целей LFM2 (PR #31041 в SGLang), запуск с llama.cpp, соответствующей сборки (PR #27383 в llama.cpp).

Ключевые факты

  • DSpark, техника спекулятивного декодирования с черновыми моделями для семейства LFM2.5, код интеграции открыт для llama.cpp и SGLang с первого дня
  • Ускорение throughput: до 3,18 раза на GPU (H100 80 ГБ, SGLang, BF16) и до 2,87 раза на устройстве (M4 Max MacBook Pro, llama.cpp, FP16 GGUF)
  • Для LFM2.5-2.6B задержка вызова функций в сценариях с несколькими инструментами снижается в среднем на 57%
  • Черновые модели, около 300 млн параметров каждая, 5 слоёв, блок размером 9, обучены 15 эпох на данных SFT/диалогов/кода/вызовов функций
  • Точность не меняется: жадное декодирование остаётся точным по построению, поэтому результаты pass@1 и exact match идентичны базовой модели

Почему это важно

Декодирование в инференсе LLM обычно упирается не в вычисления, а в перекачку весов модели из памяти, спекулятивное декодирование решает эту проблему, распределяя стоимость загрузки весов на несколько токенов сразу. DSpark добавляет к этой идее три уточнения, параллельный блок предсказаний, последовательную головку в виде цепи Маркова и верификатор с порогом уверенности, что даёт заметный прирост скорости: до 3,18 раза на GPU и до 2,87 раза на устройстве, причём без потери точности, поскольку жадное декодирование остаётся точным по построению.

Кому это важно

В первую очередь, разработчикам, которые строят агентные и on-device приложения на базе LFM2.5: снижение задержки вызова функций на 57% в среднем напрямую влияет на отзывчивость таких систем. Также это важно для инженеров, которые уже используют llama.cpp или SGLang для развёртывания моделей и получают готовую интеграцию без переписывания пайплайна, и для тех, кто хочет приблизить локальный или edge-инференс по скорости к облачным сервисам.

Как это применить

Чекпойнты черновых моделей для всех трёх размеров LFM2.5 (2.6B, 1.2B-Instruct, 8B-A1B) выложены на Hugging Face в форматах Safetensors и GGUF. Для запуска с SGLang нужна сборка с поддержкой DSpark для LFM2 (PR #31041), целевая модель запускается с флагами --speculative-algorithm DSPARK и указанием черновой модели, размер блока читается из её config.json. Для llama.cpp нужна отдельная сборка (PR #27383) и флаги --spec-type draft-dspark с указанием файла черновой модели; базовый запуск, та же команда без спекулятивных флагов.

Можно ли доверять

Источник, собственный технический блог Liquid AI, все цифры получены в их же замерах на пяти бенчмарк-наборах (какие именно, не раскрыто), без независимой сторонней проверки. DSpark назван развитием подходов EAGLE-3 и DFlash, но прямого численного сравнения с ними в материале нет. При этом ключевое инженерное утверждение, что жадное декодирование при спекуляции остаётся точным по построению, стандартный и хорошо обоснованный факт для этого класса техник, а не маркетинговое допущение.

Риски и подводные камни

Ускорение сильно зависит от модели и нагрузки: для LFM2.5-1.2B-Instruct разброс между датасетами доходит до 52%, а для LFM2.5-8B-A1B прирост на устройстве, всего 18% из-за ограничений текущей реализации MoE в бэкенде Metal у llama.cpp. Для использования нужны нестандартные сборки llama.cpp и SGLang с ещё не влитыми PR, что добавляет трение при внедрении, а сама техника завязана на конкретное семейство моделей LFM2.5.