【悲報】800億のAIが机の上で動くカラクリ、「寝てる502人」のせいで計算通りに速くなかった
「総数800億パラメータ、活性30億」。最近のローカルAIのスペック表には、こういう不思議な書かれ方をしたモデルが並ぶ。例えば Qwen3-Next-80B-A3B。800億の数字の粒を全部抱えたまま、1回の返事で実際に動かすのは30億分だけだ。中には専門家が512人もいて、1トークンにつき働くのはわずか10人。この「MoE（混合エキスパート）」という仕組みのおかげで、これまで個人の機械では手も足も出なかった規模のAIが、机の上で動くようになった。だが「計算が50分の1ならその分だけ速い」とはならない。帯域から計算すると毎秒20〜30トークン以上は出るはずの環境で、実測が7.74トークンしか出なかったという報告がある。その食い違いがどこで生まれるのか、最後まで追ってみよう。
「大きく持って小さく使う」という形
MoE とは、AI の中に専門家を大勢住まわせ、必要なやつだけ起こして使う仕組みだ。Qwen3-Next-80B-A3B なら、専門家が512人いて動くのは10人。残る502人はメモリの上で「出番を待って寝ている」。Mixtral 8x7B も同様で、自社発表では総数46.7B、1トークンで動くのは12.9Bとされている。OpenAI が重みを公開した gpt-oss-120b も、総数約1168億に対し活性は約51億の MoE だ。いずれも「大きく持って、小さく使う」という同じ基本形をしている。
どの専門家に回すかを決めるのが「ルーター（ゲートネットワーク）」と呼ばれる小さなネットワークで、本体と一緒に学習する。「誰に振るのが正解か」を自分で覚えていく。ただしここが弱点でもあり、学習が偏って一部の専門家ばかり呼ばれる「科学習（かがくしゅう）」という現象が起きやすい。均等に育てる工夫が必要で、作るのが楽な技術というわけではない。
速い理由は「計算」ではなく「運搬」
なぜ一部しか使わないと速いのか。直感的には「計算が減るから」だが、正解は半分だ。実は AI が返事を書く時、最も時間を食うのは計算そのものではなく、数字の粒をメモリから読んでくる「運搬」の時間なのである。今の機械は計算が早すぎて、材料が追いつかない。腕は立っているのに材料が来ない配達の職人状態だ。運搬の速さは「帯域（バンド幅）」、つまり1秒にどれだけ運べるかという道路の車線数で決まる。MoE は毎回30億分しか運ばないから、理屈の上では帯域が広ければ早くなるはずなのだ。
実際に計算した人の環境は、普通のノートパソコン向け CPU にメモリを96GB 積んだ個人でも買える範囲のものだった。帯域からの見積もりでは毎秒20〜30トークン以上は出るはずだった。しかし実測は7.74トークン。報告者自身が「帯域の計算より3〜4倍遅い」と書いている。これは llama.cpp の issue に上がった個人の1件の報告であり、公式ベンチマークではない。すべての環境で同じことが起きる保証はないが、原因の説明自体は筋が通っている。
169GBを48.5GBに、それでもまだ重い
800億の粒を16ビットのまま持つと約169GB になる。そこで「量子化」という、数字を荒く書き直す圧縮を施す。4ビット（Q4_K_M）まで落とすと配布ファイルは48.5GB だ。それでも普通のグラボ（24GB）には半分も入らないから、メインメモリ（64GB や 96GB）に置くことになる。gpt-oss-120b のように、最初から専門家部分を4ビット（MXFP4）で作ってあるものは、OpenAI が「80GB のグラボ1枚に乗る」としている。
ここで誤解しやすいのが「4ビットなら4倍速い」という期待だ。量子化と MoE は別のところに効く。量子化は粒1個あたりを軽くし、MoE は使う粒の数を減らす。掛け算の順番が違うのだ。軽くなるのは「読む量」だけで、「置き場所」は減らない。全員分の場所（寝てる502人分も）を確保しなければならないから、48.5GB から先は落ちない。つまり4倍のうち手に入るのは量子化分の「場所」だけで、MoE 分は場所には効かない。速さの方も、理屈の上では量子化分と MoE 分でとても早くなるはずなのに、実測は7.74なのである。
本当の原因「毎回、違う専門家が起きる」
遅い理由は、前述のルーターが「毎回違う専門家を選び直す」ことにある。512人のうち10人が動くが、次のトークンでは別の住人になる。どの住人が来るかは、計算してみないと決まらない。つまり事前に「倉庫のどこを開けるか」が分からない。特に、グラボの中の早いメモリとメインメモリの遅い方を両方使っていると、必要な専門家がメインメモリ側にいた時にその都度運んできて、使い終わったら捨て、次はまた運び直す。
llama.cpp の改善提案には具体的な回数が書かれている。36層で1層に4人選ぶモデルの場合、1トークン書くだけでメモリからグラボへのコピーが144回発生する。1文字分で144回だ。100文字書いたら1万4400回。この運搬は、「活性30億分だけ読む」前提の帯域計算には入っていなかった。実際はもっと多く読んでいるのであり、先の報告者の見立てと一致する。寝てるはずの502人が、起こされたりまた寝かされたりして邪魔をしているようなものだ。
直せる見込みはある
この問題は直せる。よく呼ばれる専門家をグラボに置きっぱなしにすればいい。考え方は簡単だが実装は難しい。どの専門家がよく呼ばれるかは、動かしてみないと分からないからだ。この仕組み（エキスパートキャッシュ）はまだ提案段階である。既に伸びた例もあり、llama.cpp から枝分かれした ik_llama.cpp は、ハードは同じまま MoE の計算をまとめて処理することで約1.9倍速いと報告されている。7.74が遅いのは機械のせいではなく、ソフトがまだ新しすぎるのだ。
MoEはそもそも個人の機械で得なのか
「全部乗せるんだから、最初から小さいモデルでいいのでは」という疑問がある。これについての研究（arXiv 2606.21428）は、「消費者向け・エッジの機材では、密なモデルに一貫して勝つわけではない」としている。計算量は減るのに、それが実際の時間短縮に素直に変わらない場合があるのだ。データセンターでは事情が違う。100人分をまとめて処理すれば、専門家を1回起こして100人分働かせられる。1回運んで100回使えるから、運搬の元が取れる。個人だと1回運んで1回しか使わない。この差が決定的だ。MoE はもともと大きい設備で安く動かすために生まれた技術であり、それが個人に降りてきた時、前提の違いがちぐはぐを生んでいる。
とはいえ悪い話ばかりではない。本当の値打ちは速さではない。「800億のモデルが個人の機械で動くようになった」こと自体が大きい。普通の800億なら1回で800億分すべてを読むことになり、48.5GB を毎回読むから1秒に1文字も出ないだろう。7.74でもそちらよりはるかにマシなのだ。30億のモデルと比べると遅いが、800億のモデルと比べればありえない速さで、賢さは800億分に近い。賢さは大きい方で、速さは小さい方による。この中間にいるのが MoE である。
速いメモリを少し、か遅いメモリを大量か
置き場所の問題に戻ると、答えはひとつに決まらない。「速いメモリを少し」か「遅いメモリを大量に」か。MoE は場所を食う分、大量派に傾くが、遅いメモリに置けば運搬でまた詰まる。さらに「読む時」と「書く時」で詰まる場所が違う。貼り付けた文章を読む段階はまとめて処理できるから計算力で決まり、返事を1文字ずつ書く段階は重みを運ぶ回数で決まる。長文を貼るか、短いやり取りを早くしたいかで、得意な機械が変わる。今できる工夫としては、グラボに「小さくて出番が多いもの」を優先して置き、大きくて出番の少ない専門家はメインメモリ側に出すことだ。どれくらい速くなるかの信頼できる数値は見つからないため、自分の環境で測るのが一番確実である。
ネットの反応
1トークンで144回もコピーってマジ？それだけで帯域の計算が崩れるわけだ。寝てる502人が邪魔って表現わかりすぎる。
7.74tok/sがソフトのせいってのが救いだな。ik_llamaで1.9倍出るなら、エコシステムが成熟すればまともになる。
「4ビットなら4倍速い」は罠だった。量子化で場所は減るけど、MoEは全員分置くからそこは減らない。掛け算の順番の話ってことね。
MoEはデータセンター向けの技術が個人に降りてきただけって見立て、めちゃくちゃ納得。1回運んで100回使えるのと1回使いの差がデカすぎ。
結局メモリ積めって話か。グラボ派と大容量派、どっちも一長一短で答え出ないのがリアルで面白い。
AIの所感
この仕組みの何が巧妙か。「大きな知能を、小さなコストで動かす」という魔法の裏で、計算の削減と置き場所の維持という二つの異なるコストが別々に効いている点だ。私たちはつい「パラメータが減るなら速い」と一足飛びに考えてしまうが、実際には「運搬」という見えない配達の負担がボトルネックになる。興味深いのは、この遅さが機械の限界ではなく、ソフトウェアの未成熟によるものだという点だ。つまり今の数字は通過点にすぎない。ローカルAI が「机の上の800億」を当たり前にするまで、あと少しの工夫の積み重ねが残っている。自分の環境で実測することが、この混沌を一番確実に理解する方法なのだ。