FreeToken github moe：セットアップガイドとMoEランタイム比較

FreeTokenは、個人向けハードウェア上で大規模なmixture-of-experts（MoE）モデルを提供するために設計されたエッジ推論エンジンです。「FreeToken github moe」を検索する際に重要なのは、FreeTokenがサービングソフトウェアであり、新しい言語モデルではないという点です。対応するチェックポイントを読み込み、推論中のGPU、CPU、システムメモリ、PCIe接続を調整します。

このシステムは、総パラメータ数が利用可能なVRAMを大幅に上回るモデルを対象としています。MoEモデルは、各トークンに対して一部のエキスパートだけを有効化するため、トークン単位の計算量を現実的な範囲に抑えられます。しかし、エキスパート全体は依然としてメモリ上のどこかに保持する必要があります。FreeTokenはエキスパート全体をホストメモリに保持し、VRAMを適応型エキスパートキャッシュとして利用します。

動画のハイライト：

• FreeTokenは、大規模なMoEモデル向けの特化型llama.cpp代替として位置づけられています。
• 報告されたテストには、Qwen3.6-35B-A3B、DeepSeek-V4-Flash、GLM-5.2が含まれます。
• このランタイムは、長時間にわたるコーディングエージェントやツール呼び出しのセッション向けに設計されています。
• 必要なハードウェアは、VRAM、システムRAM、CPU帯域幅、PCIe帯域幅によって異なります。

FreeTokenの研究論文では、3つの主要な仕組みが説明されています。

この論文では、残りの重みがシステムメモリに収まることを条件に、FreeTokenが8 GBのノートPC向けGPU上で350億パラメータクラスのモデルを提供できると報告されています。これは、モデルに必要な総メモリが8 GBだけという意味ではありません。GPUはアクティブな計算とキャッシュされたエキスパートを保持し、システムRAMはより大きなホスト常駐エキスパートプールを保持します。

FreeTokenが最も興味深くなるのは、モデルがVRAMに完全には収まらない場合です。量子化済みモデル全体がすでにGPUに収まるなら、システムメモリとVRAM間の繰り返し転送を避けられる従来型ランタイムが、依然として非常に競争力を持つ可能性があります。

報告されたRTX 5090の結果では、モデルやワークロードによって異なる挙動が示されています。

これらの数値はプロジェクトが公開した評価結果に基づくため、普遍的な保証ではなく、報告された結果として扱うべきです。モデルの精度、プロンプト長、システムメモリ、CPUアーキテクチャ、PCIeリンク、バックグラウンドアプリケーションによって、パフォーマンスは大きく変わる可能性があります。

このシステムは、エージェント型ワークロードにおける**最初のトークンまでの時間（TTFT）**も重視しています。コーディングエージェントは、ファイルを繰り返し読み込み、ツールを呼び出し、出力を受け取り、コンテキストがますます大きくなる中で新しいリクエストを送信します。FreeTokenはセマンティックな境界にプレフィックスと再帰状態のチェックポイントを作成することで、ツール呼び出しやコンテキスト編集後も変更されていないコンテキスト部分を再利用できます。

この評価では、FreeTokenをllama.cpp、KTransformers、Ollama、MoE-Infinityと比較しています。報告された優位性は、エキスパートの重みを頻繁に移動する必要があり、ワークロードに長く変化するコンテキストが含まれるケースで最も大きくなります。

利用可能な資料で説明されている高速化ドキュメントは、Linux x86-64、NVIDIA GPU、CUDA 13、そして新しいドライバーを中心としています。プロジェクトはWindowsとLinuxのデスクトップ対応にも言及していますが、最も詳しく文書化されている経路は、依然としてNVIDIAハードウェアを搭載したLinuxです。

以下のセットアップ手順を計画のガイドとして利用してください。ランタイムの対応状況は変わる可能性があるため、インストール前にプロジェクトの公式リリースチャンネルで現在のコマンドと対応チェックポイントを確認してください。

このプロジェクトの設計では、エキスパートバンクを効率的にロードできるレイアウトへ正規化するために、FTWストレージ形式を使用します。対応ディストリビューションが前処理済みの形式を提供している場合、テンソルの検出や再パッキングを繰り返す必要がなくなり、起動時の処理を削減できる可能性があります。

FreeTokenをllama.cppの万能な代替品として扱うべきではありません。両プロジェクトは異なる優先事項に最適化されています。llama.cppは、より幅広いOS、CPU、GPUベンダー、Apple Siliconデバイス、GGUFモデルに対応しています。一方、FreeTokenは、エキスパートがGPUメモリからあふれる非常に大規模なMoEモデルを提供するという難しいケースに焦点を当てています。

FreeTokenで報告されている優位性は、1つの最適化だけに依存するのではなく、複数のポリシーを組み合わせることで実現されています。

• 共有LRUエキスパートキャッシュは、トークン単位のルーティング局所性に追従します。
• ダブルバッファリングされたプリフィルは、現在の計算と次のレイヤーのエキスパート移動をオーバーラップさせます。
• 帯域幅適応型スケジューリングは、すべてのシステムでPCIeとDRAMのバランスが同じだと仮定せず、実際のマシンを測定します。
• 伸縮型キャッシュリサイズは、エキスパートと増加するKVキャッシュ需要の間でVRAMの割り当てを調整します。
• プレフィックス再利用により、ツール操作後の変更されていないコンテキストをエージェントセッションで再計算せずに済みます。

以下の項目の多くに当てはまる場合は、FreeTokenを選んでください。

• 対象モデルが、利用可能なVRAMを超えるMoEチェックポイントである。
• モデル全体を保持できるだけのシステムRAMがある。
• GPUがNVIDIA製で、ソフトウェアスタックが対応している。
• 長時間稼働するコーディングエージェントやツール呼び出しエージェントを重視している。
• より専門的なセットアップを受け入れられる。

大規模MoEモデルでのピーク性能よりも、移植性、モデルの選択肢、Apple Silicon、AMD対応、CPU動作、GGUF互換性を重視する場合は、llama.cppまたは別の汎用ランタイムを選んでください。

FreeTokenのアーキテクチャによって大規模なローカルモデルを利用しやすくなりますが、ストレージやメモリの要件がなくなるわけではありません。8 GBのGPUがあっても、35Bや284Bのチェックポイントが8 GBのインストール容量になるわけではありません。モデル全体には、依然としてホストメモリ、ストレージ、互換性のあるランタイムが必要です。

信頼性の高いテストを行うには、各ランタイムで同じモデル、精度、プロンプト、クライアント、ワークロードを使用してください。短いワンショットプロンプトはサーバーが動作することを確認するのに役立ちますが、マルチターンのコーディングエージェントを表すものではありません。複数ターンを実行し、関連する場合はツール呼び出しを含め、平均値だけでなく最も遅いTTFTにも注目してください。

プロジェクトが公開した評価では、FreeTokenのテスト中に最も遅かったターンも44秒未満に収まり、一部の項目ではベースラインのランタイムがそれを大幅に上回る遅延を記録しました。これらの数値は設計目標を理解するうえで有用ですが、実際の結果はハードウェアやソフトウェアのバージョンによって異なります。