Wygenerowana plansza tytułowa z nagłówkiem „Ten, który słucha”, podtytułem „Liquid AI d1-omni-600M kontra endpoint d1 – te same pytania, jedno z nich za pośrednictwem klipu głosowego”, z trzema plakietkami o treści: 587 mln parametrów (381 mln rdzenia, 94 mln wizji, 112 mln audio), 30 sekund monofonicznej mowy 16 kHz w jednym przejściu w przód oraz tekst, obraz lub audio, ale nigdy oba naraz, nad diagramem przebiegu fali i fotografią, które oba zasilają panel oznaczony „jedno przejście w przód”, emitujący skalibrowane prawdopodobieństwo, w stopce: „Dane techniczne zgodnie z kartą modelu LiquidAI/d1-omni-600M i wpisem wydania z 7 października 2026 r., odczytano 15 października 2026 r. Zgłoszone przez dostawcę; brak niezależnego odtworzenia.”
Guides & Insights

Liquid AI d1 vs Liquid AI d1-omni-600M: Otwarty model decyzyjny, który potrafi Cię usłyszeć

Autor

Alistair Wren

Data publikacji

Najnowsze modele · 20Zobacz wszystkie modele →
Benchmarki: Artificial Analysis · aktualizowane codziennie
Powrót do wszystkich wpisów

Wpisz nazwę Liquid AI d1, a trafisz na model o trzech miliardach parametrów, który czyta tekst i obrazy. Drugi otwarty checkpoint w tej samej rodzinie jest pięciokrotnie mniejszy, analizuje do trzydziestu sekund mowy i jako jedyny z tej dwójki potrafi cokolwiek rozstrzygnąć na temat głosu. Nazywa się Liquid AI d1-omni-600M, a jeśli natrafiłeś na tę rodzinę przez lokalną bibliotekę środowiska uruchomieniowego, a nie przez dokumentację samego dostawcy, jest spora szansa, że nigdy nie widziałeś jego nazwy. Właśnie tę sytuację ma naprawić to porównanie, ponieważ te dwa modele nie są konkurencyjnymi odpowiedziami na to samo pytanie. To odpowiedzi na dwa różne pytania, a tylko jedno z nich wiąże się ze słuchaniem.

Każda z poniższych liczb pochodzi z materiałów własnych Liquid AI: karty modelu LiquidAI/d1-omni-600M, towarzyszącego repozytorium d1-omni-600M-GGUF oraz wpisu o wydaniu z 7 października, który ogłosił oba otwarte checkpointy jednocześnie. Wiersze wydajności zostały ocenione przez dostawcę na utrzymywanym przez niego indeksie, a nie zgłoszone do publicznego rankingu, a wpis wprost stwierdza, że dedykowane benchmarki decyzyjne dla audio są otwartym problemem. Nic tutaj nie zostało odtworzone przez nikogo spoza laboratorium.

Z czego składa się 587 milionów parametrów

Główna liczba skrywa nietypowy podział. Łączna liczba parametrów wynosi 587M i nie jest to jeden stos: wspólny trzon o 381M z dołączoną głową decyzyjną, enkoder wizyjny 94M i enkoder audio 112M. Każda modalność przechodzi przez te same wagi trzonu, co jest decyzją projektową, która utrzymuje całość w małym rozmiarze — model nie jest trzema modelami w prochowcu, lecz jednym decydującym trzonem z dwoma sposobami podawania mu danych.

Elementy pochodzą z różnych miejsc w katalogu Liquid. Trzon wywodzi się z LFM2.5-Encoder-350M, dwukierunkowego kodera, a nie z linii wyłącznie dekoderowej, z której pochodzi większy odpowiednik. Wieża wizyjna to SigLIP2 zaczerpnięty z LFM2.5-VL-450M, z adapterem i aktualizacjami LoRA zastosowanymi do szkieletu. Ścieżka audio to 17-warstwowy koder FastConformer z własnym adapterem, dostrojony względem zamrożonego szkieletu tekstowego. Karta podaje kontekst o długości 16 384 tokenów współdzielony łącznie przez pozycje tekstowe, obrazowe i audio, przy czym tekst jest przycinany do 896 tokenów, gdy obecne są obrazy, oraz słownik o rozmiarze 65 536 tokenów — czyli połowę 128 000 tokenów jego większego odpowiednika. Na tę ostatnią liczbę warto zwrócić uwagę, jeśli pracujesz w języku, który ta rodzina obejmuje tylko częściowo.

Dwukierunkowość kontra model wyłącznie dekoderowy to powód, dla którego oba modele wydają się różne każdemu, kto uruchamiał oba. Rdzeń o kształcie enkodera odczytuje cały stan naraz, w obu kierunkach, zanim cokolwiek wyprodukuje. Ten o kształcie dekodera czyta do przodu tak, jak robi to model językowy. Oba są trenowane do podawania odpowiedzi na podstawie rozkładu przy zerowej liczbie tokenów wyjściowych, więc żaden nie pisze tekstu — ale maszyneria pod spodem należy do innej klasy modeli, a luka w dokładności omówiona poniżej jest widocznym kosztem mniejszego projektu o kształcie enkodera.

Trzydzieści sekund mowy i nie ma czym tego ocenić

Audio jest powodem istnienia tego punktu kontrolnego. Przyjmuje pojedynczy klip o długości do 30 sekund, 16 kHz mono, w tym samym przebiegu w przód, który generuje odpowiedź, i jest jedynym członkiem rodziny o otwartych wagach, który potrafi to zrobić. W przypadku pracy na urządzeniu nie jest to marginalna funkcja. Kamera, która oznacza defekt na linii produkcyjnej, to problem wizyjny, z którym większy brat już sobie radzi; urządzenie, które kieruje prośbę głosową, klasyfikuje wypowiedź lub decyduje, czy dzwoniący prosi o zwrot pieniędzy, to problem, do którego można skierować tylko ten jeden.

Na szczycie tej możliwości stoją dwa ograniczenia i oba są udokumentowane, co oznacza, że nie ma wymówki, by potknąć się o nie w środowisku produkcyjnym. Po pierwsze, jedno żądanie niesie obrazy lub dźwięk, nigdy oba — przekazanie obu podnosi ValueError, zamiast po cichu jeden odrzucić, więc awaria jest głośna i tania do wykrycia w testach. Po drugie, ścieżka audio została wytrenowana na wymianach między anglojęzycznym rozmówcą a asystentem, z klipami przyciętymi do 30 sekund. To jedna geometria mówcy, jedna struktura tur i jeden rozkład akcentów. Skierowanie jej na nagrania z call center lub dźwięk terenowy to proszenie się o zachowanie, którego karta nie obiecuje, i to dokładnie ten rodzaj luki, który ujawniłby benchmark, gdyby taki istniał.

Żaden nie istnieje. W poście zapowiadającym premierę dedykowane benchmarki decyzyjne dla dźwięku nazywa się „obecnie otwartym problemem" i zaprasza społeczność do zbudowania takiego benchmarku, co jak na laboratorium jest stwierdzeniem szczerym, a dla każdego, kto ocenia model, stanowi realne ograniczenie. Liquid AI d1-omni-600M ma uzasadnić swoją wartość siłą możliwości, której nikt jeszcze nie potrafi zmierzyć. Dostawca całkowicie wstrzymał też publikację liczb dotyczących wnioskowania, podając jako powód, że model jest wczesnym wydaniem badawczym w fazie aktywnego rozwoju. Nie ma więc żadnej wartości opóźnienia dla modelu 600M — ani dla tekstu, ani dla wizji, ani dla ścieżki audio, która jest tu sednem sprawy.

To, co można powiedzieć bez wymyślania czegokolwiek, to arytmetyka na opublikowanej liczbie parametrów: przy precyzji float16, którą karta modelu zaleca dla GPU, 587M parametrów to rząd 1,2 GB wag przed aktywacjami, w porównaniu z około 6,2 GB dla bliźniaczego modelu 3,12B przy tej samej precyzji. Karta zawiera też ostrzeżenie o precyzji, które łatwo przeoczyć, a którego nie należy przeoczyć: model był trenowany w float32, float16 jest zalecany na GPU, a bfloat16 zmienił najlepszą odpowiedź w niektórych wierszach podczas testowania. Jeśli Twój stos serwujący domyślnie używa bfloat16, to jest model, w przypadku którego ta domyślna wartość nie jest bezpieczna.

A screenshot of the Ollama library page for d1, titled 'd1' and described as 'a 3B decision model from Liquid AI, built on LFM2.5-VL-3B', with '10.5K Downloads' and 'Updated 2 hours ago' beside it, the tag chips 'vision' and '3b', and a models table listing 'd1:latest' and 'd1:3b' at 3.7GB, 32K context and Text, Image input — no audio entry anywhere on the page, and the readme's modality line reading 'Multimodal: images and text in the same state'.

Dlaczego łatwo jest przeoczyć mniejszą połowę rodziny

Powód, dla którego czytelnik trafia na 3B i się zatrzymuje, jest strukturalny, a nie przypadkowy. Indeks dokumentacji Liquid AI wymienia trzy wiersze w sekcji modeli decyzyjnych i nie czyta się ich tak samo: d1-3B i d1-omni-600M mają linki do Hugging Face i GGUF z „Nie" w kolumnie trenowalności, podczas gdy d1 zajmuje własny wiersz z samymi literami „API" tam, gdzie u każdego innego modelu byłyby linki do pobrania. Wpis o wydaniu nazywa d1 nazwą rodziny i nigdy nie rozróżnia udostępnianego endpointu od otwartego checkpointu. Lokalne biblioteki uruchomieniowe sięgają wtedy po 3B, ponieważ to ten, którego rozmiar i liczba modalności pasują do wpisu, który chcą opublikować, a 600M nie pojawia się w tym samym zestawieniu wcale.

Wynikiem jest rodzina, której opublikowana historia dostępu, czytana pobieżnie, wygląda jak jeden model i jeden wiersz API. To, co jest faktycznie oferowane, to dwa otwarte checkpointy o różnych trunkach, różnych modalnościach i 32-punktowej różnicy między ich wynikami we własnym indeksie dostawcy, plus hostowany endpoint, którego związku z którymkolwiek z checkpointów dostawca nigdy nie potwierdził. 600M nie kryje się za niczym. Po prostu nie ma nazwy, którą wyszukiwanie d1 ujawni, a jest to jedyny z dwóch, który słyszy.

Wyniki, które istnieją, i ta jedna kolumna, którą warto przeczytać

W Decision Index 0.2.1 dostawca podaje 15,95 dla Liquid AI d1-omni-600M w porównaniu do 48,57 dla jego większego brata — różnica tak duża, że suma jest niemal bezużyteczna jako podstawa wyboru. Podwyniki są bardziej informacyjne niż suma, a jeden z nich jest naprawdę zaskakujący.

• Wiedza — 8,3 wobec 23,8

• Język — 12,9 w porównaniu z 56,4

• Wyszukiwanie — 35,0 wobec 52,8

• Narzędzia — 15,1 wobec 74,5

• Sztuka — 6,8 wobec 36,3

Retrieval to obszar, w którym mały model trzyma się mocno — traci tam mniej niż jedną trzecią wyniku większego modelu, podczas gdy w pozostałych czterech kolumnach traci od 60 do 80 procent. Ten wzorzec odpowiada temu, w czym wytrenowany enkoder powinien być dobry: dopasowywanie stanu do treści jest bliskie temu, do czego zbudowano trzon, i znacznie mniej zależy od warstwowych możliwości językowych, które bliźniak o kształcie dekodera odziedziczył po znacznie większym pretrenowaniu. Kolumna Tools to odwrotna historia, a 59-punktowa różnica jest liczbą, na którą warto patrzeć, jeśli Twoje obciążenie polega na kierowaniu żądania do właściwej funkcji.

Na siedmiu publicznych benchmarkach tekstowych obraz się łagodzi. Dostawca podaje średnią 78,4 dla 600M wobec 82,9 dla 3B, przy czym mały model nieznacznie przegrywa w SQuAD 2.0 (74,0 wobec 85,3), PubMedQA (61,3 wobec 66,0), BoolQ (77,7 wobec 86,7) i XNLI (74,7 wobec 85,0), a wygrywa w wykrywaniu toksyczności Civil Comments (95,8 wobec 93,0) oraz identyfikacji parafraz PAWS-X (79,5 wobec 76,9). Sam Liquid ujmuje to tak, że 600M bije średnią 77,1 modelu decyzyjnego 2B przy jednej czwartej liczby parametrów. Dwa zestawy benchmarków dają dwa różne pozorne werdykty, oba raportowane przez samego dostawcę, a uczciwa interpretacja jest taka, że żaden z nich nie rozstrzyga niczego o ścieżce audio, ponieważ ścieżki audio nie ma w żadnym z tych zestawów.

A screenshot of the Hugging Face model card for LiquidAI/d1-omni-600M, showing the Image-Text-to-Text pipeline tag, the transformers, safetensors, 15languages, d1_omni, lfm2.5, edge, decision-model, multimodal, vision and audio tags, a model size of 0.6B params in tensor type F32, and a description of a 600M parameter decision model built on LFM2.5-Encoder-350M that takes a state of text or JSON with images or a voice clip and returns typed answers with zero output tokens.

Gdzie te dwa faktycznie się spotykają

Mimo wszystkich różnic model programowania jest identyczny i to właśnie czyni je wymiennymi w jednym konkretnym sensie. Oba odpowiadają na pytania typu noul, choice i score na podstawie stanu, oba zwracają wybraną odpowiedź z mapą prawdopodobieństwa i wartością ufności między 0 a 1, a także oba podają output_tokens: 0. Pole confidence jest tym, które ludzie błędnie odczytują: mierzy ono, jak mocno prawdopodobieństwa sprzyjają jednej odpowiedzi, a nie szanse, że odpowiedź jest poprawna. Wartość 0,96 przy źle postawionym pytaniu to pewna siebie błędna odpowiedź, a to pole cię nie ostrzeże.

To, gdzie spotykają się w praktyce, to kaskada. Wstępnie przesiewaj za pomocą Liquid AI d1-omni-600M — tanio, lokalnie i z uwzględnieniem przypadków audio, których nie obejmie żaden oceniający oparty wyłącznie na tekście — a następnie eskaluj elementy, które umieszcza blisko środka swojej skali, do większego checkpointu po bardziej precyzyjną decyzję. Zasady eskalacji to pewność i rozkład, które 600M już zwraca, więc logika routingu nie potrzebuje dodatkowego modelu, a przy obciążeniu ze zdecydowaną większością łatwych elementów większość ruchu nigdy nie dociera do drugiego etapu. Taki układ działa, ponieważ oba modele zwracają ten sam rodzaj obiektu. Z dwoma dowolnymi modelami tak by nie było.

Jeśli ta kaskada kiedykolwiek warunkuje wywołanie modelu generatywnego, który wynajmujesz, a nie uruchamiasz, to warstwa pod spodem jest miejscem, w którym robi się ciekawie przy podłączeniach, i to również tam wchodzimy my. Kierowanie decyzji przez łańcuch modeli to dokładnie ten typ problemu, do którego stworzono regułę routingu: OrcaRouter łączy kilka modeli za jednym endpointem zgodnym z OpenAI, każdy w cenie katalogowej swojego dostawcy przekazywanej z marżą 0%, z automatycznym przełączaniem awaryjnym między dostawcami, dzięki czemu eskalacja, która zawiedzie na poziomie dostawcy, jest ponawiana na modelu zapasowym, zamiast kończyć się niepowodzeniem żądania. Nie hostujemy żadnego modelu Liquid AI — sprawdziliśmy to przed napisaniem tego — więc nic powyżej nie jest twierdzeniem o wywoływaniu tych wag za naszym pośrednictwem. Rzecz w tym, że model decyzyjny jest tanią częścią potoku, a pożyczony model po drugiej stronie jest częścią, która pada.

Skąd pochodzi plik, jeśli chcesz go uruchomić dzisiaj

Do wdrożenia lokalnego własne repozytorium GGUF dostawcy dla modelu 600M udostępnia Q8_0 o rozmiarze 407 MB oraz F16 i BF16 po 764 MB każdy, bez wymienionej kompilacji 4-bitowej — zatem najmniejsze oficjalne pobranie jest około siedem razy mniejsze niż odpowiadająca mu kompilacja większego modelu i mniej więcej tej samej wielkości co zdjęcie średniej rozdzielczości. Przykład z samej karty uruchamia serwer llama.cpp z flagami batch o wartości 4096 i sugeruje zwiększenie ich do 16384 dla dłuższych stanów, a następnie odpytuje ten sam punkt końcowy /v1/systemone, z którego korzysta większy bliźniak.

Jedyna rzecz, której nie daje ci ścieżka lokalna, to liczby ścieżki audio, ponieważ one nie istnieją. Jeśli zamierzasz przepuszczać przez to mowę przed prawdziwymi użytkownikami, ewaluację musisz zbudować sam: oznaczony zbiór klipów, te same trzy typy pytań i zmierzony odsetek odpowiedzi dla każdej klasy. To nie jest odrzucenie modelu — checkpoint 587M, który w jednym przebiegu decyduje na podstawie klipu głosowego, to naprawdę inne narzędzie niż klasyfikator tekstu doklejony do etapu transkrypcji, i zasługuje na prawdziwy test, a nie taki oparty na wrażeniach.

A generated comparison board titled 'The two open d1 checkpoints', subheaded 'Same question types, same zero-token contract - different trunks, and only one of them hears', with a left column headed Liquid AI d1-omni-600M showing 587M total parameters (381M + 94M + 112M), text with image or audio, speech up to 30 s at 16 kHz mono, a Decision Index 0.2.1 of 15.95, a seven-benchmark text mean of 78.4 and inference latency 'Not reported', and a right column headed Liquid AI d1-3B showing 3.12B parameters, text with image only, speech 'Not supported', a Decision Index of 48.57, a mean of 82.9 and 8 ms per decision on an RTX 4090, footed 'All figures vendor-reported by Liquid AI on the d1-omni-600M model card, the d1-3B model card and the 7 October 2026 release post. No independent reproduction; the audio path has no published benchmark at all.'

Jeśli ta kaskada ma kiedykolwiek decydować o wywołaniu modelu generatywnego, który jest wynajmowany, a nie uruchamiany na własnym sprzęcie, OrcaRouter łączy kilka modeli za jednym punktem końcowym zgodnym z OpenAI , każdy w cenie katalogowej swojego dostawcy, przekazywanej z 0% marży.

Wybór punktu kontrolnego omni zamiast tekstowego to również dobry moment, aby przyjrzeć się temu, co już poszło nie tak w tej klasie: udokumentowane incydenty AI i awarie agentów związane z małymi modelami multimodalnymi są zebrane w OrcaRouter AI Incident Archive, gdzie każdy wpis zawiera własne źródła, wagę, stopień pewności i oznaczenie sporu.