Ripple-65B Preview: En endpoint för 0,20 $, en inbyggd vLLM-sammanslagning och tre kontextnummer

Vikterna landade 02:41 UTC den 4 november. Nitton timmar senare öppnade någon en pull request för att lägga in dem i vLLMs huvudgren, och 17:36 UTC den 5 november mergades den – 1 153 tillagda rader i 27 filer. Det är snabbt även för att vara en modellrelease med mycket uppmärksamhet kring sig, och det förändrar något specifikt: fram till den sammanslagningen, Ripple-65B Preview – den 65B dense Apache 2.0-checkpointen från Ricursive Intelligence – hade exakt en dokumenterad serveringsväg, en plugin som författarna levererade utanför motorn. Frågan för den som utvärderar den är inte längre om den kan serveras. Det är vilket av de nu officiella sätten att servera den som passar din hårdvara, och vad vart och ett av dem i tysthet kostar dig.

Två fakta ligger bakom den frågan, och de drar åt olika håll. Inbyggt stöd i vLLM gör självhosting rimligt för team som aldrig fick SGLang-scriptet utanför trädet att fungera. De värdbaserade listningarna å andra sidan stämmer fortfarande inte överens med modellkortet om hur mycket kontext man faktiskt får — en tjänstesida lyfter fram 128K i sin specifikationssidopanel, medan avsnittet med modellkortet på samma sida säger upp till 1 048 576 token, och den första kommersiella endpointen som hade modellen serverade 16 384. Ingen av fakta löser vad en 65B-modell som annonserar en kontext på en miljon token ska göra när endpointen framför den säger 128K.

Vad saknades egentligen före sammanslagningen

Ledtråden finns i pull requestens egen beskrivning, där det står att före den "var den enda serveringsvägen författarnas SGLang-plugin utanför kodträdet". Det pluginpaketet levererades med modellkortet som en SGLang 0.5.19-uppsättning, vilket innebär att den som ville servera Ripple-65B Preview antingen måste använda en specifik motorversion med ett externt skript, eller skriva sin egen modelldefinition mot en checkpoint som deklarerar en anpassad arkitektur.

Den andra punkten är den som tyst dödar införandet. BF16-repositoriet har taggen custom_code, och konfigurationen identifierar arkitekturen som RicursiveForCausalLM – ett namn som ingen motor hade hört talas om för en vecka sedan. Att läsa in det innebar --trust-remote-code, vilket i de flesta produktionsmiljöer är ett samtal med en säkerhetsgranskare innan det är ett tekniskt beslut.

Sammanslagningen tar bort det steget i stället för att kringgå det. PR:en lägger till en inbyggd RicursiveConfig, så checkpointen laddas utan --trust-remote-code, och den registrerar arkitekturen i modellregistret tillsammans med alla andra förstklassiga familjer. Ett parallellt arbete för att göra samma sak för SGLang är fortfarande öppet och har inte slagits samman, så vLLM är för närvarande den enda etablerade motorn där den här modellen är en medborgare som stöds i stället för ett skript.

De delar av sammanslagningen som är viktigare än modellfilen

En modellimplementation på 413 rader är den oglamorösa halvan. De intressanta tilläggen är de som får modellen att bete sig som det som dess benchmarksiffror beskriver.

• Resonemang och verktygsanrop — sammanslagningen lägger till --reasoning-parser ripple och --tool-call-parser ripple, som hanterar ett valfritt think-block och Hermes-liknande JSON-verktygsanrop, med strömmande utdata som matchar den icke-strömmande formen. Utan dessa returnerar en agentisk modell text som du själv måste tolka, och det är i tolkningen som driftsatta agenter misslyckas.

• Ett validerat recept – recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 rader, använder som standard NVFP4-checkpointen på en enda B300, med en BF16-variant och parserna inkopplade. Det klarar receptrepots egen validate-source.mjs. Detta är det närmaste en officiell "kör det så här" som finns för modellen.

• Spekulativ avkodning via draft-checkpointen — repot levereras med en drafter på 4.04B, och sammanslagningen lär vLLM att läsa dess NoPE-lagerlayout via no_rope_layers. På GSM8K rapporterar PR:en att den genomsnittliga acceptanslängden ökar från 4.98 till 7.34 token per verifieringssteg.

• 158 rader parsertester, plus en spårbyggare, vilket är den minst synliga och mest betryggande delen: resonemangsparserns beteende är förankrat av tester snarare än av en kommentar.

Varför acceptanslängd är måttet att hålla koll på, inte tokens per sekund

Ricursives egen effektivitetssiffra är 250 tokens per sekund på två B200:or med batchstorlek 8, före kvantisering eller anpassade kärnor. Den siffran mättes med författarnas egen SGLang-bygge, på den checkpoint-revision de testade. Det är ett bra tak men ett dåligt planeringsunderlag, eftersom det som avgör om en agentloop känns snabb är hur många tokens som överlever verifieringen per utkastpass.

Utkastmodellen hjälper till där och bara där. Den föreslår block med 16 token och 32 kandidater per position och läser intermediära dolda tillstånd från målmodellen i lager 1, 20, 39, 58 och 77 – en 4.04B-modell vars enda uppgift är att gissa vad 64.8B-modellen kommer att säga härnäst. Dess eget modellkort är noggrant med förutsättningarna: valideringen kördes på åtta H100:or under ripple-sglang mot RL-step-500-checkpointen, och kortet säger uttryckligen att detta "inte fastställer kompatibilitet eller prestanda för andra målrevisioner eller körtidsversioner."

{{1}}Läs den meningen två gånger innan du bygger en latensbudget på 7.34.{{/1}} {{2}}Det är en mätning på samma revision och samma körtid.{{/2}} {{3}}vLLM-sammanslagningen ändrar körtiden.{{/3}} {{4}}Ingen har ännu publicerat någon siffra för acceptanslängd för den sammanslagna vägen, vilket är det första jag skulle mäta på min egen trafik i stället för att låna.{{/4}}

Vad nedladdningen kostar dig, och på vilken hårdvara den passar

BF16-instruct-repot är 129,6 GB fördelat på 16 shards, och safetensors-metadatan uppgår till totalt 64 782 689 360 parametrar – densa, alla aktiva för varje token. Det finns ingen expertrouting att utnyttja och inget sätt att byta aktiva parametrar mot kvalitet. Om du vill ha fullprecisionsmodellen är det det antalet du dimensionerar för, plus KV-cache.

• Kvantiserad väg – NVFP4-repot lagrar 39 616 865 360 parametrar, ungefär 61 % av BF16-antalet, och det sammanslagna receptet använder den som standard på en enda B300.

• Utkastväg — lägg till 4,04B parametrar och en andra KV-väg om du aktiverar DFlash2; receptet låter det vara opt-in i stället för standard.

• Påståenden om en enda arbetsstation – Ricursive säger att modellen får plats på en NVIDIA DGX Spark, och en communityrapport visar att den körs på tre Radeon AI PRO R9700-kort under ROCm 7.2.1. Båda är trovärdiga för den kvantiserade checkpointen och ingen av dem åtföljs av en genomströmningssiffra som jag skulle ange som en servicenivå.

• Parallelism — sammanslagningen gör uttryckligen anspråk på tensor-parallellism, pipeline-parallellism, torch.compile och CUDA-grafer, vilket är det som gör multi-GPU-servering av en tät 65B-modell praktiskt genomförbar i stället för visionär. Täta modeller delas upp rent, och 65B över fyra 80GB-kort är en bekväm tensor-parallell-4-layout i BF16.

Kontextfönstret är fortfarande tre olika nummer

Detta är den olösta punkten, och den överlevde sammanslagningen orörd eftersom det är en fråga om serveringskonfiguration snarare än en motorfråga.

Modellkortet annonserar "upp till 1M kontextlängd", och konfigurationen stöder positioner långt bortom det – träningssteg för lång kontext använde sekvenser på 2M token. Den kommersiella listningen som publicerades den här veckan har ett 128K kontextfönster i rubriken och upprepar 128K i sin specifikationssidopanel, medan samma sidas modellkortsavsnitt säger "kontextlängd på upp till 1 048 576 token". Vid lanseringen betjänade den första värdbaserade endpointen som hade modellen 16 384.

Tre siffror, en checkpoint. Den mest sannolika förklaringen är intetsägande: siffran 1M beskriver vad arkitekturen och vikterna kan göra, och de mindre siffrorna beskriver vad en viss serveringsdriftsättning har konfigurerats och validerats för. Det är en normal lucka. Det är också luckan som avgör om modellen är användbar för agentarbete i repositoriestorlek, eftersom ett fönster på 16K inte kan rymma en stor diff plus dess testutdata, och ett fönster på 128K kan rymma ungefär en.

Om du utvärderar Ripple-65B Preview för agentisk kodning, behandla kontextnumret som en egenskap hos slutpunkten, inte hos modellen, och testa slutpunkten. vLLM-receptet är där du kan ställa in ditt eget.

Var detta lämnar routingbeslutet

Inget av detta ändrar valets form, bara antalet framkomliga vägar dit. Du kan nu köra modellen själv på vLLM med ett officiellt recept, eller anropa en hostad endpoint för ungefär 0,20 dollar per miljon indatatoken och 0,60 dollar per miljon utdatatoken, med cachad indata fakturerad till en bråkdel av det. Det är olika produkter med samma vikter: den ena ger dig kontroll över kontextfönstret och notan, den andra ger dig ett kreditkort och någon annans kö.

OrcaRouter har inte Ripple-65B Preview – katalogen omfattar 200+ modeller och den här är inte en av dem, vilket är värt att säga rakt ut i stället för att antyda något annat. Vad det innebär i praktiken: om anledningen till att du tittar på den här modellen är att den är billig och öppen, är den jämförelse du faktiskt behöver mot något du kan nå med samma nyckel. DeepSeek V4 Pro ligger på $0,66 och $1,98 per miljon med 1M kontext och 384K maximal utdata; Kimi K3.1 Pro ligger på $2,00 och $10,00 med 1M kontext och ett tak för utdata på 943K. Att köra de två via en enda endpoint med automatisk failover är den del av stacken vi kan ta hand om åt dig. Ripple-delen är din att hosta eller köpa.

Vad som fortfarande rapporteras av leverantören, och vad en utomstående hittade

Varje kapacitetssiffra som är kopplad till den här modellen kommer från Ricursive. Terminal-Bench 2.1 på 80,52 är huvudnumret, och kortet innehåller också 80,5 på Terminus 2, 76,5 på SWE-bench Verified, 61,42 på SWE-bench Pro v1.0, 79,1 på SWE-bench Pro v2.0 Hard, 44,3 på DeepSWE 1.1, 39,4 på SciCode och 71,67 på MCP Atlas. Inget av det har reproducerats av ett oberoende labb, och Artificial Analysis har ingen post för modellen – deras modellkatalog returnerar 404 för varje Ripple-slug jag provade, vilket är hur "unscored" ser ut från utsidan.

Den enda oberoende signal som finns pekar i motsatt riktning och förtjänar att uttryckas exakt. En testsvit på 157 tester som heter Cold Iron gav modellen 93 av 157 och placerade den på 28:e plats av 28, fem poäng efter näst lägsta bidraget. Författarens egen uppdelning är mer intressant än placeringen: av 64 misslyckanden var 12 leverantörstimeouts som returnerade noll tokens och 49 var finish=length – modellen tog slut på en utdatabudget på 4 096 tokens innan den producerade ett bedömningsbart svar. Endast tre var missar i innehållet. Om man tillgodoräknade timeouterna skulle det flytta den till 105, fortfarande omkring 26:e plats.

Det är ett resultat som handlar lika mycket om serveringskonfiguration som om förmåga, och det är precis den typen av fel som inbyggt motorstöd med ett validerat recept är tänkt att minska. En modell som slår i taket för utdata på 4K i kodningsuppgifter är en modell som körs fel, inte nödvändigtvis en modell som inte kan koda.

Vad du ska titta på härnäst

Tre saker skulle avgöra den här modellen snabbare än någon ytterligare rapportering. Ett oberoende betyg – i samma stund som Artificial Analysis eller LMArena plockar upp den blir leverantörstabellen kontrollerbar i stället för citerbar. En merge på SGLang-sidan, vilket skulle göra slut på situationen med en enda motor. Och en checkpoint utan "Preview" i namnet, eftersom Ricursive har beskrivit den här utgåvan som avsiktligt lätt eftertränad, med den verkliga interna produkten som en variant för chipdesign.

Fram till dess är den ärliga sammanfattningen av den här veckan snäv och användbar: serveringshistorien förbättrades väsentligt på 36 timmar, förmågehistorien förändrades inte alls, och frågan om kontextfönstret flyttades från modellkortet till din egen konfigurationsfil.