DeepSeek V4.1 Flash: wywoływanie narzędzi trafia do vLLM — co zepsuły tagi ze spacjami

DeepSeek V4.1 Flash jest powszechnie dostępny od 10 września 2026 r., a przez pierwszych dwanaście dni swojego istnienia model miał lukę, o której nikt nie pisał: potrafił rozumować, potrafił widzieć obrazy, potrafił utrzymać milion tokenów kontekstu, a nie potrafił niezawodnie wywołać narzędzia za pośrednictwem najszerzej używanego otwartego stosu do serwowania. Ta luka została teraz zamknięta w vLLM — nie za pomocą flagi konfiguracyjnej, ale poprzez przepisanie parsera. Dwa pull requesty zawierają tę pracę, a najciekawsze jest to, dlaczego były potrzebne.

Krótka wersja: DeepSeek V4.1 Flash wysyła swoje wywołania narzędzi w formacie znaczników, którego istniejący detektor DeepSeek V4 nie rozpoznaje, więc w standardowym wdrożeniu vLLM znaczniki wywołań narzędzi przychodzą jako zwykły tekst zamiast ustrukturyzowanych danych wyjściowych. Nie pojawia się żaden błąd. Model wygląda, jakby po prostu odmówił wywołania funkcji. Jeśli testujesz pętle agentowe z samodzielnie hostowanym DeepSeek V4.1 Flash i dochodzisz do wniosku, że model jest słaby w narzędziach, to najprawdopodobniej właśnie to widziałeś.

Co tak naprawdę zmieniło się w stacku serwującym

Parsowanie wywołań narzędzi w vLLM dla modeli DeepSeek od jakiegoś czasu istnieje w dwóch miejscach: we frontendzie w Pythonie i nowszym frontendzie w Rust, a prace na poziomie gramatyki są delegowane do projektu XGrammar. Wprowadzenie obsługi V4.1 Flash wiązało się z przeniesieniem konwersji C++ deepseek_xml wewnątrz XGrammar do buildera w Rust, a następnie podłączeniem własnego kodowania modelu do katalogu tokenizera vLLM.

• Praca nad frontendem w Rust to PR #56235, który portuje konwersję XGrammar C++ deepseek_xml do buildera w Rust. Dostarcza 18 nowych testów specjalnie dla V4.1, a pełne istniejące zestawy — 472 testy w vllm-parser i 326 testów w vllm-chat — pozostają zielone.

• Prace nad frontendem w Pythonie to PR #56408, który wciąż jest szkicem. Zależą one od wcześniejszego wdrożenia zmiany w nadrzędnym projekcie XGrammar (mlc-ai/xgrammar#885) i według raportów dają 110 przechodzących testów po zastosowaniu tej zależności.

• Nowy moduł kodowania to vllm/tokenizers/deepseek_v41_encoding.py — osobny plik, a nie gałąź wewnątrz kodowania V4, co wskazuje, że gramatyka tagów rzeczywiście się różni, a nie tylko jest rozszerzeniem.

• Wywołanie jest jawne: --tool-parser deepseek_v41. Nie istnieje żaden awaryjny mechanizm automatycznego wykrywania, który po cichu robiłby to, co należy.

Te znaczniki z odstępami to cała historia

Powodem, dla którego istnieje nowy parser zamiast rozszerzonego wyrażenia regularnego, są białe znaki. DeepSeek V4.1 Flash zapisuje swoje znaczniki narzędzi DSML ze spacjami między tokenami. Wzorzec detektora V4 oczekuje formy bez spacji, więc nie udaje mu się dopasować, a nieudane dopasowanie w parserze wywołań narzędzi jest z założenia ciche — tekst jest przekazywany dalej jako treść, zamiast zgłaszać błąd.

Warto się nad tym trybem awarii zatrzymać, ponieważ należy on do najkosztowniejszych. Parser, który zgłasza wyjątek, da się naprawić w jedno popołudnie. Parser, który zwraca poprawnie sformułowany łańcuch znaków ze znacznikami, o które wywołujący wcale nie prosił, wygląda jak problem z jakością modelu, a zespoły reagują na niego tak, jak reagowałbyś na problem z jakością modelu: próbują różnych promptów, dodają przykłady, zmieniają modele. Dwanaście dni to wystarczająco długo, by wiele z tego wydarzyło się prywatnie.

Oznacza to również, że poprawka nie jest pokrętłem dostrajania. Nie da się obejść promptem detektora, który nie pasuje do formatu wyjściowego twojego modelu, ani nie można tego naprawić w kliencie przez przetwarzanie końcowe, ponieważ zanim tekst dotrze do klienta, struktura już zniknęła. Musi się to odbywać w stosie serwowania, czyli dokładnie tam, gdzie teraz się znajduje.

Dlaczego ma to większe znaczenie w przypadku V4.1 Flash niż miało to miejsce w V4

Wywoływanie narzędzi nie jest opcją dodatkową dla tego konkretnego modelu. DeepSeek V4.1 Flash to model typu mixture-of-experts z 552 miliardami parametrów, z czego 8 miliardów parametrów jest aktywnych na wejściu, a 16 miliardów na wyjściu, z oknem kontekstu wynoszącym 1 mln tokenów i maksymalnym wyjściem 384 tys. tokenów. Podział aktywnych parametrów mówi sam za siebie: model został zbudowany tak, aby przyjmować duże dane wejściowe — repozytorium, zestaw dokumentów, długi ślad wywołań narzędzi — i generować długą, ustrukturyzowaną odpowiedź. To kształt agenta, a nie kształt czatu.

Reszta specyfikacji premiery wskazuje ten sam kierunek. Wagi na licencji MIT, 890 bajtów pamięci podręcznej KV na token, 45 bilionów tokenów pretreningowych, natywne przetwarzanie obrazu. Wartość pamięci podręcznej KV ma znaczenie operacyjne przy kontekście 1M: to ona sprawia, że długi transkrypt agenta jest opłacalny do utrzymania w pamięci, i dlatego model jest wiarygodny jako tani pracownik w pętli nadzorowanej przez droższy model.

Co czyni dwunastodniową lukę w wywoływaniu narzędzi realnym kosztem, a nie przypisem. Model, którego opłacalność opiera się na byciu masowym wykonawcą w potoku agentowym, jest wart bardzo niewiele, jeśli potok nie może uzyskać z niego ustrukturyzowanego wywołania.

Co jest jeszcze otwarte?

Uczciwy stan rzeczy na dzień 22 września 2026 r.:

• Ścieżka frontendu w Rust (PR #56235) to ta z pełnym pokryciem testami zarówno nowych przypadków V4.1, jak i wcześniej istniejących zestawów testów. Jeśli korzystasz z kompilacji vLLM, która ją zawiera, parser jest już dziś dostępny.

• Ścieżka frontendu Pythona (PR #56408) jest wersją roboczą i ma zewnętrzną zależność. Jeśli korzystasz z kompilacji przypiętej do wersji sprzed zmiany XGrammar, frontend Pythona nie zapewni jeszcze parsowania narzędzi V4.1.

• Ponieważ wywołanie jest jawne, wdrożenie, które aktualizuje vLLM, ale nie zmienia flag uruchomieniowych, zachowa stare zachowanie. To, że parser istnieje, a to, że jest używany, to dwie różne rzeczy.

• Nie ma jeszcze publicznych dowodów na to, że niezależny benchmark wywoływania narzędzi został uruchomiony względem V4.1 Flash z nowym parserem na miejscu. Wiemy, że mechanika działa, a testy przechodzą. To, czy jakość wywoływania narzędzi przez model jest dobra, to osobne pytanie, na które scalenie nie odpowiada.

Ten ostatni punkt jest tym, którego należy się trzymać. Poprawka parsera przenosi model z „nie można go ocenić” do „można go ocenić”. Jest warunkiem wstępnym werdyktu, a nie werdyktem.

Jeśli nie chcesz samodzielnie uruchamiać stosu serwowania

Jest krótsza droga. DeepSeek V4.1 Flash jest dostępny przez endpoint OrcaRouter przeznaczony dla niego, co oznacza, że zachowanie wywoływania narzędzi przychodzi jako zwykłe wywołanie API, a nie jako problem kompilacji — żadnej wersji XGrammar do dopasowania, żadnego frontendu do wyboru, żadnej flagi uruchomieniowej do zapamiętania. Powód, dla którego ma to tutaj szczególne znaczenie, jest taki, że poprawka trafiła w dwa miejsca o różnej dojrzałości, a hostowany endpoint redukuje tę decyzję do zera.

Ten sam klucz daje również dostęp do pozostałych modeli, które możesz brać pod uwagę — a to przydatna właściwość, gdy pytanie nie brzmi „czy ten parser jest poprawny”, lecz „czy ten model jest wystarczająco dobry dla mojej pętli”. Możesz umieścić DeepSeek V4.1 Flash za regułą routingu jako taniego wykonawcę i przełączyć go awaryjnie na mocniejszy model, gdy wywołanie się nie powiedzie — bez drugiej umowy czy drugiego SDK. Wypróbowywanie modelu, którego obsługa wywołań narzędzi ma dwa tygodnie, to dokładnie ta sytuacja, dla której istnieje automatyczne przełączanie awaryjne.

Co obejrzeć dalej

Trzy rzeczy sprawiłyby, że z opowieści o hydraulice stałoby się to werdyktem:

• PR #56408 wychodzi z trybu roboczego, co sprawiłoby, że ścieżka frontendu w Pythonie stałaby się realna i zakończyłoby sytuację dwupoziomowego wsparcia.

• Niezależna ewaluacja agentowa lub ewaluacja wywoływania narzędzi przeprowadzona na V4.1 Flash w ramach ustalonego stosu serwowania. Model ukazał się dwanaście dni temu, a parser jest użyteczny krócej niż od tego czasu, więc każdy wynik wywoływania narzędzi, jaki teraz widzisz dla niego przytaczany, warto poddać wątpliwości — konfiguracja ma znaczenie tak samo jak sam model.

• Czy pójdą za tym inne stosy serwujące. vLLM jest tym, który ma publiczne PR-y; problem tagów rozdzielonych spacjami nie jest specyficzny dla vLLM, więc każdy stos, który przyjął detektor V4, nie wyprowadzając go ponownie z wyników V4.1, nosi w sobie ten sam cichy błąd.

Zanim pojawi się pierwszy z nich, trafne podsumowanie jest wąskie i warto je przedstawić wprost: DeepSeek V4.1 Flash to model GA z wagami MIT, kontekstem 1M i limitem wyjścia 384K, a jego wywoływanie narzędzi działa teraz na ścieżce Rust w vLLM z jawną flagą parsera. To realny krok, a jeszcze nie wynik.