スマホやノートPCで巨大なMoEモデルをストリーミングで動かす。そんな試みが、AIコミュニティのハッカーニュースに「Show HN」として投稿されました[1]。llama.cppの上に重ねるレイヤー「BigMoeOnEdge」というプロジェクトです。現時点では1ポイント・コメント0件と、まだ反響は小さめです[1]。ただ、その周辺ではMoEの実装そのものが着実に進化しています。MoEは、モデル内の複数の「専門家」ネットワークのうち一部だけを動かす構造です。
まず押さえたいのは、llama.cppがMoEをどう処理しているかです。フォーク版の実装を解説するDeepWikiの資料によれば、MoE推論は「ルーティング→Top-K選択→加重合計」の3段階で動いています[3]。ルーティングは、トークンごとにどのエキスパートを使うかを決める処理です。続くTop-Kで上位のエキスパートだけを選び、出力を重み付きで足し合わせます。全部のパラメータを毎回動かさない疎な計算のおかげで、巨大モデルでも計算量を抑えられます。DeepSeek-V4やMixtralといった大規模MoEモデルへの対応も進んでいます[3]。
性能を左右するのが、NVIDIAのGPU向けに用意された専用カーネルです。エキスパート選びに必要な複数の計算(確率化・上位選択・重みの正規化)を1回の処理にまとめる「カーネル融合」で、メモリ帯域の負荷を減らしています[3]。またDeepSeekやQwen系のモデルは、ルーターが選ぶ疎なエキスパートに加え、全トークンに常時動く「共有エキスパート」を併用する構造です。この部分も実装側で対応済みでした[3]。
数値がはっきり出ているのはDeepSeek-V4関連です。エキスパートごとの実際のトークン数に合わせて計算タイルのサイズを調整する最適化(DSV4_MOE_TILE)により、約19%の性能向上が報告されています[3]。従来のような最悪ケース前提のサイジングではなく、実測に合わせて無駄を削る発想のようです。さらにMulti-Token Prediction(MTP、1回の処理で複数トークンを先読みして生成を速める仕組み)への対応も進んでいます[3]。加えて、会話の履歴を保持するKVキャッシュを圧縮してメモリを節約する機能も組み込まれています[3]。
周辺の動きも活発です。llama.cpp-moe-streaming-coreのREADMEでは、gpt-ossモデルへのMXFP4(重みを4ビット浮動小数点で圧縮する形式)ネイティブ対応がNVIDIAとの協力で追加されたことが紹介されています[2]。Hugging Faceのキャッシュ移行で、ダウンロード済みモデルを他ツールと共有しやすくなった点も見どころです[2]。ブラウザからGPUを直接使えるWebGPU対応も進んでおり、動かし方の幅が広がっています[2]。ノウハウ面では、CPU推論にGPUの補助を組み合わせるガイド[4]や、大規模MoEのチューニングをまとめたガイド[5][6]が公開されています。
しかし、MoEがエッジで本当に得なのかには疑問の声もあります。arXivには「MoEは消費者向け・エッジデバイスの推論に実際に役立つのか」と題した論文が投稿されています[6]。巨大MoEのローカル実行が盛り上がる中で、その前提を検証しようとする動きが出てきたこと自体が印象的です。なお、素材にはこの論文の具体的な結論や数値は見つかりませんでした。
一方で、実用例の数字は着実に伸びています。ディスクからエキスパートを流してRAM以上のモデルを動かす方式では、32GBメモリのノートPCで80BのMoEを37トークン/秒で動かしたという報告もあります[6]。ただ、冒頭のBigMoeOnEdgeがほとんど反響を得ていないことからも、個人プロジェクトの発信が埋もれやすい現状もうかがえます[1]。
MoEのローカル実行は、単に「モデルを載せる」段階から、ルーティングやカーネルの中身まで掘り下げて最適化する段階に入ったようです[3]。その一方で、エッジでの有効性を問い直す研究も現れました[6]。流行と検証が並走するこの分野、次はどちらの数字が先に動くか、注目していきたいところです。
RECENT COMMENTS