LFM3-Leak: Liquid AIs nächste Familie besteht aus vier kleinen Omni-Modellen

Ein am 27. Oktober 2026 auf GitHub eröffneter Pull-Request will SGLang beibringen, wie man eine Modellfamilie bedient, die in der Öffentlichkeit nicht existiert. Er nennt vier Checkpoints – LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B und LFM3-Omni-2B – und liest sich gegenüber den ausgelieferten LFM2.5-2.6B und LFM2.5-24B-A2B wie eine Blaupause dafür, was Liquid AI als Nächstes baut. Der PR ist nicht gemergt. Alle drei seiner CI-Prüfungen schlagen fehl. Liquid AI hat nichts davon angekündigt. Dieser nicht gemergte Diff ist mit Stand heute der gesamte öffentliche Beleg zu LFM3, und er ist informativer als die meisten Launch-Posts – vorausgesetzt, man liest ihn als das, was er ist.

Seien wir also präzise, was die Belege angeht, denn in die eine Richtung sind sie dünn und in die andere ungewöhnlich detailliert. Nichts davon ist ein Veröffentlichungsdatum, ein Preis, eine Lizenzbedingung oder ein Benchmark-Wert. Es gibt keine LFM3-Modellkarte, kein Hugging-Face-Repository, keinen Blogbeitrag, keine API-Auflistung. Was es gibt, ist ein Beitrag von tugot17 – Piotr Mazurek, der in den vergangenen zwei Monaten LFM-Runtime-Unterstützung in SGLang, llama.cpp und mlx-vlm eingebracht hat – sowie Liquids eigenes veröffentlichtes Material zur LFM2.5-Generation, die demnächst abgelöst werden soll. Alles Folgende ist entsprechend gekennzeichnet.

Was der Pull Request tatsächlich auf den Tisch bringt

Der PR-Titel lautet [Feat] lfm3: Text-, Vision-, Audio- und Omni-Unterstützung hinzufügen, und er trägt zwei Labels, die dir sagen, um welche Art von Änderung es sich handelt: jit-kernel und Multi-modal. Er fügt native Textgenerierung für eine Familie aus vier Modellen hinzu, jedes mit seinem eigenen Checkpoint-Pfad:

• LFM3-1.7B — Text rein, Text raus, das einfache Sprachmodell an der Basis der Familie

LFM3-VL-2B — Text, Bilder und Video als Eingabe, Text als Ausgabe

• LFM3-Audio-2B — Text und Audio rein, Text raus, und außerdem mit dem Endpoint /v1/audio/transcriptions verbunden

• LFM3-Omni-2B — Text, Bilder, Audio und Video als Eingabe, einschließlich des eigenen Soundtracks eines Videos, Text als Ausgabe

Ein Detail in dieser Liste verdient einen Moment des Innehaltens. Jede Variante gibt Text aus. Es gibt nirgends im PR einen Audio-Ausgabepfad, und die Nicht-Chat-Oberfläche des Audiomodells ist Transkription – Sprache rein, Text raus. Das ist enger als Liquids aktuelle Audio-Produktlinie, in der LFM2.5-Audio-1.5B laut Dokumentation ASR, TTS und verschachtelten Sprachchat in einem einzigen Modell abdeckt. Entweder deckt der erste SGLang-Schnitt nur die textgenerierende Hälfte von LFM3-Audio ab, oder die Omni-Familie lässt die Sprachsynthese tatsächlich weg. Der PR kann nicht klären, was davon zutrifft, und wer dir erzählt, er könne es, rät nur. Behandle „LFM3 spricht“ als unbewiesen.

Der Rest des Diffs ist Implementierungsdetail, das dennoch die Entstehungszeit verrät. Vision- und Audio-Encoder mit ihren Projektoren, ein gemeinsames Backbone, Hybrid-Cache-Integration, CuTe-DSL-Faltungskernel mit PyTorch-Fallback und ein Hinweis, dass FlashInfer standardmäßig paged Prefill verwendet, damit sich Sliding-Window-Attention korrekt verhält. Die Validierung lief auf H100s in FP16 mit den von der Beschreibung so genannten Entwicklungs-Checkpoints – vier Wörter, die später wichtig werden.

Der Satz zur Architektur – und die Zahl, die viele falsch lesen werden

Der PR beschreibt LFM3 als gemeinsames Rückgrat aus gated Short Convolutions mit Full- und Sliding-Window-Attention. Das ist die fortgeführte LFM2-Linie, keine Ablösung: LFM2.5-24B-A2B ist als Hybrid aus gated Short Convolutions und Grouped-Query-Attention über 40 Schichten dokumentiert. Neu im Leak wirkt die explizite Sliding-Window-Komponente, die neben der Full-Attention angesiedelt ist.

Die Validierungsnotizen erwähnen einen Prompt, der über ein gleitendes Fenster von 256 Token hinausläuft, und dies ist die Zahl, die die ganze Woche über aus dem Zusammenhang gerissen zitiert werden wird. Sie ist nicht die Kontextlänge von LFM3. In einem hybriden Design müssen die Attention-Schichten nur lokal sehen, weil die Faltungsschichten das langreichweitige Signal tragen – das ist die gesamte Prämisse der Architektur, und deshalb kann die Familie auf LFM2.5-24B-A2B 131.072 Token Kontext halten, während die meisten ihrer Schichten überhaupt keine quadratische Attention ausführen. Ein Attention-Fenster von 256 Token ist eine Aussage darüber, wohin das Modell innerhalb einer Schicht schaut, nicht darüber, wie viel Text es aufnehmen kann. Der PR nennt nicht die Gesamtkontextlänge von LFM3, und niemand außerhalb von Liquid kennt sie bisher.

Warum ein Runtime-Pull-Request das Signal und nicht das Rauschen ist

Es ist vernünftig, skeptisch zu sein, wenn man Produktstrategie aus einem Infrastruktur-Diff ableiten will. In diesem konkreten Fall ist das Muster zu konsistent, um es zu ignorieren, denn Liquid liefert die Engine-Unterstützung mit den Gewichten statt danach aus. LFM2.5-2.6B nennt llama.cpp, MLX, vLLM, SGLang, ONNX und Transformers 5.0+ als Ziele für den ersten Tag. LFM2.5-24B-A2B wurde zum Start in llama.cpp, MLX, vLLM, SGLang und ONNX unterstützt. Eine Familie, die mit fünf fertigen Runtimes auf den Markt kommt, muss ihre Kernel vor der Ankündigung geschrieben haben, was bedeutet, dass die PRs zuerst eingehen und der Blogpost danach folgt.

Der Autor fügt sich genau in diese Chronologie ein. Mazureks öffentliche Historie ist eine Reihe von LFM-Integrationsarbeiten: DSpark-Speculative-Decoding für LFM2-VL in SGLang im September, LFM2.5-VL-3B- und DSpark-Draft-Modell-Korrekturen in llama.cpp im selben Monat, vom Textmodell in mlx-vlm übernommene spekulative Dekodierung und eine Wiederverwendung einer LFM2-MoE-Konfiguration in SGLang am 13. Oktober. LFM3 ist der nächste Eintrag in dieser Sequenz, eingereicht an dem Wochenende, an dem die Familie den Namen änderte.

Zwei Abwesenheiten sind ebenso aussagekräftig wie die Anwesenheit. Es gibt keinen passenden Pull Request in Hugging Face Transformers für LFM3 – eine Suche in diesem Repository liefert nichts – und der SGLang-PR lädt seine Checkpoints über Standard-Transformers 5.19.0 mit --trust-remote-code, was man tut, wenn die Architektur noch nicht nativ in der Bibliothek ist. Außerdem gibt es einen Commit, der spekulatives Dekodieren für LFM3 ausdrücklich ablehnt, sodass die DSpark-Arbeit, die für die 2.5-Generation ausgeliefert wurde, noch nicht übernommen wurde. Früh und bewusst unvollständig.

Die Größenfrage, die niemand beantwortet hat

Hier ziehen das Leck und der erklärte Ehrgeiz in entgegengesetzte Richtungen, und die Spannung ist das Interessanteste an dem Dokument.

Maxime Labonne, Head of Pretraining bei Liquid, hat das Ziel von LFM3 als Test dafür beschrieben, ob der Short-Convolution-Ansatz, der im Maßstab von 350 Mio. bis 1,2 Mrd. funktioniert, auch jenseits von 10 Mrd. Parametern bestehen kann – dem Bereich, in dem Attention-Architekturen historisch im Vorteil waren. Das ist eine Skalierungsfrage, und sie impliziert ein großes Modell.

Die geleakten Checkpoints sind 1,7B und drei mit 2B. Keiner davon liegt über dem Schwellenwert, um den es in der Frage geht.

Zwei Lesarten bleiben bestehen. Die erste ist, dass dies die kompakte erste Welle sind – eine Omni-Familie für Telefone und Autos, bevor ein großes Geschwistermodell erscheint, was dazu passt, dass Liquid schon immer mit kleinen Modellen vorangegangen ist und dass die PR sie als Entwicklungs-Checkpoints statt als finale Releases beschreibt. Die zweite ist, dass 1.7B und 2B einfach die Größen sind, die sich bequem eigneten, um Kernel dagegen zu validieren, und uns nichts darüber sagen, was tatsächlich ausgeliefert wird. Die ehrliche Haltung ist, dass das Leck beweist, dass die Familie existiert, und ihre Form beweist; es beweist nicht ihre Obergrenze. Wenn Sie auf ein Liquid-Modell mit >10B warten, verspricht diese PR weder eines noch schließt sie eines aus.

Was LFM3 erbt – im Guten wie im Schlechten

Die Baseline, die es schlagen muss, ist aktuell und gut dokumentiert. LFM2.5-24B-A2B erschien am 13. Oktober 2026 mit insgesamt 24B Parametern, davon 2B aktiv, 40 Schichten, 64 Experten und Top-4-Routing, einem Kontext von 131.072 Tokens, einem Vokabular von 128K und 33T Vortrainings-Tokens. LFM2.5-2.6B von Anfang August passt mit einem 128K-Kontext in weniger als 2,5 GB. LFM2.5-VL-3B kombiniert die 2,6B-Basis mit einem SigLIP2-Vision-Encoder.

Um es klar zu sagen: Sämtliche Benchmarks, die Liquid hierfür veröffentlicht, werden vom Anbieter selbst auf Liquid-eigenen Testumgebungen durchgeführt, ohne dass eine unabhängige Bewertung beigefügt ist. Die prominenten Zahlen von LFM2.5-24B-A2B – AutomationBench 27,69, BFCLv4 65,01, ToolSandbox 80,71, IFEval 96,75 – sind Liquid-Zahlen, und dieselbe Tabelle zeigt, dass es auf WebArena Verified (26,75 gegenüber 37,62), bei GPQA Diamond und bei SWE-Bench Verified gegen Qwen3.6-35B-A3B verliert. Anbietertabellen, die Niederlagen enthalten, sind glaubwürdiger als solche, die das nicht tun, aber glaubwürdig ist nicht dasselbe wie verifiziert. Es gibt keinerlei LFM3-Zahlen, daher gibt es noch nichts zu vergleichen.

Die Lizenzierung wird ebenfalls weitergeführt. Liquids aktuelle LFM-Checkpoints auf Hugging Face sind jeweils mit license: other gekennzeichnet – einer maßgeschneiderten LFM-Lizenz, nicht Apache-2.0 oder MIT. Unter welcher Lizenz LFM3 auch immer erscheint, geh von denselben individuellen Bedingungen aus, bis eine Model Card etwas anderes sagt, und lies sie, bevor du ein Produkt auf den Gewichten aufbaust.

Wann es tatsächlich kommen könnte

Niemand kennt ein Datum, auch nicht die Leute, die beruflich raten. Eine Frage auf Manifold Markets dazu, wann LiquidAI LFM3 veröffentlicht wird, setzt Q4 2026 auf 40 %, Q1 2027 auf 21 %, Q2 2027 auf 21 %, Q3 2026 auf 11 % und Q2 2026 auf 7 % — bei einem Gesamtvolumen von rund Ṁ160, das klein genug ist, dass die Prozentwerte eine Handvoll Trader statt einen Konsens widerspiegeln. Lies es als „irgendwann in den nächsten zwei Quartalen, wahrscheinlich“, und nicht präziser als das.

Die Mechanik spricht dafür, es eher früher als später anzugehen. Kernel-Arbeit, die in einer wichtigen Runtime landet, ist Engineering der späten Phase, nicht der frühen Phase – man schreibt keine CuTe-Convolution-Kernel und verdrahtet keinen hybriden Cache für ein Modell, das noch ein Jahr entfernt ist. Der Familienname hat sich bei vier Varianten und vier Checkpoint-Pfaden zu LFM3 stabilisiert. Aber der PR ist nicht gemergt, alle drei Checks sind rot, er benötigt eine zustimmende Review, die ihm fehlt, und 2 von 22 Omni-Validierungschecks sowie 2 von 16 Vision-Checks scheitern weiterhin an ihrem ROUGE-Vergleich. Das ist ein Branch mitten in der Entwicklung, kein Release Candidate.

Was das bedeutet, wenn Sie diese Woche ein Modell auswählen

Nichts an LFM3 sollte eine Entscheidung ändern, die Sie heute treffen. Es ist nicht verfügbar, nicht bepreist, nicht gebenchmarkt und nicht öffentlich lizenziert. Wenn Sie jetzt ein kleines multimodales Modell benötigen, ist die LFM2.5-Generation die eigentliche Antwort, und ihre Einschränkungen – vom Anbieter berichtete Werte, eine individuelle Lizenz und ein Coding-Profil, das sowohl die eigenen Tabellen von Liquid als auch externe Berichterstattung als Schwachstelle kennzeichnen – sind die Dinge, die abzuwägen sind.

Wofür der Leak wirklich nützlich ist, ist die Planung. Er verrät dir, dass eine kompakte Omni-Familie kommt, dass sie wahrscheinlich gleichzeitig für mehrere Runtimes erscheinen wird und dass ihre Audiovariante möglicherweise keine Sprachsynthese bietet. Wenn deine Roadmap davon ausging, dass Liquids nächster Schritt ein größeres Textmodell sei, stützt die bisherige Evidenz diese Annahme nicht.

Die Laufzeitfragmentierung ist das praktische Problem, das diese Modellfamilie erzeugen wird. Liquids Angewohnheit, gleichzeitig in llama.cpp, MLX, vLLM, SGLang und ONNX auszuliefern, ist gut für die Portabilität und unpraktisch für jeden, der einen einzigen Endpunkt möchte: fünf Engines bedeuten fünf Deployment-Formen, fünf Sätze von Vorverarbeitungs-Eigenheiten und fünf verschiedene Termine, zu denen ein Fix eintrifft. OrcaRouters Katalog mit mehr als 200 Modellen enthält heute keinen einzigen LFM-Checkpoint, daher gibt es keine Möglichkeit, LFM3 über ihn aufzurufen, und nichts hier sollte als Versprechen gelesen werden, dass es einen geben wird. Wofür eine Routing-Schicht in dieser Situation tatsächlich da ist, ist die Nahtstelle zwischen einem unerprobten Modell und einem Produktionspfad — einen Teil des Traffics an etwas Neues zu leiten, während ein bekanntes Modell dahinter bleibt, wobei Failover die Lücke auffängt; so bewertet man den Nachfolger einer unveröffentlichten Familie, ohne ein kundengerichtetes Feature auf einen 40-%-Prognosemarkt zu verwetten.

Die offenen Fragen, die es zu beobachten gilt

Vier Dinge werden das schneller klären als jede weitere Spekulation. Ob die vier Checkpoint-Pfade echte, herunterladbare Hugging-Face-Repositories werden – derzeit liefert eine Suche in der LiquidAI-Organisation unter LFM3 nichts, und die im PR genannten Repositories lassen sich öffentlich nicht auflösen. Ob ein Transformers-PR auftaucht, was signalisieren würde, dass die Architektur ordnungsgemäß upstream geführt wird, statt über Remote-Code zu laufen. Ob die fehlschlagenden Validierungsprüfungen geschlossen werden, denn 2 von 22 Omni-Fehlschlägen sind der Unterschied zwischen einer Demo und einem Merge. Und ob ein >10B-Mitglied der Familie auftaucht, die Frage, zu deren Beantwortung LFM3 laut Labonne existiert.

Bis dahin ist der treffendste Satz, den man über LFM3 schreiben kann, der, mit dem dieser Artikel begonnen hat: Es gibt einen Pull Request, er ist nicht gemergt, und er nennt vier kleine Omni-Modelle, die Liquid AI noch nicht angekündigt hat. Das ist ein echtes Signal – nur ein frühes, und frühe Signale sollte man genau als das lesen.