LFM2.5-24B-A2B: Routing mit Bias, kurze Faltungen und zehn KV-Caches

Liquid AI veröffentlichte LFM2.5-24B-A2B am 13. Oktober 2026, mit herunterladbaren Basis- und nachtrainierten Gewichten. Das Modell übernimmt die hybride Faltungs-/Attention-Architektur und die sparsamen Feed-forward-Netze seines Vorgängers; neu sind ein größeres Vokabular, längerer Kontext und ein überarbeitetes Training. Dieser Artikel erklärt den veröffentlichten Checkpoint zur Textgenerierung, ohne die übernommene Architektur als neue Erfindung darzustellen.¹

Zwei voneinander unabhängige Einsparungen sind relevant: In jeder MoE-Schicht laufen pro Token vier von 64 Experten, und nur zehn von 40 Schichten halten einen wachsenden Attention-Cache. Keine der beiden Einsparungen macht das vollständige Modell zu einer Speicherbelegung von zwei Milliarden Parametern. Alle folgenden Speicherwerte sind Berechnungen, keine Messungen aus einem GPU-Lauf.

Der genaue Checkpoint

Tabellen und Formeln verwenden die internationale Zahlenschreibweise: Komma für Tausendergruppen, Punkt für Dezimalstellen.

Die Prüfung verwendet Modellrevision 1769516ac588c4c558089c94f27d96b0dc67b183 und Transformers-Code auf Revision 28034545c35acac05793695bd5c878f66e6b544e, geprüft am 14. Oktober 2026. Letztere dient als Code-Referenz; daraus folgt nicht, dass Liquid diesen Commit für seine Benchmarks verwendet hat. Der Checkpoint nennt Lfm2MoeForCausalLM; seine Konfiguration vermerkt Transformers 5.12.1.²³

Diese Werte stammen aus der Konfiguration, mit zwei Ausnahmen: Die Head-Breite folgt aus 2,048 / 32, die Zustandsbreite bestätigt die Cache-Implementierung. Die ersten beiden Schichten sind dicht und verwenden Faltungen. Die Wahl des Token-Mixers und die Wahl des Feed-forward-Netzes sind unabhängige Entscheidungen.²⁴

Bei Batch-Größe $B$ und Sequenzlänge $T$ behält ein Block die Form $[B,T,2048]$ bei. Er wendet vor dem Mixer RMS-Normalisierung an und addiert eine Residualverbindung. Anschließend folgen eine weitere RMS-Normalisierung, das dichte oder sparse Feed-forward-Netz und eine zweite Residualverbindung.³

Der Router verwendet zwei verschiedene Scores

Die normalisierten Hidden States werden zu $X\in\mathbb{R}^{N\times2048}$ mit $N=BT$ zusammengefasst. Eine Router-Matrix $W_r\in\mathbb{R}^{64\times2048}$ erzeugt 64 Logits pro Token. Die Implementierung wendet auf jeden davon separat Sigmoid an. Bei use_expert_bias=true beeinflusst ein gespeicherter Bias mit 64 Elementen die Top-4-Auswahl, wird aber nicht in die Mischgewichte übernommen.³

Der Checkpoint aktiviert diese Normalisierung und setzt den Routing-Skalierungsfaktor auf 1. Bei exakter Arithmetik summieren sich die Gewichte wegen des Epsilon auf etwas weniger als eins; endliche Genauigkeit kann diesen Unterschied wegrunden. Jeder ausgewählte Experte berechnet ein gegatetes SiLU-MLP mit drei Matrizen und insgesamt $3\times2048\times1536=9,437,184$ Gewichten. Zur Laufzeit können die beiden Eingangsmatrizen zusammengefasst werden; ihre Funktion bleibt dabei gleich.²³

Das folgende Beispiel zeigt ein Token mit fünf Kandidaten; die übrigen 59 Experten haben niedrigere Auswahlscores. Die Zahlen sind synthetisch und keine Messungen des Checkpoints.

E verdrängt D, trägt aber mit 0,40 statt mit dem durch Bias erhöhten Wert 0,60 bei. Wer die Auswahlscores als Mischgewichte verwendet, implementiert ein anderes Modell. Gleiches gilt für einen Austausch von Sigmoid durch Softmax: Ohne Bias erhalten beide zwar die Reihenfolge der Logits, liefern aber unterschiedliche Verhältnisse der normalisierten Gewichte. Ein nach der Aktivierung addierter Bias kann außerdem die ausgewählte Menge verändern.

Der Inferenzcode liest den gespeicherten Bias; er passt ihn nicht an den aktuellen Serving-Batch an. Die Trennung von Auswahl und Beitrag erlaubt Auswahlpräferenzen, ohne die Ausgabekoeffizienten direkt zu erhöhen. Daraus folgt keine gleichmäßige Expertenauslastung im Betrieb, und auch die Trainingsregel zur Bias-Anpassung ist damit nicht belegt. Verschiedene Tokens eines Batches können zusammen viele oder alle Experten aktivieren. Dispatch, Umgruppierung der Tokens und ungleiche Expertenlast bleiben relevant; siehe Expert Parallelism.

Eine kurze Faltung ist ein lokaler Mixer, kein Embedding-Lookup

Der Faltungspfad projiziert einen normalisierten Hidden-Vektor in drei Streams der Breite 2,048, im Code B, C und x genannt. Damit der Stream-Name nicht mit der Batch-Größe verwechselt wird, heißen sie hier $g,u,v$. Zuerst wird $g\odot v$ gebildet, dann eine kanalweise kausale Faltung der Breite drei ausgeführt. Das Ergebnis wird mit $u$ multipliziert und auf Breite 2,048 zurückprojiziert.³

Die Gleichung indiziert Kernel-Koeffizienten nach zeitlichem Abstand; im Tensor können sie in umgekehrter Reihenfolge liegen. Die Streams sind direkte lineare Projektionen, ohne Sigmoid auf diesen multiplikativen Gates. „Double-gated“ bezeichnet die Multiplikationen vor und nach der Faltung. Der kanalweise Kernel mischt keine Kanäle miteinander; dafür sorgen die umgebenden dichten Projektionen. Hier gibt es weder gehashte Engram-Lookups noch eine eingabeunabhängige Speichertabelle.

Das unmittelbare rezeptive Feld umfasst drei Positionen. Gestapelte Schichten erweitern es, und die eingestreuten Attention-Schichten greifen auf die gesamte vorherige Sequenz zu. Eine Faltungsschicht allein kann nicht beliebige frühere Tokens abrufen, nur weil das Modell 131,072 Positionen akzeptiert. Beim normalen Decode mit Cache speichert die Implementierung drei aktuelle $a$-Vektoren pro Faltungsschicht. Mathematisch benötigt der nächste Ausgabewert zwei vorherige Positionen; die Laufzeitimplementierung reserviert aber einen Zustand mit drei Positionen. Für Rollbacks kann zusätzliche Historie aufgezeichnet werden.⁴

Zehn Schichten behalten vollständige Attention

Jede Attention-Schicht projiziert $Q:[B,32,T,64]$, $K:[B,8,T,64]$ und $V:[B,8,T,64]$. Je vier Query-Heads teilen sich einen KV-Head. Queries und Keys erhalten pro Head RMS-Normalisierung und anschließend RoPE; Values nicht. Konfiguriert ist die Standard-RoPE-Formel mit Theta $10^7$, kein YaRN. Der kausale Attention-Skalierungsfaktor beträgt $1/\sqrt{64}=1/8$.²³

$M$ ist die kausale Maske. Der Ausdruck beschreibt die logische Operation; ein fusionierter Kernel muss die $T\times T$-Score-Matrix nicht materialisieren. Vollständige Attention behält quadratische Prefill-Arithmetik und beim Decode einen Lesezugriff, der mit der Cache-Länge wächst. Der Ersatz von 30 Attention-Schichten reduziert diese Kosten, beseitigt sie aber nicht.

Für BF16-Keys und -Values benötigt eine Sequenz mit $T$ gecachten Tokens die folgende logische Nutzlast, ohne Allokations-Padding, Aktivierungen und Workspaces:²

Der hypothetische Vergleich behält Head-Geometrie und Datentyp bei und gibt jeder Schicht vollständige Attention. Er vergleicht keine Modellqualität mit einem anderen veröffentlichten Modell. Der normale Faltungszustand ergänzt $30\times2048\times3\times2=368,640$ Bytes, also 360 KiB pro Sequenz, unabhängig von der Kontextlänge. Bei unabhängigen gleichzeitigen Sequenzen werden die Nutzlasten multipliziert; geteilte Präfixe und das Laufzeitlayout müssen separat berücksichtigt werden. Der KV-Cache-Guide erklärt diesen Unterschied.

Aktive Gewichte bestimmen nicht den residenten Speicher

Der Gewichtsindex meldet 23 971 585 280 Parameter und 47 943 180 288 Tensor-Bytes, ungefähr 44,65 GiB. Das ist serialisierte Tensor-Nutzlast, keine maximale Gerätespeicherbelegung. Sparse Ausführung überspringt Berechnungen nicht ausgewählter Experten; sie entfernt deren Gewichte nicht aus einer vollständig residenten Bereitstellung.⁵

Über 38 MoE-Schichten entfallen ungefähr 22,951 Milliarden Parameter auf Expertengewichte. Werden in dieser Zählung alle 64 Experten durch vier ausgewählte ersetzt, ergeben sich ungefähr 2,455 Milliarden aktive Parameter, passend zur Angabe 2.45B in der Model Card. Diese Zählung berücksichtigt alle übrigen Gewichte einschließlich der geteilten Vokabularmatrix, obwohl das Eingabe-Embedding nur einzelne Zeilen abruft. Sie ist keine exakte Schätzung von FLOPs oder Speicherverkehr.⁵⁶

Allein die geteilte Vokabularmatrix enthält $128000\times2048=262,144,000$ Gewichte: 500 MiB bei BF16. Das Teilen vermeidet eine zweite Matrixallokation; die Ausgabeprojektion bewertet trotzdem 128,000 Vokabulareinträge. Vollständige BF16-Tensor-Nutzlast plus ein BF16-KV-Cache mit maximaler Länge ergeben bereits ungefähr 47,15 GiB, bevor weitere Allokationen hinzukommen. Quantisierung oder Offload verändern das Budget und bringen eigene Genauigkeits-, Bandbreiten- und Laufzeitgrenzen mit; siehe Quantisierung.

Wird eine Multiplikation mit anschließender Addition als zwei FLOPs gezählt, kosten die Matrixprodukte der ausgewählten Experten ungefähr $2\times38\times4\times3\times2048\times1536\approx2.869$ GFLOPs pro Token. Die Berechnung aller 64 Experten wäre für diesen Anteil 16-mal so teuer. Das erklärt die arithmetische Einsparung bei einem größeren Vorrat trainierter Expertenfunktionen. Es belegt weder eine 16-fache Gesamtbeschleunigung noch einen Qualitätsvorteil gegenüber einem dichten Modell. Attention, gemeinsame Projektionen, Vokabular-Head, Dispatch und Speicherverkehr fehlen in dieser Schätzung.

Was im Betrieb geprüft werden muss

Die untersuchte Transformers-Implementierung trennt die Attention-Backend-Auswahl, die Prefill-Faltung und Updates des Faltungszustands für einzelne Decode-Tokens. Sie enthält PyTorch-Fallbacks für die Faltung und Hooks zum Austausch durch optimierte Kernel. Der Standardpfad für Experten gruppiert Tokens nach Experte und summiert gewichtete Ausgaben. Ein konfigurierter Modellname verrät nicht, welche optimierten Kernel tatsächlich ausgeführt wurden.³

Liquids veröffentlichter GPU-Test verwendete eine B300, SGLang 0.5.22, BF16, 1,024 Eingabetokens und bis zu 256 Ausgabetokens. Bei fester Parallelität wurden abgeschlossene Requests kontinuierlich ersetzt. Der gemeldete Gesamtdurchsatz ist weder die Decode-Geschwindigkeit eines einzelnen Requests noch ein Test mit 131k Kontext oder eine isolierte Messung des Router-Vorteils. Hier wurde kein solcher Benchmark reproduziert.¹

Gewichte, Tokenizer und Laufzeitversion sollten festgelegt werden; ebenso sind das Chat-Template und die tatsächlich verwendeten Faltungs-, Experten- und Attention-Kernel zu prüfen. Prompt-Latenz, Decode-Latenz pro Request, Gesamtdurchsatz und Aufgabengenauigkeit müssen bei der vorgesehenen Kontextlänge und Parallelität gemessen werden. Das nachtrainierte Modell verwendet ausschließlich den Reasoning-Modus und kann zusätzliche Thinking-Tokens erzeugen. Die Zeit bis zu einer brauchbaren Antwort hängt daher auch von der Ausgabelänge ab. Die Model Card führt DSpark für spekulatives Decoding als angekündigt auf, nicht als bereits veröffentlichten Geschwindigkeitsgewinn.⁶

Die Grenze von 131,072 Positionen gilt für Eingabe und generierte Tokens zusammen, einschließlich der Thinking-Tokens. Eine konfigurierte Kontextgrenze allein belegt noch keinen zuverlässigen Abruf oder eine ausreichende Aufgabengenauigkeit bei dieser Länge.

Die Gewichte verwenden die LFM Open License v1.0 mit einer Umsatzschwelle für kommerzielle Nutzung; die festgelegte Lizenz ist auf ihre Anwendbarkeit für den eigenen Betrieb zu prüfen.⁷ Dieser Checkpoint erzeugt Text. Liquid d1-3B ist ein separates veröffentlichtes Entscheidungsmodell mit geteilten Fragezweigen. Ein gemeinsamer Familienname macht ihre Serving-Pfade nicht austauschbar.

Primärquellen