AIと実装01；RTX 5090一枚で125B級MoEはどこまで動く？ ―FreeTokenでQwen3.8-Flash-Nextを約65 tok/sで動かして見えたもの―

これまでこのブログでは、AIを哲学、生物学、統計学といった少し抽象的な方向から考えることが多かった。

今回は少し毛色を変えて、もっと物理的な話をしたい。

巨大なAIモデルを、自宅のPCで実際に動かすと何が起きるのか。

RTX 5090のVRAMは32GBしかない。

それでも、125Bパラメータのメインモデルを持つQwen3.8-Flash-Nextを、ローカルPCで実用的な速度で動かすことはできるのだろうか。

FreeTokenを使って試したところ、手元のRTX 5090＋RAM 128GBのワークステーションで、Qwen3.8-Flash-Next NVFP4を実際に起動できた。

短いプロンプトで測定したsteady-stateのDecode速度は、3回平均で65.07 tok/s。TTFT（最初のトークンが返るまでの時間）は約2.4〜3.6秒だった。

ただ、今回面白かったのは「65 tok/s出た」という結果そのものではない。

FreeTokenの帯域benchmarkでPCIe転送速度が約29GB/sしか出ていないことが気になり、原因を追っていった。

すると、SSDとGPUのPCIe lane sharingにたどり着いた。

そして実は、この29GB/sという数字は「遅い」のではなかった。

現在のPCIe 5.0 x8という物理構成で使える帯域を、ほぼ使い切った結果だった。

さらに調べていくと、ホストRAM（CPU側の主記憶）も物理的な帯域上限のかなり近くまで使われていた。

この記事では、FreeTokenが何をしているのか、Qwen3.8-Flash-NextをRTX 5090一枚で動かしたときに何が起きたのか、そしてローカルLLMではGPUだけを見ていても性能を理解できない理由を整理する。

TL;DR

今回の結果だけ先にまとめる。

項目	結果
GPU	RTX 5090 32GB
CPU	Ryzen 9 9950X3D
RAM	DDR5 128GB（実動作 3600 MT/s）
Model	Qwen3.8-Flash-Next NVFP4
Runtime	FreeToken 0.1.2
MoE backend	offload
Context設定	32,768 tokens
同時request	1
平均Decode速度	65.07 tok/s
TTFT	2.38〜3.60秒
VRAM使用量	約29GB
FreeToken RAM使用量	約115GiB
PCIe H2D	28.9GB/s
GPU接続	PCIe 5.0 x8
CPU STREAM read	50.1GB/s

結論としては、

技術PoCとしては成功。

少なくとも今回の条件では、RTX 5090一枚でも125B級MoEを対話用途として十分使える速度で動かせた。

一方、128GB RAMはかなりぎりぎりで、長時間運用、長いcontext、複数requestについては別途検証が必要である。

そして今回は、PCIe帯域とRAM帯域の両方が、それぞれの物理上限のかなり近くまで使われていた。

この点が、今回いちばん面白かった。

Qwen3.8-Flash-Nextとは

Qwen3.8-Flash-Nextは、2026年8月に公開されたQwenシリーズのMoE（Mixture of Experts）モデルだ。

公式には、将来のQwen4を支えるアーキテクチャのexperimental previewという位置づけになっている。

公式のmodel cardでは、言語モデル部分について、

• main language model：125B parameters
• N-gram embeddings：51B parameters
• MTP（Multi-Token Prediction）：4B parameters
• 1 tokenあたりのactivated parameters：6B
• native context：262,144 tokens
• 最大1,000,000 tokensまで拡張可能

という構成になっている。

125Bのメインモデルに51BのN-gram Embedding、4BのMTPを加えるため、保存されている物理的なパラメータ量としては約180B規模になる。

また、モデル自体はVision Encoderを持つnativeなmultimodalモデルで、textだけでなくimageやvideoも扱える。

ただし、今回使用したFreeTokenではmultimodal checkpointも現時点ではtext-onlyでserveされる。そのため、今回の検証もテキスト生成に限定している。

ここで重要なのが、125Bすべてを毎token計算するわけではないという点だ。

MoEでは多数の「expert」を用意し、その中から入力に応じて一部だけを選んで計算する。

Qwen3.8-Flash-Nextでは各MoE layerに512のrouted expertsがあり、tokenごとに10個のrouted expertsと1個のshared expertが使われる。

つまり、

モデル全体は巨大だが、1 tokenを生成するときに実際に計算する部分は比較的小さい。

という性質を持っている。

Attentionも均一ではない

もう一つ、後の設定に関わる話をしておく。

このモデルの48層は、すべて同じ構造をしているわけではない。

12 × (
3 × (Gated DeltaNet → MoE)
\+ 1 × (Qwen Sparse Attention → MoE)
)

という3:1のhybrid attention構成になっている。

4層に1層だけQwen Sparse Attention（QSA）が入り、残りはlinear attention系のGated DeltaNetが担当する。

後で出てくるFreeTokenの設定にattention backend: qsa_sparseとあるのは、このQSAを処理するための設定である。

51BのN-gram Embeddingはoffloadしやすいように設計されている

そして今回の検証で特に重要なのが、51B parametersを占めるN-gram Embeddingだ。

これは通常のtoken embeddingとは別に用意された巨大なlookup tableで、2,000万のbigram／trigramエントリをlayer 2で参照する。

興味深いのは、Qwen自身がN-gram Embeddingについて、MoEによるparameter scalingより計算量が小さく、offloadにも適していると説明していることだ。

つまり、

このN-gram Embeddingは、memory-constrainedなacceleratorでもoffloadしやすいことを意識した設計になっている。

後で見るように、今回RAMを115GiBも消費した理由のかなりの部分を、この51BのN-gram Embeddingが占めている。

一方、使っていないMoE expertも消えるわけではない。

巨大なexpert群とembedding tableを「どこに置いておくか」という問題が生まれる。

なお、Qwen3.8-Flash-NextのライセンスはQwen Community License 1.0である。業務利用を考える場合には、ライセンス条件も確認しておいた方がよい。

RTX 5090は速い。でも32GBしかない

RTX 5090は非常に高速なGPUだが、VRAMは32GBだ。

一方、今回使用したQwen3.8-Flash-Next NVFP4 checkpointは約135GBだった。量子化前のsource checkpointは約360GBある。

135GB > 32GB

当然ながら、そのままVRAMへ載せることはできない。

そこで使ったのがFreeTokenだった。

FreeTokenは何をしているのか

FreeTokenは、VRAMに収まりきらない巨大MoEを、GPUだけでなくホストRAMも使って推論するruntimeだ。

FlashML-orgがApache 2.0で公開しているプロジェクトで、2026年8月にはFreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Executionという論文も公開されている。

設計思想は明快で、personal machineを「小さなGPUを搭載したPC」としてではなく、GPU・CPU・RAM・interconnectを組み合わせた一つの弾力的な推論platformとして扱う。

今回使用したoffload backendでは、expert weightsをホストRAM側へ置き、GPU側にはLRU方式のexpert cacheを持つ。

必要なexpertがGPU cacheに存在すれば、そのままGPUで計算する。

cache missしたexpertは、PCIe経由でホストRAMからGPUへ転送する。

配置場所	主なデータ
ホストRAM（CPU側の主記憶）	巨大なexpert群の重み、N-gram Embedding（n-gram table）
RTX 5090のVRAM（32GB）	expert cache、KV cache

つまりFreeTokenがやっていることは、

VRAMを増やすことではない。

GPU・PCIe・ホストRAMをまとめて、一つの推論システムとして使うことだ。

4種類の実行backend＋auto

FreeTokenは--moe-backendで、MoE expertをどう処理するかを切り替えられる。

backend	挙動
fused	expertをGPU上に常駐させる。大きなVRAMが必要
offload	expertはhost RAMに置き、GPUのLRU cache missをPCIeで転送する
cpu	missしたexpertをGPUへ転送せず、CPU側で計算する
hybrid	stepごとに、一部をPCIeで転送し、残りをCPUで計算してoverlapさせる
auto	MoEでは基本的にoffloadを使い、保存されたbandwidth profileがhybridを推奨する場合に切り替える

今回はoffloadで測定している。

後述するft bench bwでもoffloadが推奨されたためだ。

ただし、hybridは設定だけで比較できる。今回試していない以上、offloadの結果だけを見て「このPCの上限」と結論づけることはできない。

またFreeTokenの公式docsでは、Qwen3.8-Flash-Nextについて47.7GiBのPLE n-gram tableをホストRAMに保持すると説明されている。

Qwen公式ではN-gram Embedding、FreeToken側ではPLE n-gram tableという表現が使われているが、ここでは同じ巨大lookup tableを指している。

この時点で、推論性能を考える対象が「GPU一枚」から「PC全体」へ広がっている。

NVFP4で約135GBまで縮める

今回使用したcheckpointは、

RadixArk/Qwen3.8-Flash-Next-NVFP4

である。

checkpointのmodel cardによると、主としてMoEのrouted expert MLPをNVFP4 W4A4へ量子化する一方、attentionやshared expertsなどはBF16、PLE n-gram tableはFP8というmixed precision構成になっている。

• routed expert MLP：NVFP4
• attention：BF16
• shared experts：BF16
• routers：BF16
• LM head：BF16
• PLE n-gram table：FP8

つまり、モデル全体を一律に4bitへ落としているわけではない。

NVFP4自体も単純な4bit整数ではなく、E2M1形式とblock scalingを組み合わせた低精度形式である。

その結果、今回使用したcheckpointは約135GBまで圧縮されている。

135GBの内訳を概算してみる

この135GBという数字は、非常に粗い概算ではあるが、パラメータ構成からある程度説明できる。

routed experts
約120B × 0.5 byte (NVFP4)  ≒  60 GB

n-gram embedding
51B × 1 byte (FP8)      ≒  51 GB

attention / shared experts /
router / LM head / MTP など
残りを主にBF16で保持         ≒  数十GB

─────────
おおむね130GB台

もちろんNVFP4にはscaleなどのmetadataもあり、各componentの正確なparameter内訳もこの単純計算とは一致しない。

それでも、51BのN-gram EmbeddingをFP8、つまり1 parameterあたり1 byteで持つと、

51,000,000,000 byte
÷ 1024^3
≈ 47.5 GiB

となる。

FreeToken公式の47.7GiBという値と、ほぼ一致する。

ここが重要だ。

4bit化された巨大MoEを動かしているのに、51BのN-gram Embeddingだけで約48GiBのホストRAMが必要になる。

モデルを小さくしたからといって、すべてのmemory pressureが消えるわけではない。

検証環境

今回使用したワークステーションは以下。

Component	Specification
CPU	AMD Ryzen 9 9950X3D
GPU	ASUS ASTRAL RTX 5090 32GB
RAM	Crucial DDR5 128GB（32GB × 4）
Motherboard	ASUS ROG STRIX X870-F GAMING WIFI
System SSD	WD_BLACK SN8100 4TB
Data SSD	WD_BLACK SN7100 4TB
PSU	Corsair HX1500i
OS	Ubuntu 24.04 LTS

RAMはDDR5-5600製品だが、32GB × 4枚構成の現在の実動作速度は3600 MT/sだった。

Ryzen 9 9950X3Dの公式memory specificationでも、2 DIMM時はDDR5-5600、4 DIMM時はDDR5-3600となっている。

DDR5-3600のdual channelとして単純計算すると、理論帯域は、

3600 MT/s × 8 byte × 2 channel
≈ 57.6 GB/s

となる。

この数字も、後で効いてくる。

FreeTokenの設定

今回の主要設定は以下だった。

FreeToken:          0.1.2
Model:              Qwen3.8-Flash-Next-NVFP4
MoE backend:        offload
NVFP4 backend:      triton
Attention backend:  qsa_sparse
MoE CPU threads:    16
max_running_req:    1
max context:        32768

つまり今回測定しているのは、32K context・single requestでの性能である。

Qwen3.8-Flash-Next自体は262K native contextに対応しているが、今回はそこまで検証していない。

また、4B MTP moduleが今回のFreeToken構成で実際に推論高速化へ利用されていたかは確認できていない。

MTPがspeculative decoding等に利用されているかどうかでtok/sの解釈も変わり得るため、ここは次回、runtime側の挙動を切り分けたい。

実際、どれくらい速かったか

同じ短いプロンプトを3回生成した。

• reasoning_effort = low
• temperature = 0
• streaming
• prompt = 64 tokens

本記事ではDecode速度を簡易的に、

Decode速度
= completion tokens ÷ (Total − TTFT)

として計算している。

結果は以下。

Run	Completion	TTFT	Total	Decode
1	511 tokens	3.595 s	11.599 s	63.84 tok/s
2	511 tokens	2.380 s	10.401 s	63.71 tok/s
3	391 tokens	2.381 s	8.159 s	67.67 tok/s

3回の平均は、

65.07 tok/s

だった。

別のプロンプトでも68.20 tok/sを確認している。

ただし、この3回は完全な等条件ではない。

• run 1のTTFTだけ約1.2秒長く、warmup等の影響が残っている可能性がある
• run 3は出力が391 tokensと短い
• run 1・2の511 tokensは設定した出力上限付近まで生成している

3回の短文benchmarkだけで一般的な性能を断定することはできない。

それでも今回の条件、つまり短文・single request・warm状態では、60 tok/s台後半のDecode速度を再現できることは確認できた。

対話用途として実際に使ってみても、体感的には十分速い。

GPUより先に、RAMが限界へ近づいた

ここからがFreeTokenらしいところだ。

3回のbenchmark終了後、メモリ使用量はおおむね以下になった。

FreeToken RAM：約115 GiB
Host RAM used：約120 GiB
Available RAM：約3 GiB
Swap used：約2.1 GiB

VRAM：約29 GB

つまり、

RTX 5090のVRAMは運用できている一方で、128GBのホストRAMはほぼ使い切っている。

この115GiBという数字も、先ほどのcheckpoint内訳から大まかに理解できる。

PLE n-gram table (FP8)       ≒ 47.7 GiB
routed experts (NVFP4)       ≒ 数十GiB
その他weights / pinned buf /
runtime overhead             ＋ α
─────────
≒ 115 GiB

特に51B parametersのN-gram EmbeddingをFP8で保持すると約47.5GiBになるため、FreeTokenが示す47.7GiBという値とよく一致する。

つまりRAMを消費しているのはMoE expertだけではない。

4bit化されていない51BのN-gram Embeddingだけで、FreeTokenが使っているRAMの4割前後を占める。

「RTX 5090＋RAM 128GBで動いた」と聞くと、それなりに余裕がありそうに見える。

しかし実際にはそうではない。

Open WebUI程度なら同居させられたが、Difyや別の大きなサービスまで同一ホストで多数動かすなら、memory pressureをかなり意識する必要がある。

今回のモデルと構成に限って言えば、

128GBは「余裕のあるRAM」というより、実用上の下限に近い。

という印象だった。

「PCIe 5.0なのに28.9GB/sしか出ない？」

次に気になったのがPCIeだった。

FreeTokenには、ホストRAMとPCIeの帯域を測り、MoE backend選択に使うprofileを作るbenchmarkがある。

ft bench bw

今回の結果はこうだった。

CPU STREAM read    50.1 GB/s

PCIe H2D           28.9 GB/s
PCIe D2H           28.7 GB/s

NVFP4 CPU-MoE      45.5 GB/s
NVFP4 PCIe gather  26.7 GB/s

CPU/PCIe ratio      1.70x
recommended         offload

最初に思ったのは、

「PCIe 5.0なのに、28.9GB/sは少なくないか？」

ということだった。

PCIe 5.0 x16なら、理論上の片方向帯域は約63GB/sある。

そこでGPUのlink状態を確認した。

nvidia-smi `\`
--query-gpu=name,pci.bus_id,`\`
pcie.link.gen.current,pcie.link.gen.max,`\`
pcie.link.width.current,pcie.link.width.max `\`
--format=csv,noheader

確認すると、最大generationはGen5、最大widthはx16だが、現在のlink widthはx8だった。

なお、idle時にはcurrent generationがGen1まで下がることがある。これは省電力動作によるため、今回注目すべきなのはlink widthのx8の方だった。

原因はFreeTokenではなく、M.2スロットだった

PCIe topologyとマザーボードの仕様を追っていくと、理由が分かった。

使用しているROG STRIX X870-F GAMING WIFIでは、M.2_2とPCIEX16(G5)が帯域を共有する。

ASUSの公式仕様にも、M.2_2へSSDを搭載した場合、PCIEX16(G5)はx8で動作すると明記されている。

CPU側
├─ RTX 5090
├─ M.2_1 : WD_BLACK SN8100
└─ M.2_2 : WD_BLACK SN7100
↑
GPUと帯域を共有

つまり、FreeTokenがPCIeをうまく使えていなかったわけではない。

PCの物理構成そのものが、RTX 5090をPCIe 5.0 x8で動かす構成になっていた。

ソフトウェアのbenchmarkを追っていたはずが、最終的にはマザーボード上のM.2スロット配置まで戻ってきた。

ここが今回、一番面白かった。

むしろ28.9GB/sは、かなり出ていた

物理構成がx8だと分かると、28.9GB/sという数字の見え方が逆転する。

PCIe 5.0 x8の理論帯域を概算すると、

32 GT/s × 128/130 × 8 lane ÷ 8
≈ 31.5 GB/s

となる。

実測H2Dは28.9GB/sなので、

28.9 / 31.5
≈ 91.7%

である。

つまり、

FreeTokenが28.9GB/s「しか」出せていないのではなく、PCIe 5.0 x8の理論帯域の約92％に相当する転送速度が出ていた。

ことになる。

同じことがRAM側にも言える。

DDR5-3600・dual channelの単純な理論帯域57.6GB/sに対し、実測のCPU STREAM readは50.1GB/sだった。

50.1 / 57.6
≈ 87%

もちろんSTREAM readとDDRの理論帯域を完全に同一視することはできない。

それでも、少なくとも「RAMが全く性能を出せていない」状態ではない。

PCIeもRAMも、現在の物理構成で使える帯域をかなり使っている。

LLM推論もここまで来ると、純粋な「AI」の問題ではない。

メモリ階層とI/Oの問題になる。

CPU/PCIe ratio 1.70xは何を意味するのか

benchmark結果の中でもう一つ気になったのが、この部分だった。

NVFP4 CPU-MoE      45.5 GB/s
NVFP4 PCIe gather  26.7 GB/s

CPU/PCIe ratio      1.70x
recommended         offload

FreeTokenのft bench bwは、実際のCPU／offload MoE kernelを使ってCPU側とPCIe側の実効帯域を測り、その結果をbackend選択やhybrid executionの較正に使う。

今回の1.70xは、

benchmark上で測定されたNVFP4 CPU-MoEの実効帯域が、NVFP4 PCIe gatherの約1.7倍だった

という意味になる。

ただし、ここは注意が必要だ。

「CPUでexpertを計算すると、実際のLLM推論全体が1.7倍速くなる」という意味ではない。

実際のDecodeにはexpert cache hit率、routing、GPU演算、attention、memory access、転送と演算のoverlapなどが同時に影響する。

FreeTokenの既定のdecision thresholdは2.0で、CPU帯域がPCIeの2倍を超える場合にhybridを推奨する。

今回は1.70xだったため、benchmarkの推奨はoffloadになった。

したがってoffloadを選んだ判断は妥当だったと考えている。

一方で、hybridはハードウェアを変えず、設定だけで試せる。

benchmarkの推奨と実際のend-to-end Decode性能が必ず一致するとも限らないため、最終判断は実際に両方を動かして比較するべきだと思う。

次にやること――3つの独立した変更

ここまでで、性能を左右しそうな変更点が3つ見えてきた。

① M.2_2からM.2_4へ移して、GPUをPCIe 5.0 x16へ戻す

現在M.2_2に置いているWD_BLACK SN7100はPCIe 4.0 x4対応SSDである。

一方、M.2_2自体はCPU直結のPCIe 5.0 x4で、PCIEX16(G5)と帯域を共有している。

このマザーボードではM.2_4がX870 chipset側のPCIe 4.0 x4なので、SN7100の仕様とはちょうど合う。

そのため、

現在

SN7100
↓
M.2_2（PCIe 5.0 x4）
↓
PCIEX16(G5) と帯域共有
↓
RTX 5090 = PCIe 5.0 x8


変更後

SN7100
↓
M.2_4（X870 chipset / PCIe 4.0 x4）

RTX 5090
↓
PCIe 5.0 x16

という構成へ変更できる可能性が高い。

なおM.2_3もchipset側のPCIe 4.0 x4だが、こちらはPCIEX16(G4)と帯域を共有し、SSDを搭載するとPCIEX16(G4)が無効になる。

今回の用途ではM.2_4の方が素直な移設候補だと考えている。

chipset側へ移す以上、SSD I/Oはchipset uplinkや他デバイスとの競合の影響を受ける可能性がある。そのためmodel load時間やSSD帯域も合わせて測定したい。

② 32GB × 4から64GB × 2へ変更して、RAM帯域を上げる

実は、こちらもかなり重要かもしれない。

現在は32GB × 4枚構成のため、実動作は3600 MT/sになっている。

Ryzen 9 9950X3Dの公式memory specificationでは、4 DIMM時はDDR5-3600、2 DIMM時はDDR5-5600となっている。

同じ128GBを64GB × 2枚で構成すれば、DDR5-5600クラスを狙える可能性がある。

現在
32GB × 4 @ 3600 MT/s
理論帯域 57.6 GB/s
実測STREAM read 50.1 GB/s

候補
64GB × 2 @ 5600 MT/s
理論帯域 89.6 GB/s

もちろん、実際の安定動作速度はDIMMのrank、QVL、BIOS、memory controllerなどにも依存するため、5600 MT/sが必ず出るとは限らない。

それでもexpert群とN-gram EmbeddingがホストRAMに置かれる以上、RAM帯域はかなり重要な変数である。

③ MoE backendをhybridにして比較する

最後はソフトウェアだけで変更できる。

現在のoffloadとhybridを同じハードウェア、同じプロンプト、同じサンプリング条件で比較する。

ft bench bwはoffloadを推奨しているので、hybridが必ず速いと予想しているわけではない。

むしろ、帯域benchmarkによる推奨が実際のDecode性能とどこまで一致するのかを見る試験になる。

比較したい指標

Metric	現在 x8 / 3600 / offload	① x16	② 2 DIMM	③ hybrid
H2D	28.9 GB/s	?	?	?
CPU STREAM read	50.1 GB/s	?	?	?
PCIe gather	26.7 GB/s	?	?	?
Decode	65.07 tok/s	?	?	?
TTFT	2.4〜3.6 s	?	?	?
Model load	未計測	?	?	?

3つを同時に変えると、何が効いたのか分からなくなる。

次回は一つずつ変更して比較したい。

ただし、x16にしても2倍速くなるとは限らない

もちろん、PCIe laneが2倍になるからといって、

65 tok/s → 130 tok/s

になるとは考えていない。

今回測定したCPU STREAM readは50.1GB/sだった。

PCIe 5.0 x16の理論帯域約63GB/sより低い。

expert weightsをホストRAMから読み出してPCIeへ流す以上、RAM側の実効帯域が50GB/s程度なら、PCIeだけを広げてもその先は別の制約に当たる可能性が高い。

つまりx16化すると、

現在
PCIe bandwidthが強い制約
↓
x16化
↓
RAM bandwidthなど
別の場所が次の制約になる？

という「ボトルネックの移動」が起きる可能性がある。

さらに実際のDecode速度には、

• expert cache hit率
• expert routing
• CPU側のexpert処理
• Attention
• N-gram Embeddingのlookupとprefetch
• kernel実装
• PCIe転送とGPU演算のoverlap

なども影響する。

ボトルネックを一つ取り除けば、別の場所が次のボトルネックになる。

この挙動そのものが、巨大MoEをローカルで動かす面白さでもある。

もう一つ残る疑問――4bitにして「賢さ」は落ちないのか

性能を測っている途中で、もう一つ大きな疑問が出てきた。

NVFP4に量子化して、モデルの能力はどのくらい失われるのか。

今回のcheckpointは、source modelの約360GBから約135GBまで小さくなっている。

これだけmemory footprintが変わっている以上、tokens/sだけを見て、

「巨大モデルが高速に動いた」

と結論づけるのは不十分だ。

本当に知りたいのは、

量子化前の能力をどの程度維持しながら、この速度とmemory footprintを実現できたのか。

という点である。

特に、

• 数学・推論
• コーディング
• 日本語
• 長文処理
• JSONなどの構造化出力
• agentic task

では、量子化誤差の影響が同じとは限らない。

FreeTokenはOpenAI互換APIやAnthropic互換APIを提供しており、coding agentから利用することもできる。

そのため、一般的なbenchmarkだけでなく、実際のrepositoryを使ったcoding taskや構造化出力、tool useでも比較してみたい。

速度の次は、「賢さ」を測る必要がある。

これは次の検証テーマにしたい。

今回分かったこと――GPUではなく、PC全体でLLMを動かす

FreeTokenでQwen3.8-Flash-Nextを動かしてみて、個人的に最も興味深かったのは、

巨大LLMの推論性能が、GPUの演算性能だけでは決まらなくなっている

ことだった。

今回のシステムを単純化すると、モデルやexpertは次のようなメモリ階層の上を移動する。

SSD
↓
CPU RAM
↓
PCIe
↓
GPU VRAM
↓
Tensor Core

そして実際には、

• RAM容量
• RAM帯域
• DIMMの枚数
• PCIe generation
• PCIe lane width
• M.2スロットの配置
• expert cache
• CPUとGPUへの処理分配

までが推論性能に関係する。

これは、以前の「このモデルはGPU VRAMへ載るか」というローカルLLMの感覚とは少し違う。

そして重要なのは、これが単なるユーザー側の苦肉の策ではないことだ。

Qwenは51BのN-gram Embeddingを、MoEよりoffloadしやすいparameter scalingの方法として設計している。

FreeTokenは、personal machineを小さなGPUとしてではなく、GPU・CPU・RAM・interconnectをまとめた一つのelastic inference platformとして扱う。

モデル側とruntime側の両方が、同じ方向を向いている。

PC全体を一つのAIアクセラレータとして設計する。

という考え方が、少なくとも巨大MoEをローカルで動かす世界では重要になり始めているように思う。

AIはソフトウェアとして存在しているように見える。

しかし実際にローカルで動かしてみると、その知性はRAMを占有し、PCIeを流れ、CPUで計算され、GPUを発熱させる。

極めて物理的な存在でもある。

このブログではこれまでAIの知性や意識について考えることが多かったが、実装側から眺めると、AIの「身体」に相当する計算機そのものもまた、かなり面白い研究対象になってきた。

結論

今回、FreeTokenを使ってQwen3.8-Flash-Next NVFP4を、

Ryzen 9 9950X3D＋RTX 5090 32GB＋RAM 128GB

の単一ワークステーション上で動作させた。

短いプロンプト・single request・warm状態では、3回平均で、

65.07 tok/s

を確認した。

個人用の対話、コーディング、研究支援用途であれば、十分実用的に感じる速度だった。

一方で、今回の結果には、

• FreeTokenだけでRAMを約115GiB消費する
• そのうち約48GiBはFP8のN-gram Embedding tableである
• 128GBではmemory marginがかなり小さい
• 今回は32K contextまでしか検証していない
• concurrencyは1
• GPUはPCIe 5.0 x8で動作していた
• RAMは4 DIMM構成の3600 MT/sだった
• MoE backendはhybridを比較していない
• MTPが今回の推論でどう使われていたか確認できていない
• NVFP4による能力低下はまだ十分に評価していない

という制約もある。

したがって現時点での評価は、

RTX 5090一枚でも巨大MoEを実用速度で動かせる。ただし、その性能を決めるのはGPUだけではない。

である。

次は、

1. M.2_2のSN7100をM.2_4へ移し、RTX 5090をPCIe 5.0 x16へ戻す
2. 可能なら32GB × 4から64GB × 2へ変更し、RAM帯域を改善する
3. offloadとhybrid backendを同一条件で比較する

という3つを一つずつ試したい。

そして、その次に、

「NVFP4化で、モデルの賢さはどれくらい残っているのか」

を調べたい。

ローカルLLMは、モデルをダウンロードして動かすだけのものから、ハードウェアとソフトウェアを一緒に設計する対象になりつつある。

その過程自体が、かなり面白い。

---

参考

• FlashML-org, FreeToken
• Yang et al., FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution, arXiv:2608.16157, 2026
• Qwen, Qwen3.8-Flash-Next model card
• RadixArk, Qwen3.8-Flash-Next-NVFP4 model card
• ASUS, ROG STRIX X870-F GAMING WIFI specifications / manual
• AMD, Ryzen 9 9950X3D specifications

検証時点

2026年9月。FreeToken、Qwen3.8-Flash-Next、および今回使用したNVFP4 checkpointは公開直後で、開発が非常に速い段階にあります。runtime更新やcheckpoint更新によって、挙動、性能、必要メモリ、対応backendなどが変化する可能性があります。また、本記事の性能値は筆者の単一環境で得られた実測値であり、一般的な性能を保証するものではありません。checkpointサイズやRAM使用量の内訳には、公称パラメータ数からの概算を含みます。