LFM3-1.7B su vLLM: dopo nove giorni, il supporto nativo resta affidato a due PR aperte

Liquid AILFM3-1.7B è stato rilasciato il 27 ottobre 2026 con una model card che riporta vllm serve "LiquidAI/LFM3-1.7B" come se fosse un comando ordinario. Nove giorni dopo, vLLM upstream non ha alcuna architettura Lfm3ForCausalLM con cui eseguirlo. Quello che esiste invece è una feature request aperta il 30 ottobre, una pull request del kernel su cui si basa tutto il resto, e sei PR di modelli aperte — due delle quali implementano lo stesso modello testuale LFM3-1.7B in due modi diversi, e nessuna delle due è stata mergiata.

Quel divario è tutto il punto, qui, ed è un divario stretto. Il modello è reale e scaricabile; il supporto runtime è una coda. Questo è un articolo su ciò che sappiamo finora riguardo alla coda: cosa è in corso, cosa funziona davvero oggi e cosa dovrebbe arrivare prima che "funziona con vLLM" su una model card diventi vero nel senso in cui un piano di deployment ne ha bisogno.

La scheda dice vLLM. La tabella dei modelli supportati dice LFM2.

La documentazione di vLLM sui modelli supportati elenca tre architetture Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM e Lfm2VlForConditionalGeneration. Non esiste alcuna voce LFM3. La scheda di LFM3-1.7B, invece, afferma che il checkpoint "funziona con vLLM, SGLang e build di llama.cpp compatibili con LFM3" e fornisce un comando di serving senza alcun flag allegato.

La riconciliazione sta nella configurazione del checkpoint stesso. LFM3-1.7B include un auto_map che punta al suo modeling_lfm3.py integrato, quindi il codice lato Hugging Face esiste e si clona nei loader che consentono il codice remoto. La issue di tracciamento di vLLM per il porting, #64645 — «[Feature]: Support LiquidAI LFM3 models», aperta il 30 ottobre da abhijithneilabraham — non usa giri di parole sulla conseguenza: «vLLM non ha Lfm3ForCausalLM». L'alternativa elencata è la scappatoia che la maggior parte delle persone finirà per usare questo mese: «Esegui LFM3 tramite il codice remoto del checkpoint con il backend Transformers. Così si rinuncia alla paged attention e alla cache dello stato convoluzionale».

Vale la pena enunciare chiaramente questo compromesso, perché "gira su vLLM" e "gira sul backend transformers di vLLM" sono prodotti diversi. La Paged attention è il meccanismo che consente a vLLM di raggruppare richieste di lunghezze molto diverse senza sprecare memoria KV; la cache dello stato conv è la stessa idea applicata ai livelli a convoluzione breve di questa architettura. Togli entrambe e ottieni un endpoint funzionante che ha rinunciato alle due ragioni per cui vLLM esiste. Per un modello da 1,7B servito a bassa concorrenza può essere un weekend accettabile, non una configurazione di produzione accettabile.

Perché mai un modello da 1,7B dovrebbe aver bisogno di lavoro sul kernel

LFM3-1.7B non è un semplice riadattamento della famiglia LFM2 che vLLM serve già. È un ibrido a ventiquattro livelli con tre tipi di livello anziché due: 13 livelli di convoluzione corta con gate, 5 livelli di attenzione a finestra scorrevole con una finestra di 256 token e 6 livelli di attenzione completa. La configurazione del checkpoint specifica la geometria — conv_L_cache: 7, sliding_window: 256, un vocabolario da 128K — e l'elenco delle differenze della issue di vLLM aggiunge QK RMSNorm, un gate sigmoideo di uscita dell'attenzione per testa, normalizzazione sandwich e RoPE parziale (partial_rotary_factor: 0.5) sui livelli di attenzione completa, disposti nella stessa forma a coda zero usata da Gemma 4.

Il numero che ha mandato in tilt la porta è il sette. La convoluzione breve di LFM2 è larga tre tap; LFM3 l'ha portata a sette. I kernel Triton causal_conv1d di vLLM srotolano un insieme fisso di larghezze e, come si legge nella issue di tracciamento: "Il kernel Triton causal_conv1d di prefill srotola le larghezze da 2 a 4 e il kernel di decode da 2 a 6, quindi oggi un modello con larghezza 7 non può essere eseguito su CUDA."

Quindi il primo PR dello stack non è affatto un modello. #64647, "[Kernel] Support width-7 causal conv1d", aperto il 30 ottobre da abhijithneilabraham, tocca due file e 186 righe aggiunte: estende il kernel di prefill dalle larghezze 2–4 a 2–7 e il kernel di decode da 2–6 a 2–7, e fa sì che entrambi i wrapper sollevino ValueError per qualsiasi valore al di fuori di tale intervallo. La descrizione del PR spiega perché il rifiuto sia importante quanto l'estensione: prima della modifica, "un peso più ampio veniva eseguito senza un ramo corrispondente e restituiva valori errati". Una corruzione numerica silenziosa è un fallimento peggiore di un rifiuto, ed è il genere di cosa che emerge solo sul modello che ti è capitato di provare.

Un avvertimento merita di accompagnare quella PR. Il suo autore dichiara chiaramente di non avere una macchina CUDA: il percorso di riferimento CPU supera 96 test, i kernel Triton sono stati verificati tramite analisi statica sull'AST dei kernel, e la validazione su GPU è lasciata alla CI. Si tratta di una divulgazione onesta più che di un difetto, ma significa che l'unica modifica da cui dipendono tutte le altre PR LFM3 non è ancora stata messa alla prova sull'hardware sul quale la eseguirà la maggior parte dei lettori.

Due implementazioni dello stesso modello di testo

In sei giorni, due gruppi distinti hanno scritto un supporto nativo per LFM3 in vLLM. Non sono varianti di una stessa patch; sono progetti indipendenti che finiscono per installare lo stesso nome di architettura.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", aperta il 1° novembre da atmikshetty, è quella conservativa: sette file e, secondo la sua stessa descrizione, riutilizza ShortConv con larghezza 7, Lfm2MLP, il mapper dei pesi LFM2 e il RoPE proporzionale esistente, senza modificare alcun componente principale. Registra il modello nel registro, lo aggiunge al set di test dei modelli ibridi e alla tabella dei modelli supportati e — cosa utile per chiunque riesca a farlo funzionare — documenta i flag di serving con cui è stata validata: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. La sua sezione di validazione riporta 324 test del kernel superati su una A100-SXM4-40GB in BF16, test di registro e di inizializzazione superati e un confronto della log-probabilità rispetto al riferimento remote-code di Hugging Face.

PR #65826, "[Model] Add LFM3-Text", aperta il 5 novembre da paulpak58 — che è di Liquid AI — è la versione del fornitore stesso: dieci file e 829 righe aggiunte, inclusa la sua classe di configurazione sotto transformers_utils/configs/lfm3.py e il suo modulo di test. È stata aperta come "[Model] Add LFM3" e rinominata lo stesso giorno quando la famiglia è stata suddivisa in quattro PR impilate: #65826 per il testo, #65827 per visione-linguaggio, #65828 per l'audio e #65829 per omni, ciascuna basata sulla precedente.

I due non sono tanto in conflitto quanto in parallelo, e la discussione mostra chiaramente la rete di dipendenze. Sulla PR del kernel, paulpak58 ha scritto il 4 novembre: "Abbiamo le nostre PR interne per i modelli LFM3, ma questa è un'aggiunta pulita che possiamo sostenere." Sulla PR testuale della community, abhijithneilabraham ha suggerito che il merge potrebbe richiedere prima il merge del lavoro sui transformers di Liquid — "credo che il merge di questa PR richieda la PR sui transformers di @paulpak58" — a cui atmikshetty ha risposto che Lfm3Config non è ancora in una release di transformers, quindi il branch "carica la configurazione tramite trust_remote_code dal checkpoint, e l'esecuzione usa il modello nativo di vLLM." Questo è il secondo ostacolo a cui la maggior parte dei lettori non avrà pensato: anche una PR di vLLM già sottoposta a merge necessita di una classe di configurazione che venga distribuita da qualche parte.

Dal lato transformers la PR equivalente è #50322, «[Model] LFM3 Family: LFM3-Text», aperta il 3 novembre e ancora aperta, scorporata da una PR più ampia sulla famiglia. La sua nota sulla convoluzione coincide con il problema di vLLM: la conv breve è «torch-only in LFM3 (i kernel causal_conv1d dell'Hub servono larghezze 2-4, LFM3 usa 7)».

Anche il vision-language è oggetto di duplicazione. Oltre al #65827 di Liquid, una PR indipendente LFM3-VL (#65450, aperta il 3 novembre) è ancora aperta e dipende dalla PR testuale della community. Quindi, a oggi, ci sono sei PR LFM3 aperte in due schieramenti e nessuna è stata unita.

Cosa viene effettivamente eseguito oggi

Tolte le speculazioni, il quadro pratico del 5 novembre è questo.

• vLLM, nativo — non è possibile su una build standard. Nessun Lfm3ForCausalLM nel registry, nessuna riga LFM3 nella tabella dei modelli supportati, e la PR che ne aggiungerebbe una non è stata unita.

• vLLM, backend transformers — il workaround documentato, che utilizza il codice remoto incluso nel checkpoint e trust_remote_code. Si perde la paged attention e la cache dello stato conv; si mantiene il server compatibile con OpenAI.

• SGLang — il percorso server proprietario del fornitore. Il post di lancio di Liquid misura i suoi numeri di throughput su una singola NVIDIA B300 in BF16 con SGLang, inclusi 3,6 miliardi di token al giorno con 1.024 richieste simultanee. vLLM compare in quel post solo come il runtime su cui venivano serviti i modelli concorrenti.

• llama.cpp — la scheda fa riferimento a "build di llama.cpp compatibili con LFM3", che è una precisazione concreta e non una formula di rito; i dati on-device di Liquid sono llama.cpp a Q4_0 con una finestra di contesto di 32K.

• MLX — le note di rilascio 0.33.0 del progetto separato vLLM-Metal elencano checkpoint MLX per testo LFM3, dietro --trust-remote-code. Si tratta di una base di codice diversa da vLLM upstream e non implica il supporto CUDA.

• Ospitato — L'API e il playground di Liquid stesso. La scheda non riporta alcun listino prezzi, quindi il costo per token non è qualcosa che puoi preventivare basandoti su materiale pubblico.

Due numeri mettono in prospettiva il caso del self-hosting. I pesi sono abbastanza piccoli che la memoria non è il vincolo — Liquid dichiara circa 1 GB a 4 bit — e il fornitore afferma che un contesto da 128K token costa circa 1,6 GB di KV cache. Il vincolo è lo stack di serving, non la GPU.

Cosa cambierebbe questo, in ordine

La catena di dipendenze è insolitamente pulita, il che rende ciò che vale la pena osservare insolitamente specifico. Innanzitutto #64647 deve essere unito, perché ogni altra PR di LFM3 o include quel commit o è impilata su di esso. Poi una delle due PR testuali deve vincere la revisione: quella della community ha il record di validazione più completo, quella di Liquid ha l'autore che possiede anche il lato transformers. Poi Lfm3Config deve approdare in una release di transformers, altrimenti ogni deployment continua a passare trust_remote_code. Solo dopo ciò LFM3-VL-2B, LFM3-Audio-2B e LFM3-Omni-2B diventano realistici, e questi restano dietro ulteriori PR che presuppongono che il modello testuale sia già incluso.

Niente di tutto ciò dovrebbe essere letto come una critica al ritmo. Nove giorni dal lancio a uno stack di PR completo e testato per kernel e modello sono pochi, e il fatto che due team indipendenti abbiano realizzato implementazioni funzionanti in meno di una settimana dice più di quanto LFM3 sia vicino a LFM2 che di qualsiasi ritardo. Ma una model card è un'affermazione di compatibilità, e l'interpretazione onesta dello stato attuale di LFM3-1.7B è «compatibile con vLLM tramite il backend transformers», non «supportato da vLLM».

Se questa settimana ti serve un piccolo modello per il tool calling

LFM3-1.7B è una cosa che fa gola. I numeri dichiarati dal fornitore sono solidi proprio dove i modelli piccoli di solito falliscono — 71,39 su BFCL V4, 80,36 su ToolSandbox, 96,66 su IFEval, 43,40 su SWE-bench Verified — rispetto a una media complessiva di 49,37 che Liquid pone davanti al proprio LFM2.5-2.6B a 31,55. Queste sono valutazioni del fornitore stesso, eseguite dall'azienda che ha costruito il modello, senza riproduzione indipendente e senza alcuna voce in Artificial Analysis che siamo riusciti a trovare alla data odierna; considerate l'ordinamento come un'ipotesi e i singoli valori come affermazioni. L'avvertenza che lo accompagna proviene dalla stessa fonte: la model card sconsiglia la codifica agentica e il ragionamento complesso a più passaggi, e i benchmark di conoscenza concordano con questo consiglio — 63,37 su GPQA Diamond e 65,56 su RULER a 128K non sono i numeri di un generalista.

Quindi la decisione non riguarda davvero il modello. Riguarda se puoi permetterti di costruire su un percorso di serving che al momento è una pull request aperta. Se puoi eseguire SGLang o llama.cpp, puoi usare LFM3-1.7B già oggi e la questione vLLM è accademica. Se il tuo stack è vLLM per policy, stai scegliendo tra l'assenza di paged attention nel backend transformers e l'attesa.

C'è una terza opzione che vale la pena menzionare per i carichi di lavoro che non possono attendere: instradare qualcos'altro. OrcaRouter non offre LFM3-1.7B — un controllo del nostro catalogo oggi restituisce più di 200 ID di modelli e nessuno di questi è di Liquid — quindi non è un invito a chiamarlo tramite noi. È il punto più semplice: una PR del kernel non ancora unita è un pessimo singolo punto di guasto per un percorso di produzione. Anteporre un'unica API con failover automatico a un modello ospitato costa una modifica di configurazione e ti consente di passare a LFM3-1.7B il giorno in cui viene unito il suo supporto nativo, anziché il giorno in cui finisci di scommetterci. Se stai modificando il modello invece di limitarti a chiamarlo, il nostro LFM3-1.7B-abliterated è un rilascio ottenuto per ablazione della direzione di rifiuto dello stesso checkpoint, ed eredita esattamente questa situazione di serving.

La versione breve

LFM3-1.7B è uscito, è piccolo e ben adatto ai compiti di tool-calling a turno singolo per cui è stato addestrato. Il suo supporto vLLM è in fase di scrittura proprio ora, da parte di due team, sopra un'estensione kernel che non è ancora stata eseguita su CUDA dalla persona che l'ha scritta. Tieni d'occhio prima #64647: quando la convoluzione a larghezza 7 verrà unita, il resto dello stack si muoverà rapidamente, e "works with vLLM" sulla model card smetterà di essere un'affermazione sul codice remoto e inizierà a essere un'affermazione sull'attenzione paginata e sul batching. Fino ad allora, chiunque citi "supporto vLLM dal primo giorno" per questo modello sta citando qualcosa che il repository non contiene ancora.