Liquid AI выпускает черновые модели LFM2.5-DSpark, которые обеспечивают до 3,18 раз более быстрое декодирование без изменения выходных данных модели

Liquid AI выпустила черновые контрольные точки DSpark для трёх моделей семейства LFM2.5: LFM2.5-1.2B-Instruct, LFM2.5-2.6B и LFM2.5-8B-A1B. Каждый «черновик» добавляет к существующей целевой модели предполагаемый путь декодирования: проект с примерно 300 млн параметров предлагает блок из девяти токенов-кандидатов, а целевая модель проверяет весь блок за один прямой проход.

Результат — ускорение декодирования до 3,18 раза на H100 и до 2,87 раза на M4 Max MacBook Pro при небольшом увеличении потребления памяти. Выходные данные не меняются: при жадном декодировании последовательность идентична работе целевой модели в одиночку, поэтому точность бенчмарков не изменяется. Поддержка появилась с первого дня в llama.cpp и SGLang.

Развёртывание и лицензия. Веса поставляются в форматах Safetensors и GGUF; сегодня ни один размещённый провайдер инференса на Hugging Face черновые контрольные точки не обслуживает — для запуска нужна собственная сборка SGLang или llama.cpp с поддержкой DSpark. Лицензия LFM v1.0 разрешает бесплатное коммерческое использование при годовом доходе организации менее 10 млн долларов США; более крупным компаниям требуется коммерческая лицензия Liquid AI. Основные сценарии — локальные помощники по программированию, агенты на устройстве, рассуждающие перед каждым вызовом инструмента, однопользовательский чат и автономные ассистенты на оборудовании класса ноутбука. Отрасли: инструменты для разработчиков, локальные потребительские приложения, робототехника и встроенные системы, а также здравоохранение, финансы и оборона, где данные хранятся локально или на устройстве.

Как устроен DSpark. Спекулятивное декодирование использует небольшую модель для предложения токенов, которые проверяет более крупная. Каждый «черновик» LFM2.5 имеет примерно 300 млн параметров (295,7 млн для цели 1.2B-Instruct, 327,7 млн для 2.6B и 8B-A1B): пять уровней полного внимания со скрытой размерностью 2048, промежуточной размерностью 6144, GQA с 32 головками (8 KV) и размером блока 9. Словарные веса не дублируются: эмбеддинги и LM-голова привязываются к цели при загрузке. Репозиторий черновика 2.6B занимает 655 МБ в BF16 — это реальная цена добавляемой памяти.

DSpark объединяет три части: параллельную магистраль в стиле DFlash, зависящую от контекста цели (создаёт скрытые состояния для всех токенов за один проход); лёгкую последовательную головку, смоделированную как цепь Маркова между соседними токенами на ранге 256 (восстанавливает зависимость между токенами и повышает вероятность принятия на поздних позициях блока); и верификатор с доверительным планированием, который прогнозирует вероятность выживания каждого токена и отсекает суффиксы с низкой уверенностью, когда проверка дороже экономии.

Измерения Liquid AI (пропускная способность, 1×H100, BF16):

• LFM2.5-1.2B-Instruct: 2,10× в среднем на H100 (656 → 1384 ток/с), лучший случай 2,56× на MATH500; на M4 Max — 2,54× в среднем (138 → 350 ток/с), 2,87× на HumanEval (136 → 389).
• LFM2.5-2.6B: 2,67× в среднем на H100 (323 → 864 ток/с), 3,06× на MATH500; на M4 Max — 2,27× (61 → 139 ток/с), 2,63× на HumanEval.
• LFM2.5-8B-A1B: 2,54× в среднем на H100 (418 → 1074 ток/с), 3,18× на MATH500 (428 → 1362); на M4 Max — лишь 1,18× (90 → 106 ток/с), 1,44× на GSM8K.

Ускорение следует за скоростью принятия токенов. LFM2.5-8B-A1B принимает 8,27 из 10 токенов за шаг на MATH500 и только 4,02 на GSM8K — поэтому та же модель даёт от 3,18× до 1,29× на одном GPU. У модели 1.2B приём на MT-Bench падает до 3,90, и прирост на H100 — до 1,66×. Самый явный минус — MoE на чипах Apple: LFM2.5-8B-A1B выигрывает в среднем лишь 1,18× на M4 Max. Liquid AI объясняет это текущей реализацией MoE в бэкенде Metal llama.cpp и тем, что проверка k токенов активирует больше экспертов и, следовательно, больший весовой трафик, чем один шаг декодирования.

Главный практический выигрыш — в агентных сценариях, где пользователь ждёт рассуждений перед каждым вызовом инструмента. В сценариях вызова функций с несколькими инструментами DSpark сокращает задержку в среднем на 57% (например, на LFM2.5-2.6B): агент, который планирует, вызывает и перепланирует, платит за декодирование несколько раз за ход пользователя.

Запуск в SGLang: цель запускается с прикреплённым «черновиком», размер блока считывается из config.json, а базовая линия — та же команда без трёх флагов —speculative-*.

Ключевые выводы: черновики DSpark добавляют около 300 млн параметров и ускоряют декодирование до 3,18× на H100; жадные выходные данные идентичны базовым, так что точность бенчмарков не меняется; ускорение зависит от рабочей нагрузки — от 1,04× до 3,18×; MoE на устройстве — слабое место (лишь 1,18× на M4 Max); вызов нескольких инструментов даёт самый большой практический выигрыш — задержка ниже на 57% на LFM2.5-2.6B.