FreeToken deploy：ローカルAIセットアップのステップバイステップガイド

FreeToken deployは、コンシューマー向けハードウェア上でオープンウェイトのMixture-of-Expertsモデルを実行するためのローカルAIサービングセットアップです。GPUだけを唯一のリソースとして扱うのではなく、FreeTokenはGPUメモリ、システムRAM、CPUリソース、利用可能なインターコネクト帯域幅を連携させます。この設計により、大規模モデルをデスクトップで扱いやすくなりますが、最終的な使用感はモデルとハードウェア構成に大きく左右されます。

公式のFreeToken GitHubリポジトリでは、このプロジェクトをエッジネイティブなMoEサービングエンジンと説明しています。ランタイムには、帯域幅適応型のCPU–GPU協調実行、ダブルバッファ方式のプリフィルストリーミング、グローバルエキスパートキャッシュ、グラフ互換実行、FTW高速ウェイト形式が含まれています。

動画のハイライト：

• WindowsとLinux向けのデスクトップインストール手順
• 1台の大容量GPUによるローカルモデルの読み込み
• 大規模MoEモデルに必要なシステムRAM
• ブラウザベースのチャットインターフェースへの接続
• 1秒あたりのトークン数を用いた実用的なパフォーマンス確認

デスクトップアプリケーションは、エンジンのセットアップの大部分を処理し、モデルのダウンロード、エンドポイントの起動、チャット、ランタイムオプションの調整をグラフィカルなワークフローで行えるため、最も簡単な開始方法です。コマンドライン方式はより細かな制御が可能で、再現性のあるデプロイ、開発環境、ログを直接確認したいユーザーに適しています。

FreeTokenのデプロイを成功させるうえで最も重要なのは、モデルを利用可能なメモリに合わせることです。1台のGPUでも実用的なローカル推論を実行できますが、選択したモデルがVRAMに完全には収まらない場合、システムRAMが不可欠になります。大規模MoEモデルでは、エキスパートのウェイトとランタイムデータがホストメモリとGPUの間を移動するため、高いメモリ帯域幅の恩恵を受ける場合もあります。

実用的なデプロイ計画では、インストール前に次の4つの値を記録しておく必要があります。

• GPUのVRAM容量とコンピュート性能
• システムRAMの合計容量と利用可能な空きRAM
• RAMの世代と実効メモリ速度
• モデルに想定されるメモリ使用量

基準テストでは1台のRTX 3090を使用し、大規模MoEモデルで対話的なパフォーマンスを確認しましたが、報告された出力速度はアクティブなエキスパートやランタイムの条件によって変化しました。デスクトップ構成とサーバー側構成でも結果が異なったため、ベンチマークの期待値は柔軟に考える必要があります。

テストでは、十分なホストメモリを組み合わせれば、1台の3090で負荷の高いMoEモデルを実行できることが確認されました。同時に、モデル選択が重要であることも示されています。テスト構成では密な27B BF16モデルが起動に失敗した一方、別の大規模モデルではシステムRAMとVRAMを合わせて大幅に多くのメモリが必要でした。

以下の手順は、デスクトップアプリケーションを使った一般的なデプロイ方法です。初回起動では慎重に進めてください。利用可能なメモリに合ったモデルを使用し、不要なバックグラウンド処理を避け、チャットクライアントを開く前にAPIサーバーの準備が完了したことを確認します。

ターミナルでのワークフローを好むユーザー向けに、リポジトリはuvまたはpipによるインストールをサポートしており、開発用にソースからインストールすることもできます。依存関係の変更が他のローカルAIプロジェクトに影響しないよう、環境は分離しておいてください。

FreeTokenのパフォーマンスは、1つの固定値で表せるものではありません。生成速度は、アクティブなエキスパート、モデルアーキテクチャ、プロンプトの長さ、メモリ配置、ランタイム設定によって変化します。基準テストでは、ある構成が対話的なワークロードで毎秒およそ10〜11トークンを出力した一方、別のテスト条件のデスクトップ構成では毎秒約8.8トークンという低い結果になりました。これらは参考例であり、普遍的な保証ではありません。

再現可能なテスト手順を使用してください。

1. 同じモデルを再起動または再読み込みする。
2. 同じ短いプロンプトを送信する。
3. 最初の応答が完了するまで待つ。
4. プロンプト処理と生成の動作を記録する。
5. ハードウェアやインターフェースを比較する前にテストを繰り返す。

ランタイムのキャッシュ動作は、MoEワークロードにおいて特に重要です。エキスパートキャッシュは繰り返しの読み込みを減らせる一方、セマンティック対応キャッシュは、対応するエージェントワークフローでコンテキストの重複再計算を避けるよう設計されています。ただし、キャッシュの動作は利用可能なメモリとワークロードにも左右されます。システムが頻繁にデータを追い出し始めると、生成が安定しなくなる可能性があります。

起動に失敗したからといって、必ずしもインストールに問題があるとは限りません。一般的な原因には、対応していないモデル形式、利用可能なメモリ不足、依存関係の問題、他のアプリケーションによるリソース競合があります。テストしたワークフローではFreeTokenはベータソフトウェアと説明されているため、互換性の問題が発生した場合は、再起動、ログの確認、またはIssueの報告が必要になることがあります。

次のトラブルシューティング表を使って問題を絞り込んでください。

再現性のあるデプロイを行うには、各テストでモデル名、アプリケーションのバージョン、OS、メモリ構成、クライアント設定を保存してください。これにより、モデルの制限とインストールの問題を区別しやすくなります。あるモデルが繰り返し失敗し、別のモデルが正常に起動する場合は、プロジェクトにIssueを報告する前に、生のサーバーログを保存してください。

最も安全なアップグレード方法は、段階的に進めることです。

• 対応している扱いやすいモデルでインストールを検証する。
• チャットとエンドポイントが機能することを確認する。
• メモリを多く使用するモデルを1つずつテストする。
• 各ベンチマークでは、パフォーマンス変数を1つだけ変更する。
• 比較用に、正常に動作する既知のモデルを保持する。

FreeTokenをワンクリックのパフォーマンスプリセットではなく、設定可能なローカル推論エンジンとして扱うことが、最も優れたデプロイ習慣です。現実的なモデルから始め、エンドポイントを確認し、再現可能なプロンプトで測定しながら、システムの限界を理解したうえで段階的に拡張してください。