Recursive Flint is IMPRESSIVE
A 40B param MoE model that rips on relatively low power hardware
10/26/2026
When I first saw the release of Recursive Flint I was a little skeptical. Benchmarks show shocking performance on M4 Pros at a level of intelligence that beats the best from Qwen / Gemma /etc in this footprint of around 27-50B parameters. So I took a spare 64GB Mac Mini and fired it up against the same harness and test suites I bench the considerably larger 2x DGX Spark class models on. The results? Really damn impressive. Full results here.
Speed (spark-tuning/scripts/bench_decode.py, 1,000 decode tokens)
| Context target | Prompt tokens | Time to first token | Decode tok/s | Prefill tok/s |
|---|---|---|---|---|
| 1K | 823–998 | 1.2–1.6 s | 114–120 | ~670 |
| 16K | 12,823–15,414 | 21–27 s | 84–91 | ~565–610 |
| 64K | 51,223–61,630 | 128–169 s | 45–51 | ~360–400 |
| 128K | 102,423–123,485 | 377–528 s | 26–31 | ~235–272 |
First off the speed. Because its only 2.5B active params its pretty damn quick on an M4 Pro (and I would guess 5% quicker on an M5 Pro). Prefill is predictably quite slow, but decode is solid, degrading with context length pretty severely. But this isn't terrible, as long as your use case doesn't require regular fast turn around time on uncached prompts. rec serves one request at a time, up to Flint's full 262K context, which fits in about half of a 64GB Mac.
Quality (spark-tuning's harness, data and sandbox; 32K budget; one run per cell)
| Test | T=1.0 (card) | T=0.6 | T=0 | Best Spark run (spark-tuning) |
|---|---|---|---|---|
| HumanEval+ (164), base / plus | 97.6 / 88.4 | 97.6 / 91.5 | 96.3 / 90.2 | 95.7 Qwen FP4-Local medium (16K) |
| MBPP+ (378), base / plus | 94.7 / 79.4 | 94.2 / 79.1 | 93.7 / 79.1 | 83.6 GLM FP4-Local low (thinking-off path) |
| GSM8K (1319) | 96.29 | 96.59 | — (skipped) | 96.5 |
| LiveCodeBench (80) | 65.0 | 71.2 | 70.0 | 58.8 MiMo / GLM FP4-Local, 32K |
| LCB answers at the 32K cap | 21 | 19 | 19 | 28–36 |
| LCB mean completion tokens | 16,983 | 16,608 | 16,872 | 13,800–18,667 |
Time to solve (concurrency 1)
| Setting | HE+ solved / 41 | s per problem | s per solved | mean tokens | LCB solved / 10 | s per problem | at the cap |
|---|---|---|---|---|---|---|---|
| Flint T=1.0 | 35 | 18.6 | 21.7 | 1,963 | 4 | 311 | 4 |
| Flint T=0.6 | 36 | 15.9 | 18.1 | 1,741 | 5 | 282 | 4 |
| Flint T=0 | 37 | 24.4 | 27.1 | 2,555 | 5 | 269 | 4 |
Flint T=0.6, 16K (results/quality/FLINT-TTS-t06) |
36 | 16.2 | — | — | 1 | — | 8 |
Spark, Qwen FP4-Local medium, 32K |
36 | 14.3 | 16.3 | 935 | 1 | 564 | 9 |
| Spark, MiMo thinking on, 32K | 37 | 22.1 | 24.5 | 1,005 | 1 | 717 | 8 |
Spark, GLM FP4-Local high, 32K |
37 | 9.0 | 10.0 | 370 | 3 | 628 | 6 |
With a full 32K budget we see the little INT4 model often outperforming the much larger FP4 local versions of Qwen 3.8 Flash Next and GLM 5.3 Flash running TP=2 on a pair of DGX Sparks on hard problems; while it trails slightly on the easy ones. Flint is not particularly temperature sensitive, 0.6 was slightly better, though not significantly, which we also see with Qwen and company. Not only was Flint solving more LiveCodeBench problems within the budget but it was often faster to get there on the "hard" problems despite being on much weaker hardware.
So these results were super promising, though there was some concern it was just "benchmaxxed" against these problems. So we took problems from AtCoder after Flint's knowledge cut off (June 2026) and had Qwen run them on the Spark cluster to compare:
AtCoder 2026-07-04 to 2026-10-25 , by stratum (solved / problems):
| easy (33) | medium (33) | hard (81) | ABC (109) | ARC (38) | |
|---|---|---|---|---|---|
| Flint int4, T=0.6 | 33 | 30 | 37 | 88 | 12 |
Qwen medium |
33 | 25 | 21 | 72 | 7 |
Qwen xhigh |
33 | 26 | 19 | 69 | 9 |
The lead narrowed but Flint still handily beat Qwen. Remember this is Qwen 3.8 Flash Next, the chunky MoE model, not 3.8-27B. The dense 3.8-27B is (for my use) far too slow on a M4 Pro class Mac and even a bit too slow on a Spark.
I look forward to trying Flint for some actual work this week and see if this level of smarts holds for my actual work. In my testing rec 0.1.0 crashed after about 30 hours with a Metal memory-allocation error, but I suspect this is a rough edge that will get fixed soon.
This is shockingly impressive, and certainly the best model I have run on a (relatively) small Mac. I might give the NVFP4 version a spin on a Spark next. Exciting stuff!