- FreeToken 290bモデル:フロンティア規模のスパースモデルを支えるエッジサービングのアプローチを理解する。
- 中核設計:GPUエキスパートキャッシュ、CPU実行、PCIe転送を組み合わせる。
- 最適なセットアップ:ランタイムを調整する前に、ホストとPCIeの帯域幅を測定する。
- 主な利点:デコード時のキャッシュミスを減らし、計算の背後にプリフィル転送を隠す。
- 対応ハードウェア:8 GBのノートPC向けGPUからワークステーション級ハードウェアまで対応する。
FreeToken 290bモデル:システムの役割
FreeTokenは、大規模なMixture-of-Expertsモデル向けのエッジネイティブなサービングシステムです。FreeToken 290bモデルという検索語は一般に、論文で扱われるフロンティア規模のサービング環境を指します。ただし、文書化されたデモでは、総パラメータ数284B、トークンあたりのアクティブパラメータ数約13BのDeepSeek-V4-Flashが使用されています。重要なのは、スパースな活性化によって計算量は削減される一方、完全なエキスパートプールには依然として大容量のホストメモリとストレージが必要だという点です。
モデル全体をGPUメモリに収めることを要求する代わりに、FreeTokenはGPU、CPU、ホストメモリ、PCIeインターコネクトを1つの推論プラットフォームとして扱います。エキスパートではない重みはGPU上に残し、ルーティング対象となるエキスパートプール全体はホストメモリに保持します。動的なGPUキャッシュには、現在のワークロードで最も有用なエキスパートとレイヤーの組み合わせが保存されます。
このシステムは、長いコンテキストや繰り返し発生するツール呼び出しによって、プリフィルとデコードの両方に負荷がかかるエージェント型セッションを対象としています。その設計は、次の3つの recurring な問題に対応します。
- プリフィル転送コスト:大規模なエキスパートプールをCPU-GPUリンク経由で転送する必要がある。
- デコード時のキャッシュミス:各トークンが、現在GPU上に常駐していないエキスパートを要求する可能性がある。
- 変動するリソース:ブラウザ、ゲーム、デスクトップアプリケーション、増加するKVキャッシュによって、利用可能なVRAMが減少する可能性がある。
研究論文「FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution」では、2026年8月24日に公開されたアーキテクチャ、実装、評価について説明されています。
スパース計算
MoEルーティングは各トークンに対して少数のエキスパートサブセットだけを有効化するため、フロンティア規模の計算をローカルハードウェアでより現実的に実行できます。
弾性キャッシュ
共有LRUキャッシュが最近ルーティングされたエキスパートを追跡し、利用可能なGPUメモリ予算の変化に応じてサイズを変更できます。
ハイブリッド実行
キャッシュミスは、測定された帯域幅に応じてGPUへ転送するか、CPU上で直接実行できます。
総パラメータ数は、トークンあたりのアクティブな計算量と同じではありません。FreeTokenは、完全なエキスパートプールが占めるより大きなメモリフットプリントを管理しながら、スパース計算を実用化します。
FreeTokenがプリフィルとデコードを処理する方法
FreeTokenは、プリフィルとデコードでボトルネックが異なるため、推論を2つのフェーズに分離します。プリフィルはプロンプトを処理してTime to First Tokenを決定する一方、デコードはトークンを1つずつ生成し、エキスパートの局所性と帯域幅のバランスにより強く左右されます。
プリフィル中、システムはフルレイヤーのダブルバッファリングを使用します。GPUが1つのレイヤーを計算している間、次のレイヤーのエキスパート重みがPCIe経由で2つ目のバッファにストリーミングされます。これにより、すべてのエキスパート転送が完了するまで待つのではなく、転送と計算をオーバーラップさせます。
エージェント型ワークロードでは、会話履歴も頻繁に編集されます。思考ブロック、ツール呼び出し、ツール出力、会話ターンは、リクエスト間で削除または置換される可能性があります。FreeTokenは、これらの意味的境界に再帰状態チェックポイントを配置し、残存するプレフィックスを再利用できるようにします。再処理が必要なのは変更されたサフィックスだけです。
デコード中、ルーティングされたエキスパートが共有GPUキャッシュに存在するか確認されます。キャッシュヒットはGPU上で直接実行されます。キャッシュミスは、帯域幅から算出された比率を使って、GPUキャッシュへの補充とCPU実行に分配されます。
| 推論フェーズ | 主な負荷 | FreeTokenの対応 | 実際の効果 |
|---|---|---|---|
| プリフィル | エキスパート転送とプロンプトの再計算 | フルレイヤーのダブルバッファリングと意味的チェックポイント | 転送の影響と重複処理を削減 |
| デコード | エキスパートミスと限られたホスト帯域幅 | LRUキャッシュとCPU-GPU間のミス分割 | トークンごとの実行をより均衡化 |
| マルチターンのエージェント利用 | ツール呼び出しや推論後のコンテキスト編集 | 意味的アンカーでのプレフィックス再利用 | 保持された履歴の再プリフィルを短縮 |
| ランタイムの変更 | 変動するVRAMとKVキャッシュ需要 | エキスパートキャッシュの弾性リサイズ | メモリ調整のたびにエンジンを再起動する必要がない |
ミスポリシーでは、次の2つの測定値を使用します。
- Bₚ:ピン留めされたホストからデバイスへのエキスパート転送帯域幅。
- Bₕ:CPUエキスパートカーネルが利用できる実効ホスト側帯域幅。
m個のエキスパートが欠落しているステップでは、近似的なキャッシュ補充数は次のようになります。
q* ≈ m × Bₚ / Bₕ
PCIeの比率が高いほど、GPUキャッシュへの補充を増やす方針が有利になります。CPU側の処理能力が高い場合は、より多くのミスをCPU上で直接実行できます。これは固定されたハードウェア階層ではなく、ランタイムで適用されるポリシーです。
最適なCPU-GPU分割は、測定された帯域幅、メモリレイアウト、CPUの挙動、実際に使用するPCIeリンクに依存します。ハードウェア仕様書は計画には役立ちますが、FreeTokenのポリシーはランタイム測定に基づいて決定してください。
FreeToken 290bモデルのハードウェアとパフォーマンスガイド
文書化された評価では、複数のコンシューマー向けおよびワークステーション向け構成が対象となっています。結果はモデル、量子化、ホストメモリ、PCIe世代、ワークロードによって変化するため、以下の数値は普遍的な保証ではなく、報告された参考値として扱ってください。
このシステムは、Qwen3.6-35B-A3B、DeepSeek-V4-Flash、そしてワークステーション級のGLM-5.2デモを提供します。最大の例では、96 GBメモリを搭載した単一のRTX PRO 6000 Blackwell上で、753BパラメータのMoEモデルを実行しています。
| モデルまたは階層 | 総パラメータ数 | アクティブパラメータ数 | 報告された展開環境 |
|---|---|---|---|
| Qwen3.6-35B-A3B | 35B | 3Bクラス | ノートPC向けハードウェアを含むコンシューマー向けGPU |
| DeepSeek-V4-Flash | 284B | 13B | RTX 3090、4090、5090クラスのシステム |
| GLM-5.2 | 753B | 40B | RTX PRO 6000 Blackwell、96 GB |
| FreeToken論文の対象範囲 | 20以上のMoEモデル | モデルに依存 | 8 GBのノートPC向けGPUからワークステーション向けGPUまで |
RTX 5090では、テストされたワークロード全体で、Qwen3.6が毎秒約77~83トークン、DeepSeek-V4-Flashが毎秒約22~25トークンだったと論文は報告しています。報告結果は、モデルとシナリオに応じて最も強力なベースラインの1.5倍から2.3倍でした。
ハードウェアをまたいだQwen3.6のコーディングワークロードでは、FreeTokenは最も強力なベースラインを次の程度上回りました。
| ハードウェア構成 | 報告された優位性 |
|---|---|
| RTX 3090 | 1.3倍 |
| RTX 4090 | 1.3倍 |
| RTX 5090サーバー | 1.9倍 |
| RTX 5090デスクトップ | 2.1倍 |
| RTX 4060ノートPC | 1.8倍 |
| GLM-5.2搭載RTX PRO 6000 | llama.cpp比で2.0倍 |
RTX 4060ノートPCの例は特に注目に値します。8 GBのシステムでNVFP4ビルドを使用し、毎秒39.3トークンに到達しました。この比較では、RTX 4090のレートの92%に相当すると報告されています。この結果は、ホスト帯域幅と量子化がGPUのモデル名と同じくらい重要になり得る理由を示しています。
FreeTokenの最大の性能向上は、各要素の連携によってもたらされます。ランタイムがPCIeリンク、CPU帯域幅、キャッシュ容量、モデル形式を効率的に活用すれば、より小型のGPUでも競争力を維持できます。
FreeTokenセットアップのステップ別ワークフロー
実用的な展開は、キャッシュサイズを推測することではなく、メモリ階層の確認から始めるべきです。ホスト上に常駐するエキスパートプールが正確性の基準となるため、GPUキャッシュ容量はモデルの正しさではなく、速度とレイテンシに影響します。
モデルとエキスパート形式を確認する
モデルの総パラメータ数、アクティブパラメータ数、精度、エキスパート数、チェックポイントのレイアウトを確認します。FreeTokenのFTW形式は、エキスパートバンクをランタイムに適したレイヤー・エキスパート構造へ正規化し、起動時のテンソル探索や再パッキングを回避できます。
ホストとPCIeの帯域幅を測定する
対象マシンで、ピン留めされたエキスパート転送帯域幅と、CPUによるエキスパート処理の実効帯域幅をプロファイリングします。公称帯域幅だけに頼らず、これらの値を使って各デコードミスにおけるキャッシュ補充の割合を推定します。
メモリ予算を確保する
残りのGPUメモリをエキスパートスロットに割り当てる前に、エキスパートではない重み、アクティベーション、KVキャッシュ用の領域を確保します。長時間のエージェントセッションではKVキャッシュの需要が増えるため、キャッシュは弾力的に維持します。
ホストのエキスパートプールを準備する
エキスパートを最終的なホストレイアウトへ直接読み込み、プラットフォームが対応している場合は、データが格納されたメモリをDMA用にピン留めします。これにより不要なページフォールトを回避し、起動時のオーバーヘッドを削減できます。
実際のワークロードでウォームアップする
代表的なプロンプト、ツール呼び出し、マルチターンセッションから開始します。共有LRUキャッシュにアクティブなルーティングパターンを学習させた後、デコード速度、Time to First Token、ミス率、テールレイテンシを評価します。
| セットアップ項目 | 推奨アクション | 重要な理由 |
|---|---|---|
| GPUメモリ | KVキャッシュとエキスパートスロットに領域を分割する | コンテキストの増加によって適切なバランスが変わる |
| ホストメモリ | 完全なエキスパートプールを利用可能な状態に保つ | ホストストレージが正確性の基準であり続ける |
| PCIe経路 | 対応している場合はピン留めメモリを使用する | DMA転送がキャッシュ補充速度を決定する |
| CPU実行 | GPUのNUMAノード付近にワーカーを固定する | 不要なメモリアクセスのペナルティを回避する |
| 起動形式 | 事前パック済みのFTW形式レイアウトを優先する | 探索と再パッキングの処理を削減する |
コールドキャッシュテストとマルチターンのエージェントテストから始めてください。短いプロンプトを1回実行するだけでは、実環境のパフォーマンスを決める転送、キャッシュ、コンテキスト再利用の挙動が見えない可能性があります。
制限事項、チェックリスト、ベストプラクティス
FreeTokenはサービングシステムを改善しますが、大規模モデルにかかる物理的なコストをなくすわけではありません。完全なエキスパートプールには、依然として数百GBのホストメモリまたはストレージが必要になる場合があります。プラットフォームのサポートはOSやドライバーの挙動にも左右され、特にピン留めまたは登録済みメモリではその影響が大きくなります。
高速なDMA経路を確立できない場合、ランタイムは純CPUのMoEバックエンドへフォールバックできます。エキスパートではないレイヤーはGPU上に残し、アクティベーション、ルーティングメタデータ、集約された出力はデバイス境界を越えて転送します。これにより展開性は向上しますが、最大転送性能が低下する可能性があります。
結果を比較する前に、次のチェックリストを使用してください。
展開準備チェックリスト:
- モデルの精度と完全なエキスパートプールのサイズを確認する
- ピン留めPCIe転送帯域幅とCPUエキスパート帯域幅を測定する
- KVキャッシュとエキスパートスロットの両方にVRAMを確保する
- コールドスタート、シングルターン、マルチターンのワークロードをテストする
- キャッシュミス率、TTFT、デコード速度、テールレイテンシを追跡する
最も有用な指標は、平均トークン毎秒だけではありません。エージェント型ワークロードでは、テール部分のTTFTによって、クライアントが正常に待機できるか、タイムアウトしきい値に達するかが決まる場合があります。論文では、テスト対象のセルにおける最悪ターンのTTFTについて、FreeTokenは44秒未満に収まった一方、各ベースラインは評価のどこかで150秒を超えたと報告されています。
| 指標 | 監視対象 | 解釈 |
|---|---|---|
| デコードスループット | 平均トークン毎秒 | 生成効率を測定する |
| TTFT | 平均および最悪ターンのレイテンシ | プロンプト転送と再計算を捉える |
| エキスパートミス率 | ルーティングされた読み取りに占めるミスの割合 | キャッシュ局所性の品質を示す |
| キャッシュ容量 | 常駐しているエキスパートプールの割合 | VRAM割り当てと再利用の関係を示す |
| 起動時間 | ディスク読み込みから最初の応答まで | 実用的なオンデマンド利用性を測定する |
各エンジンで同じハーネス、プロンプト、モデル精度、成功基準を使用して評価してください。エージェントの軌跡は分岐する可能性があるため、リクエストごとの処理量が異なる場合、単純な実時間の比較は誤解を招くことがあります。
FreeToken FAQ
Q: FreeToken 290bモデルは、正式名称を持つ別個のモデルですか?
提供された研究では、FreeTokenは単独の290Bモデルチェックポイントではなく、サービングシステムとして位置付けられています。主な文書化された例は総パラメータ数284BのDeepSeek-V4-Flashであるため、「290b」という表現はフロンティア規模のサービングを扱うトピック向けの検索ラベルとして捉えるべきです。
Q: FreeTokenは静的なCPU-GPU配置と何が違いますか?
静的なシステムでは、ロード時またはプリフィル時にエキスパートの配置を決定します。FreeTokenは共有LRUキャッシュを使用してデコード時のルーティングに追従し、避けられないミスをPCIe経由のキャッシュ補充とCPUでの直接実行に分配します。
Q: FreeTokenは8 GBのノートPC向けGPUで大規模MoEモデルを実行できますか?
評価では、NVFP4を使用した8 GBのRTX 4060ノートPC構成でQwen3.6を実行した結果が報告されています。完全なモデルは依然としてホスト上に常駐するエキスパートに依存するため、GPUメモリだけでチェックポイント全体を保持するわけではありません。
Q: マルチターンのエージェント型ワークロードが重要なのはなぜですか?
ツール呼び出しとコンテキスト編集は、繰り返しプリフィルを発生させます。FreeTokenは再利用可能なプレフィックスを保持するために意味的チェックポイントを使用し、エキスパートキャッシュはデコード中のルーティング局所性を追跡します。