FreeToken：エッジネイティブMoEセットアップガイドと比較

FreeTokenは、コンシューマー向けおよびワークステーション向けハードウェア上で、大規模なMixture-of-Expertsモデルを実行するために設計されたエッジネイティブ推論エンジンです。このプロジェクトは、2026年8月に投稿されたFreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution論文で紹介されています。すべてのパラメーターをグラフィックスメモリに保持することを求めるのではなく、各トークンで選択されたエキスパートを中心に、システムメモリ、GPUメモリ、転送バスを協調させます。

この設計は、スパースモデルが抱える特有の問題に対応します。1つのトークンに対してアクティブになるパラメーターはごく一部であっても、エキスパート全体には引き続きアクセスできなければなりません。そのため、モデルはアクティブな計算量が比較的少なくても、大容量のメモリと慎重なデータ移動を必要とする場合があります。

動画のポイント：

• FreeTokenは、非常に大規模なMixture-of-Expertsモデルのローカルサービングを対象としています。
• 中心となる考え方は、固定的なレイヤー分割ではなく、動的にエキスパートを配置することです。
• 報告された性能向上は、互換性のあるNVIDIAシステムで最も顕著です。
• 確認した資料には、独立した第三者ベンチマークはありませんでした。

このプロジェクトが重要なのは、ローカル推論が単純な計算性能だけで制約されるわけではないからです。モデルが複数のメモリプールに収まっていても、頻繁に選択されるエキスパートが低速な接続を経由しなければならない場合、性能が低下する可能性があります。FreeTokenは、固定的な配置ルールを受け入れるのではなく、こうした転送をスケジューリング問題として扱います。

Mixture-of-Expertsモデルには、多数の専門化されたフィードフォワードネットワークが含まれていますが、ルーターは各トークンに対してその一部だけをアクティブ化します。確認した例では、各レイヤーに数百のエキスパートがあり、その時点では数個だけが選択されます。これにより計算はスパースになりますが、より広範なパラメーター集合にアクセスする必要がなくなるわけではありません。

実際のボトルネックは、エキスパートキャッシュミスです。次のトークンがGPU上にまだ用意されていないエキスパートを選択した場合、システムはそのデータをバス経由で移動するか、重みがすでに存在する場所で関連処理を実行する必要があります。各判断はレイテンシ、スループット、安定性に影響します。

FreeTokenのアプローチはルーティング対応です。実際に選択されたエキスパートを利用して、配置と実行方法を適応させます。これは、レイヤー番号だけを基準にした固定分割とは異なります。静的なルールは予測しやすい一方で、モデルが将来どのエキスパートを選択するかを把握できません。

重要なのは、アクティブパラメーターと常駐パラメーターを区別することです。モデルは比較的小さなサブセットだけをアクティブ化する場合でも、大きなメモリフットプリントを必要とすることがあります。そのため、数学的なワークロードが変わらなくても、ルーティングポリシーが実際の応答性に影響を与える可能性があります。

報告されたベンチマーク結果は、テストされたハードウェアとワークロードにおいて、FreeTokenに明確な優位性があることを示しています。GeForce RTX 5090で350億パラメーターのQwenモデルを提供した場合、論文では毎秒およそ77～83トークンと報告されています。DeepSeek V4 Flashでは、報告された範囲は毎秒22～25トークンです。ワークステーション向けカードでGLMを提供したテストでは毎秒5.2～14.9トークンと報告されており、引用された比較ではllama.cppが毎秒7.3トークンでした。

最も注目すべき結果は、ノートPC向けのテストです。8 GBのグラフィックスカードで毎秒39.3トークンが報告されており、テスト対象のデスクトップ版RTX 4090の結果の約92%と説明されています。この数値は、グラフィックスメモリが限られている場合に配置戦略が大きな意味を持つ可能性を示しています。ただし、これは普遍的なハードウェア性能の保証ではなく、プロジェクトによるベンチマークとして扱うべきです。

スループットは比較要素の一部にすぎません。テールレイテンシによって、外部ウォッチドッグが終了させる前にエージェントが1ターンを完了できるかどうかが決まることがあります。確認した資料では、FreeTokenの1ターンにおける最悪値は44秒未満と報告されている一方、一部の比較結果は232秒を超えていました。低速な外れ値が平均速度の低下よりも大きな問題になり得るコーディングエージェントのワークフローでは、これらの数値は特に重要です。

慎重に読み解くには、同じ条件での測定も必要です。エンドツーエンドのエージェント速度には、最初のトークンまでの時間や推論時間が含まれる場合がありますが、純粋なデコード速度ではその一部が除外されます。測定方法の定義を考慮せずに、これらの数値を単純に並べて比較すべきではありません。

FreeTokenの現在の対応範囲は、成熟したクロスプラットフォームランタイムよりも狭いものです。公開されている分類では、開発ステータスはベータ、環境はNVIDIA CUDA、対象OSはPOSIX Linuxとされています。確認したプロジェクト資料には、Windowsの修正、デュアルGPU対応、旧世代NVIDIAカード、GGUF対応、Apple Silicon対応を求める声も記載されています。

そのため、セットアップで最初に確認すべきなのは互換性です。新しいNVIDIAカードで高速な結果が出たからといって、同じエンジンがMac、旧世代のGeForceカード、またはCUDA非対応アクセラレーターで動作するとは限りません。サポート対象外の構成を最適化しようとするのではなく、まず対応環境から始めてください。

管理されたテスト用ディレクトリを使用し、設定内容を明確にしておきましょう。エンジンのバージョン、モデルファイル、量子化、プロンプト形式、コンテキストサイズ、測定した出力を記録します。これにより、高速な結果を別のモデルや軽いワークロードの結果と取り違えるのを防げます。

FreeTokenの最大の強みは、すべてのローカルAIユーザーが直ちに既存のランタイムを置き換えるべきだという点ではありません。その価値は、より具体的なものです。難しいメモリ帯域幅の問題に対してルーティング対応の解決策を探り、互換性のあるシステムで大幅な性能向上を報告しています。エージェントがエキスパート転送で頻繁に停止するユーザーにとっては、平均速度の見栄えよりもテールレイテンシの低さが重要になる可能性があります。

その代わりに、成熟度と対応範囲にはトレードオフがあります。確認したプロジェクトはllama.cppと比べて公開されてからの歴史が浅く、資料では独立した第三者ベンチマークも確認できませんでした。より広範なハードウェア対応、安定したパッケージング、再現可能な外部テストによって、このアプローチが広く採用されるランタイムになるのか、それとも確立されたプロジェクトに取り込まれる技術群にとどまるのかが決まるでしょう。

FreeToken固有の利点が自分のワークロードに合う場合に利用してください。移植性、幅広いバックエンド対応、予測可能なインストールが、特定クラスのNVIDIAシステムでのMoE性能の最大化よりも重要な場合は、確立されたランタイムを利用できる状態にしておきましょう。

ローカルエンジンには、スループットのグラフでは捉えきれない実用上の利点もあります。

• プロンプトと生成内容をローカルマシン内に保持できます。
• プロバイダーのレート制限やサービスの可用性に左右されません。
• 固定されたローカル環境により、モデルサービスの変更への依存を減らせます。
• ハードウェアを所有するには、依然として相応の初期費用がかかります。
• 電力消費、メモリ容量、保守も評価に含めるべきです。