LFM3-1.7B på vLLM: Nio dagar in, inbyggt stöd är fortfarande två öppna PR:er

Liquid AI:s LFM3-1.7B lanserades den 27 oktober 2026 med ett modellkort som skriver ut vllm serve "LiquidAI/LFM3-1.7B" som om det vore ett vanligt kommando. Nio dagar senare har upstream vLLM ingen Lfm3ForCausalLM-arkitektur att köra den med. Det som i stället finns är en funktionsförfrågan som öppnades den 30 oktober, en kernel-pull request som allt annat bygger på, och sex öppna modell-PR:ar – varav två implementerar samma LFM3-1.7B-textmodell på två olika sätt, och ingen av dem har slagits samman.

Det gapet är hela historien här, och det är smalt. Modellen är verklig och nedladdningsbar; körtidsstödet är en kö. Detta är en artikel om vad vi vet hittills om kön: vad som pågår, vad som faktiskt körs i dag och vad som skulle behöva komma på plats innan "works with vLLM" på ett modellkort blir sant på det sätt en driftsättningsplan kräver.

Kortet anger vLLM. Tabellen över modeller som stöds anger LFM2.

vLLMs egen dokumentation över modeller som stöds listar tre Liquid AI-arkitekturer: Lfm2ForCausalLM, Lfm2MoeForCausalLM och Lfm2VlForConditionalGeneration. Det finns ingen LFM3-post. LFM3-1.7B-kortet anger samtidigt att checkpointen "fungerar med vLLM, SGLang och LFM3-kompatibla llama.cpp-byggen" och ger ett serveringskommando utan några flaggor.

Avstämningen finns i checkpointens egen konfiguration. LFM3-1.7B har en auto_map som pekar på den medföljande modeling_lfm3.py, så koden på Hugging Face-sidan finns och klonar sig själv till loaders som tillåter fjärrkod. vLLM:s tracking-issue för portningen, #64645 – "[Feature]: Support LiquidAI LFM3 models", öppnat 30 oktober av abhijithneilabraham – är tydlig med konsekvensen: "vLLM har ingen Lfm3ForCausalLM." Det listade alternativet är den nödutgång som de flesta till slut kommer att använda den här månaden: "Kör LFM3 via checkpointens fjärrkod med Transformers-backend. Det innebär att man avstår från paged attention och conv state-cachen."

Den avvägningen är värd att säga rakt ut, eftersom "körs på vLLM" och "körs på vLLMs transformers-backend" är olika produkter. Paged attention är mekanismen som låter vLLM batcha förfrågningar av vitt skilda längder utan att slösa KV-minne; conv state-cachen är samma idé tillämpad på den här arkitekturens kortkonvolutionslager. Tar man bort båda har man en fungerande endpoint som har gett upp de två anledningarna till att vLLM finns. För en 1,7B-modell som serveras vid låg samtidighet kan det vara en acceptabel helg, inte en acceptabel produktionsform.

Varför en 1.7B-modell överhuvudtaget behöver kernel-arbete

LFM3-1.7B är inte en enkel omtrimning av LFM2-familjen som vLLM redan serverar. Det är en hybrid med tjugofyra lager och tre lagertyper i stället för två: 13 kortkonvolutionslager med gating, 5 attentionlager med glidande fönster och ett fönster på 256 token samt 6 lager med full attention. Checkpointens config anger geometrin explicit – conv_L_cache: 7, sliding_window: 256, en vokabulär på 128K – och vLLM-ärendets egen lista över skillnader lägger till QK RMSNorm, en sigmoidgrind för attentionutdata per huvud, sandwich-normalisering och partiell RoPE (partial_rotary_factor: 0.5) på lagren med full attention, utformade i samma zero-tail-form som Gemma 4 använder.

Talet som knäckte portningen är sju. LFM2:s korta faltning är tre tappar bred; LFM3 breddade den till sju. vLLMs Triton-kärnor för causal_conv1d vecklar ut en fast uppsättning bredder, och som spårningsärendet uttrycker det: "Triton-kärnan för causal_conv1d-prefill vecklar ut bredderna 2 till 4 och decode-kärnan 2 till 6, så en modell med bredd 7 kan inte köras på CUDA i dag."

Så den första PR:en i stacken är inte ens en modell. #64647, "[Kernel] Support width-7 causal conv1d", öppnades den 30 oktober av abhijithneilabraham, rör två filer och 186 tillagda rader: den utökar prefill-kärnan från bredderna 2–4 till 2–7 och decode-kärnan från 2–6 till 2–7, och låter båda wrapper-funktionerna kasta ValueError för allt utanför det intervallet. PR:ens egen beskrivning förklarar varför avvisandet är lika viktigt som utökningen: före ändringen "kördes en bredare vikt utan en matchande gren och returnerade felaktiga värden". Tyst numerisk korruption är ett värre fel än en vägran, och det är sådant som bara dyker upp på den modell man råkade prova.

En varning bör åtfölja den PR:n. Dess författare säger rakt ut att hen inte har någon CUDA-maskin: CPU-referensvägen klarar 96 tester, Triton-kärnorna kontrollerades med statisk analys av kärnans AST, och GPU-valideringen lämnas åt CI. Det är en ärlig redogörelse snarare än en defekt, men det innebär att den enda ändring som alla andra LFM3-PR:er är beroende av ännu inte har testats på den hårdvara som de flesta läsare kommer att köra den på.

Två implementeringar av samma textmodell

Inom sex dagar skrev två separata grupper inbyggt LFM3-stöd för vLLM. De är inte varianter av en och samma patch; de är oberoende konstruktioner som råkar installera samma arkitekturnamn.

PR #64959, "[Modell] Lägg till LiquidAI LFM3 (Lfm3ForCausalLM)", som öppnades den 1 november av atmikshetty, är den konservativa varianten: sju filer, och enligt dess egen beskrivning återanvänder den ShortConv med bredd 7, Lfm2MLP, LFM2-viktmapparen och den befintliga proportionella RoPE, utan att ändra några kärnkomponenter. Den registrerar modellen i registret, lägger till den i testuppsättningen för hybridmodeller och tabellen över modeller som stöds, och dokumenterar – användbart för alla som får igång den – de serveringsflaggor som den validerades med: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Dess valideringsavsnitt rapporterar att 324 kerneltester passerar på en A100-SXM4-40GB i BF16, att register- och initieringstester passerar, samt en log-sannolikhetsjämförelse mot Hugging Face-referensen för fjärrkod.

PR #65826, "[Model] Add LFM3-Text", som öppnades den 5 november av paulpak58 – som är Liquid AI – är leverantörens egen version: tio filer och 829 tillagda rader, inklusive en egen konfigurationsklass under transformers_utils/configs/lfm3.py och en egen testmodul. Den öppnades som "[Model] Add LFM3" och fick ny titel samma dag när familjen delades upp i fyra staplade PR:er: #65826 för text, #65827 för vision-språk, #65828 för ljud och #65829 för omni, där var och en bygger på den föregående.

De två står inte så mycket i konflikt som de löper parallellt, och diskussionen visar tydligt beroendenätet. I kernel-PR:en skrev paulpak58 den 4 november: "Vi har våra egna interna PR:er för LFM3-modeller, men detta är ett rent tillägg som vi kan stå bakom." I community-text-PR:en föreslog abhijithneilabraham att sammanslagningen kan behöva att Liquids transformers-arbete slås samman först — "Jag tror att sammanslagningen av denna PR kräver transformers-PR:en från @paulpak58" — varpå atmikshetty svarade att Lfm3Config ännu inte finns i någon transformers-version, så grenen "läser in konfigurationen via trust_remote_code från checkpointen, och körningen använder den inbyggda vLLM-modellen." Det är den andra porten som de flesta läsare inte kommer att ha tänkt på: även en sammanslagen vLLM-PR behöver en konfigurationsklass som levereras någonstans.

På transformers-sidan är motsvarande PR #50322, "[Model] LFM3 Family: LFM3-Text", öppnad den 3 november och fortfarande öppen, utbruten ur en större family-PR. Dess egen kommentar om konvolutionen stämmer överens med vLLM-ärendet: short conv är "torch-only in LFM3 (the Hub causal_conv1d kernels serve widths 2-4, LFM3 uses 7)".

Vision-språk dupliceras också. Förutom Liquids #65827 är en oberoende LFM3-VL-PR (#65450, öppnad 3 november) fortfarande öppen och beror på community-text-PR:en. Så i dag finns det sex öppna LFM3-PR:ar i två läger och ingen sammanslagen.

Vad som faktiskt körs idag

Om man bortser från spekulationerna ser den praktiska bilden den 5 november ut så här.

• vLLM, inbyggt — inte möjligt i ett standardbygge. Ingen Lfm3ForCausalLM i registret, ingen LFM3-rad i tabellen över modeller som stöds, och PR:en som skulle lägga till en sådan har inte slagits samman.

• vLLM, transformers-backend — den dokumenterade lösningen, som använder checkpointens medföljande fjärrkod och trust_remote_code. Du förlorar paged attention och conv-tillståndscachen; du behåller den OpenAI-kompatibla servern.

• SGLang — leverantörens egen serverväg. Liquids lanseringsinlägg mäter sina genomströmningssiffror på en enda NVIDIA B300 i BF16 med SGLang, inklusive 3,6 miljarder token per dag vid 1 024 samtidiga förfrågningar. vLLM förekommer i det inlägget endast som den runtime som de konkurrerande modellerna serverades på.

• llama.cpp — kortet hänvisar till "LFM3-kompatibla llama.cpp-byggen", vilket är en faktisk kvalificering snarare än utfyllnadstext; Liquids siffror för enheten är llama.cpp vid Q4_0 med en 32K-kontext.

• MLX — versionsinformationen för version 0.33.0 för det separata projektet vLLM-Metal listar LFM3-text-MLX-checkpoints, bakom --trust-remote-code. Det är en annan kodbas än den uppströms vLLM och innebär inte stöd för CUDA.

• Hosted — Liquid:s eget API och playground. Kortet anger ingen prislista, så kostnaden per token är inte något du kan budgetera utifrån offentligt material.

Två siffror sätter fallet med egen hosting i perspektiv. Vikterna är tillräckligt små för att minnet inte ska vara begränsningen – Liquid hävdar cirka 1 GB vid 4-bit – och leverantören säger att en kontext på 128K token kostar ungefär 1,6 GB KV-cache. Begränsningen är serveringsstacken, inte GPU:n.

Vad skulle ändra på detta, i ordning

Beroendekedjan är ovanligt ren, vilket gör det som är värt att bevaka ovanligt specifikt. Först måste #64647 mergas, eftersom varje annan LFM3-PR antingen innehåller den commiten eller bygger på den. Sedan måste en av de två text-PR:erna vinna granskningen – communityvarianten har det mer fullständiga valideringsunderlaget, Liquid-varianten har författaren som också äger transformers-sidan. Sedan måste Lfm3Config landa i en transformers-release, annars fortsätter varje driftsättning att skicka trust_remote_code. Först efter det blir LFM3-VL-2B, LFM3-Audio-2B och LFM3-Omni-2B realistiska, och de ligger bakom ytterligare PR:er som förutsätter att textmodellen redan är inne.

Inget av detta bör läsas som kritik av tempot. Nio dagar från lansering till en komplett, testad PR-stack med kernel och modell är snabbt, och att två oberoende team tog fram fungerande implementationer på under en vecka säger mer om hur nära LFM3 ligger LFM2 än om någon försening. Men ett modellkort är ett kompatibilitetspåstående, och den ärliga tolkningen av LFM3-1.7B i dag är ”kompatibel med vLLM via transformers-backend”, inte ”stöds av vLLM”.

Om du behöver en liten verktygsanropande modell den här veckan

LFM3-1.7B är en attraktiv sak att vilja ha. Dess leverantörsrapporterade siffror är starka precis där små modeller vanligtvis misslyckas — 71,39 på BFCL V4, 80,36 på ToolSandbox, 96,66 på IFEval, 43,40 på SWE-bench Verified — mot ett totalt genomsnitt på 49,37 som Liquid placerar före sin egen LFM2.5-2.6B på 31,55. Det är leverantörens egna utvärderingar, körda av företaget som byggde modellen, utan oberoende reproduktion och utan någon Artificial Analysis-post som vi kunde hitta i dag; behandla ordningen som en hypotes och de enskilda siffrorna som påståenden. Den åtföljande varningen kommer från samma källa: modellkortet avråder från agentisk kodning och komplexa resonemang i flera steg, och kunskapsbenchmarkarna instämmer i den varningen — 63,37 på GPQA Diamond och 65,56 på RULER vid 128K är inte siffrorna för en generalist.

Så beslutet handlar egentligen inte om modellen. Det handlar om huruvida du har råd att bygga på en servingväg som för närvarande är en öppen pull request. Om du kan köra SGLang eller llama.cpp kan du använda LFM3-1.7B idag, och vLLM-frågan är akademisk. Om din stack är vLLM enligt policy väljer du mellan transformers-backendens saknade paged attention och att vänta.

Det finns ett tredje alternativ värt att nämna för arbetsbelastningar som inte kan vänta: routa något annat. OrcaRouter tillhandahåller inte LFM3-1.7B — en kontroll av vår katalog i dag returnerar fler än 200 modell-id:n och ingen av dem är från Liquid — så det här är inte ett säljargument för att anropa det via oss. Poängen är helt enkelt att en ej mergad kernel-PR är en dålig single point of failure för en produktionsväg. Att sätta ett API med automatisk failover framför en hostad modell kostar dig en konfigurationsändring, och låter dig byta in LFM3-1.7B samma dag som dess inbyggda stöd mergas i stället för den dag du har satsat färdigt på det. Om du modifierar modellen i stället för att bara anropa den är vår egen LFM3-1.7B-abliterated release en ablation i refusal-riktning av samma checkpoint, och den ärver exakt den här serveringssituationen.

Den korta versionen

LFM3-1.7B har släppts, är litet och väl lämpat för de jobb med verktygsanrop i en enda tur som det tränades för. Dess vLLM-stöd skrivs just nu av två team, ovanpå ett kärntillägg som ännu inte har körts på CUDA av personen som skrev det. Håll först ett öga på #64647 – när bredd-7-konvolutionen slås samman går resten av stacken snabbt, och "fungerar med vLLM" på modellkortet slutar vara ett påstående om fjärrkod och börjar bli ett påstående om paged attention och batching. Fram till dess citerar den som anger "vLLM-stöd från dag ett" för den här modellen något som repot ännu inte innehåller.