Flint on a Mac mini 32GB: 5 Engines at 52.4-76.0 tok/s vs Qwen

We ran Flint on a Mac mini M6 32GB with five engines, and the median generation speed came out between 52.4 and 76.0 tokens per second. The engines used different files, so that spread is not purely an engine difference. Only Rapid-MLX and mlx_lm can be compared on the same file. When the same coding-agent tasks were also given to Qwen 3.8 27B, Qwen passed 15 runs and Flint passed 12 (out of 15).

Conclusions first

1. Speed across five engines: 52.4 to 76.0 tokens per second (median of twelve runs, thinking on). Because the files differ, this is not purely an engine difference.
2. Qwen passed more: On 49 tool-call tasks graded by exact text match, it was 36 vs 45 (Flint vs Qwen), and on the coding agent, 12 vs 15 out of 15 runs. In speed it was the opposite: Flint was more than 6 times faster than Qwen in llama-bench generation.
3. Context: With 16-bit KV, the server started up to 98,304 tokens and ran out of memory at 114,688 tokens.

What kinds of numbers appear here

• Our measurement: Values we measured ourselves on the Mac mini M6 32GB. Speeds are the median of twelve runs (4 questions, 3 times each).
• Calculation: Arithmetic on our values (for example, about 8 percent difference, more than 6 times, Fisher's test).
• Developer claim: Values stated by the developer, which we could not verify.
• Third-party report: Values written by someone else.

The reference date is the video's release date, 2026-10-25. The measurements were taken on 2026-10-24 and 2026-10-25.

What is Flint

Flint is an open-weight model from Recursive, released on October 21, 2026. According to the developer, it is a Mixture-of-Experts (MoE) design that computes only about 2.5 billion of its roughly 39.8 billion parameters per token, and it is meant for coding agents that inspect code, fix bugs and write tests (developer claim). The header of the GGUF file we used listed 39,785,287,456 parameters, and the file size was 23,387,911,136 bytes (our measurement).

According to the developer's card, it uses 6 of 256 experts plus 1 shared expert in each of 47 MoE layers. However, the header of our GGUF listed the shared-expert count as 2, which does not match, and we could not determine why. The 2.5 billion is only the amount computed per token; the whole model must still fit in memory, so this does not mean it performs like a 2.5B model.

Test conditions and limits

• Mac mini M6 32GB, one request at a time, greedy decoding (temperature 0, seed 1), at most 256 tokens.
• Four questions (26 to 443 input tokens) run 3 times each, 12 runs, and we used the median.
• Flint is a model that thinks at length, so we measured with thinking on, and the speed includes thinking tokens. In all twelve runs, the 256 tokens were filled with thinking alone.
• Turning thinking off differed by engine. Ollama could do it, and with it off the speed was 79.9 tokens per second with the answer starting in all twelve runs. For Rapid-MLX, mlx_lm and llama.cpp we could not confirm a way to turn it off.
• During speed runs, swap was 5.6 to 14.6 GiB at first, and 2.8 to 6.4 GiB when we re-measured with a lower starting swap. These are not speeds from a clean environment (the video screens show these as GB).

Generation speed by engine

Our measurements (thinking on, median of 12 runs, range in parentheses):

• The same file is used only by Rapid-MLX and mlx_lm: 73.2 vs 67.8, about 8 percent apart (calculation). The ranges did not overlap.
• For Ollama we measured only the qat-int4 tag, and we could not confirm that it holds the same weights. We did not measure the default tag. Its median is the highest, but its range overlaps with the other engines.
• LM Studio used a different file (24.17GB) and swung widely from request to request, between 29.0 and 62.4.
• Even with lower swap, Rapid-MLX, mlx_lm, llama.cpp and Ollama stayed within 2 percent of their first values (Ollama was 76.5).
• The NVFP4 GGUF gave 10.2 at first and 5.5 when re-measured (cause not isolated), so we left it out of the 52.4 to 76.0 range.
• For time to first token (input of about 33,000 tokens), we give values without ranking because the files differ: Ollama 27.6 s, Rapid-MLX 27.4 s, mlx_lm 27.3 s, llama.cpp 48.2 s, LM Studio 50.5 s. The 194.5 s we first got for Ollama did not reproduce when re-measured, and we could not isolate the cause.

As for engine support, as of 2026-10-24 the documentation lists llama.cpp, Rapid-MLX, Ollama, Unsloth and the developer's own engine rec; LM Studio was in its model list, and mlx_lm had it only in the main version. On our Mac, five of them ran. LM Studio failed on runtime 2.41.0 with a Flint chat-template error and loaded on 2.64.0.

We could neither confirm nor refute the developer's speed claims

The developer's blog puts 125 tokens or more on an M4 Pro MacBook Pro and 150 tokens or more on a 64GB RTX Spark in one sentence, and adds "at short context" at the end. It is unclear whether that qualifier also applies to 125, and the engine and file used were not tied to the numbers (developer claim). The creator of Rapid-MLX wrote 131 tokens at about 1,000 input tokens and 118.5 tokens at about 8,000 on an M5 Max 36GB (third-party report, greedy, 256 output tokens).

Our questions had short inputs of 26 to 443 tokens, but our device is an M6 32GB and the engine and file also differ, so we can neither confirm nor refute either set of numbers.

Comparison with Qwen 3.8 27B

Qwen's speeds were measured with thinking off, so we do not put them on the same line as Flint (thinking on). With the same Qwen file and about 2 to 3GB of swap, Splash 1.4 reached 36.2 tokens per second, Rapid-MLX 9.35 and mlx_lm 9.03; on the Korean question alone, Splash 11.1, Rapid-MLX 9.35 and mlx_lm 9.12 (our measurement). Splash gave very different values, 25.7 first and 36.2 on a re-run, with the same server and the same arguments, and we could not isolate the cause.

Measuring with the same llama-bench (depth 0, 128 generated tokens) twice on the same day, Flint was 6.25 to 6.35 times Qwen (calculation). Using the Qwen value of 7.04 from the night before, the ratio would be in the 7s, cause unknown. Each model used its own 4-bit file.

Coding agent

Our 52 coding problems and 49 tool-call tasks are not agent tests. So we had the models solve 5 small-repository tasks (bug fix, feature addition, refactoring, a Korean-language instruction, and long context) in an agent loop. A pass means clearing the hidden tests too, and we ran each task three times with seeds 42, 43 and 44, for 15 runs in total (Qwen with MTP on).

• Out of 15 runs, Qwen passed 15 and Flint passed 12. Flint failed once on the long-context task and twice on refactoring, and passed the Korean-instruction task all three times.
• The three repeats are not independent samples, so this difference cannot be told apart from chance (calculation; Fisher's exact test p=0.22 is for reference).
• The causes of the failures are our tester's estimates: the long-context task used up its turns by repeating a forbidden pipe command, and the refactoring rewrote a whole file and dropped a line.
• Seven runs that had to restart from the beginning because of a memory alarm are mixed in (Flint 1, Qwen 6).
• The total wall-clock time to finish the 15 runs was 1,208 seconds for Flint and 6,950 seconds for Qwen (with MTP on). This is a separate fact, not a model speed comparison.
• The 49 tool-call tasks were run once each, and the grader requires an exact text match, so some answers were marked as failures even when the meaning was right. The 36 vs 45 is therefore this grader's pass count.

Long context and device size

The developer's card lists a context of 262,144 tokens (developer claim). On our Mac mini with 16-bit KV, the server started up to 98,304 tokens and ran out of memory at 114,688, and we did not measure in between. Starting the server is different from filling that length and getting a reply. The largest input we actually filled and got a response for was about 90,000 tokens with 16-bit KV (89,941 tokens), with 224.3 seconds to the first token and generation at 20.65 tokens per second. With 8-bit KV, an input of 119,998 tokens took 369.88 seconds to the first token.

We do not have a 24GB or a 48GB Mac, so we did not measure them. If the limit ratio is assumed to be independent of device size, the calculation says our 23.39GB file does not fit on a 24GB Mac (calculation). For 48GB, the Rapid-MLX creator wrote that it also runs on 36GB (third-party report).

What we did not measure, and limits

• We did not measure the developer's speed claims, a 24GB Mac, a 48GB Mac, running on Windows, or the Ollama default tag.
• These are not clean-environment speeds. There was swap while measuring.
• Tool calls were run once each, so the sample is small, and the three repeats in the agent test are not independent samples.
• We did not complete Qwen's 52 coding problems and KMMLU, nor test real coding tools such as OpenCode. We also could not include speed by input length in the video.
• The terminal screens in the video replay measurement record files; they are not recordings of a live screen.

In short, Qwen had more passes (tool calls 36 vs 45, coding agent 12 vs 15), and Flint took much less time than Qwen (with MTP on).