Distributing LLM inference in DwarfStar

Salvatore Sanfilippo

DwarfStarにおけるLLM推論の分散

ハイエンドなNVIDIAカード、そしてそれを動かすためのサーバーや電源には、とにかく金がかかる。巨大なモデルを動かすのに十分なVRAMを確保しようとすれば、なおさらだ。これまでの代替案はAppleのハードウェアか、DGX Sparkだった。Sparkはメモリ帯域の制約がかなり厳しいものの、LLMのプロンプト処理(prefill)くらいは十分速くこなせる。Mac Studioは最大512GBのユニファイドメモリを提供してくれた。メモリ帯域は控えめだがSparkよりはずっとマシで、計算性能も考えれば、現状を踏まえると比較的まともな価格だった。

例えばDwarfStarを使えば、Mac Studio M3 Ultra 512GBでDeepSeek v4 PROをprefill 150 t/s、デコード約10〜13 t/sで動かせる。速いとは言えないが、用途によっては十分実用的な水準だ。2ビット量子化してもDeepSeek v4 PROの耐性は非常に高く、同じ量子化のFlashと同様に品質を保つ(今日はPROにCコンパイラを書かせてみた。動画は近々公開する)。約1万2000ドル程度の総コストでフロンティアモデルを自宅で動かせるというのは、決して当たり前のことではないと思っている。

この先どんどん良くなることを期待したいところだが、見通しは曇っている。NVIDIA構成が安くなる見込みはほぼゼロだし、小さな会社でさえローカル推論のために小さなデータセンターを気軽に買って運用できるわけではない。同時にRAM不足の影響で、M5 Ultraを搭載したMac Studioが出る可能性はあまり高くなさそうだ。仮に出たとしても1.2T/s程度のメモリ帯域と、より高い計算性能になるだろうが(M5 Maxはすでに計算性能では上回っており、各GPUコアに特定のモデルで効くNeural Acceleratorを内蔵している)。

つまりローカル推論における現状のベストマシンは、おそらくラップトップだ。M5 Max 128GBなら、DeepSeek v4 FlashやMimo V2.5を2ビット量子化で、かなりまともなprefillとデコード速度で動かせる。prefillで約500 t/s、デコードで約35〜40 t/sといったところで、コンテキスト長が伸びても性能低下は非常に緩やかだ。構成にもよるがコストは6000〜7000ドル程度で、現時点では最もお買い得な選択肢の一つと言える。

こういう状況なら、ローカル推論プロジェクト一般、そしてとりわけDwarfStarにとって、分散推論に目を向けるのは面白くなってくる。MacBook M5 Maxが2台、3台、4台あったら何ができるだろうか。あるいは512GBのM3 Ultraが2台あったらどうか。

従来、分散推論には大きく分けて2つの方式がある。一つはメモリを分散させる方法で、Transformerのレイヤーの50%をマシンAに、残りの50%をマシンBに載せて、推論を逐次的に実行する。この場合、やり取りするのはactivationだけで概念的には非常にシンプルだし、マイクロバッチの工夫を加えれば、単にメモリを倍増させるだけでなく、理論上はプロンプト処理速度を大幅に上げることも可能になる(ただしデコードは別だ。1トークンを生成するたびに、まずマシンAの前半レイヤー、次にマシンBの後半レイヤーと順番に待つ必要がある。とはいえ発熱は少なくなるので、持続的な負荷をかけやすくなるという利点はある)。これは決して悪くない。例えば512GBのMac Studioを2台持っている幸運な人なら、フルサイズのDeepSeek v4 PROを動かせるということだ(2ビット量子化版でさえ非常に良く動いているとはいえ)。しかもマイクロバッチを使えばprefillをさらに高速化できる。

もう一つのアプローチは、AppleのRDMAを使って2台のマシン間で実行を並列化する、要するに垂直分割だ。例えば同じ2ビット量子化モデルをマシンAとBの両方に載せる。どちらにも収まるサイズで、それぞれがすべてのrouted expertを持つようにする。そして各レイヤーで、expertの半分をマシンA、残り半分をマシンBで実行するように協調させるわけだ(両方のマシンがすべてのexpertを持っているので、ルーターがどれを選んでも計算の50%を相手に任せることができ、やり取りするactivationはごくわずかで済む)。これはrouted expertがはるかに大きいPROの方が、通信のペナルティが相対的に小さくなる分、より現実的だ。ただ、これが本当にうまく機能するかどうかは、やってみなければわからない。

テンソル並列もあるじゃないか、と思っただろう?でもAppleのマシン2台やDGX Spark 2台間などの通信速度では、これはまず成り立たないと断言できる(NVLinkの速度を調べてみればわかる)。上で挙げた2つの方式の肝は、やり取りするデータがごく少量で済むという点にある。

さて、ここまで読んで「なんだ、LLMを並列に動かす方法としてみんなが知ってるクソみたいな話じゃないか」と思っただろう。実際その通りだ。でもこの記事は、まさにここにたどり着くために書いた。もし2台のMacやDGXを、全く違う方法で並列化できるとしたらどうだろう?オープンウェイトモデルは今まさに黄金期にあり、数は豊富で、その多くが非常に強力だ。128GBで動く2ビット量子化のクラスだけでも、興味深いモデルは多い。Minimax M2.7、Mimo V2.5、DeepSeek v4 Flashなど、他にもいくつかある。同時に最近、LLMのアンサンブル(https://arxiv.org/abs/2502.18036)が、あまり研究されていないが有望な可能性として注目されている。これは2つのモデルをまったく共有なし(shared-nothing)の形で別々のマシンで動かし、最後にlogitsを統合したり、より良い続きを選んだりする手法だ。やり方は何通りかあり、2つのモデルで語彙が異なっていても機能する。perplexityが低い方の続きを選ぶ(つまり、より確信を持っているモデルを選ぶ。暗黙のルーティングを持つ2エキスパートのMoEのようなものだ)こともできるし、logitsを統合してそこからサンプリングすることも可能だ(語彙の違いによる複雑さはあるが)。より最近の論文では、この2つの手法を混ぜるのが最良だと示唆されている。いずれにせよ、これらの手法は実際に効果があるようで、モデルは単独よりも良い結果を出すように見える。それぞれが次に何を言うべきかについて異なる視点を持ち寄ることで、知識が補強されるかのようだ。

最初の2つとは別に、試す価値のある最も理にかなった第三の道は、もしかしたらこれなのかもしれない。ここ数ヶ月のうちに、ぜひ時間を取ってもっと色々といじってみたいと思っている。

原文は Salvatore Sanfilippo により に公開されました。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。