How to Run Ripple 65B Locally

To run Ripple 65B Preview locally, plan for about 40 GB of memory for a mid size AtomicChat GGUF, about 37 GB for the community MLX 4 bit build, or roughly 57 GB for the official NVFP4 checkpoint, and use a runtime that knows the custom ricursive architecture. Stock llama.cpp, Ollama and LM Studio do not load these weights yet. Until llama.cpp pull request #31692 merges, use AtomicChat's GGUF plus that PR build (or their patch), Hugging Face Transformers with trust_remote_code, the NVFP4 path aimed at DGX Spark, or the MLX conversion with --trust-remote-code.

Ripple-65B Preview is a dense open weight model from Ricursive Intelligence, published on Hugging Face on November 4, 2026 under Apache 2.0. The lab pretrained it on 12 trillion tokens, claims up to 1M context, and focuses post training on agentic coding. Its vendor reported Terminal-Bench 2.1 score of 80.52 is the lab's own number; treat it as such. On the morning of November 5, 2026 the model card had about 190 likes, a Hacker News thread on the launch sat near 300 points, and Google autocomplete for "ripple 65b" already pointed at preview, Hugging Face and GGUF.

What Ripple 65B Preview is

The model's config.json describes a custom RicursiveForCausalLM (model_type: ricursive) with remote code, so runners must trust or port that code. Shape facts from the config:

• 80 layers, hidden size 5120, intermediate size 40960
• 80 query heads, 8 key and value heads, head size 128
• Hybrid sliding window attention: window 1024, with 16 full attention layers (every fifth block) and 64 sliding window layers
• max_position_embeddings 2,097,152; vocabulary 100,352
• Chat markers use <|im_start|> and <|im_end|>

Ricursive calls the shape thin and deep: a narrow d_model with many layers, gated attention, FFN activation clipping, global NoPE on full attention layers, and value residuals. The point of staying dense, rather than shipping another huge mixture of experts, is that 65B total parameters can fit machines such as an NVIDIA DGX Spark once quantized, while still spending compute on every token. Contrast that with Muse Spark Open, Meta's 816B MoE (about 42B active) that still needs hundreds of gigabytes of weights in memory.

Official checkpoints on Hugging Face include the BF16 instruct model (this guide's main card), an experimental NVFP4 instruct build (MLP in NVFP4, attention left in BF16), a base pretrain only checkpoint, and a DFlash2 draft model for speculative decoding. Hosted APIs (Together, OpenRouter, GMI Cloud and others named on the launch page) exist if you only need an endpoint; this guide covers running weights yourself.

How much memory Ripple 65B needs

File sizes below come from the official cards and from the AtomicChat GGUF README, checked on November 5, 2026. Suggested hardware in the GGUF table is AtomicChat's, not ours. AD files use Atomic Dynamic layouts plus an importance matrix; plain Q4_K_M is the stock llama.cpp preset without that matrix.

AtomicChat reports that at similar size, AD-IQ4_XS keeps a higher same top token rate against BF16 than plain Q4_K_M (95.6% against 93.0% on their corpus). Those are their measurements. For how quant names work in general, see GGUF quantization explained.

KV cache cost (estimate)

Only the 16 full attention layers keep a full per token cache. From the config (8 KV heads, head size 128, 16 bit), that is about 64 KiB per token, which matches what the community MLX card states. The other 64 layers keep a 1,024 token window. At 32,000 tokens the full attention cache alone is about 2 GiB before overhead; at 128,000 tokens about 8 GiB. Treat this as arithmetic from the config, not a vendor bench. Our how much VRAM an LLM needs guide covers the general method.

Ricursive states the model reached 250 tok/s on 2xB200 at batch 8 before quantization or custom kernels. That is a lab claim on datacenter GPUs, not a home machine figure.

Which runtime to use

Run Ripple with Transformers

Install a current Transformers build (the config lists 4.57.6) and load the instruct repo with remote code enabled. You need enough GPU or unified memory for the BF16 shards (about 130 GB) unless you add your own offload plan. Prefer a quant path below for most local boxes.

pip install -U "transformers>=4.57.6" "accelerate" "torch"

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "ricursiveAI/Ripple-65B-Preview"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True,
)
messages = [{"role": "user", "content": "Write a Python function that checks for a palindrome."}]
prompt = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
print(tokenizer.decode(model.generate(**inputs, max_new_tokens=512)[0], skip_special_tokens=True))

Run Ripple with llama.cpp and AtomicChat GGUF

Support for ricursive is proposed in llama.cpp PR #31692 and was still open (not merged) when we checked on November 5, 2026. AtomicChat's README says stock llama.cpp, LM Studio and Ollama do not load these GGUFs until that lands. Build from the PR branch:

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
cmake --build build -j --config Release --target llama-server llama-cli

On a Mac, omit -DGGML_CUDA=ON (Metal is on by default). AtomicChat also ships ricursive-port.patch against a pinned llama.cpp commit if you prefer applying a patch. Download a quant (example: AD-Q4_K_M), then serve with the embedded chat template:

pip install -U "huggingface_hub[cli]"
hf download AtomicChat/Ripple-65B-Preview-GGUF \
  --local-dir Ripple-65B-Preview-GGUF \
  --include "*AD-Q4_K_M*"

./build/bin/llama-server \
  -m Ripple-65B-Preview-GGUF/Ripple-65B-Preview-AD-Q4_K_M.gguf \
  --jinja -c 32768 -ngl 99

For split files, point at the first part. --jinja matters: the template carries tools and reasoning markup. Ricursive has not published default sampling settings for Preview; start with the runner defaults and tune on your own prompts. AtomicChat measured one plain Q4_K_M run on a GH200 96 GB at about 309 prompt tokens/s and 40.6 generation tokens/s; that is their single run, not a guarantee for your hardware.

NVFP4 on DGX Spark (and related boxes)

The NVFP4 repository is Ricursive's experimental local path: about 57 GB on disk, with a notebook and helpers under inference/ aimed at NVIDIA DGX Spark (including an optional Google Colab local runtime on the Spark). It uses SGLang style serving with the shared format parser, and can pair with the BF16 DFlash2 draft for speculative decoding. Follow that notebook's install pins rather than inventing your own stack; the card describes a conservative quant (NVFP4 MLP, BF16 attention). This is the path Ricursive highlights for fitting the model on Spark class hardware without a community GGUF.

Run Ripple on a Mac with MLX

Stock mlx-lm does not know Ripple's architecture by itself. The community repo frogggias/Ripple-65B-Preview-MLX-4bit ships an MLX port (ricursive.py) and asks for mlx-lm 0.32.2 or newer plus --trust-remote-code. The card lists about 37 GB on disk and recommends a Mac with 64 GB or more of unified memory. An 8 bit sibling exists in the same namespace.

pip install "mlx-lm>=0.32.2"
mlx_lm.generate --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code \
  -p "Write a Python function that checks whether a string is a palindrome." -m 2048

For an OpenAI compatible server: mlx_lm.server --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code. The converter reports decode around 22 to 23 tokens/s for one stream on an M5 Ultra 256 GB Mac Studio; those are their figures. For format tradeoffs on Apple silicon in general, see MLX vs GGUF on Mac.

Settings and chat template notes

• Template: use the repo chat template (apply_chat_template or llama.cpp --jinja). Do not hand roll <|im_start|> strings unless you know the full format.
• Reasoning and tools: AtomicChat and the MLX card note reasoning markers inside reply content, and the embedded template supports tool calls.
• Sampling: Ricursive has not published Preview defaults. Keep temperature moderate for coding agents and log what you change.
• Context: the claim is up to 1M tokens and the config allows about 2M positions, but KV cache RAM sets the practical limit. Start at 8K to 32K.

Pros and cons

Pros

• Apache 2.0 weights, so commercial use and redistribution are allowed under that license's terms.
• Dense 65B envelope can fit high memory Macs, DGX Spark and multi GPU workstations once quantized.
• Hybrid SWA keeps long context cheaper than a fully global dense stack of the same depth.
• Strong vendor reported agentic coding scores relative to much larger US open weight MoE models.

Cons

• Custom architecture: stock Ollama, LM Studio and mainline llama.cpp cannot load it until the PR merges.
• All 65B parameters are active every token, so generation is heavier than a similar total size MoE.
• Preview post training is relatively light and coding focused.
• Community GGUF and MLX builds need trust in third party ports and quants.

Who it's for

Ripple 65B Preview suits people with roughly 48 GB or more of GPU, unified or combined memory who want a US open weight, Apache 2.0 dense model for private coding agents, and who will build a patched llama.cpp, run Transformers with remote code, use the NVFP4 notebook, or load the MLX conversion. On a 24 GB card, AtomicChat's smallest research quants may load with short context, but quality drops and stock apps still will not help. For a smaller dense coding model that already runs in stock Ollama, see Nanbeige4.3 33B. For a hardware shortlist, use open source LLM models to run locally.

FAQ

How much VRAM do I need for Ripple 65B?

It depends on the file. AtomicChat suggests about 48 GB class memory for AD-Q4_K_M (40.4 GB) with moderate context, about 32 GB for AD-IQ3_XXS (28.0 GB), and about 24 GB for AD-IQ2_XXS (20.0 GB), leaving room for the KV cache. The official NVFP4 build is about 57 GB on disk. BF16 needs about 130 GB. Always add context on top of the weight file.

When will stock llama.cpp, Ollama and LM Studio load Ripple?

When PR #31692 merges and those apps ship a build that includes it. As of November 5, 2026 the PR was still open. Until then, build from the PR or AtomicChat's patch for GGUF, or use Transformers, NVFP4 helpers or the MLX conversion.

How does Ripple 65B compare to Muse Spark Open for local use?

Ripple is a 65B dense model; Muse Spark Open is an 816B MoE with about 42B active. Ripple's mid size GGUFs sit near 40 GB; Muse's usable quants still start around 225 GB. Ripple fits more local boxes; Muse remains the larger multimodal flag. See how to run Muse Spark Open locally.

Is Ripple 65B free for commercial use?

The published Preview weights use Apache 2.0. That license allows commercial use, modification and redistribution when you follow its conditions (including the notice requirements). Read the LICENSE file in the Hugging Face repo for the exact text.

Can I really use 1M tokens of context?

The lab claims up to 1M context, and the config sets max_position_embeddings to about 2M. In practice your RAM for the KV cache sets the limit. With about 64 KiB per token on the 16 global layers, long contexts grow quickly. Prefer 8K to 32K for day to day agent work unless you have measured headroom.

Should I use AD GGUFs or the plain Q4_K_M?

AtomicChat's own side by side favors the AD (Atomic Dynamic + imatrix) files at a given size for next token agreement with BF16. Plain Q4_K_M stays in the repo as a baseline. Prefer an AD file unless you have a reason to match a stock preset exactly. Both still need the Ripple capable llama.cpp build.