Recursive Flint 40B-A2.5B: model do kodowania stworzony przede wszystkim z myślą o szybkości

Liczba, która decyduje, czy Recursive Flint 40B-A2.5B jest wart Twojej przestrzeni dyskowej, to nie 54,9%. To 2,5. Pierwszy model kodujący o otwartych wagach od Recursive ma 39,8 miliarda parametrów i aktywuje około 2,5 miliarda z nich dla każdego tokenu, który zapisuje, a niemal każda inna decyzja w wydaniu — układ mechanizmu uwagi, przepis kwantyzacji, własne jądro Metal, silnik wnioskowania — wynika z tego jednego stosunku. Flint ukazał się 21 października 2026 na licencji Apache 2.0, co oznacza, że w chwili pisania ma zaledwie dzień i znajduje się w okresie, gdy premiera jest jeszcze newsem, a nie historią. Ponieważ jednodniowa tabela benchmarków jest obietnicą, a nie pomiarem, rekord produkcyjny prowadzimy osobno: AI Incident Archive rejestruje, jak sprawdziły się deklaracje modeli i dostawców, gdy obsługują rzeczywisty ruch.

W skrócie dla każdego, kto decyduje teraz: to rzadki model mieszaniny ekspertów zbudowany tak, by być najszybszą rzeczą w swojej klasie wagowej na laptopie, publikuje trzy wyniki kodowania agentowego, które są w całości raportowane przez dostawcę i nieodtworzone, i jest pierwszym modelem firmy, której deklarowanym celem jest automatyzowanie badań, które budują modele. Wszystkie te trzy fakty mają znaczenie, a trzeci z nich to ten, który będzie wciąż interesujący za rok.

Co faktycznie zostało wydane

Cztery repozytoria, a nie jedno. Główne RecursiveSI/flint repozytorium zawiera checkpoint BF16, konfigurację, tokenizer, szablon czatu oraz zestaw do serwowania SGLang i zostało utworzone 21 października 2026 o 14:20 UTC. Obok niego znajdują się trzy skwantyzowane warianty, wszystkie datowane na to samo popołudnie: wersja int4 w formacie safetensors, int4 GGUF oraz NVFP4 GGUF. Każdy poniższy rozmiar zmierzono na podstawie własnych list plików repozytoriów, a nie zaczerpnięto z ogłoszenia.

• Wzorzec BF16 — 79,59 GB w 37 plikach, w 15 shardach safetensors po około 5,37 GB każdy. To artefakt dostrajania (fine-tuningu), czyli ten, którego nie chcesz pobierać do wnioskowania.

• NVFP4 GGUF — 22,86 GB w jednym pliku, najmniejsza opublikowana pełna kompilacja do wnioskowania.

• Int4 GGUF — 25,99 GB, kwantyzacja q4_1, która jest większa niż plik NVFP4, co jest odwrotnością kolejności nazewnictwa i warto o tym wiedzieć, zanim wybierzesz plik po nazwie.

• Int4 safetensors — 22.58GB dla środowisk uruchomieniowych, które preferują wagi podzielone na shardy zamiast pojedynczego GGUF.

Licencja to Apache 2.0, a karta modelu dodaje rozróżnienie, że warunki hostowanego API i praktyki dotyczące danych są oddzielne od licencji na wagi — zwykły podział, podany wprost, a nie ukryty.

Architektura jest argumentem dotyczącym przepustowości pamięci.

Na laptopie dekodowanie tokena nie jest głównie problemem obliczeniowym. To problem przemieszczania wag z pamięci do jednostek arytmetycznych wystarczająco szybko, dlatego gęsty model z 40 miliardami parametrów jest wolny niezależnie od tego, jak dobry jest chip: każdy token odczytuje każdą wagę. Odpowiedzią Flinta jest odczytanie prawie żadnej z nich.

• Rzadkość — 256 ekspertów routowanych na warstwę MoE, z 6 wybieranymi na token, plus jeden zawsze aktywny wspólny ekspert. Z 49 warstw 2 są gęste, a 47 to MoE, więc wszystkie oprócz pierwszych dwóch wykonują pracę warunkową.

• Aktywne parametry — łącznie 39,8 mld, około 2,5 mld aktywnych na token, wliczając głowicę wyjściową, stąd oznaczenie „40B-A2.5B”. Samo aktywne ciało to około 2,2 mld.

• Attention — 35 warstw z oknem przesuwnym o rozmiarze 513 tokenów (bieżący token plus 512 poprzedzających) przeplatanych z 14 warstwami pełnej uwagi. Tylko 32 głowice zapytań i 4 głowice klucz-wartość, przy wymiarze głowicy 128, dzięki czemu pamięć podręczna KV pozostaje wystarczająco mała, by długie sesje agentowe były praktyczne.

Kodowanie pozycji — osadzenia rotacyjne w warstwach z oknem przesuwnym i całkowity ich brak w warstwach z pełną uwagą; wybór, który karta modelu podaje bez wyjaśnienia. RMSNorm QK na głowę i wyuczone ujścia uwagi na głowę wykonują pracę stabilizacyjną, którą kodowanie pozycji zwykle dzieli.

• Kontekst — udokumentowano 262 144 tokeny, a karta modelu wyraźnie wskazuje, że obejmuje to łącznie prompt i wygenerowane dane wyjściowe. Ogłoszenie reklamuje „do 512k”, a następnie zaleca pozostanie w granicach 256k w przypadku kodowania. Oba stwierdzenia pochodzą od tego samego dostawcy, w odstępie jednego akapitu.

Interesujący szczegół dotyczy tego, jak wybrano ten kształt. Recursive twierdzi, że jego Eureka Machine — zautomatyzowana pętla badawcza, która zgłasza pomysły, wdraża je, testuje i łączy to, co działa — zaczęła od modelu bazowego z 35 miliardami parametrów, z których 3 miliardy były aktywne, i przeszukała różne konfiguracje ekspertów oraz szerokości. Powstała konfiguracja 40B/2.5B była, jak to ujęto w samym ogłoszeniu, „prognozowana jako oferująca najlepsze połączenie szybkości i wydajności kodowania wśród konfiguracji testowanych przez naszą Eureka Machine”. Prognozowana, a nie udowodniona w bezpośrednim porównaniu gotowych modeli. To normalny sposób wyboru architektury, gdy treningi są kosztowne, ale też twierdzenie, któremu późniejszy checkpoint mógłby po cichu zaprzeczyć.

Trzy punktacje i towarzyszące im przypisy

Flint uzyskuje 54,9% w Terminal-Bench 2.1, 89,7% w SWE-bench Pro v2 i 74,2% w SWE-bench Verified. Te liczby pojawiają się w karcie modelu jako oceny wydania, a żadna strona trzecia nie opublikowała pomiaru tego modelu — indeks modeli Artificial Analysis, zwyczajowy niezależny arbiter przy tego typu premierze, nie ma żadnego wpisu dla Flint na dzień 22 października. Zatem wszystko poniżej to Recursive mierzący Recursive.

To, co dostawca ujawnia na temat własnej metodologii, to więcej, niż większość postów o premierze podaje z własnej inicjatywy, i zmienia to sposób, w jaki należy odczytywać te liczby:

• Terminal-Bench 2.1 — uruchamiany z harnessem Terminus 2, z włączonym dostępem do internetu; rozwiązania uzyskane przez wyszukiwanie w internecie są uznawane za niepowodzenia. To ostatnie dostosowanie jest celowym utrudnieniem, a karta modelu wskazuje, że opublikowane wyniki innych deweloperów mogą go nie stosować, co sprawia, że porównanie na równych zasadach z wynikami podmiotów trzecich jest trudniejsze, a nie łatwiejsze.

• SWE-bench Pro v2 i SWE-bench Verified — uruchamiane z mini-swe-agent i całkowitym brakiem dostępu do internetu, czyli w trudniejszym wariancie niż agenci, którzy mogą w trakcie wykonywania zadania przeszukiwać dokumentację.

• Próby i limity czasu — średnia pass@1 z co najmniej pięciu prób, przy limitach czasu działania agenta wynoszących do pięciu godzin. Uśrednienie pięciu prób to rozsądny protokół; pięciogodzinne limity czasu oznaczają, że są to wyniki dla agenta, którego jesteś gotów pozostawić działającego, a nie dla autouzupełniania.

• Próbkowanie — temperatura 1.0, top-p 0.95, top-k 20 w każdej ewaluacji, a zestaw serwujący stosuje te wartości domyślne, gdy żądanie ich nie podaje.

Tabela benchmarków dostawcy jest również oświadczeniem o tym, jakie modele wybrał do porównania. Własny wykres Recursive porównuje Flint z Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer i Gemma 4 — lokalnymi modelami pasującymi do podobnego sprzętu; to uczciwa grupa porównawcza dla modelu laptopowego, a jednocześnie grupa wybrana tak, aby argument o rzadkości wypadł korzystnie. Formułowane twierdzenie jest wąskie i możliwe do obrony: Flint prowadzi wśród modeli MoE o łącznej liczbie poniżej 50 miliardów parametrów w kodowaniu agentowym i konkuruje z gęstymi modelami o 25–40 mld parametrów, działając znacznie szybciej. Nie jest to twierdzenie dotyczące czołowych modeli kodujących i Recursive go nie formułuje — ogłoszenie mówi wprost, że Flint „może wymagać więcej wskazówek niż większe zamknięte modele kodujące, do których jesteś przyzwyczajony”.

Szybkość: względem czego tak naprawdę mierzy się 2×

Recursive raportuje ponad 125 tokenów na sekundę na M4 Pro MacBook Pro i ponad 150 tokenów na sekundę na 64GB NVIDIA RTX Spark przy krótkich kontekstach, opisując to jako do dwukrotnie większą szybkość niż porównywalne modele i ponad pięciokrotnie większą szybkość niż gęste modele o 25 do 40 miliardów parametrów z podobnymi wynikami w kodowaniu. Przypis metodologiczny na wykresie szybkości jest tym, co warto przeczytać: średnia liczba tokenów na sekundę przez całą sesję 128 000 tokenów, z wyłączeniem prefillu, przy czym jeden konkurent został zmierzony przy 124k, a nie na pełnej długości.

Wyłączenie prefillu to standardowa praktyka w benchmarkowaniu dekodowania i nadal ma to tutaj znaczenie, ponieważ prefill to dokładnie ten etap, na którym agent kodujący spędza czas, gdy wrzuca repozytorium do okna kontekstu. Liczba mierząca wyłącznie połowę dekodowania sesji 128k będzie korzystnie przedstawiać każdy model z rzadką aktywacją, a cały projekt Flint opiera się na rzadkiej aktywacji. To nie czyni tej liczby błędną. Czyni ją liczbą dekodowania i należy ją porównywać z innymi liczbami dekodowania, a nie z tym, ile czasu zajmuje Twojemu agentowi ukończenie zadania.

Przepis na kwantyzację jest najbardziej przenośną częścią

Większość opracowań o kwantyzacji dotyczy tego, ile dokładności utracono. Ten tekst dotyczy decyzji, która poszła w przeciwnym kierunku niż konwencja.

Recursive skwantyzował warstwę wyjściową — lm_head — do 4 bitów. To niezgodne z powszechną praktyką, a powód jest specyficzny dla modeli rzadkich: przy zaledwie 2,5 miliarda aktywnych parametrów warstwa wyjściowa stanowi dużą część wag odczytywanych dla każdego pojedynczego tokenu, więc pozostawienie jej na 16 bitach ogranicza maksymalną możliwą szybkość modelu. Odzyskanie dokładności wymagało etapu destylacji offline, w którym skwantyzowany model trenuje na własnych wstępnie spróbkowanych odpowiedziach z coresetu, który sam odkrył, przy czym model 16-bitowy pełni rolę nauczyciela — Recursive twierdzi, że taki układ prawie o połowę zmniejszył liczbę kroków treningowych w porównaniu z jego bazowym podejściem do treningu świadomego kwantyzacji.

Opublikowany wynik jest taki, że finalny model NVFP4 uzyskuje wyniki w granicach 0,7 punktu od modelu 16-bitowego w całym zestawie testów porównawczych. To twierdzenie dostawcy i jest to rodzaj twierdzenia, które łatwo później zweryfikować, a kosztownie sfałszować, co czyni je użytecznym do rozliczenia ich z niego. Praktyczną konsekwencją są podane wyżej rozmiary plików: pobranie 22,86 GB, które uruchamia model o 39,8 miliarda parametrów na maszynie z 48 GB zunifikowanej pamięci.

Na Apple Silicon jest w tym druga warstwa. Eureka Machine od Recursive stworzyła wyspecjalizowane kernele do projekcji niskobitowych, operacji MoE, attention i przetwarzania promptów, w tym megakernel Metal, który scala cały forward pass dekodowania w jedno wywołanie na układach M4 i M5. Scalanie przebiegu dekodowania to rodzaj optymalizacji, która się opłaca tylko wtedy, gdy jednocześnie kontroluje się architekturę modelu, format kwantyzacji i kernel — i to jest właściwa teza tego wydania, bardziej niż jakakolwiek pojedyncza liczba z benchmarku.

Jak to prowadzisz i ile kosztuje cię każda ze ścieżek

Istnieją dwie odrębne historie wdrożeniowe i nie są one wymienne.

• Serwerowe GPU — checkpoint BF16 jest dostarczany z zestawem do serwowania SGLang, który obsługuje jedną B300 lub jedną H200 na replikę, udostępnia punkt końcowy zgodny z OpenAI na porcie 30000 pod nazwą modelu flint oraz zawiera przykładowego klienta do rozumowania i wywołań narzędzi. To jedyna obsługiwana ścieżka dla wag pełnej precyzji; karta modelu wprost stwierdza, że kod modelowania Transformers nie jest jeszcze dołączony.

• Komputery lokalne — llama.cpp, Ollama, Unsloth, LM Studio, vLLM i SGLang są wymienione jako obsługiwane, co jest niezwykle szerokim zakresem jak na model dostępny w dniu premiery i stanowi różnicę między checkpointem a gotowym do użycia artefaktem.

• Silnik rec — własny silnik wnioskowania Recursive, instalowany w ~/.local/bin, wymaga M4 Pro, M5 Pro lub M5 Max z co najmniej 48 GB pamięci zunifikowanej i około 30 GB wolnego miejsca na dysku oraz udostępnia lokalnie API zgodne z OpenAI. W swoim README deklaruje od 1,4× do 2,6× wyższą przepustowość tokenów niż llama.cpp na M4 Pro z wagami 4-bitowymi, dla promptów o długości od 1 000 do 252 000 tokenów i 1 024 tokenów wyjściowych, po pięć przebiegów na każdą długość kontekstu, z wyłączeniem etapu prefill. Jest wyraźnie zoptymalizowany do użytku w jednej sesji — jeśli uruchomisz kilka agentów jednocześnie, dokumentacja kieruje cię gdzie indziej.

Praktyczne uwagi, które decydują o tym, czy sesja przebiegnie dobrze: okno kontekstu jest współdzielone między promptem a odpowiedzią, trudne problemy wymagają budżetu wyjściowego wynoszącego co najmniej 32 768 tokenów, wliczając rozumowanie, a zwrócony reasoning_content musi zostać zachowany w historii konwersacji, w przeciwnym razie korzystanie z narzędzi w wielu turach ulega pogorszeniu. Własne wskazówki Recursive dotyczące złożonych zadań mówią, aby podzielić pracę na mniejsze podzadania z wyraźnymi instrukcjami, co jest szczerą radą, która jednocześnie brzmi jak opis górnego limitu możliwości modelu.

Co jest naprawdę nieudowodnione?

Trzy rzeczy, w kolejności malejącej według tego, jak bardzo powinny wpływać na decyzję.

Pierwsza kwestia to niezależny pomiar. Nie ma go. Nie chodzi o niski wynik w rankingu ani o wynik kwestionowany — nie istnieje jeszcze żadna ocena Flint przeprowadzona przez niezależną stronę trzecią, a jedyne krążące liczby pochodzą od dostawcy i powstały z użyciem wybranego przez niego zestawu narzędzi testowych oraz jego dostosowania dotyczącego wyszukiwania w sieci. Metodologia jest ujawniona na tyle dokładnie, że można ją audytować, i to wszystko, o co można prosić pierwszego dnia — ale ujawnienie to nie weryfikacja.

Drugi aspekt to czy model z 2,5 mld aktywnych parametrów sprawdza się w długotrwałych zadaniach, do których agenci kodujący są właściwie przeznaczeni. Protokół benchmarku dopuszcza pięć prób i pięciogodzinne limity czasu, co stanowi hojne ramy; model, który potrzebuje kilku prób i długiej smyczy, może uzyskać dobry pass@1, mimo że w edytorze wydaje się zawodny. Zastrzeżenie samego Recursive, że potrzebuje więcej wskazówek niż większe modele zamknięte, wskazuje na to samo.

Trzeci element to samo przeszukiwanie architektury. Konfiguracja, której przewiduje się, że będzie najlepsza spośród testowanych przez zautomatyzowany system, jest hipotezą dotyczącą przebiegu treningu, a nie wynikiem dotyczącym gotowego modelu. Jeśli prognoza Eureka Machine była trafna, jest to szablon, który skopiują inne małe zespoły. Jeśli była w przybliżeniu trafna, następny checkpoint się przesuwa, a proporcja się zmienia.

Gdzie to pasuje, jeśli Twój stack agentów jest tylko w połowie lokalny

Powód, dla którego model taki jak Flint ma znaczenie, jest taki, że usuwa jedną pozycję z rachunku, a nie wszystkie. Wnioskowanie lokalne obsługuje pracę, którą można wykonać na własnej maszynie, i nie robi nic dla pracy, której nie można — zadania z długim kontekstem, które się nie zmieści, skoku obciążenia, który przerasta jeden laptop, zadania, w którym większy model jest po prostu lepszy. To sprawia, że większość zespołów utrzymuje dwa systemy.

OrcaRouter to hostowana połowa tego układu i, żeby jasno określić granicę: nie udostępniamy Flinta, a nic w tym tekście nie jest reklamą checkpointu, który hostujemy. Flint to plik do pobrania od Recursive, a nie nasz endpoint. To, co robimy, to wystawienie jednego API przed ponad 200 hostowanymi modelami w cenie katalogowej dostawcy, bez doliczonej marży, kierowanie ruchu między nimi za pomocą łańcucha awaryjnego opartego na konfiguracji oraz automatyczne przełączanie awaryjne, gdy dostawca zawiedzie w trakcie żądania. Jeśli chcesz porównać, ile warta jest lokalna sesja Flinta wobec hostowanego modelu typu mixture-of-experts o podobnym rozmiarze — Qwen3.6-35B-A3B i Gemma 4 26B-A4B są wywoływalne przez ten jeden klucz — takie porównanie kosztuje jedno żądanie, a nie wdrożenie.

Rozsądna interpretacja

Flint to prawdziwe wydanie o konkretnym i nietypowym środku ciężkości. Recursive nie wydało najsilniejszego modelu do kodowania, jaki mogłoby stworzyć; wydało najszybszy, jaki dało się zbudować w rozmiarze mieszczącym się na laptopie, a następnie opublikowało stos kwantyzacji i jąder zaprojektowany tak, by ta przewaga przetrwała zetknięcie z 4-bitowymi wagami. Wyniki 54,9% w Terminal-Bench 2.1 i 89,7% w SWE-bench Pro v2 są mocne jak na rzadki model o 40 miliardach parametrów i na razie są to wyłącznie dane producenta.

To, co sprawia, że warto się temu przyglądać, zamiast tylko to pobierać, to metoda, która za tym stoi. Zespół, który twierdzi, że architekturę, recepturę kwantyzacji i jądra wybrała zautomatyzowana pętla badawcza, składa deklarację o procesie, a nie o modelu, a procesy można testować w sposób, w jaki benchmarki premierowe nie pozwalają: następne wydanie albo pojawi się szybciej i lepsze, albo nie. Flint jest pierwszym punktem danych w tym argumencie, udostępnionym na licencji wystarczająco permisywnej, by każdy mógł samodzielnie sprawdzić wagi.

Jeśli masz 48 GB zunifikowanej pamięci i komputer z Apple Silicon, kosztem przekonania się jest pobranie 22,86 GB i jedno popołudnie. Jeśli nie masz, uczciwym stanowiskiem jest poczekać na pierwszy niezależny eval, ponieważ jednodniowa tabela wyników benchmarków jest obietnicą, a nie pomiarem.