VRAMに収まらないMoEモデルのデコードが約2倍になった｜FreeTokenとOllamaをRTX 5080で実測比較

同じGPU・ほぼ同じVRAM使用量でデコード速度が約2倍になった

RTX 5080 16GB 1枚でQwen3.6-35B-A3Bを走らせ、FreeToken 0.1.2とOllama 0.32.15を比べた。デコード速度の中央値は毎秒123.40トークンと毎秒61.30トークンで、比は約2.0倍だった。GPU側で使われたメモリ量の目安は13.51GiBと12.92GiBで、どちらもカードの容量に対して同じような水準に収まっている。

ただし最初のトークンまでの時間は逆で、こちらはOllama 0.32.15のほうが大きく速い。しかもデコード速度の中央値はサーバを起動し直すと1割ほど動く。倍率を小数まで固定した値として扱わず、約2倍として読むのはこのためである。

比較したのは「同じGPUで同じQwen3.6-35B-A3Bを、それぞれの対応形式で動かした」状態であって、推論エンジン以外がすべて同一の比較ではない。量子化方式はNVFP4とQ4_K_Mで異なり、実行環境もWSL2とWindowsで異なる。したがって速度差を取り寄せ経路だけの成果として説明することはしない。以降では、まずFreeTokenが何であるかと、GPUに載らない重みをどう扱う設計なのかを押さえ、そのうえで実測値と、その値がどこまでしか言えないのかを順に示す。

FreeTokenとは

FreeTokenはMoEモデル向けの推論エンジンで、2026年8月17日にarXivへ投稿された論文とともに公開された。投稿日はarXivの掲載情報による。論文はShuo Yangらによるもので、著者にはKurt Keutzer、Song Han、Matei Zaharia、Ion Stoicaが含まれる。著者は全11名で、ここに挙げたのはその一部である。

ライセンスはApache License 2.0で、公開リポジトリにその表示がある。ローカル推論の選択肢としてどのあたりに位置するかを他のエンジンと並べて見たい場合は、ローカルLLM推論エンジン比較も参照できる。

公式の対応モデル一覧はMoEを中心に挙げているが、Qwen3.6の密なモデル (dense) のように、MoEでないものも含まれる。2026年8月24日時点の公式ドキュメントの記載による。本記事が評価するのはMoEでの利用に限る。

配布の形は2系統ある。PyPIで配布されているのは0.1.2で、2026年8月19日公開、配布物はPython 3.10から3.13向けのmanylinux_2_27_x86_64ホイール4本である (2026年8月23日にPyPIのメタデータを参照して列挙した内容)。これとは別に、リポジトリの説明文はflashml.aiでWindows版とLinux版を配布していると案内している。後者はデスクトップアプリの案内で、PyPIで配布されているパッケージとは別のものである。

MoEのオフロードで何が起きているか

MoEは1トークンの生成でモデル内の一部のexpertだけを使う。総パラメータのうち実際に計算へ関わる割合は小さく、Qwen3.6-35B-A3Bの場合は名称のA3Bが示すとおり活性パラメータが約3Bにあたる。計算量だけを見れば、総パラメータの規模から想像するより軽い。

問題になるのは容量のほうである。1トークンで使うexpertが一部でも、どのexpertが選ばれるかは事前に決まらないため、重みは全体を手の届く場所へ置いておく必要がある。今回動かしたQwen3.6-35B-A3Bの重みはNVFP4で約21.8GiBあり、RTX 5080のVRAM 16GBには収まらない。どのモデルがVRAM 16GBに収まるかという前提の整理はVRAM 16GBで動かすローカルLLM完全ガイドにまとめてある。

収まらない分をホストメモリ側へ置き、必要なときにやり取りする手法そのものについてはVRAMに収まらない大型LLMをRAMオフロードで動かすで扱っている。MoEの場合はここに「毎トークン、選ばれるexpertが変わる」という条件が加わる。GPU側に置いておける分をどう選び、外れた分をどう間に合わせるかが、そのまま速度に効いてくる。

GPUに載らない分をどう間に合わせるか

FreeTokenのoffload方式では、ルータが選んだexpertをGPU側のキャッシュに置き、足りない分をPCIeで取り寄せる。キャッシュの中身はルータの選択に追従して入れ替わり、単位は層とexpertの組、置き換えは最近使われていないものから外す方式だと論文は記述している。本記事で観測した速度差は、この経路で動作した状態のものである。どこが詰まるかの整理はAI推論でメモリ帯域はどこに効くかにある。

論文は、デコード時にキャッシュから外れていて取りに行く必要があったexpertの割合を、この追従型で16%と39%、ルーティングを見ずに層で静的に分ける方式で62%と89%と報告している。RTX 5090で同一のキャッシュ容量条件下 (Qwen3.6のexpertプールの37%、DeepSeek-V4-Flashの11%にあたる容量) で比較した値で、2つの数値は2つのモデルそれぞれの値であって幅ではない。いずれも取りこぼした割合であり、本記事の測定ではない。

もう一方のhybrid方式は、取り寄せる分とホスト側で処理する分に振り分ける。論文は、デコード時にGPUキャッシュに無いexpertを、PCIeで転送する分とCPUで計算する分に分け、両者を同時に走らせて終了時刻が揃うように個数を決めると述べている。欠損expert数をm、PCIe転送帯域をB_P、ホスト側がexpertを処理する帯域をB_Hとする。B_Hはメモリを素で読み出す速度の上限ではなく、実際にexpertを処理するときの速度で、重みの形式によって変わる。PCIeのDMAはホストメモリから読むため、転送中にCPUが使える残余帯域を論文は max(B_H - B_P, 0) と置く。B_HがB_Pを上回る範囲で、転送側 q÷B_P と CPU側 (m−q)÷(B_H−B_P) を等置すると、転送に回す個数は m×B_P÷B_H になる。

どちらの方式で動くかは既定の自動選択で決まる。帯域プロファイルが揃っており、かつCPU側の処理帯域がPCIe帯域の2倍を超えるときにhybridが推奨され、それ以外はoffloadに解決される。2倍は既定の閾値で、比較に使うのはexpertを処理するCPU側のカーネルと、それに対応するPCIe側の取り寄せを実際に走らせて測った値どうしである。本記事の測定ではPCIe側のカーネル計測が取得できておらず、手元の構成がどちらに解決されるかは判定していない。実際の測定はプロファイル未生成のままoffloadで動作した。実行方式は明示的に指定することもでき、自動選択は既定の動作である。

論文自身の報告としては、Qwen3.6-35B-A3BについてRTX 5090で毎秒77から83トークン、最も速いベースラインの1.8倍から2.3倍という数値が挙げられている。これは論文の測定であり本記事の測定ではない。GPUはRTX 5090 32GBで、本記事のRTX 5080 16GBとは条件が異なる。出力長・文脈長・速度の取り方が揃っているかも確認していないため、本記事の値と並べて速さを比べる材料にはしていない。

測定の前提と評価しない軸

測定環境はRTX 5080 16GB 1枚、Core i7-14700F、メインメモリ96GB。モデルはQwen3.6-35B-A3B、出力512トークン、コンテキスト8192で、1回目をコールドとして除外し以降10回を計測した。サーバの起動から停止までを1セッションとして2回実施している。比較に使ったOllamaは現行安定Verの0.32.15のみで、2026年8月24日に公式リリース一覧で確認した時点の最新安定Ver、公開は2026年8月19日である。

Windows環境でコマンドライン版を動かすにはLinux側の実行環境が要るため、FreeToken側はWSL2上のUbuntu 24.04で動かした。ドライバはWindows側のものがWSL2から見える構成で、追加のドライバ導入はしていない。Ollama側はWindows上で動かしている。実行環境が違えばPCIeの実効帯域も同条件ではない。

量子化はFreeTokenがNVFP4、OllamaがQ4_K_Mで、ビット幅はどちらも4ビットだが方式は同一ではない。つまりこの比較は、推論エンジンだけを差し替えたものではなく、同じモデルをそれぞれの対応形式で動かしたものになる。量子化の方式ごとの差は量子化で27B級LLMはVRAM 16GBに載るかで扱っている。

実測: 生成速度・VRAM・最初のトークンまでの時間

項目	FreeToken 0.1.2	Ollama 0.32.15
生成速度 中央値 (1回目)	毎秒123.40トークン	毎秒61.30トークン
生成速度 中央値 (2回目)	毎秒132.97トークン	毎秒67.83トークン
生成速度 最小〜最大 (2回分)	毎秒121.52〜143.10トークン	毎秒60.19〜68.89トークン
最初のトークンまでの時間 中央値	447ミリ秒	83ミリ秒
GPU側で使われたメモリ量の目安	13.51GiB (うちKVキャッシュ0.16GiB)	12.92GiB
量子化	NVFP4	Q4_K_M

生成速度はどちらも最初のトークンまでの時間を除いたデコード時間で算出している。セッションを変えると中央値が1割ほど動くため、倍率は約2倍として扱う。

GPU側のメモリ量は取得方法がエンジンごとに違う。FreeTokenは起動時の空き14.59GiBと初期化後の空き1.08GiBの差から求めた約13.51GiB、Ollamaは常駐モデルとして報告される12.92GiBで、同一の指標ではない。どちらもVRAM 16GBのカードに対して13GiB前後という目安であり、4ビット相当で約21.8GiBあるモデルの一部だけがGPU側に置かれ、残りはホストメモリ側に置かれた状態での測定になる。数字が近いことは、内訳まで同じであることを意味しない。量子化方式が違えば重み以外の領域の取り方も揃っているとは限らない。

最初のトークンまでの時間は、両エンジンとも同じプロンプトを繰り返して前置きの再利用が効いた状態の値である。FreeTokenは直前までのやり取りを再利用するためのキャッシュを持ち、同じ前置きが続く限り最初のトークンまでの時間を短縮できる。実際、コールドの1回目は1,009ミリ秒、以降10回の中央値は447ミリ秒だった。論文は意味的な区切りに検査点を置く設計だと述べている。ただしコールド1回目には初回だけのセットアップ分も乗るため、この差を前置きの再利用だけの効果として切り分けてはいない。上の表の83ミリ秒との比較も、Ollama 0.32.15を相手に、前置きの再利用が効いた状態どうしで並べた値である。

デコードが速い側と、最初のトークンが速い側が入れ替わるので、総時間はどこかで逆転する。中央値から算出した目安が次の表になる。

比較相手	デコード速度の比	最初のトークンまでの差	総時間が逆転する出力長
Ollama 0.32.15 (1回目の測定)	約2.0倍	364ミリ秒 Ollamaが速い	約44トークン
Ollama 0.32.15 (2回目の測定)	約2.0倍	364ミリ秒 Ollamaが速い	約50トークン

D01の中央値から算出した (総時間 = 最初のトークンまでの時間 + 出力トークン数 ÷ 生成速度)。最初のトークンまでの時間は両エンジンとも前置きの再利用が効いた状態の値なので、この逆転点は同じ話を続けている最中の目安であり、毎回まったく違う入力を投げる使い方には当てはまらない。生成速度がセッションで動くため、逆転点も動く。

接続形態で帯域はどう変わるか

ここから先の2つの節は仕組みの話になる。結論だけ先に知りたい場合は「どういう構成なら効くか」まで飛ばしてよい。

FreeTokenには帯域を測る仕組みが同梱されている。ここで効いてくるのはGPUの枚数ではなく、その1枚がどう接続されているかで、x16で挿さっているのか、x4級に落ちる外付け経路なのかで値が変わる。手元にはその両方に当たる2枚があったので、それぞれに対して実行した結果が次の表である。CPU・メモリは同一で、実行はFreeTokenの要件に合わせてWSL2上で行った。レーン構成の選び方はAI用PCのマザーボードとPCIeレーンの選び方にまとめてある。

項目	RTX 5080	RTX 5060 Ti
接続	PCIe 5.0 x16	OCuLink (PCIe 4.0 x4)
CPU側のメモリ読み出し	毎秒65.9GB	毎秒69.3GB
PCIe ホストからGPUへ	毎秒41.57GB	毎秒6.98GB
PCIe GPUからホストへ	毎秒52.78GB	毎秒7.04GB
PCIe(ホスト→GPU) ÷ メモリ素読み出し	0.63	0.10

これは実推論とは別に実行する帯域校正ベンチマークの値で、推論中に実際に出ている帯域ではない。ハードウェアの上限を測る層の結果にあたる。実行方式の自動選択が見るのはこの層ではなく、expertを処理するカーネルとそれに対応するPCIe側の取り寄せを実際に走らせて測る層の値どうしの比だが、本記事の測定ではPCIe側のカーネル計測が取得できなかった。したがってこの表の値から実行方式の選ばれ方を判定することはできない。実行環境はPCIeの実効帯域に影響するため、絶対値ではなく2枚の間の開きとして読む。CPU側の読み出し速度は同一のCPUとメモリで測っているため、2枚の間の差は測定のばらつきである。

手元の構成がこの表のどちら側に近いかは、GPUを延長しているかどうかではなく、レーン数と世代で見る。ライザーはx16のまま延長するものが一般的なので、それならRTX 5080側の値に近い。x4に落ちる外付け接続を経由しているならRTX 5060 Ti側に近い。OCuLink経由の構成そのものについてはローカルLLMを2枚のGPUのVRAMプールで動かすでも扱っている。

同じ帯域校正ベンチマークのうち、expertを処理する実際のカーネルを走らせて測る層の結果が次の表になる。RTX 5080側での測定で、命令セットの欄はエンジンが選んだ実装を示す。

重みの形式	CPUでの処理速度	使われた命令セット
bf16	毎秒61.3GB	avx2
nvfp4	毎秒52.3GB	avx2+vnni
ds_fp4	毎秒49.8GB	avx2
mxfp4	毎秒27.0GB	avx2

重みの形式によってホスト側の処理速度が変わることが読み取れる。先の分担比の式でB_Hにあたるのがこの値で、形式が違えば同じ機材でも分担の計算結果は変わる。ただし前述のとおり、自動選択が見るもう一方の値 (PCIe側の取り寄せの実測) は取得できていないため、この表だけで方式が決まるわけではない。自分の構成でどちらが選ばれたかを知りたい場合は、起動時のログに出る実行方式を見るのが確実である。

計測ごとのばらつき

D01と同じ手順で、サーバの起動から停止までを1セッションとして2回ずつ測り、生成中に記録したGPUの状態も併せて確認した。

項目	FreeToken 0.1.2	Ollama 0.32.15
1セッション内の生成速度の幅	毎秒12.0〜13.8トークン	毎秒2.0〜3.5トークン
セッション間の中央値の動き	毎秒123.40と132.97トークン	毎秒61.30と67.83トークン
GPUクロック	2850〜2857MHz	2842〜2865MHz
GPU温度	49〜58度	45〜61度
消費電力	168〜173W	102〜109W
スロットリング要因	全回で検出なし	全回で検出なし

1セッション内で見ても、セッションをまたいで見ても、FreeToken側の振れ幅のほうがOllama側より大きい。ばらつきの原因は特定できていない。記録したGPU側の指標 (クロック・温度・電力・スロットリング要因) には、ばらつきを説明できる明確な変化は見られなかった。ただしPCIeの実効帯域、ホストメモリ、CPUのスケジューリングなどは記録していないため、ハードウェア側の要因を網羅的に排除したわけではない。消費電力に差があることも観測として記すにとどめ、その原因を確かめる対照は取っていない。

実務上の意味としては、1回測って得た数値をそのまま持ち歩かないほうがよい、ということになる。中央値が1割動く前提で、比は約2倍という粒度で扱うのが妥当な範囲である。

導入の現実

公式の導入手順が示すシステム要件は「Linux x86_64, NVIDIA GPU, driver r580+ (CUDA 13)」である。2026年8月24日に確認した公式ドキュメントの記述で、これはPyPIで配布されるパッケージとコマンドライン版についての要件にあたる。デスクトップアプリは別に案内されており、リポジトリの説明文はflashml.aiでWindows版とLinux版を配布しているとしている。つまり「Linuxでしか動かない」と一般化できる話ではなく、どの配布物を使うかで前提が変わる。

PyPIで配布されている0.1.2の配布物は、Python 3.10から3.13向けのmanylinux_2_27_x86_64ホイール4本である。この形である以上、Windows環境でコマンドライン版を動かすにはLinux側の実行環境が要る。本記事ではWSL2上のUbuntu 24.04で動かした。ドライバはWindows側のものがWSL2から見える構成で、追加のドライバ導入はしていない。

導入手順そのもの、たとえばどのコマンドをどの順で実行するかについては、公式の導入手順に譲り、本記事では踏み込まない。ここで押さえておく点は、公式が案内している要件と配布物の形が2系統に分かれていること、そしてコマンドライン版を使う限りWindows単体では完結しないことである。

どういう構成なら効くか

実測から言えるのは、次の条件の重なりである。GPU 1枚のVRAMにMoEモデルの重みが収まりきらず、あふれた分をホストメモリ側に置いて動かしていて、しかも出力がある程度の長さになる用途。この場合はデコード時間が総時間の大半を占めるため、デコードが速い側の利点がそのまま出る。上の逆転点の表がその目安になる。

逆に効きにくいのは、出力が数十トークンで終わる短い応答を何度も投げる使い方である。最初のトークンまでの時間はOllama 0.32.15のほうが速く、前置きの再利用が効いた状態でも差が残るため、総時間では逆転しうる。また重みがVRAMに収まってしまう規模のモデルは、そもそもこの記事が測った状況ではない。

ホストメモリ側にどれだけ余裕が要るかの目安を、代表的なモデルで並べておく。この表は代表的なものを並べたもので、対応モデルの一覧ではない。

モデル	量子化	重みの合計	現実的なホストメモリ
gpt-oss-20b	MXFP4	約12.8GiB	32GBで余裕がある
Qwen3.6-35B-A3B	NVFP4	約21.8GiB	32GBに収まる
gpt-oss-120b	MXFP4	約60.8GiB	64GBでは実質収まらない
DeepSeek-V4-Flash 284B	MXFP4 (routed experts)	約140GB (論文記載のexpert重みのみ・10進GB)	192GB級
GLM-5.2 753B	NVFP4	約433GB (論文記載のcheckpoint容量・10進GB)	512GiB (論文が使った機材の実装容量)

この表は収まるかどうかの容量の目安であって、速度を測ったものではない。速度を実測したのはQwen3.6-35B-A3Bの1本だけで、ここに並べた他のモデルが同じように速くなるとは言えない。また重みだけの容量なので、OS・実行時の作業領域・文脈の長さに応じた領域は別に要る。本記事が算出した値は2進接頭辞のGiB、論文が記載している近似値は10進のGBのまま載せている。

行ごとに対象範囲も違う。上の3行は重みファイル全体の合計で、gpt-ossの2行は公式リポジトリの model.safetensors.index.json が持つ total_size を参照した値である (gpt-oss-120bが65,248,815,744バイトで約60.8GiB、gpt-oss-20bが13,761,264,768バイトで約12.8GiB)。DeepSeek-V4-Flashの行は論文が挙げるexpert重みのみで、論文はこのexpert重みを約140GBと記載し、routed expertはMXFP4で量子化されていると述べている。GLM-5.2の行は重みテンソルの合計ではなくcheckpoint全体の容量である。論文がこの753Bのモデルを動かした構成は、VRAM 96GBのRTX PRO 6000とホストメモリ512GiBのワークステーションで、checkpointの容量は約433GBだった。最後の行の「現実的なホストメモリ」は重みからの見積もりではなく、論文が使った機材の実装容量をそのまま記している。より大きなモデルの必要量は巨大オープンモデルは手元で動くのか比較で扱っている。

まとめ

16GBのGPUに収まらないMoEモデルを動かしている構成で、推論エンジンの選択は用途によって答えが分かれる。長めの出力を待つ使い方ならデコードの速い側が効き、短い応答を何度も返す使い方なら最初のトークンまでの時間が効く。どちらを取るかは、手元の出力長がおおよそどのあたりに落ちるかで決めればよい。

その判断に添えておく条件が3つある。1つ目は、今回の比較が同じモデルをそれぞれの対応形式で動かしたものであり、量子化方式も実行環境も揃っていないこと。差の原因を取り寄せ経路だけに帰属させることはできない。2つ目は、測定がoffload方式・GPU 1枚・単一プロンプトの条件に限られ、hybrid方式との比較も複数GPUでの推論も測っていないこと。3つ目は、今回使ったコマンドライン版がLinux x86_64を要件としており、Windows環境ではLinux側の実行環境を用意する前提になること。デスクトップアプリは別に案内されているため、ここはどの配布物を選ぶかで変わる。

測定値そのものについても、セッションを変えると中央値が動くという性質があった。1回の計測を確定値として扱わず、幅を持った目安として読むほうが実態に合う。

参考資料

• FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution (arXiv)
• FreeToken 公開リポジトリ
• FreeToken 導入手順 (docs/install.md)
• FreeToken 対応モデル一覧 (docs/models.md)
• Ollama リリース一覧