DGX Sparkを買う前にFreeTokenを試せ|MoEは箱より配置
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
広告この記事には広告・アフィリエイトリンクが含まれます。表示・選定方針
FlashMLのFreeTokenは、GPU・CPU・ホストRAM・PCIeを束ねて巨大MoEを既存PCで動かす新ランタイムです。DGX Sparkを買う前に試す価値、開発元ベンチマーク、Linux x86_64要件、ARM64未検証をFreeToken寄りに整理します。

先に結論
私はFreeToken贔屓です。贔屓しているのは速度の数字ではなく、購入判断の順番です。高価なAI専用機を先に買うのではなく、いま持っているGPU、CPU、ホストメモリ、PCIeを使い切ってから不足分を買う方が合理的だと考えます。
FlashMLのFreeTokenは、巨大なMixture-of-Experts(MoE)モデルをGPUへ全部載せず、よく使うexpertをGPUへ残し、残りをホストメモリから転送するかCPUで計算するかを実測帯域から決めます。KFBの見立てでは、これは「128GBの箱を買う競争」を「手元の資源を推論へ変換する競争」へ変える提案です。
本稿の目的は、FreeTokenがDGX Sparkより速いと断定することではありません。DGX Sparkを買う前に、手元のPCで不足しているものを測ることです。
編集方針: 本稿はFreeTokenの設計思想を高く評価する立場で整理します。FreeToken/FlashMLから金銭、機材、記事監修の提供は受けていません。
検証区分: 2026年8月23日に論文、公式リポジトリ、公式ドキュメントを照合した机上調査です。KFBがFreeTokenをインストールした結果ではありません。
ベンチマーク: 数値はFreeToken開発チームによる論文報告で、独立測定でもDGX Sparkとの直接比較でもありません。
名称: 本稿のFreeTokenはFlashML-org/FreeTokenです。名称の似たfreetoken.aiとは別のプロジェクトです。
FreeTokenは何を変えるのか
大規模MoEでは、モデル全体に多数のexpertがあっても、1トークンが実際に使うのは一部です。たとえばFreeToken論文はDeepSeek-V4-Flashについて、全284Bパラメータのうち1トークンで有効になるのは13Bと説明します。計算量は疎でも、すべてのexpert重みを保管する容量は必要です。
従来の「GPUに入る部分を固定し、残りをCPUへ任せる」方法では、会話内容が変わるたびに選ばれるexpertも変わり、必要なexpertがVRAMにない状態になって転送待ちが発生します。FreeTokenはPC全体を次の二層として扱います。
- ホストメモリに全expertの重みを置く
- GPUの空きVRAMを、全レイヤーで共有する動的なexpert cacheにする
- cache missをPCIe転送+GPU計算とCPU計算へ分け、同時に進める
- contextが伸びたら、schedulerの安全な時点でexpert cacheとKV cacheのVRAM配分をエンジン再起動なしに組み替える
FreeTokenの本質は、小さなGPUへ巨大モデルを「収納する」ことではありません。GPUだけをコンピュータだと考えるのをやめ、CPU、RAM、PCIeまで含めた不均一な一台を推論装置として使うことです。
FreeToken贔屓になる4つの理由
1. スペック表ではなく実測帯域で仕事を分ける
cacheにないexpertは、PCIe経由でGPUへ送るか、ホストメモリ上のままCPUで計算する必要があります。どちらが速いかは、GPU型番だけでは決まりません。FreeTokenのq* policyは、expert転送帯域とCPU側expert処理帯域を対象マシンで測り、missを両経路へ配分します。
公式の対応モデル文書では、ft bench bwでマシンごとの帯域を校正し、条件が合えばhybrid backendを選ぶと説明されています。「RTX 5090だからこの設定」という固定表より、実際のCPU、RAM、PCIeへ合わせる方が、ローカルAIらしい設計です。
2. expert cacheが会話についてくる
FreeTokenは、ロード時やprefill後のexpert配置に固定せず、decode時のroutingに合わせてLRU cacheを更新します。論文のrouting traceでは、RTX 5090相当のcache容量でQwen3.6のmiss率を16%、DeepSeek-V4-Flashを39%とし、同容量の静的配置より低いと報告しています。
重要なのは、同じexpertが近接するtokenで再び選ばれやすいという局所性を、VRAMの価値へ変えている点です。VRAM容量だけでなく、何を残すかが性能になります。
3. エージェントの長い会話を正面から測っている
短い単発評価だけでなく、FreeToken論文はAIME、OpenCode+SWE-bench、Claude Code+SWE-bench、OpenClawのメール・カレンダー操作という4種類のworkloadを使いました。tool call後の履歴編集やthinking blockの削除でcontextが変わっても、semantic boundaryに置いたstate checkpointから再利用し、新しいsuffixだけをprefillする設計です。
ローカルLLMは最初の1回答だけ速くても、agentが数十分働く途中で待ち時間が破綻すれば使えません。FreeTokenがdecode平均と平均time to first token(TTFT)に加え、worst turnのtailも確認した点を、KFBは高く評価します。
4. APIの入口が現実的
公式Quick Startによると、FreeTokenはOpenAI互換の/v1/chat/completions、/v1/responses、/v1/modelsと、Anthropic互換の/v1/messagesを提供します。既存clientのbase URLをローカルserverへ向けやすく、ft launchはCodex、Claude、OpenCodeなどの起動導線も用意します。
互換APIがあることは、すべてのtool callやclient機能が完全互換という保証ではありません。それでも、速いkernelだけで終わらず、実際のagentへつなぐ表面まで用意したのは大きな長所です。
開発者ベンチマークはどこまで強いか
FreeToken論文は、6台のNVIDIA GPUシステムと4種類のagent workloadで評価しています。以下はすべて著者報告で、KFB実測ではありません。
| 構成 | モデル・条件 | 論文報告 |
|---|---|---|
| RTX 5090 32GB | Qwen3.6-35B-A3B BF16 | 77〜83 tok/s。各workloadの最速baselineに対して1.8〜2.3倍 |
| RTX 5090 32GB | DeepSeek-V4-Flash MXFP4 | 22〜25 tok/s。最速baselineに対して1.5〜1.9倍 |
| RTX 4060 Laptop 8GB+RAM 32GiB | Qwen3.6-35B-A3B NVFP4 | 39.3 tok/s |
| RTX PRO 6000 96GB+RAM 512GiB | GLM-5.2 NVFP4、433GB checkpoint | 14.9 tok/s。llama.cppは7.3 tok/s |
RTX 5090、4090、3090の一部評価機はレンタルのdual-socket serverで、著者はCPU thread数とNUMAを制限し、consumer機に近いホスト帯域へ合わせています。RTX 5090 desktopとRTX 4060 laptopは実機です。モデル、量子化、RAM、PCIe、cache状態が違えば速度も変わります。
また、GLM-5.2が96GB VRAMへ全部収まったわけではありません。433GBのcheckpointと完全なexpert poolを512GiBのホストメモリ側へ置き、GPUを動的cacheとして使った結果です。「96GB GPUだけで753B」という読み方は誤りです。
論文では、各baselineは少なくとも1条件でworst turnが150秒を超えた一方、FreeTokenは全条件で44秒未満だったと報告します。ただしagentごとに実行経路が変わるため、著者はengine間の総経過時間を比較していません。FreeTokenを常に最速と一般化せず、長いagent workloadで失速しにくいという著者側の証拠として読みます。
DGX Sparkとの比較で誤解してはいけないこと
FreeTokenはDGX Spark用の高速化ソフトではありません。CLI版の公式インストール要件はLinux x86_64、NVIDIA GPU、driver r580以上、CUDA 13、Python 3.10以上です。初回のCUDA kernel JITにはCUDA 13 Toolkitとnvccも必要です。
一方、DGX Sparkは20コアArm64 CPUとBlackwell GPUが128GB LPDDR5xを共有するUMAです。FreeToken論文の評価機にDGX Sparkはなく、公開CLIの導入要件もx86_64が前提です。2026年8月23日時点で、DGX Sparkでそのまま動く、同じ速度になるとは書けません。
| 比較軸 | DGX Spark | FreeTokenの公開CLI経路 |
|---|---|---|
| 考え方 | 128GB UMAを備えた専用AI機を買う | 既存PCの離散GPU、CPU、RAM、PCIeを束ねる |
| CPU環境 | Arm64 | Linux x86_64 |
| メモリ経路 | CPU・GPU共有 | ホストRAMとVRAMをPCIeで接続 |
| 得意な価値 | 一箱の基準環境、128GB、DGX OS、ConnectX-7 | MoEの動的offload、手持ち機材の再利用 |
| 相互検証 | FreeTokenのDGX Spark対応・直接性能比較は未確認 | |
この違いが、むしろFreeTokenを先に試す理由です。FreeTokenが既存x86_64 PCの目標モデルでagent運用を成立させられれば、DGX Sparkを買わずに済む可能性があります。満たせなければ、RAM帯域、PCIe、容量、互換性のどこが不足したかを確認してから、専用機、workstation GPU、cloudを選べます。
「無料のtoken」ではない
FreeTokenのrepository本体はApache License 2.0ですが、読み込むモデルのlicenseは別です。モデルデータのdownload、数十〜数百GBの保存領域、ホストRAM、電力、保守時間も無料ではありません。名称だけを見て「API tokenが無制限に無料」と解釈してはいけません。
公式配布ページにはWindows desktop版もありますが、公開ソースで確認できるCLIの公式導入要件はLinux x86_64です。本稿では再現条件を曖昧にしないためCLI経路を基準にしています。Windows desktop版の互換性と性能はKFB未検証です。
公式のknown-goodモデル一覧にはDeepSeek-V4-Flash、GLM-5.2、Qwen3.6/3.5 MoE、gpt-oss、Gemma-4、MiniMax-M2.5などがあります。ただし、multimodal checkpointはtext-only提供と明記されています。「20以上のMoEに対応」という論文の表現も、全モデルが全GPUで同じ速度になる意味ではありません。
先に試す人、まだ待つ人
| 判断 | 条件 |
|---|---|
| FreeTokenを先に試す | Linux x86_64、対応NVIDIA GPU、CUDA 13、十分なホストRAMとSSDがあり、MoEモデルをagent用途で継続利用したい |
| 環境整備から始める | GPUはあるが、driver、CUDA Toolkit、RAM容量、PCIe接続、モデルlicenseをまだ確認していない |
| DGX Sparkも比較する | 128GB UMA、DGX OS、Arm64基準環境、ConnectX-7、複数台運用が仕事の要件になっている |
| 待つ | Windows desktop版だけで完結させたい、企業supportが必要、独立測定や長期安定性を優先する |
試す場合は、いきなり新しいGPUを買う必要はありません。公式手順に沿って環境と対応checkpointを確認し、ft bench bwで帯域を測り、同じprompt、context、出力token数で現在のruntimeと比較します。見るのはdecodeだけでなく、最初のtokenまでの時間、2回目以降のturn、RAM使用量、再起動時間です。
測定してホストRAM不足が確認できた場合だけ、増設を検討します。DDR5はDDR4と互換ではなく、デスクトップ用DIMMとノート用SO-DIMMも形状が異なります。PCまたはマザーボードの仕様とQVLや互換性情報を確認し、FreeToken、モデル、OSが使う容量を見積もってから選んでください。
PURCHASE CHECK
FreeToken用のホストRAMを確認
ft bench bwと実行時のRAM使用量を測り、不足が確認できた場合だけDDR5増設を検討するための導線です。容量を増やしても対応モデルや速度を保証するものではありません。
互換性の注意まず既存RAMで測定し、モデル、量子化、OSが使う分を含めて必要容量を決めてください。
独自視点:FreeTokenは「購入前ベンチマーク」である
KFBはFreeTokenを、DGX Sparkの代替製品ではなく、DGX Sparkを買わずに済むか判定する購入前ベンチマークと捉えます。
ハードウェア比較は、VRAM、理論FLOPS、メモリ帯域を並べるところで止まりがちです。しかしFreeTokenが示したのは、MoEではexpertの配置、cache missの処理、context再利用が、同じ機材から得られる体験を大きく変える可能性です。新しい箱の価格を比べる前に、手元の箱をどこまで使えるか測るべきです。
FreeTokenが成熟し、第三者測定でも設計上の優位が確認されるなら、ローカルAI市場で最も大きく値下がりするのはGPUではありません。「大容量専用機を買わないとfrontier級MoEへ触れない」という思い込みです。私はそこに賭けたいと思います。
よくある質問
FreeTokenはDGX Sparkで動きますか?
2026年8月23日時点では確認できません。公開CLI要件はLinux x86_64で、DGX SparkはArm64+UMAです。公式評価にもDGX Sparkは含まれません。移植や独自buildの可能性を、公式対応と同一視しないでください。
RTX 4060 Laptop 8GBで35Bが必ず39.3 tok/s出ますか?
出るとは限りません。39.3 tok/sはQwen3.6-35B-A3B NVFP4、RAM 32GiB、論文記載の1台で得られた著者測定です。GPU、CPU、RAM、PCIe、driver、cache、workloadが変われば結果も変わります。
FreeTokenはllama.cppやOllamaを置き換えますか?
すべての用途を置き換えるとは言えません。FreeTokenが特に狙うのは、全expert poolがVRAMを超えるMoEと長いagent workloadです。小型dense model、対応platformの広さ、既存運用の安定性では別runtimeが自然な場合があります。
FreeTokenは無料ですか?
repositoryはApache 2.0で公開されていますが、モデルのlicense、機材、電力、保存領域、運用費は別です。freetoken.aiの料金やcloud tokenとも無関係です。
まとめ
FreeToken贔屓で言えば、DGX Sparkを買う前にFreeTokenを試すべきです。それで十分なら高価な専用機を急いで買う理由が一つ減ります。足りなくても、容量、帯域、互換性、保守のどこへ投資すべきかが見えます。
ただし、現時点の強い数値は開発チームの測定で、CLI要件はLinux x86_64+NVIDIA GPU+CUDA 13です。DGX Spark/Arm64、Windows desktop版、長期安定性、全モデルの再現性は未確認です。贔屓するからこそ、魔法の万能runtimeには仕立てません。
DGX Sparkが「AI用の箱」を売る製品なら、FreeTokenは「いまある箱の見方」を変えるソフトです。2026年のローカルAIで先に試す価値があるのは、後者だとKFBは見ます。
参考資料
- FreeToken論文:Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution(v1、2026年8月17日)
- FlashML-org:FreeToken公式repository(2026年8月23日確認)
- FreeToken:Install requirements(2026年8月23日確認)
- FreeToken:Supported models and MoE backends(2026年8月23日確認)
- FreeToken:Quick Start and compatible APIs(2026年8月23日確認)
- FlashML:FreeToken配布ページ(2026年8月23日確認)
- Crucial:DDR5デスクトップメモリとDDR世代の互換性(2026年8月23日確認)
- Crucial:QVLとメモリ互換性の確認(2026年8月23日確認)
- NVIDIA:DGX Spark Hardware Overview(2026年8月23日確認)
- NVIDIA:DGX Spark System Overview(2026年8月23日確認)
- NVIDIA:ConnectX-7 Networking(2026年8月23日確認)


