FreeToken RTX 5090：セットアップガイド、結果とヒント

FreeTokenは新しいAIモデルではなく、エッジネイティブな推論ランタイムです。RTX 5090では、完全なエキスパートプールをGPUメモリに収められない大規模なMixture-of-Expertsモデルを提供することが主な目的です。ランタイムはモデル全体をホストメモリに保持し、GPUを適応型の作業キャッシュとして使用します。

この方式が重要なのは、MoEモデルが各トークンで全パラメータの一部だけを有効化するためです。たとえばDeepSeek-V4-Flashは、総パラメータ数2840億、アクティブパラメータ数約130億とされています。アクティブな計算はハイエンドGPUの実用的なメモリ容量に収められますが、完全なチェックポイントを保存するには依然として別の場所に大容量のストレージが必要です。

動画のハイライト：

• FreeTokenは、あらゆるローカルモデルのワークロードではなく、規模の大きいMoEモデル向けに設計されています。
• 1枚のRTX 5090でDeepSeek-V4-Flashを毎秒20トークン以上処理できたと報告されています。
• ランタイムは、エキスパートキャッシュ、転送のオーバーラップ、CPU実行を組み合わせます。
• 短い合成プロンプトよりも、長時間のコーディングエージェントセッションで大きな差が現れます。

FreeTokenの高速化パスは現在、Linux、x86-64システム、NVIDIA GPU、CUDA 13、そして最近のドライバーを中心に構成されています。プロジェクトはRTX 30、40、50シリーズのハードウェアを対象としており、RTX 5090は主要なターゲット範囲に含まれます。

GPUは構成の一部に過ぎません。VRAMを超える場合、完全なエキスパートプールをシステムメモリに配置する必要があります。RTX 5090によってモデル全体のメモリ要件が減るわけではありません。利用可能なGPU、CPU、RAM、PCIeリソースの連携方法が改善されるのです。

研究用のセットアップでは、PCIe帯域幅とホスト側のエキスパート処理帯域幅も区別しています。これらの値は製品仕様だけから推測せず、実際のコンピューター上で測定する必要があります。

2026年の評価では、数学、コーディングエージェント、ネイティブプロトコル、メール／カレンダーのワークロードを対象に、デコードスループットと初回トークンまでの時間を測定しています。エージェントはコンテキストを繰り返し変更し、ツールを呼び出し、新しいリクエストを送信するため、これは重要です。短い一回限りのプロンプトでは、同じプリフィルやキャッシュの挙動は明らかになりません。

RTX 5090上でFreeTokenは、テストしたワークロード全体において、Qwen3.6-35B-A3Bで約毎秒77～83トークン、DeepSeek-V4-Flashで約毎秒22～25トークンを維持しました。最も優れた対応ソフトウェアとの差は、モデルやシナリオによっておおよそ1.5倍～2.3倍と報告されています。

RTX 5090の結果は、モデルがGPUで利用可能なVRAMより大きい場合に最も優れています。FreeTokenの共有LRUキャッシュはトークン間のルーティング局所性に従い、帯域幅ポリシーはキャッシュから外れたエキスパートをどのように処理するかを決定します。

評価によると、テストしたRTX 5090の提供容量では、FreeTokenのキャッシュミスはQwen3.6のエキスパート読み出しの約16%、DeepSeek-V4-Flashの読み出しの約**39%**でした。同じ再生トレースにおいて、比較対象の配置方式ではより高いミス率が示されました。

FreeTokenはメモリを階層構造として管理します。ホストに常駐するエキスパートプールがルーティング対象となるエキスパートの重み全体を保存し、エキスパート以外の重みはGPU上に残ります。残ったVRAMは共有エキスパートキャッシュとなり、セッションの変化に応じて異なる方法で分割できます。

プリフィル中、メモリに余裕がある場合、ランタイムはレイヤー全体のダブルバッファリングを使用します。GPUが1つのレイヤーを処理している間に、次のレイヤーのエキスパートをPCIe経由で移動できます。これにより、転送コストの一部をアクティブな計算の背後に隠せます。デコード中、ランタイムは共有LRUキャッシュを使用して、最近のルーティング判断で選択されたエキスパートを追跡します。

キャッシュミスは、単一の固定操作として扱われません。FreeTokenは以下のように分割します。

• GPUキャッシュへの読み込み：不足しているエキスパートをPCIe経由で転送し、再利用できるよう保持します。
• CPUでの直接実行：重みがすでに存在する場所でエキスパートを処理します。
• 同時実行：両方の経路が現在のトークンの処理に貢献できるようにします。

この分割は、測定されたホスト帯域幅とPCIe帯域幅に依存します。PCIe接続が強力なデスクトップではGPUキャッシュへの読み込みが多くなる可能性があり、ホストメモリ帯域幅が高いシステムではCPUでの直接処理が増える場合があります。

ランタイムは、スケジューラーの安全なポイントでの動的な再構成にも対応しています。ホストメモリが信頼できる情報源であり続けるため、GPUキャッシュ容量の変更はモデルの正確性ではなくパフォーマンスに影響します。これは、ブラウザー、デスクトップアプリケーション、その他のGPUワークロードによって利用可能なVRAM容量が変化する個人用コンピューターで特に役立ちます。

FreeTokenはllama.cpp、Ollama、KTransformersを完全に置き換える万能なソフトウェアではありません。その強みは専門性にあります。プロジェクトは、大規模MoEチェックポイント、NVIDIAアクセラレーション、ホスト常駐エキスパート、エージェント向けの提供に焦点を当てています。

Llama.cppは、CPU、NVIDIA、AMD、Apple Silicon向けの経路を含め、より幅広いハードウェアとOSをサポートしています。また、大規模なGGUFエコシステムと十分な成熟度も備えています。Ollamaは利用しやすいローカルモデル管理を重視し、KTransformersは対応するモデルファミリー向けのCPU-GPUハイブリッド実行を対象としています。

最適な選択は、モデルがVRAMに収まるかどうか、そしてワークロードが対話型かエージェント型かによって決まります。

技術的な詳細については、arXivのFreeToken研究論文と、著者が参照しているflashml.aiのプロジェクトリリースを確認してください。これらのリンクは、プロジェクトの開発に伴って対応モデル、実装の変更、デプロイ手順を確認するための最も確かな情報源です。