FreeToken × RTX 5090——120B MoE が 127 tok/s、その請求書

FreeToken が売っているのは速度ではなく、32 GB の GPU で動かせるモデルサイズの上限です。 Zenn の holy_fox 氏が RTX 5090 32 GB + RAM 128 GB の PC で FreeToken 0.1.2 を実測した記事（2026-08-22）の数字を先に置きます。 VRAM に収まる 23.5 GB の Ornith 1.5（Qwen3.5-35B-A3B ベース）では llama.cpp と vLLM に負け、 収まらない 65.2 GB の gpt-oss-120b は単発 decode 127.1 tok/s、83.5 GB の Qwen3.5-122B-A10B は 32.0 tok/s で動きました。 原記事のタイトルどおり「35B では不要、120B 級 MoE では話が変わる」です。

FreeToken は FlashML-org が Apache-2.0 で公開しているローカル推論サーバで、llama.cpp や vLLM と同じ層に立ちます。 MoE（層ごとに多数の expert＝小さな FFN を持ち、1 トークンにつきその一部しか使わないモデル）の expert をホスト RAM に置き、 使う分だけ GPU に運ぶのが設計の中心です（expert を持たない dense モデルには無関係）。0.1.2 は 2026-08-19 に PyPI に出た版で、原記事の三日前です。 数字は holy_fox 氏の実測か、それを基にした筆者の計算です。同じカードは手元になく、再現はしていません。

三本の実測が引いた境界線

環境は一つです：RTX 5090（32 GB）、ホスト RAM 128 GB、FreeToken 0.1.2、コンテキスト長 8192。以下はすべてこの環境での著者実測です。 A3B などの A はアクティブパラメータ（1 トークンの計算に実際に使う分）です。

倍率は筆者の計算、他は原記事の値です。expert の総数は層数 × 層あたりの expert 数で、gpt-oss-120b なら 36 × 128 = 4608。 NVFP4 と MXFP4 はどちらも 4 bit 量子化（前者は NVIDIA Blackwell 世代、後者は gpt-oss の公式配布形式）で、llama.cpp だけは GGUF の Q4_K_M。同一量子化の比較ではないと原記事も明記しています。収まるこのモデルで FreeToken を選ぶ理由は、著者の言葉で「ほぼありませんでした」。

理由も著者が書いています。FreeToken 0.1.2 はこの NVFP4 チェックポイントの expert を GPU 常駐の fused backend （expert を VRAM に置いたまま一体で実行する経路）に載せられず、offload を使わざるを得ませんでした。 収まるのに一度ホスト RAM に置いて PCIe で運ぶので、転送コストだけが残ります。 測れたのは「収まるモデルに offload を使うと利点がない」までで、fused は未実測。「収まる MoE 全般に不要」とは、この一組では言えません。

32 GB に 65 GB が載る仕組み——expert は RAM、運ぶのは PCIe

FreeToken の models.md は offload backend をこう定義しています。 「experts live in host RAM, an LRU cache of expert slots on GPU; misses stream over PCIe」。1 トークンで使う expert は一部 （gpt-oss-120b なら 1 層 4 個）なので、expert 本体は pinned なホスト RAM（GPU が DMA で直接読める固定ページ）に置き、 最近使われた分だけ GPU 側の LRU キャッシュに残す。ミスした expert は PCIe で運びます。原記事の起動コマンドはこれだけです。

ft serve \
  --model /path/to/gpt-oss-120b \
  --host 127.0.0.1 \
  --port 8000 \
  --moe-backend offload \
  --moe-cache-auto \
  --max-running-requests 16 \
  --max-seq-len-override 8192

--moe-cache-auto は KV と expert のキャッシュへの VRAM 配分を空き容量から決めます（cli.md）。 実行時の VRAM は約 29 GB、ホスト RAM は約 66 GB。expert の 40.4% が GPU 側に常駐し、残りは必要になったときだけ運ばれます。 載っているのではなく、載せ替え続けている。

論文（arXiv 2608.16157）が説明する機構は二つです。第一に、キャッシュは router （各トークンにどの expert を使うかを選ぶゲート。LLM ルーティングの router とは別物）に追随します。同じ層が続けて似た expert を選ぶので、LRU で追える（§3.2）。 第二に、残るミスを PCIe で運ぶ分と CPU で直接計算する分に割り、その割合は PCIe 帯域と CPU 側帯域のその機械での実測比で決めます。CLI の ft bench bw がその計測です。

帯域を並べます。論文 §2.2 によれば GPU の VRAM は 1〜1.8 TB/s、二チャネル DDR5 は 80〜90 GB/s。論文 Table 1 の RTX 5090 デスクトップ機（Ryzen 9 9950X3D、DDR5 192 GiB、PCIe 5.0 ×16）で実測した expert 転送帯域は 49.0 GB/s。 VRAM の中と外で 20 倍以上違い、キャッシュミスは全部この管を通ります。 ただし 49.0 GB/s は論文著者の機体の値で、holy_fox 氏の機体の PCIe 帯域は原記事にありません。板が PCIe 4.0 だったり、M.2 と帯域を分け合って ×8 だったりすれば管は半分以下です （Table 1 の 4090 行 4.0 ×16 は 25.1 GB/s）。以下の 49.0 は「別の機体の値を借りた上限」です。

同じ 120B 級で 127 と 32——差は総パラメータではなく expert の通り道

両者は総パラメータがほぼ同じで、単発 decode は 4 倍違いました。原記事の対比表です。

Qwen3.5 側は 1 トークンで参照する expert が約 2.7 倍あり、GPU に残せる割合は三分の一です。 Qwen3.5 のハイブリッド線形アテンション（GDN）の状態キャッシュが約 7 GB を取り、expert キャッシュに回せる VRAM が減っています。 VRAM を食う機構が一つ増えると、offload 用のキャッシュが減って二重に不利になる。著者はこれを「GDN を使う MoE 全般の評価」ではなく「機構として確認できた」段階と慎重に書いており、筆者もそこまでです。 もう一つ、gpt-oss 側には専用実装と MXFP4 カーネルがあり、Qwen3.5 側はパッチ込みです。4 倍のうち機構の差と実装の熟度の内訳は、この一組では切り分けられません。

筆者の計算を一つ足します。PCIe が 49.0 GB/s なら、1 トークンあたり運べる expert 重みは 32.0 tok/s のとき最大でも 49.0 ÷ 32.0 ≈ 1.53 GB、 127.1 tok/s なら ≈ 0.39 GB（PCIe 4.0 ×16 の板ならそれぞれ半分）。実測ではなく上限ですが、ミスが増えるほど毎トークンこの枠を使い切る状態に近づく——「常駐率が急所」の意味はこれです。 並列を上げると異なる expert に同時アクセスしてヒット率が落ち、gpt-oss-120b でも 1 リクエストあたりの速度は 121.3 → 48.5 → 15.8 tok/s と落ちました。 著者の結論は「多数同時アクセスより単発から少数並列のローカル利用に向いています」。

請求書——一台が一日に出せるトークンと、それを API で買う値段

この連載の本題です。127 tok/s は、それで何が買えるかに直さないと評価できません。

先に口径を揃えます。127.1 tok/s は decode のみの速度で、prompt を読む prefill（TTFT、最初のトークンまでの時間）を含みません。 原記事は同じ表に 1 並列の合計生成速度 75.0 tok/s も載せていて、こちらが TTFT 込みの端到端の値です （max_tokens 256 と TTFT から逆算しても 71〜77 tok/s で一致。筆者の検算）。一日の産出は端到端で数え、以下は 75.0 を使います。 24 時間、稼働率 100% の仮定です（上限の話です）。

同じトークンを API で買うといくらか。gpt-oss-120b の serverless 出力単価は採集日（2026-08-25）で Together AI が $0.60 / 1M（入力 $0.15）、DeepInfra が $0.17 / 1M（入力 $0.037）と、3.5 倍の幅があります。 本稿は高い方の Together を採ります——ローカルの回収が早く見える、ローカルに有利な仮定です。 一日 648 万トークンを全部出力として買うと $3.89、16 並列の 1,950 万なら $11.70（decode のみの 1,098 万で数えれば $6.59 ですが、prefill ゼロの数字です）。

次にハードウェア側です。RTX 5090 の米国 MSRP は $1,999（NVIDIA、2025-01-06 発表）で、日本の実売価格ではありません。 GPU 一枚だけを $3.89 / 日で割ると 約 514 日。16 並列の $11.70 なら約 171 日ですが、1 リクエスト 15.8 tok/s の状態の数字です。 ここに 128 GB の RAM（原記事の実測は 66〜70 GB）、CPU、電源、筐体が足されます。出所のない値段は式だけ置きます。通貨は揃えてください。

回収日数 = (GPU + RAM + CPU + 電源 + 筐体 + 保守工数) / (一日の API 等価額 − 一日の電気代)
一日の電気代 = システム消費電力 [W] × 24 / 1000 × 電力単価 [円/kWh]

電気代の代入例を一つ。単価は家電公取協の電力料金目安単価 31 円/kWh（税込、2022-07-22 改定、2026-08-25 確認）、 消費電力は RTX 5090 の Total Graphics Power 575 W（NVIDIA 仕様）を天井として使います。 575 W × 24 h = 13.8 kWh、× 31 円 = 約 428 円/日。1 ドル 150 円と仮定すると $2.85 で、$3.89 の 7 割が消えます。 GPU 一枚の回収は 1,999 ÷ (3.89 − 2.85) ≈ 約 1,900 日。DeepInfra の $0.17 なら API 等価額は $1.10 / 日で電気代の天井を下回り、100% 稼働でも回収に届きません。 実測消費は原記事になく、PCIe 待ちの decode が 575 W を使い続けるとも考えにくい。書けるのは「電気代ゼロなら 514 日、天井なら約 1,900 日」の間、までです。

請求書の結論は一行です。問いは「ローカルは安いか」ではなく「何日で回収するか、その稼働率を本当に出せるか」。 514 日は電気代抜き・100% 稼働の数字で、稼働率が 20% なら電気代抜きでも 7 年を超えます。そのときには次のカードが出ています。

運用コストの行——/v1/models、互換性パッチ、未比較の対照

金額に出ない行も並べます。原記事と FreeToken のドキュメントの範囲です。

筆者の経験では、この種の「黙ってフォールバック」は速度差より先に請求書に出ます。

判定表——VRAM に収まるか、収まらないならどの型か

VRAM の倍率で三段に切りたくなりますが、データがそれを支持しません。2.04 倍で 127 tok/s、2.61 倍で 32 tok/s——差を作ったのは、倍率よりアクティブパラメータと常駐率です。 行は著者が挙げた判断基準で切り、三つの「型」に起こしたのは筆者です。

倍率の列は対位のための実例で、判定基準ではありません。expert 参照 144 と 384 の間にデータ点はありません。 判定に使う数字は四つ——チェックポイントの GB、アクティブパラメータ、expert 参照数（config.json の num_experts_per_tok × num_hidden_layers）、起動後に分かる GPU 常駐率。買う前に分かるのは前の三つです。

手元でやることは四つ。目標モデルの三つの数字を上の表に当てる。 同時に何人が叩くかを決める——16 並列で一人あたり 15.8 tok/s は、共有サーバの数字ではありません。 FreeToken を入れたら ft bench bw を一度回して、自分の PCIe と RAM の帯域比を見る。RTX 4090（24 GB、PCIe 4.0）は未測定で、不利な方向だけは確かですが数字は外挿しません。 それから請求書の式に自分の単価と、正直な稼働率を入れる。 32 GB の GPU で 65 GB のモデルが 127 tok/s で動くのは事実で、面白い。ただし面白さは請求書に載りません。