Ricursive Ripple-65B Preview model benchmark: speed and quality

Ricursive Intelligence released Ripple-65B Preview this week. It is a dense model of 65 billion parameters, trained for agentic coding, and Ricursive reports 80.5% on Terminal-Bench 2.1.

Ricursive also says the model fits on a DGX Spark. We measured its 4-bit build with our benchmark feature on two chips: the GB10 of the DGX Spark and of our own server, and an RTX PRO 6000 Blackwell, a workstation card with 96 GB. Then we ran our five quality tests.

The last model we tested on the GB10: Nemotron 3.5 Lightning 30B-A3B vs Qwen3.6 35B-A3B.

The short version

• Speed on a GB10. Ripple writes 4.1 tokens a second for one request, and 19.0 with Ricursive's DFlash2 draft model.
• Speed on an RTX PRO 6000. It writes 23.1 tokens a second, 64.8 with the draft, and 884 in total for sixteen requests at once.
• Quality. Ripple follows instructions better than the Qwen3.6 35B-A3B we serve, 96% against 89%, and codes as well. It trails Qwen a little on tool calls and science questions.
• Memory. The 4-bit weights fill 54 GiB, which fits the GB10's 128 GB with room for a context cache of 255 000 tokens in 20 GiB.

Why a dense model writes slowly

A dense model reads all of its weights from memory for every token it writes, and Ripple's 4-bit weights weigh 57 GB. The GB10 moves 273 GB a second, so one request tops out near 4.8 tokens a second, and Ripple reaches 4.1.

The RTX PRO 6000 moves 1.8 TB a second, six and a half times as much. Ripple writes 23.1 tokens a second there, 74% of that card's ceiling.

Qwen3.6 35B-A3B, the model behind CArouter Cloud's coding endpoint, uses about 3 billion of its parameters for each token. On the GB10 it writes 119 tokens a second as we serve it.

The DFlash2 draft model

A draft model guesses the next few tokens, and the main model checks all of them in one pass over its weights. Ricursive publishes DFlash2 for Ripple, a draft of 8 GB, and we let it guess 7 tokens at a time, as vLLM's own recipe for Ripple does.

On a GB10 where we also read vLLM's counters, Ripple accepted 3 of the 7 guesses on average, so each pass over the weights wrote 4 tokens instead of 1. One request went from 4.1 to 19.0 tokens a second on the GB10, and from 23.1 to 64.8 on the RTX PRO 6000.

The gain shrinks as requests are added, because one pass over the weights already serves every request at once, and checking each request's guesses adds work. With sixteen at once, the draft multiplies the total by 3.2 on the GB10 and by 2.7 on the RTX PRO 6000.

Reading a prompt

Before writing, a model reads the whole prompt. On the GB10, Ripple read an 8 500-token prompt at about 830 tokens a second, so the first token came after about 10 seconds. The RTX PRO 6000 read it at about 3 400 tokens a second, in 2.5 seconds.

Reading is limited by computation rather than memory, and there the model's size counts in full. Qwen3.6 35B-A3B reads a prompt about eight times as fast on the GB10.

Quality

We ran the five tests of our earlier benchmarks on an RTX PRO 6000, where they took under three hours. Qwen's scores come from our earlier runs of the same tests, on the same harness.

Instructions are Ripple's strongest result. On IFEval's 541 prompts, it followed every instruction of 522 and Qwen of 484, a gap too wide for chance.

Coding is level: on 50 BigCodeBench problems, each model solved 30. Both also found a sentence hidden in documents of 16 000 to 100 000 tokens, 12 times out of 12.

Tool calls go both ways. When a request needs a tool, Ripple is often the more accurate, with 60 of 62 simple calls against 57 for Qwen. When the right answer is plain text, it reaches for a tool more often, and it gets 386 of 500 requests right against 403 overall.

Science questions take Ripple a long time. On GPQA Diamond it answered 157 of 198 correctly against 165 for Qwen, and 20 of its answers reached our limit of 32 768 tokens while still reasoning, against 7 for Qwen, which we count as wrong. Ricursive reports 85.2% for the full-precision model at its highest effort.

Chance can explain the gaps on tool calls and science questions at these sample sizes, so the two models stand close on both.

How we measured

We served Ricursive's NVFP4 build, with the feed-forward layers at 4 bits and attention at 16, on the first vLLM build that supports Ripple, a nightly from November 6.

The speed figures come from our benchmark feature, which starts the model on a GB10 or an RTX PRO 6000 and then runs our throughput probe. The probe keeps 1, 4 or 16 requests running for 30 seconds after a 10-second warm-up and counts every token written in that window, then times one long prompt alone. The prompts ask for code.

A draft model sends several tokens in each piece of the stream, so the probe counts tokens as the engine reports them. Counted piece by piece, a window with the draft read 3.4 tokens a second, where the engine wrote 15.8.

We ran both setups on a second GB10 beforehand. Ripple on its own came within 3% of the figures above.

The quality tests ran with the draft model, which leaves the answers' distribution unchanged, and with vLLM's default sampling, which Ripple's checkpoint leaves in place. Each answer could use up to 32 768 tokens, and 8 192 for the long-text test.

What remains open

• Agentic work. Ricursive reports 80.5% on Terminal-Bench 2.1 and 79.1% on SWE-Bench Pro v2.0 Hard, and our tests read single requests.
• Sampling. Ripple ran at vLLM's default temperature of 1.0 and Qwen at its checkpoint's own settings, and either choice moves a score by a few points.
• Long context. Ricursive trained Ripple for up to a million tokens, and we tested up to 100 000.
• Other engines and builds. Ricursive's own DGX Spark notebook runs SGLang with 32 draft tokens, and its full-precision build needs 130 GB. We measured the 4-bit build on vLLM with 7.