「8GBのGPUで35Bモデルが動く」という見出しを見て、手元のマシンを思い浮かべたなら。
動きます。ただしその機材にはRAMが32GB載っています。見出しになっている8GBはVRAMの話で、モデルの本体が置かれるのはシステムRAMの側です。
TL;DR: RTX 4060 Laptop（VRAM 8GB）で Qwen3.6-35B-A3B が 39.3 tok/s。ただし同じ機材の host RAM は 32GB。そして macOS は公式非対応（ただしM3で動作確認済みのPRが8月23日に出ています）。
※本記事の数値は2026年8月24日時点で、arXiv論文（2608.16157）と公式リポジトリを直接確認したものです。
あの比較表は、別々のモデルの数字を並べている
まず数値の読み方を直します。各媒体が並べているのは次の3つです。
| GPU | 報道された速度 |
|---|---|
| RTX 4060 Laptop（8GB） | 39 tok/s |
| RTX 5090（32GB） | 22〜25 tok/s |
| RTX PRO 6000 | 15 tok/s |
これを縦に読むと「8GBの方が32GBより速い」と見えます。おかしいと感じたなら、その直感が正しいです。
論文の評価表を開くと、3行それぞれ動かしているモデルが違いました。
| ハードウェア | VRAM | 実行モデル | decode |
|---|---|---|---|
| RTX 4060 Laptop | 8GB | Qwen3.6-35B-A3B | 39.3 tok/s |
| RTX 5090 | 32GB | Qwen3.6-35B-A3B | 77〜83 tok/s |
| RTX 5090 | 32GB | DeepSeek-V4-Flash（284B） | 22〜25 tok/s |
| RTX PRO 6000 | 96GB | GLM-5.2（753B） | 14.9 tok/s |
同じ Qwen3.6-35B-A3B で比べれば、RTX 5090 は 77〜83 tok/s です。4060 のおよそ2倍で、順当な結果でした。
報道の表が見せているのは「モデルが大きくなるほど遅くなる」という当たり前の事実です。GPUの選定材料として読むと判断を誤ります。
本当の関門はVRAMではない。host RAM 32GBが要る
FreeToken を試せるかどうかは、VRAMではなくシステムRAMで決まります。
理由は動作原理にあります。MoE（Mixture-of-Experts）モデルは、推論のたびに一部の「エキスパート」しか使いません。FreeToken はこの性質を利用します。エキスパート群を host RAM に常駐させ、必要なぶんだけ PCIe 経由で GPU へ送る設計です。GPU側に置くのは LRU キャッシュだけです。
だから VRAM は 8GB で足ります。そのかわり、モデル本体を抱えるのは RAM の役目になります。
論文の評価機材（Table 1）を見ると、この構造がはっきり出ています。
| 機材 | VRAM | host RAM |
|---|---|---|
| RTX 4060 Laptop | 8GB | 32GB LPDDR5 |
| RTX 3090 | 24GB | 180GB DDR4 |
| RTX 4090 | 24GB | 240GB DDR4 |
| RTX 5090 Desktop | 32GB | 192GB DDR5 |
| RTX PRO 6000 | 96GB | 512GB DDR5 |
論文は制約も明記しています。エキスパート群は host メモリに載り切る必要があり、ディスクだけでは動きません。
最初に確認すべきスペックはこの2行です。
- VRAM 8GB以上 ← 見出しになっている数字
- host RAM 32GB以上 ← 記事に出てこないが必須
RAM 16GB のノートPCで35B級を狙うのは、現時点では厳しいと考えてください。
Macは公式非対応。ただし動くPRが昨日出てきた
Apple Silicon Mac を使っているなら、答えは「公式には動かない。ただし状況が動いている」です。
公式の要件は Linux x86_64 のみで、Apple Silicon 対応の要望（Issue #9）は open のままです。公式配布物としては非対応という結論は変わりません。
一方で、2026年8月23日に Pull Request #65「Apple Silicon Metal backend (ft serve on macOS arm64)」 が提出されています。内容はこうです。
ft serveが Darwin では torch を import する前に Metal バックエンド（MLX または llama.cpp）へ routing するinstall.shが macOS arm64 では mlx-lm 経由のパスを取る- M3 上での動作確認済み（
ft serve-metalがチャット補完とストリーミングを Metal 経由で提供） - 状態: open・未マージ（2026年8月24日時点）
PRの説明には、現状 ft serve が Metal 環境で ModuleNotFoundError: torch を出して落ちること、PyPI に macOS 向け wheel が無いことが動機として書かれています。
つまり「今すぐ uv pip install で動く」わけではありませんが、M1〜M4 で動かすためのコードは既に存在し、レビュー待ちの段階です。数週間のうちにマージされれば、この節の前提は覆ります。
※Mac対応の状況は2026年8月24日時点。PR #65 の進捗は変わりうるので、試す前にリポジトリの Pull Requests を確認してください。
いま動かしたいなら、量子化を詰める方向が現実的です。手前味噌ですが、16GB の Mac で 27B を動かしたときの実測を別記事にまとめています。量子化を1段間違えると生成速度が20分の1になる話です。
動かす条件は Linux x86_64 + NVIDIA + CUDA 13 の3点セット
確実に動く構成は、公式の install.md に3行で書かれています。
- Linux x86_64
- NVIDIA GPU、ドライバ r580以降（CUDA 13）
- Python 3.10 以上
ここで注意点があります。README は「Windows or Linux」でダウンロードできると案内しています。しかし install.md の Requirements は Linux x86_64 のみです。公式ドキュメント内で記述が食い違っています。
Windows 側の実情は Issue を見るとつかめます。2026年8月24日時点で open のものを挙げます（番号は実際のIssue番号）。
- 35
FreeToken Engine Install Fails in Windows with RTX4060 - 94
Desktop app is quarantined as trojan by Windows Security（アンチウイルスによる誤検知） - 42
Install of Freetoken engine fails on windows as it is bocked by antivirus - 50
Windows: server fails during CUDA graph warmup because dll is not found - 55
Windows/WDDM: offload serving fails when bank sources exceed the ~50%-RAM pageable-locking pool
最後のものは特に効いてきます。Windows の WDDM ではページロックできるメモリが実質RAMの約50%までに制限されるため、この記事の主役である offload 方式が制限に引っかかるという報告です。RAM 32GB でも、ピン留めできるのは16GB程度という計算になります。
Windows のデスクトップアプリは存在しますが、現状は「動く人は動く」段階と見るのが妥当です。
インストールと起動
導入は uv を使うのが公式推奨です。以下でエンジン本体が入ります。
uv pip install "freetoken[accel]"CUDA カーネルは初回実行時に JIT コンパイルされるため、nvcc が PATH に通っている CUDA 13 のツールキットが必要です。
サーバの起動はモデルを指定するだけです。
ft serve --model ~/models/Qwen3.6-35B-A3B--model は Hugging Face のリポジトリIDも受け付けます。dtype・アテンション・MoEバックエンド・キャッシュサイズは、チェックポイントとGPUから自動で決まります。ログに API server is ready to serve on 127.0.0.1:1919 が出れば準備完了です。
動作確認は次のコマンドで行えます。
ft --version
curl http://127.0.0.1:1919/v1/modelsMoEバックエンドは4種類から選べる
--moe-backend で挙動を切り替えられます。ここが速度を左右します。
| backend | 挙動 |
|---|---|
fused | エキスパートを全部GPUに常駐。VRAMが要るため auto では選ばれない |
offload | エキスパートは host RAM。GPUにはLRUスロット。ミスはPCIeでストリーム |
cpu | ミスを取りに行かず、CPUで計算する |
hybrid | ミスの一部をPCIe転送、残りをCPU計算してオーバーラップさせる |
auto | dense は fused、MoE は offload。較正済みなら hybrid に昇格 |
hybrid を使う前に、マシンごとに1回だけ帯域の較正を走らせます。
ft bench bwこれは host RAM と PCIe の帯域を実際のカーネルで測り、CPU計算とPCIe転送の分担比を決めるためのものです。
※ここまでの手順は公式ドキュメント（install.md / quickstart.md / models.md）と論文 arXiv:2608.16157 に基づく記述で、筆者環境での実行検証は行っていません（2026年8月時点）。筆者の手元は Apple Silicon Mac のため、前述のとおり FreeToken 本体を動かせません。実測で確認したのは後述する
ftコマンドの衝突のみです。
本命は ft launch claude — Claude Codeを自分のGPUに向ける
FreeToken で一番おもしろいのは、速度よりもエージェント接続だと考えています。
FreeToken は OpenAI互換API（/v1/chat/completions、/v1/responses、/v1/models）と Anthropic互換API（/v1/messages、/v1/messages/count_tokens）の両方をポート1919で提供します。つまりクライアント側の base URL を差し替えるだけで繋がります。
その差し替えを自動でやるコマンドが用意されています。
ft launch claude指定できるのは claude / codex / dsh / hermes / openclaw / opencode の6種類です。このコマンドはプロバイダ設定を書き込み、CLIが未インストールなら入れ、自分のサーバに向けて起動するところまでやります。変更内容を先に見たい場合は --dry-run を付けます。
ft launch claude --dry-run設計として効いている一手：APIキーを子プロセスから消す
ft launch の仕様で感心したのはここです。公式ドキュメントにこう書かれています。
Cloud API keys (
ANTHROPIC_API_KEY,OPENAI_API_KEY, …) are cleared from the child environment so the agent cannot silently fall back to a paid endpoint.
クラウドのAPIキーを子プロセスの環境変数から削除しているのです。理由は「エージェントが黙って有料エンドポイントにフォールバックできないようにするため」。
ローカルで動かしているつもりが、実は設定ミスでクラウドのAPIを叩いていて課金されていた、という事故はローカルLLM運用でよく聞く話です。それを起動側で構造的に潰しています。「ローカルで動かす」という約束を、注意書きではなく実装で守らせる設計です。
ローカルLLM系の解説では、この「起動コマンドの実名」が抜け落ちがちです。接続手順の見出しがあるのに「環境変数で設定します」で終わる記事を何度も見ました。FreeToken では ft launch claude の一行で足ります。
覚えておくと効く残りのコマンド
ft serve と ft launch 以外に、実運用で効くものが3つあります。
| コマンド | 用途 |
|---|---|
ft shell | ターミナルでチャット。--server URL で別マシンのサーバにも繋がる（attach時はGPU不要） |
ft ctl | 稼働中サーバの管理。health / stats / cache / requests |
ft checkpoint | HF safetensors を FTW（高速ロード形式）へ事前変換。ft serve --model が自動検出する |
特に ft ctl cache は、この記事の主題と直結します。サーバを再起動せずにキャッシュ配分を変更できます。
ft ctl cache # 現在のプール状況を見る
ft ctl cache --moe 64 --kv 8192 # expertキャッシュとKVの配分を無停止で変更
コンテキストを長く取りたいのか、expert のヒット率を上げたいのか。その判断を実行中に試せるのは、VRAMが逼迫する8GB環境ほど効いてきます。
対応モデルと量子化形式
公式が known-good として挙げているモデルは20以上あります。主要なものを挙げます。
| モデル | チェックポイント例 |
|---|---|
| Qwen3.6 MoE | Qwen/Qwen3.6-35B-A3B（FP8 / NVFP4 版あり） |
| DeepSeek-V4 | deepseek-ai/DeepSeek-V4-Flash-0731 |
| GLM-5.2 | nvidia/GLM-5.2-NVFP4 |
| gpt-oss | openai/gpt-oss-120b、openai/gpt-oss-20b |
| Gemma-4 | google/gemma-4-26B-A4B-it（GGUFネイティブ対応） |
| MiniMax-M2.5 | nvidia/MiniMax-M2.5-NVFP4 |
量子化形式は MXFP4 / NVFP4 / FP8 / BF16 に対応します。Hugging Face の safetensors を直接読むため、GGUF への変換は不要です（Gemma-4 のみ GGUF もネイティブ対応）。llama.cpp 系に慣れていると変換の手間を見込みますが、そこは省けます。
ft は名前が衝突する（筆者環境で実際に踏んだ）
導入前に確認しておくことがあります。ft というコマンド名は、すでに他のツールが使っている可能性があります。
筆者の環境では、ft は fieldtheory-cli に割り当て済みでした。X.com のブックマークをローカル同期するために毎日使っているCLIです。
$ which ft
/opt/homebrew/bin/ft
$ ft --version
1.2.1
この 1.2.1 は fieldtheory-cli のバージョンで、FreeToken のものではありません（FreeToken の最新は v0.1.2）。
公式手順では venv を有効化して使うため、venv が有効な間は FreeToken の ft が優先されます。ただしグローバルに ft を持っている場合、venv を抜けた状態で叩くと別のツールが起動します。ft serve のつもりで無関係なCLIのエラーを見ることになります。導入前に which ft を一度叩いておけば避けられます。
v0.1.2・open issue 123件。試すかどうかの分岐は3つ
最後に成熟度の話をします。数字で見ると、まだ非常に若いプロジェクトです。
| 項目 | 値 |
|---|---|
| 最新リリース | v0.1.2（2026-08-19） |
| リポジトリ作成日 | 2026-07-20（公開から約1か月） |
| Star | 約4,200 |
| Fork | 380 |
| Open Issues | 123 |
| ライセンス | Apache-2.0 |
※Star数は2026年8月24日に取得したスナップショットです。伸びが速く、この記事を書いている数時間のあいだにも4,156から4,204まで増えました。
論文の著者には Ion Stoica、Matei Zaharia、Song Han が並びます。Spark・Ray・vLLM を生んだ系譜の研究室から出ている点で、方向性の筋は良いと判断できます。
そのうえで、判断は環境で分かれます。
- Linux + NVIDIA + RAM 32GB以上を持っている → 試す価値があります。
ft launch claudeで Claude Code をローカルGPUに向けられる点は、他のツールにない強みです - Windows → デスクトップアプリはありますが、インストール失敗とWDDMのメモリ制限が open のままです。急ぎでなければ数バージョン待つのが無難です
- Mac → 対象外です。時間を使わず、量子化を詰める方向に切り替えてください
open issue が123件でバージョンが v0.1.2 である以上、本番の推論基盤として置くのは時期尚早です。手元の実験環境として触るぶんには、MoEオフロードの挙動を学べる良い題材だと考えています。
まとめ
今回は FreeToken の必要スペックと、報道されている数値の読み方について整理しました。
要点の再掲
- 報道の速度比較表は別々のモデルの数値を並べたもの。同一モデル（Qwen3.6-35B-A3B）なら RTX 5090 は 77〜83 tok/s で、4060 の約2倍
- 「8GB GPU」の裏に host RAM 32GB が必要。エキスパート群は host メモリに載り切る必要があり、ディスクだけでは動かない
- macOS は公式非対応。ただし M3 で動作確認済みの PR #65 が2026年8月23日に出ており、状況は動いている
- 確実に動く構成は Linux x86_64 + NVIDIA（driver r580+ / CUDA 13）
- 目玉は
ft launch claude。クラウドAPIキーを子プロセスから消して、黙って課金される事故を構造的に防いでいる ft ctl cacheでキャッシュ配分を無停止で変更できる- v0.1.2・open issue 123件のため、本番投入は時期尚早
自分のマシンで試せるかどうかは、GPUのVRAMではなくRAMの容量を見れば判断できます。まずは手元の搭載RAMを確認してみてください。
関連記事
コメント