スマホのRAMの何倍も大きなAIモデルを、そのまま動かしてしまう——前回取り上げたストリーミング層「BigMoeOnEdge」に、その後を追う材料がそろいました。今回は「284Bモデルが動いた」という結果の中身に踏み込みます。どういう仕組みで動くのか、どこに品質のトレードオフがあるのか、周囲の研究動向まで整理します。
BigMoeOnEdgeは、GitHubユーザーHelldez氏が公開するApache-2.0のC++プロジェクトです[3]。MoE(Mixture-of-Experts、トークンごとに少数の専門家ネットワークだけを計算に使うモデル構造)の重みを、flashストレージから必要な都度読み出す方式です。毎トークンが必ず使う部分はメモリに置き、残りの専門家の重みはストレージからストリーミングします。READMEによれば、出力はメモリに全部を載せた場合と同一とされています[3]。
特徴的なのが、セッティングを自動化する「プランナー」です。メモリ量、ストレージ速度、そして搭載されたすべてのCPU・GPU・NPU(AI処理向けの専用チップ)を計測します。そのうえで、何をメモリに置き、何をストリーミングするかの計画を端末ごとに組み立てます。プロンプト読みと生成をどのチップが担うかも決めます。各選択の理由まで表示するとされ、フラグ指定やチューニングは不要とされています[3]。
数値面を整理しましょう。284Bパラメータのモデルが、12GBスマホのCPUだけで0.94トークン/秒で生成したと報告されています[3]。この284Bは、2026年8月17日のMedium記事が同じ規模と説明するDeepSeek V4 Flashと一致するようです[3]。リポジトリに集まったスターは約640、コミット数は451でした[3]。一方で、Hacker Newsへの投稿は1ポイント・コメント0件のままです[1]。オープンソースのカルチャーらしい温度差ですが、実機で試した報告がまだ表に出ていないのかもしれません。ツール紹介サイトにも取り上げられており、存在は広まりつつあります[5]。
設計で意欲的なのは、llama.cppをフォークしない選択です。設計ドキュメントで「フォークしない理由」を説明し、llama.cppの公開APIとの契約を文書化しています。さらに、固定したサブモジュールの更新手順まで用意しています[3]。これは理にかなった判断と思われます。llama.cpp本体は現在も活発だからです。Hugging Faceキャッシュへの移行や、マルチモーダル対応のllama-server、ブラウザで動くWebGPU対応など、更新が相次いでいます[2]。NVIDIAとの協業では、gpt-ossモデルが新しい量子化形式MXFP4に対応しました。量子化とは、重みを圧縮してメモリを節約する仕組みです[2]。上乗せの層にとどまることで、こうした本体の改善を追いかけられるはずです。
ただし、落とし穴もあります。flashの節約と引き換えに品質を差し出す調整項目が用意されている点です。READMEはあるオプションを「flashの節約が見込める場所にだけ品質を割く」と説明しており、ここは劣化を伴う設定になります[3]。その一方で、劣化系の設定を切っていれば、先読み(プリフェッチ)の設計は出力を変えないと明言されています[3]。デフォルトで「同一出力」を守り、品質は利用者が明示的に手放す設計です。なお、0.94トークン/秒は一文字ずつ追う対話には待ちを感じる速度でしょう。
この問題意識は研究側でも共有されています。コンシューマーGPU向けのMoE推論を扱うMoBiLE[6][7]も、同じ課題への別ソリューションです。スペキュレーティブ(推測)手法と組み合わせて大規模MoEの推論の効率化を図るBigMoMo[8]、モバイル上のMoEをスケールさせるNeurIPS 2026のポスターMobileMoEもあります。メモリに載らない巨大MoEをどう動かすかは、GPUとモバイルの両面で攻められているようです。大規模MoEの推論性能を最適化するガイドも公開されています[4]。ただし、これらの論文やガイドについて、素材に具体的な数値は見つかりませんでした。
ストレージの容量は、RAMよりはるかに大きいものです。BigMoeOnEdgeは「モデルのサイズをRAMではなくストレージで決める」という発想を、フォークしない層としてllama.cppに重ねて実現しようとしています[3]。自動プランニングと任意の品質トレードオフを組み合わせたこの設計が、llama.cpp本体の進化[2]や研究側の動き[6][8]にどう追いつくかが、次の見どころです。
RECENT COMMENTS