FreeTokenとは？巨大MoEをローカル実行する仕組み・必要メモリ・llama.cppとの違いを整理

巨大なオープンウェイトLLMをローカルで動かすとき、これまでは「GPUのVRAMにどこまで入るか」が最初の壁になりやすかった。

FreeTokenは、その前提を少し変える推論エンジンだ。

GPUだけを計算装置として見るのではなく、GPU VRAM、CPU、システムRAM、CPU-GPU間の帯域まで含めて1つの推論環境として使い、巨大なMixture-of-Experts（MoE）モデルを一般向けハードウェアへ降ろすことを狙っている。

公式GitHubではRTX 30 / 40 / 50世代を含む一般向けGPUを対象にし、論文では8GBノートPC GPUから単一ワークステーションGPUまでの実行例が示されている。

ただし、「753Bモデルが1枚のGPUで動く」という数字だけを見ると誤解しやすい。

FreeTokenは753B分の重みをVRAMへ全部入れる技術ではない。MoEの疎な実行特性を利用し、エキスパート重みをシステムRAMなどへ置き、必要なものをGPU側へ動的に持ってくることで成立する。

VRAMに収まらない巨大MoEを試したい人には有力。ただし万能な高速化ソフトではない

FreeTokenを試す価値が大きいのは、次のようなユーザーだ。

• 32GBや48GB VRAMを超える巨大MoEを1台のPCで試したい
• システムRAMを128GB、256GB以上積んだワークステーションを活用したい
• GLM-5.2、DeepSeek系、Qwen系など大型MoEのローカル実行を研究したい
• CPUオフロードの速度低下を少しでも減らしたい
• コーディングエージェントやツール利用で長時間ローカルモデルを使いたい

逆に、7B〜30B級の密な構造のモデルや、すでにVRAMへ完全常駐できるモデルが中心なら、最初からFreeTokenを選ぶ理由は薄い。

LM Studio、Ollama、llama.cppなどの方が導入例も多く、一般的なGGUF推論では扱いやすい。

FreeTokenは何をしているのか

FreeTokenの特徴は、巨大MoEの重みを単純にCPUへオフロードするだけではないことだ。

公式リポジトリと論文では、主に次の仕組みが説明されている。

仕組み	役割
CPUとGPUの協調実行	GPUとCPUの双方でMoE処理を実行する
エキスパートのキャッシュ	よく使われるエキスパートをGPU側へ保持する
重みのストリーミング	必要な重みを実行に合わせて転送する
二重バッファを使った入力処理	転送と計算を重ね、待ち時間を減らす
動的メモリ管理	VRAMをエキスパートキャッシュとKVメモリの間で動的に配分する
文脈を考慮したキャッシュ	エージェントのコンテキスト編集時に再計算を減らす

つまりFreeTokenの本質は、巨大なモデルを「GPUへ全部載せる」のではなく、メモリ階層全体を実行時に使い分けることにある。

なぜMoEだとこの方式が効きやすいのか

MoEでは、モデル全体に大量のエキスパート重みが存在していても、1トークンの計算ですべてのエキスパートを使うわけではない。

たとえば総パラメータが数百Bあっても、1回の順伝播で有効になるパラメータはその一部になる。

この性質を利用すると、「全重みを高速VRAMへ常駐させる」以外の設計が取りやすい。

ただし、有効パラメータが少ないから必要RAMも少ない、という意味ではない。

使われていないエキスパートも重みとしてどこかに保持する必要がある。VRAMに置かないならシステムRAMやストレージ側が必要になる。

この点はMoEの総パラメータと有効パラメータの違いと合わせて考えると分かりやすい。

「753Bを単一ワークステーションGPUで実行」はどう読むべきか

FreeToken論文の概要では、35Bモデルを8GBノートPC GPU、284BモデルをゲーミングデスクトップPC、753BのGLM-5.2を単一ワークステーションGPUでサーバーとして実行できると説明している。

これはかなり大きな実行例だ。

しかし、ここから「RTX 5090 32GBだけあれば753Bが快適に動く」と結論づけてはいけない。

論文が示しているのはGPU VRAM単体の容量要件ではなく、個人向けマシン全体を異種混在推論プラットフォームとして使う方式だ。

実際の成立条件には少なくとも次が関係する。

• GPU VRAM
• システムRAM容量
• CPU性能
• CPUメモリ帯域
• PCIe / 接続帯域
• 重み形式と量子化
• KVキャッシュ量
• コンテキスト長さ
• ストレージ速度
• 実行するモデルのエキスパート構成

したがって、FreeTokenの記事やベンチマークを見るときは「GPU名」だけではなくマシン全体の構成を見る必要がある。

VRAMが少なくても動くことと、速いことは別

FreeTokenの重要な価値は、VRAM容量の壁を越えてモデルをサーバーとして実行できる範囲を広げることだ。

一方で、重みがVRAMに完全常駐している状態と同じ速度になるわけではない。

エキスパートをシステムRAMからGPUへ運ぶ場合、転送帯域と遅延が発生する。CPU側でも計算するならCPU性能とメモリ帯域も効く。

そのため、比較するときは次を分けて見るべきだ。

1. モデルが起動できるか
2. 入力処理が何トークン/sか
3. 生成が何トークン/sか
4. 長コンテキストで速度がどう変わるか
5. システムRAM使用量はいくつか
6. VRAM使用量のピークはいくつか
7. エージェントのツール呼び出しを繰り返したとき再計算がどうなるか

VRAM使用量とピークメモリの測り方と同じく、「起動できた」と「快適に使える」を分離する必要がある。

FreeTokenとllama.cppは何が違う？

llama.cppもCPU+GPUハイブリッド推論やGPU層オフロードを利用できるため、一見すると役割が近い。

ただしFreeTokenは、特に巨大MoEを端末ハードウェアでサーバーとして実行することへ設計の重点を置いている。

項目	FreeToken	llama.cpp
主眼	巨大MoEの端末サーバー運用	幅広いLLMの軽量ローカル推論
CPU/GPU併用	対応	対応
MoEエキスパート用キャッシュ	中核機能	モデル/実行環境依存
動的VRAM配分	エキスパート用キャッシュ / KV間で管理	一般的なメモリ管理中心
エージェント向け状態再利用	文脈を考慮したキャッシュを設計	実行環境のプロンプト/KV機能による
対応範囲	対応MoE中心	GGUFエコシステム全体が非常に広い

そのため、「FreeTokenがllama.cppの上位互換」という理解は正しくない。

一般的な7B、14B、27B、32Bモデルを動かすだけならllama.cppエコシステムの方が自然な場面は多い。

LM Studio・Ollama・llama.cppの違いも合わせて確認したい。

対応モデルと量子化形式

FreeToken公式リポジトリは、20以上のMoEモデルに対応すると説明している。

例として、DeepSeek-V4-Flash、Qwen3.6-35B-A3B、GLM-5.2などが挙げられている。

量子化・重み形式ではMXFP4、NVFP4、FP8、BF16などを案内している。

注意点は、GGUFを何でもそのままFreeTokenへ持ち込める、という意味ではないことだ。

FreeTokenは独自のFTW形式を含むサーバー運用構成一式を持っているため、使いたいモデルと重み形式が公式の対応済みモデル / ドキュメントに入っているか確認する必要がある。

Windowsでも使える？

公式リポジトリはWindowsとLinux向けデスクトップPC appを案内している。またCLIではPythonパッケージとして導入する方法が掲載されている。

ただし、新しい推論エンジンはGPU生成、CUDA、Python依存関係、モデル形式などで対応状況が変わりやすい。

「Windows版がある」ことと「すべてのモデル・最適化がLinuxと完全に同条件」は分けて考えた方が安全だ。

導入時は公式の対応済みハードウェアと対応済みモデルを現在のバージョンで確認したい。

どのくらいシステムRAMが必要？

FreeTokenを検討するとき、VRAMだけを見てはいけない。

巨大MoEの重みをVRAM外へ置く以上、システムRAMが重要になる。

必要容量はモデル、精度、量子化、実行環境の追加負荷で変わるため、「32GB GPUならRAM 128GB」のような固定式にはできない。

目安を作るなら、まず実際に使う重み一式の容量を見る。

たとえば重みだけで100GBを超えるモデルなら、128GB RAMを搭載していてもOS、実行環境、KVキャッシュ、ファイルシステムキャッシュなどの余白が必要になる。

巨大モデルを目的にPCを新規購入するなら、GPU VRAMだけでなく128GB / 256GB以上のRAM構成を取れるかも重要な比較項目になる。

16GB・24GB・32GBのVRAM差だけでなく、モデルファイル容量とシステムRAMを合わせて見るべきだ。

FreeTokenの強みが出やすい用途

1. 巨大MoEを1台で研究する

一番分かりやすい用途だ。

通常なら複数GPUやデータセンターGPUが必要になるサイズのMoEを、一般向け/ワークステーションマシンでサーバーとして実行できる範囲を広げられる。

2. ローカルコーディングエージェント

FreeTokenはOpenAI互換・Anthropic互換APIを案内し、Codex、Claude Code、OpenCode、OpenClawなどのツール-利用エージェントとの接続を想定している。

また意味上の区切りチェックポイントによって、ツール呼び出しや思考ブロックでコンテキストが編集されたときの再計算を減らす設計も論文・リポジトリで説明されている。

巨大MoEを単発チャットではなくエージェントとして長時間使う場合、ここはFreeToken独自の価値になり得る。

3. 大容量RAMワークステーションの活用

GPUは32GBでも、システムRAMを256GB積めるPCは存在する。

FreeTokenはその「GPU外の大容量メモリ」を単なる退避先ではなく、実行設計の一部として積極的に使う。

VRAMだけ増やすのが難しい一般向け市場では、この方向は重要だ。

今すぐ全員が乗り換えるべきではない

FreeTokenは技術的にはかなり面白いが、2026年9月時点では新しい実行環境だ。

ローカルAI利用者の多くにとっては、まず次の順番が安全だ。

1. LM Studio / Ollama / llama.cppで目的のモデルが普通に動くか確認する
2. 必要ならGGUF量子化やGPUオフロードを調整する
3. それでもVRAM・RAM・速度の壁に当たるか確認する
4. 巨大MoEを使いたい理由が明確ならFreeTokenを検証する

小型モデルを快適に動かす問題と、数百BのMoEを「どうにか個人向けマシンへ載せる」問題は別だ。

購入判断への影響

FreeTokenの登場は、「ローカルLLM用GPUはVRAMが多いほど絶対に正義」という単純な見方を少し変える。

もちろんVRAMは依然として重要だ。完全GPU常駐できる方が通常は単純で高速だからだ。

しかし巨大MoEでは、次の構成全体を見る必要が出てくる。

• GPU VRAM
• システムRAM容量
• CPU性能
• システムメモリ帯域
• PCIe世代と経路構成
• NVMe容量・速度
• 実行環境がそのハードウェアをどこまで最適化しているか

つまり今後のローカルAI PCでは、**GPUだけではなく「メモリ階層全体の性能」**がより重要になる可能性がある。