Liquid AI d1-omni-600M vs Liquid AI d1-3B: Której połowy rodziny d1 naprawdę potrzebujesz?

Liquid AI d1-omni-600M i Liquid AI d1-3B zostały przesłane do Hugging Face w odstępie ośmiu godzin od siebie 5 października 2026 r. i udostępnione razem w tym samym ogłoszeniu z 7 października, co czyni zwykłe pytanie — który jest nowszy, który jest lepszy — pytaniem niewłaściwym. Stanowią dwa końce celowego kompromisu. Liquid AI d1-3B to gotowy produkt: 3,12 mld parametrów, wynik 48,57 w ocenianym przez dostawcę Decision Index 0.2.1, tabele benchmarków, opóźnienie zmierzone aż na Jetson Orin Nano oraz miejsce opisane w poście premierowym jako najwyższa jakość decyzji w swojej klasie rozmiarowej. Liquid AI d1-omni-600M to eksperyment: 587 mln parametrów, 15,95 w tym samym indeksie, wejście audio, którego nie ma model 3B, oraz karta modelu, która wprost mówi, że to wczesne wydanie badawcze bez liczb dotyczących wnioskowania, ponieważ wciąż jest aktywnie rozwijany. Wybór między nimi nie jest decyzją o jakości. To decyzja o tym, czy potrzebujesz dodatkowych modalności na dole rodziny, czy dodatkowej dokładności na górze, a liczby stoją za tym podziałem, zamiast go zacierać.

Wszystko poniżej pochodzi z dwóch kart modeli oraz wpisu o wydaniu z 7 października, z zachowaniem własnych oznaczeń tego wpisu: wiersze d1 w Decision Index zostały ocenione przez Liquid AI za pomocą oficjalnego narzędzia oceniającego, a nie zgłoszone do publicznego leaderboardu, i nic tutaj nie zostało niezależnie odtworzone.

Dwa backbony, które nigdy nie miały się zbiec

Model d1 nie skalował pojedynczego przepisu w dół. Dwa punkty kontrolne zaczynają z przeciwnych krańców katalogu modeli Liquid i spotykają się pośrodku.

Liquid AI d1-3B powstał na bazie LFM2.5-VL-3B, firmowego modelu wizyjno-językowego typu decoder-only z sierpnia 2026 roku. Jego podstawę utworzono poprzez uśrednienie wag LFM2.5-2.6B z tekstowym szkieletem LFM2.5-VL-3B, a następnie dostrojenie checkpointów przy różnych losowych seedach i mieszankach danych, przed ponownym ich scaleniem. Posiada 400-milionowy enkoder wizyjny SigLIP2 NaFlex zoptymalizowany pod kątem kształtu, kontekst 32 768 tokenów, słownik 128 000 tokenów oraz szesnaście udokumentowanych języków.

Liquid AI d1-omni-600M idzie z przeciwnej strony. Jego trzon stanowi LFM2.5-Encoder-350M, dwukierunkowy enkoder, najpierw dostrojony do zadań decyzyjnych, a następnie rozbudowywany etapami — 17-warstwowy enkoder FastConformer wraz z adapterem do dźwięku, przy czym enkoder audio został później dostrojony względem zamrożonego trzonu tekstowego, a następnie wieża SigLIP2 zaczerpnięta z LFM2.5-VL-450M z adapterem oraz aktualizacjami LoRA trzonu na potrzeby wizji. Ostateczny model scalono z aktualizacji LoRA i uśredniono z poprzednim punktem kontrolnym. Całość liczy łącznie 587 mln parametrów: 381 mln współdzielonego trzonu i głowicy decyzyjnej, 94 mln enkodera wizyjnego oraz 112 mln enkodera audio.

Tylko dekoder kontra model dwukierunkowy to ta część, którą warto zapamiętać. Model 3B odczytuje stan i podejmuje decyzję tak, jak model językowy generuje sekwencję tokenów – po jednym kierunku na raz. Model 600M odczytuje cały stan naraz i decyduje, czego można by oczekiwać od enkodera, który nigdy nie został stworzony do generowania. Oba są trenowane, aby podawać odpowiedzi na podstawie rozkładu modelu przy zerowej liczbie tokenów wyjściowych, ale mechanizm pod spodem nie należy do tej samej klasy modeli, a różnica w dokładności poniżej jest widocznym kosztem mniejszego, enkoderowego projektu.

Rozpiętość Decision Index jest duża, a wyniki cząstkowe są ciekawsze niż wynik ogólny.

W Decision Index 0.2.1 Liquid podaje 48,57 dla Liquid AI d1-3B i 15,95 dla Liquid AI d1-omni-600M, wobec 50,02 dla Winnow-12B. To 32-punktowa różnica między dwoma checkpointami wydanymi tego samego dnia przez to samo laboratorium, a przyjrzenie się pięciu wynikom cząstkowym wyjaśnia, skąd się ona bierze.

• Wiedza — 23,8 dla Liquid AI d1-3B w porównaniu z 8,3 dla Liquid AI d1-omni-600M

• Język — 56,4 wobec 12,9

• Wyszukiwanie — 52,8 wobec 35,0

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

• Sztuka — 36,3 wobec 6,8

Wyszukiwanie to jedyne miejsce, w którym mały model trzyma się mocno, tracąc mniej niż jedną trzecią wyniku 3B, podczas gdy w pozostałych czterech kategoriach traci 60 do 80 procent. Ten wzorzec jest zgodny z tym, czym jest 600M: wytrenowanym enkoderem o rzeczywistej pojemności reprezentacyjnej do dopasowywania stanu do treści i znacznie mniejszym udziałem warstwowej zdolności, którą 3B dziedziczy po dekoderze wstępnie wytrenowanym na znacznie większej ilości języka. Jeśli Twoje obciążenie to decyzja o charakterze wyszukiwania — czy ten fragment odpowiada na to pytanie, który z tych dokumentów jest istotny — profil 600M jest mniej zły, niż sugeruje jego wynik łączny. Jeśli Twoje obciążenie to decyzja o routingu narzędzi, 51-punktowa różnica w tej kolumnie to liczba, na którą warto patrzeć.

Tabela wyników tekstowych opowiada łagodniejszą historię niż indeks, co warto wiedzieć, zanim którakolwiek z tych liczb zostanie użyta do uzasadnienia tezy. Na siedmiu publicznych benchmarkach model 3B prowadzi ze średnią 82,9, a 600M osiąga 78,4. Model 600M faktycznie nieznacznie przegrywa na SQuAD 2.0 (74,0 do 85,3), PubMedQA (61,3 do 66,0), BoolQ (77,7 do 86,7) i XNLI (74,7 do 85,0), ale wygrywa na wykrywaniu toksyczności Civil Comments (95,8 do 93,0) oraz na identyfikacji parafraz PAWS-X (79,5 do 76,9). Liquid sam twierdzi, że 600M bije średnią 77,1 modelu Decider 2B przy jednej czwartej parametrów. Dwa zestawy benchmarków, dwa różne pozorne werdykty, oba raportowane przez producenta — to jest to, co tekst potwierdza, i nic więcej.

Co ma 600M, czego nie ma 3B

Powód, dla którego warto tolerować 32-punktową lukę w indeksie, jest taki, że Liquid AI d1-omni-600M robi jedną rzecz, której Liquid AI d1-3B nie potrafi, i nie jest to różnica w wierności.

• Audio — Liquid AI d1-omni-600M obsługuje do 30 sekund mowy na żądanie dzięki swojemu enkoderowi FastConformer; Liquid AI d1-3B nie obsługuje żadnej

• Mieszanie modalności — model 600M przyjmuje tekst z obrazami lub tekst z dźwiękiem i podnosi ValueError, jeśli oba typy pojawią się razem; model 3B przyjmuje tekst i obrazy

• Okno kontekstu — 16 384 tokeny na pozycje tekstu, obrazu i dźwięku dla modelu 600M, przy czym tekst jest przycinany do 896 tokenów, gdy obecne są obrazy; 32 768 tokenów dla modelu 3B

• Słownik — 65 536 dla 600M, 128 000 dla 3B

• Precyzja — karta modelu 600M zaleca float16 na GPU i ostrzega, że bfloat16 zmienił najlepszą odpowiedź w niektórych wierszach; model 3B jest dostarczany w 15 kwantyzacjach, w tym w wariancie w8a8

• Języki — model 600M wymienia 16 języków w innym zestawie niż 16 modelu 3B, a jego audio jest opisywane jako trenowane na wymianach między osobą mówiącą po angielsku a asystentem, co stanowi wąski wycinek tego, co zawiera produkcyjny strumień audio

Uwagę dotyczącą treningu audio łatwo przeoczyć, a nie powinno się tego robić. Model wytrenowany na angielskich wymianach mówca–asystent widział jedną geometrię mówcy, jedną strukturę tur i jeden rozkład akcentów. Wdrażanie go na nagraniach z centrów obsługi lub nagraniach terenowych to oczekiwanie zachowania, którego karta nie deklaruje, a wpis o wydaniu otwarcie przyznaje, że nie istnieje żaden benchmark decyzji audio, względem którego można by go sprawdzić — Liquid nazywa to „obecnie otwartym problemem” i zaprasza społeczność do zbudowania takiego benchmarku.

Opóźnienie: jedno z rodzeństwa ma tabele, drugie ma przypis.

W przypadku modeli decyzyjnych interesującą liczbą jest opóźnienie end-to-end, ponieważ nie ma dekodowania, którego czas trzeba mierzyć. Liquid publikuje pełny zestaw dla 3B, a dla 600M żadnego.

• Jedno pytanie — 8 ms na RTX 4090, 9 ms na MI325X, 16 ms na Jetson AGX Thor, 26 ms na Jetson AGX Orin 64 GB, 50 ms na Orin Nano, 30 ms na Apple M5 Pro

• Trzy pytania w ramach jednego stanu — 21 ms na RTX 4090 i 20 ms na AGX Thor, około 1,3x kosztu pojedynczego pytania, a nie 3x

• Stan o rozmiarze 3,4K tokenów — 102 ms na 4090, 220 ms na Thor, 1 640 ms na Orin Nano

• Przepustowość w trybie packed — 475 decyzji na sekundę na RTX 4090, 1 106 na sekundę na MI325X

• Obraz 384px — 17 ms na 4090, 18 ms na MI325X

Te liczby opisują wyłącznie Liquid AI d1-3B. W przypadku Liquid AI d1-omni-600M karta modelu podaje, że nie raportuje się wyników wnioskowania, ponieważ model jest wczesnym wydaniem badawczym, które jest aktywnie rozwijane. Nie chodzi o to, że mały model jest wolniejszy — niemal pewne jest, że jest odwrotnie, skoro model o jednej piątej parametrów nie zwalnia przy tej samej precyzji — chodzi o to, że żadna liczba nie istnieje, a przytoczenie milisekund modelu 3B dla modelu 600M byłoby fabrykacją o wiarygodnym kształcie. Co można powiedzieć, nie wymyślając niczego, to że przy zalecanej przez kartę precyzji float16 587 mln parametrów to rzędu 1,2 GB wag przed aktywacjami, co jest arytmetyką na podstawie opublikowanej liczby parametrów, a nie pomiarem.

Kaskada jest prawdziwą odpowiedzią dla większości obciążeń.

Ponieważ oba checkpointy zostały wydane razem i zwracają ten sam rodzaj obiektu — prawdopodobieństwo, etykietę z poziomem ufności lub uporządkowany wynik — komponują się w sposób, w jaki dwa dowolne modele nie potrafią. Model 600M może filtrować wstępnie, a model 3B może rozstrzygać. Oceniaj przychodzące elementy za pomocą Liquid AI d1-omni-600M i eskaluj te, które umieści blisko środka swojej skali, do Liquid AI d1-3B, aby uzyskać dokładniejszą decyzję. Zasady eskalacji opierają się na poziomie ufności i rozkładzie, które 600M już zwraca, więc logika routingu nie wymaga dodatkowego modelu. W przypadku obciążenia z przeważającą większością łatwych elementów większość ruchu nigdy nie dociera do 3B i większość pieniędzy nigdy nie zostaje wydana.

Ten wzorzec to także powód, dla którego warto uruchamiać oba modele za routerem. W OrcaRouter oba działałyby za jednym kluczem API, a ceny katalogowe każdego dostawcy byłyby przekazywane z 0% marży, więc kaskada staje się regułą routingu, a nie drugą integracją, a eskalacja, która zawodzi na poziomie dostawcy, jest ponawiana na modelu zapasowym, zamiast powodować błąd żądania. Automatyczne przełączanie awaryjne ma tu większe znaczenie niż w przypadku ustabilizowanego modelu, ponieważ jedna połowa tej pary to checkpoint, którego zachowanie sam dostawca opisuje jako będące w fazie aktywnego rozwoju.

Nic z tego nie jest twierdzeniem o dostępności, a to rozróżnienie warto przedstawić wprost: otwarte checkpointy d1 nie znajdują się w naszym katalogu. Ścieżka dostawcy polega na pobraniu wag i uruchomieniu ich lokalnie — wsparcie llama.cpp pojawiło się już pierwszego dnia na sprzęcie Apple, AMD, Qualcomm i NVIDIA — albo na uzyskaniu do nich dostępu przez własne API dostawcy i platformy firm trzecich.

Wybieranie za jednym razem

Jeśli potrzebujesz tekstu i obrazów, a odpowiedź musi być trafna, wybierz Liquid AI d1-3B. Ma benchmarki, tabele opóźnień, szerszy kontekst, większy zasób słownictwa i kwantyzacje, a przy tym jest tym elementem pary, który Liquid pozycjonuje jako lidera jakości w swojej klasie rozmiarowej.

Jeśli potrzebujesz mowy na ścieżce decyzyjnej, weź Liquid AI d1-omni-600M, ponieważ jest to jedyna opcja o otwartych wagach w tej rodzinie, która w ogóle przyjmuje dźwięk, i zaakceptuj, że przyjmujesz ją na wyczucie i na podstawie dema, dopóki ktoś nie opublikuje benchmarku decyzji audio albo wstrzymanego splitu wizyjnego.

Jeśli jeszcze nie wiesz, który z nich opisuje twoje obciążenie, zacznij od 3B i mierz zwracaną przez niego pewność. Wyniki cząstkowe są wskazówką: zadanie, które należy do kolumn Narzędzia lub Język, będzie źle obsługiwane przez 600M, podczas gdy coś o charakterze wyszukiwania jest jedynym miejscem, w którym mały checkpoint jest bliżej, niż sugeruje jego całkowity wynik. Rodzina istnieje po to, aby można było wymienić dokładność na mniejszy rozmiar, a ta wymiana jest bezpieczna tylko wtedy, gdy wiesz, którą kolumnę zajmuje twoje zadanie.

Dzięki OrcaRouter oba modele są obsługiwane przez jeden klucz API i regułę routingu zamiast drugiej integracji, a eskalacja, która zawodzi na poziomie dostawcy, jest ponawiana na fallbacku, zamiast kończyć się niepowodzeniem żądania.