Run Ripple-65B Preview Locally: RAM, VRAM, and Coding Agent Setup

Ripple-65B Preview can run locally, but the useful starting point is a machine with enough memory for a roughly 39–46 GB Ollama package plus the runtime, cache and operating system. A 24 GB graphics card cannot hold that package entirely in VRAM. A 64 GB unified-memory machine is a candidate for a short-context trial, subject to the selected tag and real memory pressure. A larger memory pool gives a coding agent more room to keep files, test output and conversation history available.

Ricursive Intelligence released this 65B dense model under Apache 2.0 and publishes BF16 and NVFP4 weights. Ollama added Ripple Preview in v0.40.16. This guide starts with the machine and runtime decision, then shows how to test a real coding workload. Memory tiers below are planning judgments. Published benchmark results are identified separately.

What makes Ripple different from a similarly named coding agent?

Ripple is the model. It can propose edits and tool calls, while a coding harness controls which files and commands it can actually access. Running the model on the same network as a repository does not grant the model Git access. The harness decides how to mount the workspace, execute tests and ask for approval. That distinction matters when comparing an Ollama chat session with a terminal benchmark.

The official model card describes a 65B dense Transformer trained from scratch, with 80 layers and support for up to 1,048,576 tokens. Dense architecture puts the full model to work on every generated token. Memory bandwidth and effective weight precision matter even when the checkpoint fits. Ricursive reports 80.52 on Terminal-Bench 2.1 in its own test setup. A different runner, quantization and harness can change the result. See the launch report for the benchmark and architecture details.

How much RAM or VRAM should you budget?

At two bytes per parameter, 65 billion parameters imply roughly 130 GB of BF16 weight storage before runtime overhead. This is decimal GB arithmetic, rather than a measured allocation. Likewise, multiplying by four bits gives a rough lower bound for packed weights, without scales, tensors retained at higher precision, or package metadata. Use the size of the actual artifact for a download estimate and runtime telemetry for the machine budget.

An NVIDIA NVFP4 release and an Ollama tag are different artifacts. Check the official NVFP4 card before choosing that format and confirm the serving stack and GPU architecture it targets. A multi-GPU host also needs a runtime that explicitly supports splitting this checkpoint. Adding the advertised capacities of two GPUs is insufficient to establish that a model fits or runs efficiently.

Which local runtime should you choose?

The lowest-friction route is the Ollama model listing paired with v0.40.16 or a compatible newer version. Use the listing to check the current tag, package size and platform notes before downloading. For a simple test, run:

ollama run ripple-preview
ollama ps

The first command downloads the model if needed and starts a session. The second helps you see placement and loaded context. On Apple silicon, the release includes a specific MLX path for Ripple. If you want to reproduce the developer's NVIDIA results instead, use the model card's current instructions and capture the full serving configuration. Results across formats are only comparable once you account for different kernels, precisions and draft decoding.

Leave space for the model store, a temporary download, your checkout and test artifacts. On hosts that also run storage or backups, check the drive that actually holds the runner cache. A nearly full SSD can interrupt a first download even if the nominal model size looks safe.

What does a million-token context mean on a local machine?

It is the checkpoint's supported context, not a useful first setting. A coding agent may feed hundreds of files, shell output and the previous conversation back into the model. That input increases cache allocation and time before the first generated token. Long prefixes also slow the feedback loop if the harness repeatedly sends old logs.

Start with a deliberately small input and one job. Keep a fixed repository snapshot, collect peak memory after loading and again at the end of the longest prompt, then widen the context one step at a time. Watch actual resident memory or unified-memory pressure and check for sustained swap. Clear needless test logs before increasing context. The trade-offs in this local Qwen3.8-27B deployment guide make a useful baseline for a lighter model.

How do you test a real coding session?

Create a disposable checkout and pick a bounded task: explain a failing test, identify the files involved and propose a patch. Use only synthetic or approved repository data. Give the harness a list of files it may read and a short allowlist for local test commands. Review the diff and run tests independently before trusting the result. This Git worktree guide explains how to keep experiments separate from a main checkout.

Record time to the first useful answer, generation speed after prefill, peak memory and whether the suggested change passes the test. Count a failed or truncated attempt in the comparison. If a model spends five minutes generating a plausible but unusable patch, a peak tokens-per-second number will hide the problem. A second useful task is reviewing a small diff without editing files. It tells you whether the same machine is valuable for lower-risk review work.

When is a local 65B model worth the larger machine?

Use Ripple when you can give it room to run and have a workload that benefits from its coding behavior. A smaller checkpoint that stays accelerator-resident may give a better daily experience on a constrained desktop. Long runs deserve separate treatment from quick questions: bandwidth, swap and background storage traffic accumulate across an agent session.

If a NAS holds your repository snapshots and results, keep those storage services independent from the model's compute budget. Mount only the inputs the job requires and stage writes to an experiment directory. For a larger comparison point, see what drives Kimi K3’s local memory requirement.

FAQ

Does Ripple need an NVIDIA GPU?

No single GPU vendor is required for every local path. Ollama has an Apple-silicon MLX route. NVIDIA-oriented precision and acceleration instructions apply to the compatible NVIDIA stack specified by the model developer.

Can an RTX 4090 hold the whole model?

The Ollama package described above exceeds a 24 GB VRAM budget before inference overhead. CPU offload is a separate configuration with a different performance profile.

Does the download size equal peak memory?

No. The runtime, allocator, tool processes, attention cache and operating system all affect peak use. Download size is a useful starting measurement for disk planning.

Is the advertised maximum context the right initial setting?

Start with the shortest context that completes the task, then measure prefill time and memory as you increase it. Full context support does not establish a practical local throughput.

Is Terminal-Bench an estimate for my own repository?

Use it to understand the developer's evaluation, then test your own workload with a fixed harness, limits and runtime. The reported benchmark is not a guaranteed local outcome.

Conclusion

Start with an exact Ollama tag or developer-supported NVIDIA format, leave headroom beyond the weight file and test one bounded task. Ripple-65B Preview expands the choice of local coding models. Its value on your hardware depends on whether it can finish useful work within your memory and latency budget.