FreeToken api server：セットアップガイドとランタイムのヒント

FreeToken は、大規模なオープンウェイト mixture-of-experts モデル向けのエッジネイティブなサービングシステムです。ゲームやエンターテインメントのプラットフォームではなく、互換性のあるアプリケーションやエージェントフレームワークから利用できるサービングランタイムを通じて、ローカルモデル推論を提供することを目的としています。

このシステムは、2 層のメモリ階層を中心に設計されています。完全なエキスパートプールはホストメモリに保持され、GPU には非エキスパートの重みと、ルーティングされたエキスパートの伸縮可能なキャッシュが保存されます。これにより、利用可能な VRAM より大きなモデルでも、すべてのエキスパートをグラフィックスカードに常駐させることなく実行できます。

動画のハイライト：

• FreeToken は、最先端規模の MoE モデル向けローカル推論に重点を置いています。
• 中心的な課題は、キャッシュミスしたエキスパートを効率的に移動または実行することです。
• 報告された結果には、コンシューマー向け GPU、ノートパソコン、ワークステーション級のハードウェアが含まれます。
• 最高スループットの数値だけでなく、ハードウェアの互換性が重要です。

FreeToken を理解するには、モデル容量とアクティブな計算量を分けて考えると便利です。MoE モデルには合計で数千億のパラメータが含まれている場合がありますが、各トークンで有効化されるのはエキスパートのごく一部だけです。参考論文では、DeepSeek-V4-Flash は各レイヤーで 256 個のルーティング対象エキスパートのうち 6 個を有効化し、2840 億個のパラメータのうち約 130 億個がアクティブパラメータになると説明されています。

このスパース性によってローカルサービングが可能になりますが、メモリの問題がなくなるわけではありません。ルーターはトークンごとに異なるエキスパートを選択できるため、すべてのエキスパートにアクセスできる状態を維持する必要があります。そのため FreeToken では、キャッシュポリシーと帯域幅スケジューリングを API サーバー設計の中核要素として扱います。

FreeToken api server を設定する前に、マシンがランタイムの想定する導入プロファイルに合っていることを確認してください。公開資料では CUDA 中心のベータ環境が説明されており、新しい NVIDIA GPU と、完全なエキスパートプールを保持できる十分なホストメモリで最も良い結果が得られています。

最も重要なチェック項目は次のとおりです。

• NVIDIA GPU が利用可能で、適切な CUDA サポートがあること。
• 選択したモデルの完全なエキスパートプールを保持できるシステムメモリがあること。
• エキスパートの重みを効率的に転送できる PCIe 接続があること。
• CPU 側のエキスパート実行を継続できるホストメモリ帯域幅があること。
• モデルファイル用に十分なストレージ容量と読み取り速度があること。
• 非エキスパートの重みとランタイムキャッシュの両方に十分な空き VRAM があること。

論文の評価では、RTX 4060 ノートパソコン、RTX 3090 および RTX 4090 システム、RTX 5090 ハードウェア、RTX PRO 6000 ワークステーションが対象となっています。これらの結果は、すべての構成で保証される性能ではなく、参考値として扱ってください。

たとえば、8 GB の RTX 4060 ノートパソコンで報告された毎秒 39.3 トークンという結果は、NVFP4 ビルドと特定のモデル構成を使用したものです。異なるモデル形式、ドライバー、メモリレイアウト、ワークロードでは、結果も変わる可能性があります。

API サーバーは、動的なメモリ圧迫にも対応する必要があります。FreeToken の実行中は、ブラウザー、デスクトップコンポジター、ゲーム、その他のアプリケーションが VRAM を使用することがあります。FreeToken の伸縮可能なメモリ方式は、利用可能な予算が変わるたびにエンジン全体を再起動するのではなく、スケジューラーが安全に処理できる時点でエキスパートキャッシュのサイズを変更することを目的としています。

信頼性の高いセットアップは、スループットの調整ではなく、モデルとメモリ計画から始まります。起動失敗を減らし、その後の比較を意味のあるものにするため、以下の手順に従ってください。

セットアップ手順が重要なのは、FreeToken の主な利点が継続的なサービング中に現れるためです。短いプロンプトでは、プレフィックス再利用、セマンティックチェックポイント、適応型エキスパートキャッシュの価値が現れない場合があります。マルチターンのエージェントワークロードでは、コンテキストが繰り返し編集され、変化するエキスパートの組み合わせを通じてトークンがルーティングされるため、設計目標をより正確に反映します。

FreeToken の最も特徴的な仕組みは、共有 LRU エキスパートキャッシュです。デコード中、ルーターは次のトークンに必要なエキスパートを特定し、そのエキスパートがすでに常駐しているかを確認します。キャッシュヒットは GPU 上で実行されます。キャッシュミスは、実測された帯域幅に基づいて GPU キャッシュへの補充と CPU による直接実行に振り分けられます。

これは固定的なレイヤー分割とは異なります。静的な配置ポリシーでは、トークンごとのルーティングの変化が分かる前にエキスパートの配置場所を決定します。一方 FreeToken では、最近のルーティング動作に合わせてキャッシュの常駐内容が変化します。引用されているリプレイ結果では、同じキャッシュ容量であってもミス率が低下しており、特にワークロードが短期的なエキスパート局所性を示す場合に効果が大きくなっています。

q-star ポリシーは、PCIe 経由で取得すべきキャッシュミスの数と、CPU 上で実行すべきキャッシュミスの数を推定します。この分割は、ページ固定転送の帯域幅とホスト側エキスパート処理帯域幅の実測関係に基づいています。これは重要な点です。デュアルチャネル DDR5 を搭載したデスクトップと LPDDR5 を搭載したノートパソコンでは、GPU が似ていても最適な動作が大きく異なる可能性があります。

チューニングでは、平均デコード速度だけでなく、テールレイテンシーを優先してください。評価では、テストされたすべてのセルで FreeToken の最悪ターンの TTFT が 44 秒未満だった一方、一部のベースラインは 150 秒を超えました。実際のエージェント統合では、平均 tokens-per-second の数値が競争力のあるものに見えても、長い停止によってクライアントのタイムアウトやアイドル監視が発生する可能性があります。

実用上のルールとして、次の点を守ってください。

• ホストシステムに不要なメモリ圧迫を発生させない。
• 各エンジンで同一のモデル重みと精度を比較する。
• 単独のプロンプトだけでなく、マルチターンのタスクを測定する。
• 初回トークンのレイテンシーと最悪ターンのレイテンシーを追跡する。
• キャッシュサイズ、コンテキスト長、CPU スレッド数の上限を記録する。
• 他のアプリケーションが VRAM を使用した後にテストを繰り返す。

公式の FreeToken 研究論文 では、セマンティック対応キャッシュ、パイプライン化されたプレフィル、伸縮可能なメモリ管理、帯域幅適応型実行について技術的に説明されています。リリースの動作が初期の概要と異なる場合は、この論文を基準として使用してください。

FreeToken は特定の導入プロファイルにおいて有望ですが、すべてのローカル推論ユーザーにとって自動的に最適な選択肢になるわけではありません。十分な RAM を備えた新しい NVIDIA システム、MoE ワークロード、そして長時間にわたって推論をローカルで実行する理由がある環境が、最も適しています。

初期段階にあるという公開状況も重要です。提供された 2026 年の資料におけるプロジェクトの公開履歴はまだ短く、より広く採用されるためには、対応ハードウェアの拡大、追加のオペレーティングシステム、デュアル GPU ワークフロー、一般的なモデル形式など、いくつかの実用的な要望が残されています。

ローカルサービングは、ホスト型サービスのレート制限への依存を減らし、プロンプトをユーザーのマシン内に保持できます。一方で、運用上の責任はユーザーに移ります。API 認証情報を保護し、サービスのバインド先を意図的に設定し、認証なしのエンドポイントを共有ネットワークに公開しないでください。