LFM3-1.7B на vLLM: спустя девять дней нативная поддержка всё ещё состоит из двух открытых PR

Liquid AI LFM3-1.7B выпустила 27 октября 2026 года с карточкой модели, в которой vllm serve "LiquidAI/LFM3-1.7B" указана так, будто это обычная команда. Девять дней спустя в upstream vLLM нет архитектуры Lfm3ForCausalLM, с помощью которой её можно было бы запустить. Вместо этого есть запрос на добавление функции, созданный 30 октября, один pull request с ядром, на котором построено всё остальное, и шесть открытых PR с моделями — два из которых реализуют одну и ту же текстовую модель LFM3-1.7B двумя разными способами, и ни один из них не был смержен.

Этот разрыв — здесь вся суть, и разрыв этот узкий. Модель реальна и доступна для скачивания; поддержка в среде выполнения — это очередь. Это материал в формате «что мы знаем на данный момент» об этой очереди: что находится в работе, что реально работает сегодня и что должно появиться, прежде чем фраза «works with vLLM» на карточке модели станет правдой в том смысле, в каком это нужно плану развёртывания.

На карточке указано vLLM. В таблице поддерживаемых моделей указано LFM2.

В собственной документации vLLM по поддерживаемым моделям перечислены три архитектуры Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM и Lfm2VlForConditionalGeneration. Записи LFM3 там нет. При этом в карточке LFM3-1.7B указано, что чекпойнт «работает с vLLM, SGLang и сборками llama.cpp, совместимыми с LFM3», и приведена команда запуска без каких-либо флагов.

Согласование обеспечивается собственной конфигурацией чекпоинта. LFM3-1.7B содержит auto_map, указывающий на входящий в комплект modeling_lfm3.py, поэтому код на стороне Hugging Face существует и клонирует себя в загрузчики, разрешающие удалённый код. Задача отслеживания в vLLM по портированию, #64645 — «[Feature]: Support LiquidAI LFM3 models», открытая 30 октября abhijithneilabraham, — прямо говорит о последствии: «В vLLM нет Lfm3ForCausalLM». Указанная там альтернатива — это запасной выход, которым большинству людей придётся пользоваться в этом месяце: «Запускайте LFM3 через удалённый код чекпоинта с бэкендом Transformers. При этом вы отказываетесь от paged attention и кэша состояния свёртки».

Об этом компромиссе стоит сказать прямо, потому что «работает на vLLM» и «работает на transformers-бэкенде vLLM» — это разные продукты. Paged attention — механизм, который позволяет vLLM объединять в пакеты запросы совершенно разной длины, не тратя впустую память KV; кэш состояния свёртки — та же идея, применённая к слоям коротких свёрток этой архитектуры. Уберите и то и другое — и останется работающий эндпоинт, который отказался от двух причин, по которым существует vLLM. Для модели на 1,7 млрд параметров, обслуживаемой при низкой конкурентности, это, возможно, приемлемый вариант на выходные, но не приемлемая продакшн-конфигурация.

Зачем модели на 1,7 млрд параметров вообще нужна работа с ядрами

LFM3-1.7B — это не простая перенастройка семейства LFM2, которое уже поддерживается vLLM. Это гибрид из двадцати четырёх слоёв с тремя типами слоёв вместо двух: 13 слоёв стробируемой короткой свёртки, 5 слоёв скользящего оконного внимания с окном в 256 токенов и 6 слоёв полного внимания. Конфигурация контрольной точки явно задаёт геометрию — conv_L_cache: 7, sliding_window: 256, словарь на 128K, — а собственный список различий в issue vLLM добавляет QK RMSNorm, сигмоидный выходной вентиль внимания для каждой головы, сэндвич-нормализацию и частичный RoPE (partial_rotary_factor: 0.5) на слоях полного внимания, организованные в той же форме с нулевым хвостом, которую использует Gemma 4.

Число, из-за которого сломалось портирование, — семь. Короткая свёртка в LFM2 имеет ширину в три тапа; в LFM3 её расширили до семи. Triton-ядра causal_conv1d из vLLM разворачивают фиксированный набор ширин, и, как сказано в issue-трекере: «Triton-ядро causal_conv1d для prefill разворачивает ширины от 2 до 4, а ядро для decode — от 2 до 6, поэтому модель с шириной 7 сегодня не может работать на CUDA».

Итак, первый PR в стеке — вовсе не модель. #64647, «[Kernel] Поддержка causal conv1d ширины 7», открытый 30 октября пользователем abhijithneilabraham, затрагивает два файла и 186 добавленных строк: он расширяет ядро prefill с ширины 2–4 до 2–7, а ядро decode — с 2–6 до 2–7, и заставляет обе обёртки выбрасывать ValueError для всего, что выходит за пределы этого диапазона. В описании самого PR объясняется, почему отказ так же важен, как и расширение: до изменения «тензор весов большей ширины выполнялся без соответствующей ветви и возвращал неверные значения». Скрытое численное искажение — более серьёзный сбой, чем отказ, и это как раз то, что проявляется только на модели, которую вы случайно попробовали.

С этим PR стоит держать в уме одну оговорку. Его автор прямо заявляет, что у него нет машины с CUDA: эталонный путь на CPU проходит 96 тестов, ядра Triton были проверены статическим анализом по AST ядер, а проверка на GPU оставлена для CI. Это честное признание, а не дефект, но оно означает, что единственное изменение, от которого зависят все остальные PR для LFM3, ещё не проверялось на оборудовании, на котором его будут запускать большинство читателей.

Две реализации одной и той же текстовой модели

{{1}}За шесть дней две отдельные группы написали нативную поддержку LFM3 для vLLM.{{/1}} {{2}}Это не варианты одного патча; это независимые разработки, которые случайно устанавливают одно и то же имя архитектуры.{{/2}}

PR #64959, «[Model] Добавление LiquidAI LFM3 (Lfm3ForCausalLM)», открытый 1 ноября пользователем atmikshetty, — консервативный вариант: семь файлов, и, согласно его собственному описанию, он переиспользует ShortConv шириной 7, Lfm2MLP, преобразователь весов LFM2 и существующий пропорциональный RoPE, не изменяя ни одного основного компонента. Он регистрирует модель в реестре, добавляет её в набор тестов гибридных моделей и таблицу поддерживаемых моделей и — что полезно для всех, кто сможет это запустить — документирует флаги обслуживания, с которыми проводилась проверка: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. В его разделе валидации сообщается о прохождении 324 тестов ядер на A100-SXM4-40GB в BF16, о прохождении тестов реестра и инициализации, а также о сравнении логарифмических вероятностей с эталонной реализацией remote-code от Hugging Face.

PR #65826, «[Model] Add LFM3-Text», открытый 5 ноября paulpak58 (представителем Liquid AI), представляет собой собственную версию вендора: десять файлов и 829 добавленных строк, включая собственный класс конфигурации в transformers_utils/configs/lfm3.py и собственный тестовый модуль. Он был открыт как «[Model] Add LFM3» и в тот же день переименован, когда семейство разделили на четыре последовательных PR: #65826 для текста, #65827 для vision-language, #65828 для аудио и #65829 для omni, каждый из которых построен на предыдущем.

Эти два изменения не столько конфликтуют, сколько существуют параллельно, и обсуждение наглядно показывает сеть зависимостей. В PR для ядра paulpak58 написал 4 ноября: «У нас есть собственные внутренние PR для моделей LFM3, но это чистое дополнение, которое мы можем поддержать». В PR с текстом сообщества abhijithneilabraham предположил, что для слияния, возможно, сначала потребуется слить работу Liquid с transformers — «Я считаю, что для слияния этого PR требуется PR в transformers от @paulpak58», — на что atmikshetty ответил, что Lfm3Config ещё нет в релизе transformers, поэтому ветка «загружает конфигурацию через trust_remote_code из чекпойнта, а при выполнении используется нативная модель vLLM». Это второй барьер, о котором большинство читателей не задумывались: даже для слитого PR в vLLM нужен класс конфигурации, который должен где-то поставляться.

На стороне transformers эквивалентный PR — #50322, «[Model] LFM3 Family: LFM3-Text», открытый 3 ноября и всё ещё открытый, выделенный из более крупного PR семейства. Его собственная заметка о свёртке совпадает с issue в vLLM: короткая свёртка «реализована только на torch в LFM3 (ядра causal_conv1d из Hub поддерживают ширины 2–4, в LFM3 используется 7)».

Vision-language тоже дублируется. Помимо #65827 от Liquid, независимый PR LFM3-VL (#65450, открыт 3 ноября) по-прежнему открыт и зависит от текстового PR сообщества. Таким образом, на сегодняшний день имеется шесть открытых PR по LFM3 в двух лагерях, и ни один из них не был слит.

Что на самом деле работает сегодня

Отбросьте домыслы, и практическая картина на 5 ноября выглядит так.

• vLLM, нативно — невозможно в стандартной сборке. В реестре нет Lfm3ForCausalLM, в таблице поддерживаемых моделей нет строки LFM3, а PR, который добавил бы её, не смержен.

• vLLM, бэкенд transformers — задокументированный обходной путь с использованием встроенного в чекпойнт удалённого кода и trust_remote_code. Вы теряете paged attention и кэш состояния conv; при этом сохраняете сервер, совместимый с OpenAI.

• SGLang — собственный серверный путь производителя. В публикации Liquid о запуске показатели пропускной способности измеряются на одном NVIDIA B300 в BF16 с SGLang, включая 3,6 млрд токенов в день при 1 024 одновременных запросах. vLLM упоминается в этой публикации только как среда выполнения, на которой обслуживались конкурирующие модели.

• llama.cpp — в карточке упоминаются «сборки llama.cpp, совместимые с LFM3», и это не дежурная фраза, а реальное уточнение; показатели Liquid на устройстве получены в llama.cpp с квантованием Q4_0 и контекстом 32K.

• MLX — в примечаниях к выпуску 0.33.0 отдельного проекта vLLM-Metal перечислены текстовые MLX-чекпоинты LFM3, доступные при использовании --trust-remote-code. Это другая кодовая база, отличная от upstream vLLM, и это не подразумевает поддержку CUDA.

• Хостинг — собственный API и песочница Liquid. В карточке не указана тарифная сетка, поэтому стоимость за токен невозможно спланировать по публичным материалам.

Две цифры помогают трезво оценить вариант с самостоятельным хостингом. Веса достаточно малы, поэтому память не является ограничивающим фактором — Liquid заявляет около 1 ГБ при 4-битном квантовании — а производитель говорит, что контекст на 128K токенов требует примерно 1,6 ГБ KV-кэша. Ограничением является стек обслуживания, а не GPU.

Что могло бы это изменить, по порядку?

Цепочка зависимостей на удивление чистая, что делает то, за чем стоит следить, на удивление конкретным. Сначала должен быть смержен #64647, потому что любой другой PR по LFM3 либо включает этот коммит, либо построен поверх него. Затем один из двух текстовых PR должен пройти ревью — у community-варианта более полная история валидации, а у Liquid-варианта автор, который также отвечает за направление transformers. Затем Lfm3Config должен войти в релиз transformers, иначе каждое развёртывание будет продолжать передавать trust_remote_code. Только после этого LFM3-VL-2B, LFM3-Audio-2B и LFM3-Omni-2B становятся реалистичными, а они стоят за дальнейшими PR, которые предполагают, что текстовая модель уже влита.

Ничто из этого не следует воспринимать как критику темпов. Девять дней от запуска до полного, протестированного стека PR с ядром и моделью — это быстро, и тот факт, что две независимые команды создали рабочие реализации менее чем за неделю, говорит скорее о том, насколько LFM3 близка к LFM2, чем о какой-либо задержке. Но карточка модели — это заявление о совместимости, и честная трактовка сегодняшнего статуса LFM3-1.7B звучит так: «совместима с vLLM через бэкенд transformers», а не «поддерживается vLLM».

Если вам на этой неделе нужна небольшая модель с поддержкой вызова инструментов

LFM3-1.7B — привлекательная модель, которую хочется заполучить. Заявленные производителем цифры сильны именно там, где небольшие модели обычно проваливаются: 71,39 в BFCL V4, 80,36 в ToolSandbox, 96,66 в IFEval, 43,40 в SWE-bench Verified — на фоне общего среднего 49,37, которое Liquid ставит выше собственной LFM2.5-2.6B с 31,55. Это собственные оценки производителя, проведённые компанией, создавшей модель, без независимого воспроизведения и без записи в Artificial Analysis, которую мы смогли бы найти на сегодня; рассматривайте порядок как гипотезу, а отдельные цифры — как заявления. Сопутствующая оговорка исходит из того же источника: карточка модели не рекомендует использовать её для агентного программирования и сложных многошаговых рассуждений, и бенчмарки знаний согласуются с этой рекомендацией — 63,37 на GPQA Diamond и 65,56 на RULER при 128K — это не показатели универсальной модели.

Так что решение на самом деле не о модели. Оно о том, можете ли вы позволить себе строить на пути обслуживания, который сейчас является открытым pull request. Если вы можете запускать SGLang или llama.cpp, вы можете использовать LFM3-1.7B уже сегодня, и вопрос с vLLM становится теоретическим. Если по вашим правилам стек должен быть на vLLM, вы выбираете между отсутствием paged attention в бэкенде transformers и ожиданием.

Есть третий вариант, который стоит назвать для рабочих нагрузок, не терпящих ожидания: направить запросы куда-то ещё. OrcaRouter не предоставляет LFM3-1.7B — проверка нашего каталога сегодня возвращает более 200 идентификаторов моделей, и ни один из них не принадлежит Liquid — так что это не предложение вызывать её через нас. Речь о более простом: неслитый PR в ядро — плохая единая точка отказа для продакшен-пути. Поставить перед размещённой моделью единый API с автоматическим переключением при сбое стоит всего одного изменения конфигурации и позволяет подключить LFM3-1.7B в день, когда появится нативная поддержка, а не в день, когда вы закончите делать ставку на неё. Если вы модифицируете модель, а не просто вызываете её, наш собственный LFM3-1.7B-abliterated релиз — это абляция направления отказа того же чекпоинта, и он наследует ровно эту ситуацию с обслуживанием.

Короткая версия

LFM3-1.7B вышла, она компактная и хорошо подходит для одноходовых задач вызова инструментов, на которых обучалась. Поддержка vLLM для неё сейчас пишется двумя командами поверх расширения ядра, которое автор ещё не запускал на CUDA. Сначала следите за #64647 — когда будет слита свёртка ширины 7, остальной стек быстро сдвинется, и «работает с vLLM» в карточке модели перестанет быть утверждением об удалённом коде и станет утверждением о paged attention и батчинге. До тех пор всякий, кто приводит «поддержку vLLM с первого дня» для этой модели, цитирует то, чего в репозитории пока нет.