Liquid d1-3B: Verzweigte Entscheidungen ohne Decoding

Liquid AIs d1-3B ist ein veröffentlichtes Text-Bild-Entscheidungsmodell mit 3,12 Milliarden Parametern. Es nimmt einen Zustand und typisierte Fragen entgegen und liefert Ja/Nein-, Auswahl- oder Score-Wahrscheinlichkeiten, ohne eine Antwort Token für Token zu generieren. Das Interessante ist kein neuer Klassifikationskopf: Die Veröffentlichung verwendet einen LFM-Vokabularkopf und ändert, wie mehrere Prompts mit demselben Zustand ausgewertet werden.¹²

Die eigene Implementierung stellt den gemeinsamen Zustand als Stamm und jede Frage als separaten Zweig dar. Tokenweise Schichten verarbeiten den gepackten Baum einmal. Faltungszweige übernehmen die letzten Eingaben des Stamms; Attention-Zweige sehen den Stamm und ihre eigenen früheren Tokens, aber nie eine andere Frage. Damit bleibt das mathematische Ergebnis unabhängiger Prompts erhalten, während wiederholte Zustandsarbeit entfällt. Dieser Artikel analysiert Revision 051bcc464b01b9f92942b364d9586b0ef5912432, geprüft am 12. Oktober 2026.³⁴

Das veröffentlichte Modell, nicht das experimentelle Geschwistermodell

d1-3B basiert auf dem Decoder-only-Backbone LFM2.5-VL-3B. Die veröffentlichte Konfiguration und die Tensor-Metadaten ergeben folgende konkrete Form.⁵³

Die separate Veröffentlichung d1-omni-600M bezeichnet Liquid AI ausdrücklich als experimentell und in aktiver Entwicklung. Sie dient hier daher nicht als Produktionsreferenz. Für d1-3B gibt es herunterladbare BF16- und offizielle GGUF-Artefakte sowie eine ausführbare PyTorch-Implementierung. Dadurch ist der Mechanismus prüfbar, auch wenn nicht jede Runtime einen optimierten Tree-Kernel besitzt.¹⁶

Zum Vergleich: Cloudflare Clef führt einen Backbone-Prefill und danach einen gelernten gemeinsamen Schema-Kopf aus. d1-3B behält stattdessen die gewöhnliche gebundene Vokabularprojektion und wertet pro Frage einen Prompt-Zweig aus. Beide vermeiden eine autoregressive Antwortschleife, aber ihre Datenflüsse unterscheiden sich.

Der LFM-Block unter der Decision-API

Sei $X\in\mathbb{R}^{B\times T\times2048}$ der eingehende Residualzustand. Jede Decoderschicht führt RMSNorm, entweder eine kurze Faltung oder volle Attention, eine Residualaddition und danach RMSNorm, ein MLP und eine weitere Residualaddition aus.

In einer Full-Attention-Schicht werden die Projektionen zu folgenden Tensoren umgeformt:

Grouped-Query Attention teilt einen KV-Head unter vier Query-Heads. Die persistente K/V-Nutzlast eines gewöhnlichen Decode-Caches wäre damit $2\cdot8\cdot64\cdot2=2048$ Byte pro gecachter Position und Attention-Schicht in BF16, noch ohne Allokator-Overhead. d1s Entscheidungspfad hat keine autoregressive Decode-Phase und hält deshalb keinen wachsenden Decode-Cache. Prefill-Attention sowie temporäre Q/K/V- und Score-bezogene Puffer bleiben erhalten.⁷

Eine Faltungsschicht projiziert jedes Token in drei 2.048 breite Ströme $b,c,u$. Auf $b\odot u$ wird ein tiefenweiser kausaler Kernel der Breite drei angewendet, das Ergebnis mit $c$ gegated und zurück auf 2.048 projiziert. An einer Zweiggrenze besitzt er einen Zwei-Token-Zustand. Über mehrere Schichten liefern die MLPs und späteren Attention-Schichten dennoch reicheren Kontext; „Kernelbreite drei“ ist nicht die gesamte Kontextlänge des Modells.

Ein Stamm, viele unabhängige Zweige

Bei einem Zustandspräfix der Länge $P$ und Fragesuffixen mit den Längen $q_1,\ldots,q_N$ verarbeitet eine separate Auswertung

Tokenpositionen. Der Baum packt [Stamm | Zweig 0 | … | Zweig N−1]; tokenweise Projektionen, Normalisierungen und MLPs verarbeiten daher

Die Positionen eines Zweigs beginnen wieder bei $P$. Eine Faltung der Breite drei stellt jedem Zweig die letzten zwei Eingaben des Stamms voran und wendet danach denselben kausalen Filter an. Zweig $n$ erhält damit exakt den lokalen Verlauf der unabhängigen Folge [Stamm | Zweig n] und nicht das Ende von Zweig $n-1$.⁴

Attention wird in drei Rechnungen zerlegt: kausale Stamm-zu-Stamm-Attention, Branch-Queries über alle Stamm-Keys und kausale Attention innerhalb jedes Zweigs. Zweigübergreifende Paare sind maskiert. Für eine Full-Attention-Schicht erlauben unabhängige Prompts ohne Heads und Batch

Query-Key-Paare. Der Baum erlaubt dagegen

Die exakte Differenz ist $(N-1)P(P+1)/2$: Nur die wiederholte Self-Attention des Stamms entfällt. Branch-zu-Stamm- und Branch-interne Attention bleiben. Mit $P=3400$, drei Fragen und $q_n=50$ sinken die Tokenpositionen von 10.350 auf 3.550, also um 65,7 %. Die erlaubten Attention-Paare sinken von 17.858.925 auf 6.295.525, also um 64,7 %. Das sind hergeleitete Operationszahlen und keine gemessenen Latenzreduktionen.

Warum die geteilte Attention exakt bleibt

Softmax-Attention lässt sich normalerweise nicht durch Mitteln zweier Teilergebnisse berechnen. d1s Implementierung liefert zusätzlich den Log-Sum-Exp-Normalisierer jedes Teils zurück. Seien $(o_a,\ell_a)$ das Attention-Ergebnis einer Branch-Query über die Stamm-Keys und $(o_b,\ell_b)$ das Ergebnis über ihre eigenen kausalen Keys. Mit $m=\max(\ell_a,\ell_b)$ lautet das vollständige Ergebnis

Das ist algebraisch dieselbe Softmax wie über beide verketteten Key-Mengen: $e^{\ell_a}$ und $e^{\ell_b}$ sind deren Partitionssummen. Das Abziehen von $m$ stabilisiert die Rechnung numerisch. Die Gleichheit gilt für die definierte Attention-Maske und Rechengenauigkeit; der Quelltext weist darauf hin, dass unterschiedliche BF16-Kernelformen dennoch kleine numerische Abweichungen gegenüber separaten Läufen verursachen können.⁴

Die Optimierung hat außerdem eine Implementierungsgrenze. Auf CUDA-GPUs ab Ampere oder auf ROCm mit BF16/FP16-Tensoren ruft der eigene Code private Flash-Attention-Operatoren von PyTorch auf. CPU, nicht unterstützte GPUs und float32-Pfade verwenden explizite float32-Produkte. Für Stamm-Attention vervielfachen sie K/V für GQA und teilen Branch-Queries in Blöcke von 1.024; die Branch-interne Arbeit wird separat behandelt. Eine kompatible öffentliche API oder eine andere Serving-Engine kann andere Leistungs- und Wartungseigenschaften haben.

Typisierte Antworten aus gewöhnlichen Vokabular-Logits

Der letzte Hidden State jedes Zweigs wird durch den gebundenen Sprachmodellkopf auf 128.000 Token projiziert. d1 decodiert nicht aus dieser Verteilung. Stattdessen ordnet der Prompt-Code jede erlaubte Antwort einer oder mehreren Einzeltoken-Formen zu, nimmt das maximale Log-Probability-Ergebnis eines Kandidaten und wendet Softmax nur über die erlaubten Optionen an:⁸

noul nutzt Ja/Nein-Token-Aliase, choice erzeugte Optionscodes und score Zifferntokens. Dadurch sind Schema-Verletzungen beim API-Readout ausgeschlossen: Der Ausgaberaum wird vor der Rückgabe begrenzt. Zugleich können Beschreibungen, Optionsreihenfolge und gewählte Aliase den Prompt beeinflussen. Das Verfahren ist kein reihenfolgeinvarianter Klassifikationskopf.

Die Model Card nennt die zurückgegebenen Antworten kalibriert. Der öffentliche Runner verwendet standardmäßig jedoch calibration=None. Wenn der Aufrufer kein Objekt mit apply bereitstellt, ist die ausgegebene „Confidence“ lediglich die eingeschränkte Softmax oben. Ohne Zuverlässigkeitsmessung auf repräsentativen Hold-out-Daten sollte sie nicht als empirisch kalibrierte Wahrscheinlichkeit für eine neue Produktionsdomäne interpretiert werden.

Produktionsgrenzen

Die Veröffentlichung erfordert trust_remote_code=True. Wer nur den Modellnamen fixiert, kann Repository-Code, Tokenizer und Gewichte zu unterschiedlichen Zeitpunkten erhalten. Eine geprüfte Revision sollte als lokaler Snapshot geladen werden:

import torch
from huggingface_hub import snapshot_download
from transformers import AutoModel
 
REVISION = "051bcc464b01b9f92942b364d9586b0ef5912432"
snapshot = snapshot_download("LiquidAI/d1-3B", revision=REVISION)
model = AutoModel.from_pretrained(
    snapshot,
    trust_remote_code=True,
    dtype=torch.bfloat16,
).to("cuda").eval()
 
result = model.system_one(state, questions)

Das konfigurierte Limit von 32.768 Tokens gilt für den längsten Wurzel-Blatt-Pfad $P+\max q_n$, nicht für die Summe aller gepackten Zweige. Umgekehrt steuert das standardmäßige token_budget=65536 des Runners, wie viele reale Tokens in einem Batch gruppiert werden; es erhöht nicht das Kontextlimit pro Pfad. Bilder werden vor der Verarbeitung auf höchstens 1.048.576 Pixel verkleinert und vom Processor in das modellspezifische Patch-Layout überführt.⁹

Offizielle GGUF-Dateien und ein llama.cpp-Pfad /v1/systemone machen lokale Deployments praktisch. Quantisierung reduziert den Gewichtsspeicher, belegt aber weder unverändertes Antwort-Ranking noch unveränderte Wahrscheinlichkeitskalibrierung. Das offizielle Repository enthält eine 1,67 GB große Q4_K_M-Modelldatei und einen separaten 0,86 GB großen BF16-Multimodal-Projektor, aber an der geprüften Revision keinen unabhängigen Genauigkeitsvergleich der quantisierten Entscheidungen.⁶

Liquid AIs Latenztabelle misst jeweils eine Anfrage. Drei Fragen über einen Zustand benötigten auf Jetson AGX Thor 20 statt 16 ms, auf AGX Orin 35 statt 26 ms, auf Apple M5 Pro 41 statt 30 ms und auf RTX 4090 21 statt 8 ms. Der gemeinsame Stamm erklärt, weshalb sich die Kosten nicht verdreifachen müssen; die Verhältnisse unterscheiden sich aber deutlich. „1,3ד ist keine universelle Eigenschaft der Tree-Inferenz.¹

Schließlich verwendet das Modell die LFM Open License v1.0, nicht Apache 2.0 oder MIT. Abschnitt 5 knüpft Rechte zur kommerziellen Nutzung an eine jährliche Umsatzschwelle von 10 Millionen US-Dollar und schließt kommerzielle Nutzung oberhalb dieser Schwelle aus diesem Vertrag aus. Organisationen an oder über dieser Grenze sollten vor dem Deployment den genauen Lizenztext prüfen und eine passende Erlaubnis einholen.¹⁰

d1-3Bs nützliche Architekturidee ist präzise: Eine Menge Prompts wird in ein gemeinsames kausales Präfix und unabhängige Suffixe zerlegt; partielle Softmax-Statistiken erhalten die exakte Attention. Das spart wiederholte Stammarbeit, nicht die gesamte Fragenarbeit. Der Vorteil wächst mit dem Anteil des gemeinsamen Zustands und der Zahl der Fragen. Der reale Durchsatz bleibt durch Zweiglängen, Kernel, Speicherverkehr, Bildverarbeitung und Batching begrenzt.

Primärquellen