FreeToken論文：MoEサービングの比較とセットアップガイド

FreeToken論文は、モデルの重みが利用可能なGPUメモリを超える場合に、大規模なMixture-of-Expertsモデルをエッジ環境で提供するための手法を示しています。正式名称は FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution です。この論文は2026年8月17日にarXivへ投稿され、Song Han、Matei Zaharia、Ion Stoicaを含む研究者が著者として挙げられています。

FreeTokenは推論を単純なGPU専用ワークロードとして扱うのではなく、GPUメモリ、システムメモリ、プロセッサ間でエキスパートの重みをどのように移動・配置するかに焦点を当てています。この違いは重要です。スパースな計算が、そのままスパースなメモリ要件を意味するわけではないからです。モデルは各トークンに対して少数のエキスパートだけを有効化できますが、それでもエキスパート全体へアクセスできる状態を維持する必要があります。

論文の基本情報：

動画のハイライト：

• 適切なメモリ戦略を使えば、非常に大規模なMoEモデルを単一のワークステーションで実行できる理由を説明します。
• FreeTokenのルーティング対応型配置と、固定レイヤーベースのエキスパート分割を比較します。
• 報告されたスループット、テールレイテンシ、ハードウェア対応状況、独立ベンチマークの制限について解説します。

中心となる研究上の問いは明快です。次のトークンが、現在GPU上に常駐していないエキスパートを要求した場合、推論エンジンはどう動作すべきなのでしょうか。静的な配置ポリシーは予測しやすい一方で、実際に必要となるエキスパートを決める実行時のルーティング挙動を無視する可能性があります。FreeTokenは、こうした変化するアクセスパターンに合わせて実行を適応させようとします。

正式な参考資料については、arXivのFreeToken論文を参照してください。

Mixture-of-Expertsモデルには、多数の専門化されたフィードフォワードモジュールが含まれており、一般にエキスパートと呼ばれます。ルーターは各トークンに対して限られた数のエキスパートを選択します。これによりスパースな計算が実現します。つまり、特定のトークンに対して演算を行うのはネットワークの一部だけです。しかし、ルーターは次のトークンで別のエキスパートを選択できるため、パラメータ全体には引き続きアクセスできなければなりません。

FreeTokenは、この変化する需要をシステム上の問題として扱います。エンジンは、エキスパートをGPU上に残すべきか、システムメモリに保持すべきか、あるいは保存場所に近い位置で処理すべきかを判断できます。目的は、ハードウェアバスをまたぐ高コストな転送を減らしながら、実行時のルーティングに追従できるだけの柔軟性を維持することです。

利用可能な技術的議論で説明されている比較では、固定レイヤーベースのポリシーが対照例として使われています。このモデルでは、オペレーターが序盤の何層分のMoE重みをプロセッサ上に保持するかを事前に選択します。分割は推論開始前に決定され、トークンのルーティングが変化しても変更されません。

これに対してFreeTokenは、ルーティングを考慮した挙動を重視します。報告された実験では、同じキャッシュサイズの下で、配置ポリシーだけを変更しながら同一のルーティングトレースをシステムに再生しました。RTX 5090に関連するメモリ構成では、FreeTokenのエキスパート読み出しキャッシュミス率が16%、比較対象の静的分割では**62%**だったと報告されています。これらの数値は引用されたテスト条件を示すものであり、すべてのモデルやデバイスに当てはまる普遍的な結果ではありません。

実用上の重要なポイントは、キャッシュミスは単なる軽微な管理イベントではないということです。ミスが発生するたびに、重みの転送や実行場所の変更が必要になる可能性があります。自己回帰生成中にこれが繰り返されると、コストはスループットの低下として現れます。さらに重要なのは、各ターンで長い停止が発生することです。

利用可能なベンチマーク議論では、通常のGPU専用ロードには大きすぎるMoEモデルを、比較的新しいNvidiaシステム上で実行する場合にFreeTokenが特に有効だとされています。報告された結果には、RTX 5090上のQwen 35B、同程度のハードウェア上のDeepSeek V4 Flash、ワークステーション向けカード上のGLMが含まれます。

以下の数値は、利用可能な議論で報告された測定値を書き起こしたものです。より広範な第三者による再現検証が行われるまでは、研究結果として扱うべきです。

スループットは有用な指標ですが、インタラクティブエージェントの性能をすべて説明できるわけではありません。平均速度が高くても、ときどき数分間停止するシステムは、応答時間が予測可能な低速のエンジンより実用性が低い場合があります。

そのため、報告された最悪ターンの比較が重要になります。引用されたシナリオでは、FreeTokenの最も遅い単一ターンは44秒未満に収まりました。一方、議論ではllama.cppが232秒、別の実装が179秒、KTransformersが946秒とされています。これらは特定のワークロードにおける結果であり、一般的な保証ではありません。

別の比較上の問題は、分母の違いに関するものです。議論ではFreeTokenのデコード値を、クラウドエージェントのトレースにおける33 tokens per secondという値と比較しています。しかし、そのトレース測定には初回トークンまでの時間と中間推論が含まれていると報告されています。純粋なデコード中央値と同じ条件で比較すると、見出しのグラフが示すよりも優位性は小さくなります。これはベンチマークを無効にするものではありません。測定の定義を揃えて比較すべきだという意味です。

FreeTokenの最も有力なユースケースは、対象が限定されているものの意味のあるものです。比較的新しいNvidia GPU、十分なシステムメモリ、大規模MoEモデルを中心としたワークロードを持つユーザーは、ルーティング対応型サービングの恩恵を受けられる可能性があります。静的配置によってエキスパート転送が頻発する場合や、長い停止によってエージェントのウォッチドッグがタスクを終了させる場合、その利点はより明確になります。

このユーザープロファイルは、一般的なローカルAIユーザーとは異なります。利用可能な資料でまとめられたプロジェクト情報によると、対応環境はNvidia CUDAおよびPOSIX Linuxで、パッケージングはベータレベルでした。2026年8月の公開時期の周辺では、旧型Nvidiaカード、デュアルGPUのDocker対応、GGUF、Windowsの修正、Apple Silicon対応などの要望が引き続き確認されていました。

FreeTokenは、ピーク時のtokens per secondだけで評価すべきではありません。インストールの難しさ、モデル互換性、メモリ容量、OS対応、安定性によっては、ベンチマーク上の優位性が相殺されることがあります。より少数のシステムでしか動かないツールでも、専門的な研究エンジンとして価値を持つ可能性はあります。しかし、あらゆるローカル環境における最適なデフォルトになるとは限りません。

llama.cppとの比較は、このトレードオフをよく示しています。既存のプロジェクトであるllama.cppは、より広範なバックエンドとプラットフォームをカバーすると説明されています。一方、FreeTokenは、より限定されたハードウェアプロファイル向けに新しい実行ポリシーへ集中しています。したがって、両者は異なる優先事項に対応するツールとして見るべきです。一方は移植性と成熟度、もう一方は専門的なMoE効率を重視しています。

信頼できる比較には、2つのエンジンを起動して最速の数値を読むだけでは不十分です。同じモデルファイル、量子化、プロンプトセット、コンテキスト長、生成設定、ハードウェア条件を使用してください。平均スループットだけでなく、意味のあるターンの中で最も遅いものも記録します。

再現性を確保するため、正確なコマンドラインオプション、コミットまたはリリース識別子、モデルのチェックサム、テスト日を公開してください。公開プロジェクトは2026年8月時点で歴史が浅いと説明されていたため、カーネル、対応形式、配置ポリシーの進化に伴って結果が急速に変化する可能性があります。

FreeTokenの研究方針が重要なのは、エキスパートの移動を推論における主要な課題として扱っているからです。それでも、利用可能な証拠から導けるのは、あらゆる環境で置き換えられるという主張ではなく、慎重な結論です。プロジェクトはまだ新しく、プラットフォーム対応は限定的で、ベンチマークもより広範な独立検証を必要としています。

この論文は、エコシステム全体に関わるより大きな問いも提起しています。ルーティング対応型のエキスパートキャッシュが有用だと証明されれば、成熟した推論エンジンが将来的に同様の仕組みを採用する可能性があります。その場合、FreeTokenの長期的な貢献は、単独ランタイムとしての継続的な優位性ではなく、その実行ポリシーにあるのかもしれません。