LFM3-1.7B sur vLLM : neuf jours plus tard, la prise en charge native se résume encore à deux PR ouvertes

Liquid AILFM3-1.7B le 27 octobre 2026 avec une fiche modèle qui affiche vllm serve "LiquidAI/LFM3-1.7B" comme s'il s'agissait d'une commande ordinaire. Neuf jours plus tard, vLLM en amont ne possède aucune architecture Lfm3ForCausalLM pour l'exécuter. Ce qui existe à la place, c'est une demande de fonctionnalité ouverte le 30 octobre, une pull request de kernel sur laquelle tout le reste est empilé, et six PR de modèle ouvertes — dont deux implémentent le même modèle textuel LFM3-1.7B de deux manières différentes, et dont aucune des deux n'a été fusionnée.

Cet écart, c'est tout l'enjeu ici, et il est étroit. Le modèle est réel et téléchargeable ; la prise en charge de l'exécution est une file d'attente. Il s'agit d'un article sur ce que nous savons jusqu'ici à propos de cette file d'attente : ce qui est en cours, ce qui fonctionne réellement aujourd'hui, et ce qui devrait être livré avant que « fonctionne avec vLLM » sur une fiche de modèle ne devienne vrai au sens où un plan de déploiement en a besoin.

La fiche indique vLLM. Le tableau des modèles pris en charge indique LFM2.

La documentation des modèles pris en charge par vLLM répertorie trois architectures Liquid AI : Lfm2ForCausalLM, Lfm2MoeForCausalLM et Lfm2VlForConditionalGeneration. Il n’y a aucune entrée LFM3. La fiche LFM3-1.7B, quant à elle, indique que le checkpoint « fonctionne avec vLLM, SGLang et les builds llama.cpp compatibles LFM3 » et fournit une commande de service sans aucun flag.

La réconciliation se trouve dans la configuration propre au checkpoint. LFM3-1.7B comporte un auto_map pointant vers son modeling_lfm3.py intégré, de sorte que le code côté Hugging Face existe et se clone dans les chargeurs qui autorisent le code distant. Le ticket de suivi de vLLM pour le portage, #64645 — {{1}}« [Fonctionnalité] : Prise en charge des modèles LiquidAI LFM3 »{{/1}} — ouvert le 30 octobre par abhijithneilabraham, est sans détour sur la conséquence : « vLLM n’a pas de Lfm3ForCausalLM. » L’alternative indiquée est la porte de sortie que la plupart des gens finiront par utiliser ce mois-ci : « Exécutez LFM3 via le code distant du checkpoint avec le backend Transformers. Cela abandonne l’attention paginée et le cache d’état de convolution. »

Ce compromis mérite d’être énoncé clairement, car « fonctionne sur vLLM » et « fonctionne sur le backend Transformers de vLLM » désignent des produits différents. L’attention paginée est le mécanisme qui permet à vLLM de traiter par lots des requêtes de longueurs très différentes sans gaspiller la mémoire KV ; le cache d’état de convolution est la même idée appliquée aux couches à convolution courte de cette architecture. Retirez les deux et vous obtenez un endpoint fonctionnel qui a renoncé aux deux raisons pour lesquelles vLLM existe. Pour un modèle de 1,7 B servi à faible concurrence, cela peut être acceptable le temps d’un week-end, mais pas une configuration de production acceptable.

Pourquoi un modèle de 1,7 B a-t-il donc besoin de travail sur les kernels ?

LFM3-1.7B n’est pas une simple adaptation de la famille LFM2 que vLLM sert déjà. Il s’agit d’un hybride à vingt-quatre couches comportant trois types de couches plutôt que deux : 13 couches de convolution courte à portes, 5 couches d’attention à fenêtre glissante de 256 tokens et 6 couches d’attention complète. La configuration du checkpoint explicite la géométrie — conv_L_cache : 7, sliding_window : 256, un vocabulaire de 128 K — et la liste des différences de l’issue vLLM elle-même ajoute QK RMSNorm, une porte de sortie d’attention sigmoïde par tête, une normalisation sandwich et un RoPE partiel (partial_rotary_factor : 0.5) sur les couches d’attention complète, disposés selon la même forme à queue nulle qu’utilise Gemma 4.

Le chiffre qui a fait échouer le portage, c’est le sept. La convolution courte de LFM2 fait trois taps de large ; LFM3 l’a élargie à sept. Les noyaux causal_conv1d Triton de vLLM déroulent un ensemble fixe de largeurs et, comme le dit le ticket de suivi : « Le noyau de préremplissage causal_conv1d Triton déroule les largeurs 2 à 4 et le noyau de décodage 2 à 6, donc un modèle à largeur 7 ne peut pas s’exécuter sur CUDA aujourd’hui. »

Ainsi, la première PR de la pile n’est pas du tout un modèle. #64647, « [Kernel] Support width-7 causal conv1d », ouverte le 30 octobre par abhijithneilabraham, touche deux fichiers et 186 lignes ajoutées : elle étend le kernel de prefill des largeurs 2–4 à 2–7 et le kernel de décodage de 2–6 à 2–7, et fait lever une ValueError aux deux wrappers pour toute valeur hors de cette plage. La description de la PR elle-même explique pourquoi le rejet compte autant que l’extension : avant le changement, « un poids plus large s’exécutait sans branche correspondante et renvoyait des valeurs erronées. » Une corruption numérique silencieuse est une défaillance pire qu’un refus, et c’est le genre de chose qui n’apparaît que sur le modèle que vous avez essayé par hasard.

Une mise en garde mérite d’accompagner cette PR. Son auteur indique clairement qu’il ne dispose pas de machine CUDA : le chemin de référence CPU passe 96 tests, les noyaux Triton ont été vérifiés par analyse statique de l’AST des noyaux, et la validation GPU est laissée à la CI. Il s’agit d’une divulgation honnête plutôt que d’un défaut, mais cela signifie que la seule modification dont dépend chaque autre PR LFM3 n’a pas encore été exercée sur le matériel sur lequel la plupart des lecteurs l’exécuteront.

Deux implémentations du même modèle de texte

En six jours, deux groupes distincts ont écrit un support natif de LFM3 pour vLLM. Ce ne sont pas des variantes d’un même correctif ; ce sont des conceptions indépendantes qui se trouvent installer le même nom d’architecture.

PR #64959, « [Model] Add LiquidAI LFM3 (Lfm3ForCausalLM) », ouverte le 1er novembre par atmikshetty, est la plus conservatrice : sept fichiers, et selon sa propre description, elle réutilise ShortConv avec une largeur de 7, Lfm2MLP, le mappeur de poids LFM2 et le RoPE proportionnel existant, sans modifier aucun composant central. Elle enregistre le modèle dans le registre, l'ajoute à l'ensemble de tests des modèles hybrides et au tableau des modèles pris en charge, et — ce qui est utile pour quiconque parvient à le faire fonctionner — documente les indicateurs de service avec lesquels elle a été validée : --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Sa section de validation indique que 324 tests de noyau passent sur une A100-SXM4-40GB en BF16, que les tests de registre et d'initialisation passent, ainsi qu'une comparaison de log-probabilités avec la référence en code distant de Hugging Face.

PR #65826, « [Model] Add LFM3-Text », ouverte le 5 novembre par paulpak58 — qui est Liquid AI — est la version de l'éditeur lui-même : dix fichiers et 829 lignes ajoutées, y compris sa propre classe de configuration sous transformers_utils/configs/lfm3.py et son propre module de test. Elle a été ouverte sous le titre « [Model] Add LFM3 » et renommée le jour même lorsque la famille a été scindée en quatre PR empilées : #65826 pour le texte, #65827 pour la vision-langage, #65828 pour l'audio et #65829 pour l'omni, chacune construite sur la précédente.

Les deux ne sont pas tant en conflit qu'en parallèle, et la discussion montre clairement le maillage des dépendances. Sur la PR du noyau, paulpak58 a écrit le 4 novembre : « Nous avons nos propres PR internes pour les modèles LFM3, mais il s'agit d'un ajout propre que nous pouvons soutenir. » Sur la PR de texte communautaire, abhijithneilabraham a suggéré que la fusion pourrait nécessiter d'abord la fusion du travail transformers de Liquid — « Je pense que la fusion de cette PR nécessite la PR transformers de @paulpak58 » — ce à quoi atmikshetty a répondu que Lfm3Config n'est pas encore dans une version de transformers, donc la branche « charge la configuration via trust_remote_code depuis le checkpoint, et l'exécution utilise le modèle vLLM natif ». C'est la deuxième barrière à laquelle la plupart des lecteurs n'auront pas pensé : même une PR vLLM fusionnée a besoin d'une classe de configuration livrée quelque part.

Du côté de transformers, la PR équivalente est #50322, « [Model] LFM3 Family: LFM3-Text », ouverte le 3 novembre et toujours ouverte, extraite d’une PR de famille plus large. Sa propre note sur la convolution correspond à l’issue vLLM : la conv courte est « torch-only in LFM3 (les noyaux causal_conv1d du Hub prennent en charge les largeurs 2-4, LFM3 utilise 7) ».

La vision-langage se duplique aussi. Outre le #65827 de Liquid, une PR LFM3-VL indépendante (#65450, ouverte le 3 novembre) est toujours ouverte et dépend de la PR de texte communautaire. Ainsi, à ce jour, il y a six PR LFM3 ouvertes réparties entre deux camps et aucune fusionnée.

Ce qui tourne réellement aujourd’hui

Écartons les spéculations : voici à quoi ressemble la situation concrète le 5 novembre.

• vLLM, natif — impossible sur une version standard. Aucun Lfm3ForCausalLM dans le registre, aucune ligne LFM3 dans le tableau des modèles pris en charge, et la PR qui en ajouterait une n'est pas fusionnée.

• vLLM, backend transformers — la solution de contournement documentée, qui utilise le code distant fourni avec le checkpoint et trust_remote_code. Vous perdez l'attention paginée et le cache d'état convolutif ; vous conservez le serveur compatible OpenAI.

• SGLang — le chemin de serveur propre au fournisseur. L’article de lancement de Liquid mesure ses chiffres de débit sur un seul NVIDIA B300 en BF16 avec SGLang, y compris 3,6 milliards de tokens par jour à 1 024 requêtes simultanées. vLLM n’apparaît dans cet article que comme le runtime sur lequel les modèles concurrents étaient servis.

• llama.cpp — la fiche fait référence à des « versions de llama.cpp compatibles LFM3 », ce qui est une véritable précision et non une formule passe-partout ; les chiffres de Liquid pour l'exécution sur appareil correspondent à llama.cpp en Q4_0 avec un contexte de 32K.

• MLX — les notes de version 0.33.0 du projet distinct vLLM-Metal mentionnent des checkpoints MLX pour le texte LFM3, derrière --trust-remote-code. Il s'agit d'une base de code différente de celle de vLLM en amont et cela n'implique pas la prise en charge de CUDA.

• Hébergé — l'API et le playground propres à Liquid. La carte ne fournit aucune grille tarifaire, le coût par token n'est donc pas quelque chose que vous pouvez budgéter à partir d'informations publiques.

Deux chiffres mettent le cas de l’auto-hébergement en perspective. Les poids sont suffisamment petits pour que la mémoire ne soit pas la contrainte — Liquid annonce environ 1 Go en 4 bits — et le fournisseur indique qu’un contexte de 128K tokens coûte environ 1,6 Go de cache KV. La contrainte réside dans la pile de service, pas dans le GPU.

Qu’est-ce qui changerait cela, dans l’ordre ?

La chaîne de dépendances est inhabituellement claire, ce qui rend ce qu’il vaut la peine de surveiller inhabituellement précis. D’abord, #64647 doit être fusionnée, car toutes les autres PR LFM3 soit incluent ce commit, soit sont empilées dessus. Ensuite, l’une des deux PR texte doit passer la revue — celle de la communauté a le dossier de validation le plus complet, celle de Liquid a pour auteur la personne qui s’occupe aussi du côté transformers. Puis Lfm3Config doit être intégré à une version de transformers, sinon chaque déploiement continue de passer trust_remote_code. Ce n’est qu’après cela que LFM3-VL-2B, LFM3-Audio-2B et LFM3-Omni-2B deviennent réalistes, et ceux-ci se trouvent derrière d’autres PR qui supposent que le modèle texte est déjà intégré.

Rien de tout cela ne doit être lu comme une critique du rythme. Neuf jours entre un lancement et une pile de PR complète et testée, noyau plus modèle, c’est rapide, et le fait que deux équipes indépendantes aient produit des implémentations fonctionnelles en moins d’une semaine en dit plus sur la proximité entre LFM3 et LFM2 que sur un quelconque retard. Mais une fiche de modèle est une affirmation de compatibilité, et la lecture honnête de celle de LFM3-1.7B aujourd’hui est « compatible avec vLLM via le backend transformers », et non « pris en charge par vLLM ».

Si vous avez besoin d’un petit modèle d’appel d’outils cette semaine

LFM3-1.7B a de quoi séduire. Les chiffres annoncés par son fournisseur sont solides précisément là où les petits modèles échouent habituellement — 71,39 sur BFCL V4, 80,36 sur ToolSandbox, 96,66 sur IFEval, 43,40 sur SWE-bench Verified — face à une moyenne globale de 49,37 que Liquid place devant son propre LFM2.5-2.6B à 31,55. Il s'agit d'évaluations propres au fournisseur, réalisées par l'entreprise qui a créé le modèle, sans reproduction indépendante et sans entrée Artificial Analysis que nous ayons pu trouver à ce jour ; considérez le classement comme une hypothèse et les chiffres individuels comme des allégations. La mise en garde qui l'accompagne provient de la même source : la fiche du modèle déconseille le codage agentique et le raisonnement multi-étapes complexe, et les benchmarks de connaissances confirment ce conseil — 63,37 sur GPQA Diamond et 65,56 sur RULER à 128K ne sont pas les chiffres d'un généraliste.

Ainsi, la décision ne porte pas vraiment sur le modèle. Elle consiste à savoir si vous pouvez vous permettre de bâtir sur un chemin de service qui est actuellement une pull request ouverte. Si vous pouvez exécuter SGLang ou llama.cpp, vous pouvez utiliser LFM3-1.7B dès aujourd’hui et la question de vLLM devient théorique. Si votre stack est vLLM par politique, vous choisissez entre l’absence d’attention paginée du backend transformers et l’attente.

Il existe une troisième option qui vaut la peine d’être nommée pour les charges de travail qui ne peuvent pas attendre : acheminez autre chose. OrcaRouter ne propose pas LFM3-1.7B — une vérification de notre catalogue aujourd’hui renvoie plus de 200 identifiants de modèles et aucun d’eux n’est celui de Liquid — il ne s’agit donc pas d’une proposition pour l’appeler via nous. Le point est plus simple : une PR de noyau non fusionnée constitue un mauvais point unique de défaillance pour un chemin de production. Placer une API unique avec bascule automatique devant un modèle hébergé ne vous coûte qu’un changement de configuration, et vous permet de passer à LFM3-1.7B le jour où sa prise en charge native est fusionnée, plutôt que le jour où vous aurez fini de parier dessus. Si vous modifiez le modèle plutôt que de simplement l’appeler, notre propre LFM3-1.7B-abliterated version est une ablation de direction de refus du même checkpoint, et elle hérite précisément de cette situation de service.

La version courte

LFM3-1.7B est disponible, de petite taille, et bien adapté aux tâches d’appel d’outils à tour unique pour lesquelles il a été entraîné. Son support vLLM est en cours d’écriture en ce moment, par deux équipes, au-dessus d’une extension de noyau qui n’a pas encore été exécutée sur CUDA par la personne qui l’a écrite. Surveillez d’abord #64647 — quand la convolution de largeur 7 sera fusionnée, le reste de la pile avancera rapidement, et « works with vLLM » sur la fiche du modèle cessera d’être une affirmation sur le code distant pour devenir une affirmation sur l’attention paginée et le batching. D’ici là, quiconque cite « day-one vLLM support » pour ce modèle cite quelque chose que le dépôt ne contient pas encore.