Ripple-65B Preview: un endpoint da $0,20, un merge nativo per vLLM e tre numeri di contesto

I pesi sono arrivati alle 02:41 UTC del 4 novembre. Diciannove ore dopo qualcuno ha aperto una pull request per inserirli nel branch principale di vLLM, e alle 17:36 UTC del 5 novembre è stato integrato — 1.153 righe aggiunte in 27 file. È veloce anche per gli standard di un rilascio di modello su cui c'è molta attenzione, e cambia qualcosa di specifico: fino a quel merge, Ripple-65B Preview — il checkpoint denso da 65B con licenza Apache 2.0 di Ricursive Intelligence — aveva esattamente un percorso di serving documentato, un plugin che gli autori distribuivano fuori dal motore. La domanda per chiunque lo valuti non è più se possa essere servito. È quale dei modi ora ufficiali di servirlo si adatti al tuo hardware, e quanto ciascuno di essi ti costi silenziosamente.

Due fatti stanno dietro a quella domanda e tirano in direzioni opposte. Il supporto nativo di vLLM rende plausibile il self-hosting per team che non sono mai riusciti a far funzionare lo script SGLang out-of-tree. Le schede dei servizi ospitati, nel frattempo, continuano a non concordare con la model card su quanto contesto si ottenga davvero — una pagina di servizio mette in evidenza 128K nella barra laterale delle specifiche, mentre la sezione della model card sulla stessa pagina dice fino a 1.048.576 token, e il primo endpoint commerciale a offrire il modello serviva 16.384. Nessuno dei due fatti risolve cosa dovrebbe fare un modello da 65B che pubblicizza un contesto da un milione di token quando l'endpoint che lo espone dice 128K.

Cosa mancava effettivamente prima del merge

L'indizio è nella descrizione stessa della pull request, che afferma che prima di essa «l'unico percorso di serving era il plugin SGLang out-of-tree degli autori». Quel plugin era fornito con la model card come setup SGLang 0.5.19, il che significa che chiunque volesse servire Ripple-65B Preview doveva adottare una versione specifica del motore con uno script esterno, oppure scrivere la propria definizione del modello rispetto a un checkpoint che dichiara un'architettura personalizzata.

Quel secondo punto è quello che, in sordina, uccide l'adozione. Il repository BF16 porta il tag custom_code, e la configurazione identifica l'architettura come RicursiveForCausalLM — un nome che nessun motore aveva mai sentito una settimana fa. Caricarlo significava --trust-remote-code, che nella maggior parte degli ambienti di produzione è una conversazione con un revisore della sicurezza prima ancora che una decisione tecnica.

Il merge elimina quel passaggio invece di aggirarlo. La PR aggiunge un RicursiveConfig integrato, così il checkpoint si carica senza --trust-remote-code, e registra l'architettura nel registro dei modelli insieme a ogni altra famiglia di prima classe. Un'iniziativa parallela per fare lo stesso con SGLang è ancora aperta e non unita, quindi vLLM è attualmente l'unico motore mainstream in cui questo modello è un cittadino supportato anziché uno script.

Le parti del merge che contano più del file del modello

Un'implementazione del modello di 413 righe è la metà meno affascinante. Le aggiunte interessanti sono quelle che fanno sì che il modello si comporti come ciò che i suoi numeri di benchmark descrivono.

• Ragionamento e chiamate agli strumenti — il merge aggiunge --reasoning-parser ripple e --tool-call-parser ripple, che gestiscono un blocco think opzionale e chiamate agli strumenti JSON in stile Hermes, con output in streaming corrispondente alla forma non-streaming. Senza questi, un modello agentico restituisce testo che devi analizzare da solo, e il parsing è il punto in cui gli agenti in produzione falliscono.

• Una ricetta convalidata — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 righe, usa per impostazione predefinita il checkpoint NVFP4 su una singola B300, con una variante BF16 e i parser già collegati. Supera il validate-source.mjs del repository delle ricette stesso. È la cosa più vicina a un "eseguilo così" ufficiale che esista per il modello.

• Decodifica speculativa tramite il checkpoint draft: il repository include un drafter da 4,04B e il merge insegna a vLLM a leggere il layout dei suoi layer NoPE tramite no_rope_layers. Su GSM8K la PR riporta una lunghezza media di accettazione che sale da 4,98 a 7,34 token per passaggio di verifica.

• 158 righe di test del parser, più un costruttore di trace, che è la parte meno visibile e più rassicurante: il comportamento del parser di reasoning è fissato dai test anziché da un commento.

Perché la lunghezza di accettazione è il numero da tenere d'occhio, non i token al secondo

Il dato di efficienza dichiarato da Ricursive è di 250 token al secondo su due B200 con batch size 8, prima della quantizzazione o di kernel personalizzati. Quel numero è stato misurato con la build SGLang degli stessi autori, sulla revisione del checkpoint che hanno testato. È un buon tetto massimo e un pessimo dato su cui pianificare, perché ciò che determina se un ciclo di agente sembra veloce è quanti token sopravvivono alla verifica per ogni passata di draft.

Il drafter aiuta lì e solo lì. Propone blocchi da 16 token con 32 candidati per posizione e legge gli stati nascosti intermedi dal target ai layer 1, 20, 39, 58 e 77 — un modello da 4,04B il cui unico compito è indovinare cosa dirà dopo il modello da 64,8B. La sua scheda è cauta riguardo alle condizioni: la validazione è stata eseguita su otto H100 con ripple-sglang rispetto al checkpoint RL-step-500, e la scheda afferma chiaramente che ciò "non stabilisce compatibilità o prestazioni per altre revisioni del target o versioni del runtime".

Leggi quella frase due volte prima di costruire un budget di latenza su 7.34. È una misurazione sulla stessa revisione e sullo stesso runtime. Il merge di vLLM cambia il runtime. Nessuno ha ancora pubblicato un valore di lunghezza di accettazione per il percorso integrato, che è la prima cosa che misurerei sul mio traffico invece di prenderlo in prestito.

Quanto ti costa il download e su quale hardware è compatibile

Il repository instruct BF16 è di 129,6 GB su 16 shard, e i metadati safetensors totalizzano 64.782.689.360 parametri — densi, tutti attivi su ogni token. Non c'è alcun routing di esperti da sfruttare e nessun modo di scambiare parametri attivi con la qualità. Se vuoi il modello a piena precisione, è quello il numero su cui dimensionare, più la KV cache.

• Percorso quantizzato — il repository NVFP4 memorizza 39.616.865.360 parametri, circa il 61% del conteggio BF16, e la ricetta unificata lo adotta per impostazione predefinita su un singolo B300.

• Percorso draft — aggiunge 4,04B parametri e un secondo percorso KV se abiliti DFlash2; la ricetta lo lascia opt-in anziché predefinito.

• Dichiarazioni per singola workstation: Ricursive afferma che il modello entra in un NVIDIA DGX Spark, e un resoconto della community lo vede in esecuzione su tre schede Radeon AI PRO R9700 con ROCm 7.2.1. Entrambe sono credibili per il checkpoint quantizzato e nessuna delle due include un dato di throughput che citerei come livello di servizio.

Parallelismo — il merge dichiara esplicitamente tensor parallel, pipeline parallel, torch.compile e CUDA graphs, ed è ciò che rende praticabile anziché aspirazionale il serving multi-GPU di un modello dense da 65B. I modelli dense si suddividono in modo pulito, e 65B su quattro schede da 80GB è un layout tensor-parallel-4 confortevole in BF16.

La finestra di contesto è ancora tre numeri diversi

Questo è l'elemento irrisolto, ed è sopravvissuto indenne al merge perché è una questione di configurazione del serving anziché una questione del motore.

La model card pubblicizza «una lunghezza di contesto fino a 1M», e la configurazione supporta posizioni ben oltre tale limite — le fasi di addestramento a contesto lungo hanno utilizzato sequenze da 2M token. L'elenco commerciale pubblicato questa settimana mette in evidenza nel titolo una finestra di contesto di 128K e ripete 128K nella barra laterale delle specifiche, mentre la sezione model card della stessa pagina afferma «lunghezza di contesto fino a 1.048.576 token». Al lancio, il primo endpoint ospitato che includeva il modello offriva 16.384.

Tre numeri, un checkpoint. La spiegazione più probabile è banale: la cifra di 1M descrive ciò che l'architettura e i pesi possono fare, mentre le cifre più piccole descrivono per cosa è stato configurato e validato un determinato deployment di serving. Si tratta di un divario normale. È anche il divario che decide se il modello è utilizzabile per il lavoro degli agenti su scala di repository, perché una finestra da 16K non può contenere un diff di grandi dimensioni più il relativo output dei test, e una finestra da 128K può contenerne circa uno.

Se stai valutando Ripple-65B Preview per il coding agentico, considera il numero di contesto come una proprietà dell'endpoint, non del modello, e metti alla prova l'endpoint. La ricetta vLLM è il punto in cui puoi impostare il tuo.

Dove questo lascia la decisione di routing

Niente di tutto ciò cambia la forma della scelta, solo il numero di percorsi praticabili per arrivarci. Ora puoi eseguire il modello in autonomia su vLLM con una ricetta ufficiale, oppure chiamare un endpoint ospitato a circa $0,20 per milione di token di input e $0,60 per milione di output, con l'input in cache fatturato a una frazione di tale importo. Sono prodotti diversi con gli stessi pesi: uno ti dà il controllo della finestra di contesto e del conto, l'altro ti dà una carta di credito e la coda di qualcun altro.

OrcaRouter non include Ripple-65B Preview — il catalogo conta oltre 200 modelli e questo non è tra loro, cosa che vale la pena dire chiaramente anziché lasciar intendere il contrario. In pratica: se stai guardando questo modello perché è economico e aperto, il confronto che ti serve davvero è con qualcosa che puoi raggiungere con la stessa chiave. DeepSeek V4 Pro costa $0,66 e $1,98 per milione con contesto da 1M e output massimo di 384K; Kimi K3.1 Pro costa $2,00 e $10,00 con contesto da 1M e un tetto di output di 943K. Far girare quei due tramite un unico endpoint con failover automatico è la parte dello stack che possiamo togliere dalle tue mani. La parte Ripple sta a te: ospitarla o acquistarla.

Cosa è ancora riportato dal fornitore e cosa ha scoperto un esterno

Ogni numero di capacità associato a questo modello proviene da Ricursive. Terminal-Bench 2.1 a 80.52 è il dato di punta, e la scheda riporta anche 80.5 su Terminus 2, 76.5 su SWE-bench Verified, 61.42 su SWE-bench Pro v1.0, 79.1 su SWE-bench Pro v2.0 Hard, 44.3 su DeepSWE 1.1, 39.4 su SciCode e 71.67 su MCP Atlas. Nessuno di questi dati è stato riprodotto da un laboratorio indipendente, e Artificial Analysis non ha alcuna voce per il modello: la sua directory dei modelli restituisce 404 per ogni slug Ripple che ho provato, ed è così che appare "non valutato" dall'esterno.

L'unico segnale indipendente esistente punta nella direzione opposta e merita di essere enunciato con precisione. Una suite di 157 test chiamata Cold Iron ha assegnato al modello un punteggio di 93 su 157 e lo ha collocato al 28º posto su 28, cinque punti dietro la voce successiva più bassa. La suddivisione fornita dall'autore è più interessante della posizione: dei 64 fallimenti, 12 erano timeout del provider che restituivano zero token e 49 erano finish=length — il modello ha esaurito un budget di output di 4.096 token prima di produrre una risposta valutabile. Solo tre erano mancanze di contenuto. Se si considerassero validi i timeout, salirebbe a 105, comunque intorno al 26º posto.

È un risultato che riguarda la configurazione di serving tanto quanto la capacità, ed è esattamente il tipo di errore che il supporto nativo del motore con una ricetta validata dovrebbe ridurre. Un modello che esaurisce un limite di output di 4K su attività di programmazione è un modello gestito male, non necessariamente un modello che non sa programmare.

Cosa guardare dopo

Tre cose risolverebbero la questione su questo modello più rapidamente di qualsiasi ulteriore copertura. Un punteggio indipendente: nel momento in cui Artificial Analysis o LMArena lo rilevano, la tabella del fornitore diventa verificabile anziché citabile. Un merge lato SGLang, che porrebbe fine alla situazione del motore unico. E un checkpoint senza "Preview" nel nome, dato che Ricursive ha descritto questa release come deliberatamente poco post-addestrata, con il vero prodotto interno rappresentato da una variante per la progettazione di chip.

Fino ad allora, la sintesi onesta di questa settimana è circoscritta e utile: la storia del serving è migliorata in modo sostanziale in 36 ore, la storia delle capacità non è cambiata affatto, e la questione della finestra di contesto si è spostata dalla scheda del modello al tuo file di configurazione.