Liquid AI LFM2.5-VL-3B-DSpark przyspiesza dekodowanie wizji, ale nagłówek 3,13x mówi tylko połowę prawdy
Liquid AI udostępniło LFM2.5-VL-3B-DSpark, deklarując nawet 3,13-krotne przyspieszenie dekodowania dla swojego kompaktowego modelu wizyjno-językowego. Ulepszenie dotyczy generowania tokenów, a nie całego procesu rozumienia obrazu i tworzenia odpowiedzi.
To rozróżnienie określa znaczenie Liquid AI LFM2.5-VL-3B-DSpark. Eksperymentalny model szkicujący pokazuje, że dekodowanie spekulacyjne może działać w zadaniach wizualnych i tekstowych zarówno na sprzęcie centrów danych, jak i konsumenckim. Jednak własne wyniki Liquid AI wskazują, że najlepszy zysk typu end-to-end wynosi 2,62x, czyli mniej niż szczytowa wartość dla dekodowania.
Premiera skłania deweloperów do ponownego przemyślenia sposobu optymalizacji lokalnych aplikacji wizyjno-językowych. Kompresja modeli i mniejsze architektury nie są już jedynymi drogami do niższych opóźnień. Oddzielny model szkicujący może przyspieszyć istniejący model docelowy, zachowując jego sposób generowania wyników przy zgodnych ustawieniach dekodowania.
Porównanie nie dotyczy więc Liquid AI i jednego konkurencyjnego modelu. Chodzi o dekodowanie spekulacyjne w zestawieniu z konwencjonalną praktyką zmniejszania, upraszczania lub obniżania dokładności głównego modelu wizyjno-językowego w celu uzyskania większej szybkości.
Liquid AI LFM2.5-VL-3B-DSpark dodaje dedykowany model szkicujący
Premiera oddziela jakość odpowiedzi od jednego istotnego elementu problemu opóźnień.
Liquid AI LFM2.5-VL-3B-DSpark to model szkicujący z 279,5 mln parametrów, zbudowany specjalnie dla LFM2.5-VL-3B. Nie zastępuje 3-miliardowego modelu docelowego ani nie odpowiada samodzielnie na zapytania. Zamiast tego proponuje kilka prawdopodobnych tokenów, zanim większy model wspólnie je zweryfikuje.
Proces ten nazywa się dekodowaniem spekulacyjnym — metodą wykorzystującą mniejszy predyktor do szkicowania tokenów, które następnie są równolegle weryfikowane przez model docelowy. Zaakceptowane tokeny ograniczają liczbę kosztownych przebiegów modelu docelowego potrzebnych do wygenerowania odpowiedzi. Odrzucone propozycje są korygowane przez model docelowy.
Liquid AI podaje, że model szkicujący zawiera cztery warstwy full-attention, głowicę Markova i głowicę ufności. Jego blok treningowy obejmuje dziewięć proponowanych tokenów. Wdrożenie wykorzystuje bloki po osiem lub dziewięć tokenów, zależnie od sprzętu i frameworka inferencyjnego.
Firma opublikowała model w formatach Safetensors i GGUF za pośrednictwem swojego repozytorium modeli. Obsługuje SGLang na GPU Nvidia, MLX-VLM na Apple silicon oraz llama.cpp za pośrednictwem checkpointu GGUF.
Obsługa tych frameworków ma znaczenie, ponieważ przyspieszanie inferencji często pozostaje ograniczone do artykułu naukowego lub niestandardowej implementacji badawczej. W tym przypadku Liquid AI połączyło swój model szkicujący z trzema ścieżkami wdrożenia używanymi już na serwerach, Macach i w lokalnych modelach skwantyzowanych.
SGLang wymaga wersji 0.5.19 lub nowszej dla opublikowanej konfiguracji. MLX-VLM wymaga wersji 0.7.2 lub nowszej i obecnie uruchamia tę implementację DSpark z zachłannym próbkowaniem. Liquid AI zaleca użytkownikom MLX ustawienie temperatury na zero.
Model docelowy pojawił się przed modelem szkicującym. Liquid AI przedstawiło LFM2.5-VL-3B w sierpniu 2026 roku jako model wizyjno-językowy z otwartymi wagami, przeznaczony do wdrożeń brzegowych. Model łączy rdzeń językowy z enkoderem wizyjnym dla obrazów, dokumentów, uziemiania, optycznego rozpoznawania znaków i użycia narzędzi wizualnych.
Liquid AI wcześniej twierdziło, że model docelowy może dekodować 228 tokenów na sekundę na M5 Max. Firma podała również 116 tokenów na sekundę na Ryzen AI Max+ 395 oraz 20 na Galaxy S26 Ultra. Te wcześniejsze wartości pochodziły z własnych testów firmy.
Premiera DSpark zmienia pakiet wdrożeniowy, a nie wyuczone możliwości bazowego modelu. Deweloperzy dołączają model szkicujący podczas inferencji, podczas gdy LFM2.5-VL-3B nadal odpowiada za zatwierdzenie każdego wygenerowanego tokenu.
W dekodowaniu zachłannym model docelowy akceptuje token szkicu tylko wtedy, gdy odpowiada on tokenowi, który model docelowy wybrałby samodzielnie. Wynikowa odpowiedź powinna zatem być zgodna ze zwykłym zachłannym generowaniem. Przy niezerowych temperaturach zgodne próbkowanie może zachować rozkład wyników modelu docelowego zamiast pojedynczej deterministycznej sekwencji.
Ta właściwość nadaje dekodowaniu spekulacyjnemu inną wartość niż kwantyzacja czy destylacja. Techniki te mogą zmieniać precyzję numeryczną, rozmiar modelu lub wyuczone zachowanie. DSpark stara się natomiast skrócić czas potrzebny do osiągnięcia pierwotnych decyzji modelu docelowego.
Dlatego premiera tworzy istotną rywalizację między dwiema ścieżkami optymalizacji. Deweloperzy mogą ograniczyć pracę wykonywaną przez główny model albo przewidzieć większą część tej pracy i sprawnie zweryfikować przewidywania.
Wynik 3,13x zależy od sprzętu, obciążenia i sposobu pomiaru
Najwyższa wartość Liquid AI opisuje jeden wynik dekodowania, a nie uniwersalne przyspieszenie aplikacji.
Liquid AI oceniło model szkicujący w sześciu kategoriach MMSpec: ogólne odpowiadanie na pytania wizualne, rozpoznawanie tekstu, tworzenie opisów obrazów, analizę wykresów, złożone rozumowanie oraz wieloturową rozmowę. Firma testowała rozmiar batcha równy jeden na sprzęcie Apple i na jednym GPU H100.
Na M5 Max z użyciem MLX-VLM Liquid AI podało zyski w dekodowaniu od 2,30x do 3,13x. Ulepszenia end-to-end wyniosły od 1,56x do 2,62x. Szczytowe 3,13x wystąpiło w zadaniu tworzenia opisów obrazów COCO.
Firma testowała również M3 Ultra z llama.cpp. Dekodowanie przyspieszyło według raportu o 1,57x do 2,14x, a wydajność end-to-end poprawiła się o 1,30x do 1,77x.
Na pojedynczym GPU H100 80GB z SGLang Liquid AI zmierzyło zyski dekodowania od 2,04x do 2,66x. Ulepszenia end-to-end wyniosły od 1,64x do 2,27x. Szczegółowe ujawnienie benchmarków firmy przedstawia konfiguracje i wyniki dla poszczególnych zadań.
Testy wykorzystywały przetwarzanie 16-bitowe dla enkodera wizyjnego i rdzenia językowego. Konfiguracja H100 korzystała z BF16, bloku szkicującego o długości dziewięciu, batcha o rozmiarze jeden oraz temperatury zero. Testy Apple wykorzystywały FP16, blok o długości ośmiu oraz do 2048 wygenerowanych tokenów.
Mediana długości odpowiedzi w ocenie Apple wyniosła 90 tokenów. Ten szczegół jest istotny, ponieważ długość wyjścia zmienia udział dekodowania w całym zapytaniu. System tworzący długi opis daje modelowi szkicującemu więcej czasu na odzyskanie kosztu przygotowania.
Krótkie odpowiedzi tworzą mniej korzystną proporcję. Jeżeli aplikacja zwraca etykietę, współrzędną lub jedno zdanie, kodowanie obrazu i przetwarzanie promptu mogą dominować. Szybsze generowanie wpływa wówczas na mniejszą część całkowitego czasu oczekiwania.
Akceptacja szkiców pomaga wyjaśnić raportowane przyspieszenie. Liquid AI zmierzyło około 3,2–4,5 zaakceptowanego tokenu na przebieg weryfikacji w środowiskach Apple. Wyniki H100 mieściły się w przedziale od 3,46 do 4,57 zaakceptowanego tokenu.
Większa długość akceptacji oznacza, że model docelowy zatwierdza więcej użytecznego wyniku podczas każdego przebiegu. Akceptacja nie przekłada się jednak bezpośrednio na identyczne zyski szybkości. Wykonanie modelu szkicującego, synchronizacja, dostęp do pamięci i narzut frameworka nadal zajmują czas.
Wyniki różnią się również zależnie od zadania. Tworzenie opisów obrazów przyniosło najwyższą poprawę dekodowania w MLX, podczas gdy w wieloturowej rozmowie odnotowano 2,30x. Zyski end-to-end wyniosły odpowiednio 2,59x i 1,91x.
Ta zmienność uniemożliwia odpowiedzialne odczytanie „do 3,13x” jako oczekiwanego wyniku dla każdego asystenta wizualnego. To pułap zaobserwowany w jednej opublikowanej konfiguracji. Wynik aplikacji będzie zależeć od jej sprzętu, długości promptu, długości odpowiedzi, ustawień próbkowania oraz obciążenia wizualnego.
Liquid AI twierdzi, że DSpark zachował przewagę przy większej współbieżności w testach H100. Różnica malała jednak wraz ze wzrostem współbieżności. Sugeruje to, że względna korzyść z modelu szkicującego zmienia się, gdy GPU przechodzi od dekodowania ograniczonego pamięcią do wykonania ograniczonego mocą obliczeniową.
Dla zespołów produktowych praktyczne pytanie nie brzmi, czy szczytowa wartość jest rzeczywista w teście Liquid AI. Pytanie brzmi, czy ich profil opóźnień przypomina test, który ją wygenerował. Wymaga to mierzenia każdej fazy inferencji, a nie przenoszenia nagłówkowego mnożnika do planów przepustowości.
Jak dekodowanie spekulacyjne Liquid AI zachowuje model docelowy
DSpark próbuje szkicować dalsze fragmenty bez przekształcania błędów przewidywania w końcowy wynik.
Standardowe generowanie autoregresyjne tworzy po jednym tokenie. Każdy nowy token wymaga kolejnego przebiegu modelu docelowego, nawet gdy kontynuacja jest wysoce przewidywalna. Ta sekwencyjna struktura może prowadzić do niedostatecznego wykorzystania sprzętu podczas dekodowania ograniczonego pamięcią.
Dekodowanie spekulacyjne wprowadza do tej pętli mniejszy model. Model szkicujący proponuje blok przyszłych tokenów, a model docelowy ocenia te pozycje wspólnie. Praca jest oszczędzana, gdy kilka propozycji przejdzie weryfikację.
Wyzwanie polega na tworzeniu propozycji wystarczająco szybko i dokładnie, aby uzasadnić dodatkowy model. Słaby model szkicujący generuje odrzucone tokeny. Ciężki model szkicujący dobrze przewiduje, lecz zużywa zbyt dużo czasu na wytworzenie swojego bloku.
DSpark łączy generowanie równoległe z lekkim komponentem sekwencyjnym. Jego głowica Markova wprowadza ograniczoną zależność między proponowanymi pozycjami, podczas gdy głowica ufności ocenia, czy późniejsze propozycje powinny zostać zweryfikowane. Projekt ma zachować spójność bloku bez czynienia szkicowania w pełni autoregresyjnym.
Bazowe badanie DSpark opisuje to podejście jako dekodowanie spekulacyjne z harmonogramowaniem na podstawie ufności i generowaniem półautoregresyjnym. Jego główny kompromis dotyczy jakości propozycji, opóźnienia szkicowania oraz liczby tokenów wysyłanych do weryfikacji.
Czysto równoległe szkicowanie może szybko wygenerować blok, ale dokładność często spada dla tokenów znajdujących się dalej w tym bloku. Każda pozycja zależy od kontekstu obejmującego wcześniejsze przypuszczenia. Błędy mogą zatem kumulować się w kolejnych propozycjach.
W pełni autoregresyjny model szkicujący utrzymuje silniejsze zależności, lecz odtwarza część sekwencyjskiego wąskiego gardła. Hybrydowa struktura DSpark próbuje znaleźć środek. Dodaje niewielką głowicę sekwencyjną po równoległej operacji szkicowania.
Mechanizm ufności rozwiązuje kolejne źródło marnotrawstwa. Weryfikowanie całego stałego bloku ma niewielki sens, gdy model szkicujący spodziewa się, że późniejsze tokeny zawiodą. Harmonogram może skrócić przesyłany prefiks, zanim pozycje o niskiej ufności wykorzystają zasoby modelu docelowego.
Opublikowana konfiguracja LFM2.5-VL-3B-DSpark wykorzystuje głowicę Markova o randze 256 oraz oddzielną głowicę ufności. Jej słownictwo zawiera 128 000 tokenów. Architektura pozostaje powiązana z przypisanym jej modelem docelowym i nie może służyć jako uniwersalny model szkicujący typu drop-in dla każdego VLM.
Ta zależność od konkretnego modelu jest zarazem zaletą i ograniczeniem. Trening względem jednego modelu docelowego może poprawić zgodność propozycji. Zespół przechodzący na inny model docelowy potrzebuje jednak kompatybilnego checkpointu, procesu treningowego i integracji środowiska uruchomieniowego.
Określenie „bezstratny” również wymaga precyzyjnej interpretacji. Przy zachłannym dekodowaniu z temperaturą zero weryfikacja zachowuje dokładnie te wybory tokenów, które model docelowy podjąłby samodzielnie. Model szkicujący nie otrzymuje pozwolenia na zastąpienie ich jedynie prawdopodobną alternatywą.
Przy niezerowych temperaturach cel zmienia się z odtworzenia jednej sekwencji na zachowanie rozkładu modelu docelowego. Prawidłowe próbkowanie spekulacyjne może to zapewnić przy zgodnych ustawieniach, zgodnie z fundamentalnym badaniem próbkowania. Szybkość nadal zależy od tego, jak często rozkłady modelu szkicującego i docelowego są zgodne.
Liquid AI informuje, że podniesienie temperatury obniżyło akceptację w jego eksperymentach. Większa część prawdopodobieństwa rozkłada się na tokeny o niższej randze, co zwiększa liczbę sytuacji, w których model szkicujący i docelowy mogą się nie zgodzić. W konsekwencji kreatywne próbkowanie może przynieść mniejsze zyski niż generowanie deterministyczne.
Ma to znaczenie dla projektowania aplikacji. Ekstrakcja dokumentów, osadzanie wizualne, odczytywanie wykresów i odpowiedzi z ograniczeniami często korzystają z niskich temperatur. Otwarte rozmowy o obrazach mogą wykorzystywać większe próbkowanie, przez co opublikowane wyniki zachłannego dekodowania są mniej reprezentatywne.
Spekulacyjne dekodowanie Liquid AI szczególnie dobrze pasuje więc do przewidywalnych wyników. Opisywanie wystandaryzowanych zdjęć produktów, odczytywanie paragonów, opisywanie zrzutów interfejsów i ekstrakcja ustrukturyzowanych faktów to prawdopodobne zastosowania. Rzeczywiste korzyści nadal wymagają jednak lokalnych pomiarów.
Szybsze dekodowanie nie eliminuje wąskiego gardła modeli wizyjno-językowych
Główna niewiadoma dotyczy tego, jak duża część rzeczywistego żądania pozostaje poza przyspieszoną fazą dekodowania.
Żądanie dla modelu wizyjno-językowego obejmuje więcej pracy niż generowanie tekstu. System musi zakodować obraz, przekształcić go w reprezentacje wizualne, przetworzyć te tokeny wizualne wraz z promptem, a następnie zdekodować odpowiedź.
DSpark przyspiesza wyłącznie końcowy etap. Nie przyspiesza kodowania obrazu. Nie zmienia też fazy prefill, co oznacza, że model docelowy nadal przetwarza prompt i kontekst tokenów wizualnych przed wygenerowaniem pierwszego tokenu odpowiedzi.
Ta granica wyjaśnia różnicę między wynikami dekodowania a wynikami end-to-end. Liquid AI podało dekodowanie do 3,13x szybsze na M5 Max, ale najwyższa całkowita poprawa wyniosła 2,62x. W innych zadaniach różnice były większe.
W przypadku TextVQA firma zmierzyła poprawę dekodowania o 2,69x i wzrost end-to-end o 1,56x na M5 Max. Wynik sugeruje, że przetwarzanie obrazu i prefill pochłaniały znaczną część pierwotnego czasu żądania.
Ograniczenie wynika z prawa Amdahla, które ogranicza ogólne przyspieszenie, gdy część obciążenia pozostaje niezmieniona. Jeśli dekodowanie stanowi połowę bazowego opóźnienia, nawet nieskończenie szybki dekoder nie może przyspieszyć całego żądania bardziej niż 2x.
Sprzęt brzegowy czyni to ograniczenie szczególnie istotnym. Urządzenia konsumenckie zapewniają mniej mocy obliczeniowej niż procesory GPU w centrach danych do kodowania obrazu i prefill dla długiego kontekstu. Duży obraz lub prompt z wieloma obrazami może opóźnić pierwszy token, zanim spekulacyjne dekodowanie zacznie pomagać.
Niezależny benchmark MMSpec wzmacnia potrzebę ostrożnej interpretacji. Jego autorzy ocenili 600 próbek w sześciu kategoriach zadań i dla dziesięciu metod spekulacyjnego dekodowania. Stwierdzili, że samo przyspieszenie przepustowości nie odzwierciedlało wiarygodnie wydajności opóźnień.
MMSpec wykazał również, że techniki zaprojektowane dla modeli językowych obsługujących wyłącznie tekst mogą pogarszać wyniki w środowiskach multimodalnych. Zależności między modalnościami zmieniają to, które propozycje prawdopodobnie zostaną zaakceptowane. Świadomość wizualna zyskuje na znaczeniu wraz ze wzrostem rozmiarów batchy.
Liquid AI zastosowało kategorie zadań MMSpec, co zwiększa szerokość jego wewnętrznej ewaluacji. Jednak Liquid AI samo przeprowadziło i opublikowało testy wydajności DSpark. Niezależne replikacje na popularnych urządzeniach i z wykorzystaniem promptów produkcyjnych pozostają ograniczone.
Równie dużej uwagi wymaga punkt odniesienia porównania. Opublikowane mnożniki porównują ten sam model docelowy LFM2.5-VL-3B z jego modułem drafter i bez niego w określonych frameworkach. Nie dowodzą, że połączony system przewyższa każdy konkurencyjny VLM.
Nie porównują też systemu z alternatywnymi strategiami ograniczania opóźnień. Deweloperzy mogą kwantyzować model docelowy, zmniejszać rozdzielczość obrazów, buforować embeddingi wizualne, skracać prompty, grupować żądania lub wybrać mniejszy model. Zmiany te wpływają na różne części budżetu opóźnień.
Kolejną kwestią operacyjną jest pamięć. Drafter jest niewielki w porównaniu z 3-miliardowym modelem docelowym, ale nie jest bezkosztowy. Jego wagi, cache, stan środowiska wykonawczego i integracja zużywają zasoby istotne na urządzeniach o ograniczonej pojemności.
Kompatybilność powoduje dalsze utrudnienia. SGLang, MLX-VLM i llama.cpp oferują obecnie opublikowane ścieżki, ale zespoły korzystające z innych systemów serwowania nie mogą zakładać natychmiastowego wsparcia. Wdrożenie produkcyjne wymaga stabilnego ładowania, obserwowalności, przewidywalnego zachowania przy batchingu i obsługi awarii.
Obecna ścieżka DSpark w MLX-VLM, ograniczona wyłącznie do zachłannego generowania, zawęża jej bezpośrednie zastosowania. Aplikacje zależne od generowania z próbkowaniem potrzebują innego obsługiwanego stosu albo muszą poczekać na szersze wsparcie próbkowania. Nawet wtedy wyższe temperatury mogą obniżać akceptację propozycji.
Dlatego wydanie należy oceniać jako wiarygodną optymalizację systemową o jasno określonych granicach. Nie jest dowodem na to, że inferencja wizualna stała się 3,13x szybsza w każdym istotnym znaczeniu.
Rzeczywista rywalizacja to lepsze przewidywanie kontra mniejsza praca modelu
DSpark wzmacnia podejście, w którym deweloperzy zachowują model docelowy i optymalizują częstotliwość jego uruchamiania.
Standardową odpowiedzią edge AI na opóźnienia było zmniejszanie obciążenia modelu docelowego. Zespoły wykorzystują mniej parametrów, niższą precyzję, krótsze prompty, mniejsze obrazy lub destylację specyficzną dla zadania. Każda z tych technik może poprawić responsywność, ale każda może też wprowadzać kompromisy w jakości lub elastyczności.
Liquid AI LFM2.5-VL-3B-DSpark proponuje inną ścieżkę. Zachowaj istniejący model docelowy i przewiduj kilka przyszłych kroków za pomocą wyspecjalizowanego komponentu towarzyszącego. Pozwól modelowi docelowemu zweryfikować te przewidywania bez oddawania kontroli nad końcowym wynikiem.
To podejście staje się atrakcyjne, gdy zespół już akceptuje możliwości modelu docelowego. Jego zastąpienie wymagałoby nowych ewaluacji, zmian w promptach, kontroli bezpieczeństwa i dostrajania produktu. Dołączenie draftera może zachować większą część tej inwestycji.
Podejście dobrze pasuje również do wdrożeń lokalnych, gdzie przepustowość pamięci często ogranicza generowanie tokenów. Weryfikacja bloku może wykorzystywać sprzęt wydajniej niż wielokrotne ładowanie stanu modelu dla pojedynczego tokenu. Wyniki Liquid AI na Apple konkretyzują tę możliwość.
Mniejsze modele nadal zachowują jednak zalety. Upraszczają pakowanie, zmniejszają całkowite użycie pamięci i przyspieszają etapy, których optymalizacja samego dekodera nie może objąć. Kompaktowy enkoder wizyjny może skrócić czas do pierwszego tokenu, czego DSpark nie potrafi.
Kwantyzacja może również łączyć się ze spekulacyjnym dekodowaniem, zamiast wyłącznie z nim konkurować. Liquid AI dostarcza drafter GGUF dopasowany do swojego modelu docelowego GGUF. Lokalny stos może więc zmniejszyć precyzję i dodać drafting, pod warunkiem że środowisko wykonawcze poprawnie obsługuje tę parę.
To połączenie przesuwa pytanie inżynieryjne z wyboru jednej techniki na przypisanie każdej z nich do właściwego wąskiego gardła. Kwantyzacja zmniejsza rozmiar wag i koszt obliczeń. Wstępne przetwarzanie obrazu zmienia koszt przetwarzania wizji. Spekulacja celuje w autoregresywne generowanie.
Dlatego profilowanie na poziomie faz staje się niezbędne. Asystent dokumentów analizujący strony w wysokiej rozdzielczości może spędzać większość czasu przed dekodowaniem. Narzędzie czatu wizualnego tworzące szczegółowe opisy może poświęcać znacznie więcej czasu na generowanie wyniku.
To samo rozróżnienie dotyczy doświadczenia użytkownika. Czas do pierwszego tokenu decyduje o tym, czy aplikacja wydaje się responsywna na początku. Liczba tokenów na sekundę decyduje o tym, czy długa odpowiedź płynnie się wyświetla po rozpoczęciu generowania.
DSpark bezpośrednio poprawia drugą miarę. Poprawia całkowite opóźnienie, gdy dekodowanie zajmuje wystarczająco dużą część żądania. Nie gwarantuje proporcjonalnej poprawy pierwszej miary.
Deweloperzy powinni również oddzielać szybkość dla pojedynczego użytkownika od przepustowości całej floty. Liquid AI zaobserwowało przewagę na wszystkich mierzonych poziomach współbieżności H100, ale różnica malała przy większym obciążeniu. Ekonomia produkcyjna zależy od mieszaniny żądań, batchingu i celów poziomu usług.
Najbardziej konsekwentnym aspektem wydania jest więc architektura. Liquid AI spakowało spekulacyjne dekodowanie jako część możliwej do wdrożenia rodziny modeli wizyjnych, zamiast przedstawiać je wyłącznie jako badania.
Jeśli ten wzorzec się rozpowszechni, wydania modeli mogą coraz częściej obejmować model docelowy, wiele wariantów kwantyzacji i draftery specyficzne dla sprzętu. Optymalizacja inferencji stałaby się częścią artefaktu modelu, a nie decyzją dotyczącą serwowania podejmowaną po jego wydaniu.
Ten kierunek wywiera presję na innych twórców modeli open-weight. Publikowanie wyłącznie checkpointu pozostawia zespołom downstream odpowiedzialność za przyspieszenie. Dostarczenie dopasowanego draftera oferuje pełniejszą historię opóźnień, nawet jeśli mierzone korzyści nadal zależą od obciążenia.
Trzy sygnały pokażą, czy przyspieszenie ma znaczenie w praktyce
Niezależne testy, szersze wsparcie próbkowania i profile rzeczywistych aplikacji określą, czy DSpark stanie się powtarzalnym wzorcem wdrożeniowym.
Pierwszym sygnałem jest niezależna replikacja na dostępnym sprzęcie. Deweloperzy powinni śledzić testy na komputerach Mac z serii M, konsumenckich GPU i systemach brzegowych, wykorzystujące identyczne prompty z drafterem i bez niego.
Przydatne raporty muszą ujawniać wymiary obrazów, długość promptu, długość wyniku, temperaturę, kwantyzację i wersję środowiska wykonawczego. Pojedyncza wartość tokenów na sekundę nie wyjaśnia, czy pełna odpowiedź aplikacji rzeczywiście stała się istotnie szybsza.
Replikacja zbliżona do zakresów Liquid AI wzmocniłaby argumentację firmy. Mniejsze lub niespójne korzyści sugerowałyby, że opublikowane obciążenia bardziej sprzyjają drafterowi niż codzienne aplikacje.
Drugim sygnałem jest szersze wsparcie środowisk wykonawczych i próbkowania. MLX-VLM obecnie ogranicza opublikowaną ścieżkę DSpark do zachłannego generowania, podczas gdy SGLang celuje we wdrożenia Nvidia, a llama.cpp obsługuje przypadki użycia GGUF.
Wsparcie w dodatkowych silnikach inferencyjnych zmniejszyłoby koszt integracji. Stabilne próbkowanie z temperaturą inną niż zero zwiększyłoby też znaczenie tej metody dla wizualnego czatu i narzędzi kreatywnego opisywania.
Deweloperzy powinni analizować wskaźniki akceptacji wraz ze zmianą próbkowania. Liquid AI twierdzi, że wyższe temperatury zmniejszały akceptację i przepustowość w jego eksperymentach. Testy produkcyjne powinny ujawnić, czy te spadki pozostają akceptowalne dla produktów konwersacyjnych.
Trzecim sygnałem będzie to, czy zespoły raportują zyski na poziomie faz w rzeczywistych aplikacjach. Decydujące metryki to czas do pierwszego tokenu, szybkość dekodowania, opóźnienie end-to-end, szczytowe użycie pamięci oraz przepustowość przy oczekiwanej współbieżności.
Asystent wizualny do długich form może odnieść znaczące korzyści, ponieważ generowanie dominuje w jego sesji. Przepływ OCR zwracający kilka pól może zyskać znacznie mniej, ponieważ kodowanie obrazu i prefill zajmują większość żądania.
Zespoły oceniające Liquid AI LFM2.5-VL-3B-DSpark powinny zaczynać od śladów wykonania, a nie od nagłówkowych mnożników. Zmierz udział bazowy zużywany przez kodowanie obrazu, prefill i dekodowanie. Następnie dołącz drafter i powtórz to samo obciążenie.
Sprawdź równoważność wyników przy zachłannym dekodowaniu oraz zachowanie rozkładu przy obsługiwanym próbkowaniu. Mierz osobno ciepłe i zimne starty. Uwzględnij presję na pamięć oraz utrzymującą się temperaturę podczas testowania laptopów lub systemów klasy mobilnej.
Wydanie zawiera wystarczająco dużo szczegółów implementacyjnych, aby takie ewaluacje były możliwe. Przypomina też deweloperom o istotnej kwestii: możliwości modelu i zachowanie inferencji to odrębne problemy inżynieryjne.
Wartość 3,13x od Liquid AI najlepiej rozumieć jako dowód, że dopasowany drafter może istotnie przyspieszyć jedną fazę lokalnej inferencji multimodalnej. Wyniki end-to-end pokazują zarówno wartość, jak i ograniczenie tego twierdzenia.
Czy dopasowane modele draftujące staną się standardowymi towarzyszami VLM-ów open-weight, czy pozostaną wyspecjalizowanymi optymalizacjami dla obciążeń z długimi wynikami? Odpowiedź przyniosą powtarzalne ślady wykonania aplikacji, a nie pojedynczy rekordowy benchmark.
