TensorFold vs MTPLX vs mlx-dspark

Speculative decoding has always come with an asterisk. You get more tokens per second, and somewhere in the small print is a note about the output distribution shifting, or a suggestion to run greedy so the drafts line up. Three projects have spent 2026 removing that asterisk on Apple Silicon, and all three now claim the same thing: faster decoding that produces byte-identical output. This is part two of our local inference performance series. In part one we covered making the model smaller. This is the other half, making it faster without changing what it says.

What "exact" is actually claiming

A drafter model guesses several tokens ahead, and the real model verifies them in one batched pass instead of one pass per token. That is where the speed comes from. The risk is that verifying a batch of candidate rows is not arithmetically identical to stepping one row at a time, and that sampling from a drafted distribution is not the same as sampling from the model's own.

Exactness means both problems are closed. TensorFold states the two invariants directly: every token is the model's own sample, drawn as the argmax over top-k and top-p candidates of the logit divided by temperature plus Gumbel noise keyed to seed, position and token id; and a row inside a multi-row verify pass gets the same bits as a single-row step, because the kernels are written so a row's arithmetic does not depend on how many rows share the pass. The stated result is that "drafted decoding writes the same bytes as serial decoding. Drafts change speed only."

MTPLX gets there differently, using exact rejection sampling with residual correction at the model's native temperature rather than a greedy shortcut, so the output distribution is unchanged at any temperature. mlx-dspark describes its port as lossless. The claims converge even though the mechanisms do not.

The three projects

Star counts are a popularity measure, not a quality one, but the ordering is worth knowing before you pick. MTPLX is the one most people are using. TensorFold is the smallest of the three and the only one that also runs on NVIDIA.

MTPLX, the one with the users

MTPLX runs native multi-token-prediction speculative decoding on Apple Silicon behind a server that speaks both the OpenAI and the Anthropic APIs, which is unusual and useful if you point coding agents at it. It needs macOS 14 or newer and an M1 at minimum. Author-reported figures on an M5 Max with 128 GB: 125.8 tok/s on Qwen3.8 Flash Next with an 18.5K-token cached OpenCode request at depth 3, 87.6 tok/s on Qwen3.8 27B on a fresh coding task, and 64.4 tok/s on Ternary Bonsai 2 27B at depth 1.

The memory guidance is the practical part. Ternary Bonsai 2 27B is its recommendation for 16 to 31 GB Macs, Qwen3.8 27B variants want 32 GB, and Flash Next wants 96 to 128 GB. That first line is the direct link back to part one: the ternary model is what makes a 27B viable on a 16 GB machine at all.

brew install youssofal/mtplx/mtplx
mtplx start
mtplx serve --model Youssofal/Qwen3.8-Flash-Next-MTPLX-Optimized-Speed

Note the license condition: Apache 2.0 with mandatory attribution, so anything you ship on top has to display "Powered by MTPLX" with a repository link somewhere user-visible.

mlx-dspark, the port

mlx-dspark is a native MLX port of DeepSeek's DSpark and z-lab's DFlash speculative decoding, MIT licensed, claiming up to 4x faster decoding losslessly. It supports a broad model list including Gemma 4, Qwen3.8, Muse-Glimmer, Nemotron, LFM2.5 and ternary Bonsai-27B. It is the most conservative of the three in scope: a decoding technique ported well, rather than a whole serving product.

TensorFold, the one that crosses to NVIDIA

TensorFold is the only one here that is not Apple-only. It serves an OpenAI-compatible endpoint on Apple Silicon through Metal or on NVIDIA through CUDA, and it will run tensor parallel across two DGX Sparks over InfiniBand. That combination is its reason to exist.

pip install git+https://github.com/ashhart/TensorFold.git
tensorfold serve Vontra/Qwen3.8-27B-MLX-4bit

Author-reported Apple Silicon numbers on an M5 Max with 128 GB: Nemotron 3.5 Lightning at 188 to 206 tok/s on short answers and 162 tok/s at 60k context, Qwen3.8-27B with a DFlash2 drafter at 189 tok/s on code against 26 without drafts, and Qwen3.8 Flash Next at 190 tok/s on a file edit. That 189-against-26 figure is the clearest illustration of what drafting buys you when it works.

On DGX Spark it is measured against vLLM with MTP set to 3, and this is where the sharpest numbers are.

Every figure in both tables is author-reported and none has been independently replicated. Treat the ratios as more durable than the absolute numbers, since the absolutes depend heavily on which vLLM configuration was used as the baseline.

The landmine in TensorFold

TensorFold documents something the other two do not, and it is the most useful paragraph in its README. MLX 0.32.2 fails its exactness checks for Nemotron, and the fix is to downgrade to MLX 0.31.2 before enabling drafts.

That is worth dwelling on because it tells you the exactness claim is being tested rather than asserted. A project that ships a check, runs it against a dependency version and then tells you which version breaks it is a project doing the work. It also means your speed feature can silently become a correctness feature the next time you upgrade a library, so pin MLX.

There is a second caveat in the same spirit: for Flash Next and Nemotron the prompt cache's last bits can differ depending on which prefix was already cached, so a reply can differ too. Drafted and serial decoding from the same cache always match. The exactness guarantee is about drafting, not about cache state, and TensorFold is precise about the difference.

Which one to run

Run MTPLX if you are on a Mac and want the thing most people are running, especially if you point coding agents at a local endpoint, since the Anthropic-compatible API means tools that expect that shape work without a shim. Accept the attribution clause.

Run TensorFold if you have NVIDIA hardware, or a DGX Spark, or both a Mac and a Linux box and want one server that behaves the same on each. It is the smallest project of the three, so weigh that against the flexibility.

Run mlx-dspark if you want the decoding technique under MIT with the least surrounding product, or if your model is on its list and not on the others'.

And if you are still choosing a model to feed any of them, part one covers the ternary 27B that makes this worth doing on a 16 GB machine. For the wider picture of local serving, our Ollama vs llama.cpp vs vLLM comparison is the one to read next, with the caveat that vLLM is the baseline all three of these projects are beating.

Sources and further reading

• MTPLX on GitHub
• TensorFold on GitHub
• mlx-dspark on GitHub
• Ternary Bonsai 2 27B, the model all three can serve

Ten minutes: install whichever one matches your hardware, run the same prompt twice with the same seed, once with drafts on and once off, and diff the two replies. If the project is telling the truth the files are identical and only the clock differs. That is a test you can run yourself, and it is the whole claim.

Tested on: not independently tested. Every throughput figure is author-reported by the project that published it, on hardware we do not have, with no independent replication. Exactness claims are quoted from each project's own documentation and were not verified by us. Star counts, licenses and repository activity were read from the GitHub API on the date below.
Date checked: 2026-09-27