Can a 48GB Mac Run Recursive Flint int4? 22.580 GB

Yes, and 48 GB is precisely where Recursive draws the line for its own engine. The int4 MLX repository of Flint weighs 22.580 GB, 22,580,274,020 bytes across its five weight shards plus tokenizer and assets, which leaves real headroom inside a 48 GB machine once macOS and the KV cache have taken their share. The catch is not the file, it is the runtime: rec, the vendor's engine that carries the speed claim, supports only M4 Pro, M5 Pro and M5 Max silicon with at least 48 GB of unified memory. A 32 GB Mac gets Flint through a different door, the Ollama tag, whose model layer is 22.863 GB of NVFP4 weights. That one loads, but it sits at the edge of the budget.

TL;DR: A 48GB Mac runs Flint int4 comfortably: 22.580 GB of weights against roughly 35 GB of usable model budget, and 48 GB is the floor Recursive sets for rec. A 32 GB Mac runs the Ollama tag instead, 22.863 GB, which is a heavy fit: close other apps and keep the context short. llama.cpp needs nightly b11803 of 2026-10-21 or newer, because FlintForCausalLM landed that day in PR #30928. The 125 tokens per second figure is a vendor measurement taken with rec on an M4 Pro, so it does not transfer to base M4, M5, M1, M2 or M3 chips, which rec does not support.

Does Recursive Flint run on your Mac?

The answer splits by tier, and the deciding number is the weight file, not the parameter count. Flint activates about 2.5 billion parameters per token out of 39.8 billion total (Flint model card, 2026), and every one of those 39.8 billion still has to be resident in unified memory before the first token comes out.

The budget column is ModelFit's own sizing rule, the same one the recommender applies to every model in the catalog. The usable share of unified memory ramps from 70 percent at 32 GB and below to 85 percent at 128 GB and above, because macOS caps how much memory the GPU can wire and the ceiling scales with total RAM. The reasoning behind the numbers is in how much VRAM an LLM needs. No runtime peak has been published for Flint on Apple Silicon, so a fit is not a promise about speed.

Two tiers deserve the warning. On 32 GB the Ollama tag at 22.863 GB sits just above the roughly 22 GB budget, which is the same heavy-fit zone our Mac Mini M6 32GB picks live in: the weights load, but the context window is on a diet and everything else on the machine should be closed. On 24 GB only the small unsloth quants are realistic, which is the tier documented in Best LLM for Mac Mini M6 with 24GB RAM.

What Flint actually is

Attribute this one before anything else: the model card is the only primary description, and the render order below follows it.

• Developer: Recursive. Released 2026-10-21, Apache 2.0 license, text in and text out, no vision.
• Size: 39.8 billion total parameters, approximately 2.5 billion active per token including the output head. The active body alone is about 2.2 billion.
• Shape: 49 layers, 2 dense followed by 47 mixture-of-experts layers, with 256 routed experts per MoE layer, 6 selected per token, plus an always-active shared expert.
• Attention: 35 sliding-window layers with a 513-token window, and 14 full-attention layers. That mix is why long contexts stay cheaper here than on a dense model of the same total size.
• Vocabulary: 150,144 tokens. Documented context configuration: 262,144 tokens. Stated knowledge cutoff: June 2026.
• Capabilities: reasoning and multi-turn tool use, OpenAI-compatible tool calls, no multimodal input.

Flint is a coding specialist built for agent work: reading a repository, tracing a bug, writing the test. If that is not your workload, a general model of similar size still serves you better, and our local coder comparison covers where the alternatives sit on this tier of the market. The most direct size-class rival on a 16 GB Mac remains the small coder class, and Ornith 1.0 9B is the reference point there.

The measured size ladder

Every figure below is a sum of the file sizes the Hugging Face Hub reports for those repositories, read on 2026-10-22, in decimal units. That matters, because "23 GB" on an Ollama page and "22.580 GB" in a download plan are the same file described to different precision, and mixing decimal gigabytes with binary gibibytes is how people buy the wrong Mac.

Two clarifications that matter more than the table itself. The int4 MLX repository does not shard into a single number that the card states; its own README says the weights occupy approximately 22.6 GB, and the 22.580 GB figure above is the sum of the five shards plus tokenizer, chat template and assets, which is the number that shows up in a download or on a disk. Also, the BF16 checkpoint is not a Mac target at all: Recursive's own instructions run it with the SGLang kit on one B300 or H200 GPU per replica.

One more thing the file sizes do not show: the KV cache of the int4 build is bf16, per its own config, and the repository declares a maximum context of 262,144 tokens. Weights are a fixed cost, the cache is not, which is the whole reason a 48 GB machine is comfortable here and a 32 GB one is not.

Which runtime loads which file

Three paths can read Flint today, and they do not accept the same files.

Ollama

Ollama shipped Flint support in v0.40.8, released 2026-10-21, with the note that Flint is supported on MacOS and other GPU support will be enabled in a subsequent release. That Mac-only restriction is a temporary state of the release, not a design decision of the model. The library page lists a 256K context window, and the tags on 2026-10-22 are flint:latest, flint:40b, flint:40b-a2b, flint:40b-a2b-gguf-nvfp4, flint:40b-a2b-qat-int4, flint:40b-a2b-q4_1 at 26GB and flint:40b-a2b-mlx-bf16 at 80GB.

The default tag is the one to size against. Its registry manifest stores a single 22,863,084,384-byte model layer named flint-nvfp4.gguf, which is 22.863 GB of 4-bit NVFP4 weights, run through the llama.cpp runner and displayed by Ollama as 23GB. That is why the honest Mac verdict is not "23 GB fits 24 GB": it does not. It fits 32 GB tightly and 36 GB and up with room. The install itself is the standard one, covered in how to install Ollama on Mac, and the runtime trade-offs between Ollama's engine and MLX are in MLX vs Ollama on Mac.

llama.cpp

Flint's architecture, FlintForCausalLM, was added in PR #30928 and reached a nightly build the same day: b11803, published 2026-10-21. Install b11803 or newer, or a build from source after that commit. Release builds older than b11803 cannot read these GGUF files at all, so a stable llama.cpp from before that date will fail on the architecture rather than on memory. Two details from the pull request are worth knowing before you spend an evening on it: the conversion path expects the NVFP4 and INT4 GGUF repositories from Recursive, and the adaptive expert-activation scaling it uses costs a reported 10-30 percent of throughput as a temporary workaround, which the follow-up work is meant to remove.

rec

rec is Recursive's own inference engine, published at v0.1.0 on 2026-10-21. It is also the only path that carries the speed claims, and its requirements are narrow: an Apple silicon Mac with an M4 Pro, M5 Pro or M5 Max, at least 48 GB of unified memory, about 30 GB of free disk space, and Node.js 22 for the pi harness (rec README). Base M4, M5, M1, M2 and M3 chips are not listed, so the 24 GB M4 Pro MacBook Pro is out on the memory floor even though the silicon is supported. The engine downloads the int4 weights, which is where the 22.580 GB figure in this article's title comes from.

The 125 tokens per second claim, and who it applies to

Be precise about the provenance here: every speed figure below is Recursive's own measurement, published with rec, on the hardware named in the source. Nobody independent has rerun Flint on a Mac yet, and ModelFit does not have an engine estimate for it.

The blog post states the 125 tokens per second figure in the context of a 128k-token session with prefill excluded, and the engine's own chart was produced with five runs per context at the same settings. Read the second table row as the honest brake on the first: the same engine only claims 1.4 to 2.6 times llama.cpp, which is a much smaller multiple than the marketing sentence suggests, and it is a comparison against llama.cpp rather than against MLX. On a Mac, the runtime usually decides the outcome before the model does, which is the argument in does speculative decoding speed up local LLMs on Mac. If your Mac is not an M4 Pro, M5 Pro or M5 Max, none of the numbers in this section describe your machine, and the honest expectation is that llama.cpp or Ollama carries you at whatever your bandwidth allows.

The context window: 512K, 256K and 262,144 are three different promises

These numbers get merged in every summary of the release, so keep them apart.

• Recursive's announcement says Flint supports context windows of up to 512K tokens, and recommends staying within 256K tokens for the best results (Introducing Flint).
• The model card's documented context configuration is 262,144 tokens, prompt and generated output sharing that window (Flint model card).
• Ollama's library lists a 256K context window for the tag, which is the same 262,144 rounded.
• The int4 MLX repository declares a maximum context of 262,144 tokens and bf16 KV.

The practical reading: 512K is a capability ceiling, 262,144 is what the weights were configured and shipped for, and 256K is the same number as the vendor's own advice. The capacity is also not a promise of uniform accuracy at that length, and the card says so itself.

Quality scores, all publisher-reported

Flint's release evaluations report the following, all measured by Recursive and none reproduced independently yet:

Sampling was temperature 1.0, top-p 0.95 and top-k 20, with agentic scores reporting average pass@1 over at least five attempts. The model card also flags a caveat worth repeating: comparison scores from other developers may not apply the same retrieval adjustment, so the table is not an apples-to-apples leaderboard. Treat 54.9, 89.7 and 74.2 as claims from the publisher until someone reruns them.

FAQ

Can a 48GB Mac run Recursive Flint int4?

Yes. The int4 MLX repository totals 22.580 GB, which leaves roughly 12 GB of the 48 GB machine's usable budget for the KV cache, activations and macOS. The 48 GB figure is not a coincidence either: it is the minimum unified memory Recursive states for rec, on an M4 Pro, M5 Pro or M5 Max. The int4 file also fits a 36 GB machine on weights alone, but rec will not install there.

What is the smallest Mac that runs Flint?

A 32 GB Mac, through the Ollama default tag at 22.863 GB. That is a tight fit: the weights land just above the roughly 22 GB budget ModelFit sizes to, so close other applications and keep the context short. On 24 GB only the unsloth low-precision quants fit, the smallest being UD-IQ1_M at 11.352 GB.

Which llama.cpp build do I need for Flint?

Nightly b11803, published 2026-10-21, or any newer build. FlintForCausalLM landed that day in pull request #30928, so a stable release from before that date cannot read the GGUF files. Expect the reported 10-30 percent throughput cost of the expert-activation scaling workaround until its follow-up patches land.

Is Flint free to run locally?

Yes, the weights are Apache 2.0 on both the base repository and the int4 build. The license covers the weights only; hosted API terms and data practices are a separate matter.

Do the 125 tokens per second numbers apply to an M1, M2, M3 or base M4?

No. rec is limited to M4 Pro, M5 Pro and M5 Max with 48 GB of unified memory, so those chips cannot run the engine the number was measured on. On an M1, M2, M3 or base M4 Mac, Flint is still usable through Ollama or llama.cpp, but the speed depends entirely on your memory bandwidth and quant choice, and no vendor figure exists for that combination.

Sources

• Recursive Flint model card: architecture, 39.8 billion total parameters, approximately 2.5 billion active, 49 layers, 256 routed experts, 262,144-token context configuration, and the 54.9%, 89.7% and 74.2% evaluation results with their harnesses.
• Introducing Flint: release announcement of 2026-10-21, the 125 tokens per second and 150 tokens per second claims, the 512K context support with the 256K recommendation, and the quantization notes behind the NVFP4 build.
• flint-int4 repository and its blob listing: group-64 affine int4 with int8 embeddings, approximately 22.6 GB of weights, bf16 KV, 262,144-token maximum context, and the 22,580,274,020 bytes summed above.
• flint base repository and its blob listing: the 15-shard BF16 checkpoint totaling 79,575,138,056 bytes.
• unsloth/flint-GGUF and its blob listing: every GGUF size in the ladder, from UD-IQ1_M at 11,352,241,600 bytes to the 79,576,479,200-byte BF16 build.
• Ollama library page for flint: the 256K context window and the tag list as of 2026-10-22, and the v0.40.8 release notes for the MacOS support note and the 54.9% and 74.2% figures Ollama repeats from the model card.
• Ollama registry manifest for `flint:latest`: the 22,863,084,384-byte flint-nvfp4.gguf model layer behind the displayed 23GB.
• llama.cpp PR #30928 and nightly b11803: FlintForCausalLM support, the GGUF repositories it targets, and the 10-30 percent throughput note.
• rec README and rec v0.1.0: the 1.4 to 2.6 times llama.cpp claim, the M4 Pro, M5 Pro and M5 Max requirement, 48 GB of unified memory, about 30 GB of disk, and the M4 Pro 48 GB measurement conditions.