Karta tytułowa z nagłówkiem „d1-2B vs d1-omni-600M” i podtytułem „Jeden czyta piksele, drugi słyszy mowę”, trzy karty z tekstem „1.92B / 128K kontekstu”, „587M / 16K kontekstu” i „Audio: nie / tak” oraz stopka z tekstem „Żaden z modeli nie jest hostowany przez OrcaRouter; oba mają otwarte wagi”.
Guides & Insights

d1-2B vs Liquid AI d1-omni-600M: gdy decydującym sygnałem wejściowym jest dźwięk

Autor

Gideon Frost

Data publikacji

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

Postaw przed tymi dwoma modelami notatkę głosową i sfotografowaną fakturę, a tylko jeden z nich potrafi odpowiedzieć — i nie jest to ten z lepszym wynikiem. d1-2B czyta tekst, JSON, obrazy i wideo, a w ogóle nie przyjmuje dźwięku. Liquid AI d1-omni-600M czyta tekst z obrazami lub tekst z maksymalnie 30 sekundami mowy, a nie przyjmuje dźwięku i obrazów w tym samym żądaniu. Ta pojedyncza asymetria rozstrzyga większość rzeczywistych wdrożeń, zanim jeszcze sprawdzi się którykolwiek benchmark. Poniżej i tak znajduje się uczciwa wersja porównania: gdzie model 587M jest naprawdę konkurencyjny, gdzie model 1.92B jest daleki od bycia zastępowalnym, oraz jeden wzorzec potoku, który wykorzystuje oba, nie udając, że są alternatywami.

A screenshot of the Hugging Face model page for LiquidAI/d1-2B showing 44 downloads last month, Image-Text-to-Text and Transformers tags, a '2B params / BF16' panel, a capability list naming text, pictures and video, and a notice that no inference provider deploys it.

Decyzja jest kwestią modalności, a nie kwestią punktacji.

Model decyzyjny przyjmuje stan i zestaw nazwanych pytań i zwraca prawdopodobieństwo dla każdej odpowiedzi, bez generowanych tokenów. Stan to całe dane wejściowe, a typ tego stanu jest wiążącym ograniczeniem. Karta d1-2B wymienia tekst, JSON, obrazy i wideo. Karta Liquid AI d1-omni-600M wymienia tekst z obrazami lub tekst z dźwiękiem — a kod wymusza wykluczenie: przekazanie jednocześnie obrazu i klipu audio do system_one powoduje wyjątek ValueError.

Pierwsze pytanie nie brzmi więc, który model uzyskuje wyższy wynik. Brzmi ono, czy to, co musisz ocenić, dociera jako piksele, tekst czy przebieg fali. Jeśli dociera jako przebieg fali, w tej parze jest jedna odpowiedź, a reszta tej strony dotyczy tego, ile dokładności poświęcasz, aby ją uzyskać.

Co tak naprawdę można kupić za 587M

600M nie jest małą wersją d1-2B. To inna konstrukcja, a budżet warto zobaczyć w rozbiciu na pozycje, ponieważ wyjaśnia zarówno jej mocne strony, jak i jej górny limit.

• Parametry — łącznie 587M: wspólny trzon i głowica decyzyjna o rozmiarze 381M, enkoder wizyjny o rozmiarze 94M oraz enkoder audio o rozmiarze 112M. Każda modalność przechodzi przez te same wagi trzonu.

• Base — LFM2.5-Encoder-350M, dwukierunkowy enkoder, z wieżą wizyjną SigLIP2 zapożyczoną z LFM2.5-VL-450M oraz 17-warstwowym FastConformerem do dźwięku.

• Kontekst — 16 384 tokeny łącznie dla pozycji tekstowych, obrazowych i audio oraz słownik 65 536 tokenów. Okno d1-2B wynosi 128K.

• Audio — do 30 sekund mowy mono przy 16 kHz na żądanie. Karta jasno stwierdza, że część audio wytrenowano na żądaniach między osobą mówiącą po angielsku a asystentem, co stanowi wąski rozkład jak na model, który ludzie będą stosować do nagrań rozmów.

• Reguła multimediów — obrazy lub dźwięk, nigdy oba naraz. Karta dokumentuje ValueError, zamiast pozostawiać Ci odkrycie go na własną rękę.

• Licencja — LFM Open License v1.0, ta sama struktura progów co w d1-2B: użycie komercyjne przy rocznym przychodzie poniżej 10 000 000 USD.

• Szybkość — nieopublikowana. Karta nie podaje żadnych wartości opóźnień, nazywając model wczesnym wydaniem badawczym w fazie aktywnego rozwoju. d1-2B podaje 5,7 ms na H100 PCIe, 3,8 ms na MI325X i 18,6 ms na M5 Pro.

A screenshot of the Hugging Face model page for LiquidAI/d1-omni-600M showing 18,870 downloads last month, a '0.6B params / F32' panel, a '15 languages' tag, a capability list for vision-language and audio-language input with up to 30 seconds of speech, and the 587M parameter split into a 381M trunk, a 94M vision encoder and a 112M audio encoder.

Tabela tego samego przebiegu i wiersze, w których luka jest niewielka

Oba modele występują w tabeli benchmarku na karcie d1-2B, która ocenia cztery otwarte modele d1 na identycznych elementach za pomocą identycznego scorera. Dzięki temu porównanie jest czystsze niż w przypadku większości porównań między kartami, z jednym zastrzeżeniem: własna karta d1-omni-600M podaje 15,95 w Decision Index 0.2.1, podczas gdy ta tabela podaje 18,3 w wersji 0.3. Różnica wynika z edycji indeksu, a obie liczby są poprawne dla własnego testu.

• Publiczny zestaw Decision Index v0.3 — 51,1 dla d1-2B vs 18,3 dla Liquid AI d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 77,1 w porównaniu z 58,7.

• Decision Bench (decisionbench.ai) v4 — 85,2 vs 57,9.

• ImajevBench v2.0-lite — 75,5 vs 21,7, największa różnica po stronie decyzyjnej między nimi.

• WorkflowEvals — 81,6 vs 48,8.

• Średnia Vision, 18 benchmarków — 70,2 vs 42,8.

• VisualWebBench — 96,2 vs 14,9, co jest mniej porównaniem, a bardziej stwierdzeniem, ile może udźwignąć enkoder wizyjny o 94 mln parametrów.

Z kolei wiersze, które przemawiają za umiarem. Typed Decisions to 61,3 wobec 57,5 — różnica 3,8 punktu dla modelu z jedną trzecią parametrów. POPE, test halucynacji obiektów, wynosi 88,7 wobec 82,7. JevBench wynosi 77,9 wobec 58,0, co daje dużą różnicę, ale DecisionBench v4 wynosi 85,2 wobec 57,9, a oba wyniki łącznie wskazują, że model 600M jest nierówny, a nie jednolicie słaby. Własny wpis Liquid AI z okazji premiery podaje średnią z siedmiu benchmarków na poziomie 78,4, co jest wysoką wartością jak na 587M; karta modelu d1-2B nie publikuje równoważnej średniej, więc tych dwóch liczb nie należy zestawiać obok siebie.

Jedyna liczba, która nie schlebia żadnemu z modeli, to ta niezależna. Efraín Garay uruchomił Liquid AI d1-omni-600M na próbie 6000 żądań z Decision Index 0.3 i uzyskał 14,0 wobec 14,17 uzyskanych przez samego dostawcę na tej samej próbie — bliskie odtworzenie. Odkrył również, że 1758 żądań przekroczyło budżet instrukcji i opcji modelu i zostało odrzuconych, policzonych jako błędne, co jest realnym kosztem okna 16K w zestawie zbudowanym dla dłuższych stanów.

Gdzie 600M jest jedyną opcją

Routing audio to przypadek, dla którego zbudowano model, a przykłady na karcie są konkretne: routing połączeń i wiadomości głosowych, zdarzenia dźwiękowe, instrukcje mówione na tle stanu zapisanego tekstowo. Nic z tego nie jest dostępne w d1-2B z jakąkolwiek dokładnością, ponieważ nie ma enkodera audio ani pozycji audio w swoim schemacie danych wejściowych.

Dwa niezależne punkty danych powinny ostudzić ten entuzjazm. Pierwszy to powyższa ocena, w której model 600M uzyskał AUC wykrywania strzałów na poziomie 0,580 i AUC prognozy deszczu na poziomie 0,593 w zadaniach na rzeczywistych danych — zaledwie powyżej przypadku i poniżej każdego testowanego większego modelu. Drugi to praktyczna recenzja, która odnotowała zużycie poniżej 2 GB VRAM i wykazała, że model znacznie pewniej klasyfikuje sposób wypowiedzi i ton w audio niż znaczenie semantyczne, a pytania wymagające wnioskowania wypadają blisko rzutu monetą. Oba wskazują to samo: to model przesiewowy. Dobrze radzi sobie z „jakiego rodzaju to coś jest”, ale nie zastępuje modelu, który rozumie, co zostało powiedziane.

To nie jest krytyka checkpointu 587M. To jest to, co daje 587M, gdy 381M z tego to wspólny trzon. Powodem, by tego używać, są koszt i rozmiar — poniżej 2 GB VRAM, repozytorium GGUF od 6 października, kompilacje MLX od 12 października oraz decyzja w jednym przejściu w przód — a nie wierność odwzorowania.

A two-column scoreboard comparing d1-2B and d1-omni-600M across parameters (1.92B vs 587M), context (128K vs 16K tokens), Decision Index v0.3 (51.1 vs 18.3), vision average (70.2 vs 42.8), audio input (no vs 30 seconds) and weights (3.84GB vs 2.35GB), with a footer reading 'Vendor-reported, scored on the same items; no independent audio benchmark exists.'

Kaskada wykorzystująca oba

Błędem jest traktowanie ich jako konkurentów. To dwa etapy tego samego filtra, a w naturalnym potoku przetwarzania jako pierwszy uruchamiany jest tani model.

Etap pierwszy: Liquid AI d1-omni-600M przyjmuje element przychodzący — notatkę głosową, zgłoszenie do działu wsparcia, pisemną reklamację z załącznikiem — i odpowiada na ogólne pytania. Czy to problem z rozliczeniami, czy techniczny? Czy dzwoniący jest zdenerwowany? Czy ta wiadomość w ogóle zawiera prośbę? Przy rozmiarze poniżej 2 GB i jednym przebiegu jest to wystarczająco tanie, by uruchamiać na każdym elemencie.

Etap drugi: wszystko, co model 600M umieszcza blisko środka swojej skali, albo wszystko, co przychodzi z obrazem wymagającym odczytania, eskaluje do d1-2B. Model 2B otrzymuje okno 128K, wejście wideo i mniej więcej trzykrotnie wyższą średnią w zadaniach wizyjnych, a widzi tylko tę część ruchu, której pierwszy etap nie zdołał rozstrzygnąć.

Cała robota polega na progach. Obie karty zwracają prawdopodobieństwa i obie każą kalibrować na własnych danych — karta d1-2B mówi to wprost. Kaskada z nieskalibrowanym środkowym przedziałem albo eskaluje wszystko — wtedy 600M było tylko ozdobą — albo nie eskaluje niczego, a wtedy 2B nigdy nie koryguje etapu, który nie potrafi czytać.

W większości rzeczywistych systemów istnieje trzeci etap: model, który pisze odpowiedź. To tam wkracza hostowane API i tam OrcaRouter staje się istotny. Żaden z modeli Liquid AI nie jest udostępniany przez nas, więc węzły decyzyjne pozostają na Twoim własnym GPU; etap generatywny, który konsumuje ich etykiety, może pochodzić z jednego klucza zgodnego z OpenAI obejmującego ponad 200 modeli, z 0% marży na ceny katalogowe dostawców i automatycznym przełączaniem awaryjnym, jeśli dostawca wypadnie w trakcie ruchu. DSL routingu to również uczciwy sposób wyrażenia samej kaskady — dwa modele decyzyjne jako kroki po stronie GPU, generowanie odpowiedzi jako krok hostowany, złożone ze sobą, a nie sklejone w kodzie aplikacji.

Czego nie robi żaden z modeli — i trzecia opcja

Żaden z nich nie {{1}}pisze tekstu{{/1}}. Oba {{2}}zwracają odpowiedzi typowane i prawdopodobieństwa{{/2}} z {{3}}zerową liczbą tokenów wyjściowych{{/3}}; jeśli następny krok wymaga prozy, to jest to inny model. Żaden z nich nie obsługuje {{4}}wideo z dźwiękiem{{/4}}: {{5}}d1-2B{{/5}} przyjmuje klatki wideo, ale nie dźwięk, {{6}}600M{{/6}} przyjmuje dźwięk, ale nie razem z obrazami, a {{7}}30-sekundowy limit dźwięku{{/7}} to twardy limit, a nie zalecenie.

Jeśli wymaganie rzeczywiście brzmi „audio i obrazy w tym samym żądaniu”, odpowiedzią nie jest żadna z nich — jest nią d1-Omni-2B, 2,17-miliardowy model siostrzany, który Liquid AI stworzyło dwadzieścia cztery sekundy po d1-2B i który przyjmuje tekst, obrazy, klatki wideo i klipy audio na jednej liście multimediów. Jego wynik w Decision Index wynosi 49,0 w tej samej tabeli v0.3, średnia dla wizji to 67,7, a niezależne testy są nieobecne tak samo jak w przypadku d1-2B. Ma około czterokrotnie więcej parametrów niż model 600M, co jest ceną braku wyboru między modalnościami.

Zasada jest więc krótka. Jeśli stan zawiera mowę i nic więcej nie wymaga widzenia, Liquid AI d1-omni-600M jest jedynym elementem tej pary, który może działać, i należy go traktować jako ekran. Jeśli stan to tekst, obrazy lub wideo, a odpowiedź musi się obronić, modelem jest d1-2B — i to on ma opublikowany wskaźnik opóźnienia, okno 128K oraz przewagę w benchmarku, która utrzymuje się przy czytaniu wiersz po wierszu. Jeśli stan zawiera jedno i drugie, odpowiedzią nie jest żaden z nich, lecz model omni 2.17B.