FreeToken 4gb vram：セットアップガイドとハードウェアの制限

FreeTokenは、個人向けハードウェア上で大規模なMixture-of-Expertsモデルをサービングするための研究システムです。ゲーム、キャラクタービルド、ダウンロードコードに関する話題ではありません。FreeToken 4gb vram の中心的な疑問は、完全なエキスパートプールを別の場所に保持したまま、非常に小さなGPUメモリ容量で推論に参加できるかどうかです。

このシステムでは、モデルデータを大きく2つのグループに分けます。エキスパート以外の重みはGPU上に残し、ルーティングされたエキスパートの重みはCPU上に常駐するプールへ保存します。残ったVRAMは、レイヤーとエキスパートの組み合わせ全体を格納する伸縮可能なキャッシュになります。この設計により、完全なエキスパートプールがGPU容量を超えていてもモデルを動作させられます。ただし、VRAMが少ないほど一般的にキャッシュミスが増え、PCIe転送やCPU実行への依存が大きくなります。

原論文では、8 GBのノートPC向けGPUからワークステーション級のハードウェアまで、複数のハードウェアにまたがる評価が記録されています。4 GB構成でテストされたことは確認されていません。そのため、4 GB構成は確実なデプロイ対象ではなく、制約の多い実験として考えるべきです。

FreeTokenは、2段階のエキスパートメモリ階層を使用します。ホスト側にはルーティング対象となる完全なエキスパートプールを保持し、GPU側では共有LRUキャッシュを維持します。各キャッシュスロットには、1つのレイヤーとエキスパートの組み合わせを評価するために必要なテンソルが保存されます。この論理構成により、起動時に固定されたエキスパート配置に依存するのではなく、ルーティングの挙動に応じてキャッシュを追従させることができます。

デコード中、ルーターはアクティブなエキスパートを識別します。キャッシュ済みのエキスパートはGPU上で直接実行されます。キャッシュにないエキスパートは2つのグループに分けられ、一部はGPUのキャッシュスロットへ転送され、残りはCPU上に常駐するプールから直接実行されます。この分割は、すべてのハードウェアに共通する仕様ではなく、測定された帯域幅に基づいて行われます。

論文では、おおよその充填率を次のように定義しています。

q* ≈ m × BP / BH

ここで、mはキャッシュにないエキスパートの数、BPは測定されたピン留め転送帯域幅、BHは測定されたCPU側のエキスパート処理帯域幅です。実際の意味は単純で、PCIe転送が高速であるほど多くのキャッシュ充填が有利になり、CPUメモリ帯域幅が強いほどCPU上で直接実行する方法が有効になります。

4 GB GPUのワーキング領域は、文書化された8 GBのノートPC向け区分よりも大幅に小さくなります。この違いは、キャッシュできるエキスパートの数だけに影響するわけではありません。同じメモリ予算で、GPUに常駐するモデルコンポーネントやコンテキスト関連の状態も収容する必要があります。会話やエージェントセッションが長くなるとKVキャッシュの需要が増加し、エキスパートキャッシュの容量を維持することが難しくなります。

キャッシュ領域が少ないと、FreeTokenではコールドミス、ワーキングセットの入れ替わり、ホストからデバイスへの移動が増える可能性があります。システムのCPU実行経路は一部のミスを吸収できますが、ホストメモリからエキスパートの重みを読み出すコストをなくすことはできません。そのため、性能はモデル形式、プロンプト長、CPU帯域幅、PCIeリンク、OSのメモリ挙動、同時に実行するアプリケーションに左右されます。

原資料では、8 GBのノートPC向け構成で公式NVFP4リリースのQwen3.6をサービングし、測定可能なデコード性能を維持したことが報告されています。この結果は参考点として有用ですが、4 GBへ直接外挿すべきではありません。小さなGPUでは、KVキャッシュとエキスパートキャッシュの分割をより積極的に調整する必要がある可能性があり、一部のモデル構成では実用的なランタイムに十分な領域が残らないこともあります。

有効な評価手順として、まず短い単一ターンのリクエストから始めます。次に長いプロンプトを試し、その後、コンテキストを変化させる複数ターンを実行します。これにより、コールドスタート時の挙動と持続的なデコード時の挙動を分離し、メモリ需要が変化してもGPUキャッシュが有効であり続けるかを確認できます。

最も重要な準備は、実行を制限しているリソースを特定することです。FreeTokenは、エンジンを再起動したりホスト常駐プールを再読み込みしたりせず、スケジューラーの安全なタイミングでエキスパートキャッシュを調整できるよう設計されています。この柔軟性は、ブラウザー、デスクトップコンポジター、その他のアプリケーションによって利用可能なVRAMが変化する個人用コンピューターで特に重要です。

ホスト側のプールも、最適化されたレイアウトの恩恵を受けます。論文では、ランタイムに適したバンク構成でエキスパートの重みを格納するFreeToken Weight形式が説明されています。最終的なホストレイアウトへ直接読み込むことで起動時の処理を削減でき、遅延メモリピン留めによって、空のページを読み込んだ直後に上書きするようなページフォールトを避けられます。

FreeTokenの設計は、MoEモデルにおける「収まる」という言葉の意味を変えます。非アクティブなエキスパートをホストメモリに残せるため、モデルのすべてのエキスパートを同時にVRAMへ常駐させる必要は必ずしもありません。しかし、アドレス可能なメモリ階層にモデルを収めることと、インタラクティブな速度でサービングすることは別の問題です。キャッシュミスが発生するたびに、スケジューリング上の判断とメモリ帯域幅のコストが生じます。

このコストを削減するため、システムはいくつかの仕組みを組み合わせています。

• フルレイヤーのダブルバッファリングは、プリフィル転送とGPU計算を重ね合わせます。
• セマンティック対応の状態キャッシュは、エージェントによる編集境界の周辺で再帰状態とプレフィックスを保持します。
• 共有LRUエキスパートキャッシュは、デコードステップ間で最近のルーティング局所性を追跡します。
• 帯域幅適応型実行は、キャッシュミスをGPUキャッシュへの充填とCPU実行に分割します。
• 伸縮可能なメモリ管理は、状況の変化に応じてエキスパートキャッシュとKVキャッシュの配分を調整します。

4 GBシステムについて最も安全な結論は、条件付きのものです。FreeTokenのアーキテクチャは、制約されたGPUメモリを実験するための道筋を提供しますが、利用可能な資料は4 GBを公式または一般的に実用的な対象として確立していません。ランタイムが必要なGPUコンポーネントのために十分なメモリを確保できない場合や、キャッシュの入れ替わりによってレイテンシが許容できない場合、その制限は単純な設定ミスではなく、アーキテクチャとハードウェアに固有の問題です。