Splash Engine Requirements: Which Macs Run Inco's 36GB AI Engine (2026)

Splash is an open-source inference engine from Inco AI that runs only on Apple Silicon, and it asks for more memory than most local LLM tools. The stated floor is an M3 chip or newer, macOS 26.4 or later, and 36 GB of unified memory, with 48 GB recommended. Exactly two models are supported. The chip requirement, however, bites harder than the memory requirement: a 192 GB M2 Ultra Mac Studio is excluded, while a 36 GB M3 Pro MacBook Pro qualifies.

That inversion is the whole story. Splash is not a general runtime that happens to be fast on a Mac: it is an engine rebuilt around each model it serves, so the requirements follow from that design choice rather than from a marketing decision.

TL;DR: Splash needs an M3-or-newer Mac on macOS 26.4 or later with 36 GB of unified memory, and Inco recommends 48 GB. Two models are supported, both Qwen. For example, a 192 GB M2 Ultra Mac Studio is out, while a 36 GB M3 Pro MacBook Pro is in.

The short answer: M3 or newer, 36GB minimum, 48GB recommended

Inco states the same requirement in four places, so it is easy to verify.

• Chip: Apple M3 or newer. M1 and M2 are not supported.
• OS: macOS 26.4 or later.
• Unified memory: at least 36 GB, with 48 GB or more recommended.
• Installer: Homebrew, through a tap rather than pip.
• Disk: free space for the model, its draft, and a prepared copy of the weights.

Unified memory is the single pool of RAM that Apple Silicon shares between the CPU and the GPU, and that is why a Mac's memory budget decides which models fit.

The install is two commands: brew install incoai/tap/splash and splash serve --model incoai/Qwen3.8-27B-Splash. The server binds 127.0.0.1:8000, authentication is off by default until you set SPLASH_API_KEY, and the API speaks OpenAI Chat Completions, OpenAI Responses and Anthropic Messages, with streaming, tool calls, JSON Schema output, images and inline PDFs. There is no config file. The only settings are ceilings such as --max-memory and --max-context.

The Hugging Face packages appeared on September 17, 2026, and the repository and the Splash 1.0 release followed on September 18. Version 1.0.1 landed on September 20 and 1.0.2 on September 21. As of September 26 the repository reports 817 stars, 79 forks and 38 open issues. The code is mostly Python (36.5 percent), C++ (32.7 percent) and Objective-C++ (22.6 percent), with 5.9 percent Metal, and it is Apache-2.0 throughout.

Splash compatibility table: every Mac configuration that qualifies

This table uses the RAM configurations Apple ships per chip tier, so you can find your machine and stop reading. Does yours qualify?

Two things stand out. First, no MacBook Air qualifies at any configuration, because the Air tops out at 32 GB. Second, memory alone never rescues an M1 or M2 machine, however much of it you bought. In other words, the chip decides before the memory does.

Why 36GB is the floor, and what the 27B package actually occupies

Splash publishes real sizes, so the arithmetic is public. In fact, we ran it from the file listings rather than from a benchmark.

The incoai/Qwen3.8-27B-Splash package is 16.19 GiB across 82 files: a 14.12 GiB 4-bit target, a 1.18 GiB DFlash 2 draft and a 0.87 GiB vision encoder. That is a 17.38 GB download, which matches the 17.4 GB figure on the model card. Inco's blog rounds it the same way, describing 15 GiB of weights and a 1.2 GiB draft before any KV cache.

The incoai/Qwen3.6-35B-A3B-Splash package is larger at 19.51 GiB, because a mixture-of-experts model with 35B total parameters has more weights even though only about 3B are active per token. Inco recommends 48 GB of disk for it against roughly 40 GB for the 27B, counting the prepared weight copy.

A mixture-of-experts (MoE) model is a design that activates only part of its parameters for each token, which is why a 35B total can outrun a dense 27B on the same Mac.

The KV cache is the per-request state a model keeps for the tokens it has already read, and it is the part of the budget that grows with context length. It is also the part nobody has published. Inco says the engine computes a memory budget at startup from the limit Metal recommends, minus the weights, the draft and each request's state. We analyzed the README, the launch post and both model cards, and none of them publishes a per-token KV figure or a 32K footprint. If a model does not fit, startup prints a budget breakdown and stops. One published budget number does exist. A pull request adding low-bit GGUF support states that a 24 GB Mac gets a 16.76 GiB budget, and that the smallest file it could load for the 27B needs about 18.4 GiB, which is why 24 GB machines could not serve it. Inco has not published the equivalent budget for a 36 GB machine. If the same ratio held, a 36 GB Mac would get roughly 25 GiB, leaving about 9 GiB for KV cache after the 27B package's 16.19 GiB. That is our extrapolation from one data point, not an Inco figure.

Is 36GB a hard technical limit or a support policy?

Inco never explains why 36 GB specifically. The blog gives the reason for the higher number instead: 48 GB "leaves room for an editor and a browser while a task runs". That phrasing suggests 36 GB is the point where the package plus a working context fits, and 48 GB is the point where the Mac stays usable while it does.

What is enforced is not a RAM label but a runtime check. Splash verifies the macOS version, probes for sparse buffer support, and computes a memory budget at startup. If the model does not fit, it stops. Consequently, the 36 GB figure is documentation of where that check is expected to pass, not a line of code that reads your RAM and refuses to run.

Why Splash runs exactly two models

The launch post is direct about the trade: there is no generic multi-model runtime and no fallback path. The runtime, scheduler, cache and API are shared across models. Everything else is rebuilt per model, including fused Metal kernels sized to that model's tensor shapes, a DFlash 2 draft trained for it, and a memory plan computed for the machine.

Speculative decoding is the decode path in which a small draft model proposes tokens that the full model verifies in one pass. In Splash it is not an option you enable, it is the only decode path. The draft is a five-layer model that proposes 7 tokens per step. Because it is trained per model rather than borrowed, the speedup holds under concurrency instead of collapsing.

The practical consequence is that support arrives model by model. Inco says more are coming, and an open feature request asks for Gemma 4 26B-A4B. If your model is not on the list, Splash is not the tool, and no amount of tuning changes that.

There is one wrinkle worth knowing. The README on the main branch documents --model accepting upstream repositories directly, including mlx-community 4-bit conversions and Unsloth GGUF files, and its quick start example uses mlx-community/Qwen3.8-27B-4bit. An open issue filed on September 26 reports that Splash 1.0.2 rejects exactly that command with repository has no Splash runtime package manifest.json, on an M4 Max with 64 GB. In the shipped build, therefore, the two incoai Splash packages are what actually load.

Does Splash run on stock MLX?

No. The model card states plainly that the package is not a Transformers or MLX checkpoint and does not load anywhere but Splash. Splash is its own runtime, written in C++, Objective-C++ and Metal, that ingests MLX affine 4-bit or GGUF weights and repacks them into layouts its own kernels decode. The prepared weights live in a separate cache directory, and later starts reuse them.

That explains the install path. Splash ships as a Homebrew tap, not a Python package, and every kernel is precompiled with presets for GPU family, core count and workload. There is no Xcode and no compiler toolchain on your machine. The GGUF kernels include MIT-licensed material from llama.cpp, but the engine is not a llama.cpp build.

If you are choosing between the MLX-based runtimes instead, our MLX vs Ollama comparison covers that ground, and how speculative decoding behaves on a Mac explains why Splash's draft is the interesting part.

The M3 requirement: technical or a support decision?

The short answer is that it is enforced technically, but it does not look like a hardware limit.

A GPU family is Apple's generation label for its GPU cores, and the numbering decides everything here: family 9 starts at M3, family 8 at M2 and family 7 at M1.

Splash rejects M2 machines with the error apple_gpu_family_9_required, and GPU family 9 starts at M3. A pull request opened on September 20 lowers that gate to family 8 for M2, and reports that an M2 Max with 64 GB passes the capability probes, including sparse buffers. The same pull request notes that real-model generation quality and throughput were not validated. Going further back, a community branch adds native Metal kernels for Apple7 and Apple8, meaning M1 and M2. On an M1 Max with 64 GB it reports about 2.1x the decode speed of the stock kernels for a single request, 3.6x for four parallel requests, and 2.3x to 2.7x faster prefill. Inco's own tracker separately records that Apple7 runs correctly with a measured kernel policy once a Simdgroup decode corruption is fixed.

So M1 and M2 hardware can run these kernels. Inco has not documented support for either, and the released binaries refuse them. Treat the M3 floor as a support boundary that is enforced in code, not as proof that your M2 Max is incapable.

The speed numbers: every one of them is a vendor measurement

Inco's published figures come from one machine: a 48 GB M5 Pro. It ran coding prompts from NVIDIA's SPEED-Bench over HTTP, with a 1,024-token output limit and reasoning at medium for the 27B. Single-request figures are medians.

The comparison engines were oMLX, Lily, uzu and Ollama, each at its own recommended settings, so these are end-to-end results rather than isolated kernel benchmarks. Inco also reports that with 16 concurrent 32K requests, Splash completed all 16 while a general-purpose memory policy accepted nine. It notes, however, that it did not test whether another engine could be configured to match.

LM Studio's launch post repeats the 27B numbers, roughly twice the decode speed of the next-fastest engine measured, 74 tokens per second on short prompts and 54 at 32K. LM Studio attributes them to Inco's tests. That is a second publisher, not a second measurement.

As of September 26 we found no independent Mac reproduction from a lab, a reviewer or a benchmark suite. A figure of 144 tokens per second on an M5 Max MacBook Pro circulates in third-party write-ups and is attributed to Inco's launch video. That figure, however, appears in no primary Inco or LM Studio page we could check, so we do not treat it as a published Inco result.

One internal inconsistency is worth flagging: the README describes the benchmark machine as an M5 Pro with a 16-core GPU in one table and a 20-core GPU in another. The 48 GB figure is consistent everywhere.

What users actually measured, on machines Inco did not test

So what do owners on supported hardware actually get? The most useful numbers sit in the project's own issue tracker, where users posted results on hardware Inco never benchmarked. These are single reports with unpublished prompts, not independent lab work, but they are the only non-vendor data that exists.

On a MacBook Pro M3 Max with 40 GPU cores and 128 GB, one user ran Splash 1.0.1 against Ollama and an MLX server on the same machine and day. For Qwen3.6-35B-A3B, Splash decoded at 98.8 tokens per second against 96.2 for the MLX server and 84.7 for Ollama. For Qwen3.8-27B, Splash decoded at 30.0 tokens per second against 42.5 for Ollama's MLX path, so Splash lost on the dense model on that machine. Inco's own M5 Pro figures for the same two models are 210 and 74 tokens per second, so the gap between the published numbers and a real M3 Max is wide.

On a MacBook Pro M5 Max with 36 GB, the documented minimum, another user confirmed the engine side of the story. Splash 1.0.1 decoded at 232 tokens per second, prefilled at roughly 3,400 tokens per second, hit its prefix cache 91.8 percent of the time against 47.5 percent for LM Studio, and accepted an 81,844-token prompt. The same report found the agent loop needed 110 to 207 or more turns where LM Studio finished in 60, which is a workflow problem rather than a throughput one.

That is the honest shape of the evidence. Throughput claims hold up on at least two machines. Model quality and agent behaviour on those machines have open issues against them.

Known problems on specific Macs

• M3 Ultra with a 60-core GPU: Splash 1.0.2 produces garbage output at a batch width of one and fails the engine entirely at two or more. Versions 1.0 and 1.0.1 are correct on the same machine. A root cause was identified in the Apple9 decode path, and the fix was merged on September 25, but no release contains it yet. Therefore, if you own an M3 Ultra, pin 1.0.1 for now.
• M5 Max, 36 GB: the documented minimum works. The agent-turn behaviour described above, however, is an open issue.
• M4 Max, 64 GB: the README's upstream MLX loading path fails on 1.0.2 with a manifest error.
• Hugging Face: both packages report zero tracked downloads. The model pages also state that downloads are not tracked for these repositories at all, so the zero is not evidence of usage in either direction. The packages show 94 and 23 likes.

If you are picking a machine for this kind of work rather than testing one you own, our Mac Studio M5 Max 48GB breakdown and the M5 Pro and M5 Max guide cover the tiers Splash actually targets.

What is not verified

• No independent reproduction of Inco's throughput figures on any Mac, as of September 26, 2026.
• Similarly, the KV cache footprint at 32K context, and the memory budget on a 36 GB machine, which Inco has not published.
• Whether 36 GB is a technical floor or a support policy, since Inco documents the check but not the reasoning.
• Whether M1 and M2 are excluded for technical reasons or for support scope. Community kernels suggest the hardware is capable.
• The 144 tokens per second M5 Max figure, which we could only find in third-party summaries.
• The GPU core count of Inco's benchmark machine, which the README states inconsistently.

FAQ

Does Splash run on an M1 or M2 Mac?

Not with a released build. Splash rejects those machines with a GPU family error, and GPU family 9 begins at M3. Community work adds M1 and M2 kernels and reports that an M1 Max runs them, and a pull request lowers the gate for M2, but Inco has not documented support for either generation. If you have an M1 or M2 Mac, an MLX-based runtime is the practical route, and our Qwen3.8-27B local guide covers that.

Can I run Splash on a 32GB MacBook Air?

No. The Air tops out at 32 GB and Splash asks for at least 36 GB. Inco's own low-bit GGUF work found that a 24 GB Mac gets a 16.76 GiB memory budget while the smallest loadable 27B file needs about 18.4 GiB, which is the shape of the problem. A 36 GB MacBook Pro with an M3 Pro, M3 Max, M4 Max or M5 Max is the cheapest entry point.

Is 36GB of unified memory enough for Qwen3.8-27B in Splash?

It is the stated minimum, and 48 GB is what Inco recommends. The 27B package occupies 16.19 GiB before any KV cache, so the question is how much context you want to hold at once. On a 36 GB machine that leaves roughly 9 GiB for KV cache if the same budget ratio holds as on a 24 GB Mac, which is our extrapolation rather than a published number.

Does Splash replace Ollama or LM Studio for all my models?

No. Splash supports two base models, Qwen3.8-27B and Qwen3.6-35B-A3B, and there is no generic runtime behind them. Keep a general engine for everything else. If you would rather not touch a terminal at all, Splash also ships inside LM Studio Bionic 1.1.5 or newer under experimental backends, and our no-terminal LM Studio guide walks through that path.

How fast is Splash on a Mac?

Inco reports 74 tokens per second on Qwen3.8-27B short prompts and 210 on Qwen3.6-35B-A3B, both on a 48 GB M5 Pro, with 54 and 143 at a 32K context. Those are vendor numbers with no independent reproduction. On an M3 Max, one user measured 30 and 98.8 tokens per second, so expect the published figures to overstate what older supported hardware delivers.

Every number in this article is either a vendor figure we opened ourselves or our own arithmetic, labelled as such. How we work: about ModelFit. Corrections welcome: contact.