LFM3-1.7B na vLLM: dziewięć dni później natywne wsparcie to wciąż dwa otwarte PR-y

Liquid AI LFM3-1.7Bzostał wydany 27 października 2026 r. wraz z kartą modelu, która podaje vllm serve "LiquidAI/LFM3-1.7B" tak, jakby to było zwykłe polecenie. Dziewięć dni później upstream vLLM nie ma architektury Lfm3ForCausalLM, za pomocą której mógłby go uruchomić. Zamiast tego istnieje zgłoszenie funkcji otwarte 30 października, jeden pull request z kernelem, na którym opiera się wszystko inne, oraz sześć otwartych PR-ów modelu — z których dwa implementują ten sam model tekstowy LFM3-1.7B na dwa różne sposoby, a żaden z nich nie został scalony.

Ta luka jest tu całą historią — i jest wąska. Model jest realny i można go pobrać; wsparcie w środowisku uruchomieniowym to kolejka. To tekst typu „co wiemy do tej pory” o tej kolejce: co jest w toku, co faktycznie działa dziś i co musiałoby się pojawić, zanim „works with vLLM” na karcie modelu stanie się prawdą w takim sensie, w jakim potrzebuje tego plan wdrożenia.

Karta podaje vLLM. Tabela obsługiwanych modeli podaje LFM2.

Dokumentacja vLLM dotycząca obsługiwanych modeli wymienia trzy architektury Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM i Lfm2VlForConditionalGeneration. Nie ma wpisu LFM3. Karta modelu LFM3-1.7B stwierdza natomiast, że checkpoint „działa z vLLM, SGLang oraz kompilacjami llama.cpp zgodnymi z LFM3” i podaje polecenie serwowania bez dołączonych flag.

Rozwiązanie tkwi w konfiguracji samego checkpointu. LFM3-1.7B zawiera auto_map wskazujące na dołączony plik modeling_lfm3.py, więc kod po stronie Hugging Face istnieje i klonuje się do loaderów, które zezwalają na zdalny kod. Zgłoszenie śledzące vLLM dotyczące portu, #64645 — „[Feature]: Wsparcie dla modeli LiquidAI LFM3”, otwarte 30 października przez abhijithneilabraham — wprost mówi o konsekwencji: „vLLM nie ma Lfm3ForCausalLM”. Wymieniona alternatywa to furtka awaryjna, z której większość osób ostatecznie skorzysta w tym miesiącu: „Uruchamiaj LFM3 przez zdalny kod checkpointu z backendem Transformers. To oznacza rezygnację z paged attention i pamięci podręcznej stanu konwolucji”.

Ten kompromis warto przedstawić wprost, ponieważ „działa na vLLM” i „działa na backendzie transformers vLLM” to różne produkty. Paged attention to mechanizm, który pozwala vLLM grupować żądania o skrajnie różnej długości bez marnowania pamięci KV; pamięć podręczna stanu konwolucji to ta sama idea zastosowana do warstw krótkiej konwolucji w tej architekturze. Odejmij jedno i drugie, a otrzymasz działający endpoint, który zrezygnował z dwóch powodów, dla których vLLM istnieje. Dla modelu 1.7B obsługiwanego przy niskiej współbieżności może to być akceptowalny weekendowy projekt, ale nie akceptowalny kształt produkcji.

Dlaczego model 1.7B w ogóle wymaga pracy nad kernelami?

LFM3-1.7B nie jest prostym ponownym dostrojeniem rodziny LFM2, którą vLLM już obsługuje. To hybryda o dwudziestu czterech warstwach z trzema typami warstw, a nie dwoma: 13 bramkowanych warstw krótkiej konwolucji, 5 warstw uwagi z przesuwanym oknem o rozmiarze 256 tokenów oraz 6 warstw pełnej uwagi. Konfiguracja checkpointu dokładnie określa geometrię — conv_L_cache: 7, sliding_window: 256, słownik o rozmiarze 128K — a sama lista różnic w zgłoszeniu vLLM dodaje QK RMSNorm, bramkę wyjściową uwagi z sigmoidą dla każdej głowy, normalizację sandwich oraz częściowe RoPE (partial_rotary_factor: 0.5) w warstwach pełnej uwagi, ułożone w tym samym kształcie z zerowym ogonem, którego używa Gemma 4.

Liczbą, która zepsuła port, jest siedem. Krótka konwolucja LFM2 ma szerokość trzech odczepów; LFM3 poszerzył ją do siedmiu. Jądra causal_conv1d w Tritonie z vLLM rozwijają stały zestaw szerokości, a jak ujmuje to zgłoszenie śledzące: „Jądro prefill causal_conv1d w Tritonie rozwija szerokości od 2 do 4, a jądro decode od 2 do 6, więc model o szerokości 7 nie może dziś działać na CUDA”.

Zatem pierwszy PR w stosie wcale nie jest modelem. #64647, „[Kernel] Support width-7 causal conv1d", otwarty 30 października przez abhijithneilabraham, dotyka dwóch plików i 186 dodanych linii: rozszerza kernel prefill z szerokości 2–4 do 2–7, a kernel decode z 2–6 do 2–7, i sprawia, że oba wrappery zgłaszają ValueError dla wszystkiego poza tym zakresem. Sam opis PR-a wyjaśnia, dlaczego odrzucanie ma znaczenie równie duże jak rozszerzenie: przed zmianą „szerszy weight działał bez pasującej gałęzi i zwracał błędne wartości". Cicha korupcja numeryczna to gorsza awaria niż odmowa, a to rodzaj problemu, który ujawnia się tylko na modelu, który akurat wypróbowałeś.

Jedno zastrzeżenie powinno towarzyszyć temu PR-owi. Jego autor otwarcie stwierdza, że nie ma maszyny z CUDA: ścieżka referencyjna na CPU przechodzi 96 testów, jądra Triton sprawdzono za pomocą analizy statycznej AST jąder, a walidację GPU pozostawiono CI. To uczciwe ujawnienie, a nie defekt, ale oznacza, że jedyna zmiana, od której zależy każdy inny PR LFM3, nie została jeszcze sprawdzona na sprzęcie, na którym uruchomi ją większość czytelników.

Dwie implementacje tego samego modelu tekstowego

W ciągu sześciu dni dwie osobne grupy napisały natywne wsparcie LFM3 dla vLLM. Nie są to warianty jednej łatki; to niezależne rozwiązania, które przypadkiem instalują tę samą nazwę architektury.

PR #64959, „[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)”, otwarty 1 listopada przez atmikshetty, jest wariantem zachowawczym: siedem plików, a według własnego opisu ponownie wykorzystuje ShortConv o szerokości 7, Lfm2MLP, mapper wag LFM2 i istniejący proporcjonalny RoPE, nie zmieniając żadnych podstawowych komponentów. Rejestruje model w rejestrze, dodaje go do zestawu testów modeli hybrydowych i tabeli obsługiwanych modeli oraz — co jest przydatne dla każdego, kto go uruchomi — dokumentuje flagi serwowania, z którymi go zweryfikowano: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Jego sekcja walidacji raportuje 324 przechodzące testy jądra na A100-SXM4-40GB w BF16, przechodzące testy rejestru i inicjalizacji oraz porównanie log-prawdopodobieństw z referencją zdalnego kodu Hugging Face.

PR #65826, „[Model] Add LFM3-Text”, otwarty 5 listopada przez paulpak58 — z Liquid AI — jest własną wersją dostawcy: dziesięć plików i 829 dodanych linii, w tym własna klasa konfiguracji w transformers_utils/configs/lfm3.py oraz własny moduł testowy. Został otwarty jako „[Model] Add LFM3” i tego samego dnia zmieniono mu tytuł, gdy rodzinę podzielono na cztery ułożone warstwowo PR-y: #65826 dla tekstu, #65827 dla wizji i języka, #65828 dla audio i #65829 dla omni, każdy zbudowany na poprzednim.

Te dwa nie tyle są w konflikcie, ile biegną równolegle, a dyskusja wyraźnie pokazuje siatkę zależności. W PR dotyczącym kernela paulpak58 napisał 4 listopada: „Mamy własne wewnętrzne PR-y dla modeli LFM3, ale to jest czysty dodatek, który możemy poprzeć”. W społecznościowym PR tekstowym abhijithneilabraham zasugerował, że scalenie może wymagać najpierw scalenia prac Liquid nad transformers — „Uważam, że scalenie tego PR-a wymaga PR-a transformers od @paulpak58” — na co atmikshetty odpowiedział, że Lfm3Config nie jest jeszcze w wydaniu transformers, więc gałąź „ładuje konfigurację przez trust_remote_code z checkpointu, a wykonanie korzysta z natywnego modelu vLLM”. To druga brama, o której większość czytelników nie pomyślała: nawet scalony PR vLLM potrzebuje klasy konfiguracji, która gdzieś jest dostarczana.

Po stronie transformers równoważny PR to #50322, „[Model] LFM3 Family: LFM3-Text”, otwarty 3 listopada i wciąż otwarty, wydzielony z większego PR-a dotyczącego rodziny. Jego własna uwaga na temat konwolucji jest zgodna ze zgłoszeniem w vLLM: krótka konwolucja jest „tylko w torchu w LFM3 (kernele causal_conv1d z Hub obsługują szerokości 2–4, LFM3 używa 7)”.

Wizja-język również jest dublowany. Poza #65827 w Liquid, niezależny PR LFM3-VL (#65450, otwarty 3 listopada) nadal pozostaje otwarty i zależy od społecznościowego PR tekstowego. Tak więc na dzień dzisiejszy mamy sześć otwartych PR-ów LFM3 w dwóch obozach i ani jednego scalonego.

Co faktycznie działa dzisiaj

Odrzućmy spekulacje — praktyczny obraz 5 listopada wygląda tak.

• vLLM, natywnie — niemożliwe w standardowej kompilacji. Brak Lfm3ForCausalLM w rejestrze, brak wiersza LFM3 w tabeli obsługiwanych modeli, a PR, który by go dodał, nie został scalony.

• vLLM, backend transformers — udokumentowany obejście, wykorzystujące dołączony do checkpointu zdalny kod i trust_remote_code. Tracisz paged attention i pamięć podręczną stanu konwolucji; zachowujesz serwer zgodny z OpenAI.

• SGLang — własna ścieżka serwerowa dostawcy. W poście premierowym Liquid liczby przepustowości są mierzone na pojedynczym NVIDIA B300 w BF16 z SGLang, w tym 3,6 miliarda tokenów dziennie przy 1024 równoczesnych żądaniach. vLLM pojawia się w tym poście wyłącznie jako środowisko uruchomieniowe, na którym obsługiwano konkurencyjne modele.

• llama.cpp — karta odnosi się do „kompilacji llama.cpp zgodnych z LFM3”, co jest rzeczywistym kwalifikatorem, a nie szablonowym zapisem; wyniki Liquid na urządzeniu dotyczą llama.cpp w Q4_0 z kontekstem 32K.

• MLX — informacje o wydaniu 0.33.0 oddzielnego projektu vLLM-Metal wymieniają punkty kontrolne LFM3 text MLX, dostępne za flagą --trust-remote-code. To inna baza kodu niż upstream vLLM i nie oznacza wsparcia dla CUDA.

• Hostowane — własne API i playground Liquid. Karta nie podaje cennika, więc kosztu za token nie da się oszacować na podstawie publicznych materiałów.

Dwie liczby stawiają kwestię samodzielnego hostowania we właściwej perspektywie. Wagi są wystarczająco małe, że pamięć nie jest ograniczeniem — Liquid twierdzi, że około 1 GB przy 4 bitach — a dostawca mówi, że kontekst 128K tokenów kosztuje około 1,6 GB pamięci podręcznej KV. Ograniczeniem jest stos serwowania, a nie GPU.

Co by to zmieniło, po kolei?

Łańcuch zależności jest wyjątkowo czysty, co sprawia, że rzecz warta obserwowania jest wyjątkowo konkretna. Najpierw musi zostać scalony #64647, ponieważ każdy inny PR LFM3 albo zawiera ten commit, albo jest na nim oparty. Następnie jeden z dwóch PR-ów tekstowych musi wygrać przegląd — ten społecznościowy ma pełniejszy zapis walidacji, a ten od Liquid ma autora, który odpowiada także za stronę transformers. Potem Lfm3Config musi trafić do wydania transformers, w przeciwnym razie każde wdrożenie nadal będzie przekazywać trust_remote_code. Dopiero po tym LFM3-VL-2B, LFM3-Audio-2B i LFM3-Omni-2B stają się realistyczne, a te są zależne od kolejnych PR-ów, które zakładają, że model tekstowy jest już włączony.

Niczego z tego nie należy odczytywać jako krytyki tempa. Dziewięć dni od premiery do kompletnego, przetestowanego stosu PR-ów obejmującego kernel i model to szybko, a fakt, że dwóm niezależnym zespołom udało się w mniej niż tydzień stworzyć działające implementacje, mówi więcej o tym, jak blisko LFM3 jest LFM2, niż o jakimkolwiek opóźnieniu. Ale karta modelu to deklaracja zgodności, a uczciwe odczytanie dzisiejszej karty LFM3-1.7B brzmi: „zgodny z vLLM przez backend transformers”, a nie „obsługiwany przez vLLM”.

Jeśli w tym tygodniu potrzebujesz małego modelu do wywoływania narzędzi

LFM3-1.7B to kusząca propozycja. Deklarowane przez dostawcę wyniki są mocne dokładnie tam, gdzie małe modele zwykle zawodzą — 71,39 w BFCL V4, 80,36 w ToolSandbox, 96,66 w IFEval, 43,40 w SWE-bench Verified — przy średniej ogólnej 49,37, którą Liquid stawia przed własnym LFM2.5-2.6B z wynikiem 31,55. To oceny samego dostawcy, przeprowadzone przez firmę, która zbudowała model, bez niezależnego odtworzenia i bez wpisu w Artificial Analysis, jakiego udałoby się nam znaleźć na dziś; kolejność traktuj jako hipotezę, a poszczególne liczby jako twierdzenia. Towarzyszące zastrzeżenie pochodzi z tego samego źródła: karta modelu odradza kodowanie agentowe i złożone wieloetapowe rozumowanie, a benchmarki wiedzy potwierdzają tę radę — 63,37 w GPQA Diamond i 65,56 w RULER przy 128K to nie są wyniki generalisty.

Więc decyzja tak naprawdę nie dotyczy modelu. Chodzi o to, czy możesz sobie pozwolić na budowanie na ścieżce serwowania, która obecnie jest otwartym pull requestem. Jeśli możesz uruchomić SGLang lub llama.cpp, możesz używać LFM3-1.7B już dziś, a kwestia vLLM ma charakter akademicki. Jeśli Twój stack to vLLM z założenia, wybierasz między brakiem paged attention w backendzie transformers a czekaniem.

Istnieje trzecia opcja warta wymienienia w przypadku obciążeń, które nie mogą czekać: skierować je gdzie indziej. OrcaRouter nie obsługuje LFM3-1.7B — sprawdzenie naszego katalogu na dziś zwraca ponad 200 identyfikatorów modeli i żaden z nich nie należy do Liquid — więc to nie jest zachęta, by wywoływać go przez nas. Chodzi o prostszą kwestię: niezmergowany PR do jądra to zły pojedynczy punkt awarii dla ścieżki produkcyjnej. Wystawienie hostowanego modelu za jednym API i z automatycznym przełączaniem awaryjnym kosztuje tylko zmianę konfiguracji i pozwala podmienić LFM3-1.7B w dniu, w którym zostanie zmergowane jego natywne wsparcie, a nie w dniu, w którym skończysz na niego stawiać. Jeśli modyfikujesz model, a nie tylko go wywołujesz, nasze własne wydanie LFM3-1.7B-abliterated jest ablacją kierunku odmowy tego samego checkpointu i dziedziczy dokładnie tę sytuację serwowania.

Krótka wersja

LFM3-1.7B jest już dostępny, mały i dobrze nadaje się do jednoturowych zadań wywoływania narzędzi, do których został wytrenowany. Jego obsługa vLLM jest właśnie tworzona przez dwa zespoły, na bazie rozszerzenia jądra, którego autor jeszcze nie uruchomił na CUDA. Najpierw śledź #64647 — gdy splot o szerokości 7 zostanie scalony, reszta stosu ruszy szybko, a „działa z vLLM” na karcie modelu przestanie być stwierdzeniem o zdalnym kodzie, a zacznie być stwierdzeniem o uwadze stronicowanej i grupowaniu wsadów. Do tego czasu każdy, kto cytuje „obsługę vLLM od pierwszego dnia” dla tego modelu, cytuje coś, czego repozytorium jeszcze nie zawiera.