DeepSeek's Open Source Model Ported to Mac Within a Week — by a Hobbyist Engineer

DeepSeek's open-source release was ported to Mac within a week, all thanks to an amateur engineer. Just one week after DeepSeek's DSpark technology went open-source, someone managed to port it to Apple computers. The ported version, called mlx-dspark, runs two models: Gemma-4 12B and Qwen3-4B. Once installed, the generation speed on Mac improved by 1.6 times and

💡 What You Will Learn

DeepSeek's open-source release was ported to Mac within a week, all thanks to an amateur engineer. Just one week after DeepSeek's DSpark technology went open-source, someone managed to port it to Appl

# DeepSeek's Open Source Model Ported to Mac Within a Week — by a Hobbyist Engineer Just one week after DeepSeek open-sourced its DSpark technology, someone has already ported it to Apple computers. The port is called **mlx-dspark**, running two models: Gemma-4 12B and Qwen3-4B. After installation, generation speeds on Mac improved by **1.6x and 1.4x** respectively — Gemma-4 12B jumped from 18 tokens per second to roughly 30, while Qwen3-4B went from 53 to about 73. In plain terms: running large models on Mac used to feel like squeezing toothpaste from a tube; now it's at least a faucet turned halfway on. What's even more impressive is that it achieves something most ports can't — the output is **byte-for-byte identical** to the original model, not a single character off. Speed gained, quality intact. The person behind it is **Abdur Rahim**, an engineer who tinkers with open-source projects in his spare time. The first native Mac version of DSpark after its open-source release — done by one person. ## Giving Large Models a "Helper" to Lend a Hand DSpark's principle isn't complicated: pair the target large model with a smaller model that assists it. The small model quickly generates a few candidate tokens, and the target model verifies them all at once — accepting the correct ones and rejecting the wrong ones for a retry. But this step has completely different cost structures on data center GPUs versus Apple silicon. On data center GPUs, verifying a batch of candidates is like chartering a bus — flat rate regardless of passenger count. Decoding is already memory-bound, so verifying a few extra tokens costs almost nothing in additional time. Apple silicon is more like a metered taxi — the more candidates you verify, the higher the meter runs. Rahim measured that for Gemma-4 12B, each additional token verified costs roughly **14 milliseconds**. He turned this into a cost model, concluding that the theoretical speed ceiling on Apple silicon is around **2.2x**. The current 1.6x achieved still leaves room before hitting that ceiling. Rahim pulled the helper model from HuggingFace, rebuilt the verification pipeline using the MLX framework, and quantized the weights to 4-bit. After compression, the small model is only **1.8GB** — fits into Mac memory with zero strain, and runs losslessly. ## Going One Step Further Than Others Most local ports of large models only support "greedy decoding" — picking the highest-probability token at each step, simple and crude. Rahim also implemented the temperature sampling method from the DSpark paper. After the draft model produces candidates, a precise probability-based acceptance mechanism kicks in, with rejected tokens resampled from the residual. He verified personally that the output strictly matches the exact distribution of the target model at the same temperature — not a watered-down approximation. He also stumbled upon a precision-matching pitfall: if the small model is a base version without instruction fine-tuning, only **47%** of candidates pass verification; switching to the instruction-tuned version raises that to **82%**. But upgrading the target model to bf16 precision turned out to be counterproductive — verification costs rose more than the acceptance rate improved, making it slower overall. His final optimal configuration keeps the target model at **8-bit**. These details aren't in the paper — only someone who's actually done the porting can uncover them. ## A Comment in the Thread Leads to Another Technology After the tweet went out, a comment appeared — from **Jian Chen**, one of the authors of the DFlash paper, asking: "Could you try our team's model?" DFlash is another acceleration approach proposed in a z-lab paper this May, led by **Zhijian Liu**, assistant professor at UCSD and research scientist at NVIDIA. Its approach is fundamentally different from DSpark: it uses a single parallel "block diffusion" pass to denoise an entire block of **16 tokens** at once, rather than DSpark's step-by-step dependency-based guessing. Rahim moved quickly. On the same Mac, he ran a head-to-head comparison against the DSpark he'd just benchmarked. On coding and math tasks, DFlash achieved an acceptance length of **5.95–6.20**, running at roughly **36 tok/s**, about **2.1x** — beating DSpark. But in open-ended chat scenarios where content is hard to predict, the acceptance length doesn't climb, blocks don't fill up, and DFlash's advantage fails to materialize. DSpark's Markov head exists precisely to solve this problem — when a whole block of tokens is generated in parallel, later positions are computed independently and can clash with each other; the Markov head adds dependencies between those positions. The results are clear: **DSpark is faster for chat, DFlash is stronger for code and math.** Version v0.0.3 officially integrated DFlash into the same package, adding a parameter to manually adjust block length. On the same Mac, in the same package, both chat and code/math workloads are covered — no more juggling between two projects. ## Why This Matters Three signals: **First, running large models on Mac has moved past the "it just runs" stage.** The two pain points of local deployment used to be: slow, and quality degradation. The DSpark + DFlash combination tackles both simultaneously — speed (up 60% to 110%) and precision (byte-for-byte lossless). Gemma-4 at 30 tokens per second on an M4 Pro is already more than adequate for everyday code assistance and content generation. **Second, a hobbyist developer can outpace a team.** Rahim isn't a DeepSeek employee, isn't an Apple employee — just an engineer tinkering with open-source projects on his own. One week after DSpark's open-source release and two months after the DFlash paper, he single-handedly brought both technologies to Mac, complete with engineering optimizations the papers never mentioned. The leverage of the open-source ecosystem is on full display here — the day a technology is open-sourced is the day it begins growing on every platform. **Third, speculative decoding is moving from data centers to edge devices.** The "large-small model collaboration" approach represented by DSpark and DFlash will become the standard paradigm for running large models on Apple silicon. Rahim himself noted that the same method should work on larger models like Qwen3-8B and 14B. Once that path is paved, Mac will no longer be synonymous with "weak inference" — at least for local models, it's more than enough. --- > Source: QbitAI / 36Kr > Project URL: https://github.com/ARahim3/mlx-dspark > Original article: https://www.36kr.com/p/3879842615308547