何が起きたか:MoE推論を効率化する「FreeToken」の登場と実測性能
コンシューマー向けハードウェアで大規模なオープンウェイトMoE(Mixture-of-Experts:複数の専門家ネットワークを切り替える構造)モデルの推論を効率化するエッジネイティブ推論エンジン「FreeToken」が発表されました[1]。本ソフトウェアはShuo Yang氏、Xiaoze Fan氏、Melissa Pan氏、Haocheng Xi氏、Zhe Wang氏、Shanlin Sun氏、Kurt Keutzer氏、Song Han氏、Matei Zaharia氏、Chenfeng Xu氏、Ion Stoica氏らによって発表され、関連論文が2026年8月17日にarXivへ投稿されました[2]。
FreeTokenは、GPU、CPU、ホストメモリ、接続帯域を一体の弾性基盤として扱います。20超のMoEモデルに対応し、コンシューマー機からワークステーションまで幅広くサポートします[3]。公開リポジトリではDeepSeek-V4、GLM-5.2/4.7、Qwen3.8-Flash-Next、Qwen3.6/3.5 MoE、Qwen3-MoE、gpt-oss、Gemma-4、MiniMax-M2.5、Muse-Glimmerなどの対応系統が挙げられています[4]。論文の評価では、284B総パラメータ・13B活性のMXFP4版DeepSeek-V4-Flash、35B級のQwen3.6-35B-A3B、753B総パラメータ・40B活性のNVFP4版GLM-5.2が中心的に検証されました[5]。
評価ハードウェアとして、RTX 3090(24GB)、RTX 4090(24GB)、RTX 5090(32GB)のサーバー、RTX 5090(32GB)のデスクトップ、RTX 4060 Laptop(8GB)、RTX PRO 6000(96GB)の計6構成が用いられました[6]。RTX 5090環境では、Qwen3.6-35B-A3Bで毎秒77〜83トークン、DeepSeek-V4-Flashで毎秒22〜25トークンを達成しました。これは各ワークロードにおける最速ベースラインと比較して、それぞれ1.8〜2.3倍および1.5〜1.9倍の向上です[7]。
| 評価ハードウェア | 対象モデル | 総パラメータ数 | 活性パラメータ数 | Decodeスループット (tokens/s) | 比較ベースラインに対する倍率 |
|---|---|---|---|---|---|
| RTX 4060 Laptop (8GB) | Qwen3.6-35B-A3B (NVFP4) | 35B | - | 39.3 tokens/s | 最速ベースライン比 1.8倍 |
| RTX 5090 (32GB) | Qwen3.6-35B-A3B | 35B | - | 77〜83 tokens/s | 最速ベースライン比 1.8〜2.3倍 |
| RTX 5090 (32GB) | DeepSeek-V4-Flash (MXFP4) | 284B | 13B | 22〜25 tokens/s | 最速ベースライン比 1.5〜1.9倍 |
| RTX PRO 6000 (96GB) | GLM-5.2 (NVFP4) | 753B | 40B | 14.9 tokens/s | llama.cpp比 2.0倍 (7.3 tokens/s) |
コーディング評価におけるクロスハードウェア測定では、最速ベースライン比でRTX 3090および4090が1.3倍、RTX 5090サーバーが1.9倍、RTX 5090デスクトップが2.1倍、RTX 4060 Laptopが1.8倍の速度向上を示しました。8GB VRAMのRTX 4060 Laptop環境でも毎秒39.3トークンに達しています[8]。また、単一のRTX PRO 6000(96GB)による測定では、753BパラメータのGLM-5.2を毎秒14.9トークンで処理し、llama.cppの毎秒7.3トークンに対して2.0倍の性能を記録しました[9]。
後輩8GB VRAMのノートPCで35Bモデルが毎秒39.3トークン出たというのは、手元のマシンでそのまま高速に動くという意味ですか?
先輩そこは条件を確認する必要があるよ。VRAMが8GBでも、モデルの重みを置くホストRAMが別途十分に確保されていることが前提になっているんだ。
後輩GPUのメモリだけでなく、マシン全体のメモリ構成が重要になるわけですね。
先輩その通りだね。単一のパーツを見るのではなく、PC全体の協調動作として結果を見る視点が大切だよ。
なぜ今か:巨大化するMoEモデルとローカル実行の背景
公開されているMoEモデルは、1トークンの生成で動員する活性パラメータ数を抑えつつ、総パラメータ数を大きく拡大する傾向を見せています。例えばDeepSeek-V3は総パラメータ数671Bに対して活性パラメータ数が37Bであり、Llama 4 Maverickは総パラメータ数400Bに対して活性パラメータ数が17Bと公表されています[10]。
MoEはトークンごとに一部のエキスパートのみを選択して計算します。DeepSeek-V4-Flashの例では、各MoE層の256個のエキスパートのうち活性化されるのは6個で、43層全体で総パラメータ284Bのうち1トークンに参加するのは13Bです[11]。計算負荷自体は疎になりますが、推論時には全エキスパートの重みを保持しなければなりません。そのため、コンシューマー機ではメモリ転送がボトルネックになりやすい構造があります[12]。
FreeTokenの論文では、オープンモデルと独自モデルの能力差の縮小に比べ、実際に大規模モデルを利用できるアクセシビリティの格差解消が遅れており、継続利用の費用も課題として残ると指摘されています[13]。一方、OpenAIのgpt-oss-20bが16GBメモリのエッジデバイス向けに提供されるなど、コンシューマー機への配備を意識したモデルも現れています[14]。
ローカル環境での推論には、データプライバシーの確保、オフライン動作、通信遅延の排除、トークン単位の従量課金を回避できる利点があります[15]。加えて、AIエージェントやコーディング用途では処理が長時間セッションへ広がりつつあります。Anthropicの分析によると、Claude Codeにおける対話ターンの所要時間(99.9パーセンタイル値)は、2025年10月の25分未満から2026年1月には45分超へと倍増しました[16]。
このようなモデル構造と利用形態の変化に対し、コンシューマー機でMoEを効率的に動かす要求は、総モデル容量と計算量の乖離、オープンウェイト化、長時間の対話、プライバシーやコスト要求が重なった結果と考えられます。ただし、これは総合的な背景の整理であり、確定的事実として単一の要因に帰結できるものではありません[17]。
後輩クラウドのAPIがある中で、なぜ手元のマシンで動かす工夫が必要になるんでしょう?
先輩エージェントのセッションが何十分も続くようになると、トークン従量課金の累積やデータの送信先が実務上の関心事になるからだね。
後輩モデルの計算自体は軽くなっても、重み全体のサイズが大きければ転送の手間が残るというわけですか。
先輩そうだね。計算の軽さと重みの巨大さというギャップをどう埋めるかが、技術的な焦点になっているんだ。
何が変わるか:帯域適応型協調実行(q*)と状態再利用の仕組み
FreeTokenは、ローカルPCを単にVRAMの小さいGPUとして扱うのではなく、GPU、CPU、ホストメモリ、PCIe帯域を一体の推論基盤として捉えます[18]。重み管理においては、完全なエキスパートプールをホストメモリ上に保持して正解性の基準とします。そして、GPUの空きVRAMを全MoE層で共有するグローバルなLRU(Least Recently Used)エキスパートキャッシュとして活用します[19]。
プロンプトを一度に処理するPrefill段階では、レイヤー全体のダブルバッファリングを用います。GPUが現行レイヤーを計算している間に、次レイヤーのエキスパート一式をPCIe経由で転送し、待ち時間を計算と重ね合わせます[20]。RTX 5090上での実測では、8,192トークンのチャンクを1.19〜1.22秒で処理し、16kトークンのプロンプトにおいて毎秒6.7kトークンのスループットに達しました[21]。
1トークンずつ逐次生成するDecode段階では、「Dynamic Co-Execution」を適用します。GPUキャッシュに存在しないエキスパート(キャッシュミス)が発生した際、一部をPCIe経由でGPUへ転送して計算し、残りはホストCPU上で直接計算します。この配分比率(q*)はマシンの測定帯域に基づき決定され、両経路が並行実行されます[22]。この協調実行は出力を合成する配置の最適化であり、モデル構造やルーターの挙動を変更しないため、厳密なMoE出力を維持します[23]。
同一のルーティングトレースとキャッシュ容量による比較では、FreeTokenのグローバルLRUキャッシュは、llama.cppの静的分割やKTransformersの配置手法に比べてミス率を低減させました[24]。llama.cppの現行CLIはMoE全体や指定層をCPUに配置する設定を提供しており、論文では静的分割として比較されています[25]。またKTransformersは複数の配置戦略や動的エキスパート更新を提供していますが、FreeTokenはさらに実測帯域からPCIe転送とCPU計算の最適比率を算出する点が異なります[26]。
動的スケジューリングの制御はGPU側のCUDA Graphに統合されており、トークンごとのホスト側オーバーヘッドを抑えています[27]。また、独自フォーマット(FTW)による事前変換で起動時の処理を省き[28]、動作中にもエキスパートキャッシュとKVキャッシュのVRAM配分を動的に再構成できます[29]。エージェントの思考やツール呼び出しで文脈が編集された際は、意味境界のチェックポイントから差分サフィックスのみを再計算する状態再利用を行います[30]。
後輩CPUとGPUで計算を分けると聞くと、精度が落ちたり近似が入ったりしないのか気になります。
先輩この手法はモデルの重みやルーティングを変更せず、計算担当を動的に割り振って出力を足し合わせているから、数学的に同一の出力を保てるよ。
後輩つまりアルゴリズムの近似ではなく、ハードウェア資源のスケジューリングによる効率化なんですね。
先輩その通り。モデルの振る舞いを変えずにハードウェアの帯域制約に対処している点が特徴だね。
誰に影響するか:個人開発者・研究者・エッジ事業者のユースケース
FreeTokenは、ローカル推論の選択肢を「VRAMに収まる小型モデル」から「CPUやホストRAMを含めて動かせるMoEモデル」へと広げます[31]。個人開発者に対しては、OpenAIおよびAnthropic互換のAPIエンドポイントを提供します。既存のコーディングエージェントの接続先を手元の環境へ切り替えることができ、子プロセスからクラウドAPIキーを除去して不要な外部通信を抑制する機能も備わっています[32]。
研究者にとっては、Apache 2.0ライセンスの下でHugging Face形式のチェックポイントを直接読み込めます。モデルのルーティングを近似せずに動作させられるため、再現性のある実験環境を手元で構築しやすくなります[33]。8GB VRAMのノートPCでも、Qwen3.6-35B-A3Bの推論で毎秒39.3トークンのデコードが確認されています[34]。
ただし、あらゆる大規模モデルが標準的なPCで扱えるわけではありません。753BのGLM-5.2の動作検証には、96GB VRAMのGPUに加え、512GiBのホストRAMと433GBのチェックポイント容量を備えたワークステーション環境が用いられています[35]。また、BF16版のQwen3.6-35B-A3Bでも約70GBの空きホストRAMが必要とされています[36]。
完全ローカル推論の導入により、機密性の高いプロンプトやソースコードを外部事業者に送信せず処理できるため、プライバシー管理の選択肢は増えます[37]。費用面では、クラウドの従量課金から機材導入費や電気代、保守運用の負担へと構造が移行します。そのため高頻度・長時間の利用では有利になりやすい一方、利用頻度が低い場合はクラウド従量課金の方が適する場合もあります[38]。
後輩クラウドを使わずに全部ローカルへ移行すれば、コストも完全に抑えられると考えてよいでしょうか?
先輩利用頻度やハードウェアの初期投資によるよ。たまにしか使わないなら従量課金の方が安いこともあるし、電気代や保守の手間もかかるからね。
後輩常にどちらかが優れているわけではなく、利用パターンの頻度や運用体制で判断が分かれるわけですね。
先輩その通り。手元で抱える固定費とクラウドの従量費用のバランスを見極める必要があるよ。
導入前の注意点:ハードウェア要件・未検証事項・セキュリティリスク
FreeTokenの導入にあたっては、対応ハードウェアと環境の要件を正確に把握する必要があります。公式FAQによると、現行版はx86_64アーキテクチャ、RTX 30シリーズ以降のNVIDIA GPU、CUDA 13環境を対象としています。macOS、AMD GPU、aarch64環境への対応はロードマップ段階です[39]。また、対応モデル表にマルチモーダルモデルが含まれている場合でも、現行の推論はテキスト処理のみに限定されます[40]。
公開論文の評価指標はリクエストあたりのデコード速度とTTFT(最初のトークン出力までの時間)が中心です。GPUやシステムの消費電力、tokens/Jなどの電力効率は測定されておらず、省電力性を断定することはできません[41]。また、単発の短いプロンプト処理においてはllama.cppが有利であった事例も報告されています[42]。
ソフトウェアは初期段階にあり、個別の環境依存性も報告されています。例えばデュアルRTX 3090環境において、自動選択された協調実行(hybrid)がオフロード単体実行よりも低速になった事例や[43]、Windowsの32GB RAM機で特定容量以上のオフロード配置に失敗した事例がIssueとして挙げられています[44]。サーバーの既定同時実行数は4リクエストであり、長時間の並行負荷に対する可用性などは導入側での検証が必要です[45]。
セキュリティおよび法制度への対応も重要です。FreeTokenは既定でローカルアドレス(127.0.0.1)にバインドしますが、現行版にAPI認証設定が見当たらないとの指摘もあります。外部ネットワークへ公開する場合は、リバースプロキシによるTLS終端や認証機構の付加が求められます[46]。また、ローカル推論を用いてもツール呼び出しやログからの情報漏洩リスクは残るため、多層防御やアクセス制御、ハルシネーションや権利侵害への確認体制が必要です[47]。EU AI法などの透明性要件や、モデル個別の利用規約(MiniMaxの独自条件など)の遵守も利用者側で確認する必要があります[48]。
後輩手元のローカル環境で完結させていれば、セキュリティや外部への情報流出は気にしなくて大丈夫ですか?
先輩モデル推論自体は手元でも、エージェントが使う外部ツールや検索、ローカルログの管理など、別の経路でのリスク管理は残るよ。
後輩推論エンジンの外側にあるシステム全体で安全性を設計しなければならないんですね。
先輩その通りだね。単一のツール導入で安全性が自動的に完結するわけではない点に注意が必要だよ。
主な略語・用語一覧
- MoE(Mixture-of-Experts):複数の専門家ネットワーク(エキスパート)を持ち、入力トークンごとに必要なエキスパートだけを選択して計算するニューラルネットワーク構造。
- Prefill:入力されたプロンプト全体のトークンを並列に処理し、初期状態を生成する推論フェーズ。
- Decode:直前までの文脈に基づいて、1トークンずつ逐次的に生成を行う推論フェーズ。
- TTFT(Time To First Token):推論リクエストを送信してから、最初の1トークンが出力されるまでに要する時間。
- LRU(Least Recently Used):容量が上限に達した際、最も長い間参照されていないデータを優先的に破棄・更新するキャッシュ管理アルゴリズム。
- CUDA Graph:一連のGPU操作やカーネル起動をグラフとして定義し、CPUからの実行オーバーヘッドを削減するNVIDIAの機能。



