Przeciek LFM3: Następna rodzina Liquid AI to cztery małe modele omni

Pull request otwarty na GitHubie 27 października 2026 r. chce nauczyć SGLang obsługi rodziny modeli, która nie jest publicznie dostępna. Wymienia cztery checkpointy — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B i LFM3-Omni-2B — a w zestawieniu z wydanymi LFM2.5-2.6B i LFM2.5-24B-A2B czyta się jak plan tego, co Liquid AI zbuduje następnie. PR nie został scalony. Wszystkie trzy kontrole CI nie przechodzą. Liquid AI nie zapowiedziało nic z tego. Ten niescalony diff to cały publiczny zapis LFM3 na dziś i jest bardziej informacyjny niż większość postów premierowych — pod warunkiem że czyta się go jako to, czym jest.

Bądźmy więc precyzyjni co do dowodów, ponieważ są one skąpe pod jednym względem, a nietypowo szczegółowe pod innym. Nie ma tu daty wydania, ceny, warunku licencji ani wyniku benchmarku. Nie ma karty modelu LFM3, repozytorium Hugging Face, wpisu na blogu ani pozycji w API. Istnieje natomiast wkład tugot17 — Piotra Mazurka, który w ciągu ostatnich dwóch miesięcy wprowadził obsługę środowiska uruchomieniowego LFM w SGLang, llama.cpp i mlx-vlm — oraz własne opublikowane materiały Liquid na temat generacji LFM2.5, którą ma ona wkrótce zastąpić. Wszystko poniżej jest odpowiednio oznaczone.

Co pull request faktycznie stawia na stole

Tytuł PR to [Feat] lfm3: Dodanie obsługi tekstu, obrazu, dźwięku i Omni, a do tego ma dwie etykiety, które mówią, jakiego rodzaju to zmiana: jit-kernel i Multi-modal. Dodaje natywne generowanie tekstu dla rodziny czterech modeli, z których każdy ma własną ścieżkę checkpointu:

• LFM3-1.7B — tekst na wejściu, tekst na wyjściu, zwykły model językowy stanowiący podstawę rodziny

• LFM3-VL-2B — tekst, obrazy i wideo na wejściu, tekst na wyjściu

• LFM3-Audio-2B — tekst i audio na wejściu, tekst na wyjściu, a także podłączony do punktu końcowego /v1/audio/transcriptions

• LFM3-Omni-2B — tekst, obrazy, dźwięk i wideo na wejściu, w tym własna ścieżka dźwiękowa wideo, tekst na wyjściu

Jeden szczegół na tej liście zasługuje na chwilę uwagi. Każdy wariant zwraca tekst. W całym PR nie ma żadnej ścieżki wyjścia audio, a pozaczatowe zastosowanie modelu audio to transkrypcja — mowa na wejściu, tekst na wyjściu. To węższy zakres niż obecna linia audio Liquid, gdzie LFM2.5-Audio-1.5B jest opisany jako obsługujący ASR, TTS i przeplatany czat głosowy w jednym modelu. Albo pierwsze wydanie SGLang obejmuje tylko tę połowę LFM3-Audio, która generuje tekst, albo rodzina omni faktycznie rezygnuje z syntezy mowy. PR nie rozstrzyga, która z tych możliwości jest prawdziwa, a każdy, kto twierdzi, że rozstrzyga, zgaduje. Traktuj „LFM3 mówi” jako nieudowodnione.

Reszta diffa to szczegóły implementacyjne, które mimo to pozwalają datować tę pracę. Enkodery wizji i dźwięku wraz z ich projektorami, wspólny backbone, integracja hybrydowej pamięci podręcznej, jądra splotowe CuTe DSL z fallbackiem do PyTorch oraz uwaga, że FlashInfer domyślnie korzysta z paged prefill, dzięki czemu sliding-window attention działa poprawnie. Walidacja została przeprowadzona na H100 w FP16 z użyciem tego, co opis nazywa checkpointami deweloperskimi — cztery słowa, które będą miały znaczenie później.

Zdanie o architekturze i liczba, którą ludzie błędnie odczytają

PR opisuje LFM3 jako wspólny szkielet bramkowanych krótkich konwolucji z pełną uwagą i uwagą z przesuwanym oknem. To kontynuacja linii LFM2, a nie jej zastąpienie: LFM2.5-24B-A2B jest udokumentowany jako hybryda bramkowanych krótkich konwolucji i uwagi z grupowanymi zapytaniami w 40 warstwach. Nowością, która wydaje się pojawiać w przecieku, jest wyraźny komponent przesuwanego okna współistniejący z pełną uwagą.

Notatki walidacyjne wspominają o prompcie wykraczającym poza 256-tokenowe okno przesuwne i to właśnie ta liczba będzie przez cały tydzień cytowana bez kontekstu. To nie jest długość kontekstu LFM3. W konstrukcji hybrydowej warstwy uwagi muszą patrzeć tylko lokalnie, ponieważ warstwy konwolucyjne przenoszą sygnał dalekiego zasięgu — na tym opiera się cała idea tej architektury i dlatego rodzina modeli może utrzymać kontekst 131 072 tokenów w LFM2.5-24B-A2B, podczas gdy większość jej warstw wcale nie wykonuje uwagi kwadratowej. Okno uwagi o długości 256 tokenów mówi o tym, gdzie model patrzy wewnątrz jednej warstwy, a nie o tym, ile tekstu może przyjąć. PR nie podaje całkowitej długości kontekstu LFM3 i nikt spoza Liquid jeszcze jej nie zna.

Dlaczego pull request dotyczący środowiska uruchomieniowego jest sygnałem, a nie szumem

Rozsądnie jest podchodzić z podejrzliwością do odczytywania strategii produktu z diffa infrastruktury. W tym konkretnym przypadku wzorzec jest zbyt spójny, by go ignorować, ponieważ Liquid dostarcza wsparcie silników wraz z wagami, a nie po nich. LFM2.5-2.6B wymienia llama.cpp, MLX, vLLM, SGLang, ONNX i Transformers 5.0+ jako platformy docelowe od pierwszego dnia. LFM2.5-24B-A2B był obsługiwany w llama.cpp, MLX, vLLM, SGLang i ONNX już w momencie premiery. Rodzina, która pojawia się z pięcioma gotowymi środowiskami uruchomieniowymi, musi mieć swoje jądra napisane przed ogłoszeniem, co oznacza, że PR-y trafiają najpierw, a wpis na blogu pojawia się później.

Autor idealnie wpisuje się w tę chronologię. Publiczna historia Mazurka to ciąg prac integracyjnych nad LFM: spekulatywne dekodowanie DSpark dla LFM2-VL w SGLang we wrześniu, poprawki modelu szkicowego LFM2.5-VL-3B i DSpark w llama.cpp w tym samym miesiącu, spekulatywne dekodowanie odziedziczone po modelu tekstowym w mlx-vlm oraz ponowne wykorzystanie konfiguracji LFM2-MoE w SGLang 13 października. LFM3 to kolejny wpis w tej sekwencji, zgłoszony w weekend, w którym rodzina zmieniła nazwę.

Dwie nieobecności mówią tyle samo co obecność. Brak pasującego pull requesta w Hugging Face Transformers dla LFM3 — wyszukiwanie w tym repozytorium nic nie zwraca — a PR w SGLang wczytuje swoje checkpointy przez standardowe Transformers 5.19.0 z --trust-remote-code, co robi się, gdy architektura nie jest jeszcze natywna dla biblioteki. Jest też commit, który wprost odrzuca dekodowanie spekulatywne dla LFM3, więc prace DSpark, które trafiły do generacji 2.5, nie zostały jeszcze przeniesione. Wcześnie i z założenia niekompletne.

Pytanie o rozmiar, na które nikt nie odpowiedział

Tutaj przeciek i deklarowana ambicja ciągną w przeciwnych kierunkach, a ta sprzeczność jest najciekawszym elementem dokumentu.

Maxime Labonne, szef ds. pretreningu w Liquid, opisał cel LFM3 jako sprawdzenie, czy podejście oparte na krótkich splotach, które sprawdza się w skali od 350M do 1,2B, może się utrzymać powyżej 10B parametrów — w reżimie, w którym architektury oparte na atencji historycznie miały przewagę. To kwestia skalowania i implikuje duży model.

Wyciekłe checkpointy to jeden 1,7B i trzy po 2B. Żaden z nich nie przekracza progu, którego dotyczy to pytanie.

Utrzymują się dwie interpretacje. Pierwsza mówi, że to kompaktowa pierwsza fala — rodzina omni dla telefonów i samochodów, zanim pojawi się większe rodzeństwo, co pasuje do tego, że Liquid zawsze zaczynał od małych modeli, oraz do sposobu, w jaki PR opisuje je jako punkty kontrolne rozwoju, a nie finalne wydania. Druga mówi, że 1.7B i 2B to po prostu rozmiary wygodne do walidacji kernelów i nie mówią nam nic o tym, co zostanie wydane. Uczciwe stanowisko jest takie, że wyciek dowodzi istnienia rodziny i dowodzi jej kształtu; nie dowodzi jednak jej górnego pułapu. Jeśli czekasz na model Liquid o rozmiarze >10B, ten PR ani go nie obiecuje, ani go nie wyklucza.

Co LFM3 dziedziczy, na dobre i na złe

Poziom odniesienia, który musi pobić, jest świeży i dobrze udokumentowany. LFM2.5-24B-A2B został wydany 13 października 2026 r.; ma łącznie 24B parametrów, z czego 2B aktywnych, 40 warstw, 64 ekspertów i routing top-4, kontekst 131 072 tokenów, słownik 128K oraz 33T tokenów pretreningowych. LFM2.5-2.6B z początku sierpnia mieści się w mniej niż 2,5 GB przy kontekście 128K. LFM2.5-VL-3B łączy bazę 2.6B z enkoderem wizyjnym SigLIP2.

Warto powiedzieć wprost: każdy benchmark, który Liquid publikuje dla tych modeli, jest przeprowadzany przez dostawcę na własnych środowiskach testowych Liquid, bez dołączonej niezależnej oceny. Główne liczby LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — to wyniki Liquida, a ta sama tabela pokazuje, że przegrywa on z Qwen3.6-35B-A3B w WebArena Verified (26.75 wobec 37.62), GPQA Diamond i SWE-Bench Verified. Tabele dostawców, które uwzględniają porażki, są bardziej wiarygodne niż te, które tego nie robią, ale wiarygodny to nie to samo co zweryfikowany. Nie istnieje jakakolwiek liczba LFM3, więc nie ma jeszcze czego porównywać.

Licencjonowanie również będzie obowiązywać w przyszłości. Najnowsze checkpointy LFM firmy Liquid w Hugging Face są każde oznaczone jako license: other — dedykowana licencja LFM, a nie Apache-2.0 ani MIT. Niezależnie od tego, na jakiej licencji zostanie udostępniony LFM3, zakładaj te same niestandardowe warunki, dopóki karta modelu nie stwierdzi inaczej, i przeczytaj je, zanim zbudujesz produkt na wagach.

Kiedy to może faktycznie nastąpić

Nikt nie zna daty, w tym osoby, które zgadują zawodowo. Pytanie na Manifold Markets o to, kiedy LiquidAI LFM3 zostanie wydany, wskazuje Q4 2026 na 40%, Q1 2027 na 21%, Q2 2027 na 21%, Q3 2026 na 11% i Q2 2026 na 7% — przy całkowitym wolumenie około Ṁ160, który jest wystarczająco mały, by odsetki odzwierciedlały garstkę traderów, a nie konsensus. Odczytuj to jako „gdzieś w ciągu najbliższych dwóch kwartałów, prawdopodobnie” i nie dokładniej niż to.

Mechanika przemawia za tym, żeby zrobić to raczej wcześniej niż później. Praca nad kernelami wchodząca do dużego runtime’u to inżynieria późnego, a nie wczesnego etapu — nie pisze się kernelów konwolucyjnych CuTe ani nie podłącza hybrydowego cache’u dla modelu, który pojawi się dopiero za rok. Nazwa rodziny ustabilizowała się na LFM3 w czterech wariantach i czterech ścieżkach checkpointów. Ale PR pozostaje niezmergowany, wszystkie trzy kontrole są czerwone, wymaga zatwierdzającej recenzji, której nie ma, a 2 z 22 kontroli walidacji omni i 2 z 16 kontroli wizji nadal nie przechodzą porównania ROUGE. To gałąź w trakcie prac, a nie kandydat do wydania.

Co to oznacza, jeśli w tym tygodniu wybierasz model

Nic w kwestii LFM3 nie powinno zmieniać decyzji, którą podejmujesz dziś. Nie jest publicznie dostępny, nie ma ceny, publicznych benchmarków ani publicznej licencji. Jeśli potrzebujesz teraz małego modelu multimodalnego, prawdziwą odpowiedzią jest generacja LFM2.5, a jej ograniczenia — wyniki podawane przez dostawcę, niestandardowa licencja oraz profil kodowania, który zarówno własne tabele Liquid, jak i zewnętrzne omówienia wskazują jako słaby punkt — to właśnie to, co należy rozważyć.

To, do czego przeciek jest naprawdę przydatny, to planowanie. Mówi, że nadchodzi kompaktowa rodzina omni, że prawdopodobnie pojawi się w kilku środowiskach uruchomieniowych jednocześnie i że jej wariant audio może nie syntezować mowy. Jeśli twoja mapa drogowa zakładała, że następnym krokiem Liquid będzie większy model tekstowy, dotychczasowe dowody nie potwierdzają tego założenia.

Fragmentacja środowiska wykonawczego to praktyczny problem, który ta rodzina stworzy. Przyzwyczajenie Liquid do jednoczesnego dostarczania do llama.cpp, MLX, vLLM, SGLang i ONNX jest dobre dla przenośności i niewygodne dla każdego, kto chce jednego punktu końcowego: pięć silników oznacza pięć kształtów wdrożenia, pięć zestawów osobliwości przetwarzania wstępnego i pięć różnych terminów, w których pojawia się poprawka. OrcaRouter ma katalog ponad 200 modeli, który nie zawiera dziś ani jednego checkpointu LFM, więc nie ma sposobu, by wywołać przez niego LFM3, i niczego tutaj nie należy odczytywać jako obietnicy, że tak będzie. Do czego warstwa routingu faktycznie służy w tej sytuacji, to styk między niesprawdzonym modelem a ścieżką produkcyjną — wysłanie części ruchu do czegoś nowego, podczas gdy znany model pozostaje za nim, a przełączanie awaryjne wychwytuje lukę, to sposób oceny następcy niewydanej rodziny bez stawiania funkcji skierowanej do klienta na 40-procentowym rynku predykcyjnym.

Otwarte pytania, na które warto zwrócić uwagę

Cztery rzeczy rozstrzygną to szybciej niż jakiekolwiek dalsze spekulacje. Czy cztery ścieżki checkpointów staną się rzeczywistymi, możliwymi do pobrania repozytoriami Hugging Face — obecnie wyszukiwanie w organizacji LiquidAI nie zwraca nic pod LFM3, a repozytoria wymienione w PR nie są publicznie dostępne. Czy pojawi się PR do Transformers, co sygnalizowałoby, że architektura jest właściwie wdrażana do upstreamu, a nie uruchamiana przez zdalny kod. Czy nieudane kontrole walidacji zostaną zamknięte, ponieważ 2 z 22 niepowodzeń omni to różnica między demem a mergem. I czy pojawi się członek rodziny o rozmiarze >10B, co jest pytaniem, na które — według Labonne — LFM3 ma odpowiedzieć.

Do tego czasu najprecyzyjniejszym zdaniem, jakie ktokolwiek może napisać o LFM3, pozostaje to, od którego zaczął się ten artykuł: istnieje pull request, nie został scalony i wymienia cztery małe modele omni, których Liquid AI nie ogłosiło. To realny sygnał — tyle że wczesny, a wczesne sygnały należy odczytywać dokładnie jako takie.