8月23日、MarkTechPostが「Meet FreeToken: An Edge-Native MoE Serving Engine that Runs 753B GLM-5.2 on a Single Workstation GPU」と題した記事を公開した。Kimi-K3、GLM-5.2、DeepSeek-V4-Flashといったフロンティア級のオープンウェイトモデルが続々と登場しているが、「パラメータを公開すること」と「実際に動かせること」は別の話だ。これらのモデルを動かすには依然としてデータセンター級のGPUクラスタが前提とされており、個人開発者や小規模チームにとってのコスト負担は重い。UC BerkeleyとUT Austinの研究チームが提案するFreeTokenは、この問題に正面から取り組むエッジネイティブ推論エンジンだ。

FreeTokenが出す数字

FreeTokenは、GPU・CPU・メモリ・PCIe帯域を統合した弾性的な推論プラットフォームとして個人のマシンを活用する設計で、以下のスループットを報告している。

• 35Bモデル：VRAM 8GBのラップトップGPU（RTX 4060）で 39.3 tok/s
• 284Bモデル（DeepSeek-V4-Flash）：ゲーミングデスクトップで 22–25 tok/s
• 753B GLM-5.2：ワークステーション用GPU（RTX PRO 6000）1枚で 14.9 tok/s

既存エンジン（llama.cpp・KTransformers・Ollama）と比べてデコードスループットで 1.5〜2.3倍を達成している。

なぜMoEはエッジで動かしやすいはずなのか

MoE（Mixture-of-Experts）は、各トークンの処理時に全パラメータを使わない設計だ。たとえばDeepSeek-V4-Flashは43層それぞれで256のルーティング済みエキスパートのうち6つしか活性化しないため、284Bのパラメータ全体のうち実際に計算に参加するのは約13Bにとどまる。

この「スパース性」があるため、原理的にはエッジでの推論に向いている。ただし問題がある。アクティブでないエキスパートもメモリには全部載せておく必要がある。FP4量子化でもDeepSeek-V4-Flash全体は約140GBに及ぶため、使われないエキスパートはホストメモリに待機し、必要に応じてGPUへ転送される。

既存エンジンの3つの失敗パターン

FreeTokenの論文は、既存エンジンが抱える問題を3点に整理している。

1. プリフィルがスパース性を壊す：数千トークンを一括処理するプリフィルでは、ほぼ全エキスパートが呼び出され、PCIe経由でエキスパートプール全体をストリームする羽目になる。RTX 5090でも約2秒、PCIe 4.0デスクトップで5秒、ラップトップの×8リンクでは10秒以上かかる。

2. 静的なエキスパート配置がデコードのトラフィックと合わない：llama.cppはMoEテンソルをロード時に割り当て固定し、KTransformersは「ホット」なサブセットをピン留めする。しかしルーティングはトークンごとに変化するため、大半のエキスパート計算がCPU側に落ち、GPUとPCIeリンクがアイドルになる。

3. コンシューマー向けCPUが帯域不足：デュアルチャネルDDR5は80〜90 GB/sに留まり、RTX 4090/5090のオンパッケージメモリが持つ1〜1.8 TB/sには遠く及ばない。

FreeTokenの3つのコア機構

帯域適応型実行（q*ポリシー）

FreeTokenの中核となる仕組みだ。PCIe転送とCPUエキスパート実行は同じホストメモリサブシステムを参照する。PCIeがホスト帯域B_Hの一部B_Pを使うと、残りの帯域B_H − B_PでCPUがエキスパートを並行計算できる。

各ステップでキャッシュミスが発生したエキスパート数をmとすると：

q* ≈ m × B_P / B_H 個をGPUキャッシュに転送し、残りをCPUで直接計算

両者の部分和を最後に合算する。ルーターの変更も近似も一切なく、出力はビット単位で同一だ。この分割比は実機プロファイリング（ft bench bw）によって決定され、RTX 5090サーバーでは52.7:77.3、4060ラップトップでは11.8:47.5と大きく異なる。

セマンティック認識キャッシング

プリフィル中はレイヤl+1の転送とレイヤlのGPU計算をダブルバッファリングで重ねる。また、「思考ブロック」「ツール呼び出し」「ツール出力」といった特殊トークン境界にリカレント状態のチェックポイントを置く。エージェントのコンテキストが途中で切り詰められる場合、追加された末尾部分だけを再プリフィルすれば済む。

デコード中は全MoEレイヤをまたぐ共有LRUエキスパートキャッシュがルーターの動きに追随する。等キャパシティ条件（Qwen3.6プールの37%）での比較では、FreeTokenのキャッシュミス率は**16%**に対し、KTransformersは41%、llama.cppは62%だった。

弾性メモリ管理

スケジューラのセーフポイントで、エンジンを再起動することなくGPUエキスパートキャッシュを再構築できる。エキスパートはディスクからホストの最終レイアウトへ直接読み込まれてピン留めされ、初回リクエストはコールドキャッシュのまま処理される。

数値の検証：クリーンだが独立再現はない

記事内の「Data Check」セクションは率直だ。16クレームのうち独立検証済みは3つにとどまり、9つは自己報告、4つには「ミスリーディング」のフラグが立っている。このフラグは論文著者自身による記載ではなく、記事執筆者による第三者評価として付与されたものだ。

主な注意点：

• 「Codexの33 tok/sを超えた」という比較は指標が異なる。FreeTokenの39.3 tok/sは純粋なデコード速度だが、比較対象のTraceLab 33.9 tok/sはTTFTを含む正規化レート。同論文でのCodexの純粋デコード中央値は57.1 tok/sであり、like-for-likeでは上回っていない。

• 「RTX 4090の92%」という比較は量子化が異なる。39.3 tok/s（NVFP4）対42.9 tok/s（BF16）の比較で、精度フォーマットが揃っていない。

• 「GPU1枚で753B」というフレーミングはVRAMの話。実際には、753Bモデルを動かすワークステーション構成にはXeon Platinum 8559C上に512 GiBのDDR5が、284Bの「ゲーミングデスクトップ」構成でも192 GBのホストDRAMが必要だ。192 GBのDDR5を搭載する構成はサーバー向けマザーボードとECCメモリを前提とし、コンシューマー向けPCとしての一般的な価格帯とは大きく異なる点に注意が必要だ。

一方、論文内の全比率は数値から正確に再計算可能であり、不正な水増しは確認されていない。コードが公開されてから6日後の時点での監査であり、独立した再現実験はまだ存在しない。

即座に使えるか

Apache-2.0でGitHubに公開済みで、PyPIからは：

uv pip install "freetoken[accel]"

でインストールできる。Windows/Linux向けのワンクリックデスクトップアプリもflashml.aiで配布されている。ft serveでポート1919にOpenAI・Anthropic互換のエンドポイントが立ち上がり、ft launch claudeでClaude CodeやCodexを手元のボックスに接続できる。

CLIはLinux x86_64＋NVIDIAドライバr580以降（CUDA 13）が対象だ。

論文が想定するユースケースとして明記されているのは、ローカルコーディングエージェント、プライベートコードレビュー、オフラインでの契約書分析、合成データ生成、バッチ評価などだ。データをマシン外に出せないヘルスケア・法律・国防・金融・IP集約型R&Dといった分野向けの用途も挙げられている。

詳細はMeet FreeToken: An Edge-Native MoE Serving Engine that Runs 753B GLM-5.2 on a Single Workstation GPUを参照していただきたい。