FreeToken、MoEキャッシュミスを動的に分割し、8GBのRTX 4060で35Bモデルを39.3 token/sで実行

FreeTokenは、ローカルMoE推論を、パーソナルコンピューターを小型サーバーとして扱うのではなく、CPU、メインメモリ、PCIe、GPUの協調スケジューリング問題として再定義する。エキスパートの全重みをホストメモリに常駐させ、非エキスパート重みはGPUに配置する。残りのVRAMは、複数レイヤーで共有され、実行中に容量を調整できるLRUエキスパートキャッシュとして使用される。この構成の正確性はキャッシュヒット率に依存しない。ホスト側が常に重みの正本を保持し、GPU容量は速度にのみ影響する。

デコード中に`m`個のエキスパートでキャッシュミスが発生した場合、システムは転送とCPU offloadのどちらかに固定せず、実測したホスト帯域幅`B_H`とPCIe帯域幅`B_P`に基づき、`q≈m·B_P/B_H`によってGPUへ転送する数を決定する。残りはCPU上でそのまま計算する。2つの分岐を並列実行した後、部分出力を統合するため、エキスパートの削除や近似ルーティングは行われない。論文は、短期的なルーティングには局所性があるとも指摘している。RTX 5090でキャッシュ容量を同一にした場合、FreeTokenにおけるQwen3.6とDeepSeek-V4-Flashのエキスパート読み込みミス率はそれぞれ16%と39%で、KTransformersの41%と59%を下回った。

エージェント型ワークロードでは、ツール呼び出し後にprefillが繰り返されることもコスト要因となる。FreeTokenは特殊tokenの境界でKVおよびループ状態のチェックポイントを保存し、会話が切り詰められたり書き換えられたりした場合には、直近の有効なアンカー以降のサフィックスだけを再計算する。また、モデルレイヤーの読み込みではダブルバッファリングを用い、次のレイヤーのPCIe転送を現在のレイヤーの計算とオーバーラップさせる。[論文](https://arxiv.org/abs/2608.16157)では、RTX 5090上のQwen3.6-35B-A3Bで77～83 token/s、8GBのRTX 4060 Laptop GPUでは[NVFP4チェックポイント](https://huggingface.co/nvidia/Qwen3.6-35B-A3B-NVFP4)を使用して39.3 token/sを達成したと報告している。このモデルは合計35Bパラメータを持ち、tokenごとに約3Bパラメータがアクティブ化される。

ただし、これらの結果は依然として著者が管理した単一リクエストのテストに基づく。ワークロード、CPUスレッド数、量子化形式はすべてのエンジンで完全に統一されているわけではなく、マルチテナント環境のスループットや消費電力も評価されていない。さらに重要なのは、論文からGitHubリポジトリへのリンクが設けられているものの、確認時点では404が返され、外部からkernel、状態キャッシュ、動的なVRAM再構成を再現できない点だ。エンジニアリングチームは、コード公開後のメモリ要件、モデルサポートマトリクス、長時間のエージェント処理でも同等のテールレイテンシを維持できるかを注視する必要がある。