FreeToken vram：ローカルMoE推論セットアップガイド

FreeToken vramは、統合されたローカル推論システムの一部として理解するのが最適です。FreeTokenは、GPUメモリ、システムRAM、CPU処理、そしてそれらを接続するPCIeリンクを組み合わせて、Mixture-of-Expertsモデルを提供します。ルーティング対象となるエキスパートプール全体をホストメモリに保持しながら、利用可能なVRAMには非エキスパート重み、ランタイム状態、KVキャッシュページ、最近使用されたエキスパートを格納できます。

この設計が重要なのは、MoEモデルが非常に大きな総パラメータ数を持ちながら、各トークンではその一部だけをアクティブ化する場合があるためです。DeepSeek-V4-Flashは、284Bパラメータのモデルで、1トークンあたり約13Bのアクティブパラメータを持つモデルとして説明されています。これによりローカルでの提供がより現実的になりますが、より広範なエキスパートプールをどこかに保持する必要がなくなるわけではありません。

動画のハイライト：

• 単一GPUでのテストでは、RTX 3090を使用したFreeTokenのローカル提供が実証されています。
• DeepSeek-V4-Flashは、あるサーバー構成で毎秒およそ10～11トークンに達します。
• デスクトップクライアントは起動が簡単ですが、サーバー経由よりスループットが低くなる場合があります。
• システムRAMの容量とメモリ帯域幅は、実際のパフォーマンスに直接影響します。

実用上の要点はシンプルです。VRAMが多いほど有利ですが、VRAMだけで対応可能なモデルの範囲が決まるわけではありません。大容量GPUを搭載していても、ホストメモリが不足しているシステムでは、フロンティア規模のモデルを読み込めない場合があります。一方、十分なRAMを備えたシステムでは、より柔軟なオフロード動作でモデルを実行できますが、応答速度は帯域幅に大きく左右されます。

FreeTokenのメモリ要件は、モデル、量子化形式、コンテキスト長、そしてエキスパートキャッシュ用に確保するVRAM容量によって異なります。利用可能な資料では、単一GPU構成におけるシステムRAMの実用的な開始点として32 GBが示されており、64 GBあればより余裕を持って運用できます。より大規模なモデルでは、これを大幅に上回る容量が必要になる場合があります。

モデル全体のフットプリントを、アクティブパラメータと混同しないようにしてください。スパースなアクティベーションは各トークンの計算量を削減しますが、非アクティブなエキスパートもホストメモリまたは別のストレージ階層に保持しておく必要があります。そのため、計算上は実行可能なモデルでも、VRAMとRAMを合わせた利用可能なメモリ予算が小さすぎると起動に失敗することがあります。

コンテキストが長くなると、メモリの配分も変化します。エージェントセッションが長くなるにつれてKVキャッシュの需要は増加する一方、エキスパートのワーキングセットは比較的安定している場合があります。そのためFreeTokenは、初回起動時の割り当てを固定のものとして扱うのではなく、KVキャッシュページとエキスパートキャッシュスロットの配分を調整する必要があります。

2026年に公開された論文FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Executionでは、この柔軟なメモリアプローチが説明されています。GPU上のエキスパートキャッシュは、エンジンを再起動したり、CPU上に常駐するエキスパートプール全体を再読み込みしたりすることなく、スケジューラの安全なタイミングで再構築できます。

以下の手順に従って、ローカルFreeToken環境を準備してください。利用可能なテスト資料ではデスクトップアプリケーションがベータ版ソフトウェアとして説明されているため、正確なインターフェースや対応モデルの一覧は変更される可能性があります。

初回起動は、最終的なパフォーマンス結果ではなく、基準値を測定するテストとして扱うべきです。メモリ使用量、プロンプト処理時間、Decode速度、そして複数のリクエストにわたってモデルが安定して動作するかを記録してください。

FreeTokenのパフォーマンスは、頻繁に使用されるエキスパートをどれだけ効果的にVRAMに保持できるか、そしてキャッシュミスをどのように処理するかに左右されます。Decode中、ルーティングされたエキスパートがすでに常駐している場合もあれば、ホストメモリから移動させる必要がある場合もあります。FreeTokenは共有のLRU方式エキスパートキャッシュを使用するため、直近のルーティング動作が今後の常駐状態に影響する可能性があります。

ランタイムは、キャッシュミスをGPU転送とCPUによる直接実行に振り分けます。この分割は、単一の固定ルールではなく、実測されたホスト側の処理帯域幅とピン留め転送帯域幅に基づいて行われます。この方式が有用なのは、PCIe性能に優れたデスクトップと、リンク幅の狭いノートPCでは、異なる配分が有効になる可能性があるためです。

PrefillとDecodeでは動作が異なります。Prefillでは大きなプロンプトを処理するため、エキスパートプールの広範囲にわたる移動が必要になる場合があります。FreeTokenは、利用可能なメモリ予算が許す場合、フルレイヤーのダブルバッファリングを使用して、エキスパート転送とGPU計算をオーバーラップさせます。Decodeはより段階的に進みますが、キャッシュミスが繰り返されると応答性が低下する可能性があります。

提供された資料のテストでは、単一のRTX 3090構成が、あるサーバー側のシナリオで毎秒約10.5トークンを生成しました。別の構成で行われたデスクトップクライアントのテストでは、毎秒約8.8トークンに達しました。これらの数値は普遍的なベンチマークではなく、特定の構成に依存する参考値です。保証値としてではなく、目安として利用してください。

すべてのモデルがFreeTokenで同じように動作するわけではありません。参照されたテストでは、密結合型のQwen 3.8 27B BF16構成が、ある環境で起動に失敗し、予期しないエンジン終了が発生しました。これは、メモリ容量だけでなく、モデルの互換性、量子化形式、ランタイムのサポートも重要であることを示しています。

大規模モデルは、単純に利用可能なRAMが不足しているという理由でも失敗します。あるテストでは、GLM-5.2 NVFP4構成に、利用可能な予算を超えて数百GBの追加システムメモリが必要であることが示されました。このようなモデルには、より大規模なワークステーション構成が必要になる場合があります。

以下の管理された手順でトラブルシューティングを行ってください。

• 同じモデルを短いプロンプトでテストする。
• 失敗が読み込み中に発生したのか、生成中に発生したのかを確認する。
• モデルが対応している量子化形式を使用しているか確認する。
• 他のアプリケーションを終了する前後で利用可能なメモリを比較する。
• 再現可能なエンジンエラーを報告する際は、サーバーログを保存する。

最も確実な方法は、一度に1つの変数だけを変更することです。モデル、クライアント、オペレーティングシステム用パッケージ、メモリ割り当て、推論モードを同時に変更すると、実際の原因を特定することが難しくなります。