2026-08-27·★ 会員·論文·18分で読めます

論文解説: FreeToken — 手元のPCを「一台の推論基盤」として使い切る帯域適応型MoEサービング

公開重みの巨大MoEを、データセンターではなく手元のPCで動かすためのサービング系FreeToken。ミスしたエキスパートをPCIeで運ぶかCPUでその場で計算するかを、実測した2つの帯域の比だけで決めるq*ポリシーを中心に読み解く。

#moe #llm-serving #edge-inference #agents #systems

対象textタスクagents

FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution

一次資料 — この記事の根拠

論文の発表 2026-08-17→この解説の公開 2026-08-27同月

FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive ExecutionShuo Yang, Xiaoze Fan, Melissa Pan ほか · 2026-08-17 · v1arXiv:2608.16157論文ページ·PDF

原文の要旨（Abstract）を読む

Frontier open-weight models are increasingly available, but serving them still largely assumes datacenter infrastructure. We present FreeToken, an edge-native MoE serving system that treats a personal machine not as a small GPU, but as a unified, elastic inference platform. FreeToken co-designs the full serving stack, including model layout and loading, expert residency, CPU--GPU execution, agentic state reuse, and runtime memory management, around two realities of local AI: agent workloads continuously change their execution pattern, and edge hardware exposes heterogeneous resources whose balance differs from machine to machine. Rather than committing to a fixed offloading strategy, FreeToken continuously maps computation and model state onto the resources actually available. FreeToken supports more than 20 MoE models and real coding and tool-using agents across hardware ranging from an 8GB laptop GPU to a single workstation GPU. More importantly, it changes what these machines can practically serve, from a 35B model on a laptop to a 284B model on a gaming desktop and the 753B GLM-5.2 on a single workstation GPU. FreeToken turns open weights into deployable local software, making the machines users already own a practical platform for frontier-scale intelligence. We release the system at flashml.ai.

「重みが公開された」は「動かせる」ではない

レシピが無料公開されても、業務用オーブンを持たない人はそのケーキを焼けません。パラメータを公開する行為が決めるのは「誰がモデルを手に入れられるか」だけで、「誰がそれを走らせる余裕があるか」ではない——論文はこの区別から始まります（§1）。エージェントが普及するほど推論需要は跳ね上がるので、能力のギャップより、アクセスのギャップのほうが閉じるのが遅い。

ところがディスクリートGPUを積んだ個人所有のマシンは1億台以上ある、と論文は見積もります。Steamだけで月間アクティブ2億人超、調査対象のおよそ72%にNVIDIAのディスクリートGPUが載っている（§1）。足りないのはハードウェアではなく、構成がバラバラな消費者向けマシンを一台の推論基盤として束ねるサービング系のほうだ、というのがFreeToken（2026年8月17日公開）の立場です。

MoEは扉を開けると同時に、別の扉を閉める

MoE（混合エキスパート）は1層に $E$ 個のエキスパートを持たせ、トークンごとに $k \ll E$ 個だけを通す構造です（仕組みはMixture of Expertsを参照）。

論文の例が分かりやすい。DeepSeek-V4-Flashは43層それぞれに256個のルーテッド・エキスパートを持ち、1トークンにつき6個だけ起動します。284Bのうち計算に関与するのは13B。配備時の精度なら、この「実際に動く分」はRTX 5090の32GBに収まります（§1）。

閉じる扉のほうはこうです。スパース性が減らすのは1トークンあたりの計算量であって、エキスパート全体を置くのに必要なメモリではない（§1）。全エキスパートの重みはGPUメモリを大きく超えるので、使われていない分はホストメモリやSSDに置かれ、呼ばれたときに実行経路へ入ってきます。

壁1: プレフィルではスパース性が消える

デコード時は1トークンが $k$ 個しか使いませんが、プレフィルは1層あたり数千トークンをまとめて流します。経路を全部合わせると、ほぼ全エキスパートが起動される（§2.1）。スパースだったはずの作業集合が実質的に密になるのです。

論文の数字では、DeepSeek-V4-FlashのFP4配備は約140GBのエキスパート重みの転送を要し、RTX 5090（PCIe 5.0 x16、約60GB/s）で約2秒、4090・3090クラス（PCIe 4.0 x16、約25GB/s）で約5秒、ノートに多いx8リンクでは10秒以上をプレフィルのたびに上乗せします。オンデマンドで取りに行くエンジンは、この時間をまるごとGPUのアイドルとして露出させます。

FIG 1ルータ出力の分布。温度を下げると少数のエキスパートに票が集中し（デコードの局所性に近い）、上げると平らになって「結局ほぼ全員が呼ばれる」プレフィルの状況に近づく。※直感のための図で、論文がルータ温度を操作しているわけではない

もうひとつが再プレフィルです。最近のモデルはハイブリッド注意（DeepSeek-V4-Flash、GPT-OSS）やリカレント層（Qwen3.6-35B-A3Bのgated DeltaNet、Kimi-K3のKimi Delta Attention）を使い、過去の文脈を1つの状態に圧縮します。KVキャッシュと違い途中から部分再利用ができず、保存した状態1つが数百トークン分のKVに匹敵するので、チェックポイントは少ししか置けない。ところがエージェントはほぼ毎ターン、古いツール出力や思考ブロックを削って文脈を書き換えます。編集位置より後のチェックポイントは全部無効になり、数千トークンの再プレフィルが走る。RTX 5090の密なBF16スループットはH100の約5分の1、B200の10分の1なので、これがGPUを数十秒占有します（§2.1）。

壁2: デコードのミスを「どう捌くか」が決まっていない

デコードは逆の世界です。1ステップで起動するエキスパートは少数ですが、GPU上に無ければ運ぶか、どこかで計算するしかありません。

既存エンジンは配置を読み込み時かプレフィル時に固定します。llama.cppは読み込み時にMoEテンソルをデバイスへ割り当て、KTransformersは「ホットな」部分集合をGPUに固定して残りをCPUで実行する（§2.2）。しかしルーティングはトークンごとに動くので固定配置が捕まえられるのはごく一部で、大半の評価がCPUに落ち、GPUもPCIeも遊ぶ（§5.3）。

かといってCPU一択にもできません。小さなデコードバッチではエキスパート実行はメモリ律速で、消費者向けCPUのDRAMは2チャネル止まり——デュアルチャネルDDR4で約50GB/s、DDR5で80〜90GB/s。対してRTX 4090・5090がオンパッケージメモリから引けるのは1〜1.8TB/sです（§2.2）。そして論文が強調するのは、正しい配分は機種ごとに違い、スペックシートからは読めないという点です。

壁3: エッジでは何ひとつ専有できない

GPUはコンポジタやブラウザやゲームと共有され、使える予算は起動のたびに違い、セッション途中でも増減します。しかも最適な分割自体が動く。エージェントはターンを重ねるほど文脈が伸びてKVキャッシュ需要が増える一方、エキスパートの作業集合はほぼ一定なので、初回ターンで決めた分割は何ターンも後には間違っている（§2.3）。起動コストも重く、約140GBのプールを7GB/sのNVMeから読むだけで約20秒かかります。

設計: 2階建てのエキスパート記憶

FreeTokenの土台は単純な2階層です（§3）。CPU常駐のエキスパートプールが全ルーテッド重みを持ち、これが常に正本（source of truth）。エキスパート以外の重みはGPU常駐。残りのGPUメモリは全MoE層で共有される1つの弾性的なエキスパートキャッシュにします。1スロットは「層×エキスパート」ペアの評価に必要なテンソルを丸ごと持つので、常駐判定も参照も実行も論理的な $(\text{層},\text{エキスパート})$ の上で行えます。

ここから出てくる性質が効いています。正本はホスト側なので、GPUメモリは性能にしか影響せず、正しさには決して影響しない（§3.3）。だからキャッシュをいつ縮めても広げても答えは変わらず、実行時の作り直しが成立します。

プレフィル: 全層ダブルバッファと「意味の錨」

転送を計算の裏に隠す。 どうせ全エキスパートが呼ばれるので、オンデマンドをやめます。スロットプールから2層分のバッファを取り、GPUが層 $l$ を計算する間に転送ストリームが層 $l+1$ の全エキスパートをもう片方へ流す。全層まるごと読むので、その層のルーティングが決まる前に転送を開始できるのが肝です。デコード用と同じスロットプールを共有するため専用キャッシュもフェーズ引き継ぎも無く、プレフィルを生き延びたエントリがそのままデコードを温めます。2層分取れない場合はオンデマンドにフォールバックし、メモリを超過契約しません（§3.1）。

意味の節目に錨を打つ。 リカレント層の再利用はチェックポイント頼みなので、少ない枠をどこに置くかが価値を決めます。FreeTokenは意味的アンカー——思考セグメント、ツール呼び出しと出力、会話ターンを区切る特殊トークンの境界——に置きます。根拠はエージェント側の実装です。OpenClawは最新以外の全アシスタントターンから思考ブロックを剥がし、OpenCodeは直近ウィンドウより古いツール出力を固定プレースホルダに置き換え、SWE-agentは最後の $n$ 個以外の観測を削る（§3.1）。いずれも消えるのは特殊トークンで区切られたブロック単位で、その手前の接頭辞はそのまま残る。だから境界の錨は任意位置の錨よりずっと生き残りやすく、生き残れば全注意層はKVを編集点まで再利用し、リカレント層は錨から再開して、本当に新しい末尾だけを再プレフィルすれば済みます。