8GB/12GB/16GB VRAM GPUの救世主FreeTokenのWindows版、爆誕！
以前の記事で、コンシューマーGPUで巨大なMoE型LLMを動かせる「FreeToken」をLinux環境で試しました。
FreeTokenは、個人的にはかなり面白いプロジェクトだと思っています。
FreeTokenは何が凄いのか？
普通、数百億～数千億パラメータ級のLLMをローカルで動かそうとすると、GPUのVRAMが大きな壁になります。
ところがFreeTokenは、MoE（Mixture of Experts）の特性を利用し、GPUだけでなくCPU・システムRAM・PCIeなどを一体として使って推論するという発想を取っています。
つまり、
「GPUのVRAMにモデル全部を載せられないなら、CPU側のメモリも使ってしまえばいい」
というわけです。
しかも、単純にモデルを全部CPUに逃がすのではありません。
その時々でGPUとCPUのどちらで処理するのが速いかを判断しながら、必要なExpertをGPU側で処理する仕組みを持っています。
これが上手く機能すれば、これまで「VRAMが足りないから無理」と諦めていた巨大MoEモデルを、ゲーミングPCで動かせる可能性があります。
FreeToken自身も「コンシューマーGPUで290B以上のフロンティア級MoEモデルを動かす」ことを掲げており、RTX 30/40/50シリーズもサポート対象になっています。
これは、コンシューマーGPUでLLMを動かす世界を変えるゲームチェンジャーだと思っています。
そしてWindows版が登場！
これまでFreeTokenを試すにはLinux環境を用意する必要がありました。
Linuxなら前回のように動かせるのですが、世の中のLLMユーザーが全員Linuxを使っているわけではありません。
むしろ私のように、
「Windows + NVIDIA GPU」
という人の方が圧倒的に多いでしょう。
そんなWindowsユーザーに嬉しいものが登場しました。
なんと、
FreeToken DesktopのWindows版です！
現在のDesktop版にはWindows版が用意されており、GUIからモデルの管理、ダウンロード、チャット、エンジン設定などができるようになっています。最新版はv0.2.0-beta.14です。
「これはWindowsユーザーにはありがたい！」
ということで、さっそく私のRTX 5060 Ti 16GB環境に入れてみました。
……ところが、いきなりエラー（笑）
インストーラーを起動すると、GPUもちゃんと認識されました。
GPU: NVIDIA GeForce RTX 5060 Ti, 591.86さらにPython 3.12の仮想環境まで自動的に作ってくれます。
これは順調！
と思ったところで、
==> installing runtime + kernel-cache + deps (torch backend: cu130) ...
error: invalid value 'cu130' for '--torch-backend <TORCH_BACKEND>'
とエラー。
おいおい（笑）。
せっかくWindows版が来たのに、インストールで止まってしまいました。
原因はFreeTokenではなく「uv」だった
ログをよく見ると、インストーラーは
uv 0.8.22を使っていました。
そしてFreeTokenは現在CUDA 13系、つまりcu130を使おうとしているのに、この古いuvではcu130を認識できなかったわけです。
つまり、
FreeToken「CUDA 13.0を使います」
↓
uv「cu130？そんなもの知りません」
↓
インストール失敗
という状態でした。
そこでWindowsに入っていたuvを確認すると、WinGetで管理されていることが判明。
そこで、
winget upgrade --id=astral-sh.uv
を実行。
すると、
uv 0.12.5
まで一気に更新できました。
これで準備完了。
FreeTokenのインストーラーをもう一度実行してみます。
今度は……
インストール成功！
FreeToken Desktopが無事に起動しました。
いやー、これは嬉しい。
Linux環境を用意しなくても、Windows上でFreeTokenを使えるところまで来ました。
FreeTokenはまだ開発途上で、Windows版にもいくつか制約があります。特に巨大MoEモデルのCPUオフロードでは、Windowsのメモリ管理に関係する問題も報告されています。
それでも、
Windows + RTX 5060 Ti
でFreeTokenを起動できたというだけで、かなりワクワクします。
そして、こんな画面が出てきます！
起動すると、モデルを選択したりダウンロードしたりできるFreeTokenの画面が表示されます。
「おお、ちゃんとWindowsアプリになってる！」
という感じです。
さっそくモデルを選択して……
ダウンロード開始！
ここから先は、いよいよ
RTX 5060 Ti 16GB + システムRAM
で、どこまで巨大なLLMを動かせるのか。
FreeTokenの本領発揮です。
Windowsユーザーとしては、これはかなり楽しみな展開になってきました。
いよいよ起動
実際に巨大MoEモデルを動かして、速度やVRAM・RAMの使用量などを見ていきたいと思います。
なお、テンプレートのモデルだけでなく、既定のフォーマットに沿っていればローカルにあるLLMモデルもフォルダーごとドラッグ&ドロップで使えるようです（Q4などの量子化モデルは不可。FP16やNVFP4のモデルが対象）。
各モデルでの検証結果
Qwen3.6-35B-A3B-NVFP4：初回はロードエラー
ダウンロード後にロードを試みましたが、まだ環境が整っていないようで、RTX 5060 TiではQwen3.6-35B-A3B-NVFP4がエラーになりました。エコシステム全体でまだ埋まっていない穴のようで、GDNハイブリッド構造を持つモデルは現状まだ動かないようです。同様の問題が予想されるモデルとして以下が挙げられます。
Qwen3.5系のMoEモデル全般：Qwen3.6と同じGDNハイブリッド構造を継承しているため、ほぼ確実に同じ問題が出ます。
MiniMax-M2.5：MiniMaxは以前のモデル（MiniMax-01系）でも独自の線形アテンション（Lightning Attention）をハイブリッドで使ってきた実績があり、M2.5でも同種の層がある可能性があります。
ローカル変換モデル：コンバートエラー
HFダウンロードでローカルに落とした sakamakismile/llm-jp-4-32b-a3b-thinking-NVFP4 をインポート・コンバートしようとするとエラーになりました。NVFP4モデルそのものが、現環境ではコンバートが難しいようです。
gemma4 26B-A4B（BF16, 47GB）：ロード成功、応答は不安定
テンプレートにある gemma4 26B-A4B BF16（47GB）をダウンロードしたところ、ようやくロードできました。
チャットを試すとエラーが出たため、ダウンロードしたモデルの tokenizer_config.json を簡単に修正したものに入れ替えたところ、一応返事が返ってくるようになりました。
速度は15token/sくらい。これだけオフロードが大きいとLM StudioやOllamaでは1桁token/sになりそうですがそれでも微妙な数字です。
ただしメッセージがループする現象も発生しています。
前回テストしたようにLinux版のようにいずれはQwen3.6-35B-A3B-NVFP4が 100token/s出てくれれば。これからに期待ですね。
Qwen3.6-35B-A3B-NVFP4：パッチ適用でロード成功
あれこれ調べた結果、Qwen3.6-35B-A3B-NVFP4を動かせるようになりました。RRX5060Ti16GBで40token/s前後です。ピークで50行くことは無いですが45,6が最大のようです。
【重要】このバージョン専用の回避パッチ
単にバグを回避するだけのパッチです。開発元の修正を待てない方は、以下のファイルを置き換えることで同じ問題を回避できます。
C:\Users\ユーザー名\AppData\Local\FreeToken\venv\Lib\site-packages\freetoken\kernel\triton\fp8_pertensor_linear.py上記ファイルをバックアップした上で、下記ファイルに置き換えてください。
症状
RTX 50/40シリーズ（Hopper以外のGPU）で nvidia/Qwen3.6-35B-A3B-NVFP4 など、GDN（GatedDeltaNet/線形アテンション）の融合projection（in_proj_qkvzなど）がFP8 per-tensor量子化＋input_scale付きで保存されているチェックポイントをロードすると、以下のエラーでサーバー起動時にクラッシュします。
RuntimeError: Rowwise scaling is not currently supported on your device原因
freetoken/kernel/triton/fp8_pertensor_linear.py の fp8_pertensor_linear() は、量子化チェックポイントに input_scale（アクティベーションの静的スケール）が含まれ、かつ e4m3_native() がTrueの場合、torch._scaled_mm（cuBLASLt経由のW8A8 GEMM）を使う経路に入ります。
in_proj_qkvz のようにq/k/v/zを1つのテンソルに融合したprojectionは、各パートごとに別々のスケール値を持つため weight_scale が「区分定数」ベクトルとなり、uniform_scale=False と判定されます。これにより torch._scaled_mm のrowwise（行単位）スケーリング分岐が呼ばれます。
しかしPyTorch本体側では、rowwise-scaled f8f8bf16 _scaled_mm のCUTLASSカーネルがHopper（sm_90）専用として実装されており（参考：pytorch/pytorch#145728）、それ以外のアーキテクチャ（Ada sm_89、Blackwell sm_100/103/120など）では明示的に例外を投げます。
つまりFreeToken側の e4m3_native() ガードは「sm_89以上ならtorch._scaled_mmを使ってよい」という判定しかしておらず、rowwise分岐が実質Hopperしか通らないことを考慮していません。この結果、H100/H200以外のGPUで、融合projection＋input_scale付きのチェックポイントを使うと必ず再現します。RTX 50系固有の問題ではなく、RTX 40系（Ada）でも同様に発生し得ます。
回避方法
uniform_scale=False（融合projection）の場合のみ、GPUがsm_90かどうかを追加チェックし、非対応ならTritonネイティブの _gemv/_gemm（W8A16）経路にフォールバックさせます。uniform_scale=True（通常の単一スケール層）は元の torch._scaled_mm 経路のまま変更ありません。
python
# fp8_pertensor_linear.py に追加
_ROWWISE_SCALED_MM_OK: bool | None = None
def _rowwise_scaled_mm_supported() -> bool:
global _ROWWISE_SCALED_MM_OK
if _ROWWISE_SCALED_MM_OK is None:
_ROWWISE_SCALED_MM_OK = (
torch.cuda.is_available() and torch.cuda.get_device_capability() == (9, 0)
)
return _ROWWISE_SCALED_MM_OKpython
# fp8_pertensor_linear() 内、分岐条件を変更
elif input_scale is not None and e4m3_native() and (
uniform_scale or _rowwise_scaled_mm_supported()
):
out = _scaled_mm(...)検証環境
GPU: RTX 5060 Ti（sm_120 / Blackwell）
torch 2.11.0+cu130 / Driver 591.86 / CUDA 13.1
モデル: nvidia/Qwen3.6-35B-A3B-NVFP4（FreeTokenテンプレート）
備考
FreeTokenがアップデートされるとこのファイルは上書きされるため、パッチは都度再適用が必要です。根本修正はアップストリーム側で対応されるのが望ましいところです。
まとめ
Windows + RTX 5060 Tiという環境でも、FreeToken Desktopをなんとか動かすところまでたどり着きました。途中でuvのバージョン問題やGDNハイブリッド構造のモデルでのロードエラーなど、いくつかの壁がありましたが、パッチを当てることでQwen3.6-35B-A3B-NVFP4のロードにも成功しています。
FreeTokenのWindows版はまだ発展途上ですが、Linux環境が必須だったハードルが下がったのは大きな進歩です。
あとQwen3.6-35B-A3B-NVFP4 + FreeTokenでopencodeにつないで、コーディングさせたのですがファイル操作などは完璧でしたが、肝心のコードを書くのは苦手なようでバグ混在率が高すぎてKAT-Coder-V2.5-Devと対決させるには至りませんでした。Freetokenでexpertを絞っているのが原因かNVFP4の量子化が原因なのか、はたまたQwen3.6-35B-A3Bはコーディングが苦手なのかはっきりしませんが、Q4<NVFP4 ≒ Q5 あたりなのでちょっと凝ったインベーダーゲーム程度なら一発でコーディングして欲しかったのです。
