Local LLM hardware requirements usually get answered with one number, how much memory you have. For Ripple-65B Preview, an Apache 2.0 model from Ricursive Intelligence with 65 billion parameters and open weights since 2026-11-04, memory is the easy half. The model card says it “can fit on consumer hardware such as the NVIDIA DGX Spark”, true for a quantized file. What the card does not tell you is how many tokens a second you get once it fits.
Below, what each file weighs, what a long context costs in cache, and the ceiling per machine. I did not run this model. I read the config, summed the file sizes and did the division, so below is arithmetic. Verdict: you buy memory for the file, then pay for bandwidth every second after.
I run Trellis, which builds AI tools for Amazon sellers, so my question is always a batch job. Mettons 5,000 product listings to rewrite overnight, 300 output tokens each. That is 1.5 million tokens, and at 5 tokens a second it is 83 hours. Worst case: one request at a time, no draft model. What beats that comes up below.
What are the local LLM hardware requirements for Ripple-65B?
These are sizes I summed from the Hugging Face API on 2026-11-08, in decimal GB. The GGUFs come from community repos (Chungulus, AtomicChat), not Ricursive. The lab’s own quant is only NVFP4, marked experimental, with the MLP in 4-bit and attention in BF16. That is why it weighs 57.21 GB, not 35.
The last two columns are the ceiling, not a benchmark. For one request at a time with no draft model, decode speed cannot beat bandwidth divided by the bytes read per token, and a dense model reads about the whole file for every token. I used 273 GB/s from NVIDIA’s DGX Spark page and 819 GB/s from Apple’s Mac Studio specs, both fetched today. One catch on that second column: Apple sells M3 Ultra only at 96 GB or 256 GB, and the 64 GB and 128 GB Mac Studios are M4 Max at 546 GB/s, capping Q4_K_M near 14 tokens a second, not 21.
| File | Size | Spark, 273 GB/s | M3 Ultra, 819 GB/s | |—|—|—|—| | BF16 safetensors (Ricursive) | 129.57 GB | 2.1 tok/s | 6.3 tok/s | | Q8_0 GGUF | 68.84 GB | 4.0 | 11.9 | | NVFP4 (Ricursive, experimental) | 57.21 GB | 4.8 | 14.3 | | Q4_K_M GGUF | 38.80 GB | 7.0 | 21.1 | | Q3_K_M GGUF | 31.02 GB | 8.8 | 26.4 |
Real speeds will be lower: kernels miss peak bandwidth. BF16 is only a bandwidth line, since it does not fit on that box with cache and system added, so 2.1 is not reachable.
Reading your prompt is limited by compute, not bandwidth, and I have no figure for that.
How much memory does a 128k context need?
Less than I expected. The config.json lists 80 layers, 8 key-value heads, a head size of 128, and a layer pattern where only 16 layers see the whole context. The other 64 use a sliding window of 1,024 tokens.
My arithmetic, assuming a BF16 cache and an engine that drops everything outside the window. A full-attention layer stores 8 heads × 128 × 2 (keys and values) × 2 bytes, so 4 KiB per token per layer, and 16 layers make 64 KiB a token. At 131,072 tokens that is 8.0 GiB. The 64 sliding layers add a fixed 256 MiB. Total: 8.25 GiB.
With all 80 layers on full attention it would be 40 GiB. Long context is cheap here; the weights are the bill. At the full 1M-token window the 16 full layers alone want 64 GiB, not a home number. The card advertises 1Mi, but config.json carries 2,097,152 positions, double what this computes at.
I have not checked that llama.cpp frees the sliding-window cache this way. The support landed through one pull request, merged 2026-11-05. A second one was closed, and its author wrote that he “did not check for compatibility with existing GGUFs”.
Which machine for which file?
My rule of thumb: file size, plus cache, plus 4 to 6 GB for the operating system.
- 16 or 24 GB of memory: nothing here. Even Q3_K_M is 31 GB. Pick a smaller model.
- 48 GB: Q3_K_M with a shorter context. Q4_K_M plus a full 128k cache is 47.7 GB, so no room left.
- 64 GB: Q4_K_M at full 128k context fits, at about 14 tokens a second, because a 64 GB Mac Studio is an M4 Max at 546 GB/s. The cheapest comfortable setup.
- 96 GB: Q6_K (53.15 GB) or Q8_0 (77.7 GB with the cache) both fit at 819 GB/s, because 96 GB is the smallest M3 Ultra.
- 128 GB: Q8_0 with space to spare, near 8 tokens a second on the same 546 GB/s. Not BF16.
One trap: on a Mac the GPU does not get all of unified memory by default. Community guides put the usable share near 75 percent, raised with sudo sysctl iogpu.wired_limit_mb, which makes a 64 GB machine 48 GB in practice. I could not find an Apple page stating the default, so treat that as unconfirmed.
And the plain desktop: dual-channel DDR5-6000 is 96 GB/s by my arithmetic (6,000 million transfers × 8 bytes × 2). Q4_K_M tops out near 2.5 tokens a second there. You will not enjoy it.
Why does dense make this so slow?
Every one of the 65 billion parameters is read for every token. A mixture-of-experts reads only the experts it routes to. I covered one, Flint, 39.8B total and about 2.5B active, two weeks ago. Q4_K_M here averages 4.79 bits per weight (38.80 GB over 64.78 billion parameters). If Flint were stored at that same density, 2.5B active parameters would be about 1.5 GB per token, and the same 273 GB/s would give a ceiling near 180 tokens a second.
A ceiling 26 times higher on the same box. I would never size a MoE and a dense model with the same spreadsheet.
Me, I’d say it flat: on a Spark, one request at a time, a chat window where you watch the cursor is slow. But 7.0 is a ceiling for that case only. The lab ships DFlash2, a 4.04B-parameter draft model that proposes several tokens for the big model to check, and its server README runs eight concurrent requests per replica. Both beat my number, and the division is still right. Nobody has published a Spark figure with either, so 83 hours is a ceiling, not a forecast.
What about the 80.52 benchmark score?
The model card claims 80.52 on Terminal-Bench 2.1. That is the lab’s own number, run with OpenCode, a separate open-source agent, not Ricursive’s: the card says “where the harness is not specified, we use OpenCode”. The harness does not flatter Ripple, though. A second card row, under the official Terminus 2 harness, keeps Ripple at 80.5 and drops the rivals to 55.1, 56.2 and 70.8, with only Muse Spark Open higher at 78.7. That is a 1.8-point lead. The rivals are the lab’s runs too, so I read it as a claim, not a result.
The launch discussion on Hacker News raised three points I could not verify. The chart leaves out Qwen3.8, on the self-reported row the lead (Reflection Beam 501B at 80.1) is about 0.4 points on one chosen benchmark, and “US open-weight” is a narrower category than “open weights”. I found no independent reproduction.
What I would test first
Bon, with a 64 GB machine or a Spark on the desk, this is my order.
- Download the Q4_K_M and run llama-bench with the cache at 32k, then 128k. Compare the real tokens a second to my 7.0. If it is above 7.0 on a Spark with one request and no draft model, my division is wrong.
- Watch resident memory at 128k. 8.25 GiB means the sliding window is really being dropped. A number near 40 means it is not.
- Time the prompt reading of a 20k-token coding session, separately from writing.
I could not do any of this: my box has 4 CPU cores and no GPU. When somebody posts real tokens a second for the Q4_K_M, I will put it next to my 7.0.
