Ripple-65B Preview: een endpoint van $0,20, een native vLLM-merge en drie contextgetallen

De gewichten arriveerden om 02:41 UTC op 4 november. Negentien uur later opende iemand een pull request om ze in vLLM's hoofdtak te zetten, en om 17:36 UTC op 5 november werd die samengevoegd — 1.153 toegevoegde regels verspreid over 27 bestanden. Dat is snel, zelfs naar de maatstaven van een modelrelease met veel aandacht ervoor, en het verandert iets specifieks: tot die samenvoeging had Ripple-65B Preview — de 65B dense Apache 2.0-checkpoint van Ricursive Intelligence — precies één gedocumenteerd servingpad, een plugin die de auteurs buiten de engine om leverden. De vraag voor iedereen die het evalueert is niet langer of het geserveerd kan worden. Het is welke van de nu officiële manieren om het te serveren bij je hardware past, en wat elk ervan je stilletjes kost.

Achter die vraag schuilen twee feiten, en die wijzen in tegengestelde richtingen. Native vLLM-ondersteuning maakt self-hosting plausibel voor teams die het out-of-tree SGLang-script nooit aan de praat kregen. De gehoste vermeldingen zijn het ondertussen nog steeds oneens met de modelkaart over hoeveel context je daadwerkelijk krijgt — de ene servicepagina zet 128K als kop in de specificatiezijbalk, terwijl het gedeelte met de modelkaart op dezelfde pagina zegt tot 1.048.576 tokens, en het eerste commerciële endpoint dat het model aanbood, leverde 16.384. Geen van beide feiten lost op wat een 65B-model dat adverteert met een context van een miljoen tokens geacht wordt te doen wanneer het endpoint dat ervoor staat 128K zegt.

Wat er eigenlijk ontbrak vóór de merge

De aanwijzing zit in de beschrijving van de pull request zelf, waarin staat dat vóór deze wijziging "het enige serveerpad de out-of-tree SGLang-plugin van de auteurs was." Die plugin werd bij de modelkaart geleverd als een SGLang 0.5.19-opstelling, wat betekent dat iedereen die Ripple-65B Preview wilde serveren, ofwel een specifieke engineversie met een extern script moest gebruiken, ofwel hun eigen modeldefinitie moest schrijven voor een checkpoint dat een aangepaste architectuur declareert.

Dat tweede punt is wat de adoptie geruisloos de das omdoet. De BF16-repository draagt de custom_code-tag, en de config identificeert de architectuur als RicursiveForCausalLM — een naam die een week geleden nog geen enkele engine kende. Het laden ervan betekende --trust-remote-code, wat in de meeste productieomgevingen eerst een gesprek met een beveiligingsreviewer is voordat het een technische beslissing wordt.

De merge verwijdert die stap in plaats van eromheen te werken. De PR voegt een ingebouwde RicursiveConfig toe, zodat het checkpoint laadt zonder --trust-remote-code, en registreert de architectuur in het modelregister naast elke andere eersteklas familie. Een parallelle inspanning om hetzelfde voor SGLang te doen is nog open en niet samengevoegd, dus vLLM is momenteel de enige gangbare engine waar dit model een volwaardig ondersteund onderdeel is in plaats van een script.

De onderdelen van de merge die belangrijker zijn dan het modelbestand

Een modelimplementatie van 413 regels is de weinig glamoureuze helft. De interessante toevoegingen zijn degene die ervoor zorgen dat het model zich gedraagt als het ding dat zijn benchmarkcijfers beschrijven.

Redeneren en tool-aanroepen — de merge voegt --reasoning-parser ripple en --tool-call-parser ripple toe, die een optioneel think-blok en Hermes-achtige JSON-tool-aanroepen afhandelen, waarbij streaming-uitvoer overeenkomt met de niet-streamingvorm. Zonder deze retourneert een agentisch model tekst die je zelf moet parsen, en het parsen is waar gedeployde agents falen.

• Een gevalideerd recept — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 regels, gebruikt standaard de NVFP4-checkpoint op één B300, met een BF16-variant en de parsers aangesloten. Het doorstaat de eigen validate-source.mjs van de recipes-repository. Dit komt het dichtst in de buurt van een officiële "zo voer je het uit" die voor het model bestaat.

• Speculatief decoderen via het draft-checkpoint — de repository levert een 4,04B-drafter, en de merge leert vLLM de NoPE-laagindeling ervan te lezen via no_rope_layers. Op GSM8K meldt de PR dat de gemiddelde acceptatielengte stijgt van 4,98 naar 7,34 tokens per verificatiestap.

• 158 regels parsertests, plus een trace-builder, het minst zichtbare en meest geruststellende onderdeel: het gedrag van de reasoning-parser wordt vastgelegd door tests in plaats van door een commentaar.

Waarom acceptatielengte het getal is om in de gaten te houden, niet tokens per seconde

Ricursives eigen efficiëntiecijfer is 250 tokens per seconde op twee B200's bij batchgrootte 8, vóór kwantisatie of aangepaste kernels. Dat cijfer is gemeten met de eigen SGLang-build van de auteurs, op de checkpoint-revisie die zij testten. Het is een mooi plafond en een slechte planningsinput, want wat bepaalt of een agentlus snel aanvoelt, is hoeveel tokens per conceptronde de verificatie overleven.

De opsteller helpt daar en alleen daar. Hij stelt blokken van 16 tokens voor met 32 kandidaten per positie en leest tussenliggende verborgen toestanden van het doelmodel op lagen 1, 20, 39, 58 en 77 — een model van 4,04B waarvan de hele taak erin bestaat te raden wat het model van 64,8B hierna zal zeggen. De eigen kaart is zorgvuldig over de voorwaarden: de validatie liep op acht H100's onder ripple-sglang tegen de RL-step-500-checkpoint, en de kaart stelt ronduit dat dit "geen compatibiliteit of prestatie vaststelt voor andere doelrevisies of runtime-versies."

Lees die zin twee keer voordat je een latencybudget op 7.34 bouwt. Het is een meting met dezelfde revisie en dezelfde runtime. De vLLM-merge verandert de runtime. Niemand heeft nog een acceptatielengtecijfer gepubliceerd voor het samengevoegde pad; dat is het eerste dat ik op mijn eigen verkeer zou meten in plaats van over te nemen.

Wat de download je kost, en op welke hardware het past

De BF16-instruct-repo is 129,6 GB verdeeld over 16 shards, en de safetensors-metadata komt uit op 64.782.689.360 parameters — dense, allemaal actief bij elk token. Er is geen expert-routing om te benutten en geen manier om actieve parameters in te ruilen voor kwaliteit. Als je het full-precision-model wilt, is dat het aantal waarop je moet dimensioneren, plus KV-cache.

• Gekwantiseerd pad — de NVFP4-repo bevat 39.616.865.360 parameters, ongeveer 61% van het BF16-aantal, en het samengevoegde recept gebruikt dit standaard op één enkele B300.

• Draft-pad — voeg 4,04B parameters en een tweede KV-pad toe als je DFlash2 inschakelt; het recept laat het opt-in in plaats van standaard.

• Claims voor één werkstation — Ricursive zegt dat het model op een NVIDIA DGX Spark past, en een rapport uit de community laat het draaien op drie Radeon AI PRO R9700-kaarten onder ROCm 7.2.1. Beide zijn geloofwaardig voor het gequantiseerde checkpoint en geen van beide gaat gepaard met een doorvoercijfer dat ik als serviceniveau zou citeren.

• Parallelisme — de merge claimt expliciet tensor-parallelisme, pipeline-parallelisme, torch.compile en CUDA graphs, wat multi-GPU-serving van een 65B-dicht model praktisch maakt in plaats van aspirational. Dichte modellen laten zich netjes splitsen, en 65B over vier kaarten van 80GB is een comfortabele tensor-parallel-4-indeling in BF16.

Het contextvenster is nog steeds drie verschillende getallen.

Dit is het onopgeloste punt, en het is ongewijzigd door de samenvoeging gekomen omdat het een kwestie van serveerconfiguratie is en niet van de engine.

De modelkaart adverteert met 'tot 1M contextlengte', en de configuratie ondersteunt posities ruim daarbuiten — lange-context-trainingsfasen gebruikten sequenties van 2M tokens. De commerciële vermelding die deze week is gepubliceerd, zet een contextvenster van 128K in de kop en herhaalt 128K in de specificatiezijbalk, terwijl het gedeelte met de modelkaart op dezelfde pagina zegt: 'contextlengte tot 1.048.576 tokens'. Bij de lancering serveerde de eerste gehoste endpoint die het model aanbood 16.384.

Drie getallen, één checkpoint. De meest waarschijnlijke verklaring is niets bijzonders: het 1M-cijfer beschrijft wat de architectuur en de gewichten kunnen, en de kleinere cijfers beschrijven waarvoor een gegeven serving-deployment is geconfigureerd en gevalideerd. Dat is een normaal gat. Het is ook het gat dat bepaalt of het model bruikbaar is voor agentwerk op repositoryschaal, omdat een venster van 16K een grote diff plus de testuitvoer niet kan bevatten, en een venster van 128K er ongeveer één kan bevatten.

Als je Ripple-65B Preview evalueert voor agentic coding, beschouw het contextgetal dan als een eigenschap van het endpoint, niet van het model, en test het endpoint. Het vLLM-recept is waar je je eigen waarde kunt instellen.

Wat dit betekent voor de routeringsbeslissing

Niets hiervan verandert de vorm van de keuze, alleen het aantal haalbare paden ernaartoe. Je kunt het model nu zelf draaien op vLLM met een officieel recept, of een gehost endpoint aanroepen voor ongeveer $0,20 per miljoen inputtokens en $0,60 per miljoen outputtokens, waarbij gecachte input tegen een fractie daarvan wordt gefactureerd. Dat zijn verschillende producten met dezelfde gewichten: de een geeft je controle over het contextvenster en de rekening, de ander geeft je een creditcard en andermans wachtrij.

OrcaRouter heeft Ripple-65B Preview niet in het assortiment — de catalogus bevat 200+ modellen en dit is er daar niet één van, wat je beter gewoon duidelijk kunt zeggen dan anders te suggereren. Wat dat in de praktijk betekent: als de reden dat je naar dit model kijkt is dat het goedkoop en open is, dan is de vergelijking die je echt nodig hebt met iets dat je via dezelfde sleutel kunt bereiken. DeepSeek V4 Pro kost $0,66 en $1,98 per miljoen met een context van 1M en een maximale output van 384K; Kimi K3.1 Pro kost $2,00 en $10,00 met 1M-context en een outputplafond van 943K. Die twee via één endpoint laten draaien met automatische failover is het deel van de stack dat we van je kunnen overnemen. Het Ripple-deel is aan jou om te hosten of te kopen.

Wat nog steeds door de leverancier wordt gerapporteerd, en wat een buitenstaander ontdekte

Elk capaciteitscijfer dat aan dit model wordt toegekend, komt van Ricursive. Terminal-Bench 2.1 op 80,52 is het uithangbord, en de kaart vermeldt ook 80,5 op Terminus 2, 76,5 op SWE-bench Verified, 61,42 op SWE-bench Pro v1.0, 79,1 op SWE-bench Pro v2.0 Hard, 44,3 op DeepSWE 1.1, 39,4 op SciCode en 71,67 op MCP Atlas. Niets ervan is gereproduceerd door een onafhankelijk lab, en Artificial Analysis heeft geen vermelding voor het model — de modellenmap ervan geeft 404 voor elke Ripple-slug die ik heb geprobeerd, wat van buitenaf bezien is hoe "unscored" eruitziet.

Het enige onafhankelijke signaal dat bestaat, wijst de andere kant op en verdient het precies te worden verwoord. Een suite van 157 tests genaamd Cold Iron gaf het model een score van 93 van de 157 en plaatste het op de 28e plaats van de 28, vijf punten achter de op één na laagste inzending. De eigen uitsplitsing van de auteur is interessanter dan de rang: van de 64 fouten waren er 12 time-outs bij de provider die nul tokens opleverden en 49 finish=length — het model raakte door een outputbudget van 4.096 tokens heen voordat het een beoordeelbaar antwoord produceerde. Slechts drie waren inhoudelijke missers. Als de time-outs werden meegeteld, zou het naar 105 gaan, nog steeds ongeveer 26e.

Dat is evenzeer een resultaat over serverconfiguratie als over capaciteit, en het is precies de klasse van fouten die native engine-ondersteuning met een gevalideerd recept zou moeten verminderen. Een model dat bij coderingstaken de uitvoerlimiet van 4K bereikt, is een model dat verkeerd wordt gebruikt, niet noodzakelijk een model dat niet kan coderen.

Wat nu te kijken

Drie dingen zouden de kwestie rond dit model sneller beslechten dan welke verdere berichtgeving dan ook. Een onafhankelijke score — zodra Artificial Analysis of LMArena het oppikt, wordt de leverancierstabel controleerbaar in plaats van alleen citeerbaar. Een merge aan SGLang-zijde, waarmee de single-engine-situatie zou eindigen. En een checkpoint zonder "Preview" in de naam, aangezien Ricursive deze release heeft beschreven als bewust licht post-getraind, waarbij het echte interne product een chipontwerpvariant is.

Tot dan is de eerlijke samenvatting van deze week smal en nuttig: het servingverhaal is in 36 uur wezenlijk verbeterd, het capaciteitsverhaal is helemaal niet veranderd, en de vraag over het contextvenster is van de modelkaart naar je eigen configuratiebestand verschoven.