- FreeTokenのリリースでは、大規模MoEモデル向けのエッジネイティブなサービングシステムが導入されます。
- 最大の利点:動的なエキスパートキャッシングにより、GPU、CPU、ホストメモリ、PCIe帯域幅を組み合わせます。
- 最適な用途:十分なシステムメモリを備えた比較的新しいNVIDIAシステムでのMoEワークロード。
- 主な制限:2026年版はベータ開発を重視しており、主にCUDA対応Linuxを対象としています。
- 要点:エンジンを切り替える前に、ハードウェア対応状況とベンチマーク上の注意点を確認してください。
FreeTokenリリース:2026年に変わったこと
2026年のFreeTokenリリースは、フロンティア規模のMixture-of-Expertsモデルを個人用ハードウェアでより実用的に動作させるために設計されたローカル推論エンジンを提供します。すべてのエキスパート重みをGPUメモリに保持する代わりに、システムはエキスパートプール全体をホストメモリに保持し、利用可能なVRAMを柔軟なキャッシュとして使用します。
プロジェクトの研究論文FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Executionは、2026年8月24日に公開されました。この論文では、このリリースを新しいモデルではなくサービングシステムとして位置付けています。その目的は、既存のオープンウェイトMoEモデルをコンシューマー向けハードウェア上で読み込み、キャッシュし、実行する方法を改善することです。
動画のポイント:
- FreeTokenは、非常に大きなパラメータ数を持つモデルのローカルサービングを対象としています。
- 動的ルーティングによって、GPUメモリに保持すべきエキスパートを決定します。
- CPU実行とPCIe転送は、測定された帯域幅に応じてバランス調整されます。
- 報告された結果には、ノートパソコン、デスクトップ、ワークステーション級のハードウェアが含まれます。
MoEサービング
- スパースルーティングにより、トークンごとに少数のエキスパートサブセットだけがアクティブになります。
- エキスパートプール全体はホストメモリで利用可能な状態に保たれます。
- ローカルVRAM容量を超えるモデルに有効です。
適応型キャッシュ
- 共有LRUキャッシュが、最近ルーティングされたエキスパートを追跡します。
- キャッシュ容量は実行中に変更できます。
- PrefillとDecodeは同じエキスパートメモリプールを共有します。
ハイブリッド実行
- キャッシュにないエキスパートはGPUへ転送できます。
- その他のキャッシュミスはCPU上で直接実行できます。
- 振り分けは、測定されたホスト側およびPCIeの帯域幅に従って行われます。
FreeTokenはモデルのリリースではなく、推論ランタイムのリリースとして捉えてください。利用するには、互換性のあるモデル重み、対応ランタイム環境、そしてエキスパートプール全体を保持するのに十分なホストメモリが必要です。
| リリース領域 | 2026年の方向性 | 重要な理由 |
|---|---|---|
| モデル対応 | およそ35B~753BパラメータのMoEモデル | 一般的なVRAM容量を超えるモデルへのローカルアクセスを拡大 |
| メモリ設計 | ホスト常駐エキスパートプールと柔軟なGPUキャッシュ | GPU容量は基本的な動作可否よりも速度に大きく影響 |
| スケジューリング | 帯域幅適応型のCPU/GPU実行 | 避けられないキャッシュミスの影響を軽減 |
| Prefill | レイヤー全体のダブルバッファリング | エキスパートの移動とGPU計算をオーバーラップ |
| 提供状況 | ベータ指向のCUDAおよびPOSIX Linuxターゲット | インストール前にプラットフォーム対応を確認する必要がある |
FreeTokenのアーキテクチャの仕組み
FreeTokenは推論を、PrefillとDecodeという2つの重要なフェーズに分けます。Prefillは既存のプロンプトや会話コンテキストを処理し、Decodeは新しいトークンを1つずつ生成します。各フェーズには異なるボトルネックがあるため、ランタイムもそれぞれ異なる手法を使用します。
Prefillでは、長いコンテキスト全体で多数のエキスパートにアクセスする可能性があります。FreeTokenはレイヤー全体のダブルバッファリングを使用し、GPUが現在のレイヤーを処理している間に、次のレイヤーのエキスパートをストリーミングします。これにより、転送時間の一部を計算処理の裏に隠せます。また、思考セグメント、ツール呼び出し、会話ターンなどの意味的な境界にチェックポイントを保存します。エージェントがコンテキストを編集した場合、変更された末尾部分だけを再計算すればよい可能性があります。
Decodeではルーティングはスパースですが、トークンごとに変化します。起動時に選択した静的な配置では、アクティブなエキスパートを頻繁に見逃す可能性があります。そこでFreeTokenは、レイヤーをまたいだ最近のルーティング動作に追従する共有LRUキャッシュを使用します。
| ランタイムフェーズ | 主な課題 | FreeTokenの対応 |
|---|---|---|
| Prefill | 大量のエキスパート移動とコンテキストの再計算 | レイヤー全体のパイプライン処理と意味状態チェックポイント |
| Decode | 変化するエキスパート経路とキャッシュミス | 共有LRUエキスパートキャッシュ |
| キャッシュミス | 転送とCPU実行がホスト帯域幅を競合 | 測定帯域幅に基づく振り分け |
| メモリ圧迫 | アプリケーションやコンテキストの増加に伴うVRAMの変化 | ランタイム中のキャッシュサイズ調整 |
| 起動 | 大規模なエキスパートプールの読み込みに時間がかかる | 最終的なホストレイアウトへの直接読み込み |
帯域幅ポリシーは、このリリースを特徴づける主要なアイデアの1つです。Bₚを測定されたPCIe転送帯域幅、Bₕをホスト側での実効エキスパート処理帯域幅とします。ランタイムは、キャッシュにないエキスパートのうち、GPUキャッシュへ転送すべき数とCPU上で直接実行すべき数を推定します。
このアプローチでは、すべてのキャッシュミスを転送として扱うことを避けます。エキスパートを後続トークンのためにキャッシュへ残せるため、転送が有効な場合もあります。一方で、ホスト帯域幅に余裕がある場合やキャッシュ容量が限られている場合は、CPU実行の方が高速になる可能性があります。
スパースアクティベーションによってトークンごとの計算量は減りますが、エキスパートプール全体をアクセス可能な場所に保存する必要がなくなるわけではありません。大規模モデルでは、依然として相当量のホストメモリとストレージが必要になる可能性があります。
エキスパートプールを読み込む
FreeTokenは正規化されたエキスパート重みをホストメモリへ読み込みます。FTW形式は、サービング時に使用するレイアウトへ重みを直接配置できるよう設計されており、起動時の検出や再パッキング作業を削減します。
GPUキャッシュを確保する
エキスパート以外の重みとランタイム状態を確保した後、残ったVRAMをKVキャッシュと完全なエキスパートスロットに分配します。この予算は、安全なランタイム時点で見直すことができます。
コンテキストをPrefillする
レイヤー全体のバッファリングによって、GPUが計算している間にエキスパートデータをストリーミングします。意味的なチェックポイントにより、エージェントのターンやコンテキスト編集をまたいで有用なプレフィックスを保持します。
ルーティング対応キャッシュでDecodeする
ルーターがアクティブなエキスパートを特定し、GPU上の常駐状況を確認します。キャッシュミスは、帯域幅適応型のCPU経路またはPCIe経路へ送られます。
性能結果とハードウェアの適合性
報告された2026年の評価では、6台のマシンと複数のエージェント型ワークロードを用いて、FreeTokenと現在も積極的に保守されているエッジサービングエンジンを比較しています。結果は、最新のNVIDIA GPU、十分なホストメモリ、そしてCPUメモリ帯域幅とPCIe転送容量のバランスが取れたシステムで最も優れています。
RTX 5090では、Qwen3.6-35Bで毎秒77~83トークン、DeepSeek-V4-Flashで毎秒22~25トークンを報告しています。8 GB構成のRTX 4060ノートパソコンでは、Qwen3.6の報告結果は毎秒39.3トークンに達します。ワークステーション級のRTX PRO 6000では、GLM-5.2を毎秒14.9トークンで処理しており、比較対象として示されたllama.cpp構成の7.3と比べて高い結果です。
| ハードウェア層 | 実証ワークロード | 報告結果 | 実用上の見方 |
|---|---|---|---|
| RTX 4060ノートパソコン、8 GB | Qwen3.6-35B | 39.3 tok/s | VRAMが限られた環境で適応型サービングの価値を示す |
| RTX 5090デスクトップ/サーバー | Qwen3.6-35B | 77~83 tok/s | 報告されたコンシューマー層で最も強い結果 |
| RTX 5090デスクトップ/サーバー | DeepSeek-V4-Flash | 22~25 tok/s | 大規模なエキスパートプールでもローカル運用が可能 |
| RTX PRO 6000、96 GB | GLM-5.2 | 14.9 tok/s | 753Bパラメータのフロンティア規模層を実証 |
| RTX PRO 6000、96 GB | llama.cppとの比較 | 7.3 tok/s | 同等の重みを用いたベースライン結果 |
テールレイテンシーも重要です。評価では、テストされた条件におけるFreeTokenの最も遅いターンが44秒未満に収まった一方、ベースラインシステムでは一部のケースで大幅に長い遅延を超えたと報告されています。エージェントアプリケーションでは、クライアントのウォッチドッグやタイムアウトに割り込まれる前にリクエストを完了できるかどうかに影響します。
ただし、ベンチマークは適切な注意を払って読む必要があります。測定は論文の著者によって実施されており、利用可能な資料からは広範な第三者による再現性は確認できません。また、特にDecodeスループットとエンドツーエンドの本番トレースを比較する際には、測定の定義に注意が必要です。
FreeTokenは、比較的新しいNVIDIA GPU、十分なシステムメモリ、大規模MoEモデルを繰り返しサービングするワークロードで最も大きな価値を発揮します。見出し上のトークン速度よりも、ハードウェアの互換性が重要です。
| ハードウェア要素 | 好ましい条件 | 懸念事項 |
|---|---|---|
| GPU | 比較的新しいCUDA対応NVIDIAカード | 古いカードではテスト済みまたはパッケージ化された経路が利用できない可能性がある |
| VRAM | エキスパート以外の重み、KVキャッシュ、エキスパートスロットを格納できる容量 | VRAMが少ないとキャッシュミスが増加 |
| ホストメモリ | エキスパートプール全体を収容できる容量 | 大規模モデルでは一般的なデスクトップのメモリ容量を超える可能性がある |
| PCIe | 広帯域幅の広いリンク | ノートパソコンのx8リンクや低速なリンクでは転送負荷が増加 |
| CPUメモリ | 高性能なデュアルチャネルDDR5以上 | CPU側の実行が帯域幅の制約を受ける可能性がある |
| オペレーティングシステム | CUDA対応のPOSIX Linux | macOSおよび広範なWindows対応は確立されていない |
サポート状況、制限、セットアップ時の確認事項
2026年のリリースは、初期段階のシステムとして扱うべきです。公開されている分類情報では、ベータ開発状況、CUDA環境、POSIX Linuxオペレーティングシステムが示されています。利用可能なプラットフォーム資料からは、Apple Silicon向けのネイティブビルド、広範なmacOSサポート、成熟したエッジランタイムに匹敵するハードウェア対応範囲は確認できません。
プロジェクトが示す方向性には、FTW重み形式、CUDA互換カーネル、CPU SIMD実装、そしてピン留めメモリやDMA登録が利用できない場合の純粋なCPUによるMoEバックエンドが含まれます。これらの機能は柔軟性を高めますが、すべてのオペレーティングシステムやグラフィックスカードで同等の性能を保証するものではありません。
FreeTokenをテストする前に確認すること:
- GPUとCUDA環境が対応ランタイム経路に一致していることを確認する
- 利用可能なホストメモリをモデルのエキスパートプール全体と照らし合わせて測定する
- 性能を見積もる前に、PCIeのレーン幅とホストメモリ帯域幅を確認する
- エキスパート以外の重みと増加するKVキャッシュに十分なVRAMを確保する
- エンジンを比較する際は、同一の重みとワークロードを使用する
リリースの詳細、実装上の注意点、対応構成については、FreeToken公式プロジェクトページと2026年の研究論文を主要な参照先として利用してください。
| 確認項目 | 推奨アクション | 理由 |
|---|---|---|
| インストール先 | テスト済みのLinux CUDAマシンを優先する | リリース資料で最も明確にサポートされている環境であるため |
| モデル形式 | モデルに互換性のある、または変換可能なレイアウトがあるか確認する | FreeTokenは正規化されたエキスパートバンクとFTWストレージを使用するため |
| メモリ計画 | エキスパートプール、KVキャッシュ、同時実行アプリケーションを考慮する | エッジシステムではメモリ予算が変動するため |
| ベンチマーク方法 | プロンプト、重み、ワークロードトレースを再利用する | エージェントの軌跡が異なると比較結果が歪む可能性があるため |
| 信頼性テスト | 平均スループットだけでなくテールレイテンシーを測定する | 長い停止がクライアントのウォッチドッグやタイムアウトを引き起こす可能性があるため |
最初の評価では、ホストメモリの予算に収まるモデルと、短時間の管理されたワークロードから始めてください。起動時間、最初のトークンまでの時間、安定時のDecode速度、キャッシュの挙動、最も遅いターンのレイテンシーを記録します。その後、通常のデスクトップアプリケーションを実行しながらテストを繰り返し、負荷がかかった状態で柔軟なメモリ管理がどのように動作するかを確認してください。
2026年にFreeTokenを使うべき人
FreeTokenは、あらゆるローカル推論エンジンを置き換える万能なソリューションではありません。適したNVIDIAハードウェアを所有し、MoEモデルを扱い、ローカルでの制御、予測可能な可用性、ホスト型推論への依存低減を重視する技術に精通したユーザーや小規模チームに最も適しています。
プラットフォームの広さを優先する場合、このシステムは適さない可能性があります。Apple Silicon、古いNVIDIAカード、CUDA非対応デバイスに依存するユーザーや、簡単なクロスプラットフォームインストールを必要とするユーザーは、移行に時間をかける前に対応状況を確認してください。
非常に適している
- 比較的新しいNVIDIA GPU
- 大容量のホストメモリ
- 頻繁なMoEサービング
- エージェント型またはマルチターンのワークロード
適する可能性がある
- 限られたVRAM
- 高速なPCIeリンク
- 最新のDDR5システム
- ローカルでベンチマークする意思がある
あまり適していない
- Apple Siliconへの依存
- 古いGPUハードウェア
- 少ないシステムメモリ容量
- 洗練された汎用インストーラーが必要
評価の優先事項
- 最初に互換性を確認する
- テールレイテンシーを比較する
- メモリ圧迫を監視する
- ワークロードの精度を検証する
このリリースのより広い意義は、アーキテクチャにあります。GPUメモリだけを単独で評価するのではなく、コンシューマー向けハードウェアを統合されたシステムとして扱います。エキスパートキャッシュ、CPUとの協調実行、意味的チェックポイント、ランタイムでのメモリ調整によって、専用データセンターの外で大規模なスパースモデルを利用可能にするという同じ問題の異なる側面に対応しています。
まず互換性を確認し、次にメモリ容量を確かめ、短時間のワークロードを測定してから、最後にスループットを比較してください。これにより、印象的なベンチマーク値が使いものにならないデプロイ経路を覆い隠すことを防げます。
Q: 2026年のFreeTokenリリースとは何ですか?
公開されたFreeTokenのエッジネイティブMoEサービングシステムと、それに付随する2026年8月24日の研究リリースを指します。FreeTokenは新しい言語モデルではなく、推論ランタイムです。
Q: FreeTokenはどのようなハードウェアを対象としていますか?
文書化された経路では、主にNVIDIA CUDAシステムを対象としており、コンシューマー向けノートパソコン、デスクトップ、ワークステーション級GPUが含まれます。利用可能なリリース資料では、LinuxおよびPOSIX環境が最も明確なサポート方針です。
Q: なぜFreeTokenはGPUメモリより大きなモデルをサービングできるのですか?
エキスパートプール全体をホストメモリに保持しながら、選択されたエキスパートを柔軟なGPUキャッシュへ移動するか、CPU上で直接実行します。スパースMoEルーティングでは各トークンで一部のエキスパートだけがアクティブになりますが、プール全体を保存する必要はあります。
Q: FreeTokenはすべてのローカル推論エンジンより高速ですか?
2026年の論文では、選定されたエッジサービングのベースラインに対して優れた結果が報告されています。ただし、これらの測定はプロジェクトの著者によるものであり、自分のハードウェアとワークロードで独自にテストする必要があります。