DeepSeek新技術移植蘋果晶片！Mac本地大模型加速60%

DSpark剛開源一週，就被搬進了蘋果電腦。

移植版本叫mlx-dspark，跑的是Gemma-4 12B和Qwen3-4B這兩個模型。

裝上之後，這兩個模型在Mac上的生成速度分別提了1.6倍和1.4倍。

更難的是，它做到了大多數移植版本做不到的一件事——輸出和原模型逐字節相同，一個字都不差。

也就是說，速度換來了，質量一點沒丟。

動手的人是Abdur Rahim，業餘時間搗鼓開源項目的一個工程師，DSpark開源以來的第一個Mac原生版本，都是他一個人做出來的。

蘋果電腦跑大模型，提速60%

針對DeepSeek在6月27日開源的DSpark，官方給出的數字是服務端場景下能提速60%到85%。

不過這套技術當時只有數據中心GPU上的實現，沒有適配蘋果芯片的版本。

mlx-dspark是這套技術的第一個蘋果芯片原生版本。

DSpark的思路是配一個更小的模型給目標模型打下手，小模型先一口氣蹦出幾個候選詞，目標模型再一次性核對，對的收下，錯的打回去重猜。

這一步的成本，在數據中心和蘋果電腦上不一樣。

在數據中心的GPU上，核對一批候選詞更像包車，坐幾個人都是一口價，解碼本來就是內存瓶頸，多核對幾個詞幾乎不多花時間。

蘋果芯片更像打表的出租車，核對的候選詞越多，表跳得越多。

Rahim實測過，Gemma-4 12B每多核對一個token，要多花約14毫秒。他把這套帳算成了一個成本模型，得出的結論是，蘋果芯片上的速度天花板在2.2倍左右。

總之，Rahim把這個打下手的小模型從HuggingFace的checkpoint裡搬了過來，分別配給Gemma-4 12B和Qwen3-4B這兩個目標模型使用。

他還把核對流程在MLX框架裡重新搭了一遍，權重量化成4-bit。

結果，在M4 Pro上，對比蘋果官方的MLX工具，Gemma-4 12B的生成速度從18.4tok/s漲到約30tok/s，是原來的約1.6倍；Qwen3-4B從52.9tok/s漲到約73tok/s，是原來的約1.4倍。

另外，在mlx-dspark裡，Rahim還做了一件大多數移植工作沒做的事。

移植版本，也能高精度還原

多數把大模型搬到本地的版本，只支持貪婪解碼，也就是每一步都挑概率最高的那個詞。

Rahim在mlx-dspark裡，把DSpark論文裡原本描述的溫度採樣方法也實現了出來，草稿模型給出候選詞，接受概率是min(1, p/q)，沒通過的部分從殘差重新採樣。

他自己核對過，這套流程跑出來的輸出，嚴格等於目標模型在同樣溫度下會給出的那個精確分佈，不是打了折扣的近似版本。

多數投機解碼只做貪婪版本，是因為驗證貪婪模式的正確性很簡單，逐字比對就行。

Rahim多做的這一步，是自己把採樣模式下跑出來的輸出分佈核對了一遍，確認沒有走樣。

負責核對的目標模型該配哪個精度，是他自己試出來的一個坑。

如果小模型配的是沒經過指令微調的基礎版目標模型，蹦出的候選詞只有47%能通過核對；換成對應的指令微調版本，這個比例漲到82%。

他還測過把目標模型換成bf16精度，核對成本漲得比通過率漲得多，反而更慢，所以目標模型默認留在8-bit上最划算。

負責打前站蹦候選詞的小模型，用的是另一套精度。

草稿模型本身被他做了壓縮，4-bit量化之後只有1.8GB，裝進內存毫無壓力，跑起來還是無損。

結果就是，DSpark不僅實現了加速，也確實把論文裡提到的16%到18%接受率提升，在設備端復現了出來。

DFlash也接了進來，代碼任務更快

推文發出後，評論區來了一條留言，DFlash論文的作者之一Jian Chen問，能不能試試他們團隊的模型。

DFlash是z-lab今年5月發的論文裡提出的另一種投機解碼方案，作者團隊帶頭人Zhijian Liu，UCSD助理教授，同時是NVIDIA的研究科學家。

DFlash的思路和DSpark不太一樣，它用一次並行的「塊擴散」去噪一整塊16個token，而不是像DSpark那樣一步步帶著依賴關係去猜。

Rahim迅速動手。

他用Jian自己寫的移植腳本，把z-lab發佈的gemma4-12B-it-DFlash接到mlx-vlm的Gemma-4目標模型上，在同一台Mac上，跟自己剛測完的DSpark又跑了一輪頭對頭對比。

代碼和數學任務上，DFlash整塊解碼的接受長度能到5.95到6.20，速度約36tok/s，達到約2.1倍，跑贏了DSpark。

但是，DFlash一次要蹦出一整塊16個token，而但目標模型未必全部認可，實際能通過核對的只是其中一部分，業內管這個叫「接受長度」，不是每次都能把16個全填滿。

所以在開放聊天這種內容不好預測的場景裡，接受長度上不去，塊填不滿，DFlash的優勢發揮不出來。

DSpark的Markov頭正是為了對付同一個毛病存在的，並行蹦出一整塊詞，越往後的位置是各自獨立算出來的，容易互相不搭調，Markov頭給這些位置之間加了一層依賴關係，專門糾正這個問題。

結果就是，在聊天場景裡，DSpark反而比DFlash更快。

而後更新的mlx-dspark v0.0.3，正式把z-lab原版DFlash接入了包裡，還加了一個參數，可以手動把DFlash的有效塊長度調短，聊天場景用短塊，代碼和數學場景仍然用滿16的整塊。

這之後，同一台Mac、同一個包，就能同時完成聊天和代碼、數學類的任務，不用再在DSpark和DFlash兩個項目之間來回搬了。

Rahim在推文裡說，同樣的方法，用在更大的Qwen3-8B和14B草稿模型上應該也能跑通。

來源：量子位

風險提示及免責條款

        市場有風險，投資需謹慎。本文不構成個人投資建議，也未考慮到個別用戶特殊的投資目標、財務狀況或需要。用戶應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。