DeepSeekの新技術がAppleチップに移植！Macローカルの大規模モデルが60%高速化

DSparkがオープンソース化されてわずか1週間で、Apple製コンピューターに移植された。

移植版はmlx-dsparkと呼ばれ、Gemma-4 12BとQwen3-4Bの2つのモデルで動作する。

インストール後、Mac上でのこれら2つのモデルの生成速度はそれぞれ1.6倍と1.4倍に向上した。

さらに難しいのは、ほとんどの移植版では実現できないこと――出力が元のモデルと1バイト単位で完全に一致し、一字も違わないことだ。

つまり、速度を向上させても、品質はまったく損なわれていない。

この作業を行ったのはAbdur Rahim氏。余暇を利用してオープンソースプロジェクトに取り組むエンジニアであり、DSparkがオープンソース化されて以来初のMacネイティブ版も、彼一人で作り上げたものだ。

Apple製コンピューターで大規模言語モデルを実行、速度60%向上

DeepSeekが6月27日にオープンソース化したDSparkについて、公式の数値ではサーバーサイドのシナリオで60%から85%の速度向上が可能とされている。

ただし、この技術は当時データセンターのGPUでの実装しかなく、Appleシリコン向けのバージョンは存在しなかった。

mlx-dsparkは、この技術初のAppleシリコンネイティブ版である。

DSparkの考え方は、ターゲットモデルに補助させる小さなモデルを用意し、まず小さなモデルが一気にいくつかの候補単語を生成し、ターゲットモデルが一括で検証、正しいものは採用し、間違っているものは破棄して再推測させるというものだ。

このステップのコストは、データセンターとApple製コンピューターでは異なる。

データセンターのGPUでは、候補単語のバッチ検証はチャーター便のようなもので、人数に関わらず定額料金。デコードはそもそもメモリ律速であるため、余分に単語を検証してもほとんど時間がかからない。

Appleシリコンはタクシーのメーター制のようなもので、検証する候補単語が増えるほどメーターも多く回る。

Rahim氏の実測によれば、Gemma-4 12Bでは、1トークン追加で検証するごとに約14ミリ秒余分にかかる。彼はこの計算をコストモデルとしてまとめ、Appleシリコンでの速度上限は約2.2倍と結論付けた。

ともあれ、Rahim氏はこの補助役の小さなモデルをHuggingFaceのチェックポイントから移植し、Gemma-4 12BとQwen3-4Bのターゲットモデルそれぞれに組み合わせた。

さらに、検証プロセスをMLXフレームワーク内で再構築し、重みは4ビット量子化した。

その結果、M4 Pro上でApple公式の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ビットにしておくのが最も効率的だと結論付けた。

先陣を切って候補単語を生成する小さなモデルには、別の精度が使われている。

ドラフトモデル自体は圧縮されており、4ビット量子化後はわずか1.8GB。メモリへの読み込みに全く負担がなく、動作はロスレスだ。

その結果、DSparkは加速を実現しただけでなく、論文で言及されていた16%から18%の受理率向上をデバイス上でも再現できた。

DFlashも統合、コードタスクでさらに高速化

ツイート投稿後、コメント欄にひとつの書き込みがあった。DFlash論文の共著者であるJian Chen氏が、自分たちのチームのモデルを試してみてほしいと尋ねてきたのだ。

DFlashは、z-labが今年5月に発表した論文で提案された別の投機的デコード方式。著者チームのリーダーはZhijian Liu氏、UCSD助教であり、同時にNVIDIAの研究科学者でもある。

DFlashの考え方はDSparkとは少し異なり、並列の「ブロック拡散」を用いて16トークンのブロック全体を一度にノイズ除去する。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トークン全体を生成しようとするが、ターゲットモデルがすべてを承認するとは限らず、実際に検証を通過するのはその一部に過ぎない。業界ではこれを「受理長」と呼び、毎回16全部が埋まるわけではない。

そのため、オープンチャットのような内容予測が難しいシナリオでは、受理長が伸びずブロックが埋まらず、DFlashの利点が発揮されない。

DSparkのMarkovヘッドはまさに同じ問題に対処するために存在する。並列にブロック全体の単語を生成すると、後の位置ほど互いに独立して計算されるため、整合性が取れなくなりやすい。Markovヘッドはこれらの位置に依存関係を追加し、この問題を修正する。

その結果、チャットシナリオではDSparkの方がDFlashよりも速くなる。

その後アップデートされたmlx-dspark v0.0.3では、z-lab版のDFlashが正式にパッケージに統合され、DFlashの有効ブロック長を手動で短く調整できるパラメータも追加された。チャットシナリオでは短いブロック、コードや数学のシナリオでは引き続き16の完全ブロックを使用する。

これにより、同じMac、同じパッケージで、チャットとコード・数学の両方のタスクを同時にこなせるようになり、DSparkとDFlashのプロジェクト間を行き来する必要がなくなった。

Rahim氏はツイートで、同じ手法はより大きなQwen3-8Bや14Bのドラフトモデルでも動作するはずだと述べている。

出典：量子位

リスク注意事項及び免責条項

        市場にはリスクが伴い、投資は慎重に行う必要があります。本稿は個人の投資アドバイスを構成するものではなく、特定のユーザーの特別な投資目標、財務状況、またはニーズを考慮したものでもありません。ユーザーは本稿の意見、見解、または結論が自身の状況に適合するかどうかを検討する必要があります。これに基づく投資については、自己責任でお願いします。