FreeTokenエッジネイティブMoEサービング：アーキテクチャガイド

FreeTokenエッジネイティブMoEサービングは、一般的なローカルハードウェア上で非常に大規模なmixture-of-experts（MoE）言語モデルを実行するための研究システムです。限られたGPUメモリを自動的に障害とみなすのではなく、グラフィックスプロセッサ、中央処理装置、ホストメモリ、利用可能なインターコネクトの間で処理を分担します。

中心となる考え方は、リソースのオーケストレーションです。一般的なコンシューマー向けコンピューターには高性能なGPUが搭載されていても、最先端規模のモデルを収めるのに十分なグラフィックスメモリがない場合があります。すべての処理を同じ低速な経路で移動させると、停止時間が発生します。FreeTokenはその代わりに、帯域幅、キャッシュ状態、推論の現在のフェーズに応じて実行を適応させます。

このプロジェクトは、2026年8月17日にFreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive ExecutionというタイトルでarXivに公開されました。記載された著者には、Shuo Yang、Xiaoze Fan、Melissa Pan、Haocheng Xi、Zhe Wang、Shanlin Sun、Kurt Keutzer、Song Han、Matei Zaharia、Chenfeng Xu、Ion Stoicaが含まれます。

動画のハイライト：

• 大規模MoEモデルをCPUとGPUのリソースに分散できます。
• プリフィルでは、転送、計算、チェックポイント作成をオーバーラップさせます。
• デコードでは、キャッシュミスが発生した際にエキスパートのロード方法を適応させます。
• 報告されたテストは、8 GBのノートパソコンから96 GBのワークステーションまで対象としています。
• エージェントワークロードでは、より高速なデコードと応答開始までの短縮による恩恵が得られます。

FreeTokenは、推論をプリフィルとデコードという2つの重要なフェーズに分けます。プリフィルは入力コンテキストを処理し、デコードは新しいトークンを1つずつ生成します。これらのフェーズでは性能上の課題が異なるため、両方に1つの固定スケジューリングポリシーを使用すると、ハードウェアを十分に活用できない可能性があります。

プリフィル中、システムはフルレイヤー・ダブルバッファリングを使用します。モデルの一部分を計算している間に、別の部分を転送または準備できます。この構成は、エキスパートの重みをGPUメモリに恒久的に常駐させられない場合に特に重要です。

システムは、特別なトークンアンカーに状態チェックポイントも保持します。エージェントのワークフローでは、ユーザーやツールが会話の一部を編集することがあります。編集のたびにプロンプト状態全体を再構築する代わりに、チェックポイントによって再利用可能な計算を保持し、繰り返し行われるプリフィル処理を削減できます。

デコード段階では、別の戦略を使用します。アクティブキャッシュにエキスパートが存在しない場合、FreeTokenはインターコネクト経由でそのエキスパートをロードする処理と、CPU上でインプレースに実行する計算のバランスを取ることができます。このポリシーは、一方が有用な処理を継続できるときに、他方がアイドル状態にならないよう設計されています。

この違いが重要なのは、MoEモデルがすべてのトークンに対してすべてのエキスパートを有効化するわけではないためです。システムは必要なエキスパートを特定し、それらがどこで利用可能かを確認したうえで、処理を移動する方が効率的か、ローカルで処理する方が効率的かを選択する必要があります。

FreeTokenは、理想化された1台のマシンではなく、さまざまなローカル構成で評価されました。報告されたテスト範囲は、8 GBのノートパソコンから96 GBのワークステーションに及びます。これらのシステムでは、ホストメモリ帯域幅とインターコネクト性能が大きく異なるため、適応型スケジューリングが重要になります。

ある小型ノートパソコンの構成では、インターコネクト帯域幅が毎秒12 GB未満でした。一方、最も高性能なワークステーション構成では、CPUメモリ帯域幅が毎秒178 GBに達しました。こうした違いは、エキスパートをGPUへ移動するべきか、CPUで処理するべきか、後で使用するためにキャッシュへ保持するべきかに影響します。

報告された結果は、ワークロードとハードウェアによって異なります。あるノートパソコン構成では、FreeTokenは7530億パラメータモデルをサービングしながら、毎秒40トークン近くに達しました。ワークステーションでは、同じ大まかなテストカテゴリでそのモデルが毎秒約15トークンに達し、比較対象のサービングエンジンの約2倍のスループットと報告されました。

RTX 5090デスクトップでは、報告されたテストにおいてコーディングエージェントのワークロードが毎秒76トークンを超えました。大規模モデルを使用した別のワークロードでは毎秒22トークンを超え、別のモデルでは毎秒80トークンを超えました。これらの数値は、すべてのデバイスに適用される保証値ではなく、特定の構成、モデルのバリエーション、ワークロードに基づくベンチマーク結果として解釈してください。

キャッシュは、FreeTokenにおける最も重要な性能メカニズムの1つです。MoE推論では選択されたエキスパートが有効化されるため、適切なキャッシュによって転送の繰り返しを防げます。配置ポリシーが不適切だとミスが増加し、都合の悪いタイミングでデータの移動や再計算が必要になります。

報告された評価では、LRU（Least Recently Used）キャッシュポリシーと、静的配置およびプリフィルベースの配置戦略が比較されています。FreeTokenのLRUポリシーは、テストされたモデル全体でエキスパートキャッシュミスを大幅に削減しました。このアプローチは変化するワークロードに対して直感的です。最近使用されたエキスパートは、近接するデコードステップでも引き続き有用である可能性が高い一方、ワークロードの挙動は変化する場合があります。

長いプロンプトでは、テストされた構成において、16,000トークンのコンテキストでプリフィルスループットが毎秒6,600トークンを超えたと報告されています。ダブルバッファリングされたパイプラインは、非パイプライン実行およびベースラインシステムと比較され、報告された測定ではオーバーラップ構成がより高いスループットを示しました。

実践的なチューニングの順序は、システムのアーキテクチャに従います。

• 固定配置を選択する前に、ホストメモリ帯域幅とインターコネクトの挙動を測定する。
• ボトルネックが異なるため、プリフィルの分析とデコードの分析を分ける。
• モデル全体のサイズだけで性能を判断せず、エキスパートキャッシュミスを監視する。
• プロンプトを繰り返し編集するエージェントワークフローでは、再利用可能な状態を保持する。
• 実際のワークロードにおけるCPU側の実行コストと転送コストを比較する。

FreeTokenは、エッジネイティブなモデルサービングに関心を持つ研究者、インフラエンジニア、高度なローカル推論ユーザーに特に関係があります。報告されたエージェントワークロードにはコーディング関連のタスクが含まれており、初回トークンまでの時間と持続的なデコード速度の両方が使いやすさに影響します。

このシステムは、大規模MoEモデルのサービングがメモリ容量だけの問題ではないことも強調しています。メモリは依然として重要ですが、データ保存場所間の経路、ホスト計算の速度、キャッシュの挙動、スケジューリングの判断によって、利用可能なハードウェアを効率的に使えるかどうかが決まります。

注目されたRTX 5090エージェントテストでは、報告された初回トークンまでの時間は数秒以内に収まりました。一方、比較システムではさらに長い時間を要したり、正常に完了しなかったりする場合がありました。この指標はデコードスループットとは異なります。システムによっては開始が遅くてもその後すばやくトークンを生成することがあり、逆に開始は速くても出力速度が低いままになる場合があります。

FreeTokenを使用しても、適切なハードウェア、モデルのサポート、慎重な評価が不要になるわけではありません。性能は、メモリ容量、帯域幅、インターコネクト速度、モデル構造、プロンプト長、サービングワークロードの挙動に依存します。公開資料も、普遍的な互換性リストではなく、研究上の評価について説明しています。

技術読者にとっての主要な参考資料は、FreeToken arXiv論文です。この論文は分散・並列・クラスタコンピューティング分野のarXiv:2608.16157として掲載されています。2026年8月に公開されたこの論文は、実装の詳細、実験方法、著者が用いる正式な用語を確認するための適切な出発点です。