Recipes/Ripple-65B Preview · 1× RTX PRO 6000
Recipe 002 · Dense 65B · One card · 600 W
135 tokens a second from a dense 65B, on one card.
Ripple-65B Preview reads all of its weights for every pass, so on its own one card writes 24 tokens a second. Ricursive's DFlash2 drafter turns each pass into several tokens: 135.2 tok/s on code and 97.9 on reasoning, one request at a time, with Ricursive's own NVFP4 weights and flags. One command starts the same server.
Is it any good
Early signs say yes. Not a thorough test.
A short check on 4 November, on the BF16 weights, paired item by item with DeepSeek-V4.1-Flash on the same harness.
19/20 on our private coding set
Twenty real defects from our own code, each fixed with a regression test. DeepSeek-V4.1-Flash also scored 19/20; each missed a different task.
30/40 on a reasoning mix
AIME 2026 7/8, HMMT February 2026 5/8, GPQA-Diamond 18/24, against DeepSeek-V4.1-Flash's 32/40: within noise (McNemar p = 0.63). 9 of the 10 misses ran out of a 16K-token budget; on the items it finished it was 30/31.
Tools (auto, required, parallel, a full round trip), JSON-schema output and a 30K-token needle all worked. A small sample on one harness: treat it as worth your time, not as a ranking.
Why it is fast
One pass over the weights, several tokens out.
A dense model touches every weight on every pass. The time to stream them out of memory caps decode at one token per pass, and a drafter is the way past it.
Without drafts, 76% of the ceiling
Ricursive's NVFP4 export stores the MLPs in 4 bits (28 GB) and keeps attention in BF16 (27 GB). With the 2 GB output head, about 57 GB moves per pass. At 1.79 TB/s that allows about 31 tok/s. Measured: 41.7 ms per token, 24.0 tok/s.
DFlash2 checks 16 tokens per pass
Ricursive's 4.04B, 5-layer drafter drafts a whole 16-token block at once from the model's own hidden states, and one pass of the 65B checks it. A step reads about 65 GB and takes 51.6 ms. The model keeps only tokens it would have picked itself.
Predictable text lands more per step
Code-v1 lands 6.9 tokens per step, reasoning-v1 5.1, the 1,000-line script 6.9 and the essay 3.9. Step time barely moves, so tokens per step sets the speed.
The flags were already right
A profile of 30 steps: BF16 matrix multiplies 50% of GPU time, FP4 MLP multiplies 38%, both at about 1.46 TB/s, 82% of peak. Nothing in our sweep beat Ricursive's DGX Spark flags; the next gain needs fewer bytes, a quantization project.
In our coding agent, with about 18K tokens of system prompt and tools before every request, we saw a steady 50-70 tok/s on prose and 110-120 on long code after warmup. That is below the bare-API numbers above: the long context makes each step slower, and the agent samples with its own settings rather than at temperature 0.
What we tried
The vendor's flags, against every alternative that ran.
Screening runs, 3 after 1 warmup, so read them against each other. Milliseconds per step is the fair comparison, because tokens per step moves run to run.
| Change from the vendor flags | Code tok/s | Reasoning tok/s | ms / step | Result |
|---|---|---|---|---|
None./start.sh | 135.6 | 99.7 | 51.6 | kept |
| 32-token draft blocks | 130.0 | 101.9 | 53 | the checkpoint drafts 16-token blocks |
| Marlin FP4 GEMM | 133.1 | 102.0 | 51.6 | equal, slower prefill |
| cuDNN FP4 GEMM | 124.2 | 93.6 | 55 | slower |
| Triton attention | 112.8 | 91.1 | 55 | slower |
| Online FP8 attention q, k, v, o projections | 116.7 | 95.6 | 53 | fewer bytes, but 6.2 tokens per step instead of 7.0 |
| Decode-mode verify attention | 133.0 | 100.0 | 51.2 | equal |
No drafter./start.sh nospec | 24.0 | 24.0 | 41.7 per token | the reference |
Swipe the table for more →
Did not run: cuteDSL FP4 (no SM120 support), torch.compile (CUDA-graph capture fails) and an FP8 drafter (Ricursive's loader requires BF16).
Run it
One command builds, downloads, starts and checks it.
Clone and start
git clone https://github.com/puretensor/Ripple-65B-Preview-1x-RTX-PRO-6000
cd Ripple-65B-Preview-1x-RTX-PRO-6000
./start.sh dflash --print # show the exact server command, start nothing
./start.sh # Python env, 62 GB of weights, SGLang, then a smoke testThe first start compiles kernels and captures CUDA graphs, which takes a few minutes. It ends by printing the server's address.
Talk to it
curl -s http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
"model": "ripple",
"messages": [{"role": "user", "content": "Write a Python function that merges two sorted lists."}],
"max_tokens": 4096
}'Any OpenAI client works with base_url = "http://127.0.0.1:8000/v1"; tool calls and reasoning_content come back parsed. Set GPU, PORT, CONTEXT or MODELS_DIR to change the card, the port, the context or where weights go.
Measure your card
python3 bench.py # LocalMaxxing's prompts plus ours, temperature 0, median of 5It prints decode speed, time to first token, tokens per step and milliseconds per step, so you can see which of the two differs from ours.
One RTX PRO 6000
96 GB, with about 85 GB free. Measured on the 600 W Workstation Edition; the Max-Q is not measured.
CUDA 13 and uv
A CUDA 13 toolkit with nvcc (we used 13.2) for SGLang's kernels, and uv for the pinned environment. Tested on driver 615.71.09.
Disk
54 GB for the NVFP4 weights, 7.6 GB for the drafter, about 10 GB for the Python environment.
Pinned
Weights by commit, every Python package by version, Ricursive's model plugin by sha256.
Receipts
Eight runs, all linked.
Each LocalMaxxing run page holds the prompt, the model's output, the engine's own timings and the exact launch command. Runs on LocalMaxxing's canonical prompts are Verified; the others are marked unverified only because their prompts are not canonical.
How each number was measured
One request at a time, temperature 0, 2 warmups discarded and the median of 5 kept, each prompt behind LocalMaxxing's cache-bust nonce. Ripple reasons when it needs to and has no switch, so reasoning tokens count as output. Decode is (output tokens − 1) divided by the time from the first token to the last; tokens per step come from SGLang's per-request counts.
How the setup was chosen
One change at a time against Ricursive's flags, compared on milliseconds per step, plus a profiler capture. Nothing beat the vendor flags, so there was no gain to confirm with fresh-boot A/B runs. The canonical runs had the CPU in a performance window; the essay and script runs did not.
Reproduced from a fresh clone
On 5 November we cloned the recipe on the same card, with the CPU in its normal state and the default 64K context. start.sh built the environment from the lock file, reused the pinned weights already on disk and was serving in 354 s. bench.py then measured 131.9 tok/s on code and 101.6 on reasoning, at 51.1 and 51.6 ms per step: the Verified runs' step time, with tokens per step moving as the output does.
Credits
Ricursive Intelligence for Ripple-65B Preview, the NVFP4 export, the DFlash2 drafter and the SGLang plugin and Spark launcher this server is built from; SGLang, FlashInfer, and LocalMaxxing for the prompts and verification.
Licenses
The recipe's scripts are MIT. The weights and Ricursive's plugin are Apache-2.0 and download from Hugging Face; nothing is redistributed.