Liquid AI d1-omni-600M jest już dostępny do pobrania przez Ollama: model decyzyjny 600M, który potrafi Cię usłyszeć

Liquid AI d1-omni-600M stał się pakietem Ollama o 22:32 UTC 17 października 2026. Ten znacznik czasu nie jest domysłem: rejestr Ollama zwraca nagłówek ollama-push-time przy każdym manifeście, a cztery tagi stojące za nazwą d1-omni zostały przyjęte między 22:31:25 a 22:32:13 tego wieczoru, około czterech godzin przed napisaniem tego tekstu. Sam model nie jest nowy — Liquid AI udostępniło na otwartej licencji wagi Liquid AI d1-omni-600M wraz z Liquid AI d1-3B 5 października 2026 i zapowiedziało oba w swoim wpisie „Open d1” 7 października — ale do zeszłej nocy jedynymi sposobami uruchomienia tego obsługującego dźwięk modelu na własnym sprzęcie było środowisko transformers z trust_remote_code=True albo samodzielnie skompilowana wersja llama.cpp. Teraz to ollama pull d1-omni. Nikt tego nie ogłosił: ani blog Liquid AI, ani Ollama.

Opakowanie to cała historia i warto precyzyjnie wskazać, które jego części są udokumentowane. Najnowsze wpisy na blogu Liquid AI to d1-ultra z 15 października i LFM2.5-24B-A2B z 13 października, a żaden z nich nie wspomina o Ollama; własna strona laboratorium poświęcona wdrożeniom w Ollama wciąż uczy uruchamiania jego repozytoriów GGUF bezpośrednio z Hugging Face za pomocą ollama run hf.co/LiquidAI/... i nigdy nie wymienia żadnego modelu d1. Blog Ollama milczy równie wymownie — jego najnowsze wpisy to Reflection's Beam z 16 października i integracja z Fly.io z 13 października. Zamiast tego istnieje wpis w rejestrze, cztery tagi, weryfikowalny skrót i strona biblioteki, która wciąż była tworzona, gdy pisano ten artykuł: wczesne przechwycenie tej strony zwróciło „No readme”, a przechwycenie czterdzieści minut później zwróciło pełny opis napisany przez Liquid AI, z tabelą benchmarków i sekcją licencji. Jeśli chcesz mieć datowane, możliwe do sprawdzenia wydarzenie z ostatnich siedmiu dni, to właśnie ten nagłówek nim jest.

Co rejestr faktycznie zaakceptował

Cztery tagi wskazują na dwa obrazy — to pierwsza rzecz, którą trzeba zrozumieć przed pobraniem. d1-omni:latest, d1-omni:600m i d1-omni:600m-q8_0 to ten sam manifest — digest 1ba59f63e836 — natomiast d1-omni:600m-bf16 to drugi, digest c1e95fce6627. Nie ma tagu F16, choć repozytorium GGUF samego dostawcy publikuje gałąź F16.

• Warstwy wag (wersja Q8_0) — 407 MB rdzenia z d1-omni-600M-Q8_0.gguf plus 442 MB projektora z mmproj-d1-omni-600M-BF16.gguf, z 10,5 KB bloba licencyjnego i 18-bajtowym blobem parametrów, co daje łącznie 849 659 968 bajtów.

• Podany rozmiar — 850 MB dla domyślnego tagu i 1,2 GB dla 600m-bf16, oba tak, jak podano na stronie biblioteki.

• Minimalna wersja środowiska uruchomieniowego — wymaga: 0.40.4 w bloku konfiguracji, który dodatkowo zgłasza model_family: lfm2, model_type: 380.73M oraz typ pliku Q8_0.

• Kontekst — blob parametrów ustala num_ctx na 16 384.

• Licencja — osadzony tekst to LFM Open License v1.0, wskazujący Liquid AI, Inc. jako licencjodawcę, zgodny z identyfikatorem lfm1.0 na karcie modelu.

Ten projektor zasługuje na drugie spojrzenie, ponieważ jest większy niż model, do którego został dołączony. Odczyt metadanych GGUF bezpośrednio z bloba rejestru pokazuje, że clip.has_vision_encoder = True i clip.has_audio_encoder = True w tym samym pliku: 197 tensorów wizji w 12 blokach przy osadzeniach o szerokości 768 i wejściach 256-pikselowych oraz 641 tensorów audio w 17 blokach przy osadzeniach o szerokości 512 ze 128 binami mel. To wieża SigLIP2 i enkoder FastConformer podróżujące razem w multimodalnym pakiecie, dlatego pień o 381 mln parametrów jest dostarczany za załącznikiem o rozmiarze 442 MB. Możliwość audio jest fizycznie w pakiecie, który pobierasz; kwestia, czy endpoint może do niej dotrzeć, pojawia się później.

Model ma 587M parametrów, a plakietka 125K jest większa niż prawda.

Strona Ollama reklamuje „okno kontekstu 125K” na każdym tagu. Własne num_ctx pakietu wynosi 16,384, a karta modelu Liquid AI mówi to samo słowami: 16,384 tokenów obejmujących łącznie pozycje tekstowe, obrazowe i audio, przy czym tekst stanu i pytania jest przycinany do 896 tokenów, gdy tylko obecne są obrazy. Liczbę 125K można prześledzić — główny plik GGUF zawiera lfm2.context_length = 128000 — ale to pułap architektury, a nie okno, które otrzymujesz, i jest to liczba, która najprawdopodobniej wprowadzi w błąd kogoś, kto dobiera zamiennik dla klasyfikatora długiego kontekstu. Przyjmij 16,384 jako roboczą wartość, a 896 tokenów tekstu jako roboczą wartość, gdy w stanie znajduje się obraz.

Reszta metadanych potwierdza kartę modelu, a nie slogan marketingowy. Trzon to 18 bloków, embeddingi o szerokości 1024 i słownik 65 536 tokenów, i nie jest to dekoder: lfm2.attention.causal ma wartość False. Liczby głowic KV w poszczególnych warstwach wynoszą 0, 0, 8, 0, 0, 8, …, co oznacza, że większość tych bloków wcale nie jest blokami uwagi — to prześwituje dziedzictwo dwukierunkowego enkodera. Głowa decyzyjna to dwa bloki (lfm2.decision.block_count = 2), a stałe kalibracyjne, które dostawca trzyma w config.json, są także w tym GGUF — pytania wyboru mają temperaturę 1,7465 przy dwóch opcjach, 1,3999 przy trzech do pięciu, 1,1751 przy sześciu do dziesięciu i 1,3725 powyżej jedenastu; tak/nie to 1,6663; pytania punktowane to 1,7301 przy trzech do pięciu poziomów i 1,0 przy sześciu do dziesięciu. To cały projekt w jednym miejscu: stały zestaw nazwanych odpowiedzi, punktowanych w jednym przebiegu, kalibrowanych według kształtu pytania, z output_tokens: 0 na końcu.

To nie jest model konwersacyjny i nie pisze tekstu. Liquid AI wymienia piętnaście języków, a dane treningowe audio podaje wyłącznie w języku angielskim — żądania między mówiącym a asystentem — i ogranicza długość klipów do 30 sekund. Karta ostrzega również przed bfloat16 na GPU: w testach przeprowadzonych przez samego dostawcę zmieniło ono najlepszą odpowiedź w 0,8% wierszy tekstowych i 1,7% wierszy audio, podczas gdy float16 we wszystkich przypadkach zgadzał się z float32.

Audio znajduje się w wagach, ale nie występuje w udokumentowanym API.

To rozbieżność, o której warto wiedzieć, zanim zgłosisz błąd. README na stronie biblioteki, napisany przez Liquid AI, dokumentuje audio, umieszczając WAV w base64 wewnątrz tablicy images żądania /v1/systemone. README GGUF dostawcy na Hugging Face dla tego samego checkpointu dokumentuje to inaczej: tablica files przenosi data:audio/wav;base64,… do serwera llama.cpp. A publikowany przez Ollamę opis referencyjny endpointu nie dokumentuje żadnej z tych dwóch metod: jej schemat żądania zawiera state, images, questions i keep_alive, opisuje images jako „Wymaga modelu z obsługą wizji, takiego jak Clef” i nie zawiera w ogóle pola audio ani pola files. Tymczasem własny przewodnik Ollamy po modelach decyzyjnych wymienia Nimble, Tev1, Clef i Clef Flash jako modele decyzyjne i mówi jedynie, że modele Clef mogą również oceniać obrazy.

Uczciwe stanowisko w sprawie dźwięku w Ollama wygląda dziś tak: potwierdzono, że enkoder jest obecny w blobie, README dostawcy mówi, że działa on poprzez obrazy, a opublikowany schemat go nie dopuszcza. Wejście obrazowe w tym samym modelu ma mocniejsze podstawy — widzenie to udokumentowana funkcja System One, a d1-omni pojawia się w wykazie kategorii widzenia Ollama. Obok tej luki istnieją dwie mniejsze luki dokumentacyjne: dokumentacja referencyjna endpointu dopuszcza do 255 kluczy opcji w pytaniu wyboru, podczas gdy przewodnik decyzyjny podaje od 2 do 26, a minimalna wersja środowiska uruchomieniowego pakietu 0.40.4 jest wyższa niż 0.35.0 podawana w dokumentacji endpointu.

Zaklasyfikowane jako wizja, a nie jako decyzja.

Wyszukiwarka modeli Ollama wydziela modele decyzyjne do osobnej kategorii. Zawiera ona dziewięć pozycji — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya i strands-decider — a ani d1, ani d1-omni nie znajduje się wśród nich. Strona d1-omni jest oznaczona tagami vision i 600m i pojawia się na liście modeli vision, więc czytelnik szukający „modelu decyzyjnego” nie znajdzie najnowszego. To problem odnajdywalności, a nie możliwości, ale ma to znaczenie, jeśli planowałeś porównać rodziny modeli decyzyjnych we własnym katalogu Ollama i doszedłeś do wniosku, że ten model nie istnieje.

Oznacza to również, że d1-omni jest pierwszym modelem decyzyjnym w bibliotece Ollama, który w ogóle potrafi przyjmować mowę — koder audio znajduje się w pakiecie i żaden inny model z tej dziewięciomodelowej listy go nie ma. Otwartym pytaniem z powyższej sekcji pozostaje, czy endpoint przekaże mu Twój plik WAV, i to jest ta jedna rzecz, która najprawdopodobniej zmieni się do czasu, gdy to przeczytasz.

Liczby i kto wyprodukował każdą z nich

Każda wartość dokładności przypisana do Liquid AI d1-omni-600M należy do Liquid AI i o ile możemy ustalić, nie istnieje żadna niezależna ocena jakiegokolwiek modelu d1 — żaden wiersz na leaderboardzie, żaden przebieg prowadzony przez stronę trzecią, żadne opublikowane odrzucenie sposobu punktowania przez dostawcę. Dostawca sam ocenił oba checkpointy d1 za pomocą oficjalnego skryptu Decision Index, zamiast zgłaszać je do publicznego leaderboardu, i mówi o tym na karcie; każdy konkurencyjny wiersz w jego tabeli pochodzi z leaderboardu v0.2.1, co oznacza, że porównanie to liczba oceniona przez samego dostawcę zestawiona z liczbami ocenionymi zewnętrznie.

• Decision Index 0.2.1 — 15,95 dla d1-omni-600M (wiedza 8,3, język 12,9, wyszukiwanie 35,0, narzędzia 15,1, sztuka 6,8) wobec 48,57 dla d1-3B.

Benchmarki jako decyzje, średnia z siedmiu — 78,4 dla d1-omni-600M wobec 82,9 dla d1-3B, przy czym model 600M prowadzi w Civil Comments (95,8 vs 93,0) i PAWS-X (79,5 vs 76,9), a pozostaje w tyle w BoolQ (77,7 vs 86,7) i SQuAD 2.0 (74,0 vs 85,3).

• Fast Decisions, podział dev — 76.9, dane zgłoszone przez dostawcę, brak opublikowanego wiersza porównawczego.

• Szybkość — nic. Karta wyraźnie stwierdza, że liczby dotyczące wnioskowania nie są podawane, ponieważ jest to wczesne wydanie badawcze w trakcie aktywnego rozwoju, więc każda wzmianka o opóźnieniach, jaką zobaczysz gdzie indziej, to czyjś własny pomiar.

• Numery fixture na stronie Ollama — przykład w readme pokazuje urgent z odpowiedzią 0,998 i technical z 0,995. To są ilustracyjne wyniki jednego żądania, opublikowane przez runtime, i nie stanowią benchmarku.

Różnica między 15.95 a 48.57 jest najużyteczniejszą rzeczą na karcie, ponieważ rozstrzyga kwestię zakupu słowami samego dostawcy: README każe używać d1, gdy liczy się dokładność w przypadku tekstu i obrazów, a po d1-omni sięgać, gdy liczy się rozmiar lub potrzebujesz audio. Model 587M, który uzyskuje 78.4 w siedmiu publicznych benchmarkach, przełożony na decyzje, to wiarygodny klasyfikator brzegowy. To nie jest mniejsza wersja modelu 3B.

Gdzie OrcaRouter pasuje, a gdzie nie

Nie obsługujemy tego modelu. Sprawdzenie naszego katalogu 18 października zwróciło 208 identyfikatorów modeli i żaden z nich nie pochodzi od Liquid AI, więc nic tutaj nie jest twierdzeniem o dostępności i nie mamy po naszej stronie żadnej ścieżki, by go pobrać. Jeśli chcesz Liquid AI d1-omni-600M, ścieżka lokalna to ta opisana powyżej, a ścieżka hostowana to własne API dostawcy i cokolwiek przejmą z niego platformy zewnętrzne.

To, co zmienia pakowanie, to kształt systemu wokół niego, i właśnie tam jesteśmy przydatni. Model decyzyjny prawie nigdy nie jest całym pipeline'em: zgłoszenie, które etykietuje, klatka, którą oznacza, i transkrypcja, którą kieruje, nadal wymagają odpowiedzi, podsumowania lub eskalacji przez coś, co pisze tekst. Te wywołania generatywne są realizowane za pośrednictwem jednego klucza zgodnego z OpenAI dla ponad 200 hostowanych modeli w cenie katalogowej dostawcy, przekazywanej z marżą 0%, więc zmiana ceny u dostawcy dociera do Ciebie tego samego dnia, a nie dopiero wraz z nową umową. A ponieważ d1-omni-600M jest dostarczany bez niezależnych dowodów na dokładność i bez publikowanych opóźnień, właściwym sposobem wystawienia go na rzeczywisty ruch jest oparcie się na automatycznym przełączaniu awaryjnym między dostawcami — pozwól mu obsługiwać wywołania, których jest pewien, a gdy nie jest, zachowaj drogę wyjścia, zamiast czynić z 587M parametrów pojedynczy punkt awarii dla Twojego etapu triażu. Decyzja pozostaje lokalna; mechanizm awaryjny nie musi.

Co zmieniłoby ten odczyt?

Cztery rzeczy, z których każda zamieniłaby notatkę o pakowaniu w inny artykuł. Ollama dokumentująca obsługę dźwięku w schemacie żądania System One, co zamieniłoby sztuczkę z WAV w obrazach z readme w obsługiwane wejście i uczyniło to pierwszym modelem decyzyjnym obsługującym mowę, który można uruchomić jednym poleceniem. Uznanie portu przez którąkolwiek z firm — Liquid AI dodająca d1-omni do strony Ollama w swojej dokumentacji wdrożeniowej albo Ollama wymieniająca go w sekcji modeli decyzyjnych zamiast w sekcji wizji. Jakikolwiek pomiar szybkości od kogokolwiek, dostawcy lub nie, ponieważ dziś nie istnieje żaden. Oraz niezależny wiersz Decision Index dla dowolnego modelu d1, który pozostaje jedynym brakującym elementem w całej rodzinie.

Do tego czasu decyzja jest prosta. Jeśli masz już Ollama w wersji 0.40.4 lub nowszej, pobranie to jedna komenda, plik do pobrania ma 850 MB, a otrzymujesz klasyfikator 587M, który odpowiada na wpisywane pytania w jednym przebiegu w przód po tekście i obrazach — a jeśli wierzyć readme, również na podstawie ponad 30 sekund angielskiej mowy. Jeśli twój stan jest długi, pamiętaj raczej o oknie 16 384 tokenów i budżecie 896 tokenów na tekst niż o plakietce 125K. A jeśli potrzebujesz dowodów, że jest dokładny, zanim oznaczy cokolwiek, co zobaczy klient, takie dowody jeszcze nie istnieją — ani dla tego modelu, ani dla żadnego z jego modeli siostrzanych.

Udokumentowane awarie AI i incydenty z agentami stojące za takimi wydaniami jak to są gromadzone w OrcaRouter AI Incident Archive, gdzie każdy wpis zawiera własne źródła, poziom istotności, stopień pewności i znacznik sporności.