Ripple-65B Preview (NVFP4 with DFlash2 drafts) on one DGX Spark, RicursiveAI's DGX Spark recipe with SGLang 0.5.19

How fast it runs

Long prompts

Method: code+prose; 2 run(s) each; 512 tokens; 1 warm-up(s); median; context steps: prompts of exactly 16K, 32K and 64K tokens and of 130,048 tokens for the 128K step, which is reduced so that prompt plus 512 output tokens fit the 131,072 window (a filler log first, the code or prose task prompt last), 2 runs per step, 512 output tokens; decode = tokens after the first / time after the first token; prefill = prompt tokens / time to first token of the same request, median over its requests; requests at once: C1,C2,C4,C8 at once; 2 rounds each; 512 tokens per request; prose prompt; total = all tokens / wall time, per request = tokens / end-to-end time; median over the rounds. Measured 2026-11-05. Raw files: speed result · speed contract · log · long answer.

The speed test ran with the DGX Spark recipe of RicursiveAI (inference/local/spark.py and the notebook ripple.ipynb in the NVFP4 repository, revision 99eea447): SGLang 0.5.19 with torch 2.13.0+cu130, transformers 5.12.1 and flashinfer-python 0.6.18 in a virtual environment, the author's model code (RicursiveForCausalLM) and reasoning parser, the NVFP4 checkpoint (57.22 GB; the author labels it "Experimental": NVFP4 for the MLP layers, attention in BF16) and the author's DFlash2 draft model (8.08 GB). Both checkpoints were checked file by file against the Hugging Face hashes. The engine arguments are the recipe's (spark.py lines 139 to 163): tensor parallel 1, flashinfer attention, flashinfer_cutlass FP4 matrix multiplication, --context-length 131072 --max-total-tokens 139264 --mem-fraction-static 0.78 --max-running-requests 1 --disable-radix-cache, DFlash drafts of 32 tokens with a draft window of 16384. At its start SGLang prints "DFLASH block size mismatch: using speculative_num_draft_tokens=32 but draft config block_size=16": the DGX Spark recipe sets 32, the DFlash2 model card says 16 for the draft blocks; I kept the recipe's 32. The DFlash2 card says its recorded validation used eight H100 GPUs with the reinforcement-learning step-500 target and "does not establish compatibility or performance for other target revisions or runtime versions". The author's DGX Spark code is an offline engine without a web server, and the speed test needs an OpenAI-style endpoint. So I started the same engine with the same arguments through SGLang's HTTP server, as the author's server example does for B200 cards; only the host, the port and the served model name are added, and two cache folders (SGLANG_CACHE_DIR and SGLANG_JIT_CACHE_DIR) point to my user folder, because the default folder belongs to root. None of the recipe's values is lowered. The author names no sampling anywhere; the author's own examples use temperature 0, and so does this test (seed 42). The author gives one speed figure on the model card (the BF16 README): "reaching 250 tok/s on 2xB200 batch=8 prior to quantization or custom kernels". The author gives no number for a DGX Spark. Thinking cannot be switched off: the chat template has no switch (the author's notebook says so), and the request flag for no thinking is ignored. In every chat request of the decode, requests-at-once, long-prompt and long-answer parts (52 of the 61 requests the cache check covered) the reply was thinking text: all 512 tokens of each of the four decode runs were thinking, with no visible answer word, and so were the 32,768 tokens of the long answer. The 9 prefill probes are plain 8-token completions of the filler log without the chat template. So the decode speed here is the speed of thinking text with drafts. Words per second and characters per second of the visible answer are 0 in the raw files (no visible answer was produced), so the page does not show them and gives no time for 500 words. The headline 9.83 tok/s is the mean of the code prompt (9.85) and the prose prompt (9.80), medians of two runs each (spread 1.7 % and 2.0 %). The speed varied between runs: the one-request rounds of the requests-at-once test ran at 15.1 and 11.7 tok/s in total (the table shows their median, 13.4), and the long answer averaged 17.1 tok/s over its decode window. The speed test could not read draft statistics from the server (the author's command has no metrics flag), so the page shows no acceptance rate. The server has 1 slot, as in the recipe ("One request at a time"), so the requests-at-once test (1, 2, 4 and 8) measures the queue: the total stays at about 10 tok/s (10.2, 10.5 and 10.9 for 2, 4 and 8), and each request gets less (7.8, 4.4 and 2.4 tok/s). The long answer (the house prompt, up to 32,768 tokens) ran into the token limit after 1,921.6 s and counts as wrong; all of it was thinking text, and the raw file "long answer" is empty (0 bytes) because the reply had no visible text; the thinking text of this request is not among the public raw files. The 128K step of the long-prompt table ran with a prompt of 130,048 tokens: the prompt plus 512 output tokens must fit the window of 131,072. The prose cell of that step (12.7 tok/s) is the median of two runs that differ a lot (14.9 and 10.5 tok/s, spread 24.4 %): the speed contract flags it as noisy ("re-measure"), and I did not run extra rounds for it. The server does not report cached prompt tokens, so the check for them could not confirm anything for the 61 requests; the recipe switches the prefix cache off. A first run on 4 and 5 Nov 2026 (started 23:56) stopped at the fixed time limit of 3 hours for the speed block after the guard had thrown away three tries of the long answer because of scheduled jobs on the box (package manager, Docker daemon); it left no results, but its partial log lines showed decode speeds between 9.1 and 16.7 tok/s for the four decode runs (the second run: 9.7 to 10.0), so decode speed varies from run to run. This page shows the second run (5 Nov 2026, 03:40 to 06:14). The load guard (a sample every half second) saw other processes together above 25 % CPU in 266 of 18,424 samples, up to 342 %: mostly a firmware query tool (78 samples), the Docker daemon (71), package-manager checks (41), nvidia-smi calls (22), the box's update-check scripts (21) and two Python commands (25 samples: 13 of the test tool's own tokenizer helper and 12 of a check that I ran over ssh on the box myself). It threw away four tries and repeated them: the second decode run of the code prompt (a package-manager check, up to 100 %), the long answer (my own check, up to 340 %, which cost 32 minutes), and the first runs of the code and the prose prompt at 128K (a package-manager check, up to 102 %, and the tool's tokenizer helper, up to 88 %); the repeats are the ones that count, and no other step had to be repeated. The guard's sample file and the quiet-check file are not among the raw files here; the speed contract lists the guard's steps and the tries it threw away. The ten-second quiet-check file lists the SGLang scheduler itself as the busiest process in 912 of its 914 samples (I think because the wrapper started the server and not the tool), so it hides most foreign load and the guard above is the record of it; in the other 2 samples another process was the busiest, a package-manager query at 100 % and my own check at 142 %.

python3 speed2.py --base-url http://127.0.0.1:33067/v1 --label ripple65b-box-1-0511b-speed-r0 --prompts $BENCH/repos/rigmark-v2/prompts-v2.json --output $RUN/raw/ripple65b-box-1-0511b-speed-r0/ripple65b-box-1-0511b-speed-r0/speed2 --contract $RUN/raw/ripple65b-box-1-0511b-speed-r0/ripple65b-box-1-0511b-speed-r0/speed2/speed-contract.json --parts decode,prefill,conc,l1,ctx --prefill-depths 2048,8192,32768 --prompt-ids code,prose --runs 2 --max-tokens 512 --warmups 1 --prefill-runs 3 --conc-levels 1,2,4,8 --conc-rounds 2 --conc-max-tokens 512 --conc-prompt prose --ctx-depths 16384,32768,65536,131072 --ctx-runs 2 --ctx-max-tokens 512 --tokenizer-json $HOME/models/ripple-65b-nvfp4-99eea447/tokenizer.json --tokenizer-python $HOME/not published --sampling {"temperature": 0.0} --sampling-source The author names NO recommended sampling anywhere (model cards BF16/NVFP4/DFlash2, launch blog, generation_config.json without temperature/top_p). His own examples run with temperature 0: inference/local/spark.py:175 (complete()), :187 (chat()), ripple.ipynb cell 3 (sampling_params temperature 0), inference/server/README.md tool example ('temperature': 0). top_p/top_k/penalties are not sent. The model always reasons: the chat template has no thinking switch (ripple.ipynb markdown 3; server/README.md:67), so 'instruct' and 'thinking' are the same sampling and enable_thinking has no effect. --model ripple --no-cache-prompt --server-log $RUN/logs/server-A.log --engine-version-file $RUN/logs/engine-version.txt --server-slots 1 --server-slots-source inference/local/spark.py:157 (--max-running-requests 1 --cuda-graph-bs-decode 1) of ricursiveAI/Ripple-65B-Preview-NVFP4 @99eea447; ripple.ipynb markdown 1 ('One request at a time') --server-ctx 131072 --server-ctx-source spark.py:156 (--context-length 131072 --max-total-tokens 139264) of inference/local/spark.py @99eea447; the server's own value is read at start (GET /v1/models max_model_len)

Quality

The quality tests were still running on this setup when this page was built (5 Nov 2026), so the page shows no value for them: no MMLU-Pro, GPQA Diamond, IFEval, long-text, LiveCodeBench or thinking value, no memory test and no sparkDash. Thinking cannot be switched off and the server answers one request at a time, so these tests take many hours.

Also made this possible

• Draft model (Ripple-65B Preview DFlash2, revision 35609b3b)RricursiveAI/Ripple-65B-Preview-DFlash2Hugging Face
• Engine (SGLang 0.5.19)SSGLangGitHub

Run it yourself

What you need and how to start it, step by step. The results below come from exactly this setup.

What you need

Hardware

1x NVIDIA DGX Spark class box (an ASUS Ascent GX10, GB10 chip, 128 GB unified memory), GPU clock capped at 2200 MHz. Driver 580.178.04, kernel 7.0.0-1019-nvidia, CUDA 13.0 (torch 2.13.0+cu130)

Model

ricursiveAI/Ripple-65B-Preview-NVFP4 @99eea447 (65B dense, 80 layers, SWA + global NoPE; NVFP4 MLP, BF16 attention) + ricursiveAI/Ripple-65B-Preview-DFlash2 @35609b3b (BF16 drafter, 4.04B)

Model, NVFP4 checkpoint, DFlash2 draft model and the DGX Spark recipe (inference/local/spark.py)

huggingface.co/ricursiveAI/Ripple-65B-Preview-NVFP4

Draft model (Ripple-65B Preview DFlash2, revision 35609b3b)

huggingface.co/ricursiveAI/Ripple-65B-Preview-DFlash2/tree/35609b3be3dd08a822b3ba1257c1ea5dd6f87632

Engine

SGLang 0.5.19 with the author's model code, RicursiveAI's NVFP4 checkpoint (revision 99eea447) and DFlash2 draft model (revision 35609b3b), 131,072 tokens of context, 1 request at a time — the program that loads the model and answers requests · github.com/sgl-project/sglang

Steps

1. Get the engine and the model files from the list above.

2. Start the server with this command. It loads the model into memory.

   Copy

   python serve_ripple_box-1.py

SGLang 0.5.19 (torch 2.13.0+cu130, transformers 5.12.1, flashinfer-python 0.6.18, venv), model code = author model.py (RicursiveForCausalLM) + ripple_format.py, DFLASH speculative (32 draft tokens), flashinfer attention, flashinfer_cutlass FP4 GEMM, 1 GB10 (sm_121), context 131072, 1 slot; python serve_ripple_box-1.py (author's spark.py arguments: --tp-size 1 --attention-backend flashinfer --fp4-gemm-backend flashinfer_cutlass --context-length 131072 --max-total-tokens 139264 --mem-fraction-static 0.78 --max-running-requests 1 --cuda-graph-bs-decode 1 --disable-radix-cache --speculative-algorithm DFLASH --speculative-num-draft-tokens 32 --speculative-draft-window-size 16384 ...; wrapper $HOME/ripple65b-0511/ripple-ctl.sh)