d1-2B: Liquid AI veröffentlichte ein Entscheidungsmodell mit 1,9 Mrd. Parametern, ohne es mit einem Beitrag anzukündigen

Das Repository von Hugging Face für LiquidAI/d1-2B wurde am 24. Oktober 2026 um 19:30 UTC erstellt. Sein Schwestermodell d1-Omni-2B erschien vierundzwanzig Sekunden später. Bis zum Ende jenes Abends waren beide Repos vollständig – 3,84 GB BF16-Safetensors, gut vierzig Dateien mit benutzerdefiniertem Transformers-Code, eine Kalibrierungstabelle, eine API für typisierte Fragen – und nichts, was Liquid AI veröffentlichte, besagte, dass eines der beiden Modelle existierte. Der erste Satz des Anbieters, in dem d1-2B genannt wird, kam am 27. Oktober – im Rahmen des Launches der LFM3-Familie, im selben Beitrag, der auf liquid.ai und im eigenen Blog von Hugging Face veröffentlicht wurde – als ein Nebensatz in einem Absatz über zwei Entscheidungsmodelle. Seitdem ist kein eigener Beitrag dazu erschienen. Das ist also keine Launch-Story, und sie als eine zu behandeln, würde einen Marketingmoment erfinden, den es nie gab. Es ist eine Geschichte über ein vollständiges Modellartefakt mit einer unvollständigen Ankündigung und über die zwei Dinge, die ein Leser damit noch tun kann: das Repo lesen und die Zahlen des Anbieters auf Abstand halten, bis jemand außerhalb des Labors sie selbst überprüft.

Die fünf Tage zwischen den Gewichten und dem Satz

Die d1-Familie wurde zweimal veröffentlicht, und keine der beiden Veröffentlichungen sah aus wie diese. Am 7. Oktober veröffentlichte Liquid AI „Open d1: Edge-Entscheidungsmodelle für Text, Vision und Audio“, worin d1-3B mit 3,12B Parametern und d1-omni-600M mit 587M vorgestellt wurden – mit einer prominenten Behauptung, einer Benchmark-Tabelle, Latenzzahlen und einem Blogbeitrag, der seitdem online geblieben ist. Dieser Beitrag enthält kein 2B-Modell.

Die 2B-Reihe folgte einem anderen Zeitplan. Der Basis-Checkpoint LFM3-Omni-2B erschien am 21. Oktober. Am 24. Oktober erstellte Liquid AI um 19:30 und 19:30:24 UTC die Repositories d1-2B und d1-Omni-2B. Dann bezeichnete der LFM3-Launch-Post am 27. Oktober das Paar als „Entscheidungsmodelle, spezialisiert aus den Vision- und Omni-Modellen“ – eine Beschreibung, keine Ankündigung. Am selben Tag kamen vier abgeleitete Repositories für d1-2B hinzu: MLX-Builds in fp16, 8-Bit und 4-Bit sowie ein ONNX-Export. Auch darüber schrieb niemand einen Beitrag.

Aus einem praktischen Grund ist das wichtig. Eine Ankündigung ist der Ort, an dem ein Anbieter seine Positionierung festlegt: wofür das Modell gedacht ist, was es kostet, welche Laufzeitumgebung es anvisiert, was es nicht tut. Die Karte leistet einen Teil dieser Arbeit und leistet ihn ungewöhnlich gut. Doch die Lücken, die der fehlende Beitrag hinterlässt, sind real und konkret, und sie werden am Ende dieses Textes aufgeführt, statt übertüncht zu werden.

Was das Repository Ihnen tatsächlich sagen wird

Zieht man das Framing ab, ist der Checkpoint ein kleiner, dicht spezifizierter multimodaler Klassifikator, der sich weigert, Text zu generieren. Jeder Aufruf liefert typisierte Antworten mit angehängten Wahrscheinlichkeiten und output_tokens: 0. Die Karte sagt es unverblümt: d1-2B „ist kein Chat-Modell“.

• Parameter — 1,92 Mrd., bereitgestellt als einzelne 3,84 GB große BF16-Safetensors-Datei.

• Base — LFM3-VL-2B, auf dem LFM3-Backbone: 24 Schichten, davon 13 gated Short Convolutions, 5 Sliding-Window-Attention und 6 globale Attention.

• Kontext — 128K Token und ein Vokabular von 128.000 Token, viermal so groß wie das Fenster von d1-3B mit 32.768.

• Eingabe – ein Zustand, der Text oder ein beliebiger JSON-Wert, Bilder oder ein Video sowie beliebig viele benannte Fragen sein kann, alles in einer Medienliste. Video ist die Funktion, die d1-3B nicht auflistet.

• Ausgabe — ja/nein, eine Auswahl unter benannten Optionen, ein geordneter Score, ein Wert oder Datum, das mit seiner Spanne aus einem Dokument gelesen wird, eine Zahl mit einem p10–p90-Intervall, eine Bounding Box oder jedes Vorkommen eines Objekts mit einer Anzahl. Jede trägt eine Wahrscheinlichkeit.

• Sprachen — sechzehn: Englisch, Arabisch, Chinesisch, Französisch, Deutsch, Italienisch, Japanisch, Koreanisch, Portugiesisch, Spanisch, Vietnamesisch, Thailändisch, Indonesisch, Hindi, Russisch, Polnisch.

• Lizenz — LFM Open License v1.0. Die kommerzielle Nutzung wird bei einem Jahresumsatz unter $10,000,000 gewährt; der Lizenztext definiert diesen Betrag als Schwellenwert, und Rechte für die kommerzielle Nutzung oberhalb dieses Betrags setzen voraus, dass er nicht überschritten wird.

• Geschwindigkeit — 5,7 ms für eine einzelne Entscheidung auf einer H100 PCIe und 3,8 ms auf einer AMD MI325X, mit 1.132 bzw. 1.699 Entscheidungen pro Sekunde, wenn 64 Zustände in einem Aufruf gebündelt werden. Auf einem Apple M5 Pro beträgt der Wert für eine einzelne Frage 18,6 ms.

Die Behauptung, über die es sich zu streiten lohnt: Sie schlägt das Modell, das sie ersetzt hat.

Die Modellkarte von Liquid AI macht eine vergleichende Aussage ohne Einschränkung: d1-2B „führt die offenen d1-Modelle im Durchschnitt und in unserem Board aus über hundert Entscheidungs-Benchmarks an, vor d1-3B bei weniger als zwei Dritteln seiner Größe.“ Das ist eine starke Aussage eines 1,92-B-Modells über ein 3,12-B-Modell, und sie ist überprüfbar, weil die Karte alle vier offenen d1-Modelle in einer einzigen Tabelle aufführt, in der sie anhand derselben Aufgaben mit demselben Scorer bewertet werden.

Die Spitzenzahl beträgt 51,1 gegenüber 49,0 in der Decision Index public suite, Version 0.3 — ein Vorsprung von 2,1 Punkten. Bevor das jemand als sauberen Sieg liest, gehören zwei Einschränkungen daneben. Erstens meldet d1-3Bs eigene Model Card 48,57 auf Decision Index 0.2.1, und der Unterschied zwischen 48,57 und 49,0 ist die Indexversion, keine Verbesserung des Modells; die Model Card von d1-2B gibt an, dass alle vier Modelle anhand derselben Items neu bewertet wurden und dass einige Zahlen von d1-3B daher von ihrer eigenen Model Card abweichen. Zweitens ist die public suite nur ein Bruchteil dessen, was die öffentliche Rangliste bestimmt: Der unabhängige Gutachter, der sie neu aufgebaut hat, beschreibt 37 öffentliche Benchmarks, die mit 20 % der Punktzahl gewichtet werden, während der Rest aus privaten Tests stammt, die nur die Betreuer ausführen.

Was die 49,0 als Zahl glaubwürdig macht – obwohl d1-2B selbst keine externe Überprüfung hat –, ist, dass jemand das 3B bereits auf genau dieser Version reproduziert hat. Efraín Garay hat Mitte Oktober d1-3B anhand einer stratifizierten Stichprobe von 6.000 Anfragen aus Decision Index 0.3 ausgeführt und 49,11 erhalten, gegenüber Liquids eigenen 49,04 auf denselben Zeilen und 48,99 auf der vollständigen Suite. Das ist eine Reproduktion innerhalb eines Zehntelpunkts. Sie validiert nicht die 51,1 von d1-2B, die kein Dritter ausgeführt hat, aber sie validiert die Bewertungsmethode hinter der Tabelle, in der 51,1 steht.

Wo das kleinere Modell nicht vorne liegt

„Bei den meisten Einzel-Benchmarks vorn zu liegen“ leistet in diesem Satz im Stillen ganze Arbeit. In der Same-Run-Tabelle gewinnt d1-3B noch immer drei der gut zwanzig Zeilen, die für eine Deployment-Entscheidung relevant sind:

• Fast Decisions — 59,3 für das 3B gegenüber 58,8, der einzige geschwindigkeitsorientierte Entscheidungs-Benchmark, bei dem das größere Modell knapp vorne liegt.

• Typisierte Entscheidungen — 65,0 gegenüber 61,3, eine Differenz von 3,7 Punkten und das klarste einzelne Argument für das ältere Modell, wenn die Ausgabe ein typisierter Wert statt einer Bezeichnung sein muss.

• AI2D — 79,9 gegenüber 76,7, dem Diagramm-Lese-Benchmark, bei dem ein größerer Vision-Tower noch immer Genauigkeit bringt.

Überall sonst kehrt sich die Reihenfolge um, teils deutlich. VisualWebBench liegt bei 96,2 für d1-2B gegenüber 71,4 für d1-3B. ImajevBench v2.0-lite bei 75,5 gegenüber 64,0. MMMU-Pro bei 26,4 gegenüber 18,5 — beide niedrig genug, dass man keinem der Modelle schwieriges multimodales Reasoning zutrauen sollte, was man klar sagen sollte, statt die 7,9-Punkte-Lücke als Sieg darzustellen. Die Vision-Durchschnitte liegen bei 70,2 und 65,4.

Drei Leerstellen, die die Karte nicht füllen kann

Die fehlende Ankündigung zeigt sich als fehlende Artefakte. Nichts davon ist ein Defekt des Modells; jedes ist ein Grund, warum das Modell sich heute schwerer einführen lässt, als es seine Benchmark-Kurve nahelegt.

• Kein GGUF.d1-3B und d1-omni-600M erhielten beide am 6. Oktober GGUF-Repositories – einen Tag, nachdem ihre Gewichte hochgeladen worden waren – und d1-3B folgte mit einem 8-Bit-Weight-Activation-Build sowie vier MLX-Varianten. d1-2B hat seit dem 27. Oktober MLX- und ONNX-Builds, aber kein GGUF – es gibt also keinen veröffentlichten llama.cpp-Pfad für den Decision Head, obwohl das Basismodell LFM3-VL-2B am 19. Oktober sein eigenes GGUF bekam. Wenn Ihr Edge-Stack llama.cpp ist, ist das die ganze Geschichte.

• Kein Preis und kein Endpunkt. Die Karte führt keine gehostete API, keinen Preis pro Token und keinen Inferenzanbieter auf. Das ist bei einer Open-Weights-Veröffentlichung nicht ungewöhnlich, aber es bedeutet, dass die einzige Möglichkeit, d1-2B zu nutzen, darin besteht, es selbst auszuführen, und der Deployment-Abschnitt der Karte endet bei einem Transformers-Snippet.

• Kein unabhängiger Benchmark. Stand 28. Oktober zeigt das Repo 44 Downloads und 13 Likes. Die vorhandene unabhängige Bewertung des Entscheidungsmodells umfasst d1-3B und d1-omni-600M, nicht dieses Modell. Jede oben genannte Leistungsangabe stammt von Liquid AI selbst.

Außerdem nennt die Karte selbst eine Grenze: Antworten werden „hinter etwa 64K Tokens Zustand weniger zuverlässig“, also hinter der Hälfte des beworbenen 128K-Fensters, und Schätzungen sind bei Zählungen und Punktzahlen zuverlässig, bei freien Größen jedoch weniger. Ein Modell, dessen eigene Karte Ihnen sagt, wo seine Leistung nachlässt, ist nützlicher als eines, das dies nicht tut, aber die 128K-Schlagzeile sollte als Kapazitätsangabe gelesen werden, nicht als Arbeitsbereich.

Wie ein erstes Deployment tatsächlich aussieht

Der praktische Weg ist Transformers 5.19 oder neuer mit trust_remote_code=True, bf16 auf der GPU und dem Aufruf system_one oder system_one_batch. Es gibt keine Sampling-Parameter, weil es kein Sampling gibt. Der einzige Tuning-Regler, der zählt, ist set_size, der standardmäßig auf die trainierte Größe von 16 gesetzt ist; eine Erhöhung bringt Geschwindigkeit und kostet Textgenauigkeit.

Die Empfehlung auf der Karte selbst ist der Schritt, den die meisten Teams überspringen: Kalibrieren Sie Ihre Entscheidungsschwelle anhand von Daten aus Ihrem eigenen Anwendungsfall. Eine Wahrscheinlichkeit von 0,62 sagt für sich genommen nichts aus. Wenn Sie Support-Tickets weiterleiten oder Dokumente markieren, muss die Schwelle, die zwischen „eskalieren“ und „automatisch bearbeiten“ unterscheidet, auf Ihre eigene gelabelte Stichprobe angepasst werden, denn die Kalibrierung des Anbieters wurde auf dessen eigener Stichprobe angepasst.

Die Form, in die das passt, ist ein Pipeline-Schritt, kein Assistent: Triage, Moderation, Intent-Klassifizierung, Extraktion aus Formularen, Reranking, visuelle Inspektion. Das sind genau die Stellen, an denen eine Pipeline bereits mehrere Modelle aufruft und an denen die generativen Schritte rund um die Entscheidung normalerweise von einer gehosteten API kommen. OrcaRouter bietet heute kein Modell von Liquid AI an – dieses eingeschlossen –, wer d1-2B ausführen will, muss es also selbst betreiben. Der Nutzen eines Routers zeigt sich im Rest der Kette: ein OpenAI-kompatibler Schlüssel für über 200 gehostete Modelle, eine Routing-DSL, die Schritte zu einem einzigen Aufruf zusammensetzt, und automatisches Failover, wenn ein Anbieter ausfällt, damit der Entscheidungsknoten auf Ihrer GPU nicht dem generativen Knoten daneben ausgeliefert ist.

Was würde diese Geschichte verändern?

Vier Dinge, in absteigender Reihenfolge ihrer Bedeutung. Ein GGUF würde d1-2B auf dieselbe Laufzeitbasis wie seine Geschwistermodelle stellen und den Edge-Pitch Realität werden lassen. Ein eigener Beitrag würde Käufern sagen, wofür Liquid AI das Modell vorgesehen hat – über die Liste der Pipeline-Schritte im Model Card hinaus. Ein unabhängiger Lauf – idealerweise dieselbe Stichprobe mit 6.000 Zeilen, mit der d1-3B reproduziert wurde – würde aus 51.1 eine Messung statt einer Herstellerangabe machen. Und ein Hosting-Preis würde die Build-versus-Buy-Frage überhaupt erst beantwortbar machen.

Bis dahin ist die ehrliche Zusammenfassung knapp und nützlich: Es gibt ein 1,92-B-Entscheidungsmodell, sein Repository ist vollständig genug, um es zu bewerten, sein Benchmark-Vorsprung gegenüber dem 3B-Modell ist auf der eigenen Same-Run-Tabelle des Anbieters real und überall sonst unbestätigt, und die fehlende Ankündigung hat dazu geführt, dass ihm das Drumherum fehlt – Laufzeitumgebung, Endpoint, Preis –, das die meisten Teams brauchen, bevor sie ein Modell in eine Pipeline aufnehmen. Wenn Sie bereits Transformers einsetzen und einen Klassifikator mit 128K-Fenster und Videoeingabe wollen, ist es einen Nachmittag wert. Wenn Sie llama.cpp oder einen verwalteten Endpoint benötigen, warten Sie.