Liquid AI d1 vs. Liquid AI d1-3B: Was die Ollama-Bibliothek als ein Modell und der Anbieter als zwei bezeichnet

Es gibt zwei Möglichkeiten, dieselbe Menge von Gewichten zu benennen, und Liquid AI d1 und Liquid AI d1-3B veranschaulichen den Unterschied besser, als es jeder Parametervergleich könnte. Zieht man vom zweiten Namen einen Bindestrich und ein Größen-Suffix ab, erhält man den ersten; daher ist es verlockend, die kürzere Zeichenkette als Spitznamen zu behandeln. Die beiden Kataloge, die diese Modelle tatsächlich aufführen, stimmen mit dieser Lesart nicht überein. Der Dokumentationsindex von Liquid AI selbst führt d1 in einer eigenen Zeile mit den Buchstaben „API“ dort, wo die Download-Links stehen, auf, und führt d1-3B und d1-omni-600M in einem separaten Paar von Zeilen mit funktionierenden Links zu Hugging Face und GGUF sowie einem „No“ in der Spalte für Trainierbarkeit auf. Ollama, dessen Bibliothekseintrag überhaupt der Grund ist, warum dieses Paar erwähnenswert ist, fasst all das in einer einzigen Seite namens d1 zusammen, beschreibt es in einer einzigen Zeile als „ein 3B-Entscheidungsmodell von Liquid AI, gebaut auf LFM2.5-VL-3B“, und bietet darunter genau drei Tags. Ein Vergleich von Liquid AI d1 mit Liquid AI d1-3B ist daher weder ein Vergleich zwischen einem gehosteten Endpunkt und einem offenen Checkpoint noch ein Vergleich zwischen zwei Checkpoints. Es ist ein Vergleich zwischen einem gehosteten Endpunkt und dem offenen Checkpoint, von dem das lokale Runtime-Ökosystem entschieden hat, dass er d1 ist, wenn man das Wort ohne Qualifizierung sagt. Das meiste des Folgenden dreht sich darum, auf welche dieser Lesarten Ihre Bereitstellung tatsächlich angewiesen ist.

Ein Hinweis dazu, wie die unten stehenden Zahlen belegt sind, denn die Ehrlichkeit ist wichtiger als ihre Formatierung. Alle hier genannten Zahlen stammen aus der eigenen Berichterstattung von Liquid AI, auf den Modellkarten oder im Release-Post vom 7. Oktober. Die Decision-Index-Zeilen wurden vom Anbieter mit dem offiziellen Scorer bewertet und nicht für ein öffentliches Ranking eingereicht, und soweit wir feststellen konnten, hat keine dritte Partei irgendein d1-Ergebnis unabhängig reproduziert. Wenn eine Zahl aus einer veröffentlichten Angabe errechnet statt gemessen ist, wird das angegeben.

Woher die beiden Namen kommen

Der kürzere Name ist älter. Der Beitrag von Liquid AI vom 5. Oktober stellte das Modell als Liquid AI d1 vor – „unser erstes Entscheidungsmodell“, in dieser Veröffentlichung multimodal, das getippte Fragen über einen Zustand aus Text, Bildern oder beidem in einem einzigen Vorwärtsdurchlauf mit null Ausgabe-Tokens beantwortet. In diesem Beitrag wird ein Hosting-Preis von 0,04 $ pro Million Eingabe-Tokens genannt, es werden nur Eingabe-Tokens berechnet, und es wird angemerkt, dass Bilder wie Text mit 1,5 Tokens pro 32×32-Patch berechnet werden, sodass ein 1024×1024-Bild 1.536 Tokens kostet. Außerdem wird die Textentscheidungslatenz mit 200–300 ms angegeben. Das sind Zahlen für den gehosteten Dienst, und der Beitrag stellt ausdrücklich klar, dass die Runtime dahinter der eigene Entscheidungsendpunkt des Anbieters unter api.liquid.ai/decisions/v1/systemone ist.

Der längere Name erscheint im Beitrag vom 7. Oktober und auf Hugging Face, und er ist derjenige, der die reproduzierbaren Details trägt: 3,12B Parameter, einen 32.768-Token-Kontext, ein 128.000-Token-Vokabular, sechzehn dokumentierte Sprachen, einen formoptimierten SigLIP2-NaFlex-400M-Vision-Encoder und die Basiskette LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Diese Karte stellt außerdem unmissverständlich klar, dass das Modell kein Chat-Modell ist und keinen Text schreibt. Dies ist der Checkpoint, auf dem das gesamte lokale Ökosystem aufbaut: Das GGUF-Repository enthält Q4_K_M mit 1,67 GB, Q8_0 mit 2,87 GB sowie F16 und BF16 mit jeweils 5,4 GB.

Was kein Herstellerdokument laut ausspricht, ist, dass Liquid AI d1 und Liquid AI d1-3B dieselben Gewichte sind. Der Dokumentationsindex weist ihnen getrennte Zeilen zu. Der Release-Beitrag bezeichnet d1 als Familie, nicht als Checkpoint. Drittanbieter-Berichte haben die Lücke bemerkt und darauf hingewiesen, dass der Anbieter die Gleichsetzung nicht bestätigt hat. Die ehrliche Aussage ist also kurz: Die Zahlen, mit denen die beiden Namen veröffentlicht werden, stehen nirgends, soweit wir feststellen können, in Konflikt, das Familien-Release und der bereitgestellte Endpunkt wurden im Abstand von zwei Tagen mit einer kompatiblen Beschreibung angekündigt, und der Anbieter hat nicht gesagt, dass sie dasselbe Modell sind. Betrachten Sie die Äquivalenz als vernünftige Arbeitsannahme und nicht als eine Tatsache, zu der sich der Anbieter mit Namen bekennt.

Was der lokale Build tatsächlich ändert

Ollamas Eintrag ist keine Neuveröffentlichung und kein neuer Checkpoint. Es ist eine Paketierungsentscheidung, und die Paketierung auferlegt drei Einschränkungen, die die Dokumentation des Anbieters selbst überhaupt nicht erwähnt. Die erste ist die Tag-Liste: d1:latest, d1:3b und d1:3b-q8_0, drei Tags, die eine Quantisierung benennen. Das GGUF-Repository, das Liquid veröffentlicht, führt vier Präzisionen, und das 1,67 GB große Q4_K_M – dasjenige, auf das die meisten auf einem Laptop zurückgreifen würden – ist nicht unter den Ollama-Tags. Was man pullen kann, ist das 2,87 GB große Q8_0 und das, was es im lokalen Speicher belegt; die Bibliotheksseite gibt den Download mit 3,7 GB an.

Das Zweite ist der Anfragevertrag. Ollama bedient diese Modelle unter /v1/systemone, nimmt einen State plus ein questions-Objekt entgegen und gibt typisierte Antworten mit output_tokens: 0 zurück. Das ist dieselbe Form, die der gehostete Endpunkt des Anbieters verwendet, was den Wechsel zwischen lokal und gehostet zu einer Konfigurationsänderung statt zu einer Neuimplementierung macht. Die dritte Einschränkung steht in Ollamas Endpunktdokumentation und nicht auf der Modellseite, und sie ist strenger als die eines generativen Modells: Anfragen müssen ohne Bilder in 64 KiB und mit Bildern in 32 MiB passen, Streaming wird nicht unterstützt, cloud-gehostete Modelle werden abgelehnt, und Bilder müssen als base64-kodiertes PNG, JPEG oder WebP im Request-Body vorliegen – Remote-URLs werden abgelehnt. Bilder gelten für jede Frage in einer Anfrage gemeinsam, deshalb braucht ein Bild, das nur eine Antwort berücksichtigen soll, einen eigenen Aufruf. Eingaben werden niemals abgeschnitten, was bedeutet, dass ein zu großer State einen Fehler zurückgibt, statt stillschweigend beschnitten zu werden. Das ist der bessere Fehlermodus, und es bleibt ein Fehlermodus, den Ihr Client behandeln muss.

Zwei Dokumentationsdetails bleiben ungeklärt und es lohnt sich, sie zu kennen, bevor Sie einen Bug melden. Ollamas Endpunktreferenz gibt an, dass der Auswahlfrage-Typ 2 bis 255 Optionsschlüssel akzeptiert, während ihre Fähigkeitsseite für Entscheidungsmodelle 2 bis 26 angibt; eine der beiden ist veraltet. Und die Fähigkeitsseite führt ihre unterstützten Modelle als Nimble, Tev1, Clef und Clef Flash auf, ohne d1 zu erwähnen – obwohl das Readme des d1-Pakets selbst /v1/systemone und --ask-Unterstützung dokumentiert und das Paket Ollama 0.40.4 erfordert, während die eigene dokumentierte Mindestversion des Endpunkts 0.35.0 ist. Lesen Sie die Versionsanforderung im Paket, nicht die im Leitfaden.

Die Zahlen und unter welchem Namen sie veröffentlicht wurden

Dies ist der Teil der Paarung, bei dem man am ehesten etwas falsch macht, weil beide Namen zusammen mit Leistungszahlen veröffentlicht werden und die Zahlen nicht so aufgebaut sind, wie man es erwarten würde.

• Decision Index 0.2.1 — 48,57, veröffentlicht unter Liquid AI d1-3B. Liquid beschreibt ihn als den besten Wert für ein Entscheidungsmodell unter 10B Parametern und platziert ihn vor einem 35B-A3B-Modell mit 47,11. • Text-Entscheidungslatenz — 200–300 ms, veröffentlicht unter Liquid AI d1 im Beitrag zur gehosteten API. Für den eigenen Namen des offenen Checkpoints gibt es keine entsprechende Angabe. • Latenz bei einer einzelnen Frage auf lokaler Hardware — 8 ms auf einer RTX 4090, 16 ms auf einem Jetson AGX Thor, 26 ms auf einem Jetson AGX Orin 64 GB, 50 ms auf einer Orin Nano, 30 ms auf einem Apple M5 Pro. Veröffentlicht unter Liquid AI d1-3B. • Durchsatz — 475 Entscheidungen pro Sekunde auf der RTX 4090 und 1.106 pro Sekunde auf einer AMD MI325X, wenn Fragen zu Batches gebündelt werden. Veröffentlicht unter Liquid AI d1-3B. • Vision — ein Mittelwert von 74,1 über elf öffentliche Bild-Benchmarks, gegenüber 73,9 für die LFM2.5-VL-3B-Basis, auf der es aufbaut. Veröffentlicht unter Liquid AI d1-3B. • Bild-Ablation — derselbe Fragensatz, ohne Bilder beantwortet, erzielt 45,1; das ist die eigene Messung des Anbieters dafür, was der Vision-Pfad beiträgt. Veröffentlicht unter Liquid AI d1-3B.

Aus dieser Liste ergeben sich zwei Probleme, und keines von beiden ist fatal – genau deshalb werden sie übersehen. Der gehostete Wert und der lokale Wert liegen um den Faktor 25 bis 37 auseinander – 200–300 ms gegenüber 8 ms – und sie wurden an Dingen gemessen, die der Anbieter nicht in vergleichbaren Begriffen beschreibt. Die Lücke als „lokal ist schneller“ zu lesen, ist nicht haltbar, denn der gehostete Wert ist Ende-zu-Ende über eine API, und die 8 ms sind ein Forward Pass auf einer namentlich genannten GPU. Es sind nicht dieselben Messungen, und der Anbieter behauptet das auch nie.

Das zweite Problem ist die Vision-Zeile. Eine Verbesserung um 0,2 Punkte gegenüber dem Basismodell über elf Bild-Benchmarks hinweg liegt innerhalb des Rauschens der meisten Benchmark-Berichterstattung, also ist der Decision Head, egal was er bringt, kein wesentlich besserer Bild-Encoder. Die Ablationszeile wirkt in die andere Richtung weit beeindruckender – ein Ausschlag von rund 29 Punkten, wenn Bilder hinzugefügt werden –, aber sie vergleicht zwei verschiedene Fragensets statt zwei Versionen eines Sets, was Liquid im Beitrag selbst angibt. Beide Zeilen sind nützlich. Keine von beiden stützt eine starke Aussage über die visuelle Entscheidungsqualität, und kein Dritter hat eine von beiden durchgeführt.

Wo die beiden Namen in der Praxis auseinandergehen

Für einen Käufer läuft die Unterscheidung auf vier Fragen hinaus, und die Antworten weisen nicht alle in dieselbe Richtung.

• Kostenstruktur — Liquid AI d1 wird pro Eingabe-Token zum veröffentlichten Tarif des Anbieters abgerechnet, wobei keine Ausgabe-Tokens zu bezahlen sind. Liquid AI d1-3B ist ein 2,87 GB großer Download im Paket von Ollama oder ein 1,67 GB großer aus dem GGUF-Repo des Anbieters, ganz ohne Abrechnung pro Aufruf. • Latenz, messbar — die gehostete Route nennt 200–300 ms pro Textentscheidung. Die veröffentlichten 8 ms der lokalen Route sind ein Forward-Pass auf einer RTX 4090 mit warmem Modell, eine echte Zahl und kein Roundtrip einer Anfrage. • Datenpfad — die gehostete Route sendet den Zustand an den Anbieter. Die lokale Route behält ihn auf dem Rechner, was bei einem Support-Ticket, einer medizinischen Notiz oder einem Foto normalerweise das Argument ist, das die Diskussion beendet. • Versions-Pinning — Liquid AI d1 hinter einem Endpoint ist das, was der Anbieter heute ausliefert. Liquid AI d1-3B in Ollama ist ein festes Paket, das Sie kontrollieren, und der Kompromiss besteht darin, dass Sie sich selbst um die Upgrades kümmern.

Die unbequeme Realität unter allen vieren ist, dass der offene Checkpoint eher ein Geschwister des gehosteten Modells als ein Ersatz dafür ist, und der Anbieter hat nichts Gegenteiliges gesagt. Die Modellkarte für den offenen Checkpoint empfiehlt ihn für Routing und Triage, Moderation, Intent-Klassifizierung, Extraktionsprüfungen, Reranking, LLM-as-a-Judge und Guardrails und beschreibt ihn als nachtrainiert auf LFM2.5-VL-3B für kalibrierte Entscheidungen in einem einzigen Durchlauf. Der Beitrag zum gehosteten Modell beschreibt dieselbe Aufgabenmenge mit anderen Worten und nennt den Preis für das gehostete Angebot. Wenn das ein und dasselbe Modell ist, ist der lokale Build eine kostenlose Kopie eines gehosteten Produkts, was für ein Labor ungewöhnlich wäre, so etwas auszuliefern, ohne es zu sagen. Wenn es zwei Fine-Tunes einer gemeinsamen Basis sind, sollte nicht davon ausgegangen werden, dass die veröffentlichten Zahlen in irgendeine Richtung übertragbar sind. Die zweite Erklärung verlangt dem Anbieter weniger ab und passt zu den Belegen, die wir haben.

Beide Hälften der Entscheidung ausführen, ohne zwei Stacks zu betreiben

Welchen Namen Sie auch wählen, die Pipeline darum herum sieht meist gleich aus. Eine Support-Warteschlange bekommt eine Auswahlfrage zu einem Zielteam, eine noul-Frage dazu, ob eine Rückerstattung angefordert wird, und eine Score-Frage zur Dringlichkeit – ein Zustand, drei Antworten, ein Durchlauf. Wo die beiden Namen wirklich auseinandergehen, ist an dem Punkt, an dem die Entscheidung einen Aufruf an ein generatives Modell steuert, das Sie mieten statt selbst zu betreiben. Dieser Aufruf ist ein anderes Problem mit einem anderen Fehlerprofil, und er ist der Teil der Pipeline, wo es am wenigsten darauf ankommt, dass d1 richtig ist: Eine Routing-Antwort mit 0,98-Wahrscheinlichkeit, gefolgt von einem 502 von dem Modell, an das Sie geroutet haben, ist so oder so eine fehlgeschlagene Anfrage.

Wir hosten kein Liquid-AI-Modell – wir haben unseren eigenen Katalog geprüft, bevor wir das geschrieben haben –, also ist nichts hier eine Aussage darüber, diese Gewichte über uns aufzurufen. Was wir tun, ist die Ebene auf der anderen Seite der Entscheidung: ein OpenAI-kompatibler Schlüssel für die Modelle, auf die eine triagierte Anfrage aufgefächert wird, zum Listenpreis des jeweiligen Anbieters, mit 0 % Aufschlag durchgereicht, sodass eine Preissenkung eines Anbieters Sie an dem Tag erreicht, an dem sie in Kraft tritt, statt erst bei der Vertragsverlängerung, mit automatischem Failover über Anbieter hinweg sodass eine triagierte Anfrage es übersteht, wenn das Modell, an das Sie sie geroutet haben, ausfällt. Wenn Sie ein Entscheidungsmodell zum ersten Mal in eine Pipeline einbinden, ist das die Hälfte, die man getrost langweilig machen sollte.

Welchen Namen je nach Situation verwenden

Wenn du das Modell diese Woche ausprobieren möchtest, ohne eine Python-Umgebung, die es wert ist, gepflegt zu werden, verwende den Namen, den die lokale Runtime verwendet. Zieh Liquid AI d1 aus der Bibliothek, akzeptiere Q8_0 und 3,7 GB und betrachte die 64-KiB-Anfrageobergrenze und die No-Streaming-Regel als Designvorgaben statt als Ärgernisse. Du bekommst einen echten Endpoint, echte typisierte Antworten und vom ersten Tag an keinen Zähler pro Aufruf.

Wenn Sie einen kleineren Footprint als Q8_0 benötigen, lautet der Name, den Sie verwenden sollten: Liquid AI d1-3B, denn der 1,67 GB große Q4_K_M-Build liegt im GGUF-Repository des Herstellers und nicht im Bibliothekseintrag. Diese einzelne Tatsache ist heute der praktischste Unterschied zwischen den beiden Namen, und sie ist diejenige, die am ehesten von jedem übersehen wird, der die Bibliotheksseite liest und dort stehen bleibt.

Wenn Sie das zahlenden Nutzern vorlegen und zuerst Genauigkeitsbelege benötigen, hilft Ihnen bisher keiner der beiden Namen weiter. Es gibt keine unabhängige Bewertung irgendeines d1-Modells, die wir finden konnten, die Decision-Index-Zeilen wurden selbst bewertet, und der Anbieter hat überhaupt keinen Audio-Entscheidungs-Benchmark veröffentlicht. Was Sie tun können, ist, den Konfidenzwert zu instrumentieren, den das Modell bereits zurückgibt – 0 bis 1, der widerspiegelt, wie stark die Wahrscheinlichkeiten eine Antwort begünstigen, statt wie wahrscheinlich es ist, dass diese Antwort richtig ist – und in Ihrem eigenen Traffic herauszufinden, wo die Sache unsicher ist. Diese Messung ist mehr wert als jede der oben genannten Folien, und sie dauert einen Tag.

Das Entscheidungsmodell ist die günstige Hälfte der Pipeline. Das generative Modell, an das es weiterleitet, ist die Hälfte, die einen Vertrag braucht – ein einziger OpenAI-kompatibler Schlüsselumfasst die Modelle, auf die eine triagierte Anfrage verteilt wird – jeweils zum Listenpreis des jeweiligen Anbieters, durchgereicht mit 0 % Aufschlag.

Das Herunterskalieren eines destillierten Checkpoints gegenüber seinem eigenen vollständigen Release ist ebenfalls ein guter Moment, um die Aufzeichnungen zu prüfen: Die dokumentierten KI-Vorfälle und Agentenausfälle rund um kleine Liquid-Modelle sind im OrcaRouter AI Incident Archive gesammelt, wo jeder Eintrag eigene Quellen, Schweregrad, Konfidenzstufe und Kennzeichnung als umstritten enthält.