#分散処理

AppleのMachine Learning Researchが、Mac Studio上で巨大なLLMをどう走らせるかをかなり具体的に示しました。単体のMac Studioで扱えるモデルの範囲を確認したうえで、2台、4台とつないで推論を分散し、Thunderbolt経由のRDMAで通信の遅さをどこまで抑えられるかを測っています。単なる「MacでもAIが動きます」という話ではなく、どの場面で速くなり、どこで効きにくいのかまで踏み込んでいるのが面白いところです。研究としての位置づけも、AppleがMacをAI開発機として押し出したい意図も、かなりはっきり見えます。 元記事は、Appleのオープンソースの配列計算フレームワーク「MLX」を使い、Mac Studio上で大きなLLMをローカル実行する話から始まります。Apple siliconのユニファイドメモリを生かせば、研究者や開発者が自分の手元のハードウェアで新しい推論手法やfine-tuningを試せる、というのが前提です。 今回の主役は、ほぼ1兆パラメータ級とされる新しいモデル「Muse Spark Open」です。Appleはこれを

この記事を読んでまず思ったのは、「これ、最初は便利で、あとからじわじわ効いてくるやつだ」 ということだった。ひとつの process に全部乗せる設計は、動かし始めるだけなら本当に楽だ。関数呼び出しで済むし、ローカルで試すのも簡単だし、見た目もすっきりする。だからこそ、分割の話はつい後回しになる。でも、著者が描いているのは、その“楽さ”が少しずつ借金になる瞬間なんだと思う。 特に刺さったのは、問題が「コードの結合」ではなく「実行環境の結合」にまで広がっている ところだった。Python の中でモジュールを import してつないでいるだけ、と思っていても、実際には dependency の衝突やメモリの食い合い、再デプロイの巻き込みまで一緒に抱え込む。ここは地味だけど重い。しかも厄介なのは、開発初期にはその痛みが見えにくいことだと思う。デモでは動くし、最初の数機能なら十分だからだ。記事のトーンはかなり実務寄りで、その「あとで壊れる」感じに覚えがある人ほど、うなずく部分が多いはずだ。 もうひとつ印象に残ったのは、MCP を持ち上げすぎていないことだ。著者は、境界が大事な