「RAMが足りないなら、先にRAMをダウンロードしておこう」——巨大MoEモデルをローカルで動かすためのガイドに、こんな冗談が書かれています[2]。この冗談には理由があります。MoEモデルの総サイズは、ノートPCやスマホのメモリを簡単に超えてしまうからです。前回の記事では、12GBのスマホで284Bモデルを動かすMoEストリーミング層を紹介しました。その後もこの流れは続いています。Hacker Newsには、スマホとノートPCの両方で巨大MoEをストリーミング実行するllama.cpp拡張「BigMoeOnEdge」が投稿されました[1]。今回は、その周辺で動き出した技術を追います。
巨大MoEがエッジで動くカギは、MoE(専門家混合)という構造の特性にあります。MoEモデルは、総パラメータと、1回の推論で実際に動くパラメータの2つの数字で語られます。ガイドによると、DeepSeek V3は総パラメータ671Bですが、1回の推論で実際に使うのは37Bだけです[2]。モデルの大部分を占める「ルーティングされるエキスパート」(入力に応じて選ばれる専門部署のような部分)は、毎回ごく一部しか起動しません。一方で、アテンション(文章の中のつながりを見る部分)や共有エキスパートなど「常に使う部分」は、毎回必ず全部動きます。
この非対称さが最適化の出発点になります。常に使う部分は最速のGPUに置き、たまにしか使わないエキスパートはCPU側に置く分担です[2]。ガイドはゲーミングPCからマルチGPUワークステーションまでを対象にしています。量子化(重みを圧縮してメモリを節約する仕組み)したGGUF形式のモデルは、RAMとVRAMの合計に収まる必要があります。さらに、会話の記憶を保持するk/vキャッシュやOSの分まで余裕を見込むとしています。
実際の分担は、GPUに置く層とCPUに置く層を分ける指定(例:-ot “exps=CPU”)で行います。設定ミスでメモリが足りなくなったとき、llama.cppの自動調整に任せると原因がつかめません。そこでガイドは、あえて自動調整を切ってメモリの限界を確認する方法も紹介しています[2]。
この発想をさらに進めた専用ツールも出てきました。llama.moe(実装名はzilong)は、llama.cppの上に動的なエキスパートオフロードを組み込んだ軽量推論フレームワークです[3]。オフロードとは、重みの一部を別の記憶域に置き、必要なときだけ呼び出すことです。使い方はllama-serverをzilongに置き換えるだけとシンプルで、CUDA(NVIDIA製GPU向けの実行環境)でのビルド手順も公開されています。llama.cpp本体のMoEオフロード機能とストリーミングの仕組みを解説する記事も現れました[4]。2026年版のllama.cpp最適化ガイドでも、速度を出すための設定が整理されています[7]。
実力を示す数値も出ています。Janasという取り組みでは、RAMより大きなMoEモデルをSSDからエキスパートをストリーミングする方式を採ります。32GBノートPCに80B MoEを載せて37トークン/秒を達成したとされる(2026年10月)[4]。前回取り上げたスマホの実証と並び、エッジ側の実力が段階的に伸びていることをうかがわせる数字です。
しかし、道のりは平坦ではないようです。BigMoeOnEdgeのHacker News投稿は、現時点で1ポイント・コメント0件にとどまっています[1]。注目はまだ限定的です。また、研究レベルではHOBBITという試みもあります。混合精度(精度の高い重みと低い重みを使い分ける仕組み)で、エキスパートのオフロードを高速化する研究です[4]。単純なCPU/GPU分担だけでは速度の壁に当たる場面があることをうかがわせます。SSDからのストリーミングはメモリを超えるモデルを動かせる一方、37トークン/秒が快適な水準かどうかは用途次第でしょう。
ガイド[2]、専用フレームワーク[3]、研究[4]と、エッジで巨大MoEを動かすための部品が揃い始めました。仕組みの理解、ツールの導入、速度の追い込みという三つの層が重なり始めたと言えそうです。スマホやノートPCで巨大AIモデルを動かす流れは、単発のデモから実用の段階へ一歩ずつ進んでいます。次に注目したいのは、これらの技術がどれだけ一般ユーザーの手に届く形になるかです。
RECENT COMMENTS