第77回ブログ｜「VRAMが足りない」は、もう言い訳にならない — FreeToken登場で総点検する、MoEオフロード時代のローカルLLM実行環境（2026年8月版）

はじめに — ちょっと贅沢な悩み

「このモデル、メインメモリには載るんだけど、VRAMが足りないから遅くて使えないんだよねぇ」

ローカルLLMをやっている人なら、一度は口にしたことがあるはずです。DDR5のメインメモリは64GB〜128GBを比較的安価に積める一方、GPUのVRAM(ビデオメモリ)はミドルレンジで8〜16GB、ハイエンドのRTX 5090ですら32GB。モデルの重みを全部VRAMに載せようとすると、すぐ天井に当たります。

2026年8月、この状況に一石を投じるプロダクトが公開されました。UC Berkeley系チームによるMoE特化推論エンジン FreeToken です。「RTX 4060 Laptop(8GB)でQwen3.6-35B-A3Bが39 tok/s」「RTX PRO 6000 1枚で753BのGLM-5.2が動く」という数字が話題になっています。

ただ、FreeTokenは突然変異ではありません。llama.cppの--cpu-moe、清華大学のKTransformers、統合メモリ機(DGX Spark / Strix Halo / Mac)——「VRAMの壁を越える」技術はこの1〜2年で一気に実用段階に入っており、FreeTokenはその系譜の最新形です。本記事では、FreeTokenの仕組みを入口に、この領域の現在地を全体マップとして整理します。数値はできる限り出典を付け、開発元の公称値と第三者の実測を区別して書きます。

前提知識 — なぜ「VRAMの壁」が崩れつつあるのか

MoE(Mixture-of-Experts / 専門家混合)とは

近年のフロンティア級オープンウェイトモデル(DeepSeek、Qwen、GLM、GPT-OSSなど)のほぼすべてが採用しているアーキテクチャです。モデルの各層に「エキスパート」と呼ばれる小さなサブネットワークを多数持ち、トークン(テキストの処理単位)ごとに「ルーター」が必要なエキスパートを数個だけ選んで計算します。

結果として、総パラメータ数は巨大でも、1トークンあたり実際に動くパラメータ(アクティブパラメータ)はごく一部になります。モデル名の「35B-A3B」は「総35B、アクティブ約3B」という意味です。GPT-OSS-120Bなら総117Bに対しアクティブ約5B。

推論速度を決めるのは帯域幅

LLMの推論は、1トークン生成するたびに重みをメモリから読み出すため、計算速度よりもメモリ帯域幅(1秒間に読み書きできるデータ量)に律速されます。

decode(1トークンずつの生成)の速度上限は「帯域幅 ÷ 1トークンあたりに読むバイト数」でほぼ決まります。分母を決めるのが総パラメータではなくアクティブパラメータである——これがMoEの本質的なインパクトです。だから「巨大なエキスパートの束は遅いRAMに置き、毎トークン必ず動く部分(Attention層など)だけ速いVRAMに置く」という分業が成立します。

もう1つ、prefill(プロンプト全体の一括処理・計算律速)とdecode(生成・帯域律速)は別物です。同じ「tok/s」でも指す指標が違うので、ベンチを読むときは必ず区別してください。本記事でも pp(prefill)/ tg(decode)を分けて表記します。

ソフトウェア編 — 四天王の現在地

VRAMに載らないMoEを単一マシンで動かすソフトウェアは、2026年8月時点で実質4つに集約されつつあります。

1. llama.cpp --cpu-moe — 全員の出発点

ローカルLLM実行環境のデファクトであるllama.cpp(Ollama / LM Studioの中身でもある)には、MoE向けオフロードフラグが正式に入っています。

llama-server -m model.gguf -ngl 99 --cpu-moe        # 全エキスパートをRAMへ
llama-server -m model.gguf -ngl 99 --n-cpu-moe 21   # 先頭21層分だけRAMへ

-ngl 99で全層をGPU割当にした上で、ルーテッドエキスパートの重みだけをRAMに退避します。VRAMにはKVキャッシュ(コンテキストの中間計算結果)、Attention、ルーター、共有エキスパートといった「毎トークン必ず動く部分」だけが残ります。

効果は劇的です。国内の実測では、RTX 4070(12GB)+ 64GB RAM + WSL2で、OllamaデフォルトのGPU/CPU自動分割だと約10.6 tok/sだったQwen3.5-35B-A3Bが、llama.cpp + --cpu-moeで34.6 tok/s、フラグ追加チューニングで41.2 tok/sまで伸びています(Qiita: VRAM 12GBでQwen 35Bを動かす、続編スライド)。RTX 5090(32GB)+192GB RAMでGPT-OSS-120Bを約30 tok/sという報告もあります(llama.cpp Discussion #15396)。

限界も明確です。 配置はロード時に静的に決まるため、RAM側のエキスパートは毎トークン「転送して使い捨て」か「CPU計算」になります。MoEのルーティングは偏りが大きく、実際には少数のホットエキスパートが大半のトークンを処理するのに、その再利用ができない。本家にも「GPU側に永続的なLRUエキスパートキャッシュを持つべき」というFeature Request #20757が挙がっており、RFC Discussion #24528やSSD直ストリーミングのPRなどが並走中ですが、2026年8月時点で本流にはマージされていません(試作ではキャッシュヒット率97〜99%でも同期ポイントがボトルネックになり逆に遅くなる、という興味深い知見も出ています)。

2. ik_llama.cpp — 大規模MoE特化フォーク

ikawrakow氏によるllama.cppフォークで、独自量子化(_R4/_R8行インターリーブ等)とMoE特化最適化が売りです。DeepSeek系のMLA(Multi-head Latent Attention)を「absorbed」モードで実行する-mla 3、fused MoEの-fmoeなど、本家にないフラグを持ちます。

同一ハードでの直接対決の実測(2×RTX PRO 6000 + EPYC + 768GB DDR5、Kimi-K2.6 1T MoE)では、ik側がtg 18.6 tok/s vs 本家15.4 tok/s(+21%)、prefillに至っては567 vs 188 tok/sで約3倍という報告があります(loFT LLC。単発の自己申告値である点は留意)。一方で、旧世代AVX2 CPU(Ryzen 7 5800X)ではikが本家より大幅に遅くなる逆転事例(Issue #1699)もあり、「最新CPU+高帯域RAMで巨大MoEならik、コンシューマ構成なら本家と要比較」が現時点の相場観です。ik固有量子化のGGUFは本家で動かない点にも注意。

3. KTransformers — CPUを本気の計算資源にする清華発エンジン

清華大学MADSys LabのKTransformersは、OSシステム系トップ会議SOSP'25に採択された本格派です。思想が独特で、「エキスパートをGPUに転送する」のではなく、Intel AMX(Xeon内蔵の行列演算アクセラレータ)を使ってCPU側で直接計算する方向に振っています。671BのDeepSeek-R1を24GB GPU 1枚+大容量RAMで動かした実績で知られます。

2025年10月にはSGLangへの統合が発表され、「hot expertはGPU、cold expertはCPU」というヘテロ推論が本番サービング基盤で使えるようになりました。2026年に入ってAVX2のみのCPU対応も追加され、AMX非搭載機にも門戸が開きつつあります(ただし公式ベンチはXeon/EPYC中心で、Ryzen等での実測はまだ少数)。Kimi-K2、MiniMax-M2.1、Ascend NPUへの対応、LLaMA-Factory連携でのMoEファインチューニングまで、開発の活発さは頭一つ抜けています。

4. FreeToken — 2026年8月の新星

そして本命のFreeToken(論文 arXiv:2608.16157、Apache 2.0)。UC Berkeley系チームによる「エッジネイティブMoEサービングエンジン」で、設計思想は「パーソナルマシンを小さなGPUとして扱うのではなく、GPU・CPU・RAM・PCIeをまとめて1つの弾力的な推論基盤として扱う」というものです。

技術的なポイントは4つ。

1. 動的LRUエキスパートキャッシュ: 全エキスパートはRAMに常駐させ、VRAMには「最近実際に使われたエキスパート」だけをLRU(最も長く使われていないものから追い出す方式)でキャッシュ。llama.cppの静的配置と違い、ルーターの選択に追従してキャッシュ内容が変わる
2. 帯域適応型のCPU/GPU分担: 初回にft bench bwでそのマシンのPCIe帯域とメモリ帯域を実測し、キャッシュミス時に「PCIe転送してGPU計算」と「RAM上でCPU計算」の最適比率を閉形式で導出
3. プリフィルのダブルバッファリング: 層lの計算中に層l+1の重みを転送し、待ち時間を隠蔽
4. セマンティック・アウェア・キャッシング: Claude Codeのようなエージェントがコンテキストを編集して再投入するワークロードを想定し、ツール呼び出し等の境界にチェックポイントを置いて差分だけ再計算

公称値はRTX 4060 Laptop(8GB)でQwen3.6-35B-A3Bが39 tok/s、RTX 5090(32GB)でDeepSeek-V4-Flash 284Bが22〜25 tok/s、RTX PRO 6000でGLM-5.2 753Bが15 tok/s。ただし753Bの例はホストRAM 512GBが前提で、「VRAM要件がRAM要件に置き換わる」設計だと理解するのが正確です。

実用面では、OpenAI互換とAnthropic互換の両APIを提供し、ft launch claudeでClaude Code等のエージェントCLIをローカルサーバーに自動接続できる点が面白い。GGUF変換不要でsafetensorsを直接ロードでき、flashml.aiからWindows/Linux向けデスクトップアプリも配布されています。

注意点: CLIはLinux x86_64 + NVIDIA(ドライバr580+ / CUDA 13)限定、公開されたばかりで第三者検証はまだ薄く、公称値の多くは開発元クレームです。RTX 5080(16GB)でVRAM超過のQwen3.6-35B-A3Bが約100 tok/sというコミュニティ追試は出始めていますが、WSL2での動作可否を含め、評価が定まるのはこれからです。

ハードウェア編 — 統合メモリという別解

ソフトウェアで階層メモリを隠蔽するのではなく、CPUとGPUが同じメモリプールを共有するハードウェアで解決するのが統合メモリ(Unified Memory)機です。オフロードという概念自体が不要になります。2026年8月時点の三択はこうなっています。

実測値で比べると性格の違いがよく分かります。GPT-OSS-120B(MXFP4)のdecodeは、DGX Sparkで約39 tok/s→llama.cpp最適化ビルドで約59 tok/s(NVIDIA公式フォーラム、DevelopersIOの実測ではOllamaで pp 282 / tg 39)、Strix Haloで約55 tok/s。decodeはほぼ帯域なりに並ぶ一方、prefillはDGX Sparkが約1,700〜1,900 tok/s、Strix Haloが約340 tok/sと5倍差が付きます。長文RAGやエージェント用途(プロンプトが長い)ならDGX Spark、対話中心でコスト重視ならStrix Halo、という住み分けです。

重要なのは、統合メモリ機の主役用途がまさにMoEだという点です。帯域がdGPUのVRAMより遅いため密70Bは5 tok/s前後と苦しいのですが、アクティブが小さいMoEなら128GB機でGPT-OSS-120B級が30〜60 tok/s出る。「大型MoE + 128GB統合メモリ機」は今年のローカルLLM界隈の定番構成になりました(DevelopersIOの2026年夏総括でも同様の整理)。

実測値クイックリファレンス

代表的な構成の実測・公称値をまとめます。(公)=開発元公称、(三)=第三者実測。ビルドやバージョンで大きく変わるスナップショットとして見てください。

人間が読み流す速度は8〜10 tok/s程度と言われるので、いずれも対話・エージェント用途で実用域です。8GBのラップトップで35B級、ゲーミングPC 1台で100〜284B級、ワークステーション1台で753B——1年前の常識からすると隔世の感があります。

周辺と脱落組 — 押さえておくべき残りのプレイヤー

網羅性のため、四天王と統合メモリ機以外も簡潔に。

レイヤーストリーミング系(AirLLM): 層を1つずつVRAMに読み込んでは捨てる方式で、「Kimi K3(2.8T)を4GB弱のVRAMで」という極端な省VRAMを実現。開発は2026年も活発(v3.0でFP8対応)ですが、毎層読み直すためdecodeは実用速度に届きません。検証用と割り切るべきツールです。

分散(exo): 手持ちの複数デバイス(Mac、Linux機、iPhone等)を束ねてモデルを分割するexoは、1.0がApache-2.0でOSS化され継続中。DGX Spark + M3 Ultraのハイブリッドクラスタで「prefillはSpark、decodeはMac」という帯域特性を活かした構成をEXO Labsが実証しています。ただしLinuxは現状CPU実行のみという大きな制約あり。

vLLM / SGLang / TensorRT-LLM: 本番サービング系も追従中です。vLLMはKVキャッシュのCPUオフロードを実装済みで、MoEエキスパートオフロードはRFC段階。SGLangは前述の通りKTransformersカーネルを統合済み。TensorRT-LLMはDGX Spark公式スタックの中核です。

研究プロジェクト群: MoE-Infinity、HOBBIT、Fiddler、HybriMoE、PreScope、FineMoE(EuroSys'26)など、学術側の提案は膨大にあります。焦点は「キャッシュヒット率」→「CPU協調」→「予測プリフェッチ」→「エージェントワークロード」へと移っており、FreeTokenはこの流れの集大成的な位置にいます。一方、初代PowerInferやMoE-Infinityのように、論文実装止まり・商用ピボットで実運用の主流から外れたものも多い。研究→1〜2年でプロダクトに降りてくるサイクルの「観測点」として見るのがよいでしょう。

NVIDIA以外のGPU: AMD ROCm/Vulkanではllama.cppの--cpu-moeが動作し、Strix Haloが実用段階。Intel系はipex-llmがOllamaのエキスパートCPU退避(OLLAMA_SET_OT="exps=CPU")をサポート。KTransformersはAscend NPU対応も追加しています。この領域はNVIDIA一強ではなくなりつつあります。

選び方の指針(2026年8月版・私見)

1. まず本家llama.cpp + --cpu-moeから。12〜24GB VRAM + 64GB RAMがあれば、Qwen3.6-35B-A3BやGPT-OSS-120Bは今日から動きます。-otでエキスパートを段階的にGPUへ戻すチューニング、Flash Attention、KVキャッシュ量子化で更に伸びる
2. DeepSeek/Kimi級の数百B〜1Tを狙うなら ik_llama.cpp(最新CPU+大容量RAM前提)か KTransformers(Xeon/AMX環境なら本命)
3. 新しもの好き・エージェント統合重視なら FreeTokenを評価。ただし第三者検証が薄い段階なので、本番投入前に自環境で必ずベンチを
4. ハード新規購入なら 用途で三択: prefill重視(長文RAG/エージェント)→DGX Spark、コスパ→Strix Halo 128GB、帯域と静音→Mac
5. 本番サービング・複数同時ユーザーなら SGLang(+KTransformers)/ vLLM。単一ユーザーならllama.cpp系で十分

まとめ — 何が起きているのか

整理すると、この変化は3層構造です。

1. モデル側の構造変化が先にあった: フロンティア級オープンウェイトがほぼ例外なくMoE化し、「総パラメータ=必要VRAM」の等式が崩れた
2. ソフトウェアとハードウェアが同時に追従した: llama.cppの静的オフロード → KTransformers/FreeTokenの動的ハイブリッド、そして統合メモリ機の普及
3. 研究→プロダクトのサイクルが確立した: 動的エキスパートキャッシュはllama.cpp本家の「次の主戦場」になっており、この記事の内容も1年持たずに古びるはず

FreeTokenの論文にある「重みの公開は誰がダウンロードできるかを決めるが、誰が実行できるかは決めない」という問題意識が、この領域全体を貫くテーマです。その「実行できる」範囲は、データセンターから手元のゲーミングPCまで、確実に広がっています。

医療機関のオンプレ環境のように「データを外に出せない」現場を相手にしている身としては、既存ワークステーション1台で284B級が動く可能性は、導入提案の前提を根本から変える話です。まずは手元のRTX + WSL2環境で--cpu-moeとFreeTokenを追試し、実測は続報として書きます。

参考リンク

一次情報

• FreeToken(GitHub) / 論文 arXiv:2608.16157 / 配布サイト flashml.ai
• KTransformers(GitHub) / SGLang統合(LMSYSブログ)
• ik_llama.cpp(GitHub)
• llama.cpp 動的エキスパートキャッシュ Feature Request #20757 / RFC Discussion #24528

実測・解説(日本語)

• Qiita: VRAM 12GBでQwen 35Bを動かす(kenimo49) / 続編: cpu-moeで満足するな
• DevelopersIO: DGX Spark実測シリーズ / 2026年夏のローカルLLM事情
• Zenn: 私が今DGX Sparkを購入した理由
• note: FreeTokenの概要(npaka氏)

実測・解説(英語)

• llama.cpp MoEオフロード実践ガイド(HF Blog)
• --n-cpu-moeの実際(Aliteq)
• ik_llama.cppでKimi-K2.6 1Tを回す(loFT LLC)
• KTransformers解説(noze.it)
• 統合メモリ+MoEがローカルAIの未来という論説(XDA)

*本記事の数値は2026年8月24日時点のスナップショットです。llama.cpp系はビルド番号ごとにMoE性能が大きく変わり(DGX SparkのGPT-OSS-120Bは2ヶ月で39→59 tok/sに改善)、モデルも高速に世代交代しているため、追試の際は最新情報を確認してください。*