FreeToken 1秒あたりのトークン数：2026年ベンチマークガイド

FreeTokenの1秒あたりのトークン数は、プロンプト処理後にローカルで提供される言語モデルが出力を生成する速度、つまりデコードスループットを表します。これは、初回トークンまでの時間、プロンプト処理速度、合計応答時間とは異なります。インタラクティブなチャットでは、回答が表示されている間にユーザーが通常実感するのがデコードスループットです。

FreeTokenは、大規模なMixture-of-Expertsモデル向けのエッジネイティブなサービングシステムです。その設計では、エキスパート全体をホストメモリに保持し、利用可能なGPUメモリを柔軟なエキスパートキャッシュとして使用します。その結果、性能はグラフィックスカードだけでなく、マシン全体に依存します。

動画のハイライト：

• 単一のRTX 3090環境で、約10～11デコードトークン/秒を生成しました。
• 後のテストでは、デスクトップクライアントが約8.8トークン/秒を報告しました。
• システムRAMの容量と帯域幅が、主要な性能要因として確認されました。
• バックグラウンドアプリケーションは、使用可能なVRAMを減らし、スループットに影響する可能性があります。

公開されているFreeTokenの研究論文では、システムが測定されたホストメモリとPCIeの帯域幅に応じて実行方法を適応させることが説明されています。同じGPUを搭載した2台のコンピューターでも、結果に明確な差が生じるのはこのためです。

利用可能なテストでは、サーバー側とデスクトップクライアントの測定値に実用上の差があることが示されています。単一のRTX 3090では、通常のチャットプロンプトでDeepSeek V4 Flashが毎秒10～11トークン付近を維持しました。別のデスクトップクライアントの実行では、毎秒8.8トークンが報告されました。これらの数値は参考値として有用ですが、普遍的な評価値ではありません。

この差は、クライアントのオーバーヘッド、OSの挙動、モデル設定、バックグラウンドプロセス、測定のばらつきなどから生じる可能性があります。思考モードもワークロードを変化させます。最大限の推論で生成された回答は、短く直接的な回答と比べて、表示上の出力速度が低くなり、完了までの経路が長くなる場合があります。

研究評価で新しいハードウェアの結果が高くなっているのは、最適化されたサービングランタイム、測定された帯域幅スケジューリング、特定のベンチマーク条件が使用されているためです。これらの数値を、そのまま一般的なデスクトップ環境の推定値として使用しないでください。

有効な比較方法は、各構成で同じモデル、プロンプト形式、コンテキストサイズ、生成設定を使ってテストすることです。1回の完了結果だけに頼らず、複数の応答を記録してください。MoEのルーティングはトークンごとに変化するため、個々の結果にはばらつきが生じます。

FreeTokenでは、性能に関する議論の多くが、GPUの生の計算能力からメモリ転送へと移ります。Mixture-of-Expertsモデルは、各トークンでパラメータの一部だけを有効化しますが、エキスパート全体をシステムメモリ上で利用可能な状態に保つ必要がある場合があります。エキスパートがGPUにキャッシュされていない場合、ランタイムはPCIe経由で転送するか、CPU上で直接実行できます。

そのため、システムメモリの容量が不可欠になります。テストでは、一部のローカル構成では32GBが開始点になり得る一方、64GBあればより余裕を持てることが示されています。より大きなモデルでは、さらに多くのメモリが必要になる可能性があります。研究資料では、特に最先端規模のモデルについて、数百GBのホストメモリを必要とする構成が説明されています。

研究論文では、エキスパート転送におけるプラットフォームレベルの差が概算されています。PCIe 4.0 x16を使用するRTX 4090およびRTX 3090クラスのシステムでは、プリフィル中に大規模なエキスパートセットを移動するのに数秒かかることがあります。一方、より狭いノートPC向けリンクではさらに時間がかかる可能性があります。デコード時の挙動は異なり、キャッシュとCPUの同時実行によって転送コストの一部が隠れる場合があります。

クリーンなテスト環境も重要です。不要なGPU負荷の高いソフトウェアを終了し、複数のモデルサービスを同時に実行することを避け、OS用に十分なRAMを確保してください。ランタイムがRAMまたはVRAM不足を報告している場合、1秒あたりのトークン数への期待値を下げてもロード問題は解決しません。まずモデル構成がリソース内に収まる必要があります。

この手順を使って、信頼できるローカル環境のベースラインを測定してください。目的は、一時的に非常に高い数値を追いかけることではなく、変化の原因を説明できる再現可能なテストを作ることです。

デスクトップクライアントとサーバー接続インターフェースを比較する場合は、それぞれを分けてテストしてください。利用可能な結果からは、デスクトップ経路は便利である一方、測定値が低くなる可能性が示唆されています。これは、すべてのワークロードでモデルが自動的に遅いという意味ではありません。インターフェースとランタイム経路を記録すべきだという意味です。

FreeTokenの最大の強みは、GPUメモリ、ホストメモリ、CPU実行、PCIe転送を連携させることにあります。そのため、実用的なチューニングでは、モデルを変更したり高い出力速度を期待したりする前に、回避可能なリソース競合を取り除くことが重要です。

利用可能なテストでは、ソフトウェアの成熟度も考慮すべき要素として挙げられています。FreeTokenはベータ版ソフトウェアと説明されており、テスト中にある密モデルのQwen構成が予期せず終了しました。モデルの起動失敗は、1秒あたりのトークン数の結果ではなく、互換性またはリソースの問題として扱うべきです。

トラブルシューティングでは、ログを確認し、モデルが対応している形式を検証し、OSや他のアプリケーションの使用分を考慮したうえで利用可能なメモリを確認し、ランタイムを再起動してテストを繰り返してください。1回の起動失敗を、すべてのモデル構成に互換性がない証拠だと解釈しないでください。