LFM3-1.7B op vLLM: negen dagen later is native ondersteuning nog steeds twee open PR's

Liquid AI's LFM3-1.7B verscheen op 27 oktober 2026 met een modelkaart die vllm serve "LiquidAI/LFM3-1.7B" afdrukt alsof het een gewoon commando is. Negen dagen later heeft upstream vLLM geen Lfm3ForCausalLM-architectuur om het mee te draaien. Wat er in plaats daarvan bestaat, is een feature request die op 30 oktober is geopend, één kernel-pullrequest waarop al het andere is gestapeld, en zes open model-PR's — waarvan er twee hetzelfde LFM3-1.7B-tekstmodel op twee verschillende manieren implementeren, en geen van beide is samengevoegd.

Die kloof is hier het hele verhaal, en het is een smalle kloof. Het model is echt en downloadbaar; de runtime-ondersteuning is een wachtrij. Dit is een stuk over wat we tot nu toe weten over die wachtrij: wat er in behandeling is, wat vandaag daadwerkelijk draait, en wat er moet landen voordat "works with vLLM" op een modelkaart waar wordt in de zin die een deploymentplan nodig heeft.

De kaart zegt vLLM. De tabel met ondersteunde modellen zegt LFM2.

De eigen documentatie van vLLM over ondersteunde modellen noemt drie Liquid AI-architecturen: Lfm2ForCausalLM, Lfm2MoeForCausalLM en Lfm2VlForConditionalGeneration. Er is geen LFM3-vermelding. De LFM3-1.7B-kaart vermeldt daarentegen dat het checkpoint "werkt met vLLM, SGLang en LFM3-compatibele llama.cpp-builds" en geeft een serveercommando zonder enige flags.

De verzoening zit in de configuratie van het checkpoint zelf. LFM3-1.7B bevat een auto_map die verwijst naar de meegeleverde modeling_lfm3.py, dus de code aan de Hugging Face-kant bestaat en kloont zichzelf in loaders die remote code toestaan. vLLM's trackingissue voor de port, #64645 — "[Feature]: Support LiquidAI LFM3 models", op 30 oktober geopend door abhijithneilabraham — is bot over de consequentie: "vLLM heeft geen Lfm3ForCausalLM." Het genoemde alternatief is het ontsnappingsluik dat de meeste mensen deze maand zullen gebruiken: "Draai LFM3 via de remote code van het checkpoint met de Transformers-backend. Dat geeft paged attention en de conv state cache op."

Die afweging is het waard om ronduit te benoemen, want "runs on vLLM" en "runs on vLLM's transformers backend" zijn verschillende producten. Paged attention is het mechanisme waarmee vLLM verzoeken van sterk uiteenlopende lengtes kan batchen zonder KV-geheugen te verspillen; de conv state cache is hetzelfde idee toegepast op de short-convolutionlagen van deze architectuur. Haal beide weg en je hebt een werkend endpoint dat de twee redenen waarom vLLM bestaat, heeft opgegeven. Voor een 1,7B-model dat bij lage concurrency wordt geserveerd, mag dat een acceptabel weekend zijn, niet een acceptabele productievorm.

Waarom een 1,7B-model überhaupt kernelwerk nodig heeft

LFM3-1.7B is geen eenvoudige herstemming van de LFM2-familie die vLLM al bedient. Het is een vierentwintiglaagse hybride met drie laagtypen in plaats van twee: 13 gated korte-convolutielagen, 5 sliding-window-aandachtslagen met een venster van 256 tokens en 6 volledige-aandachtslagen. De configuratie van het checkpoint specificeert de geometrie expliciet — conv_L_cache: 7, sliding_window: 256, een vocabulaire van 128K — en de eigen lijst met verschillen in de vLLM-issue voegt QK RMSNorm toe, een sigmoïde aandachtsuitvoerpoort per hoofd, sandwich-normalisatie en gedeeltelijke RoPE (partial_rotary_factor: 0.5) op de volledige-aandachtslagen, opgezet in dezelfde zero-tail-vorm die Gemma 4 gebruikt.

Het getal dat de port brak, is zeven. LFM2's korte convolutie is drie taps breed; LFM3 verbreedde die naar zeven. vLLM's Triton causal_conv1d-kernels unrollen een vaste set breedtes, en zoals het trackingissue het zegt: "De Triton causal_conv1d prefill-kernel unrollt breedtes 2 tot 4 en de decode-kernel 2 tot 6, dus een model met breedte 7 kan vandaag niet op CUDA draaien."

De eerste PR in de stack is helemaal geen model. #64647, "[Kernel] Ondersteuning voor causal conv1d met breedte 7", geopend op 30 oktober door abhijithneilabraham, raakt twee bestanden en 186 toegevoegde regels: hij breidt de prefill-kernel uit van breedtes 2–4 naar 2–7 en de decode-kernel van 2–6 naar 2–7, en zorgt ervoor dat beide wrappers ValueError opwerpen voor alles buiten dat bereik. De beschrijving van de PR zelf legt uit waarom de afwijzing net zo belangrijk is als de uitbreiding: vóór de wijziging "liep een breder gewicht zonder bijpassende vertakking en gaf verkeerde waarden terug." Stille numerieke corruptie is een erger falen dan een weigering, en het is het soort probleem dat alleen opduikt bij het model dat je toevallig hebt geprobeerd.

Eén voorbehoud verdient het om met die PR mee te reizen. De auteur ervan zegt ronduit dat hij geen CUDA-machine heeft: het CPU-referentiepad slaagt voor 96 tests, de Triton-kernels zijn gecontroleerd via statische analyse over de kernel-AST, en de GPU-validatie wordt aan CI overgelaten. Dat is een eerlijke onthulling, geen defect, maar het betekent dat de enige wijziging waar elke andere LFM3-PR van afhangt, nog niet is getest op de hardware waarop de meeste lezers deze zullen draaien.

Twee implementaties van hetzelfde tekstmodel

Binnen zes dagen schreven twee afzonderlijke groepen native LFM3-ondersteuning voor vLLM. Het zijn geen varianten van één patch; het zijn onafhankelijke ontwerpen die toevallig dezelfde architectuurnaam installeren.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", geopend op 1 november door atmikshetty, is de conservatieve: zeven bestanden, en volgens de eigen beschrijving hergebruikt hij ShortConv met breedte 7, Lfm2MLP, de LFM2-gewichtmapper en de bestaande proportionele RoPE, zonder kerncomponenten te wijzigen. Hij registreert het model in het register, voegt het toe aan de testset voor hybride modellen en aan de tabel met ondersteunde modellen, en documenteert — nuttig voor iedereen die het aan de praat krijgt — de serving-flags waarmee hij heeft gevalideerd: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. In de validatiesectie meldt hij dat 324 kerneltests slagen op een A100-SXM4-40GB in BF16, dat register- en initialisatietests slagen, en een log-waarschijnlijkheidsvergelijking met de remote-code-referentie van Hugging Face.

PR #65826, "[Model] Add LFM3-Text", op 5 november geopend door paulpak58 — die van Liquid AI is — is de eigen versie van de leverancier: tien bestanden en 829 toegevoegde regels, inclusief een eigen configuratieklasse onder transformers_utils/configs/lfm3.py en een eigen testmodule. Het werd geopend als "[Model] Add LFM3" en dezelfde dag van een nieuwe titel voorzien toen de familie werd opgesplitst in vier gestapelde PR's: #65826 voor tekst, #65827 voor visie-taal, #65828 voor audio en #65829 voor omni, elk voortbouwend op de voorgaande.

De twee zijn niet zozeer met elkaar in conflict als wel parallel, en de discussie laat het afhankelijkheidsnetwerk duidelijk zien. Over de kernel-PR schreef paulpak58 op 4 november: "We hebben onze eigen interne PR's voor LFM3-modellen, maar dit is een nette toevoeging die we kunnen steunen." Over de community-tekst-PR suggereerde abhijithneilabraham dat de merge mogelijk eerst Liquid's transformers-werk gemerged moet hebben — "Ik geloof dat de merge van deze PR de transformers-PR van @paulpak58 vereist" — waarop atmikshetty antwoordde dat Lfm3Config nog niet in een transformers-release zit, dus de branch "laadt de config via trust_remote_code uit de checkpoint, en de uitvoering gebruikt het native vLLM-model." Dat is de tweede poort waar de meeste lezers niet aan gedacht zullen hebben: zelfs een gemergede vLLM-PR heeft een configklasse nodig die ergens wordt meegeleverd.

Aan de transformers-kant is de equivalente PR #50322, "[Model] LFM3 Family: LFM3-Text", geopend op 3 november en nog steeds open, afgesplitst van een grotere family-PR. De eigen opmerking daarin over de convolutie komt overeen met de vLLM-issue: de korte conv is "torch-only in LFM3 (de Hub causal_conv1d-kernels ondersteunen breedtes 2-4, LFM3 gebruikt 7)".

Vision-language wordt ook gedupliceerd. Naast Liquid's #65827 staat er nog een onafhankelijke LFM3-VL PR (#65450, geopend op 3 november) open, die afhankelijk is van de community-tekst-PR. Dus er zijn vandaag de dag zes open LFM3-PR's verdeeld over twee kampen, en geen enkele daarvan is gemerged.

Wat er vandaag daadwerkelijk draait

Zet de speculatie opzij, en het praktische beeld op 5 november ziet er zo uit.

• vLLM, native — niet mogelijk op een standaardbuild. Geen Lfm3ForCausalLM in het register, geen LFM3-rij in de tabel met ondersteunde modellen, en de PR die er een zou toevoegen is niet samengevoegd.

• vLLM, transformers-backend — de gedocumenteerde workaround, met behulp van de meegeleverde remote code van het checkpoint en trust_remote_code. Je verliest paged attention en de conv state-cache; je behoudt de OpenAI-compatibele server.

• SGLang — het eigen serverpad van de leverancier. De launchpost van Liquid meet de doorvoercijfers op één NVIDIA B300 in BF16 met SGLang, waaronder 3,6 miljard tokens per dag bij 1.024 gelijktijdige verzoeken. vLLM komt in die post alleen voor als de runtime waarop concurrerende modellen werden geserveerd.

• llama.cpp — de kaart verwijst naar "LFM3-compatibele llama.cpp-builds", wat een echte kwalificatie is en geen standaardtekst; de on-device cijfers van Liquid zijn llama.cpp op Q4_0 met een context van 32K.

• MLX — de releaseopmerkingen van 0.33.0 van het afzonderlijke vLLM-Metal-project vermelden LFM3-tekst-MLX-checkpoints, achter --trust-remote-code. Dat is een andere codebase dan upstream vLLM en houdt geen CUDA-ondersteuning in.

• Gehost — Liquid's eigen API en playground. De kaart bevat geen tariefkaart, dus de kosten per token kun je niet begroten op basis van openbaar materiaal.

Twee getallen zetten de zelfhosting-case in perspectief. De gewichten zijn klein genoeg dat geheugen niet de beperkende factor is — Liquid claimt ongeveer 1 GB bij 4-bit — en de leverancier zegt dat een context van 128K tokens ruwweg 1,6 GB aan KV-cache kost. De beperkende factor is de serving-stack, niet de GPU.

Wat zou dit veranderen, in volgorde

De afhankelijkheidsketen is ongewoon overzichtelijk, waardoor wat de moeite waard is om te volgen ongewoon specifiek wordt. Eerst moet #64647 worden samengevoegd, omdat elke andere LFM3-PR die commit ofwel bevat ofwel erop is gestapeld. Dan moet een van de twee tekst-PR's de review winnen — de community-PR heeft het volledigere validatiedossier, de Liquid-PR heeft de auteur die ook de transformers-kant beheert. Dan moet Lfm3Config in een transformers-release terechtkomen, anders blijft elke deployment trust_remote_code doorgeven. Pas daarna worden LFM3-VL-2B, LFM3-Audio-2B en LFM3-Omni-2B realistisch, en die liggen achter verdere PR's die ervan uitgaan dat het tekstmodel al is opgenomen.

Niets hiervan mag worden opgevat als kritiek op het tempo. Negen dagen van een lancering tot een complete, geteste kernel-plus-model-PR-stack is snel, en het feit dat twee onafhankelijke teams in minder dan een week werkende implementaties hebben opgeleverd, zegt meer over hoe dicht LFM3 bij LFM2 ligt dan over enige vertraging. Maar een modelkaart is een compatibiliteitsclaim, en de eerlijke lezing van die van LFM3-1.7B vandaag is "compatibel met vLLM via de transformers-backend", niet "ondersteund door vLLM".

Als je deze week een klein tool-calling-model nodig hebt

LFM3-1.7B is iets aantrekkelijks om te willen hebben. De door de leverancier gerapporteerde cijfers zijn sterk precies daar waar kleine modellen meestal falen — 71,39 op BFCL V4, 80,36 op ToolSandbox, 96,66 op IFEval, 43,40 op SWE-bench Verified — tegenover een algeheel gemiddelde van 49,37 dat Liquid voor zijn eigen LFM2.5-2.6B plaatst, op 31,55. Dat zijn de eigen evaluaties van de leverancier, uitgevoerd door het bedrijf dat het model heeft gebouwd, zonder onafhankelijke reproductie en zonder vermelding in Artificial Analysis die we vandaag konden vinden; beschouw de rangorde als een hypothese en de afzonderlijke cijfers als beweringen. De bijbehorende waarschuwing komt uit dezelfde bron: de modelkaart raadt af om het model te gebruiken voor agentisch coderen en complexe meerstapsredeneringen, en de kennisbenchmarks bevestigen dat advies — 63,37 op GPQA Diamond en 65,56 op RULER bij 128K zijn niet de cijfers van een generalist.

Dus de beslissing gaat niet echt over het model. Het gaat erom of je het je kunt veroorloven om te bouwen op een serving-pad dat momenteel een open pull request is. Als je SGLang of llama.cpp kunt draaien, kun je LFM3-1.7B vandaag gebruiken en is de vLLM-kwestie academisch. Als je stack volgens beleid vLLM is, kies je tussen de ontbrekende paged attention van de transformers-backend en wachten.

Er is een derde optie die het vermelden waard is voor workloads die niet kunnen wachten: routeer iets anders. OrcaRouter biedt LFM3-1.7B niet aan — een controle van onze catalogus vandaag levert meer dan 200 model-id's op en geen daarvan is van Liquid — dus dit is geen pleidooi om het via ons aan te roepen. Het is het eenvoudigere punt dat een niet-gemergede kernel-PR een slecht single point of failure is voor een productiepad. Een gehost model voorzien van één API met automatische failover kost je een configuratiewijziging, en laat je overschakelen naar LFM3-1.7B op de dag dat de native ondersteuning wordt gemerged, in plaats van op de dag dat je klaar bent met erop te wedden. Als je het model aanpast in plaats van het alleen aan te roepen, dan is onze eigen LFM3-1.7B-abliterated release een ablatie in de weigeringsrichting van dezelfde checkpoint, en die erft precies deze serveersituatie.

De korte versie

LFM3-1.7B is uit, klein en zeer geschikt voor de single-turn tool-callingtaken waarvoor het is getraind. De vLLM-ondersteuning ervoor wordt op dit moment geschreven, door twee teams, bovenop een kerneluitbreiding die nog niet op CUDA is uitgevoerd door de persoon die hem heeft geschreven. Let eerst op #64647 — wanneer de breedte-7-convolutie wordt samengevoegd, gaat de rest van de stack snel vooruit, en houdt "werkt met vLLM" op de modelkaart op een uitspraak over remote code te zijn en begint het een uitspraak over paged attention en batching te worden. Tot die tijd citeert iedereen die "day-one vLLM-ondersteuning" voor dit model aanhaalt, iets wat de repository nog niet bevat.