- FreeToken gguf は Gemma-4 をネイティブサポートしています。一方、掲載されているその他のモデルの多くは Hugging Face safetensors を使用します。
- 最適な用途：利用可能な GPU VRAM を超える一方で、システムメモリには収まる大規模な MoE チェックポイント。
- 主な利点：適応型エキスパートキャッシュ、CPU 処理、PCIe 転送により、トークン間の待ち時間を短縮できます。
- 主な制限：高速化されたセットアップは、Linux、NVIDIA GPU、CUDA 13、x86-64 システムを中心に構成されています。
- 重要な確認事項：FreeToken が対象アーキテクチャとフォーマットをサポートしていない限り、GGUF ファイルが自動的に互換性を持つわけではありません。
FreeToken gguf の互換性を解説
FreeToken は AI モデルではなく、ローカル推論エンジンです。その目的は、利用可能なハードウェア上でサポート対象のチェックポイントを実行することであり、特に完全な重みを VRAM に収められない大規模な Mixture-of-Experts モデルを対象としています。現在のモデルドキュメントによると、FreeToken は Hugging Face safetensors チェックポイントを直接読み込み、Gemma-4 の GGUF をネイティブサポートしています。
つまり、「FreeToken gguf」は GGUF 形式全般との互換性を意味するものではありません。GGUF はモデルコンテナ形式ですが、ランタイムには対応するアーキテクチャ、カーネル、読み込みロジックも必要です。チェックポイントを変換またはダウンロードする前に、FreeToken 公式モデルドキュメントを確認してください。
動画のポイント：
- FreeToken はあらゆるローカル推論ワークロードではなく、非常に大規模な MoE モデルを対象としています。
- 適応型エキスパートキャッシュにより、頻繁に使用されるエキスパートを VRAM 上で利用可能な状態に保ちます。
- ハイブリッド実行では、GPU 転送と CPU 計算を組み合わせることができます。
- 報告されたテストには、グラフィックスカードの容量を超える大規模モデルの実行結果が含まれています。
| 形式またはソース | FreeToken における現在の扱い | 実用上の意味 |
|---|---|---|
| Hugging Face safetensors | 動作確認済みのチェックポイントを直接読み込み | 掲載されているモデルファミリーの主要な利用方法 |
| GGUF | Gemma-4 のネイティブサポートが文書化されています | すべての GGUF モデルが読み込めるとは限りません |
| 変換済み FreeToken チェックポイント | 任意で使用できる高速読み込み形式 | ft serve --model が変換結果を自動検出できます |
| サポート対象外のアーキテクチャ | 文書化された保証はありません | 変換前にモデルサポートを確認してください |
ファイル拡張子だけでは互換性を確認できません。FreeToken のデプロイを準備する前に、モデルファミリー、チェックポイント構造、量子化方式、文書化されたバックエンドサポートを確認してください。
サポート対象モデルとランタイムバックエンド
文書化されたモデル一覧では、DeepSeek-V4 と GLM-5.2 が動作確認済みの Hugging Face チェックポイントとして挙げられています。また、ドキュメントでは、エキスパートをどこに保存し、キャッシュミスをどのように処理するかを決定する複数の MoE バックエンドについても説明されています。
auto 設定は、モデルの種類に基づいてデフォルトを選択します。Dense モデルでは fused が選択され、MoE モデルでは通常 offload が使用されます。マシンベンチマークで推奨された場合は、hybrid に切り替えることもできます。
fused
エキスパートを GPU 上に常駐させます。利用可能な VRAM が十分な場合は効率的ですが、最も多くの GPU メモリを必要とします。
offload
エキスパートはホスト RAM に配置し、LRU キャッシュによって選択したエキスパートスロットを GPU 上に保持します。キャッシュミスが発生すると、PCIe 経由でストリーミングされます。
hybrid
各ステップで一部のエキスパートを PCIe 経由で取得し、別のエキスパートを CPU で計算できます。ハードウェアに適した分割であれば、処理をオーバーラップさせることも可能です。
| バックエンド | エキスパートの配置場所 | 適した状況 |
|---|---|---|
fused | GPU VRAM | モデルとアクティブなワークロードが GPU に余裕を持って収まる場合 |
offload | GPU キャッシュ付きのホスト RAM | 大規模な MoE モデルが VRAM 容量を超える場合 |
cpu | CPU がキャッシュミスを処理 | 転送を繰り返すより CPU のメモリ帯域幅を利用する方が適している場合 |
hybrid | CPU と PCIe 転送 | ベンチマークで混合経路の方が高速と示された場合 |
auto | 自動選択 | サポート対象モデルでの妥当な開始点 |
FreeToken の設計は、モデルがグラフィックスカードより大きい一方で、システム全体のメモリには収まる場合に特に有効です。固定的な分割に依存するのではなく、GPU 計算、CPU 計算、RAM 容量、PCIe 帯域幅を一つのシステムとして扱います。
ハイブリッド実行を利用する前に、マシンごとに一度 ft bench bw を実行してください。得られた帯域幅プロファイルを使って、キャッシュミス時にエキスパートの取得と CPU 計算のどちらが適しているかを FreeToken が推定できます。
サポート対象チェックポイントの FreeToken セットアップ手順
セットアップ前に、ホスト環境が文書化された要件を満たしていることを確認してください。要件は Linux、x86-64 コンピューター、NVIDIA GPU、CUDA 13、そして新しいドライバーです。プロジェクトでは RTX 30、RTX 40、RTX 50 シリーズのカードを取り上げていますが、実際の性能はモデルサイズ、量子化、RAM、VRAM、CPU 速度、PCIe 帯域幅によって異なります。
チェックポイントを確認する
公式ドキュメントに掲載されているモデルから始めてください。たとえば、サポート対象の DeepSeek-V4 または GLM-5.2 Hugging Face チェックポイントを使用します。GGUF の場合は、アーキテクチャが明示的にサポートされていることを確認してください。文書化されているネイティブ対応例は Gemma-4 です。
メモリ容量を確認する
完全なチェックポイントを VRAM とシステム RAM に分散して保存できることを確認してください。8 GB の GPU であっても、モデル全体の保存要件が 8 GB になるわけではありません。
マシンをベンチマークする
ft bench bw を使用して、ローカルのメモリおよび転送性能を測定します。これにより、offload、cpu、hybrid のどれが MoE に適した経路かを判断しやすくなります。
任意の高速読み込み形式を準備する
読み込みの高速化が役立つ場合にのみ、文書化されたチェックポイント変換を実行してください。変換は任意であり、サービングコマンドは変換後の形式を自動検出できます。
起動して監視する
ft serve --model でモデルを起動し、長いコンテキストやエージェントからの繰り返しリクエスト中に、メモリ使用量、初回トークンまでの遅延、生成速度、安定性を確認します。
| セットアップ項目 | 確認内容 | 重要な理由 |
|---|---|---|
| オペレーティングシステム | Linux を中心とした高速化経路 | 現在の手順は、あらゆるデスクトップ環境に対応するものではありません |
| GPU | 適切なドライバーを備えた NVIDIA カード | 文書化された高速化は NVIDIA と CUDA を中心に構成されています |
| CUDA | CUDA 13 | 文書化されたコマンドライン手順で必要です |
| システム RAM | オフロードされた重みを保持できる容量 | 残りのモデル重みを保存する場所が必要です |
| チェックポイント | サポート対象のアーキテクチャと形式 | 読み込みはファイル拡張子だけでなく、ランタイムのサポートに依存します |
長いコンテキストやエージェントのワークロードを開始する前に、モデルの読み込みと短いプロンプトをテストしてください。長時間のセッションを開始せずに、チェックポイント、ドライバー、メモリに関する問題を発見できます。
性能、メモリ、llama.cpp との比較
FreeToken の最大の強みは、あらゆるローカルランタイムを置き換えることではありません。総重量が VRAM を超える大規模な MoE モデルを実行することに特化しています。このエンジンはアクティブなエキスパートをキャッシュし、転送と計算をオーバーラップさせ、ホストマシンに応じて GPU 転送と CPU 処理を選択できます。
利用可能な資料で説明されている報告結果には、RTX 5090 上での Qwen3.6-35B-A3B が約 77～83 tokens per second、テストされたワークロードにおける DeepSeek-V4 Flash が約 22～25 tokens per second という数値が含まれています。また、VRAM 8 GB、システムメモリ 32 GB の RTX 4060 ノートパソコンでは、公式の 4-bit Qwen チェックポイントを使用して 39.3 tokens per second に達したと報告されています。これらは報告された結果であり、あらゆる構成で保証されるものではありません。
| ワークロードの条件 | FreeToken との関連性 | 比較時の注意点 |
|---|---|---|
| モデルが VRAM に完全に収まる | 低い | 成熟したランタイムの方がすでに非常に高速な場合があります |
| MoE モデルが VRAM を超える | 高い | エキスパートキャッシュとオフロードが重要になります |
| 長いエージェントコンテキスト | 高い | ツール呼び出しの繰り返しにより転送遅延が表面化することがあります |
| CPU のみでの動作 | 限定的 | FreeToken は汎用 CPU ランナーとして位置付けられていません |
| Apple Silicon 環境 | 不明確 | 提供された資料には比較可能な経路が文書化されていません |
llama.cpp との比較は、ワークロードによって異なります。llama.cpp は、幅広いオペレーティングシステム、プロセッサ、GPU、モデル形式をサポートしており、大規模な GGUF エコシステムも利用できます。FreeToken はより新しく、対応範囲も狭い一方、その狭い焦点は、NVIDIA ベースの大規模な MoE デプロイで役立つ可能性があります。
エージェントにとって、生成速度は指標の一つにすぎません。短い合成プロンプトでの結果よりも、初回トークンまでの遅延、コンテキストの再利用、ツール呼び出しの応答時間、長時間セッションでの安定性が重要になる場合があります。数分間に及ぶ停止を避けられるランタイムは、tokens per second の代表値が似ていても、より応答性が高く感じられることがあります。
公開された数値やコミュニティの報告値は、構成に依存するものとして扱ってください。結論を出す前に、同じモデル、量子化方式、プロンプト長、コンテキストサイズ、ハードウェア、バックエンド、メモリ配置で比較してください。
検証チェックリストと FAQ
FreeToken gguf のワークフロー、またはサポート対象のチェックポイントを評価する際は、このチェックリストを使用してください。目的は、性能を調整する前に互換性とシステムへの適合性を確認することです。
事前確認：
- モデルアーキテクチャが FreeToken のドキュメントに掲載されていることを確認する
- チェックポイントが Hugging Face safetensors またはサポート対象のネイティブ GGUF を使用しているか確認する
- システム RAM、GPU VRAM、利用可能なストレージを測定する
- hybrid 実行を選択する前に ft bench bw を実行する
- 長いコンテキストやエージェントのワークロードの前に短いプロンプトをテストする
| 指標 | 正常な結果 | 失敗した場合の対応 |
|---|---|---|
| モデルの読み込み | フォーマットエラーなしでチェックポイントが初期化される | アーキテクチャとチェックポイントの構成を再確認する |
| VRAM 使用量 | キャッシュとコンテキストに十分な余裕がある | キャッシュの負荷を下げるか、別のバックエンドを選択する |
| 初回トークンまでの遅延 | 繰り返しのリクエストでも安定している | 転送、コンテキスト長、RAM の圧迫を調査する |
| 生成速度 | 選択したワークロードで一貫している | 同じプロンプトを使ってバックエンドを比較する |
| 長いコンテキスト | 深刻な停止やメモリ不足が発生しない | コンテキストサイズを下げるか、システム容量を見直す |
Q: FreeToken はすべての GGUF モデルをサポートしていますか？
すべてをサポートすることは確認されていません。ドキュメントで明確に示されているネイティブ GGUF サポートは Gemma-4 であり、掲載されているその他のチェックポイントの多くは Hugging Face safetensors を使用します。別の GGUF ファイルを使用する前に、アーキテクチャのサポートを確認してください。
Q: FreeToken はすべてのコンピューターで llama.cpp より優れていますか？
いいえ。llama.cpp はハードウェア、オペレーティングシステム、GGUF の対応範囲がより広いです。FreeToken は、サポート対象の NVIDIA システム上で GPU VRAM を超える大規模な MoE モデルに、より特化しています。
Q: 8 GB の GPU で 8 GB より大きいモデルを実行できますか？
十分なシステム RAM が残りの重みを保持し、チェックポイントがサポート対象であれば、実行できる可能性があります。ただし、モデル全体ではコンピューター上に合計サイズ分の保存容量が必要です。
Q: DeepSeek-V4 のチェックポイントでエラーが発生した場合はどうすればよいですか？
inference/config.json サブディレクトリが残っていることを確認してください。文書化されたモデル引数はその場所から読み込まれるためです。
文書化されたチェックポイントから始め、メモリ要件を検証し、実際のマシンでベンチマークを行ってください。GGUF というラベルだけでなく、形式のサポートとハードウェア上の挙動が重要です。
FreeToken 公式モデルドキュメントは、サポート対象チェックポイント、バックエンドフラグ、変換に関する注意事項、モデル固有の要件を確認するための基準資料です。