Liquid AI d1 vs. Liquid AI d1-omni-600M: Das offene Entscheidungsmodell, das dich hören kann

Suche nach dem Namen Liquid AI d1 und du landest bei einem Modell mit drei Milliarden Parametern, das Text und Bilder liest. Der andere offene Checkpoint derselben Familie ist ein Fünftel so groß, verarbeitet bis zu dreißig Sekunden Sprache und ist der einzige der beiden, der überhaupt irgendetwas über eine Stimme entscheiden kann. Er heißt Liquid AI d1-omni-600M, und wenn du die Familie über eine lokale Runtime-Bibliothek statt über die Dokumentation des Anbieters selbst gefunden hast, stehen die Chancen gut, dass du seinen Namen noch nie gesehen hast. Genau diese Situation soll dieser Vergleich klären, denn die beiden Modelle sind keine konkurrierenden Antworten auf dieselbe Frage. Sie sind Antworten auf zwei verschiedene Fragen, und nur bei einer davon geht es ums Zuhören.

Jede Zahl unten stammt aus Material von Liquid AI selbst: der Modellkarte LiquidAI/d1-omni-600M, dem zugehörigen Repository d1-omni-600M-GGUF und dem Veröffentlichungsbeitrag vom 7. Oktober, in dem beide offenen Checkpoints gleichzeitig angekündigt wurden. Die Leistungszeilen wurden vom Anbieter anhand eines Index bewertet, den er selbst pflegt, statt für ein öffentliches Ranking eingereicht zu werden, und in dem Beitrag heißt es unumwunden, dass spezielle Benchmarks für Audio-Entscheidungen ein offenes Problem sind. Nichts davon wurde von jemandem außerhalb des Labors reproduziert.

Woraus 587 Millionen Parameter bestehen

Die Zahl in der Schlagzeile verbirgt eine ungewöhnliche Aufteilung. Die Gesamtparameter belaufen sich auf 587 Mio., und sie sind kein einzelner Stack: ein gemeinsamer Trunk mit 381 Mio., an dem der Entscheidungs-Head hängt, ein Vision-Encoder mit 94 Mio. und ein Audio-Encoder mit 112 Mio. Jede Modalität läuft durch dieselben Trunk-Gewichte, was die Designentscheidung ist, die das Ganze klein hält – das Modell sind nicht drei Modelle in einem Trenchcoat, sondern ein einziger Trunk, der die Entscheidungen trifft, mit zwei Wegen, ihn zu füttern.

Die Komponenten stammen aus verschiedenen Teilen des Katalogs von Liquid. Der Trunk stammt vom LFM2.5-Encoder-350M ab, einem bidirektionalen Encoder, nicht von der Decoder-only-Linie, aus der das größere Geschwistermodell stammt. Der Vision-Tower ist ein SigLIP2, der aus LFM2.5-VL-450M übernommen wurde, mit einem Adapter und LoRA-Updates am Backbone. Der Audiopfad ist ein 17-schichtiger FastConformer-Encoder mit eigenem Adapter, der gegen ein eingefrorenes Text-Backbone feinabgestimmt wurde. Die Modellkarte gibt einen Kontext von 16.384 Token an, der gemeinsam über Text-, Bild- und Audiopositionen hinweg genutzt wird, wobei Text auf 896 Token gekürzt wird, wenn Bilder vorhanden sind, und ein Vokabular von 65.536 Token — die Hälfte der 128.000 des größeren Geschwistermodells. Die letzte Zahl ist beachtenswert, wenn Sie in einer Sprache arbeiten, die die Familie nur teilweise abdeckt.

Bidirektional versus Decoder-only ist der Grund, warum sich die beiden Modelle für jeden, der beide ausgeführt hat, unterschiedlich anfühlen. Der encoderförmige Rumpf liest den gesamten Zustand auf einmal, in beide Richtungen, bevor er überhaupt etwas erzeugt. Der decoderförmige liest vorwärts, so wie es ein Sprachmodell tut. Beide sind darauf trainiert, Antworten aus einer Verteilung mit null Ausgabe-Tokens zu melden, also schreibt keines von beiden Text – doch die Maschinerie darunter ist eine andere Modellklasse, und die unten diskutierte Genauigkeitslücke ist der sichtbare Preis des kleineren, encoderförmigen Designs.

Dreißig Sekunden Rede, und nichts, womit man sie bewerten kann

Audio ist der Grund, warum dieser Checkpoint existiert. Er akzeptiert einen einzelnen Clip von bis zu 30 Sekunden, 16 kHz Mono, im selben Forward-Pass, der die Antwort erzeugt, und er ist das einzige Open-Weight-Mitglied der Familie, das dazu in der Lage ist. Für On-Device-Arbeit ist das kein marginales Feature. Eine Kamera, die einen Defekt an einer Produktionslinie meldet, ist ein Vision-Problem, das das größere Geschwistermodell bereits bewältigt; ein Gerät, das eine gesprochene Anfrage routet, eine Äußerung klassifiziert oder entscheidet, ob ein Anrufer eine Rückerstattung verlangt, ist ein Problem, auf das nur dieses eine gerichtet werden kann.

Auf dieser Fähigkeit lasten zwei Einschränkungen, und beide sind dokumentiert, was bedeutet, dass es keine Entschuldigung dafür gibt, in der Produktion über sie zu stolpern. Erstens enthält eine Anfrage Bilder oder Audio, niemals beides – beides zu übergeben löst einen ValueError aus, statt eines stillschweigend zu verwerfen, sodass der Fehler laut ist und sich beim Testen günstig finden lässt. Zweitens wurde der Audio-Pfad auf Austausch zwischen einem englischsprachigen Sprecher und einem Assistenten trainiert, wobei die Clips auf 30 Sekunden geschnitten wurden. Das ist eine Sprechergeometrie, eine Turn-Struktur und eine Akzentverteilung. Ihn auf Callcenter-Aufzeichnungen oder Feld-Audio anzuwenden, verlangt Verhalten, das die Karte nicht beansprucht, und es ist genau die Art von Lücke, die ein Benchmark aufdecken würde, wenn es einen gäbe.

Keines existiert. Der Release-Beitrag bezeichnet dedizierte Benchmarks für Audio-Entscheidungen als „derzeit ein offenes Problem" und lädt die Community ein, eines zu entwickeln – eine bemerkenswert offene Aussage für ein Labor und eine echte Einschränkung für jeden, der das Modell bewerten möchte. Liquid AI d1-omni-600M muss sich mit der Stärke einer Fähigkeit rechtfertigen, die noch niemand messen kann. Der Anbieter hat zudem sämtliche Inferenzzahlen zurückgehalten, mit der angegebenen Begründung, dass es sich um eine frühe Forschungsversion in aktiver Entwicklung handelt. Somit gibt es überhaupt keinen Latenzwert für das 600M – weder für Text, noch für Vision, noch für den Audio-Pfad, um den es eigentlich geht.

Was sich sagen lässt, ohne irgendetwas zu erfinden, ist Arithmetik anhand der veröffentlichten Parameterzahl: Bei der float16-Präzision, die die Modellkarte für GPUs empfiehlt, liegen 587M Parameter in der Größenordnung von 1,2 GB an Gewichten vor den Aktivierungen, gegenüber ungefähr 6,2 GB beim 3,12B-Schwestermodell bei derselben Präzision. Die Modellkarte enthält außerdem eine Präzisionswarnung, die man leicht überfliegt und die man nicht überfliegen sollte: Das Modell wurde in float32 trainiert, float16 wird auf GPUs empfohlen, und bfloat16 änderte beim Testen in einigen Zeilen die Top-Antwort. Wenn Ihr Serving-Stack standardmäßig bfloat16 verwendet, ist dies ein Modell, bei dem diese Standardeinstellung nicht sicher ist.

Warum die kleinere Hälfte der Familie leicht zu übersehen ist

Der Grund, warum ein Leser beim 3B ankommt und stehen bleibt, ist struktureller und nicht zufälliger Natur. Der Dokumentationsindex von Liquid AI führt drei Zeilen unter Entscheidungsmodellen auf, und sie lesen sich nicht gleich: d1-3B und d1-omni-600M tragen Hugging-Face- und GGUF-Links mit einem „Nein“ in der Spalte „trainierbar“, während d1 in einer eigenen Zeile steht, mit den bloßen Buchstaben „API“ dort, wo bei jedem anderen Modell die Download-Links stünden. Der Release-Beitrag nennt d1 einen Familiennamen und unterscheidet nie den ausgelieferten Endpunkt vom offenen Checkpoint. Lokale Runtime-Bibliotheken greifen dann zum 3B, weil es dasjenige ist, dessen Größe und Modalitätsanzahl zum Eintrag passen, den sie veröffentlichen wollen, und das 600M taucht in derselben Auflistung überhaupt nicht auf.

Das Ergebnis ist eine Familie, deren veröffentlichte Zugangsgeschichte, schnell gelesen, wie ein Modell und eine API-Zeile aussieht. Was tatsächlich angeboten wird, sind zwei offene Checkpoints mit unterschiedlichen Trunks, unterschiedlichen Modalitäten und einer 32-Punkte-Lücke zwischen ihren Scores im hauseigenen Index des Anbieters, plus ein gehosteter Endpoint, dessen Beziehung zu einem der beiden Checkpoints der Anbieter nie bestätigt hat. Das 600M ist nicht hinter irgendetwas versteckt. Es hat einfach keinen Namen, den eine Suche nach d1 zutage fördern wird, und es ist das einzige der beiden, das hört.

Die Punktzahlen, die es gibt, und die einzige Spalte, die lesenswert ist.

Auf dem Decision Index 0.2.1 meldet der Anbieter 15,95 für Liquid AI d1-omni-600M gegenüber 48,57 für sein größeres Schwestermodell — eine Lücke, die groß genug ist, dass die Gesamtsumme als Grundlage für die Auswahl nahezu unbrauchbar ist. Die Teilbewertungen sind aussagekräftiger als die Summe, und eine davon ist wirklich überraschend.

• Wissen — 8,3 gegen 23,8

• Sprache — 12,9 gegenüber 56,4

• Abruf — 35,0 gegen 52,8

• Tools — 15,1 gegen 74,5

• Kunst — 6,8 gegen 36,3

Retrieval ist der Bereich, in dem das kleine Modell sich behauptet: Es verliert weniger als ein Drittel des Scores des größeren Modells, während es in den anderen vier Spalten 60 bis 80 Prozent verliert. Dieses Muster entspricht dem, worin ein trainierter Encoder gut sein sollte: Einen Zustand mit Inhalten abzugleichen, kommt dem nahe, wofür der Trunk gebaut wurde, und es hängt viel weniger von der geschichteten Sprachfähigkeit ab, die das decoderförmige Geschwistermodell aus weit mehr Pretraining geerbt hat. Die Spalte „Tools“ erzählt die entgegengesetzte Geschichte, und eine Lücke von 59 Punkten ist die Zahl, auf die man starren sollte, wenn es bei Ihrer Workload darum geht, eine Anfrage an die richtige Funktion weiterzuleiten.

Auf sieben öffentlichen Text-Benchmarks relativiert sich das Bild. Der Anbieter berichtet einen Mittelwert von 78,4 für das 600M gegenüber 82,9 für das 3B, wobei das kleine Modell auf SQuAD 2.0 (74,0 gegenüber 85,3), PubMedQA (61,3 gegenüber 66,0), BoolQ (77,7 gegenüber 86,7) und XNLI (74,7 gegenüber 85,0) knapp unterliegt, während es bei der Toxizitätserkennung von Civil Comments (95,8 gegenüber 93,0) und der Paraphrasen-Identifikation von PAWS-X (79,5 gegenüber 76,9) gewinnt. Liquids eigene Darstellung ist, dass das 600M mit einem Viertel der Parameter den Mittelwert von 77,1 eines 2B-Entscheidungsmodells übertrifft. Zwei Benchmark-Suites liefern zwei unterschiedliche scheinbare Urteile, beide selbst berichtet, und die ehrliche Lesart ist, dass keine von beiden etwas über den Audio-Pfad klärt, weil der Audio-Pfad in keiner der beiden Suites enthalten ist.

Wo die beiden tatsächlich aufeinandertreffen

Trotz aller Unterschiede ist das Programmiermodell identisch, und genau das macht sie in einer bestimmten Hinsicht austauschbar. Beide beantworten noul-, Choice- und Score-Fragen über einem Zustand, beide geben die gewählte Antwort mit einer Wahrscheinlichkeitskarte und einem Konfidenzwert zwischen 0 und 1 zurück, und beide melden output_tokens: 0. Das confidence-Feld ist das, was die Leute falsch lesen: Es misst, wie stark die Wahrscheinlichkeiten eine Antwort begünstigen, nicht die Chance, dass die Antwort richtig ist. Eine 0,96 bei einer schlecht gestellten Frage ist eine selbstsichere falsche Antwort, und das Feld wird Sie nicht warnen.

Wo sie sich in der Praxis treffen, ist eine Kaskade. Vorfiltern mit Liquid AI d1-omni-600M — kostengünstig, lokal und einschließlich der Audiofälle, die kein reiner Text-Scorer abdecken kann — dann die Elemente, die es nahe der Mitte seiner Skala einordnet, an den größeren Checkpoint eskalieren, für eine präzisere Entscheidung. Die Eskalationsregeln sind die Konfidenz und die Verteilung, die das 600M bereits zurückgibt, sodass die Routing-Logik kein zusätzliches Modell benötigt, und bei einer Arbeitslast mit einer starken Mehrheit einfacher Elemente erreicht der Großteil des Datenverkehrs nie die zweite Stufe. Diese Zusammensetzung funktioniert, weil beide Modelle dieselbe Art von Objekt zurückgeben. Zwei beliebige Modelle würden das nicht.

Wenn diese Kaskade jemals einen Aufruf an ein generatives Modell, das Sie mieten, anstatt es selbst zu betreiben, steuert, dann ist die Ebene darunter der Punkt, an dem die Verkabelung interessant wird, und dort kommen auch wir ins Spiel. Eine Entscheidung durch eine Kette von Modellen zu routen, ist genau die Art von Problem, für die eine Routing-Regel gedacht ist: OrcaRouter kombiniert mehrere Modelle hinter einem einzigen OpenAI-kompatiblen Endpunkt, jedes zum Listenpreis seines Anbieters, durchgereicht mit 0 % Aufschlag, mit automatischem Failover über Anbieter hinweg, sodass eine Eskalation, die auf Anbieterebene fehlschlägt, stattdessen über einen Fallback erneut versucht wird, anstatt die Anfrage fehlschlagen zu lassen. Wir hosten kein Liquid AI-Modell – wir haben vor dem Schreiben nachgesehen –, daher ist nichts von dem oben Gesagten eine Aussage darüber, diese Gewichte über uns aufzurufen. Der Punkt ist, dass das Entscheidungsmodell der günstige Teil der Pipeline ist und das geliehene Modell auf der anderen Seite der Teil, der ausfällt.

Woher die Datei stammt, wenn du sie heute ausführen möchtest

Für die lokale Bereitstellung enthält das eigene GGUF-Repository des Anbieters für das 600M-Modell Q8_0 mit 407 MB sowie F16 und BF16 mit jeweils 764 MB, wobei kein 4-Bit-Build aufgeführt ist – somit ist der kleinste offizielle Download etwa siebenmal kleiner als der entsprechende Build des größeren Modells und etwa so groß wie ein mittelauflösendes Foto. Das Beispiel auf der Karte selbst startet einen llama.cpp-Server mit Batch-Flags von 4096 und schlägt vor, sie für längere Zustände auf 16384 zu erhöhen, und fragt dann denselben /v1/systemone-Endpunkt ab, den das größere Geschwistermodell verwendet.

Das Einzige, was die lokale Route nicht liefert, sind die Zahlen des Audiopfads, denn die gibt es nicht. Wenn Sie Sprache vor echten Nutzern durch dieses System laufen lassen wollen, müssen Sie die Evaluierung selbst bauen: ein gelabeltes Set von Clips, dieselben drei Fragetypen und eine gemessene Antwortrate pro Klasse. Das ist keine Abwertung des Modells – ein 587M-Checkpoint, der in einem Durchlauf über einen Sprachclip entscheidet, ist ein wirklich anderes Werkzeug als ein Textklassifikator, der an einen Transkriptionsschritt angeschraubt ist, und es verdient einen echten Test statt eines auf Bauchgefühl basierenden.

Wenn diese Kaskade jemals einen Aufruf an ein generatives Modell steuert, das Sie mieten statt selbst zu betreiben, kombiniert OrcaRouter mehrere Modelle hinter einem einzigen OpenAI-kompatiblen Endpunkt , jeweils zum Listenpreis des Anbieters, durchgereicht mit 0 % Aufschlag.

Die Wahl eines Omni-Checkpoints anstelle des reinen Text-Checkpoints ist auch ein guter Zeitpunkt, um sich anzusehen, was in dieser Klasse bereits schiefgelaufen ist: Die dokumentierten KI-Vorfälle und Agentenfehler mit kleinen multimodalen Modellen sind gesammelt in dem OrcaRouter AI Incident Archive, wo jeder Eintrag seine eigenen Quellen, Schweregrad, Vertrauensstufe und Disputed-Flag trägt.