671Bの巨大モデルを、スマホやノートPCで動かそうという動きが出てきました。Hacker Newsに「BigMoeOnEdge」というプロジェクトが投稿されたのです。llama.cppの上に被せるレイヤーとして、スマホとラップトップで大型MoEのストリーミングを可能にする、という触れ込みです[1]。投稿は1ポイント・コメント0件で、始まったばかりです。それでも注目に値するのは、ローカルAI推論の常識を変える可能性を秘めているからです。
MoE(混合エキスパート)は、モデル内部に多数の「専門家」を用意し、トークンごとに必要な一部だけを動かす仕組みです。DeepSeek V3やGLM、Kimi K2、Qwen3 MoEなどが現在の代表格とされます[2]。たとえばDeepSeek V3は全体で671Bパラメータですが、1回の計算で動くのは37Bだけです[2]。Qwen3-Coderの30Bモデルなら、同時に動くのはわずか3Bです[3]。総サイズは「置き場所」の問題になり、動くサイズが速度を決める、という構図です。
では、動かない専門家はどこに置くのか。専門家はモデル全体の大半のサイズを占めますが、使わない分も含め、重みは全部どこかに保持しておく必要があります[2]。16GBや24GBのGPUでは、ここが最大の壁になります[3]。llama.cppの–n-cpu-moeは、下の層から順にN層分の専門家の重みを、VRAMではなくシステムRAMに置く指定です。Nを増やせばVRAMは節約できる代わりに、1トークンあたりのCPU処理が増えます。この調整だけで、30B級のMoEが16GBのGPUで動くようになります[3]。ただしこれは最適化ではなく、速度と容量を交換する「つまみ」です。適切な値は、モデルがメモリ不足で落ちないぎりぎりの値だと説明されています[3]。
CPUとGPUの分担のコツも、詳しいガイドとして共有されています[2]。モデルは、アテンション(前後の文脈への注目を計算する部分)や共有エキスパート、そしてトークンごとに選ばれて動く専門家で構成されます。毎トークン必ず使う部分をすべてGPUに置き、サイズの大半を占める専門家だけCPU側に回すのが最適です[2]。ガイドが示すセットアップ例は、GLM-4.7をQ4_K_Mという圧縮形式(重みを圧縮してメモリを節約する仕組み)で読み込み、コンテキスト長32768トークンというものです。ゲームPCでもマルチGPUワークステーションでも、RAMとVRAMの合計に収まる量子化を選ぶことが前提とされます[2]。KVキャッシュ(会話履歴を保持するメモリ領域)やOSの分の余白も、あらかじめ見込んでおくとされています[2]。冒頭には「必要なRAMはあらかじめダウンロードしておいてください」というジョークも添えられていました。
ここからが本題の「ストリーミング」です。専門家をあらかじめRAMに読み込むのではなく、ディスクから必要な分だけ、その都度読み込む方式です。「全部を事前に載せる」のではなく「必要なときに流し込む」——発想の転換です。llama.cppには機能要望が立てられており、コミュニティではすでに少なくとも5つの独立した実装が動いています[3]。カラクリは、次の層でどの専門家が必要かが、現在の層の計算が終わる前に分かることです。この隙間時間に、ディスクから次の専門家を先読みしておけます。読み込みと計算を重ねることで、あるプロジェクトの議論では約2倍のスループット向上が報告されています[3]。
一方で、冷静に見るべき点もあります。まず、RAMへのオフロードは速度を直接犠牲にする代償付きの手段で、その代償はトークン/秒に直接現れます[3]。また、今回のShow HN投稿はコメントがまだ付かず、実力は未検証です[1]。さらに意外なことに、この発想自体は目新しくありません。MoE推論の最適化技術を整理したサーベイがarXiv[4]とACM[5]から公開済みで、論文リンク集のawesome-moe-inference[5]や、コスト効率を重視するPyTorchライブラリMoE-Infinity[5]といった蓄積があります。研究のアイデアが、身近な道具の形でエッジ側に降りてきた段階のようです。
なお、素材には絶対値の実測TPSがなく、速度は「約2倍」という相対的な報告だけです。それでも要点は明快です。総パラメータではなく「動くパラメータ」で考えれば、VRAMの壁はRAMとディスクで乗り越えられます。スマホやノートPCで巨大モデルが動くかどうかは、メモリの総量よりも、読み込みをどう重ねるかで決まりそうです。研究とエッジ実装の距離がここまで縮んだこと自体が、今回の素材が示す一番の収穫でしょう。
RECENT COMMENTS