FreeToken llama：ローカルMoEのセットアップガイドとヒント

FreeToken llamaは、単独のLlama製品名というよりも、ローカル推論に関する検索語として理解するのが適切です。FreeTokenは、一般向けハードウェア上でフロンティア規模のオープンウェイトMixture-of-Expertsモデルを実行するために設計された、エッジネイティブなサービングエンジンです。このプロジェクトは、GPU計算、CPU実行、ホストメモリ、インターコネクト帯域幅を1つの推論プラットフォームに統合します。

公開されているプロジェクト情報から、すべてのLlamaファミリーモデルが普遍的にサポートされているとは判断できません。Llamaの互換性はモデルごとに確認すべき事項として扱い、セットアップを決める前にアーキテクチャ、ウェイト形式、トークナイザー、コンテキストの挙動、サポートされるランタイム経路を確認してください。これにより、モデルファミリーとサービングエンジンを混同することを避けられます。

FreeTokenの公式プロジェクトページでは、WindowsおよびLinux向けのデスクトップアプリケーションに加え、uvまたはpipを使用したコマンドラインインストールについて説明されています。同ページでは、帯域幅適応型のCPU–GPU協調実行、ダブルバッファリングによるPrefillストリーミング、グローバルLRUエキスパートキャッシュ、グラフ互換実行、FTW高速ウェイト形式などの機能も紹介されています。

主な用語：

公式プロジェクト概要： GitHub上のFreeToken

FreeTokenは、大規模MoE推論における中心的な問題に対応します。完全なモデルは利用可能なグラフィックスメモリよりはるかに大きい場合がありますが、各トークンが有効化するのはエキスパートの一部だけです。そのためランタイムは、どのウェイトをGPU上に保持し、どれをホストメモリに置き、どれをCPU上で直接実行するかを判断する必要があります。

Prefill中は、多数のプロンプトトークンが広範囲のエキスパートに集約的にアクセスします。FreeTokenは、次のレイヤーを転送している間に現在のレイヤーを計算できるよう、レイヤー全体を対象としたダブルバッファリングストリーミングを使用します。このオーバーラップ処理により、すべての転送が順番に完了するのを待つのではなく、データ移動のコストの一部を算術処理の背後に隠すことを目指します。

Decode中は、アクセスパターンが疎で対話的になります。静的なエキスパート配置では頻繁に要求されるエキスパートを取り逃す可能性があるため、FreeTokenはグローバルLRUエキスパートキャッシュを維持します。帯域幅適応型ポリシーは、GPUへの補充とCPU実行の実際のバランスを測定し、より早く完了すると予想される経路に応じてキャッシュミスを振り分けます。

このプロジェクトでは、エージェント型コンテキスト向けのセマンティック対応キャッシュも挙げられています。ツール呼び出し、思考ブロック、その他のコンテキスト編集が発生した場合、セマンティックアンカーチェックポイントによって、変更されていないコンテキストの再計算を回避できる可能性があります。これは、短いプロンプトを一度だけ処理する場合よりも、長時間継続する対話型ワークロードで特に重要です。

動画のハイライト：

• FreeTokenはPrefillとDecodeを異なる帯域幅問題として分離します。
• エキスパートの配置とキャッシュミスは、対話時の応答時間に影響します。
• ローカルハードウェアによって、利用可能なGPUメモリを超えるサイズのモデルをサービングできます。
• エージェントセッションでは、平均速度だけでなく最悪時のターン遅延が重要です。

FreeTokenは異種の一般向けシステム向けに設計されているため、容量計算においてGPUメモリは一要素にすぎません。システムRAMはモデルウェイト用の追加領域を提供し、CPU実行性能とメモリプール間のリンクは、不足しているエキスパートをどれだけ速く供給できるかに影響します。

プロジェクト資料では、特定のテスト構成において、8 GBのノートPC用GPUで350億パラメータモデルを約39トークン/秒でサービングできると報告されています。また、1台のワークステーションGPU上で7530億パラメータモデルを約15トークン/秒近くで実行した結果も報告されています。これらは参考値であり、すべてのLlamaチェックポイント、オペレーティングシステム、量子化方式、プロンプト、ハードウェア構成に対する保証ではありません。

同じパフォーマンスの議論では、テールレイテンシも重視されています。4種類の対話型エージェントワークロードでは、引用された比較においてFreeTokenの最も遅いターンは44秒未満に収まりました。一方、ベースライン構成では、テスト中に少なくとも150秒に達するケースがありました。あるベースラインでは、1ターンだけで946秒を要しました。これらの数値は特定の実験条件に基づくものであり、普遍的なベンチマークとして扱うべきではありません。

Llamaファミリーを試す場合は、正確なチェックポイント、形式、コンテキスト長、量子化またはウェイト表現、GPU、システムメモリ、ランタイムのバージョンを記録してください。これらの詳細がなければ、比較結果は誤解を招く可能性があります。局所性に優れた小さなモデルのほうが、低速なリンクを介してコールドエキスパートを何度も移動させる大きなモデルより、応答性が高く感じられることもあります。

以下のワークフローを使って、曖昧なモデルのアイデアから、制御されたローカルテストへ進めてください。この手順は意図的に慎重な順序になっています。まずエンジンを検証し、次にモデルのサポートを確認してから、パフォーマンスを調整します。

実用的な初回テストには、短い会話型プロンプトと、想定するワークロードに近い長めのプロンプトの両方を含めるべきです。短いプロンプトでは基本的な起動挙動が分かり、長いプロンプトではPrefillストリーミングとコンテキスト処理を検証できます。システムでツールを使うエージェントをサポートする場合は、単一の完了結果だけに頼らず、コンテキスト編集を含む複数ターンをテストしてください。

FreeToken llamaのセットアップが遅く感じられる場合は、問題が読み込み、Prefill、Decodeのどの段階で発生しているかを確認してください。各段階は異なるボトルネックを示します。起動に時間がかかる場合は、ストレージまたは初期ウェイト転送が原因であることが多く、初回応答が遅い場合はプロンプト処理やレイヤー転送が関係している可能性があります。トークン生成が不規則な場合は、キャッシュミス、CPUフォールバック、メモリ圧迫、サーマルスロットリングなどが考えられます。

平均速度だけを対象に最適化することは避けてください。単純なプロンプトには高速に応答できても、長いエージェントターンで停止する構成は、実際の利用には適さない可能性があります。FreeTokenのアーキテクチャは最悪時の対話挙動を明確に重視しているため、反復的で複合的なワークロードのほうが適切な評価になります。

一般的な調整の優先事項：

• ストリーミングされるモデルウェイトとランタイム状態のために、十分なシステムメモリを確保する。
• アプリケーションで履歴全体が不要な場合は、不要なコンテキストを減らす。
• 独立したプロンプトだけでなく、キャッシュの影響を受ける会話をテストする。
• 実際のマシン上でCPUフォールバックとGPU補充の挙動を比較する。
• 生成直後の数トークンではなく、持続的なパフォーマンスを監視する。
• 複数の設定を変更する前に、正常に動作する構成を保存する。

研究上の背景として、このプロジェクトでは論文 「FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution」 を紹介しています。引用情報は公式リポジトリと、リンク先のarXiv論文レコードから確認できます。リポジトリでは、SGLang、vLLM、FlashInfer、LightLLM、llama.cppなどのプロジェクトから得た着想や、再利用された設計アイデアについても謝辞が述べられています。