なぜ800億のAIが、個人の机の上で動くのか｜Qwen3-Nextと512人の専門家【ゆっくり解説】
リアクション
2026年08月22日
「総数800億パラメータ、活性30億」。最近のローカルAIには、こういう不思議な書かれ方をしたモデルが並んでいます。Qwen3-Next-80B-A3B がまさにそれで、800億の粒を全部かかえたまま、1回の返事で動くのは30億ぶんだけです。中には専門家が512人いて、1トークンにつき10人しか働きません。
MoE(混合エキスパート)というこの作りのおかげで、これまで個人の機械では手も足も出なかった規模のAIが、机の上で動くようになりました。
ところが「計算が50分の1なら、その分だけ速い」とはなりません。llama.cpp の不具合報告に、帯域から計算すると毎秒20〜30トークン以上は出るはずの環境で、実測が 7.74 トークンしか出なかったという報告が上がっています。報告者本人が「帯域の計算より3〜4倍遅い」と書いています。
この動画では、その食い違いがどこで生まれるのかを最後まで追います。鍵は「毎回、違う専門家が起きる」ことです。36層で4人ずつ選ぶモデルなら、1トークン書くだけでメモリからグラボへのコピーが144回発生します。この運搬は、活性30億ぶんだけ読む前提の計算には入っていません。
そのうえで「MoEはそもそも個人の機械で得なのか」も扱います。消費者向け・エッジの機材では密なモデルに一貫して勝つわけではない、とする研究があります。一方で、枝分かれした ik_llama.cpp が同じハードのまま約1.9倍速いという報告もあり、今の数字が最終形ではありません。
最後に、置き場所と速さのどちらを取るか——速いメモリを少しか、遅いメモリを大量か——という、答えがひとつに決まらない話まで行きます。
■ 目次
0:00 オープニング
1:36 実物の数字 — 800億と30億、Mixtral、gpt-oss
3:33 ルーターが選ぶ — 512人のうち10人しか働かない
5:15 なぜ一部しか使わないと速いのか — 帯域の話
6:26 計算では20〜30。実測は7.74だった
7:55 169ギガを4ビットで48.5ギガまで落とす
9:30 「4ビットなら4倍速い」が成り立たない理由
10:39 本題 — 毎回、違う専門家が起きる
11:48 1トークン書くのにコピーが144回
12:43 直せる見込みはある — ソフトで1.9倍
13:55 MoEはそもそも個人の機械で得なのか
15:28 本当の値打ちは速さではない
16:32 速いメモリを少しか、遅いメモリを大量か
17:10 読むときと書くときで、詰まる場所が違う
18:12 いま使える工夫 — グラボに何を置くか
19:17 まとめ
■ 動画で扱った数字
・Qwen3-Next-80B-A3B … 総パラメータ 800億 / 活性 約30億 / エキスパート512個のうち1トークンで10個
・16ビットのまま持つと約169GB / 4ビット(Q4_K_M)の配布ファイルは 48.5GB
・Mixtral 8x7B … 総数 46.7B / 1トークンあたり 12.9B(Mistral AI の公称)
・gpt-oss-120b … 総数 116.83B / 活性 5.13B / MoE の重みをネイティブ4ビット(MXFP4)で持ち、80GBのGPU1枚に載る(OpenAI の説明)
・実測 7.74 トークン毎秒(帯域の計算では毎秒20〜30以上の想定)
・36層・top-4 のモデルで、1トークンあたり RAM→GPU のコピーが144回
・ik_llama.cpp で約1.9倍(ハードは同じまま)
※ 7.74 トークン毎秒は llama.cpp の issue に上がった個人1件の報告であり、公式ベンチマークではありません。すべての環境で同じことが起きる保証はありません。動画内でもそのように断って扱っています。
※ 設定の変更でどれだけ速くなるかについては、前後を測った信頼できる数値が見つからなかったため、倍率は出していません。
■ 主な参照先
・Hugging Face「Mixture of Experts Explained」https://huggingface.co/blog/moe
・Mistral AI「Mixtral of experts」https://mistral.ai/news/mixtral-of-experts/
・apxml(Qwen3-Next-80B-A3B の仕様)https://apxml.com/models/qwen3-next-80b-a3b
・unsloth(Q4_K_M の実サイズ)https://huggingface.co/unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF
・llama.cpp Issue #19480(7.74 t/s の実測報告)https://github.com/ggml-org/llama.cpp/issues/19480
・llama.cpp Issue #20757(1トークン144回のコピー / エキスパートキャッシュの提案)https://github.com/ggml-org/llama.cpp/issues/20757
・apxml「Inference Challenges with Sparse Models」https://apxml.com/courses/mixture-of-experts/chapter-5-moe-inference-optimization-deployment/moe-inference-challenges
・arXiv 2606.21428「Does Mixture-of-Experts Actually Help Inference on Consumer and Edge Hardware?」https://arxiv.org/pdf/2606.21428
・OpenAI「Introducing gpt-oss」https://openai.com/index/introducing-gpt-oss/
・llama.cpp の MoE オフロード解説 https://huggingface.co/blog/Doctor-Shotgun/llamacpp-moe-offload-guide
この動画は独自に調査した内容をもとに構成しています。図解もすべて独自に作成しました。
自社発表(モデル提供元の公称)と、第三者による解説・個人の実測報告は、動画内で区別して扱っています。
誤りや見落としがありましたら、コメントで教えていただけると助かります。
あなたは「速いメモリを少し」派ですか、「遅いメモリを大量に」派ですか。
MoEのモデルを動かしてみた方は、出た速さもぜひコメントで教えてください。
#ゆっくり解説 #AI #ローカルAI #MoE #Qwen #llamacpp #オープンウェイト #LLM #生成AI #量子化 #自作PC #AIニュース
MoE(混合エキスパート)というこの作りのおかげで、これまで個人の機械では手も足も出なかった規模のAIが、机の上で動くようになりました。
ところが「計算が50分の1なら、その分だけ速い」とはなりません。llama.cpp の不具合報告に、帯域から計算すると毎秒20〜30トークン以上は出るはずの環境で、実測が 7.74 トークンしか出なかったという報告が上がっています。報告者本人が「帯域の計算より3〜4倍遅い」と書いています。
この動画では、その食い違いがどこで生まれるのかを最後まで追います。鍵は「毎回、違う専門家が起きる」ことです。36層で4人ずつ選ぶモデルなら、1トークン書くだけでメモリからグラボへのコピーが144回発生します。この運搬は、活性30億ぶんだけ読む前提の計算には入っていません。
そのうえで「MoEはそもそも個人の機械で得なのか」も扱います。消費者向け・エッジの機材では密なモデルに一貫して勝つわけではない、とする研究があります。一方で、枝分かれした ik_llama.cpp が同じハードのまま約1.9倍速いという報告もあり、今の数字が最終形ではありません。
最後に、置き場所と速さのどちらを取るか——速いメモリを少しか、遅いメモリを大量か——という、答えがひとつに決まらない話まで行きます。
■ 目次
0:00 オープニング
1:36 実物の数字 — 800億と30億、Mixtral、gpt-oss
3:33 ルーターが選ぶ — 512人のうち10人しか働かない
5:15 なぜ一部しか使わないと速いのか — 帯域の話
6:26 計算では20〜30。実測は7.74だった
7:55 169ギガを4ビットで48.5ギガまで落とす
9:30 「4ビットなら4倍速い」が成り立たない理由
10:39 本題 — 毎回、違う専門家が起きる
11:48 1トークン書くのにコピーが144回
12:43 直せる見込みはある — ソフトで1.9倍
13:55 MoEはそもそも個人の機械で得なのか
15:28 本当の値打ちは速さではない
16:32 速いメモリを少しか、遅いメモリを大量か
17:10 読むときと書くときで、詰まる場所が違う
18:12 いま使える工夫 — グラボに何を置くか
19:17 まとめ
■ 動画で扱った数字
・Qwen3-Next-80B-A3B … 総パラメータ 800億 / 活性 約30億 / エキスパート512個のうち1トークンで10個
・16ビットのまま持つと約169GB / 4ビット(Q4_K_M)の配布ファイルは 48.5GB
・Mixtral 8x7B … 総数 46.7B / 1トークンあたり 12.9B(Mistral AI の公称)
・gpt-oss-120b … 総数 116.83B / 活性 5.13B / MoE の重みをネイティブ4ビット(MXFP4)で持ち、80GBのGPU1枚に載る(OpenAI の説明)
・実測 7.74 トークン毎秒(帯域の計算では毎秒20〜30以上の想定)
・36層・top-4 のモデルで、1トークンあたり RAM→GPU のコピーが144回
・ik_llama.cpp で約1.9倍(ハードは同じまま)
※ 7.74 トークン毎秒は llama.cpp の issue に上がった個人1件の報告であり、公式ベンチマークではありません。すべての環境で同じことが起きる保証はありません。動画内でもそのように断って扱っています。
※ 設定の変更でどれだけ速くなるかについては、前後を測った信頼できる数値が見つからなかったため、倍率は出していません。
■ 主な参照先
・Hugging Face「Mixture of Experts Explained」https://huggingface.co/blog/moe
・Mistral AI「Mixtral of experts」https://mistral.ai/news/mixtral-of-experts/
・apxml(Qwen3-Next-80B-A3B の仕様)https://apxml.com/models/qwen3-next-80b-a3b
・unsloth(Q4_K_M の実サイズ)https://huggingface.co/unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF
・llama.cpp Issue #19480(7.74 t/s の実測報告)https://github.com/ggml-org/llama.cpp/issues/19480
・llama.cpp Issue #20757(1トークン144回のコピー / エキスパートキャッシュの提案)https://github.com/ggml-org/llama.cpp/issues/20757
・apxml「Inference Challenges with Sparse Models」https://apxml.com/courses/mixture-of-experts/chapter-5-moe-inference-optimization-deployment/moe-inference-challenges
・arXiv 2606.21428「Does Mixture-of-Experts Actually Help Inference on Consumer and Edge Hardware?」https://arxiv.org/pdf/2606.21428
・OpenAI「Introducing gpt-oss」https://openai.com/index/introducing-gpt-oss/
・llama.cpp の MoE オフロード解説 https://huggingface.co/blog/Doctor-Shotgun/llamacpp-moe-offload-guide
この動画は独自に調査した内容をもとに構成しています。図解もすべて独自に作成しました。
自社発表(モデル提供元の公称)と、第三者による解説・個人の実測報告は、動画内で区別して扱っています。
誤りや見落としがありましたら、コメントで教えていただけると助かります。
あなたは「速いメモリを少し」派ですか、「遅いメモリを大量に」派ですか。
MoEのモデルを動かしてみた方は、出た速さもぜひコメントで教えてください。
#ゆっくり解説 #AI #ローカルAI #MoE #Qwen #llamacpp #オープンウェイト #LLM #生成AI #量子化 #自作PC #AIニュース
