Ripple-65B Preview Requirements

Ripple-65B Preview is an open-weight language model released by Ricursive Intelligence on November 4, 2026: a dense Transformer with about 65B parameters (64.78B on Hugging Face), under Apache 2.0, with up to 1M (1,048,576) tokens of context. It is tuned for agentic coding, and the company says it fits on local hardware such as the NVIDIA DGX Spark. Measured file sizes are 129.57GB for the official BF16 release and 57.21GB for the official NVFP4 release, so NVFP4 fits on a single 96GB-class GPU or a DGX Spark (128GB).

The weight sizes in this article are the actual safetensors and GGUF file sizes on Hugging Face, checked on November 9, 2026. KV cache sizes, how well each setup fits on GPUs and Macs, and speed expectations are estimates derived from config.json and standard formulas, and are labeled as such. Benchmark numbers such as Terminal-Bench 2.1 at 80.5 are Ricursive's own measurements, not independent reproductions.

If you want to check quickly whether it runs on your own GPU or Mac, the VRAM calculator (free, no sign-up) estimates the required VRAM from the model, quantization, and context length you choose. Ripple-65B Preview is available in its model list.

The sizes above are weights only. Hugging Face "GB" means 10^9 bytes, while GPU "GB" is effectively GiB (2^30), so a 32GB card holds roughly 34.4GB in decimal terms. KV cache, the CUDA context, and activations come on top, so leave at least 1-3GB beyond the weight size (estimate).

Sources are the Hugging Face model card (https://huggingface.co/ricursiveAI/Ripple-65B-Preview) and Ricursive's launch blog (https://www.ricursive.com/ripple). The blog states a total development and training cost of about $32M; that is the company's own claim and does not affect the requirements.

The NVFP4 build is about 44% of BF16 (57.21GB), not a quarter, because it is a conservative quantization: only the MLPs use NVFP4, while attention, embeddings, and the output head stay in BF16 (per the official description). The DFlash2 draft needs another ~8.1GB, so running speculative decoding on a Spark means about 65.3GB of weights in total (calculation).

An MoE can have a huge total parameter count yet only runs a few experts per token, so it is memory-heavy but light on compute. Ripple-65B is the opposite: all 65B weights are read for every token. Decode speed is bounded roughly by memory bandwidth divided by weight size, so the amount of weight read maps directly to speed (a standard approximation; estimate).

- On a GPU with 1TB/s bandwidth, Q4_K_M (38.8GB) has a theoretical ceiling of about 26 tokens/s (1,000 / 38.8; estimate). Real numbers are lower
- Quantization helps speed as well as capacity: NVFP4 (57.21GB) reads less per token than BF16 (129.57GB)
- Compared with a several-hundred-billion-parameter MoE, total memory is smaller but compute per token is larger
- The launch blog describes the DGX Spark as high on compute but low on memory bandwidth relative to datacenter GPUs, and the official Spark notebook pairs the model with DFlash2 speculative decoding

Only two speed figures are available from official or semi-official sources. The model card says 250 tokens/s on 2x B200 at batch size 8, in BF16 and without quantization or custom kernels. The community team AtomicChat published a single run of plain Q4_K_M with llama-cli on a GH200 96GB: 309 tokens/s prompt processing and 40.6 tokens/s generation. We found no official generation speed for the DGX Spark.

To feel the difference from an MoE, compare it with the 280B MoE released on November 5, 2026, in ERNIE 5.5 Flash Base requirements. If a lighter dense model is what you need, Qwen3.8-27B and Nanbeige4.3-33B are candidates.

The KV cache can be computed from config.json. With 80 layers, 8 KV heads, head_dim 128, and BF16, K plus V costs 2 x 8 x 128 x 2 bytes = 4KiB per token per layer. The layer layout matters: of the 80 layers, 16 (one in five) are full attention, and the other 64 use a 1,024-token sliding window, so they need no KV for tokens older than the window (estimate, assuming the engine implements it that way).

The math is 16 layers x 4KiB = 64KiB per token, plus 64 layers x 1,024 tokens x 4KiB = 256MiB. If an implementation keeps full KV for the windowed layers too, it becomes 320KiB per token: about 40GiB at 131,072 tokens and about 320GiB at 1M (estimate). This is also per request; concurrent requests scale it proportionally. The official server uses two B200s with BF16 KV for the 1Mi default, presumably for this headroom (estimate).

In practice, 57.21GB of NVFP4 weights plus a 128K KV cache (~8.3GiB) fits easily in a Spark's 128GB. A single 1M-token request, however, adds about 64GiB of KV and becomes tight on a Spark or a single 96GB GPU once the weights are included. That is probably why the official Spark sample defaults to 131,072 tokens.

Native NVFP4 compute assumes Blackwell-generation hardware (B200, RTX 5090, RTX PRO 6000, the Spark's GB10), and the official NVFP4 local runtime is written for the Spark. On Hopper (H100/H200) or Ada (RTX 4090), NVFP4 is unlikely to give the same speed benefit (estimate), so GGUF or FP8 is the more straightforward choice there.

Apple Silicon uses unified memory, so you are not limited by a dedicated VRAM pool, but not all of it can be given to the GPU (estimate). Besides llama.cpp GGUF files, community MLX conversions exist: frogggias's MLX 4-bit totals about 36.4GB of safetensors and the 8-bit about 68.8GB.

- 36-48GB Macs: MLX 4-bit (~36.4GB) and Q4_K_M (38.8GB) load, but room for context and the OS is thin, so only a short context on a 48GB machine
- 64GB Macs: Q5_K_M (45.76GB) is realistic; Q6_K (53.15GB) only with a short context
- 96GB Macs: Q8_0 (68.84GB) fits with room for tens of thousands of tokens of context
- 128GB Macs: Q8_0 with a longer context. BF16 (129.57GB) does not fit
- Speed: a dense model reads all weights per token, so high-bandwidth Max and Ultra chips are favored and base M-series chips will be slow (estimate)

Before comparing options on a Mac, our guide on keeping confidential code on a local LLM with a DGX Spark is a useful reference for splitting work between local hardware and the cloud.

The model card itself has no launch commands; the instructions live in the repo's inference folders. Stock SGLang does not support Ripple yet (the support PR #48636 was still unmerged on November 9, 2026), so the company ships dedicated launch scripts.

The official server recipe runs BF16 on two B200s and requires SGLang 0.5.19, CUDA Toolkit 13, a C++ compiler, and uv. Run it from inference/server. Defaults are TP=2, BF16 weights and KV cache, a 1Mi-token context, and DFlash2 with 16 draft tokens, listening on 127.0.0.1:30000.

For the DGX Spark, the company provides a notebook (inference/local/ripple.ipynb) that combines the NVFP4 build with DFlash2. It needs a Python 3.12 Jupyter kernel, CUDA Toolkit 13, and pinned packages including sglang==0.5.19, torch==2.13.0+cu130, and transformers==5.12.1. You create it with Spark("ricursiveAI/Ripple-65B-Preview-NVFP4", "ricursiveAI/Ripple-65B-Preview-DFlash2") after from spark import Spark. It runs offline rather than as an HTTP server, handles one request at a time, and spark.py defaults to a 131,072-token context.

For vLLM, the Ripple support PR #65745 was merged on November 5, 2026. The newest tag we saw was v0.33.0rc3 (November 2), which predates the merge, so which release will contain it is unconfirmed. The Red Hat AI NVFP4 build (RedHatAI/Ripple-65B-Preview-NVFP4) lists this example:

For llama.cpp, Ripple support (PR #31692) was merged on November 5, 2026, and stock llama.cpp works from release b12167 (November 6). Apps that bundle an older llama.cpp (AtomicChat's page names LM Studio and Ollama) cannot load the GGUFs until they update. Build the CUDA version as follows and pass --jinja (on a Mac, drop -DGGML_CUDA=ON).

The chat template covers tool calls and <think> reasoning output, and the official server has a parser (ripple) that returns reasoning_content and tool_calls separately. The template does not implement a thinking on/off switch or reasoning-effort levels (per the official README).

AtomicChat also published next-token agreement with BF16 for its own layouts: AD-Q4_K_M 95.9%, AD-IQ3_XXS 91.2%, AD-IQ2_XXS 80.8%, and plain Q4_K_M 93.0%. At the same size, importance-matrix (imatrix) quantization beats a plain Q4_K_M in quality. These are third-party measurements, not official ones.

The numbers below come from the official model card. Ricursive says it used each lab's published scores where available and measured only the missing ones in its own eval flow; competitor values marked with a dagger were measured by Ricursive. For Terminal-Bench 2.1, it also notes that almost all models scored lower with the official Terminus 2 harness at 128K with summarization. Everything here is self-reported and not independently verified.

The standout is the terminal-agent scores (Terminal-Bench 2.1, SWE-bench Pro v2.0 Hard), where it matches or beats models with 7-15x more total parameters. On SWE-bench Verified, DeepSWE 1.1, MCP Atlas, and GPQA Diamond, it trails Reflection Beam 501B and Muse Spark Open 816B. The strength is concentrated in terminal-style agentic tasks rather than broad knowledge or general reasoning, so try it on your own repository before deciding.

Note that the pretraining data is text-only and mostly English and code. Japanese-language performance and image input are not documented, so verify them yourself before using it on Japanese business documents.

The license is Apache 2.0 (the repository's LICENSE is the full Apache License, Version 2.0), with permissive terms for commercial use, modification, and redistribution. The BF16, NVFP4, Base, and DFlash2 repositories all show Apache 2.0. For community quantizations and derivatives (such as abliterated versions), check each repository's own license field.

The Base release (Ripple-65B-Base-Preview) is a pretrain-only checkpoint without midtraining or synthetic QA data and is not meant for chat as is. If you fine-tune it, remember that on top of the 129.57GB of BF16 weights you need memory for gradients and optimizer state (a general rule; actual amounts depend on the method).

- CUDA out of memory at startup: the weights do not fit. Switch to NVFP4 or a smaller GGUF quantization, or add GPUs
- OOM after startup: not enough KV cache room. Lower the context length (-c or --context-length) or concurrent requests. The official server defaults to 1M, which is especially large
- llama.cpp says "unknown model architecture: ricursive": support starts at b12167. Apps that bundle an older llama.cpp, such as LM Studio and Ollama, need an update
- Stock SGLang will not load it: the support PR #48636 is unmerged. Use the official serve.py (inference/server) or the Spark spark.py
- DFlash2 fails or gives no speedup: the draft was validated only with the matching Ripple runtime. The official README says compatibility is not guaranteed for other target revisions or runtime versions
- Slow generation (Spark, Mac): a dense model is bandwidth-bound. Use NVFP4 or a smaller quantization, and on the Spark pair it with DFlash2
- Garbled output at Q2_K: plain Q2_K is extremely poor (per mrfakename's perplexity measurement). Pick an IQ2 or imatrix-based quantization
- Extra arguments in tool calls: per the official README, use strict=true and additionalProperties=false with tool_choice: "required"