- FreeToken linux は、CUDA対応ハードウェアとホストメモリを活用したローカルMoEサービングに重点を置いています。
- 最適な環境:十分なRAMとPCIe帯域幅を備えた新しいNVIDIAシステム。
- 中核となる利点:ルーティングを考慮したエキスパートキャッシュが、トークン単位のモデル挙動に適応します。
- 主な制限:最も明確な対象はLinuxであり、macOSのサポートは記載されていません。
- 主な成果:報告されている改善効果は、大規模MoEモデルとエージェント型ワークロードで特に強く現れています。
FreeToken linuxの概要と最適な用途
FreeToken linuxは、個人用ハードウェア上で大規模なMixture-of-Expertsモデルを提供するために設計された、ベータ段階のローカル推論システムです。すべてのエキスパートの重みをGPUメモリに保持する代わりに、エキスパート全体をホストメモリに置き、利用可能なVRAMを柔軟なキャッシュとして使用します。そのため、このプロジェクトはモデル、ゲーム、報酬コードのプラットフォームというよりも、システムランタイムとして位置付けられます。
最も適しているのは、コーディング、数学、またはツールを使用するエージェントを通じて、大規模なオープンウェイトモデルを実行する開発者です。モデルが利用可能なVRAMを超えていても、活性化がスパースである場合、FreeTokenは特に有用です。このシステムは、コンシューマー向けGPU、CPU、RAM、PCIeのリソースを、1つの協調的な推論プラットフォームとして活用することを目指しています。
動画のハイライト:
- FreeTokenは、数千億パラメータ規模のモデルをローカルで提供することを目指しています。
- ルーティングを考慮したキャッシュにより、デコード中の不要なエキスパート転送を削減します。
- 報告されているベンチマークには、NVIDIAのデスクトップ、ワークステーション、8 GBのノートPC向けGPUが含まれます。
- 利用可能なプロジェクトメタデータでは、LinuxとNVIDIA CUDAが最も明確にサポートされている環境です。
| 項目 | FreeTokenが提供するもの | 実際の意味 |
|---|---|---|
| ランタイムの焦点 | エッジネイティブなMoEサービング | 大規模なスパースモデルをデータセンター外で実行できる |
| 主要プラットフォーム | NVIDIA CUDAを備えたPOSIX Linux | Linuxユーザーにとって最も明確な対象環境 |
| メモリモデル | ホスト常駐エキスパートとGPUキャッシュ | モデル全体の重みをVRAMに収める必要がない |
| ワークロードの焦点 | エージェント型推論 | マルチターンのコンテキストとツール呼び出しを重視 |
| プロジェクトの成熟度 | ベータ段階のシステム | 互換性やパッケージングの変更を想定する必要がある |
FreeTokenは、特化型のLinux推論ランタイムとして捉えてください。互換性のあるNVIDIAハードウェア、十分なシステムメモリ、大規模なMoEモデルを繰り返し使用するワークロードがすでにある場合に、特に大きな価値を発揮します。
FreeTokenがMoEメモリを処理する仕組み
Mixture-of-Expertsモデルには多数のエキスパートネットワークが含まれますが、ルーターは各トークンに対してその一部だけを活性化します。参考論文では、DeepSeek-V4-Flashを例として挙げています。各レイヤーで256個のルーティング対象エキスパートのうち6個が活性化され、284Bパラメータのモデルに対して13Bのパラメータがアクティブになります。スパースな活性化によって計算量は減りますが、すべてのエキスパートの重みには引き続きアクセスできなければなりません。
FreeTokenは、モデルをCPU常駐のエキスパートプールとGPU常駐のワーキングセットに分けます。GPUキャッシュはMoEレイヤー間で共有されるLRUポリシーを使用し、最近選択されたエキスパートを後続のトークンでも利用できるようにします。エキスパートがキャッシュにない場合、ランタイムはそのエキスパートをGPUへ転送するか、CPU上で直接実行できます。
| メモリ階層 | 保存されるデータ | 推論中の役割 |
|---|---|---|
| GPUメモリ | 非エキスパートの重み、KVキャッシュ、エキスパートスロット | 高速な実行と最近使用されたエキスパートの保持 |
| ホストメモリ | ルーティング対象エキスパートの完全なプール | MoEモデル全体の完全なデータソース |
| PCIeリンク | エキスパート転送とランタイムデータ | 選択されたキャッシュミスをGPUメモリへ移動 |
| CPUコア | 選択されたキャッシュミスの直接実行 | 待機する代わりに残りのホスト帯域幅を利用 |
| NVMeストレージ | 元のモデルまたは準備済みの重みファイル | 起動と形式変換のソース |
ランタイムは、ホスト側のエキスパート処理帯域幅と、PCIe経由のページ固定転送帯域幅という2種類の帯域幅を測定します。その後、GPUキャッシュに取り込むべきキャッシュミスのエキスパート数と、CPU上でそのまま実行すべきエキスパート数を推定します。この方式により、すべてのハードウェア構成を同一のものとして扱う必要がなくなります。
プリフィル中、FreeTokenはレイヤー全体のダブルバッファリングを使用します。あるレイヤーを実行している間に、次のレイヤーのエキスパートをPCIe経由でストリーミングできます。デコード中は、共有キャッシュが変化するルーターの判断に追従します。同じキャッシュが両方のフェーズをサポートするため、プリフィル用とデコード用に分離したメモリプール間で、コストの高い切り替えを行う必要がありません。
| 仕組み | 解決する問題 | 重要な理由 |
|---|---|---|
| 共有LRUエキスパートキャッシュ | トークン間でルーティングが変化する | GPU上の常駐状態が直近の需要に追従する |
| 帯域幅適応型実行 | 一部のエキスパートがキャッシュから外れる | CPUとGPUがキャッシュミスを同時に処理できる |
| レイヤー全体のダブルバッファリング | プリフィル転送による実行停止 | エキスパートの移動と計算を重ね合わせられる |
| セマンティック状態チェックポイント | エージェントのコンテキストが繰り返し編集される | 保持されたプレフィックスの再計算を減らせる |
| 柔軟なキャッシュサイズ変更 | VRAMの利用可能量が変化する | 再起動せずにキャッシュ容量を適応させられる |
スパースな活性化によって、メモリ要件がなくなるわけではありません。エキスパートプール全体をホストメモリから利用できる状態に保つ必要があり、モデルファイルは非常に大きくなる可能性があります。GPU速度を評価する前に、システムRAM、ストレージ容量、メモリ帯域幅を確認してください。
FreeToken linuxのセットアップ手順
利用可能な情報では、Linux、NVIDIA CUDA、POSIXオペレーティングシステム、ベータ開発段階が最も明確な対象環境として示されています。パッケージングは急速に変わる可能性があるため、古いガイドのコマンドをコピーするのではなく、flashml.aiにあるプロジェクトの最新リリース手順を使用してください。
ハードウェア構成を確認する
マシンが互換性のあるNVIDIA GPUとCUDA環境を使用していることを確認します。利用可能なVRAM、システムRAM、PCIeリンク幅、ストレージ容量、ホストメモリ帯域幅を記録してください。これらの値は、エキスパートキャッシュのサイズや、GPU転送とCPU実行の分担に影響します。
Linuxランタイムを準備する
サポート対象のPOSIX Linux環境を使用し、プロジェクトが指定する最新の依存関係をインストールします。NVIDIAドライバーとCUDAスタックをリリース要件に合わせてください。利用可能なメタデータではFreeTokenはベータソフトウェアであるため、あるディストリビューション向けに構築されたパッケージが別のディストリビューションでも同じように動作すると仮定しないでください。
モデルの重みをステージングする
サポート対象のMoEチェックポイントを選び、エキスパートプール全体がホストメモリに収まることを確認します。FreeTokenのFTW形式は、ランタイム向けのレイアウトでエキスパートバンクを保存するため、起動時のテンソル探索と再パッキングを削減できます。元のチェックポイントと準備済みの表現を保存できる十分なNVMe容量を確保してください。
プロファイルを取得し、小さなリクエストをテストする
ランタイムにホスト処理帯域幅とPCIe転送帯域幅を測定させ、その後、短いプロンプトから始めます。長時間のエージェントセッションへ移行する前に、モデルが読み込まれ、GPUキャッシュが初期化され、CPUとGPU間のキャッシュミス処理が機能することを確認してください。
実際のワークロード向けに調整する
本番環境で実行する予定のコーディング、数学、またはツール利用パターンと同じ内容をテストします。平均デコードスループットだけに頼らず、最初のトークンまでの時間、最悪ターンのレイテンシ、RAM使用量、VRAMの圧迫状況、リクエスト完了率を確認してください。
| セットアップ確認項目 | 目標条件 | 失敗の兆候 |
|---|---|---|
| GPUバックエンド | NVIDIA CUDA互換環境 | ランタイムがGPU経路を初期化できない |
| オペレーティングシステム | POSIX Linux対象環境 | サポートされないパッケージまたはフォールバックの欠如 |
| ホストメモリ | エキスパートプール全体を収容できる容量 | 読み込み失敗または過度なページング |
| ストレージ | チェックポイントと準備済みファイル用のNVMe容量 | ステージングが長時間化する、またはディスク不足 |
| ランタイムテスト | 短いプロンプトが正常に完了する | キャッシュ、ドライバー、またはモデル形式のエラー |
長時間セッションを実行する前に:
- NVIDIAドライバーとCUDAの互換性を確認する
- エキスパートプール全体に十分なRAMを確保する
- 元のモデルファイルとFTWモデルファイル用のNVMe容量を確認する
- PCIeリンクとホストメモリの性能を測定する
- エージェントを起動する前に短いプロンプトをテストする
セットアップが成功したかどうかは、モデルを一度読み込めるだけでは判断できません。エージェント型ワークロードではプリフィル、キャッシュの再利用、エキスパートのキャッシュミスに繰り返し負荷がかかるため、過度なテールレイテンシなしにマルチターンのリクエストが完了することを確認してください。
パフォーマンス、互換性、トレードオフ
FreeTokenの公開評価では、大規模MoEモデルとエージェント型ワークロードで最も強い結果が報告されています。RTX 5090では、Qwen3.6-35Bで毎秒77~83トークン、DeepSeek-V4-Flashで毎秒22~25トークンに達します。また、8 GB GPUを搭載したRTX 4060ノートPCでは毎秒39.3トークン、単一のRTX PRO 6000ではGLM-5.2で毎秒14.9トークンが報告されています。
同じ評価では、最初のトークンまでのテール時間も重視されています。FreeTokenで報告された最悪ターンは、テストされたセルでは44秒未満に収まりました。一方、一部の構成ではベースラインの停止時間がそれを大きく上回りました。これらの測定値はプロジェクト独自の評価によるものなので、導入を決定する前に独立したテストを行うことも有用です。
| モデルまたは層 | ハードウェア | FreeTokenの報告結果 | コンテキスト |
|---|---|---|---|
| Qwen3.6-35B-A3B | RTX 5090 | 77~83 tok/s | エージェント型ワークロード |
| DeepSeek-V4-Flash | RTX 5090 | 22~25 tok/s | エージェント型ワークロード |
| Qwen3.6-35B-A3B | RTX 4060ノートPC、8 GB | 39.3 tok/s | NVFP4リリース、PCIe x8 |
| GLM-5.2 | RTX PRO 6000、96 GB | 14.9 tok/s | 753B規模のデモンストレーション |
| FreeTokenのテールTTFT | テスト済み構成 | 44秒未満 | 報告された最悪ターンの結果 |
llama.cppとの比較は、単純に平均速度だけで決まるものではありません。参考分析では、あるRTX 5090のキャッシュ容量において、FreeTokenのグローバルLRUキャッシュはQwen3.6のエキスパート読み取りの16%をキャッシュミスにしたと報告されています。これは、ルーティングを考慮しない静的分割の62%と比較した値です。同じ比較地点におけるDeepSeek-V4-Flashでは、FreeTokenのミス率は39%でしたが、引用された静的ポリシーではさらに高い頻度でミスが発生しました。
ただし、互換性は大きなトレードオフです。利用可能なプロジェクトメタデータでは、サポート対象はLinuxとNVIDIA CUDAの環境とされています。旧世代NVIDIAカード、デュアルGPUのDockerサポート、GGUF、Windowsの修正、Apple Siliconのサポートに関する要望は、ローンチ時点では未解決の課題として説明されていました。FreeTokenがより限定されたシステム構成で性能上の優位性を持つ場合でも、既存のプロジェクトのほうが幅広いハードウェアに対応している可能性があります。
FreeTokenが力を発揮する場面
- 大規模なMoEチェックポイント
- 新しいNVIDIA GPU
- 長時間実行するコーディングエージェント
- テールレイテンシーの影響を受けやすいワークロード
互換性が優先される場面
- Apple Siliconシステム
- 旧世代のNVIDIAハードウェア
- 混在構成またはマルチGPU構成
- 確立されたクロスプラットフォームワークフロー
測定すべき項目
- 最悪ターンのTTFT
- エキスパートキャッシュのミス率
- ホストRAMの圧迫状況
- リクエスト完了率
公開されている数値は有用な参考値として利用し、普遍的な保証と捉えないでください。ハードウェアの帯域幅、モデル形式、プロンプトの長さ、同時実行中のアプリケーション、エージェントハーネスの挙動によって、ローカル環境での結果は大きく変わる可能性があります。
FreeToken linux FAQと実用チェックリスト
FreeTokenは、ローカルでオープンウェイトのMoE推論を行うための、エッジネイティブなサービングシステムとして理解するのが適切です。すべてのモデルをあらゆるコンピューターに適したものにするわけではなく、ピーク時のトークン毎秒だけで評価すべきでもありません。Linuxユーザーは、互換性の確認、メモリ計画、現実的なマルチターンテストを優先してください。
技術的な詳細は、2026年8月24日に公開されたarXivのFreeToken論文に記載されています。この論文では、キャッシュアーキテクチャ、帯域幅適応ポリシー、柔軟なメモリ管理、実装方法、評価手法について説明されています。
Q: FreeToken linuxとは何ですか?
FreeToken linuxは、大規模なMixture-of-Expertsモデル向けのLinux中心のローカル推論ランタイムです。GPUメモリ、CPU実行、ホストRAM、PCIe転送を連携させ、利用可能なVRAMを超えるモデルをエッジハードウェア上で利用できるようにします。
Q: FreeTokenはmacOSやApple Siliconをサポートしていますか?
利用可能な2026年のプロジェクト情報には、MacビルドやApple Siliconのサポートは記載されていません。公式のプラットフォーム資料が変更されるまでは、NVIDIA CUDAを搭載したLinuxを最も明確なサポート対象として扱ってください。
Q: なぜFreeTokenはGPUメモリを超えるモデルを実行できるのですか?
MoEルーティングでは、各トークンに対して一部のエキスパートだけが活性化されます。FreeTokenはエキスパートプール全体をホストメモリに保持し、VRAMをルーティング対応キャッシュとして使用します。選択されたキャッシュミスはGPUへ転送するか、CPU上で直接実行できます。
Q: FreeTokenはどのコンピューターでもllama.cppより高速ですか?
いいえ。報告されている優位性は、大規模MoEモデルとエージェント型ワークロードを新しいNVIDIAハードウェア上で実行する場合に最も強く現れます。幅広いハードウェア対応や確立されたクロスプラットフォームワークフローが、特化型MoE性能より重要な場合は、llama.cppが依然として実用的な選択肢です。
互換性のあるNVIDIA Linuxハードウェア上でのローカルMoEサービングを優先するなら、FreeTokenを選択してください。プラットフォーム対応範囲、より簡単なデプロイ、既存のモデル形式のサポートが決め手になる場合は、より幅広いランタイムを選択しましょう。