Ускорение инференса LFM2.5: технология DSpark повышает скорость генерации до 3,2 раз

Разработчики искусственного интеллекта продолжают искать эффективные способы оптимизации работы больших языковых моделей. Одним из наиболее заметных прорывов последнего времени стало ускорение инференса LFM2.5 за счет интеграции архитектуры DSpark. Данный подход позволил увеличить пропускную способность вычислений до 3,18 раза на графических процессорах (GPU) и до 2,87 раза на локальных пользовательских устройствах. Кроме того, для модели LFM2.5-2.6B среднее время задержки при вызове функций (function-calling) сократилось на 57%, что открывает новые возможности для работы автономных локальных агентов. Важно, что поддержка интеграции DSpark, совместимой с LFM, уже в первый день была добавлена в популярные инструменты llama.cpp и SGLang.

Технологический базис: как достигается ускорение инференса LFM2.5

Традиционно фаза декодирования при работе больших языковых моделей ограничена пропускной способностью памяти (memory-bound). Основная задержка возникает не из-за высокой вычислительной сложности, а из-за необходимости постоянной передачи весов модели из системной памяти DRAM во внутреннюю память ускорителя SRAM. Спекулятивное декодирование решает эту проблему за счет использования легкой «черновой» модели (draft model), которая генерирует потенциальные токены-кандидаты. Затем основная целевая модель проверяет их все за один прямой проход. Такой подход распределяет накладные расходы на загрузку тяжелых весов сразу на все проверяемые токены.

Три компонента архитектуры DSpark

За последние годы было предложено несколько методов спекулятивного декодирования, включая EAGLE-3 и DFlash. Новейший подход DSpark объединяет в себе три ключевых элемента:

• Параллельная основа (backbone) в стиле DFlash, которая ориентируется на контекст целевой модели и генерирует скрытые состояния для всех черновых токенов за один проход.
• Легкая последовательная марковская голова (Markov head), моделирующая связи между соседними токенами, что повышает вероятность их принятия на более поздних позициях.
• Верификатор с планированием уверенности, который оценивает вероятность выживания каждого токена и отсекает низкодетализированные суффиксы, если их проверка обойдется дороже, чем потенциальная выгода.

Разработчики применили рецепт DSpark, задействовав расширенный и диверсифицированный набор данных, охватывающий инструкции (SFT), диалоги, программный код и сценарии вызова функций. Согласно результатам исследований, первые версии черновых моделей представляют собой упрощенные архитектуры, состоящие только из механизмов внимания (attention-only), с 5 слоями и размером блока 9. Для каждого черновика было проведено 15 эпох обучения на всем датасете. В качестве финальной версии выбиралась эпоха с наивысшим показателем принятия токенов (acceptance rate), а не с минимальными потерями (loss). В итоге получились компактные модели объемом около 300 млн параметров.

Структура параметров этих черновых моделей распределяется следующим образом:

• Декодер (5 слоев): 241,2 млн параметров для всех версий (LFM2.5-1.2B-Instruct, LFM2.5-8B-A1B и LFM2.5-2.6B).
• Проекция скрытого состояния (Hidden-state projection): 21,0 млн параметров для всех версий.
• Марковская голова (Markov head): 33,6 млн для версии 1.2B-Instruct и по 65,5 млн для версий 8B-A1B и 2.6B.
• Нормализация и голова уверенности (Norms + confidence head): 27,5 тыс. параметров для всех версий.
• Общий объем: 295,7 млн параметров для LFM2.5-1.2B-Instruct и по 327,7 млн параметров для LFM2.5-8B-A1B и LFM2.5-2.6B.

Сохранение точности и практические тесты производительности

При жадном декодировании (greedy decoding) черновой токен принимается только тогда, когда он полностью соответствует распределению вероятностей целевой модели. Если токен отклоняется, его место занимает токен самой целевой модели. Таким образом, результирующая последовательность символов абсолютно идентична базовому жадному алгоритму. Это означает, что точность работы на бенчмарках (метрики вроде pass@1 или exact match) остается неизменной.

Разработанные черновые модели DSpark для семейства LFM2.5 сразу получили поддержку в llama.cpp (реализация построена на базе официального репозитория с экспериментальными ядрами Metal) и SGLang (на основе официального кода DSpark для этой платформы).

Измерения локальной производительности проводились с использованием llama.cpp и Metal на ноутбуке MacBook Pro с процессором M4 Max с использованием весов FP16 GGUF и ограничением до 256 выходных токенов. Тестирование производительности GPU осуществлялось с помощью SGLang на одном ускорителе NVIDIA H100 (80 ГБ) в формате BF16. В обеих конфигурациях размер блока DSpark составлял 9, размер пакета (batch size) — 1, а температура — 0. Оценка проводилась на пяти наборах тестовых данных.

Все три черновые модели продемонстрировали значительный рост пропускной способности как на мощном серверном ускорителе H100, так и на клиентском устройстве M4 Max. Особенно заметен прирост для LFM2.5-2.6B на MacBook: скорость работы превзошла показатели большинства проприетарных облачных моделей, достигая интерактивности уровня около 140 токенов в секунду в зависимости от конкретного набора данных.

Результаты тестирования: скорость на серверах и локальных устройствах

Для детальной оценки эффективности технологии разработчики провели серию независимых бенчмарков на различных конфигурациях оборудования — от мощных серверных ускорителей NVIDIA H100 до локальных чипов Apple M4 Max. Тесты охватывали популярные датасеты, моделирующие разные типы задач: сложные математические вычисления (MATH500), генерацию программного кода (HumanEval, MBPP), логические рассуждения (GSM8K) и общие диалоговые сценарии (MT-Bench).

Показатели производительности модели LFM2.5-2.6B

Для базовой полноразмерной модели LFM2.5-2.6B интеграция алгоритма DSpark позволила добиться существенного прироста скорости. В сценариях с использованием различных инструментов (multi-tool) DSpark снижает задержку в среднем на 57%. Подробные результаты тестирования на контрольных наборах данных выглядят следующим образом:

• MATH500: средний показатель принятия токенов (из 10 предложенных драфт-моделью) составил 5,42. На ускорителе NVIDIA H100 зафиксировано ускорение в 3,06 раза (рост производительности с 326 до 1000 токенов в секунду), а на M4 Max — в 2,25 раза (с 61 до 137 токенов/с).
• HumanEval: показатель принятия составил 4,54. Ускорение вычислений на H100 достигло 2,56 раза (с 326 до 835 токенов/с), на Apple M4 Max — 2,63 раза (с 61 до 161 токенов/с).
• MBPP: уровень принятия зафиксирован на отметке 4,71. Скорость выросла в 2,64 раза на серверном чипе (с 326 до 861 токенов/с) и в 2,11 раза на клиентском процессоре (с 62 до 132 токенов/с).
• GSM8K: коэффициент принятия равен 4,32. Прирост производительности на H100 составил 2,22 раза (с 312 до 693 токенов/с), на M4 Max — 2,36 раза (с 60 до 143 токенов/с).
• MT-Bench: уровень одобрения предложенных токенов — 5,07. Скорость работы увеличилась в 2,87 раза на H100 (с 325 до 933 токенов/с) и в 1,99 раза на M4 Max (с 62 до 123 токенов/с).
• Средние значения (Mean): при среднем уровне принятия 4,81 общая скорость генерации увеличилась в 2,67 раза на сервере (с 323 до 864 токенов/с) и в 2,27 раза на локальном устройстве (с 61 до 139 токенов/с).

Оптимизация и ускорение инференса LFM2.5-1.2B-Instruct

Для более компактной инструкции-модели LFM2.5-1.2B-Instruct наблюдается заметно большая вариативность в уровне принятия токенов драфт-моделью. В зависимости от специфики текстового распределения в датасетах, показатели ускорения могут колебаться в пределах 52%. Тем не менее, итоговое ускорение инференса LFM2.5 в этой конфигурации демонстрирует отличные результаты:

• MATH500: показатель принятия — 6,02. Ускорение на H100 составило 2,56 раза (с 668 до 1712 токенов/с), на M4 Max — 2,62 раза (с 140 до 366 токенов/с).
• HumanEval: коэффициент принятия — 5,31. Скорость выросла в 2,26 раза на H100 (с 664 до 1499 токенов/с) и в 2,87 раза на M4 Max (с 136 до 389 токенов/с).
• MBPP: одобрение на уровне 5,52. Производительность увеличилась в 2,37 раза на серверном железе (с 667 до 1578 токенов/с) и в 2,74 раза на локальном чипе Apple (с 137 до 375 токенов/с).
• GSM8K: принятие токенов — 4,34. Ускорение на H100 достигло 1,67 раза (с 624 до 1041 токенов/с), а на M4 Max — 2,73 раза (с 140 до 381 токенов/с).
• MT-Bench: показатель одобрения — 3,90. На сервере скорость увеличилась в 1,66 раза (с 657 до 1091 токенов/с), на потребительском чипе — в 1,72 раза (с 137 до 237 токенов/с).
• Средние значения: средний показатель принятия токенов составил 5,02. Общий прирост быстродействия на H100 равен 2,10x (с 656 до 1384 токенов/с), на M4 Max — 2,54x (с 138 до 350 токенов/с).

Особенности работы с MoE-моделью LFM2.5-8B-A1B

При тестировании архитектуры со смесью экспертов (MoE) LFM2.5-8B-A1B обнаружилась интересная закономерность. С одной стороны, уровень принятия токенов здесь оказался заметно выше, чем у плотных (dense) моделей. С другой стороны, при запуске на локальных устройствах Apple средний прирост быстродействия составил скромные 18%. Инженеры объясняют этот разрыв ограничениями текущей реализации MoE в бэкенде Metal библиотеки llama.cpp: процедура валидации k токенов одновременно активирует большее число экспертов, что резко увеличивает нагрузку на пропускную способность памяти и генерирует избыточный трафик весов по сравнению с классическим пошаговым декодированием одного токена.

Детальные цифры для MoE-версии распределились так:

• MATH500: при высоком принятии 8,27 скорость на H100 возросла в 3,18 раза (с 428 до 1362 токенов/с), тогда как на M4 Max прирост составил всего 1,21 раза (с 93 до 112 токенов/с).
• HumanEval: принятие — 7,02. На H100 скорость увеличилась в 2,58 раза (с 426 до 1100 токенов/с), на M4 Max — в 1,12 раза (с 91 до 101 токенов/с).
• MBPP: коэффициент одобрения — 6,93. На серверной системе скорость выросла в 2,64 раза (с 426 до 1122 токенов/с), на локальном чипе — в 1,09 раза (с 89 до 97 токенов/с).
• GSM8K: принятие токенов — 4,02. Ускорение на H100 составило 1,29 раза (с 385 до 496 токенов/с), на M4 Max — 1,44 раза (с 90 до 129 токенов/с).
• MT-Bench: уровень принятия — 8,52. Рост скорости на H100 в 3,02 раза (с 426 до 1288 токенов/с), на M4 Max — всего в 1,04 раза (с 87 до 90 токенов/с).
• Средние показатели: при высоком среднем уровне принятия 6,95 общая производительность на H100 выросла в 2,54 раза (с 418 до 1074 токенов/с), а на M4 Max — в 1,18 раза (с 90 до 106 токенов/с).

Запуск и практическая интеграция DSpark

Для того чтобы развернуть сопутствующие модели DSpark на практике, разработчики предлагают два основных сценария интеграции: через высокопроизводительный фреймворк SGLang или с использованием легковесной библиотеки llama.cpp.

Интеграция через SGLang

Для работы потребуется сборка SGLang с поддержкой технологии DSpark для моделей семейства LFM2 (соответствующие изменения внесены в пул-реквест PR #31041). Запуск целевой модели с подключенной драфт-моделью выполняется следующей консольной командой:

python -m sglang.launch_server –model-path LiquidAI/LFM2.5-2.6B –speculative-algorithm DSPARK –speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark –speculative-draft-attention-backend flashinfer –disable-radix-cache –mem-fraction-static 0.75 –port 30000

После успешного запуска сервер предоставляет стандартный OpenAI-совместимый эндпоинт по адресу http://localhost:30000/v1. Размер блока (block size) автоматически считывается из конфигурационного файла драфт-модели config.json. Чтобы замерить базовую скорость без оптимизации, достаточно запустить ту же команду, исключив из нее три параметра спекулятивного декодирования с префиксом –speculative-*.

Использование библиотеки llama.cpp

Для локального запуска на процессорах и графических ускорителях через llama.cpp необходима сборка, поддерживающая изменения из PR #27383. Команда запуска локального сервера выглядит следующим образом:

llama-server -m LFM2.5-2.6B-F16.gguf -md LFM2.5-2.6B-DSpark-F16.gguf –spec-type draft-dspark –spec-draft-n-max 10 –spec-draft-n-min 0 -fa on -ngl 99

В данном случае размер блока извлекается напрямую из метаданных сопутствующего файла (значение параметра n-max автоматически ограничивается этим размером). Важно отметить, что спекулятивное декодирование здесь работает без потери точности: целевая модель строго верифицирует каждый предложенный токен, поэтому результаты жадного (greedy) вывода полностью идентичны работе одиночной базовой модели без ускорителей. В логах времени ответа для каждого запроса выводится соотношение предложенных и принятых токенов в формате draft_n / draft_n_accepted.

Доступность моделей и цитирование

Все чекпоинты сопутствующих моделей DSpark выложены в открытый доступ на платформе Hugging Face. Разработчикам доступны версии в исходном формате Safetensors, а также оптимизированные квантованные GGUF-версии для локального запуска:

• Safetensors: LiquidAI/LFM2.5-2.6B-DSpark, LiquidAI/LFM2.5-1.2B-Instruct-DSpark, LiquidAI/LFM2.5-8B-A1B-DSpark;
• GGUF-контейнеры: LiquidAI/LFM2.5-2.6B-DSpark-GGUF, LiquidAI/LFM2.5-1.2B-Instruct-DSpark-GGUF, LiquidAI/LFM2.5-8B-A1B-DSpark-GGUF.

При цитировании этой работы в научных или коммерческих публикациях разработчики просят использовать следующую ссылку:

Liquid AI, “LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook”, Liquid AI Blog, Aug 2026.

Официальная публикация и материалы проекта

Технические подробности и полные результаты тестов представлены в официальной публикации Liquid AI (2026) под названием «LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook». В этом материале, размещенном в блоге компании (liquid.ai/blog/lfm2.5-dspark), разработчики детально описывают архитектурные решения, позволившие реализовать кратное ускорение инференса LFM2.5 на самом разном оборудовании — от мощных графических процессоров NVIDIA H100 до персональных ноутбуков MacBook.

Источник: huggingface.co