You can run Ripple-65B Preview locally today, but none of the routes are stock. A DGX Spark gets about 26 tok/s on code through a community server kit, GGUF files need a patched llama.cpp because Ollama and stock builds can't load them yet, and the MLX build needs --trust-remote-code.
People want it because Ricursive's Apache 2.0 model claims 80.52 on Terminal-Bench 2.1, 0.42 points ahead of the 501B Reflection Beam. The catch is that Ripple is dense: every generated token reads all 65B weights, while Beam's active set is 23B. That makes memory the easy part and bandwidth the thing you'll pay for.
I haven't run the model. The scores are Ricursive's own, each speed below comes from whoever published that build, and repo and PR status is as of November 5, 2026, one day after the preview went up.
How much memory Ripple-65B needs, and how fast each route runs
The BF16 repo is 129.6 GB across 16 shards. Ricursive publishes no minimum VRAM, and the main card names no llama.cpp, Ollama or MLX path. The repo is tagged custom_code. Its server README describes SGLang on two B200s, which is not most people's definition of local.
| Route | Weights | Suggested memory | Reported generation speed |
|---|---|---|---|
| NVFP4 + DFlash2 on DGX Spark | ~65 GB | single GB10 | 20-36 tok/s code (avg 26.5), ~9 prose |
| MLX 4-bit | 37 GB | 64 GB+ Mac | 22.0-23.3 tok/s on an M5 Ultra 256 GB |
| GGUF AD-Q4_K_M | 40.4 GB | 48 GB | not published for this file |
| GGUF plain Q4_K_M | 38.8 GB | not listed | 40.6 tok/s on 1x GH200 96 GB |
| GGUF Q6_K_XL | 52.76 GiB | 96 GB GPU | 26.2 tok/s short prompt on an RTX PRO 6000 |
| GGUF IQ3_XXS (prometheusAIR) | 25.38 GiB | 32 GB GPU, sized but not tested on one | 46.0 tok/s short prompt on the same 96 GB card |
| GGUF AD-IQ2_XXS | 20.0 GB | 24 GB (RTX 3090/4090) | not published |
| Official BF16 | 129.6 GB | 2x B200 | 250 tok/s at batch=8 (Ricursive) |
Each community number is one publisher on one box. The Spark author estimates plain decoding at about 5 tok/s without speculative decoding, so most of that 26.5 comes from DFlash2, and it helps code far more than prose. The card doesn't say whether Ricursive's 250 tok/s is a total across the batch. If it is, that's about 31 tok/s per stream.
I'd skip the 24 GB route for agent work. AD-IQ2_XXS matches BF16's top token 80.8% of the time on AtomicChat's corpus, and AD-Q4_K_M sits at 95.9%. If you quantize your own low-bit file, set the attention types by hand: prometheusAIR measured llama.cpp's stock IQ3_XXS recipe at 70.7% same top token, against 88.30% for its own recipe with attention at IQ4_XS. The two publishers used different test corpora, so only compare numbers from the same one.
How to run Ripple-65B on a DGX Spark
Ricursive ships an experimental NVFP4 checkpoint with MLPs in NVFP4 and attention left in BF16, plus a notebook and an offline spark.py. That script has no HTTP server, so an agent can't talk to it. A community kit wraps it in an OpenAI-compatible API:
git clone https://huggingface.co/rlaope/Ripple-65B-Spark-Server && cd Ripple-65B-Spark-Server
./setup.sh # pinned venv + ~65 GB of weights, into ~/ripple
~/ripple/ripple.sh # first start ~11 min (kernel compile), later ~2 min
Then point your client at http://127.0.0.1:30000/v1 with model ripple. RIPPLE_HOST=0.0.0.0 exposes it to your LAN with no auth, so don't set that casually.
The kit's changes are worth copying if you roll your own. It cuts draft tokens from 32 to 16 (code 23.2 to 24.5 tok/s, prose 7.4 to 9.0) and turns on the radix cache, which spark.py disables. That took next-turn time to first token from 10.2 s to 1.0 s on a 5.8K prompt. Temperature defaults to 0 because the checkpoint ships no sampling defaults, and at 1.0 the author saw non-English answers fall apart. Three concurrent requests raised total throughput from 23.9 to 52.3 tok/s.
The card reports one agent run: Hermes Agent fixed 4 failing tests in a small repo in 1m 36s, with 14 tool calls. I wouldn't generalize from a single run, but it's closer to real use than a tok/s figure.
Ripple-65B GGUF: stock llama.cpp and Ollama won't load it
AtomicChat's card says stock llama.cpp, LM Studio and Ollama don't load these files yet, and mrfakename's card also says a patched llama.cpp is required. Hugging Face still shows a one-line ollama run snippet on both repo pages, so ignore it for now. Support is in PR #31692, still open.
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git fetch origin pull/31692/head:ripple && git checkout ripple
cmake -B build -DGGML_CUDA=ON # Mac: omit -DGGML_CUDA=ON
cmake --build build -j --config Release --target llama-server llama-cli
hf download AtomicChat/Ripple-65B-Preview-GGUF Ripple-65B-Preview-AD-Q4_K_M.gguf --local-dir .
./build/bin/llama-server -m Ripple-65B-Preview-AD-Q4_K_M.gguf --jinja -c 32768 -ngl 99
The chat template, tool calls and <think> reasoning live in the file. AtomicChat's card passes --jinja for that reason, though the flag is already on by default on this branch.
I compiled the branch for CPU on Linux at 6414d5b0c, and llama-server and llama-cli built cleanly. That only proves the build: I didn't try -DGGML_CUDA=ON or Metal, and I didn't load the weights.
Match each GGUF to the build its card names. AtomicChat's files work with the PR branch or its own patch, while mrfakename and prometheusAIR each ship a separate patch against commit 6f1e654. The ports aren't identical: the PR adds a tensor called attn_vres_lambda, and prometheusAIR's patch calls it attn_value_res. I didn't test loading one publisher's file on another's build, and I wouldn't assume it works.
Vulkan users should read the PR thread: a Strix Halo attempt failed, and the PR author suspects a limit on single KV tensor size at 1-2M context.
Ripple-65B on Mac with MLX
The unofficial 4-bit conversion needs mlx-lm 0.32.2 or newer and runs a custom ricursive.py, about 280 lines, so read it before passing the flag:
pip install "mlx-lm>=0.32.2"
mlx_lm.server --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code
Prefill runs at 535-565 tok/s on the M5 Ultra, so a fresh 32K prompt takes about a minute. The publisher checked quality against BF16 on only three prompts.
Ripple-65B's 1M context fits on 96 GB and runs at 6.7 tok/s
Ripple's 16 global-attention layers keep the whole context, at 64 KiB of KV cache per token at 16-bit according to the MLX card. That matches the layer and head counts on AtomicChat's card. prometheusAIR lists 34 KiB per token with a q8_0 cache. My arithmetic from there:
| Context | KV cache at 16-bit | KV cache at q8_0
|
|---|---|---|
32,768 (-c 32768 above) |
2 GiB | ~1 GiB |
131,072 (spark.py default) |
8 GiB | ~4 GiB |
| 1,048,576 | 64 GiB | ~34 GiB |
On a Spark, the full 1M won't fit with spark.py's settings. It refuses anything but a BF16 KV cache and sets --mem-fraction-static 0.78, and 65 GB of weights plus 64 GiB of cache comes to about 134 GB on a 128 GB machine. Budget for 128K there. The 1Mi default lives in the official two-B200 server.
llama.cpp can quantize the cache, which is how prometheusAIR gets the full context onto a single 96 GB RTX PRO 6000 with its own patched build:
llama-server -m Ripple-65B-Preview-Q6_K_XL.gguf -ngl 999 \
--ctx-size 1048576 -ctk q8_0 -ctv q8_0 -fa on -b 2048 -ub 1024 -np 1 --jinja
It answered all four test questions correctly at every depth, which is a small test, but look at the speed:
| Prompt tokens | Prefill (whole prompt) | Decode |
|---|---|---|
| 32,135 | 1,448 tok/s | 23.9 tok/s |
| 131,315 | 982 tok/s | 19.3 tok/s |
| 1,031,887 | 226 tok/s (76 minutes) | 6.7 tok/s |
The publisher says the decode drop is steeper than the KV cache's size explains and hasn't profiled why. I'd treat 1M as something you can fill once, overnight, and plan daily agent work around 128K.
Does Ripple-65B really beat a 501B model?
On Terminal-Bench 2.1, yes, by Ricursive's own numbers. But "65B vs 501B" only counts total parameters, so here is the card's table with active parameters included:
| Model | Total | Active | TB 2.1 self-reported | TB 2.1 Terminus 2 | SWE-bench Verified |
|---|---|---|---|---|---|
| Ripple-65B Preview | 65B | 65B | 80.5 | 80.5 | 76.5 |
| Reflection Beam | 501B | 23B | 80.1 | 70.8 | 81.6 |
| Muse Spark Open | 816B | 42B | 76.4 | 78.7 | 78.7 |
| Inkling | 975B | 41B | 63.8 | 56.2 | 77.6 |
| Nemotron 3 Ultra | 550B | 55B | 56.4 | 55.1 | 71.9 |
Ripple has the fewest total parameters and the most active ones, which is why stewartpark on HN expects it to be "prohibitively slow on consumer grade hardware". The Spark and M5 Ultra numbers above are that argument's first test, and the answer so far depends on whether you're writing code or prose.
The harness matters more than the lead. Beam drops 9.3 points between the two Terminal-Bench rows, more than 20 times Ripple's 0.42-point margin. The competitor Terminus 2 scores are Ricursive's in-house runs, and the card itself says agentic scores are hard to replicate.
The other benchmarks are mixed. Ripple takes SWE-bench Pro v2.0 Hard 79.1 to Beam's 76.5 and DeepSWE 1.1 44.3 to 43.3, but Beam wins SWE-bench Verified, and MCP Atlas goes 71.67 for Ripple against 80.8 for Beam and 89.2 for Muse.
The card also says every model was tested at full BF16 precision, so 80.52 is a BF16 claim. Sixteen quantized repos are listed, and I found no Terminal-Bench run on any of them. The NVFP4 card repeats 80.52 without giving a score for that checkpoint.
"U.S. open-weight SOTA" is a narrow title as well. One HN commenter cites 84.3 for Qwen 3.8 Flash Next, which isn't in Ricursive's chart. I haven't verified that figure, but the geographic qualifier is there for a reason.
Test Ripple-65B hosted before you buy hardware
Run your own agent task first. Ricursive lists Together AI, GMI Cloud, OpenRouter and Fireworks. pcwelder on HN hit a 131k context limit and 4 of 8 tool calls failing on the GMI Cloud endpoint through OpenRouter. Treat that as one data point and repeat it.
If you self-host on SGLang and use tool_choice: "required", check your schema. Ricursive's server README says non-strict required calls produced extra argument fields on its SGLang version, and it asks for function.strict=true and additionalProperties: false.
Then time prefill on a prompt the size of your repo context, because agents resend long prefixes all day.
A 65B model this close to a 501B one moves my shopping list from most memory toward most bandwidth per dollar. I'm still not buying hardware for a preview when I can't find an independent replication of the headline number or a Terminal-Bench run on a quantized build.
Would a dense 65B model change what you'd buy for local inference, or would you stay with a MoE that only touches a fraction of its weights per token? If you've run a quant on your own box, post the hardware, tok/s and context length.
Top comments (0)