d1-omni vs. Liquid AI D1 Omni 600M: Zwei Namen, ein Checkpoint und eine Kontextzahl, für die niemand eine Quelle nennen kann

Liquid AI D1 Omni 600M und d1-omni sind keine zwei Modelle, und sie sind auch keine zwei Checkpoints desselben Modells. Sie sind ein Satz Gewichte – das multimodale Entscheidungsmodell von Liquid AI mit 587 Mio. Parametern, aufgebaut auf Liquid AI LFM2.5-Encoder-350M und am 5. Oktober 2026 auf Hugging Face unter dem Repo-Namen LiquidAI/d1-omni-600M veröffentlicht –, das in zwei verschiedenen Katalogen zwei verschiedene Dateinamen trägt. Einer dieser Kataloge, der des Anbieters, sagt Ihnen, was das Modell ist. Der andere, der von Ollama, sagt Ihnen, in welches Paket jemand es verpackt hat, und nennt drei Zahlen auf der Karte, die die Dokumentation des Anbieters nicht stützt. Diese Diskrepanz ist der eigentliche Grund, warum sich dieser Vergleich lohnt, denn bei einem so kleinen Modell ist die Verpackung keine Fußnote – sie ist der Unterschied zwischen einem Text-und-Bild-Modell und dem Modell, von dem die Karte behauptet, dass Sie es heruntergeladen haben.

Der Anbieter hat nichts zum Ollama-Eintrag angekündigt, und es gibt weder einen Maintainer-Hinweis noch einen Changelog-Eintrag oder ein Readme auf der Ollama-Seite, das irgendetwas davon erklären würde. Die ehrliche Einordnung für alles Folgende ist daher diese: Die Gewichte sind öffentlich und überprüfbar, die Paketierung ist öffentlich und überprüfbar, und die hier gebotene Lesart der Paketierung ist unsere, nicht die von Liquid AI. Wo sich eine Zahl nicht auf eine Quelle zurückführen lässt, sagt dieser Beitrag das, statt sie zu wiederholen.

Wie die beiden Namen tatsächlich lauten

Liquid AI veröffentlichte das Modell auf Hugging Face mit einem Erstellungszeitstempel vom 5. Oktober 2026 – zwei Tage, bevor es am 7. Oktober im eigenen Blogbeitrag des Anbieters "Open d1: Edge decision models for text, vision, and audio" erschien. Die Gewichte sind unter den eigenen LFM-1.0-Bedingungen von Liquid lizenziert und tragen die Tags d1_omni, system-one, multimodal, vision, audio und decision-model, und sie haben zum Zeitpunkt des Schreibens rund 13.900 Downloads und 135 Likes erzielt. Quantisierte Varianten folgten nach eigenem Zeitplan: ein GGUF-Repository am 6. Oktober, MLX-Builds für Apple Silicon am 12. Oktober.

Der Ollama-Eintrag ist keines dieser Repositories. Es ist eine Ollama-Bibliotheksseite namens d1-omni, die das Badge „vision 600m“ trägt, vier Tags anzeigt und Minuten vor dem Verfassen dieses Textes aktualisiert worden war – weshalb das Radar überhaupt darauf aufmerksam wurde. Nichts darin nennt Liquid AI, LFM2.5-Encoder-350M oder das Hugging-Face-Repository, aus dem die Bytes stammen.

Der praktische Unterschied liegt also in einem Dateinamen und einem Verteilungspfad, nicht in einem Modell. Was sich unterscheidet – und worauf es ankommt –, sind die Metadaten, die die Bytes umhüllen.

Die drei Zahlen auf der Ollama-Karte, eine nach der anderen geprüft

Ollamas Seite zeigt für jedes Tag eine Größe, ein Kontextfenster und eine Eingabeliste an. Alle drei verdienen einen zweiten Blick, denn bei diesem Modell überstehen zwei davon den Kontakt mit der Quelle nicht.

• Kontextfenster — 125K auf der Modellkarte, 16.384 in jeder Herstellerquelle. Die Modellkarte von Liquid AI nennt eine Obergrenze von 16.384 Token, die Text-, Bild- und Audiopositionen zusammen abdeckt, und die eigene Dokumentationsseite des Herstellers für d1-omni-600M sagt „16K tokens“. Die Zeichenfolge 125K taucht in keiner der beiden auf. Sie könnte ein Artefakt der Positionskonfiguration der zugrunde liegenden LFM2.5-Encoder-Architektur sein oder davon herrühren, wie Ollama ein Cache-Limit meldet, aber sie ist keine von Liquid AI veröffentlichte Zahl und keine, die dieser Artikel irgendjemandem zuschreiben kann. Was die Diskrepanz zu mehr als Haarspalterei macht, ist die nächstkleinere Zahl.

• Der State, den Sie tatsächlich übergeben können, ist auf dem Bildpfad auf 896 Token begrenzt. In der Karte von Liquid heißt es, dass bei vorhandenen Bildern „der State- und Fragetext auf 896 Token gekürzt wird, wie trainiert“. Eine Entscheidungsanfrage mit Foto hat also ein Textbudget von ungefähr der Größe dieses Satzes – unabhängig davon, welche Kontextzahl auf einer Pull-Seite angegeben ist. Wenn Sie einen Triage-Prompt an 125K ausrichten und erwarten würden, für einen langen State zu zahlen, würden Sie sich an einer Zahl orientieren, die die Laufzeit nicht beschreibt. Die Zahl 16.384 ist die tatsächliche Obergrenze; die Zahl 896 ist das tatsächliche Arbeitslimit für den multimodalen Pfad; die 125K ist eine Zahl ohne Papierspur.

• Größe — 850 MB auf der Karte, zwei Dateien in der Registry. Der Ollama-Tag d1-omni:latest verweist auf eine 407 MB große quantisierte Gewichtsdatei mit der Bezeichnung Q8_0 plus eine 442 MB große Projektordatei mit der Bezeichnung BF16, und 407 + 442 = 849, was die Seite auf 850 MB rundet. Beide werden ehrlich aufgeführt; die Arithmetik ist lediglich die Summe einer Mixed-Precision-Paarung statt einer einzigen Datei. Der d1-omni:600m-bf16-Tag ist der sauberere: 764 MB BF16-Gewichte plus derselbe 442-MB-Projektor, 1,2 GB auf der Festplatte, und der Projektor ist zwischen den beiden Tags byte-identisch. Erwähnenswert für den nächsten Abschnitt, weil ein Projektor, der seine eigenen Gewichte mitbringt, die effektive Parameterzahl verschieben kann.

Ein weiteres Detail, das es wert ist festzuhalten statt zu erklären: Der Laufzeit-Parameter-Blob im d1-omni-Paket von Ollama ist byte für byte genauso lang – 18 Bytes – wie der im separaten d1-Paket von Ollama, das Liquid AI d1-3B mit 2,87 GB Q8_0-Gewichten und einem 855 MB großen Projektor ausliefert. Zwei Architekturen, zwei Parameteranzahlen, zwei Dekaden Parameter-Skala dazwischen und dieselbe 18-Byte-Laufzeitkonfiguration. Das ist eine Packaging-Konstante, keine Aussage über eines der beiden Modelle.

Was die Gewichte selbst sagen

Zieht man die Verpackung ab, ist das Modell ungewöhnlich gut dokumentiert. Liquid AI D1 Omni 600M umfasst insgesamt 587M Parameter, aufgeteilt auf drei Teile: einen 381M großen gemeinsamen Trunk samt Entscheidungskopf, einen 94M großen Vision-Encoder und einen 112M großen Audio-Encoder. Der Trunk ist bidirektional – dies ist ein Encoder, kein Decoder – und es ist derselbe Trunk für jede Modalität, an den modalitätsspezifische Türme angebaut sind.

• Vision stammt von einem SigLIP2-Turm, der von Liquid AI LFM2.5-VL-450M übernommen wurde, mit einem Adapter und LoRA-Updates, die nur für Bildeingaben aktiv waren, während der Encoder selbst eingefroren blieb.

• Audio stammt von einem 17-schichtigen FastConformer mit eigenem Adapter, der in einer Phase feinabgestimmt wurde, in der das Text-Backbone eingefroren war; anschließend wurde der gesamte Stack feinabgestimmt, die LoRA zusammengeführt und die Gewichte wurden wieder gegen den vorherigen Checkpoint gemittelt.

• Vokabular umfasst 65.536 Tokens in 15 Sprachen: Englisch, Deutsch, Spanisch, Französisch, Italienisch, Niederländisch, Polnisch, Portugiesisch, Arabisch, Hindi, Japanisch, Russisch, Türkisch, Vietnamesisch und Chinesisch.

• Modalitäten können nicht gemischt werden. Eine einzelne Anfrage umfasst Text plus Bilder oder Text plus bis zu 30 Sekunden Sprache – nicht beides. Audio wird in 16 kHz Mono, zwischen 0,5 und 30 Sekunden erwartet und wurde auf Dialogen zwischen einem englischsprachigen Sprecher und einem Assistenten trainiert, was eine echte Einschränkung für alles Mehrsprachige oder Verrauschte darstellt.

Nichts davon erscheint auf der Ollama-Seite, und das Weglassen hat eine Folge, die man direkt in den Verwendungsbeispielen sieht. Ollamas Snippets sind Chat-Aufrufe – ein Modell-String, ein messages-Array, das Wort „Hello!“ – und der zugrunde liegende Checkpoint kann sie nicht beantworten. Er ist kein Chat-Modell und schreibt keinen Text. Er liefert typisierte Antworten: eine Ja/Nein-Wahrscheinlichkeit, ein Label mit einer Wahrscheinlichkeit pro Label oder eine Position auf einer geordneten Skala, alles direkt aus der Ausgabeverteilung abgelesen, ohne dass Ausgabe-Tokens generiert werden. Die veröffentlichten Schnittstellen spiegeln das wider: system_one und probabilities über Transformers oder einen /v1/systemone-Endpunkt über llama.cpp 0.7.0 und später. Ein chatförmiger Aufruf gegen ein Entscheidungsmodell ist genau der Fehler, zu dem diese Namenslücke einlädt.

Zu jeder dieser Zahlen gehören zwei Vorbehalte.

Erstens hat Liquid seine eigenen Zeilen mit dem offiziellen Scorer bewertet, statt sie für das öffentliche Ranking einzureichen, und kein Dritter hat irgendein Ergebnis des d1-omni-600M reproduziert – der Anbieter stellt auf der Modellkarte ausdrücklich fest, dass er für diesen Checkpoint keine Inferenzzahlen meldet, weil es sich um eine frühe Forschungsversion in aktiver Entwicklung handelt. Zweitens widersprechen sich die beiden Schlagzeilen-Zahlen: Die 32-Punkte-Lücke im Index und die 4,5-Punkte-Lücke beim Benchmark-Mittelwert beschreiben dasselbe Modell, weshalb die Teilwerte und nicht die Gesamtwerte die aussagekräftige Lesart sind. Retrieval bei 35,0 und Tools bei 15,1 gegenüber Arts bei 6,8 sagen Ihnen, für welche Aufgaben dieser Checkpoint bereit ist und für welche nicht. Audio hat überhaupt keine Benchmark-Spalte; Liquid bezeichnet dedizierte Audio-Entscheidungsbenchmarks als offenes Problem.

Liquid AI D1 Omni 600M führt außerdem seine eigene Familie bei zwei der sieben an: Civil Comments mit 95,8 und PAWS-X mit 79,5. Das sind die beiden Zeilen, in denen ein 587M-Encoder den 3B-Decoder klar übertrifft, und beide sind eher auf Textklassifikation als auf Reasoning ausgelegt – was zur Architektur passt, statt ihr zu widersprechen.

Wählen Sie danach, was Sie möchten. Wenn Sie es lokal unter Ollama ausführen möchten, d1-omni ist der Name, der funktioniert – 850 MB für den Q8_0-Build, 1,2 GB für BF16, derselbe Image-Pfad, den Liquid dokumentiert, und keines der Tags trägt einen Audio-Projektor. Wenn Sie das Modell möchten, das der Anbieter beschreibt, Liquid AI D1 Omni 600M ist der Name, nach dem Sie suchen sollten, und der Transformers-Weg über das Hugging-Face-Repository ist derjenige, dessen Kontextlänge, Modalitätenliste und Parameteranzahl mit der Dokumentation übereinstimmen.

So oder so ist dies die günstige Hälfte einer Pipeline. Das Entscheidungsmodell klassifiziert; etwas anderes muss auf die Klassifizierung reagieren. Das ist die Grenze, an der OrcaRouter sitzt, und die es wert ist, präzise zu benennen: Kein Liquid-AI-Modell steht in unserem Katalog, der d1-omni-Aufruf selbst läuft also dort, wo Sie ihn ohnehin betreiben — diese Gewichte auf Ihrer eigenen Hardware oder die API des Anbieters selbst und Drittanbieterplattformen für die gehosteten Geschwister.Über 200 Modelle hinter einem einzigen OpenAI-kompatiblen Schlüssel sind für alles Nachgelagerte da, zu den Listenpreisen des jeweiligen Anbieters, durchgereicht mit 0 % Aufschlag, mit automatischem Failover über Anbieter hinweg, wenn eine triagierte Anfrage auf ein Modell ausgefächert wird, das gerade einen schlechten Tag hat.

Was würde die offene Frage klären?

Drei Dinge würden das abschließen, und keines davon braucht eine Ankündigung des Anbieters. Wenn jemand die Ausgabe des 850MB-Ollama-Tags bei denselben Eingaben mit dem Hugging Face Checkpoint vergleicht, würde uns das zeigen, ob die Verpackung die Antworten verändert hat. Ein llama.cpp-Commit oder ein Eintrag im Ollama-Changelog, der den Kontextwert erklärt, würde uns zeigen, ob 125K ein Fehler ist oder eine Fähigkeit, mit der die Modellkarte noch nicht Schritt gehalten hat. Und ein veröffentlichtes Audio-Ergebnis – irgendein Audio-Ergebnis – würde diesen Checkpoint aus der Kategorie herausbewegen, in der er sich derzeit befindet: ein gut dokumentiertes Modell mit einer undokumentierten Verpackungsschicht und einer Ergebnisliste, die vollständig vom Anbieter selbst stammt.

Die dokumentierten KI-Ausfälle und Agent-Vorfälle hinter Veröffentlichungen wie dieser werden gesammelt in dem OrcaRouter AI Incident Archive, wo jeder Eintrag eigene Quellen, Schweregrad, Konfidenzstufe und eine Kennzeichnung als strittig enthält.