FreeToken Docker：セットアップガイド、制限事項と回避策

FreeTokenは、非常に大規模なMixture-of-Expertsモデルをワークステーションのハードウェアで実用的に動作させるために設計された、ローカルAI推論システムです。現在のFreeToken Dockerの状況は明確です。公開されている情報によると、Dockerサポートはまだ含まれておらず、専用のDockerサポート要望がプロジェクトのGitHub issue trackerでオープンのままになっています。

つまり、FreeTokenをすぐに実行できるコンテナイメージとして扱ったり、標準的なdocker runコマンドが動作すると想定したりすべきではありません。コミュニティによる検証を通じて、将来的にコンテナデプロイが可能になる場合はありますが、非公式イメージには互換性、セキュリティ、再現性に関する問題が入り込む可能性があります。

動画のポイント：

• FreeTokenは、固定的なCPUとGPUの分割ではなく、動的なエキスパート配置を使用します。
• 報告された結果には、Nvidia製ワークステーションおよびノートPCのハードウェアが含まれています。
• このプロジェクトは、CUDAをサポートするLinuxおよびWindows向けとして説明されています。
• Docker、GGUF、デュアルGPU、Apple Siliconのサポートは、利用できない機能として報告されています。

プロジェクトの公開issueページには、Docker Support · Issue #11が掲載されており、2026年8月21日に作成されています。参照されたスナップショットの時点では、この要望はオープンで、担当メンテナーも関連する開発ブランチも割り当てられていません。プロダクション環境へのデプロイを計画する前に、公式Dockerサポートissueを確認してください。

FreeTokenの主な技術的アイデアは、大規模なモデルを単純に1つのGPUへ読み込むことではありません。報告されているシステムは、トークンごとに一部のエキスパートだけを選択し、エキスパートの読み出しを動的に管理することで、Mixture-of-Expertsアーキテクチャを処理します。この動作により、メモリ配置とデータ移動がパフォーマンスの中心的な要素になります。

従来のコンテナはライブラリやプロセスをパッケージ化できますが、GPUメモリの制限を自動的に解決するわけではありません。ホスト側には、互換性のあるNvidiaドライバー、CUDAアクセス、システムRAM、十分なストレージ帯域幅、そしてコンテナランタイムがGPUと通信するための権限が必要です。

モデルの重みも重要な検討事項です。引用された解説では、7530億パラメータのモデルについて、4ビット量子化された重みがディスク上でおよそ433GBを占有すると説明されています。各トークンではより小さなアクティブエキスパートの集合だけが必要ですが、ルーティングが変化した際に利用できるよう、非アクティブなエキスパートも保存しておく必要があります。

静的なエキスパートオフロードとの比較結果からも、単純なコンテナラッパーだけでは不十分な理由がわかります。コンテナは依存関係を分離できますが、ルーティングポリシーを改善したり、PCIe転送を減らしたり、利用可能なVRAMを増やしたりすることはできません。

公式のコンテナサポートが文書化されるまでは、即席のデプロイではなく、準備状況を評価するワークフローが最も安全です。以下の手順により、ホストの問題とFreeTokenランタイムの問題を切り分け、複数の未知の変数を同時にトラブルシューティングする可能性を減らせます。

プロセスの最後には、公式Dockerサポートを待つ、ネイティブインストールを継続する、明確にコミュニティ製と表示されたビルドを隔離環境でテストする、といういずれかの判断を文書化してください。コミュニティ製イメージを公式FreeTokenリリースとして扱ってはいけません。

FreeTokenの報告されたパフォーマンスは、モデル、GPU、メモリの挙動、測定方法に大きく左右されます。引用された数値には、RTX 5090クラスのワークステーションでQwen 35Bを実行した際の約77～83トークン/秒、DeepSeek V4 Flashの22～25トークン/秒、ある比較におけるGLM 5.2の14.9トークン/秒が含まれています。また、ノートPCで39.3トークン/秒という結果も紹介されています。

これらの数値は、普遍的なDockerベンチマークではなく、プロジェクトが報告した結果として扱うべきです。コンテナのオーバーヘッドは、モデル実行コストより小さいことが多い一方、GPU設定の誤り、低速なボリュームマウント、ファイルシステム変換、ライブラリの不一致によって、結果は大きく異なる可能性があります。

経済面での議論も、単純に「無料」というラベルだけにとどまりません。ローカル推論によって継続的なAPI利用を減らし、プロンプトをプライベートなハードウェア内に保持できますが、ハードウェアへの投資、電気代、メンテナンス、モデルストレージ、セットアップ時間も考慮する必要があります。

コンテナを利用する場合、最も重要な指標は単一のピークトークン速度ではありません。起動の成功、モデルの読み込み時間、持続的なデコード速度、メモリ使用量、エラー率、想定するコンテキスト長での挙動を記録してください。

ローカル環境は、プライバシー、可用性、モデルバージョンの管理という点で、依然として魅力的です。ただし、こうした利点は現在のサポート不足や、コンテナ化されたワークフローでコミュニティによる保守が必要になる可能性と比較して判断すべきです。

現在のFreeTokenのサポート状況には、Dockerの計画に直接影響するいくつかの境界があります。参照された情報では、Dockerサポート、GGUFサポート、デュアルGPUサポート、Apple Siliconサポートがないと報告されています。また、Windowsでのインストール失敗についても説明されています。これらの制限により、コンテナは万能な互換性レイヤーではありません。

ハードウェアがNvidia CUDAの対象外である場合、Dockerを追加してもランタイムが互換性を持つ可能性は低いでしょう。同様に、コンテナがサポートされていないGGUFファイルを自動的に変換したり、アプリケーション自体が提供していないマルチGPUスケジューリングを実現したりすることもできません。

現在の機能を過大に表現せず、責任ある次のステップを選ぶために、以下の判断ガイドを使用してください。

最新情報については、FreeToken GitHubリポジトリとDockerサポートissueを確認してください。これらのリンクは、検証されていないセットアップの断片よりも信頼性があります。プロジェクトの変更、issueの状態、メンテナーの議論を確認できるためです。