FreeToken量子化：MoE推論のセットアップガイド

FreeTokenはエッジネイティブな推論エンジンであり、新しい言語モデルでも、単独で動作する量子化アルゴリズムでもありません。FreeTokenの量子化という文脈で重要なのは、Mixture-of-Expertsモデル全体が利用可能なVRAMを超える場合に、ランタイムが対応する低精度チェックポイントをどのように提供するかという点です。

Mixture-of-Expertsモデルは大量のエキスパートを保持しますが、各トークンはそのうち限られたエキスパートだけを通過します。DeepSeek-V4-Flashは、総パラメータ数が2,840億で、各トークンあたり約130億のパラメータがアクティブになると説明されています。このスパースなアクティベーションによりローカル実行がより現実的になる一方、完全なエキスパートプールは依然として大きなメモリ容量とデータ転送の課題を生みます。

論文では、FreeTokenが複数のモデルファミリーと精度形式をサポートしていると説明されています。評価には、ネイティブにMXFP4量子化されたDeepSeek-V4-Flashチェックポイント、8 GBノートPC構成向けのNVFP4リリース、そしてBF16のQwen3.6-35B-A3Bが含まれています。つまり、「量子化サポート」は普遍的な変換ルールではなく、特定のモデルチェックポイントとランタイム経路に依存します。

動画のポイント：

• FreeTokenは、GPUメモリを超える大規模MoEモデル向けに設計されています。
• 適応型エキスパートキャッシュにより、頻繁にルーティングされるエキスパートをVRAMに保持します。
• キャッシュミス時には、CPU実行とPCIe転送を組み合わせて処理できます。
• 長時間のコーディングエージェントセッションが重要な対象ワークロードです。

FreeTokenは、2階層のエキスパートメモリ階層を中心に推論を構成します。ホストシステムはルーティング対象となるエキスパートプール全体を保持し、エキスパート以外の重みはGPU上に残ります。そのうえで、利用可能なVRAMはMoEレイヤー間で共有される可変エキスパートキャッシュとして使用されます。

この構成によって、量子化の役割も変わります。低精度の重みはホスト上に常駐するモデルのサイズと転送量を削減しますが、ランタイムは依然として、どのエキスパートをVRAMに置くか、欠落しているエキスパートをどれだけ転送するか、そしてどれをCPUで直接実行するかを判断しなければなりません。

Prefill中、十分なキャッシュ容量がある場合、FreeTokenはレイヤー全体のダブルバッファリングを使用します。GPUがあるレイヤーを計算している間に、次のレイヤーのエキスパートをPCIe経由でストリーミングできます。これにより、各転送を個別のGPUアイドル時間として発生させるのではなく、データ移動と計算を重ね合わせます。

Decode中は、ルーティングがより細粒度になります。ランタイムは、最近選択されたエキスパートに基づく共有LRUキャッシュを維持します。キャッシュヒット時はGPU上で実行されます。キャッシュミス時には、ホスト側と転送側の帯域幅を測定した結果に応じて、PCIe経由でキャッシュに追加するか、CPU上で直接実行できます。

帯域幅に適応するポリシーは、この設計の中心です。PCIe接続が高速であれば、より多くの不足エキスパートを転送する方が有利になる可能性があります。一方、ホストメモリ帯域幅が優れていれば、CPUで直接実行する方が魅力的になります。この判断は固定されたハードウェアプロファイルからコピーするのではなく、実際に導入されたマシンに合わせて行われます。

FreeTokenで文書化されている高速化セットアップは、現時点では専門性の高い構成に限定されています。利用可能な資料で説明されているコマンドライン経路には、x86-64コンピューター上のLinux、NVIDIA GPU、CUDA 13、新しいドライバーが必要です。プロジェクトではRTX 30、RTX 40、RTX 50シリーズのハードウェアが重点的に取り上げられています。

公開された評価では、RTX 5090構成において、Qwen3.6-35B-A3Bは毎秒77～83トークン、DeepSeek-V4-Flashは毎秒22～25トークンと報告されています。VRAM 8 GB、システムメモリ32 GBのRTX 4060ノートPCでは、公式NVFP4 Qwen構成が毎秒39.3トークンに達しました。

別のワークステーション結果では、7530億パラメータモデルと説明されているGLM-5.2を、単一のRTX PRO 6000上で毎秒14.9トークンで提供しました。これらの数値は、特定のチェックポイント、ハードウェア、ワークロード、精度形式に基づくものです。普遍的な性能保証ではなく、参考値として扱ってください。

最も適した用途は、VRAMには収まらないものの、システムメモリ上では扱えるモデルです。量子化モデルがGPU内に完全に収まる場合、汎用ランタイムでもすでに優れた速度が得られる可能性があり、FreeTokenの転送指向の利点はそれほど重要ではなくなるでしょう。

公開されているベンチマーク値を保証された結果とみなすことなく、対応する量子化モデルを評価するには、次の手順を使用してください。

ランタイムは、スケジューラーの安全なポイントでGPUエキスパートキャッシュのサイズ変更と再構築を動的に行えます。これは、セッション中にブラウザーウィンドウ、デスクトップアプリケーション、その他のGPUワークロードによって利用可能なVRAMが変化する場合に役立ちます。

エージェント型ワークロードでは、生のデコード速度と同じくらいコンテキスト処理が重要です。FreeTokenは、思考セグメント、ツール呼び出し、ツール出力、会話ターンなどの意味的境界に再帰状態チェックポイントを設定します。エージェントが以前のブロックを編集した場合、ランタイムは変更されていないプレフィックスを再利用し、新しいサフィックスだけを再度Prefillできます。

FreeTokenを通常のローカルサービングに採用する前に、セットアップが実用的かどうかを左右することの多い制約を確認してください。

FreeTokenは、llama.cppの万能な代替製品として位置付けられているわけではありません。llama.cppは、より幅広いOS、プロセッサ、GPUベンダー、Apple Siliconデバイス、モデル形式をサポートしています。一方、FreeTokenは、規模の大きいMoEモデルと、GPUメモリ、CPU実行、ホストRAM、PCIe転送の連携に重点を置いています。

このプロジェクトは、OpenAI互換およびAnthropic互換のAPIも提供しており、ローカルモデルを対応するコーディングツールやエージェントツールに接続できます。ただし、APIレイヤーで互換性があっても、すべてのクライアントで挙動が同一になるとは限りません。そのため、認証、コンテキスト処理、ツール呼び出し、タイムアウト設定を個別にテストしてください。

技術設計と評価の詳細については、FreeTokenの研究論文を参照してください。論文ではFreeTokenをApache 2.0のオープンソースシステムとして位置付け、リリース先としてflashml.aiを記載しています。