LFM3-1.7B auf vLLM: Nach neun Tagen besteht die native Unterstützung weiterhin aus zwei offenen PRs

Liquid AIs LFM3-1.7B wurde am 27. Oktober 2026 mit einer Modellkarte veröffentlicht, die vllm serve "LiquidAI/LFM3-1.7B" aufführt, als wäre es ein gewöhnlicher Befehl. Neun Tage später verfügt das Upstream-vLLM über keine Lfm3ForCausalLM-Architektur, mit der es ausgeführt werden könnte. Stattdessen gibt es eine am 30. Oktober eröffnete Feature-Anfrage, einen Kernel-Pull-Request, auf dem alles andere aufbaut, und sechs offene Modell-PRs – von denen zwei dasselbe LFM3-1.7B-Textmodell auf zwei verschiedene Arten implementieren und keiner von beiden zusammengeführt wurde.

Diese Lücke ist hier die ganze Geschichte, und sie ist eng. Das Modell ist real und herunterladbar; die Runtime-Unterstützung steht in einer Warteschlange. Dies ist ein Artikel zum bisherigen Wissensstand über die Warteschlange: was gerade in Arbeit ist, was heute tatsächlich läuft und was noch kommen müsste, bevor „funktioniert mit vLLM“ auf einer Modellkarte in dem Sinne wahr wird, in dem ein Deployment-Plan es braucht.

Die Karte nennt vLLM. Die Tabelle der unterstützten Modelle nennt LFM2.

Die Dokumentation von vLLM zu den unterstützten Modellen listet drei Liquid-AI-Architekturen auf: Lfm2ForCausalLM, Lfm2MoeForCausalLM und Lfm2VlForConditionalGeneration. Einen LFM3-Eintrag gibt es nicht. Die Modellkarte von LFM3-1.7B wiederum besagt, dass der Checkpoint „mit vLLM, SGLang und LFM3-kompatiblen llama.cpp-Builds funktioniert“, und nennt einen Serving-Befehl ohne angehängte Flags.

Die Auflösung liegt in der eigenen Konfiguration des Checkpoints. LFM3-1.7B enthält eine auto_map, die auf die mitgelieferte modeling_lfm3.py verweist, sodass der Code auf der Hugging-Face-Seite existiert und sich in Loader klont, die Remote-Code zulassen. vLLMs Tracking-Issue für den Port, #64645 – „[Feature]: Unterstützung für LiquidAI LFM3-Modelle“, am 30. Oktober von abhijithneilabraham eröffnet – sagt unverblümt, was die Folge ist: „vLLM hat kein Lfm3ForCausalLM.“ Als aufgeführte Alternative nennt es die Notlösung, die die meisten in diesem Monat nutzen werden: „LFM3 über den Remote-Code des Checkpoints mit dem Transformers-Backend ausführen. Das verzichtet auf Paged Attention und den Conv-State-Cache.“

Dieser Kompromiss verdient es, klar benannt zu werden, denn „läuft auf vLLM“ und „läuft auf vLLMs Transformers-Backend“ sind unterschiedliche Produkte. Paged Attention ist der Mechanismus, der es vLLM ermöglicht, Anfragen mit stark unterschiedlichen Längen zu bündeln, ohne KV-Speicher zu verschwenden; der Conv-State-Cache ist dieselbe Idee, angewendet auf die Short-Convolution-Schichten dieser Architektur. Nimmt man beides weg, bleibt ein funktionierender Endpunkt, der die beiden Gründe aufgegeben hat, aus denen es vLLM überhaupt gibt. Für ein 1,7B-Modell, das bei geringer Nebenläufigkeit bedient wird, mag das ein akzeptables Wochenendprojekt sein, aber keine akzeptable Produktionsform.

Warum braucht ein 1,7B-Modell überhaupt Kernel-Arbeit?

LFM3-1.7B ist kein einfaches Retuning der LFM2-Familie, die vLLM bereits bedient. Es ist ein 24-schichtiger Hybrid mit drei statt zwei Schichttypen: 13 gated Short-Convolution-Schichten, 5 Sliding-Window-Attention-Schichten mit einem Fenster von 256 Token und 6 Full-Attention-Schichten. Die Konfiguration des Checkpoints legt die Geometrie explizit dar – conv_L_cache: 7, sliding_window: 256, ein Vokabular von 128K –, und die Liste der Unterschiede im vLLM-Issue selbst ergänzt QK RMSNorm, ein Sigmoid-Attention-Ausgangsgatter pro Head, Sandwich-Normalisierung und partielles RoPE (partial_rotary_factor: 0.5) auf den Full-Attention-Schichten, angeordnet in derselben Zero-Tail-Form, die Gemma 4 verwendet.

Die Zahl, die den Port zum Scheitern brachte, ist die Sieben. LFM2s kurze Faltung ist drei Taps breit; LFM3 erweiterte sie auf sieben. Die Triton-Kernel causal_conv1d von vLLM entrollen einen festen Satz von Breiten, und wie es im Tracking-Issue heißt: „Der Triton-causal_conv1d-Prefill-Kernel entrollt Breiten von 2 bis 4 und der Decode-Kernel 2 bis 6, sodass ein Modell mit Breite 7 heute nicht auf CUDA laufen kann.“

Der erste PR im Stack ist also überhaupt kein Modell. #64647, „[Kernel] Support width-7 causal conv1d“, am 30. Oktober von abhijithneilabraham geöffnet, berührt zwei Dateien und 186 hinzugefügte Zeilen: Er erweitert den Prefill-Kernel von Breiten 2–4 auf 2–7 und den Decode-Kernel von 2–6 auf 2–7 und lässt beide Wrapper für alles außerhalb dieses Bereichs ValueError auslösen. Die Beschreibung des PR erklärt selbst, warum die Ablehnung genauso wichtig ist wie die Erweiterung: Vor der Änderung „lief ein breiteres Gewicht ohne passenden Zweig und lieferte falsche Werte zurück.“ Stille numerische Verfälschung ist ein schlimmerer Fehler als eine Ablehnung, und sie ist die Art von Problem, die nur bei dem Modell auftaucht, das man zufällig ausprobiert hat.

Ein Vorbehalt gehört zu diesem PR dazu. Der Autor erklärt offen, dass er keine CUDA-Maschine hat: Der CPU-Referenzpfad besteht 96 Tests, die Triton-Kernel wurden durch statische Analyse über den Kernel-AST geprüft, und die GPU-Validierung bleibt der CI überlassen. Das ist eine ehrliche Offenlegung und kein Mangel, aber es bedeutet, dass die eine Änderung, von der jeder andere LFM3-PR abhängt, noch nicht auf der Hardware erprobt wurde, auf der die meisten Leser sie ausführen werden.

Zwei Implementierungen desselben Textmodells

Innerhalb von sechs Tagen haben zwei separate Gruppen native LFM3-Unterstützung für vLLM geschrieben. Es handelt sich nicht um Varianten eines Patches; es sind unabhängige Designs, die zufällig denselben Architekturnamen installieren.

PR #64959, „[Model] LiquidAI LFM3 (Lfm3ForCausalLM) hinzufügen“, am 1. November von atmikshetty eröffnet, ist der konservative Ansatz: sieben Dateien, und laut eigener Beschreibung verwendet er ShortConv mit Breite 7, Lfm2MLP, den LFM2-Gewichtsmapper und das bestehende proportionale RoPE wieder und ändert keine Kernkomponenten. Er registriert das Modell in der Registry, fügt es dem Testset für Hybridmodelle und der Tabelle der unterstützten Modelle hinzu und dokumentiert – nützlich für alle, die es zum Laufen bringen – die Serving-Flags, mit denen es validiert wurde: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Sein Validierungsabschnitt meldet 324 bestandene Kernel-Tests auf einer A100-SXM4-40GB in BF16, bestandene Registry- und Initialisierungstests sowie einen Vergleich der Log-Wahrscheinlichkeiten gegen die Remote-Code-Referenz von Hugging Face.

PR #65826, „[Model] Add LFM3-Text“, am 5. November von paulpak58 geöffnet – der zu Liquid AI gehört –, ist die eigene Version des Anbieters: zehn Dateien und 829 hinzugefügte Zeilen, einschließlich einer eigenen Konfigurationsklasse unter transformers_utils/configs/lfm3.py und eines eigenen Testmoduls. Sie wurde als „[Model] Add LFM3“ geöffnet und noch am selben Tag umbenannt, als die Familie in vier gestapelte PRs aufgeteilt wurde: #65826 für Text, #65827 für Vision-Language, #65828 für Audio und #65829 für Omni, wobei jeder auf dem vorherigen aufbaut.

Die beiden stehen weniger in Konflikt als vielmehr parallel zueinander, und die Diskussion zeigt das Geflecht der Abhängigkeiten deutlich. Zum Kernel-PR schrieb paulpak58 am 4. November: „We have our own internal PRs for LFM3 models, but this is a clean addition we can back.“ Zum Community-Text-PR merkte abhijithneilabraham an, dass der Merge möglicherweise erst Liquid's transformers-Arbeit erfordert – „I believe the merge of this PR requires the transformers PR from @paulpak58“ –, worauf atmikshetty erwiderte, dass Lfm3Config noch in keiner transformers-Version enthalten sei, sodass der Branch „loads the config via trust_remote_code from the checkpoint, and execution uses the native vLLM model.“ Das ist das zweite Hindernis, an das die meisten Leser nicht gedacht haben dürften: Selbst ein gemergter vLLM-PR braucht eine Config-Klasse, die irgendwo ausgeliefert wird.

Auf der transformers-Seite ist der entsprechende PR #50322, „[Model] LFM3 Family: LFM3-Text“, der am 3. November eröffnet wurde und noch offen ist und aus einem größeren Family-PR herausgetrennt wurde. Die eigene Anmerkung zur Konvolution deckt sich mit dem vLLM-Issue: Die Short Conv ist „torch-only in LFM3 (die causal_conv1d-Kernel auf dem Hub decken Breiten 2–4 ab, LFM3 verwendet 7)“.

Vision-Language wird ebenfalls dupliziert. Neben Liquids #65827 ist ein unabhängiger LFM3-VL-PR (#65450, eröffnet am 3. November) weiterhin offen und hängt vom Community-Text-PR ab. Somit gibt es Stand heute sechs offene LFM3-PRs in zwei Lagern und keinen gemergten.

Was heute tatsächlich läuft

Lässt man die Spekulationen beiseite, sieht das praktische Bild am 5. November so aus.

• vLLM, nativ — mit einem Standard-Build nicht möglich. Kein Lfm3ForCausalLM in der Registry, keine LFM3-Zeile in der Tabelle der unterstützten Modelle, und der PR, der eine hinzufügen würde, ist noch nicht gemergt.

• vLLM, Transformers-Backend — der dokumentierte Workaround unter Verwendung des im Checkpoint gebündelten Remote-Codes und von trust_remote_code. Sie verlieren Paged Attention und den Conv-State-Cache; der OpenAI-kompatible Server bleibt Ihnen erhalten.

• SGLang — der eigene Serverpfad des Anbieters. Der Launch-Post von Liquid misst seine Durchsatzwerte auf einer einzelnen NVIDIA B300 in BF16 mit SGLang, einschließlich 3,6 Milliarden Tokens pro Tag bei 1.024 gleichzeitigen Anfragen. vLLM taucht in diesem Post nur als die Runtime auf, auf der konkurrierende Modelle bereitgestellt wurden.

• llama.cpp — die Karte bezieht sich auf „LFM3-kompatible llama.cpp-Builds“, was eine echte Einschränkung und keine bloße Standardfloskel ist; Liquids On-Device-Werte sind llama.cpp bei Q4_0 mit einem 32K-Kontext.

• MLX — die Versionshinweise 0.33.0 des separaten vLLM-Metal-Projekts führen LFM3-Text-MLX-Checkpoints auf, hinter --trust-remote-code. Das ist eine andere Codebasis als das Upstream-vLLM und impliziert keine CUDA-Unterstützung.

• Hosted — Liquids eigene API und Playground. Die Karte nennt keine Preisliste, daher lassen sich die Kosten pro Token nicht anhand öffentlich verfügbarer Informationen kalkulieren.

Zwei Zahlen verdeutlichen das Argument für Self-Hosting. Die Gewichte sind klein genug, dass der Speicher nicht der Engpass ist – Liquid gibt für 4 Bit etwa 1 GB an –, und der Hersteller sagt, dass ein Kontext mit 128K Token ungefähr 1,6 GB KV-Cache kostet. Der Engpass ist der Serving-Stack, nicht die GPU.

Was würde das ändern, der Reihe nach

Die Abhängigkeitskette ist ungewöhnlich sauber, was die Sache, die es zu beobachten gilt, ungewöhnlich spezifisch macht. Zuerst muss #64647 gemergt werden, denn jeder andere LFM3-PR enthält diesen Commit entweder oder baut darauf auf. Dann muss einer der beiden Text-PRs das Review gewinnen – der Community-PR hat die vollständigere Validierungsdokumentation, der Liquid-PR hat den Autor, der auch die transformers-Seite verantwortet. Dann muss Lfm3Config in einem transformers-Release landen, sonst muss jede Deployment weiterhin trust_remote_code übergeben. Erst danach werden LFM3-VL-2B, LFM3-Audio-2B und LFM3-Omni-2B realistisch, und diese hängen hinter weiteren PRs, die voraussetzen, dass das Textmodell bereits enthalten ist.

Nichts davon sollte als Kritik am Tempo verstanden werden. Neun Tage von einem Launch bis zu einem vollständigen, getesteten PR-Stack aus Kernel und Modell sind schnell, und die Tatsache, dass zwei unabhängige Teams in weniger als einer Woche funktionierende Implementierungen erstellt haben, sagt mehr darüber aus, wie nah LFM3 an LFM2 liegt, als über irgendeine Verzögerung. Aber eine Model Card ist eine Kompatibilitätsaussage, und die ehrliche Lesart des heutigen Stands von LFM3-1.7B ist „kompatibel mit vLLM über das Transformers-Backend“, nicht „von vLLM unterstützt“.

Wenn Sie diese Woche ein kleines Tool-Calling-Modell benötigen

LFM3-1.7B ist ein attraktives Ziel. Die vom Anbieter gemeldeten Werte sind stark genau dort, wo kleine Modelle üblicherweise scheitern – 71.39 bei BFCL V4, 80.36 bei ToolSandbox, 96.66 bei IFEval, 43.40 bei SWE-bench Verified – gegenüber einem Gesamtdurchschnitt von 49.37, den Liquid vor sein eigenes LFM2.5-2.6B mit 31.55 setzt. Das sind die eigenen Evaluierungen des Anbieters, durchgeführt von dem Unternehmen, das das Modell gebaut hat, ohne unabhängige Reproduktion und ohne Artificial-Analysis-Eintrag, den wir mit Stand heute finden konnten; behandle die Reihenfolge als Hypothese und die einzelnen Zahlen als Behauptungen. Der begleitende Vorbehalt stammt aus derselben Quelle: Die Modellkarte rät von agentischem Coding und komplexem mehrstufigem Reasoning ab, und die Wissens-Benchmarks stimmen mit diesem Rat überein – 63.37 bei GPQA Diamond und 65.56 bei RULER mit 128K sind nicht die Zahlen eines Generalisten.

Die Entscheidung hängt also nicht wirklich vom Modell ab. Sie hängt davon ab, ob Sie es sich leisten können, auf einem Serving-Pfad aufzubauen, der derzeit ein offener Pull Request ist. Wenn Sie SGLang oder llama.cpp ausführen können, können Sie LFM3-1.7B heute nutzen, und die vLLM-Frage ist akademisch. Wenn Ihr Stack per Richtlinie vLLM ist, wählen Sie zwischen der fehlenden Paged Attention des Transformers-Backends und dem Warten.

Es gibt eine dritte Option, die es wert ist, genannt zu werden, für die Workloads, die nicht warten können: etwas anderes routen. OrcaRouter führt LFM3-1.7B nicht — eine Prüfung unseres Katalogs liefert heute mehr als 200 Modell-IDs, und keine davon ist von Liquid — das ist also kein Plädoyer dafür, es über uns aufzurufen. Es ist der einfachere Punkt, dass ein nicht gemergter Kernel-PR ein schlechter Single Point of Failure für einen Produktionspfad ist. Ein gehostetes Modell mit einer API und automatischem Failover vorzuschalten kostet dich eine Konfigurationsänderung und ermöglicht es dir, LFM3-1.7B an dem Tag einzutauschen, an dem seine native Unterstützung gemergt wird, statt an dem Tag, an dem du aufhörst, darauf zu wetten. Wenn du das Modell modifizierst, statt es nur aufzurufen, ist unser eigener LFM3-1.7B-abliterated-Release eine Refusal-Direction-Ablation desselben Checkpoints, und er erbt genau diese Serving-Situation.

Die Kurzfassung

LFM3-1.7B ist draußen, klein und gut geeignet für die Single-Turn-Tool-Calling-Aufgaben, für die es trainiert wurde. Die vLLM-Unterstützung dafür wird gerade geschrieben, von zwei Teams, auf Basis einer Kernel-Erweiterung, die von der Person, die sie geschrieben hat, noch nicht auf CUDA ausgeführt wurde. Beobachte zuerst #64647 — wenn die Width-7-Convolution gemergt wird, geht es mit dem Rest des Stacks schnell voran, und „funktioniert mit vLLM“ auf der Modellkarte ist dann keine Aussage mehr über Remote-Code, sondern über Paged Attention und Batching. Bis dahin zitiert jeder, der „vLLM-Unterstützung ab Tag eins“ für dieses Modell angibt, etwas, das das Repository noch nicht enthält.