チャッピーに聞いてみた「EOQって何？」
チャッピーに聞いてみた記事です。チャッピーが記事作成してます。記事の内容は大体問題ないと思いますが、各自でご確認ください。タイトル画像はイメージです。また相変わらず変な画像。
参照先の記事内でKimi K2を使用しているのにQwen3.5が出てくるのはFlash-MoEのREADMEの記載を説明しているからかな？分かり難い。結局EOQは関係ないのか？どうなんだろう？
https://x.com/ai_hakase_/status/2038832411086037090?s=20
「EOQ」ではなかった。でも本質はもっと面白い
MacのローカルLLMが急に速く見える理由は、巨大モデルを“丸ごと載せる”発想をやめたから
最近、「MacのローカルLLMで“EOQ”みたいな新技術が出て、速度が大幅改善した」という話を見かけた人もいると思います。
結論から言うと、今回話題になっていたものは EOQという技術ではなく、MoEモデルをSSDから必要な分だけ読み出して動かす“Flash-MoE”系の仕組み です。Anemllの投稿では、Kimi K2 1T parameters を M5 Max 128GB で 3.5 tokens/s で動かしたデモとして紹介されています。
ただ、ユーザー目線ではここが大事です。
名前がEOQかどうかは本質ではありません。実際に「今までローカルでは無理」と思われていた巨大モデルが、Mac上である程度現実的に動くなら、それ自体が大きな意味を持ちます。 そのうえで、何が起きているのかをきちんと理解しておくと、この手の話を見たときに誤解しにくくなります。
まず結論
今回の高速化は「魔法の新圧縮技術」ではない
今回の話をひと言でまとめると、こうです。
巨大モデル全体をメモリに載せてから推論するのではなく、今この瞬間に必要な重みだけをSSDから順次読み込み、Metalで処理するようにした。
Flash-MoEのREADMEには、Qwen3.5-397B-A17BをApple Siliconで動かすための仕組みとして、“the entire model streams from SSD through a custom Metal compute pipeline” と明記されています。つまり、モデル全体をRAMに常駐させるのではなく、SSDを実質的な保管場所として使い、その都度読み出す設計です。
この発想自体は、Appleの研究 “LLM in a Flash” ともつながっています。Appleは2023年から、DRAMに載りきらないLLMの重みをフラッシュメモリに置き、必要な分だけDRAMへ持ってくる ことで推論する方向性を示していました。さらに最適化の要点として、フラッシュから転送するデータ量を減らすこと と より大きく連続した読み出しを行うこと を挙げています。
では、なぜそんなことが可能なのか
カギは「MoEモデルは全部を毎回使わない」こと
ここで重要なのが、話題のモデルが DenseモデルではなくMoEモデル だという点です。
Kimi K2は論文上、総パラメータ数1兆、ただし各トークンで活性化されるのは320億パラメータ のMoEモデルです。つまり、見た目の総サイズは非常に大きいのですが、1トークン生成のたびに1兆全部を計算しているわけではありません。
MoEはざっくり言えば、「専門家がたくさんいるが、そのたびに全員を呼ぶのではなく、必要な専門家だけ呼び出す」構造です。
普通の巨大Denseモデルだと、巨大な重み全体が毎回ほぼ関与します。けれどMoEなら、そのトークンに必要なexpertだけ読めばいい。この“疎な活性化”があるからこそ、SSDストリーミングという発想が成立します。
イメージで言うとこうなる
従来のローカル推論は、巨大な辞書を机の上に全部広げてから作業するようなものです。
当然、机が小さいと無理です。
今回の方式は違います。
辞書は本棚、つまりSSDに置いたままにしておき、今引く必要があるページだけ持ってくる。それをすごく高速に、しかも「次にどのページを引くか」を見越しながら繰り返しているイメージです。
だから「1TB級モデルがMacで動く」という見出しだけを見ると驚きますが、実態は
1TB全部をメモリに入れたわけではない
必要な専門家だけ、その都度ストレージから読んでいる
ということです。
どこが速くなったのか
実は計算よりI/Oが支配的
ここがかなり面白いところです。
Flash-MoEのベンチマークでは、M5 Max 128GB上の4-bit構成において、1トークンあたりの時間の47%が“Expert I/O (SSD)” で、Expert compute自体は1% とされています。言い換えると、ボトルネックは「計算」より「読み込み」です。
同じ表では、1トークンあたり 約1.7GB read、そのうち 1.62GBがexperts、89MBがdense部分 と書かれています。
つまり、この方式で重要なのは、GPUをひたすら強くすることよりも、
読み出す量を減らす
読み出し方を効率化する
必要なexpertだけに絞る
読み出した後のMetal処理を無駄なく回す
この4つです。
では、具体的に何を工夫しているのか
1. expertをSSDに置き、必要時だけ読む
これが中核です。Flash-MoEは、モデル全体をSSDからストリーミングする と明記しています。特にMoEのexpert部分が巨大なので、ここを常駐させず必要時だけ読むことで、RAM不足を回避しています。
2. 量子化でI/O量をさらに削る
Anemll版Flash-MoEでは、Q3 GGUF experts が推奨構成になっており、4-bit MLX expertsより 36%速い decode で、PPLは 3.81 vs 3.64 と、品質低下を比較的小さく抑えています。2-bit構成はさらに速いものの、PPL悪化が大きいとされています。つまり、ただ軽くするのではなく、品質と読み出し量の折り合いが良い点を探しているわけです。
3. Metal向けにデコード経路を手で詰めている
READMEには、Pure C/Metal inference engine、hand-tuned Metal shaders とあります。つまり一般的なフレームワークに丸投げしているのではなく、Apple Silicon向けにかなり低レベルで最適化しています。
4. SSD側の読み出し効率も改善している
Anemllフォーク版では、page-aligned pread fanout を使った cache-io-split により、SSDキャッシュのスループット改善を図っています。実測でも、Q3 GGUF + cache-io-split 4 が推奨構成として示されています。つまり「SSDから読む」と言っても、単純に読んでいるのではなく、読み方そのものを最適化しています。
「EOQ」と何が違うのか
今回の件で一番誤解しやすいのがここです。
“EOQ”という言葉を見て、多くの人は「新しい量子化方式」や「圧縮アルゴリズム」を想像すると思います。ですが、今回の本体はそこではありません。
今回の本質は、
巨大モデルをより小さくしたから速くなった
というより、
巨大モデルを丸ごと抱え込まなくても動くように、読み込み前提の設計にした
という点にあります。
もちろん量子化も使っています。ですが、それは主役ではなく補助輪に近いです。
主役はあくまで、
MoEの疎な活性化
SSDストリーミング
読み出し最適化
Apple Silicon向けMetal実装
この組み合わせです。
ユーザー目線では、なぜこれが重要なのか
ユーザーとして一番大きいのは、
「ローカルで無理」と思っていたサイズ帯が、工夫次第で視野に入ってきた
ということです。
たとえばAnemllの投稿では、Kimi K2 1TをM5 Max 128GBで3.5 tokens/sとしています。速さだけ見るとクラウドGPUのような世界ではありませんが、“1兆パラメータ級のMoEをローカルMacで動かす” という意味ではインパクトが大きいです。
さらにFlash-MoE側では、Qwen3.5-397B-A17Bについて、M3 Max 48GBの元実装 4.36 tok/s に対し、AnemllフォークのM5 Max 128GBでは最大 14.5 tok/s、推奨のQ3構成でも 12.9 tok/s とされています。これは「何でも一瞬で動く」という話ではないものの、ローカル巨大MoEの実用域をかなり押し広げている数字です。
ただし、何でも速くなるわけではない
ここは冷静に見ておく必要があります。
この方式が特に効くのは、MoEで、しかもexpertの疎な呼び出しを活かせるモデル です。Denseモデルを同じノリでSSDストリーミングしても、毎回必要になる重みが大きすぎて、かなり厳しくなります。
また、SSDオフロードは万能でもありません。2025年の研究では、SSD offloadingはエネルギー効率の面で不利で、現行SSDではHBMやDRAMよりトークン生成あたりの消費エネルギーが大きくなりやすいと指摘されています。つまり、容量と可搬性には強いが、効率のすべてで勝つわけではない、ということです。
要するにこれは、
“クラウドGPUを完全に置き換える技術” ではなく、
“ローカルで扱えるサイズの上限を押し上げる技術”
と見るのが適切です。
今回の話をいちばん分かりやすく言い直すと
「大きいモデルを小さくして速くした」のではなく、
「大きいモデルを全部持たなくていい設計に変えた」
のが本質です。
だから今回の技術を見て「EOQなのか、別名なのか」は、正直そこまで大事ではありません。
大事なのは、
ローカルLLMの世界で、“RAMに全部載るモデルしか使えない”という前提が崩れ始めていること
です。
そのうえで中身を厳密に言うなら、今回話題だったのは
MoE × SSD streaming × quantization × Metal最適化
です。
ここを正しく押さえておけば、この先また似た話題が出てきても「ああ、巨大モデル全体を抱えるのではなく、疎な部分だけ流し込んでいるのだな」と理解しやすくなります。
まとめ
今回話題になっていたものは、少なくとも確認できる範囲では EOQという新名称の技術ではありません。
実態は、MoEモデルのexpertをSSDから必要な分だけ読み出し、Apple Silicon向けに最適化した推論を行うFlash-MoE系の仕組みです。
ユーザーにとって重要なのは、
「名前」より「結果」 です。
巨大モデルをローカルで快適寄りに動かせるなら、それは十分に価値があります。
ただ、その価値の正体は「魔法の高速化」ではありません。
必要なものだけ読む
読む量を減らす
読み方を工夫する
Apple Silicon向けに実装を詰める
その積み重ねです。
ローカルLLMの進化は、単純なFLOPS勝負から、
メモリ階層とI/Oをどう料理するか
の勝負に入ってきています。
今回の話は、その流れを象徴するかなり面白い事例だと思います。
参照元としては、Anemllの該当投稿、Flash-MoEのGitHub、Appleの「LLM in a Flash」を見ておくと全体像をつかみやすいです。
SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。