Liquid AI выпустила DSpark-драфтеры для трех моделей LFM2.5 и получила до 3,18x прироста пропускной способности на GPU и до 2,87x на устройстве. Для локального контура это серьезный повод обновить стек, но не готовый ответ на вопрос, стал ли DGX Spark выгоднее облачного API: самого DGX Spark в тестах нет, стоимость токена не считали, а максимальный результат зависит от модели и типа запросов.
Откуда взялось ускорение
В опубликованном на Hugging Face разборе Liquid AI объясняет результат особенностью decode-фазы. При обычной генерации задержка возникает в основном из-за постоянной загрузки весов из DRAM в SRAM, а не из-за сложных вычислений. Speculative decoding пытается разделить эту работу: небольшая draft-модель предлагает сразу несколько следующих токенов, после чего основная модель проверяет их за один проход.
DSpark сочетает три элемента. Параллельный backbone создает скрытые состояния для всех draft-токенов за один проход. Легкая последовательная head-модель добавляет зависимость между соседними токенами и повышает вероятность принятия поздних позиций. Verifier оценивает шансы каждого токена пройти проверку и отбрасывает низкоуверенный хвост, если его проверка уже не окупается.
Liquid AI обучила attention-only драфтеры примерно по 300 млн параметров, с пятью слоями и блоком из девяти токенов. Для каждого провели 15 эпох, а чекпойнт выбирали по максимальному acceptance rate, не по минимальному loss. Это важная деталь: оптимизировали не красоту учебной метрики, а долю предложений, которые основная модель действительно примет.
Опубликованы драфтеры для LFM2.5-2.6B, LFM2.5-1.2B-Instruct и LFM2.5-8B-A1B. Они доступны в Safetensors и GGUF, поддержка добавлена в llama.cpp и SGLang. Базовый замер авторы проводили тем же запуском, но без трех speculative-флагов.
Качество не урезали, условия теста урезали
При temperature 0 предложенный токен принимается только тогда, когда совпадает с распределением основной модели. Если совпадения нет, в ответ идет токен самой target-модели. Поэтому результат при greedy decoding идентичен базовой генерации, а pass@1 и exact match не меняются по конструкции.
То есть ускорение здесь не куплено обычным трюком из серии «ответим приблизительно, зато быстро». Цена другая: дополнительный драфтер, зависимость от acceptance rate и конкретной реализации backend.
На M4 Max MacBook Pro тесты шли через llama.cpp и экспериментальные Metal kernels, с FP16 GGUF, batch size 1 и ответами длиной до 256 токенов. На одной H100 80 GB использовали SGLang и BF16, также с batch size 1 и temperature 0. Длину входного контекста авторы не раскрывают. Поэтому из публикации нельзя заключить, что 3,18x сохранится на длинных документах, больших системных промптах или параллельной нагрузке.
Лучше всего выглядит LFM2.5-2.6B. На MacBook модель доходила примерно до 140 токенов в секунду в зависимости от датасета, а в сценариях с несколькими инструментами DSpark снижал задержку function calling в среднем на 57%. Для LFM2.5-1.2B-Instruct разброс ускорения между датасетами достигал 52% из-за разного acceptance rate.
У LFM2.5-8B-A1B картина еще показательнее: при более высоком acceptance rate средний прирост на устройстве составил лишь 18%. Liquid AI связывает разрыв с текущей реализацией MoE в Metal backend и тем, что проверка нескольких токенов активирует больше экспертов, увеличивая трафик весов. Иными словами, хороший драфтер не отменяет узкое место самого runtime.
Что пересчитать владельцу локального контура
Рынок уже видел более эффектные множители. NVIDIA писала о приросте DFlash до 15x на Blackwell, а Pandaily сообщала об 80% ускорении генерации у DeepSeek DSpark. Складывать эти проценты в одну презентацию бессмысленно: отличаются модели, железо, backend и режимы измерения.
Практический вывод для владельца DGX Spark скромнее, но полезнее. LFM2.5-DSpark дает шанс увеличить выпуск токенов на уже купленном устройстве без изменения greedy-ответа. При постоянной загрузке это может улучшить экономику локального инференса. Но публикация не сравнивает расходы с облачными API и не измеряет DGX Spark, поэтому объявлять локальный контур победителем пока рано.
Проверять нужно три числа на собственной трассе запросов: acceptance rate, токены в секунду и задержку полного ответа. Отдельно стоит прогнать типичные длины контекста, function calling и параллельные сессии. Главный маркер успеха прост: если после подключения DSpark стоимость обработанного запроса на DGX Spark падает при том же greedy-выходе и приемлемой задержке, локальный контур действительно стал конкурентнее. Если прирост останется около 18% или исчезнет на ваших контекстах, цифра 3,2x так и останется свойством чужого бенчмарка.