ローカルプラグアンドプレイAIに向けて
本記事では、ローカルAI推論のソフトウェア最適化について、MoE対稠密モデルのトレードオフ、様々な注意機構、投機的復号化に焦点を当てて解説します。ハードウェア構成の実践的な決定木を提供し、ソフトウェアの選択がパフォーマンスに劇的な影響を与えることを強調します。
2026年5月17日
先週、私はローカルAI実行のハードウェア側面について書きました。メモリ帯域幅が生の計算能力よりも重要な理由、構築する価値のあるマシン、市場の動向などです。見逃した方はそちらから始めてください。この記事はその上に直接構築されています。
AI独立を目指す過程で、ハードウェアが天井を設定しますが、実際にどれだけ近づけるかを決めるのはソフトウェアです。同一のGPU、同一のVRAM、同一の帯域幅を持つ2台のマシンで、一方がナイーブな推論を実行し、もう一方が最適化されたスタックを実行すると、1秒あたりのトークン数に3〜5倍の差が生じる可能性があります。これは、5 tok/sから20〜30 tok/s(実用に必要な速度)への違いを意味します。さらに、一部の技術やソフトウェア・モデル・ハードウェア最適化実装により、少なくとも96GBのRAMを搭載したMacBook上でDeepSeek-V4-Flashのような大規模モデルを実行できる可能性があります。同じモデル、同じハードウェアでも、ソフトウェア層の選択が異なります(この点では、ビデオエンコーディング・圧縮業界から学ぶことが多いと感じています。ハードウェアリソースの1ドルから最大限を引き出さなければなりません)。
先週、私は特定の価格帯で十分に高速にトークンを生成する推論ボックスを作成するという新たな目標を提示しました。これまでのところ、私のニーズを完全に満たすものは見つかっていません。この作業の成果として、ローカル推論に最適化された、プラグアンドプレイで法外に高価ではないハードウェア構成、または現在のハードウェアを検出して最適なモデルと構成を提案するツールが見つかることを期待しています。
この記事では、その探索を続け、推論スタックを改善するための最新技術に焦点を当てます。
MoE vs 稠密モデル
ソフトウェアのトリックに入る前に、それらの下にあるアーキテクチャ上の決定があります。それはソフトウェア層が対処しなければならないものを変えるからです。ローカルでまともなスループットで実行する可能性が高い興味深いモデルのほとんどは、混合専門家(MoE)アーキテクチャです。Qwen3.6-35B-A3B、Qwen3-235B-A22B-250、DeepSeek-V4。命名規則は構造を示しています:35B総パラメータ、ただしトークンあたり3Bのみアクティブ。モデルは専門家サブネットワークと、各トークンに対してどの専門家を起動するかを決定するルーターに分割されます。
これらのタイプのモデルの主な利点(そしてなぜハードウェアに適合させるための最大の変更点なのか)は、トークンあたり30Bのパラメータのうち3Bだけが作業を行う場合、3B規模の推論速度に近いものを得ながら、モデルは30B規模の知識を持つことです。llama.cppの-ngl 99 -ncmoe 99フラグ(注意と共有重みをGPUに保持し、コールドな専門家FFN層をシステムRAMにオフロード)のような適切なサービングトリックを使用すると、Qwen3.6-35B-A3Bは、64GB以上の高速システムRAMがあれば、わずか8GB VRAMのRTX 3070 Tiで33.5 tok/sを達成できます。35B知識モデルを実行する下限は、ほとんどの人が認識するよりもさらに下がりました。
主な欠点は一貫性です。そして、MoEを長時間使用したことがあるなら、おそらくこれから説明することを経験したことがあるでしょう。MoEモデルを病院と考えてください。各患者は適切な専門医に振り分けられます。しかし、どの専門医が起動するかはトークンに依存します。モデルは、活性化する専門家に応じて、ある分野では鋭く、別の分野では著しく弱く感じられることがあります。稠密モデルにはこの問題はありません。すべてのパラメータが毎回すべてのトークンを処理するからです。より遅く、より高価ですが、完全に一貫しています。この一貫性の欠如は、ツール呼び出しループ、パフォーマンス低下、壊滅的忘却として経験される可能性があります。
推論タスク、長いコンテキストの一貫性、モデルが50,000トークンのコンテキストにわたって鋭さを保つ必要があるものには、稠密モデルが一般的に優れています。これが、複数のアシスタントターンと正確なコンテキスト保持を必要とするエージェントタスクには常に稠密モデルを推奨する理由です。
サービングの問題もあります。バッチ内のあまりに多くのトークンが同時に同じ専門家にルーティングされると、その専門家のバッファがオーバーフローし、トークンが静かにドロップされます。モデルはこれが発生していることを警告しません。そして悪化する一方です。稠密推論にはそのような複雑さはありません。
では、稠密モデルとMoEモデルの間でどのように選択すればよいのでしょうか?以下は、私が現在使用している実践的な決定木です。
- 8GB VRAM GPU + 64GBシステムRAM?MoEと専門家オフロードが、能力のあるモデルを実行するための唯一の現実的な選択肢です。Qwen3.6-35B-A3B Q4またはGemma4-26B-A4Bとllama.cppオフロードがこのプロファイルに適合します。スループットはCPU帯域幅に制限され、GPUではありません。したがって、ここでは高速なDDR5システムがGPU世代よりも重要です。
- 16~24GB VRAM(RTX 3090、RTX 4090、RTX 4080)?本当の選択肢があります。稠密なQwen3.6-27B Q4_K_Mは、約16GBにオフロードなしで収まり、サービングの複雑さがなく、一貫した品質です。MoEのQwen3-35B-A3Bもこの階層に部分オフロードで収まります。ワークロードがエージェント型(長いコンテキスト、ツール呼び出し、マルチステップの一貫性など)の場合、稠密モデルの一貫性の利点は、わずかに低い生のスループット(前回の記事で説明したように苦痛になり得る)を上回ります。
- 128GB以上のユニファイドメモリ(Mac M3 Ultra、Strix Halo / Ryzen AI Max+)?ここではMoEが明確に優れています。Qwen3-235B-A22B(235B総パラメータ、トークンあたり22Bアクティブ)全体をユニファイドメモリに保持し、オフロードなしで完全なコンテキストで実行できます。この階層では、ローカルでフロンティアクラスの能力を得られます。トークンあたり22Bのアクティブパラメータは、ユニファイドメモリの高帯域幅プールで強力なスループットを提供します。鋭い読者は疑問に思うかもしれません。ではなぜあなた自身はStrix HaloでQwen3.6-27Bのような稠密モデルを実行しているのか?一貫性の問題に戻ります。私は長時間実行されるエージェントタスクを実行しようとしています。コンテキストが大きくなるとパフォーマンスは急速に低下します。
- マルチGPU / 192GB以上のVRAM?必要なものに対して十分なモデルを基本的に実行できます。MoEをフル精度で、量子化不要です。このレベルの並列性ではルーティングオーバーヘッドは無視できます。
短くまとめると:VRAMが限られていてシステムRAMが多い場合は、MoEと専門家オフロード。稠密モデルをきれいに収めるのに十分なVRAMがある場合は、長いコンテキストの一貫性が必要なものには稠密を優先。大規模なユニファイドメモリマシンがある場合は、トップ階層のMoE(Qwen3-235B-A22Bなど)がローカルで実行できる最も能力のある選択肢になります。
幸い、AlibabaはQwen3.6でこのスペクトルの両端を構築しており、今のところ私はそれらを使用してかなり満足しています。MoEオプションはQwen3.6-35B-A3B、稠密オプションはQwen3.6-27Bです。どちらも同じハイブリッド注意コアを実行しており、両者の選択はほぼ完全にハードウェアとワークロードの問題であり、モデルの品質の問題ではありません。
これらの数値はどのように得たのか?このセクションの調査中に、LocalMaxxing.comに出会いました。このサイトはまさに金鉱です。異なるハードウェアアーキテクチャ上の異なるモデルのベンチマークを、使用された推論エンジンとその構成に関する明確な情報とともに提供しています。これにより、今後数ヶ月の宿題ができ、この新たな探求にとって素晴らしいリソースとなります。
注意機構の動物園
MoE/稠密の問題はモデルアーキテクチャの1つの次元にすぎません。もう1つはモデルが内部で使用する注意機構です。すべての変種は同じ制約に対する異なる答えです。標準的な注意はN×N行列を生成し、Nはシーケンス長です。10,000トークンでは1億エントリになり、メモリコストは二次的に増加します。過去2年間の注意におけるすべての興味深い発展は、本質的に、品質をあまり犠牲にせずにその曲線から逃れるための異なる試みです。それぞれに独自のトレードオフがあり、異なる基盤アーキテクチャに適している場合があります。
Sebastian Raschkaのビジュアルガイドは、注意機構の状況をナビゲートするために私が推薦できる最良のリソースです。その進化を追う価値があります。各ステップが異なるトレードオフを明らかにするからです。
- 標準マルチヘッド注意は、誰もが(あるいは私だけかもしれませんが)トランスフォーマーの注意機構を考えるときに思い浮かべるもので、すべてのトークンが他のすべてのトークンに注意を払います。二次メモリ、二次計算。今日、ローカルハードウェア向けにこれを選択する人はいません。これは他のすべてが測定されるベースラインにすぎません。
- GQA(グループ化クエリ注意)は、実際にスケールで出荷された最初の修正です。各クエリヘッドが独自の独立したキー値投影を維持する代わりに、複数のクエリヘッドが単一のKVペアを共有します。約50%のKVキャッシュ節約、ほとんど品質損失なし。Llama 3、Qwen3、Gemma 3はすべて使用しています。トレードオフは最小限で、これがすぐにデフォルトになった理由です。
- MLA(マルチヘッド潜在注意)はDeepSeekによるもので、さらに深く進みます。保持するKVペアの数を減らすのではなく、各ペアに格納されるものを圧縮し、潜在表現を保存し、オンデマンドで完全なKV状態を再構築します。GQAよりもサービングが複雑ですが、大規模では品質対バイトの利点は本物です。DeepSeek V3とKimi K2が使用しています。再構築オーバーヘッドを吸収するメモリがあり、フロンティア級の出力品質を望む場合に適切な選択です。なぜかは聞かないでください。私は個人的にMLAを実装したモデルが大好きです。
- SWA(スライディングウィンドウ注意)はまったく異なる角度を取ります。キャッシュを圧縮するのではなく、各トークンがどれだけ遡って見るかを単純に制限します。Gemma 3は5:1のローカル対グローバル層の比率、1,024トークンのウィンドウ、そしてその上にGQAを使用しています。メモリは二次的ではなく線形に増加し、ほとんどの実用的なワークロード(コード補完、ドキュメントQ&A、チャットなど)では品質への影響は最小限です。トレードオフは、これらのローカル層でグローバルコンテキストを実際に放棄していることです。ほとんどのタスクでは問題ありませんが、非常に長距離の推論には影響します。
- Gated DeltaNetはQwen3.6-27Bで使用されており、さらに進みます:格納されたシーケンスに注意を払う代わりに、新しいトークンごとに継続的に更新される高速重みメモリを維持します。メモリフットプリントはシーケンス長に関係なく一定です。4kから65kコンテキストへの移行では、数GBではなく約800MBのVRAMしか消費せず、16GBのカードが壁にぶつかるのと、3倍のサイズのマシンと競争力を保つことの違いになります。トレードオフはアーキテクチャの複雑さと、完全な注意では簡単な非常に長距離の依存関係を、モデルが実行中のメモリ状態に圧縮することを学習する必要があることです。
- Mamba-2ハイブリッド(NvidiaのNemotron Nano)は論理的な極限で、注意のほとんどがシーケンス長に関係なく一定のメモリを持つリカレントステートマシンに置き換えられます。エッジおよび組み込みハードウェアに適切な選択であり、GQAでさえも多すぎる場合に適しています。適切なGPUが利用可能な場合の最初の選択肢ではありません。品質の上限は低いですが、メモリの下限はこの状況の中で最も低いです。
これらの違いはマシンに現れます。SWAでは長いコンテキストでKVキャッシュはほとんど動かず、サービングエンジンはMHAでは得られない余裕を持ちます。同じコンテキスト長でGQAに切り替えると、VRAMは顕著に増加します。DeltaNetハイブリッドを実行すると、メモリプロファイルはほぼフラットになります。固定メモリ予算に複数のエージェントを適合させる場合、モデルがどの注意変種を使用するかは、パラメータ数と同じくらい重要です。
さらに、この投稿からは除外することにしたもう1つの次元があり、それだけで別の投稿に値します。それはどの量子化メカニズムを使用するかと、利用可能なさまざまなフレーバーです(それ自体が獣です)。これについては、TurboQuantに関する私の投稿を参照してください。
投機的復号化
数週間前、GoogleはGemma 4に専用のMTPドラフター(小型コンパニオンモデル)が搭載され、品質に影響を与えずに推論速度を最大3倍向上できると発表しました。
投機的復号化が解決する問題は、トランスフォーマーの根本的な問題です。このニュースレターで何度か説明したように、LLMは自己回帰的にテキストを生成します。つまり、一度に1トークンずつ、各トークンはその前のすべてに依存します。大規模モデルは、すべての単一トークンに対して完全なフォワードパスを実行する必要があります。生成自体を並列化することはできません。したがって、どれほど高速でも...(AIコスト制御のため省略)