Ripple-65B Preview came out on 4 November from Ricursive: a 65B dense model for agentic coding, under Apache 2.0. Its card puts it at 80.5 on Terminal-Bench 2.1 and 76.5 on SWE-bench Verified, next to mixture-of-experts models of 500B to 975B. Those are Ricursive's own numbers; nobody outside has checked them yet, and we did not either.
What we did check is the other half of the pitch: a model in that league that fits on one GPU. We served it with vLLM on a rented H200 NVL and measured it.
What we measured
On one H200 NVL (141 GB) rented on ParalonCloud at $3.50 an hour, vLLM nightly, weights in FP8, requests of 1,024 tokens in and 512 out:
| Concurrent requests | Output tok/s, in total | Time to first token (median) | Per user, ms a token |
|---|---|---|---|
| 1 | 43 | 0.20 s | 23.2 |
| 8 | 307 | 0.25 s | 24.4 |
| 16 | 619 | 0.27 s | 25.4 |
| 32 | 662 to 709 | 3.3 to 4.3 s | 39 |
| 64 | 1,197 | 0.89 s | 40.8 |
| 128 | 1,127 | 5.5 s | 102.5 |
| Long prompts, one request | Time to first token | Then |
|---|---|---|
| 16,000 tokens | 3.8 s (about 4,200 tokens/s of prefill) | 23.4 ms a token |
| 60,000 tokens | 12.2 s (about 4,900 tokens/s) | 24.1 ms a token |
| Memory | |
|---|---|
| Weights, FP8 | 62.6 GiB |
| KV cache left | 61 GiB, 486,626 tokens |
| Requests of the full 65,536 tokens at once | about 7 |
What that means:
- One user gets about 43 tokens a second, steady from a short prompt to 60,000 tokens: every token reads all 65 billion parameters, and a dense model pays for that every time. It reads faster than anyone types, slower than the small MoE models people are used to.
- The card fills up at about 64 requests: 1,197 tokens a second in total, each user still at about 25 tokens a second. At 128 the total does not grow, and the wait for the first token does: half the requests waited over 5.5 seconds, the slowest 29.
- 32 is an odd point. We ran it twice and got the same thing both times: lower total than 64 and a first token that takes 3 to 4 seconds, against 0.27 s at 16 and 0.89 s at 64. We used vLLM's default scheduler settings and did not tune them; if you serve at that load, try
--max-num-batched-tokensbefore you size anything on our number.
What it costs
| At $3.50 an hour | Output tokens an hour | Per million output tokens |
|---|---|---|
| One request at a time | 153,000 | about $22.80 |
| 64 at a time | 4.3 million | about $0.81 |
The rental bills by the minute, so a coding agent you run for an afternoon costs the afternoon. Per token, the model only gets cheap with many requests at once: as a shared endpoint for a team, or for agents running in parallel.
How to run it
It does not start yet with a plain pip install vllm. Two things to know:
- vLLM's latest release (0.33.0) does not know the model. It stops with
Model architectures ['RicursiveForCausalLM'] are not supported for now. Support was merged on 5 November (vllm#65745) and is in the nightly builds only. - It needs
--trust-remote-code, since its configuration class lives in the model's repository.
On a rented GPU with 141 GB (an H200), in JupyterLab's terminal or over SSH:
python3 -m venv ~/vllm
~/vllm/bin/pip install -U --pre vllm --extra-index-url https://wheels.vllm.ai/nightly
~/vllm/bin/hf download ricursiveAI/Ripple-65B-Preview
~/vllm/bin/vllm serve ricursiveAI/Ripple-65B-Preview --trust-remote-code \
--served-model-name ripple --quantization fp8 \
--max-model-len 65536 --gpu-memory-utilization 0.92 \
--reasoning-parser ripple
| Step | On our H200 |
|---|---|
| Download, 129.6 GB of BF16 weights | 20.5 minutes (about 105 MB/s; it depends on the machine's connection) |
| Start, with the weights on disk | 2 min 14 s: 23 s to load, 54 s to compile, the rest warm-up |
Then it answers on localhost:8000/v1 like any OpenAI-compatible server. Any tool that takes an OpenAI base URL can use it, coding agents included.
Why FP8 and not the NVFP4 checkpoints. Ricursive and Red Hat publish 4-bit NVFP4 versions (44 to 57 GB). NVFP4 is built for Blackwell's FP4 hardware, which an H200 does not have, so on Hopper we loaded the BF16 weights and let vLLM quantize them to FP8 as it loads them (--quantization fp8). They take 62.6 GiB that way, which leaves 61 GiB of the card for context. BF16 itself, at 129.6 GB, would leave almost nothing.
Good to know
- We measured speed, not quality. The scores above are Ricursive's. The model is a preview, and its card says its post-training was light.
- 65,536 tokens was our choice, not the model's limit; Ricursive gives it up to about a million. More context per request means fewer requests at once: the cache holds 486,626 tokens in all.
- The numbers come from random prompts. A coding agent sends long prompts that share most of their text from one turn to the next, so vLLM's prefix cache makes later turns start faster than our first-token times.
- Everything is deleted when the rental ends, the 130 GB download too. If you will run it again, keep the rental, or count 20 minutes to download it again.
The raw results of every run, and the script: bench.sh, c1.json, c8.json, r16.json, c32.json and r32.json, c64.json, c128.json, long16000.json, long60000.json.
Want to try it? Rent an H200, billed by the minute.
