Ripple-65B Preview: punkt końcowy za 0,20 USD, natywne scalenie vLLM i trzy liczby kontekstu

Wagi opublikowano o 02:41 UTC 4 listopada. Dziewiętnaście godzin później ktoś otworzył pull request, aby dodać je do głównej gałęzi vLLM, a 5 listopada o 17:36 UTC został on scalony — 1153 dodane linie w 27 plikach. To szybko nawet jak na wydanie modelu, któremu poświęca się tak wiele uwagi, i zmienia coś konkretnego: do momentu tego scalenia Ripple-65B Preview — gęsty checkpoint 65B na licencji Apache 2.0 od Ricursive Intelligence — miał dokładnie jedną udokumentowaną ścieżkę serwowania, wtyczkę, którą autorzy wydali poza silnikiem. Pytanie dla każdego, kto go ocenia, nie brzmi już, czy można go serwować. Brzmi: która z obecnie oficjalnych metod serwowania pasuje do twojego sprzętu i ile każda z nich po cichu cię kosztuje.

Dwa fakty stoją za tym pytaniem i ciągną w przeciwnych kierunkach. Natywne wsparcie vLLM sprawia, że self-hosting jest realny dla zespołów, którym nigdy nie udało się uruchomić zewnętrznego skryptu SGLang. Tymczasem oferty hostowane nadal nie zgadzają się z kartą modelu co do tego, ile kontekstu faktycznie się dostaje — jedna strona usługi podaje w nagłówku 128K w bocznym panelu specyfikacji, podczas gdy sekcja karty modelu na tej samej stronie mówi o nawet 1 048 576 tokenach, a pierwszy komercyjny endpoint obsługujący ten model serwował 16 384. Żaden z tych faktów nie rozstrzyga, co model 65B reklamujący kontekst miliona tokenów ma właściwie robić, gdy endpoint stojący przed nim mówi 128K.

Czego tak naprawdę brakowało przed scaleniem

Wskazówka tkwi w opisie samego pull requesta, w którym stwierdzono, że przed nim „jedyną ścieżką serwowania był zewnętrzny (out-of-tree) plugin SGLang autorów”. Ten plugin był dostarczany wraz z kartą modelu jako konfiguracja SGLang 0.5.19, co oznaczało, że każdy, kto chciał serwować Ripple-65B Preview, musiał albo przyjąć konkretną wersję silnika z zewnętrznym skryptem, albo napisać własną definicję modelu dla checkpointu deklarującego niestandardową architekturę.

Ten drugi punkt to ten, który po cichu zabija adopcję. Repozytorium BF16 ma tag custom_code, a konfiguracja wskazuje architekturę jako RicursiveForCausalLM — nazwę, o której żaden silnik nie słyszał jeszcze tydzień wcześniej. Ładowanie go oznaczało --trust-remote-code, co w większości środowisk produkcyjnych jest rozmową z recenzentem bezpieczeństwa, zanim stanie się decyzją techniczną.

Merge usuwa ten krok, zamiast go obchodzić. PR dodaje wbudowany RicursiveConfig, dzięki czemu checkpoint ładuje się bez --trust-remote-code, oraz rejestruje architekturę w rejestrze modeli obok każdej innej rodziny pierwszej klasy. Równoległe przedsięwzięcie mające zrobić to samo dla SGLang jest wciąż otwarte i niezmergowane, więc vLLM jest obecnie jedynym silnikiem głównego nurtu, w którym ten model jest pełnoprawnym obywatelem, a nie skryptem.

Części scalenia, które mają większe znaczenie niż plik modelu

Implementacja modelu licząca 413 linii to ta mniej efektowna połowa. Ciekawsze dodatki to te, które sprawiają, że model zachowuje się jak rzecz opisana przez jego wyniki benchmarków.

• Rozumowanie i wywołania narzędzi — scalenie dodaje --reasoning-parser ripple oraz --tool-call-parser ripple, które obsługują opcjonalny blok think i wywołania narzędzi w formacie JSON w stylu Hermes, a dane wyjściowe strumieniowe odpowiadają formie niestrumieniowej. Bez nich model agentowy zwraca tekst, który trzeba samemu sparsować, a właśnie na parsowaniu zawodzą wdrożone agenty.

• Sprawdzony przepis — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 linii, domyślnie używa checkpointu NVFP4 na pojedynczym B300, z wariantem BF16 i podłączonymi parserami. Przechodzi własny validate-source.mjs repozytorium recipes. To najbliższe oficjalnemu „uruchom to w ten sposób”, jakie istnieje dla tego modelu.

• Dekodowanie spekulatywne przez checkpoint draftu — repozytorium dostarcza drafter o rozmiarze 4,04B, a scalenie uczy vLLM odczytywania jego układu warstw NoPE poprzez no_rope_layers. W GSM8K PR raportuje wzrost średniej długości akceptacji z 4,98 do 7,34 tokenów na krok weryfikacji.

• 158 linii testów parsera oraz konstruktor śladów, czyli najmniej widoczna i najbardziej pokrzepiająca część: zachowanie parsera rozumowania jest utrwalone przez testy, a nie przez komentarz.

Dlaczego długość akceptacji to liczba, na którą warto patrzeć, a nie tokeny na sekundę

Własny wskaźnik wydajności Ricursive wynosi 250 tokenów na sekundę na dwóch B200 przy rozmiarze partii 8, przed kwantyzacją lub niestandardowymi jądrami. Liczbę tę zmierzono przy użyciu własnej kompilacji SGLang autorów, na testowanej przez nich wersji checkpointu. To dobra górna granica, ale słabe dane wejściowe do planowania, ponieważ o tym, czy pętla agenta wydaje się szybka, decyduje to, ile tokenów przechodzi weryfikację na jeden przebieg szkicu.

Drafter pomaga tam i tylko tam. Proponuje bloki po 16 tokenów z 32 kandydatami na pozycję i odczytuje pośrednie stany ukryte z modelu docelowego w warstwach 1, 20, 39, 58 i 77 — model 4.04B, którego całym zadaniem jest zgadywanie, co model 64.8B powie następnie. Jego własna karta modelu ostrożnie podchodzi do warunków: walidację przeprowadzono na ośmiu H100 w środowisku ripple-sglang względem checkpointu RL-step-500, a karta wprost stwierdza, że nie potwierdza to zgodności ani wydajności dla innych wersji modelu docelowego ani wersji środowiska uruchomieniowego.

Przeczytaj to zdanie dwa razy, zanim oprzesz budżet opóźnień na 7.34. To pomiar w tej samej wersji i tym samym środowisku uruchomieniowym. Scalanie vLLM zmienia środowisko uruchomieniowe. Nikt jeszcze nie opublikował wartości długości akceptacji dla scalonej ścieżki, a to pierwsza rzecz, którą zmierzyłbym na własnym ruchu, zamiast ją pożyczać.

Ile kosztuje cię pobranie i na jakim sprzęcie się zmieści

Repozytorium BF16 instruct ma 129,6 GB w 16 shardach, a metadane safetensors sumują się do 64 782 689 360 parametrów — gęstych, wszystkich aktywnych przy każdym tokenie. Nie ma routingu ekspertów, który można wykorzystać, ani sposobu, by wymienić aktywne parametry na jakość. Jeśli chcesz model w pełnej precyzji, to właśnie na tę liczbę trzeba zapewnić zasoby, plus KV cache.

Ścieżka skwantyzowana — repozytorium NVFP4 przechowuje 39 616 865 360 parametrów, około 61% liczby w BF16, a połączona receptura domyślnie z niej korzysta na pojedynczym B300.

• Ścieżka draft — dodaje 4,04 mld parametrów i drugą ścieżkę KV, jeśli włączysz DFlash2; przepis pozostawia ją jako opcję do włączenia, a nie ustawienie domyślne.

• Twierdzenia o pojedynczej stacji roboczej — Ricursive twierdzi, że model mieści się na NVIDIA DGX Spark, a raport społeczności wskazuje, że działa on na trzech kartach Radeon AI PRO R9700 w środowisku ROCm 7.2.1. Oba są wiarygodne w przypadku skwantyzowanego checkpointu i żadne nie podaje wartości przepustowości, którą podałbym jako poziom usługi.

• Równoległość — scalenie wprost deklaruje równoległość tensorową, równoległość potokową, torch.compile i grafy CUDA, co sprawia, że obsługa modelu gęstego 65B na wielu GPU jest praktyczna, a nie tylko aspirująca. Modele gęste można czysto dzielić, a 65B na czterech kartach 80GB to wygodny układ tensor-parallel-4 w BF16.

Okno kontekstu to nadal trzy różne liczby.

To jest nierozstrzygnięta pozycja i przetrwała scalenie bez zmian, ponieważ jest to kwestia konfiguracji obsługi, a nie kwestia silnika.

Karta modelu reklamuje „kontekst o długości do 1M”, a konfiguracja obsługuje pozycje znacznie wykraczające poza ten zakres — etapy treningu długiego kontekstu wykorzystywały sekwencje 2M tokenów. Opublikowana w tym tygodniu oferta komercyjna w nagłówku podaje okno kontekstu 128K i powtarza 128K w bocznym panelu specyfikacji, podczas gdy sekcja karty modelu na tej samej stronie mówi o „długości kontekstu do 1,048,576 tokenów”. W momencie premiery pierwszy hostowany endpoint obsługujący ten model oferował 16,384.

Trzy liczby, jeden checkpoint. Najbardziej prawdopodobne wyjaśnienie jest niepozorne: wartość 1M opisuje, co mogą zrobić architektura i wagi, a mniejsze wartości opisują, do czego skonfigurowano i zweryfikowano dane wdrożenie obsługujące. To normalna luka. To także luka, która decyduje, czy model nadaje się do pracy agentowej w skali repozytorium, ponieważ okno 16K nie pomieści dużego diffu wraz z jego wynikami testów, a okno 128K pomieści mniej więcej jeden taki zestaw.

Jeśli oceniasz Ripple-65B Preview pod kątem kodowania agentowego, traktuj liczbę kontekstu jako właściwość endpointu, a nie modelu, i testuj endpoint. To przepis vLLM jest miejscem, w którym możesz ustawić własny.

Co to oznacza dla decyzji o routingu

Nic z tego nie zmienia kształtu wyboru, jedynie liczbę realnych ścieżek do niego. Możesz teraz uruchomić model samodzielnie na vLLM według oficjalnej receptury albo wywołać hostowany endpoint za około 0,20 USD za milion tokenów wejściowych i 0,60 USD za milion wyjściowych, przy czym buforowane wejście jest rozliczane za ułamek tej kwoty. To różne produkty z tymi samymi wagami: jeden daje ci kontrolę nad oknem kontekstu i rachunkiem, drugi daje ci kartę kredytową i cudzą kolejkę.

OrcaRouter nie oferuje Ripple-65B Preview — katalog liczy ponad 200 modeli i tego w nim nie ma, co warto powiedzieć wprost, zamiast sugerować inaczej. Co to oznacza w praktyce: jeśli patrzysz na ten model, bo jest tani i otwarty, porównanie, którego naprawdę potrzebujesz, dotyczy czegoś, do czego możesz dotrzeć na tym samym kluczu. DeepSeek V4 Pro kosztuje $0.66 i $1.98 za milion przy kontekście 1M i maksymalnej długości wyjścia 384K; Kimi K3.1 Pro kosztuje $2.00 i $10.00 przy kontekście 1M i limicie wyjścia 943K. Przepuszczanie tych dwóch przez jeden endpoint z automatycznym przełączaniem awaryjnym to ta część stosu, którą możemy zdjąć ci z głowy. Połowa związana z Ripple należy do ciebie — do hostowania albo kupienia.

Co jest nadal zgłaszane przez dostawcę, a co znalazła osoba z zewnątrz

Każda liczba dotycząca możliwości podana dla tego modelu pochodzi od Ricursive. Terminal-Bench 2.1 z wynikiem 80.52 to najważniejsza informacja, a karta zawiera także 80.5 w Terminus 2, 76.5 w SWE-bench Verified, 61.42 w SWE-bench Pro v1.0, 79.1 w SWE-bench Pro v2.0 Hard, 44.3 w DeepSWE 1.1, 39.4 w SciCode i 71.67 w MCP Atlas. Żadnego z tych wyników nie odtworzyło niezależne laboratorium, a Artificial Analysis nie ma wpisu dla tego modelu — jego katalog modeli zwraca 404 dla każdego sluga Ripple, którego próbowałem, co z zewnątrz wygląda jak „brak oceny”.

Jedyny istniejący niezależny sygnał wskazuje w przeciwnym kierunku i zasługuje na precyzyjne przedstawienie. Zestaw 157 testów o nazwie Cold Iron przyznał modelowi 93 punkty na 157 i umieścił go na 28. miejscu na 28, pięć punktów za następną najniższą pozycją. Własne zestawienie autora jest ciekawsze niż sama pozycja: spośród 64 niepowodzeń 12 stanowiły przekroczenia limitu czasu dostawcy zwracające zero tokenów, a 49 — finish=length; modelowi skończył się budżet wyjściowy 4096 tokenów, zanim zdążył wygenerować odpowiedź możliwą do oceny. Tylko trzy były pomyłkami merytorycznymi. Zaliczenie przekroczeń limitu czasu przesunęłoby go na 105 punktów, co nadal dawałoby około 26. miejsce.

To wynik w równym stopniu dotyczący konfiguracji serwowania, co możliwości, i jest to dokładnie ta klasa błędów, którą natywne wsparcie silnika ze zweryfikowanym przepisem ma ograniczać. Model, który wyczerpuje limit 4K na wyjście przy zadaniach programistycznych, to model uruchamiany nieprawidłowo, a niekoniecznie model, który nie potrafi programować.

Co obejrzeć dalej

Trzy rzeczy rozstrzygnęłyby kwestię tego modelu szybciej niż jakiekolwiek dalsze omówienia. Niezależny wynik — w momencie, gdy przejmie go Artificial Analysis lub LMArena, tabela dostawcy stanie się możliwa do zweryfikowania, a nie tylko do cytowania. Merge po stronie SGLang, który zakończyłby sytuację z jednym silnikiem. Oraz checkpoint bez „Preview” w nazwie, ponieważ Ricursive opisał to wydanie jako celowo lekko poddane post-trainingowi, a prawdziwym produktem wewnętrznym jest wariant do projektowania układów.

Do tego czasu uczciwe podsumowanie tego tygodnia jest wąskie i użyteczne: historia serwowania poprawiła się istotnie w ciągu 36 godzin, historia możliwości nie zmieniła się wcale, a kwestia okna kontekstu przeniosła się z karty modelu do twojego własnego pliku konfiguracyjnego.