Apple Silicon の Mac で、2.8兆パラメータ級の MoE モデルをどう動かすか。argonautlabsai/deltafin は、その無茶にかなり真面目に挑んだ GitHub リポジトリだ。単なる「動いた」報告ではなく、SSD から expert をストリーミングしながら、どこまで実用速度に近づけるかをベンチマーク付きで公開している。しかも、モデルを削ったり「だいたい同じ」で済ませたりしない。そこがこの話の面白いところだと思う。
元記事が扱っているのは、ARGODRIVE Deltafin という fork だ。元になっているのは gavamedia/deltafin で、そこに ARGODRIVE の storage work と benchmark package を足したものだという。狙いははっきりしていて、Kimi K3 を「フルのまま」、しかも Apple Silicon 上でできるだけ速く動かすことにある。
README の TL;DR では、Kimi K3 は 2.8T-parameter の MoE モデルで、expert weights は 1.45 TB に達すると書かれている。これを 128 GB の M5 Max MacBook Pro 1台で動かし、4台の SSD から expert を stream する、というのがこのリポジトリの肝だ。ベンチマークでは、512 トークンの回答生成で steady decode が 1.00 tok/s、128 トークンでは 1.13 tok/s、公開 issue #15 の 17 トークンプロンプトでは 0.9631 tok/s を記録している。上流の gavamedia/deltafin では同じ 17 トークンの条件で 0.684 tok/s だったので、そこより速い結果を出したことになる。
ただし、いい話ばかりではない。512 トークンのプロンプトでは、最初の 1 トークンが出るまでにおよそ 376〜375 秒かかる。README はこれを率直に「honest limit」と呼び、原因は prefill が各 layer の experts を 8 回読み直してしまうことだとしている。つまり、生成の途中は 1 tok/s 前後で回っても、最初に文脈を読み込む段階が重すぎる。修正案は見つかっているが、まだ実装はされていない。
面白いのは、ストレージ本数が性能にどう効くかまで見ている点だ。README によると、1台のドライブでも 4台構成の約 52%、2台で約 73%、3台で約 90% まで届く。ここから分かるのは、単純な総帯域ではなく、各 layer で発生する 16 回の read のうち「最も遅いもの」が全体の足を引っ張るということだ。機械的に速いSSDを増やせばよい、という単純な話ではない。
このリポジトリは、モデルの品質を落とさないことも強く打ち出している。Deltafin は「Nothing pruned. Nothing skipped. K3 decides every token.」を掲げ、16 個の routed experts を全部使う。小さな draft model が先読みすることは許すが、最終的に通すかどうかは K3 自身が決める、という設計だ。加えて、Qwen を raw text completion 用のオプションとして足せるが、それも chat を速くするためではなく、同じ出力をより早く出すための補助として扱っている。
README にはインストール方法や upgrade の流れも載っている。setup --full で 1.7 TB の full model を落とす方法と、空き容量が少ない場合に setup --stream で 215 GB から始める方法があり、後者は必要な expert をその都度 fetch する。アップグレードは binary を再ビルドしつつ、既存の model data や cache は残す設計だ。全体として、これは製品というより「どこまでできるか」を詰める研究用の実験場に見える。
このリポジトリで一番おもしろいのは、速くするための工夫が、結局「何が遅いのか」をかなり露骨に暴いてしまっている点だと思う。MoE は全部の重みを毎回使うわけではないので、理屈の上では一見、巨大でも現実的に見える。だが deltafin の結果を見ると、問題は単なる総サイズではなく、どの expert がどの順番で、どれだけ散らばって読み出されるかにあると分かる。4台の SSD で 1 tok/s に届くのに、1台だと半分強まで落ちる。ここには、計算資源よりも I/O の形が支配的になる局面がある。
私は、これは「大きなモデルをローカルで使う未来」の話というより、「巨大モデルが本当に巨大であることを、誰もが再確認する話」だと思う。クラウド側では VRAM を積んだ大規模ノードに隠れていたボトルネックが、家庭用マシンではそのまま露出する。しかも deltafin はそこを誤魔化さず、ベンチマークの遅さまで見せている。研究としては正直だし、実装としても潔い。ただ、利用者にとっては、こうした速度が出てもなお、待ち時間はかなり長い。実験としては面白いが、日常の対話体験としてはまだ厳しい、という線ははっきりしている。
512 トークンの prompt で first token まで約 376 秒という数字は、かなり強烈だ。生成速度が 1 tok/s 前後でも、最初の応答が出るまでに 6 分以上待つなら、体感はまるで別物になる。チャットであれば、この遅さはかなり致命的だと思う。人は「平均トークン速度」より、「返事が返ってくるまでの沈黙」に強く反応するからだ。README が prefill の問題を別枠で扱っているのは正しい。ここを直さない限り、実用性の議論はずっと途中で止まる。
一方で、こういう露骨な遅さが公開されているのは、むしろ価値がある。ベンチマークは速い数字だけを並べると誤解を生むが、deltafin は raw completion と chat 的な使い方を分け、しかも cold run だと明示している。これは「実際の体験」を測る姿勢として評価できる。私は、AI の実運用では平均速度よりも、最初の応答と失敗時の挙動が重要だと考えている。deltafin はその両方を隠していないので、単なるデモよりもずっと信用しやすい。
README は、他のプロジェクトが K3 をより速く動かしているように見えても、それは expert bank を約 3 bit まで再エンコードした結果かもしれない、と釘を刺している。要するに、同じ「K3対応」を名乗っていても、何を削ったかで意味が変わる。ここはかなり重要で、性能比較の土俵そのものを見直さないといけない。圧縮して速くするのは立派な工学だが、それは「元のモデルをそのまま使う」こととは別問題だ。
私は、deltafin の立場はベンチマーク競争というより、忠実性の実験に近いと思う。Moonshot が出した重みをそのまま使い、そのうえでどこまで速くできるかを探る。これは実運用ではなく、むしろ基準点を作る営みだ。こうした基準点があると、圧縮版や量子化版の価値も相対化できる。どれだけ削ると、どれだけ速くなるのか。その引き算の前に、引く前の姿を押さえる必要があるからだ。
ただし、ここにも落とし穴はある。フルモデルへの忠実さは、一般ユーザーの利便性にそのまま結びつくとは限らない。1.7 TB の full model を落とし、4台の SSD を用意し、128 GB のメモリを積む。これは「消費者向け hardware」とは言っても、かなり選ばれた消費者だ。だからこそ私は、deltafin を未来の標準として見るより、「フロンティアモデルを自宅に持ち込むと何が壊れるか」を測る計測器のように見るほうがしっくりくる。
このプロジェクトがいいのは、ただ夢を語るのではなく、何ができて何がまだ無理かをかなり細かく切り分けているところだ。steady decode は 1 tok/s を超え、SSD の台数と速度の関係も出した。いっぽうで prefill の重さと最初の応答遅延も隠さない。こういう資料は、ローカル推論やモデルサービングに関心がある人にはかなり参考になるはずだ。
私は、deltafin の価値は「Mac で 2.8T が動いた」ことそのものより、巨大 MoE をローカルに持ち込むと、計算・メモリ・ストレージ・待ち時間のどれが主犯になるのかをかなり露骨に見せた点にあると思う。派手さはあるが、結局やっているのは地味な計測だ。そこがよい。AI の世界では「できる」と「使える」がすぐ混同されるが、このリポジトリはその境界をはっきりさせている。使えるかどうかはまだ怪しい。でも、何が邪魔をしているかは、かなり見えた。
