Muse Glimmer 30BをVRAM 16GBで動かす｜全52層が載る条件とDFlashの効き方をRTX 5080・5060 Tiで実測

先に結論: 構成別に動くか

測ったのは Meta 公式配布の GGUF (kquant-17gb) を llama.cpp b10356 で動かした場合。読者の環境は三つに分かれる。以下はいずれもテキスト入力のみ、知覚エンコーダを読み込ませない状態での観測になる。

表示にも使っている16GBが1枚 (RTX 5080)

どちらの時点でも起動している。ただし速度と、指定した層数の通り方は、同居していた使用量が違う2つの時点で入れ替わった。デスクトップ描画などで約2.5〜2.8 GiB が同居していた時点に測ったのは46層と48層で、それぞれ毎秒15.58トークンと毎秒7.57トークン。起動前の使用量が925 MiB の時点では52層と99の指定で起動し、99の指定で毎秒42.36トークンだった。表示負荷・クロック・温度・電力制限を固定した対照ではないため、言えるのは同居分が違う2時点で結果が入れ替わったという対応関係までになる。

表示に使っていない16GBが1枚 (RTX 5060 Ti)

層数の指定を99にした状態で起動し、llama-bench の生成 (tg128) が毎秒24.61トークン、プロンプト処理 (pp512) が毎秒1090.5トークン。起動の前後で見た GPU 全体の使用量の増分は 15,742 MiB (総コンテキスト指定4,096・テキスト入力のみ・ドラフタなし)。空きメモリ・ドライバの予約・接続方法・ビルドで変わるため、「表示に使わない16GBなら入る」とは一般化できず、本記事の2枚のカードで観測された範囲にとどまる。

16GBが2枚

生成はテンソル並列が毎秒39.50トークン、レイヤー分割が毎秒31.14トークン。プロンプト処理は向きが逆で、レイヤー分割が毎秒1491.2トークン、テンソル並列が毎秒1123.9トークンだった。2枚目は外部接続で増設したカードになる。

公式モデルカードが想定として示すのは24GBで、16GBはその外側にある。以下の実測は、外側で何が起きたかの記録になる。DFlashを扱う節を除き、ドラフタは読み込ませていない。

Muse Glimmerとは何か

Muse Glimmer は Meta が公開した30Bクラスのオープンウェイトモデルで、Apache 2.0 ライセンスで配布されている (公式発表時点の情報)。30B という表記は知覚エンコーダを含めた数字で、公式モデルカードは総パラメータを約29.6B、うち知覚エンコーダを約1.8B としている。配布 GGUF のヘッダにある general.size_label の値は 28B で、公式モデルカードにこの表記は無い。画像入力に使うエンコーダは別ファイルとして配布されている。

配布 GGUF のヘッダから読み取れるのは、アーキテクチャ名 muse-glimmer、層数は52、宣言されている文脈長は131072、注意機構はクエリ32ヘッドに対し KV 2ヘッドのグループ化クエリ注意、スライディングウィンドウは2048。context_length は宣言値であって学習系列長の証明ではない。公式モデルカードの表記は131,072+ になる。

量子化ビルドは2種類が配布されている。小さい方 (kquant-17gb) は24GBのVRAMに収まる想定、大きい方は32GB向けの高品質版と位置づけられている。小さい方のファイルサイズは 16,756,681,056 bytes で、GiB換算すると約15.61 GiB、公式ページの10進表記は 16.8 GB。llama-bench が起動時に表示するサイズはテンソル部分のみを指すためこれより小さく、ファイルサイズとは別物になる。ファイルサイズがそのまま必要な VRAM 量になるわけでもない。

実行側は、llama.cpp が公開当日に対応している (対応を加えた変更は2026年8月10日に取り込まれた)。本記事の実測はすべて llama.cpp で行っている。実行環境の選択肢そのものはローカルLLM推論エンジン比較で扱っている。

公式が示すVRAM要件の読み方

公式モデルカードのVRAM目安は、小さい方のビルドでテキストのみ約17GB、画像入力を足して約19GB、さらにドラフタ (本体とは別に用意される小さな補助モデルで、次に続くトークンをまとめて提案する) を足して約20GBとされている。

この数字は、重みと作業用の文脈を合わせたおおよその合計として示されており、どの文脈長を前提にした値かは示されていない。24GBという想定値の内訳も公式は示していないため、ここでは分解しない。

画像入力を使う場合は知覚エンコーダのファイルを別に読み込ませる必要があり、公式の目安ではテキストのみの約17GBが約19GBへ上がる。本記事は画像入力を使わない構成しか測っていない。

測定の前提と、測っていない軸

測定条件は次のとおり。指定していない引数は llama.cpp の既定値のままで、b10356 では空きメモリに合わせて未指定の引数を調整する仕組みが既定で有効になっている。ただし層数を明示した測定では、その調整は行われずに指定がそのまま使われた。

項目	値
CPU / システムRAM	Intel Core i7-14700F / 96 GB
OS	Windows 11 Home build 26200
GPUドライバ	610.47（測定時点）
GPU 1枚目	RTX 5080（PCIe Gen5 x16 接続・画面表示に使用）
GPU 2枚目	RTX 5060 Ti（OCuLink 外部接続・PCIe 4.0 x4。nvidia-smi のリンク幅も x4 と読めた）
推論エンジン	llama.cpp b10356（CUDA 13.3ビルド）
モデル	muse-glimmer-30B-kquant-17gb.gguf（16,756,681,056 bytes）
モデルの SHA-256	7e9b74b7c8875e9e265695df9613bf6290f2392e479ce740495a129019c488d8
ドラフタの SHA-256	27d9a805fa29b943cfb6ad4843367cd4eaaaf06bd452d8cc3e00a2cd18a677bc
配布元のリビジョン	a0532f7263ee67f1e0a5f5c5fdcd50dd62fc9aa4（2026年8月11日時点）
バッチサイズ	既定のまま（論理2048 / 物理512）
Flash Attention	既定のまま（auto）
KVキャッシュの型	指定なし（既定）
同時実行スロット	既定（自動で4・KVは共有）
思考量の指定	指定なし（既定のまま。全条件で変更していない）
生成時の温度	0（貪欲デコード）
llama-bench の集計	各条件3回の平均値（ツールが出す avg）
llama-server の集計	総コンテキスト指定の測定は4回・DFlash の測定は6回。いずれも先頭2回を暖機として除いた中央値

2枚目のリンクは OCuLink 経由の PCIe 4.0 x4 で、1枚目の Gen5 x16 とは帯域が大きく違う。カード側の対応上限は x8 だが、実際に読めたリンク幅は x4 だった。分割方式の比較はこの接続条件での結果になる。DFlash の採択率は暖機を含む全 run の合算で、速度の中央値とは集計範囲が違う。llama.cpp は b10356、GPUドライバは610.47。どちらも計測した時点のもので、その後さらに新しいビルドが出ている。

条件を切り替える測定はそのつどサーバを終了して起動し直し、起動前の GPU 使用量が元の水準に戻ったことを確認してから次に移っている。総コンテキスト指定を変えた測定で投げたプロンプトは、投機的デコードやグループ化クエリ注意などの技術的な説明を求める短い英文8種を順に使い回したもので、全条件で同じものを同じ順で使っている。呼び出し先は /v1/chat/completions、温度0。キャッシュを無効化する指定はしていない。

サーバ経由の数値が何を指しているかも、先に確認しておく必要がある。実測と同じ呼び方で1回投げ、返ってきた内容の種別を確認した。

項目	値
使ったエンドポイント	/v1/chat/completions
返ってきた内容	思考部分のみ (最終回答は空)
そのときの生成速度	毎秒24.53トークン (120トークン生成)

このモデルのチャットテンプレートは思考を伴う応答を返す。実測で使ったトークン数の範囲では、返ってきたのは思考部分だけで最終回答には到達していない。したがってサーバ経由の数値は「1秒あたり何トークン生成できたか」であって、「何秒で答えが返るか」ではない。llama-bench の測定はチャットテンプレートを通さないため、両者の値は直接比べない。

測っていないのは、出力品質・回答の正しさ・エージェントとしての実用性・体感差。画像入力を使った構成も測っていない (実測はテキスト入力のみで、知覚エンコーダは読み込ませていない)。DFlash ありの出力がドラフタなしと一致するかも検証していない。大きい方のビルドは2枚構成でしか測っておらず、16GB 1枚での起動可否は確かめていない。値は単一機・単一素材の測定で、プロンプト内容や並列数を変えると動く。

実測1: 16GB 1枚でどこまで載るか

表が多いため、先に順路を示す。表示にも使うカード1枚で動かすなら本節の同居分が違う二つの表、表示に使っていない1枚なら本節の層数指定の表と起動ログの内訳、2枚なら実測3、DFlashを試すなら実測4を見ると早い。

層数の指定は53で頭打ちになる

llama.cpp の ngl は GPU に載せる層数の指定で、本記事では層数の指定と呼ぶ。52を超える値を指定したときに何が起きるかを先に確認した。

層数の指定	生成 (tg128)	プロンプト処理 (pp512)
52	毎秒21.82トークン	毎秒991.2トークン
53	毎秒24.60トークン	毎秒1089.8トークン
60	毎秒24.60トークン	毎秒1089.6トークン

RTX 5060 Ti 単体で、層数の指定だけを52・53・60と変えた測定 (llama-bench で pp512・tg128 を各3回)。53以上は値が変わらず、53指定の生成 毎秒24.60トークンは、別途99を指定して測った毎秒24.61トークンと一致した。したがって層数の指定は53で頭打ちになり、GGUFヘッダのブロック数52の外に、GPUへ載せられる要素がもう1つあることまでは言える。それが何なのかは本記事では確認していないため、正体は断定しない。起動ログには繰り返し層と出力層を分けた表示が出るが、足し算が53にならないため、ログの表示をそのまま構造の説明には使わない。以降の表では、各行がどの指定での測定かを併記する。

同じ層数指定でも、同居していた使用量で結果が変わった

構成	生成 (tg128)	プロンプト処理 (pp512)
RTX 5080 単体・46層をGPUへ	毎秒15.58トークン	毎秒301.8トークン
RTX 5080 単体・48層をGPUへ	毎秒7.57トークン	毎秒51.6トークン
RTX 5060 Ti 単体・46層をGPUへ	毎秒13.35トークン	毎秒626.4トークン
RTX 5060 Ti 単体・50層をGPUへ	毎秒18.13トークン	毎秒832.4トークン
RTX 5060 Ti 単体・全52層をGPUへ	毎秒24.61トークン	毎秒1090.5トークン
2枚・レイヤー分割	毎秒31.14トークン	毎秒1491.2トークン
2枚・テンソル並列	毎秒39.50トークン	毎秒1123.9トークン

llama-bench で pp512・tg128 を各3回。各行の層数は指定の値そのもので、「全52層をGPUへ」の行と2枚の行は99を指定した測定になる。この時点の RTX 5080 は、デスクトップ描画などで約2.5〜2.8 GiB が同居していた状態、RTX 5060 Ti は使用量0 MiB の状態だった。生成 (tg) とプロンプト処理 (pp) の測定で、出力品質は測っていない。カード間のプロンプト処理を比べる場合は層数の指定を揃える必要があり、この表の中でも向きが変わる。

この表の RTX 5080 の行から「表示に使うカードは遅い」とは言えない。同じ層数指定を、同居分が少ない状態で測り直したのが次の表になる。

層数の指定	起動前の使用量	生成 (tg128)	プロンプト処理 (pp512)
46層	810 MiB	毎秒17.44トークン	毎秒1227.4トークン
48層	856 MiB	毎秒21.02トークン	毎秒1400.3トークン
50層	891 MiB	毎秒23.47トークン	毎秒280.2トークン

違いは層数指定ではなく、測定時に他へ使われていた VRAM の量になる。どちらが正しいという関係ではなく、同じ指定でも同居する使用量で結果が変わることを示す対照として並べている。もう一点、層数を増やしていくとプロンプト処理側が先に落ちる形が出ている (50層で毎秒280.2トークン)。生成の速度だけを見ていると、プロンプト処理がすでに大きく落ちていても気づけない。

同じ RTX 5080 で、層数の指定を52と99まで上げた場合も測っている (起動前の使用量は 925 MiB)。

層数の指定	生成 (tg128)	プロンプト処理 (pp512)
52層	毎秒35.44トークン	毎秒278.1トークン
99（全層を載せる指定）	毎秒42.36トークン	毎秒294.9トークン

同居していたのが約2.5〜2.8 GiB の時点と約925 MiB の時点で、同じカードの結果が入れ替わっている。ただし表示負荷・クロック・温度・電力制限を統制した対照ではないため、同居分を速度差の唯一の原因とは書けない。言えるのは、同居分が違う2時点で結果が入れ替わったという対応関係までになる。なおこの構成でもプロンプト処理側は低い水準にとどまっており、生成だけが速い。プロンプト処理と生成は別の指標として扱う。

起動でどれだけ増えるか

同じ層数指定で llama-server を起動し、起動の前後で nvidia-smi の memory.used を読んで差分を取った値。総コンテキスト指定は4,096。速度の測定とは別のタイミングで取っているため、起動前の使用量は測定ごとに異なる。「全52層をGPUへ」と2枚構成の行は99を指定した測定になる。

構成	測定時の起動前使用量	起動前からの増分	増分の合計
RTX 5080 単体・46層をGPUへ	RTX 5080: 835 MiB / RTX 5060 Ti: 0 MiB	RTX 5080: 13,870 MiB	13,870 MiB
RTX 5080 単体・48層をGPUへ	RTX 5080: 976 MiB / RTX 5060 Ti: 0 MiB	RTX 5080: 14,284 MiB	14,284 MiB
RTX 5060 Ti 単体・46層をGPUへ	RTX 5080: 889 MiB / RTX 5060 Ti: 0 MiB	RTX 5060 Ti: 13,738 MiB	13,738 MiB
RTX 5060 Ti 単体・50層をGPUへ	RTX 5080: 851 MiB / RTX 5060 Ti: 0 MiB	RTX 5060 Ti: 14,892 MiB	14,892 MiB
RTX 5060 Ti 単体・全52層をGPUへ	RTX 5080: 840 MiB / RTX 5060 Ti: 0 MiB	RTX 5060 Ti: 15,742 MiB	15,742 MiB
2枚・レイヤー分割	RTX 5080: 826 MiB / RTX 5060 Ti: 0 MiB	RTX 5080: 8,047 MiB / RTX 5060 Ti: 8,264 MiB	16,311 MiB
2枚・テンソル並列	RTX 5080: 838 MiB / RTX 5060 Ti: 0 MiB	RTX 5080: 8,151 MiB / RTX 5060 Ti: 8,056 MiB	16,207 MiB
2枚・レイヤー分割 (大きい方のビルド)	RTX 5080: 823 MiB / RTX 5060 Ti: 0 MiB	RTX 5080: 9,327 MiB / RTX 5060 Ti: 9,746 MiB	19,073 MiB

「起動前からの増分」は GPU 全体の使用量の差分で、「測定時の起動前使用量」はその時点で他に使われていた分。「増分の合計」は各カードの増分を足した値であって、nvidia-smi が示すロード後の総使用量ではない。nvidia-smi で容量として読めた値は、RTX 5080 が 16,303 MiB、RTX 5060 Ti が 16,311 MiB だった。製品の公称容量そのものではなく、その環境で見えた総容量になる。起動前にまず見るのはこの二つ (今使われている分と、これから増える分) になるが、合計が容量に収まる計算かどうかだけで結果が決まるわけではない。増分は総コンテキスト指定4,096で起動した状態の値で、どのテンソルがGPU側に置かれたかを個別に確認したものではないため、確保量を根拠に配置を断定はしない。

起動ログが示す内訳

RTX 5060 Ti 単体・99指定・総コンテキスト指定4,096で起動し、ログに出る配置とバッファの内訳をそのまま読んだ値。

項目	値
GPUへ配置された層	53/53（ログの表示。GGUFヘッダのブロック数52とは数え方が違う）
CPU側に残った分 (CPU_Mapped)	721.42 MiB
GPU側のモデル本体 (CUDA0)	15,246.49 MiB
KVキャッシュ (CUDA0)	52.00 MiB と 156.00 MiB
計算バッファ (CUDA0 / CPU側)	151.02 MiB / 34.02 MiB
llama.cpp 自身の安全マージン警告	必要 15,605 MiB・空き 15,172 MiB で、目標の空き 1,024 MiB を確保できないと報告

99を指定しても 721.42 MiB は CPU 側に置かれており、すべてが GPU に載るわけではない。また nvidia-smi で見える GPU 全体の増分 15,742 MiB は、この内訳の合計 15,605.51 MiB に CUDA コンテキストなどの実行用領域が加わった値になる。nvidia-smi の増分を「モデルが確保した分」とは呼べない。最下行の警告は、この起動が成功した測定でも出ている。空きを1,024 MiB残すという目標を満たせないという内容であって、載らないという予測ではない。

実測2: llama-server の総コンテキスト指定を上げるとどうなるか

ここで測ったのは、llama-server の総コンテキスト指定 (-c) を変えて起動した場合の生成速度になる。その長さの入力を実際に与えた測定ではない。

文脈長の指定 (-c)	生成速度	GPU全体の使用量
4,096	毎秒24.53トークン	15,742 MiB
16,384	毎秒23.87トークン	16,026 MiB
32,768	毎秒13.12トークン	16,002 MiB
65,536	毎秒8.41トークン	15,994 MiB
131,072	毎秒7.99トークン	15,994 MiB

RTX 5060 Ti 単体・99指定で、1リクエスト128トークン生成を4回、暖機2回を除いた中央値。GPU全体の使用量にはベースラインが含まれるが、このカードは表示に使っておらず起動前は0〜60 MiB のため、差し引けばそのまま増分の目安になる。使用量は16,002 MiB でカードの容量 16,311 MiB に収まる計算のまま、速度だけが落ちている点は押さえておく必要がある。

測定点の間も刻んでいる。

文脈長の指定 (-c)	生成速度	GPU全体の使用量
20,480	毎秒19.30トークン	15,998 MiB
24,576	毎秒19.08トークン	16,006 MiB
28,672	毎秒15.66トークン	15,994 MiB

16,384 から 32,768 にかけて、測った範囲では段差になる点は見られなかった。測定点は離散的で未測定の区間が残るため、これ以上の一般化はしない。

この低下は全構成に共通する性質でもない。表示に使っている RTX 5080 で層数の指定を46にした構成では、同じ範囲で下がっていない。

文脈長の指定 (-c)	生成速度	GPU全体の使用量
4,096	毎秒17.30トークン	14,713 MiB
16,384	毎秒17.61トークン	15,124 MiB
32,768	毎秒18.28トークン	15,237 MiB

全52層を載せられない構成での曲線であり、全層を GPU へ寄せた1枚構成とは前提が違う。両者は直接比較しない。

総コンテキスト指定がスロットへどう配られるかも確認している。

総コンテキスト指定 (-c)	起動ログの n_ctx	1スロットの上限 (n_ctx_slot)	KVキャッシュの確保
4,096	4,096	4,096	52.00 MiB と 156.00 MiB
32,768	32,768	32,768	416.00 MiB
131,072	131,072	131,072	1,664.00 MiB

公式モデルカードには、-c が並列スロット間で分割され、1リクエストの上限は -c をスロット数で割った値になるという説明がある。よく引用される記述だが、本記事が使ったビルドの既定設定ではそのとおりにならなかった。既定ではスロットがKVキャッシュを共有する設定 (kv_unified) が有効で、起動ログは n_slots = 4 でありながら、n_ctx_slot も各スロットの n_ctx も指定値そのままを示している。スロット設定を明示的に変えた場合や、共有を無効にした場合の挙動は確かめていない。KVキャッシュについて公式は、グループ化クエリ注意とスライディングウィンドウにより小さく済むと説明しているが、実際のKVキャッシュ量を本記事で個別に測ったわけではなく、表の値は起動ログの表示になる。

落ち込みが空き容量によるものかを確かめるため、総コンテキスト指定を32,768で固定し、層数の指定だけを変えた対照も取った。

層数の指定	生成速度
全52層	毎秒13.13トークン
46層	毎秒13.94トークン
40層	毎秒10.65トークン

「全52層」の行は99を指定した測定で、他の行は表記どおりの指定になる。結果は仮説を支持しなかった。空きが少ない状態が原因なら層を減らせば速度が戻るはずだが、46層でもほとんど戻らず、40層まで減らすとかえって遅くなっている。ただし層を減らすとCPU側の計算と転送が増えるため、この対照だけでは容量の影響を切り分けられない。落ち込みの原因は本記事の測定では特定できていない。「層を減らして余裕を残す方が長い総コンテキスト指定では速い」とも言えない。

総コンテキスト指定とVRAMの関係そのものはVRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるかで扱っている。

実測3: 2枚に分けたときのVRAMの使われ方と分割方式

ここから先は2枚積める環境の話になる。本記事の2枚目は OCuLink で外部接続して増設したもので、リンクは PCIe 4.0 x4。1枚目の Gen5 x16 とは帯域が大きく違う。以下の値はこの狭い経路を挟んだ状態での結果になる。

16GBに収まりきらないモデルを2枚目で受け止めた例としては、16GB VRAMで38%あふれる qwen3.5:35b-a3b、2枚目でオフロード解消し約1.9倍にでも別のモデルを扱っている。

2枚のGPUは1つの大きなVRAMとして統合されるわけではなく、llama.cpp が層や重みをGPU間に分けて配置する。各カードの容量の制約は残り、分割方式の指定 (-sm) によって分け方が変わる。テンソル並列は公式の説明では実験的な位置づけとされているため、安定した推奨設定としては扱わない。以下の結果も特定の2枚構成での実測で、2枚構成一般の推奨にはならない。

速度は実測1の表のとおりで、生成はテンソル並列が毎秒39.50トークンで上、プロンプト処理はレイヤー分割が毎秒1491.2トークンで上だった。起動時の増分はレイヤー分割が 8,047 MiB と 8,264 MiB、テンソル並列が 8,151 MiB と 8,056 MiB。これは2枚に分けた場合の各カードの増分であり、1枚に載せる場合の必要量として読み替えることはできない。

大きい方のビルド (kquant-dynamic・18.30 GiB) との比較も2枚構成で取っている。

ビルド	生成 (tg128)	プロンプト処理 (pp512)
kquant-17gb・レイヤー分割	毎秒31.14トークン	毎秒1491.2トークン
kquant-dynamic・レイヤー分割	毎秒26.44トークン	毎秒1360.3トークン
kquant-17gb・テンソル並列	毎秒39.50トークン	毎秒1123.9トークン
kquant-dynamic・テンソル並列	毎秒34.54トークン	毎秒1086.6トークン

速度のみの比較になる。公式は大きい方を高品質版と位置づけているが、品質差は本記事では測っていない。大きい方は2枚構成でしか測っておらず、16GB 1枚での起動可否は確かめていない。

2枚構成の帯域と組み方についてはローカルLLMを2枚のGPUのVRAMプールで動かすで扱っている。

実測4: DFlashはどれだけ効くか

DFlashは複数トークンをまとめて提案する補助ネットワークで、公式はRTX 5090で毎秒74.9トークンから毎秒233.4トークンへ、3.1倍になったと示している。公式が示すのはRTX 5090・バッチ1・貪欲デコードでの値で、カードも構成も異なる環境にそのまま当てはめられない。速度を測った構成は単体のRTX 5090で、推論にはllama.cppが使われている。つまり2枚のGPUを要求する仕組みではない。

llama.cppで使う場合は、ドラフタのGGUFと –spec-type draft-dflash の指定が要る。提案できるトークン数は、学習時のブロックサイズ16のうち先頭1つが既知トークンのため最大15になり、16を指定しても15へ切り詰められる。

設定	生成速度の中央値	範囲	ドラフタなし比
ドラフタなし	毎秒30.71トークン	毎秒30.46〜30.76トークン	1.00倍
DFlash・n-max 16 指定	毎秒55.45トークン	毎秒52.26〜56.87トークン	1.81倍
DFlash・n-max 3 指定	毎秒50.73トークン	毎秒49.81〜51.43トークン	1.65倍

2枚構成 (RTX 5080 + RTX 5060 Ti・レイヤー分割・総コンテキスト指定4,096) で、1リクエスト256トークン生成を6回、暖機2回を除いた中央値。温度0の貪欲デコードで、公式が速度を測った条件に合わせている。この 1.81倍 は 2枚・レイヤー分割・総コンテキスト指定4,096 での値になる。提案が採用されるかどうかで速度が振れるため、ばらつきは他の測定より大きい。出力内容の一致は検証していない。

1枚でも試している。ドラフタを載せる余地を作るため、層数の指定を46に揃えた。

設定	生成速度の中央値	範囲	ドラフタなし比	提案が採用された割合
ドラフタなし	毎秒13.33トークン	毎秒13.18〜13.46トークン	1.00倍	—
DFlash・n-max 16 指定	毎秒14.92トークン	毎秒13.40〜15.85トークン	1.12倍	1051/6930 (15.2%)
DFlash・n-max 3 指定	毎秒22.85トークン	毎秒20.38〜23.75トークン	1.71倍	905/1860 (48.7%)

RTX 5060 Ti 単体・層数の指定46・総コンテキスト指定4,096で、ドラフタありのGPU全体使用量は 15,772 MiB。層の一部がCPU側にあるため、全層をGPUへ寄せた構成の数値とは直接比べない。この構成では n-max 3 の方が採用された割合が高く、速度も上だった。採用の割合はサーバが返す採択数を全 run で合算したもので、プロンプト依存で動く。本記事のプロンプトは技術的な説明を求める短い英文6種で、内容が変われば割合も倍率も変わる。出力内容がドラフタなしと一致するかは検証していない。

層数の指定を上げた状態では、ドラフタを読み込めなかった。

層数の指定	ドラフタの読み込み
99	できず
46	でき、生成も動いた
40	できた
30	できた
20	できた

99の指定ではモデル側だけでGPU全体の使用量が 15,742 MiB に達しており、カードの容量 16,311 MiB との差は約569 MiB しかない。ドラフタのファイルは1.6GBあるため、この差には収まらない。ファイルサイズと実際の確保量は同じではないため、この引き算は読み込めなかった理由の断定ではなく、量の見当になる。層数を下げて空きを作れば単体GPUでも読み込めており、書けるのは「この環境・このビルドでは99の指定で起動できなかった」まで。単体GPUでは使えないという制約ではない。

複数トークンをまとめて扱う高速化としてはMTP（マルチトークン予測）でローカルLLMは本当に速くなるかでも別のモデルを扱っている。

構成別の選び方

起動前に見る数字は二つ。今そのカードで何 MiB 使われているか (nvidia-smi の memory.used) と、その構成でどれだけ増えるか。本記事の RTX 5060 Ti・99指定・テキスト入力のみ・ドラフタなし・総コンテキスト指定4,096での増分は 15,742 MiB だった。画像入力やドラフタを足すと公式の目安では上積みがあるため、この数字はその断面での計画値にとどまる。合計が容量に収まる計算かどうかだけで可否が決まるわけでもなく、共有メモリへの退避があるため収まらない計算でも動く場合がある。

• 表示にも使う16GBが1枚: 同居分と結果が対応して動いていたため、他のアプリケーションを閉じた状態で測り直す価値がある。層数の指定を動かす場合は、生成だけでなくプロンプト処理も併せて見る (層数を上げるとプロンプト処理が先に落ちる形が出ている)。
• 表示に使っていない16GBが1枚: 本記事の RTX 5060 Ti は99の指定で起動している。総コンテキスト指定を上げると生成速度は下がり、原因は特定できていない。長い総コンテキスト指定を常用するなら、この低下を織り込んで判断する。
• 16GBが2枚: 本記事の構成では、生成はテンソル並列、プロンプト処理はレイヤー分割が速かった。テンソル並列は公式の説明では実験的な位置づけで、結果は2枚目を OCuLink (PCIe 4.0 x4) で足したこの接続条件での話になる。
• DFlashを使う: 1枚で使う場合は層数の指定を下げてドラフタの分の空きを作る。倍率は構成とプロンプトで変わるため、自分の用途のプロンプトで測り直す。

16GBで動かせるモデル全体の見取り図はVRAM 16GBで動かすローカルLLM完全ガイド、2枚目を足すかどうかの判断材料はAI用途にGPUは2枚必要かにまとめてある。24GB級を待つという選択肢については、RTX 50 SUPER（24GB）を待つべきかが待つかどうかを論じている。

よくある質問

Ollamaのタグでも同じ数字になるか

Ollama公式ライブラリのタグには、Apple Silicon向けのMLXタグに加えてGGUFのタグが用意されている (取得日時点で公開されているタグ一覧による)。ただしOllama経由の量子化は公式GGUFと別物になるため、本記事の実測値はそのまま当てはまらない。

llama-benchの数字とサーバ経由の数字が食い違うのはなぜか

条件が違う。llama-benchはチャットテンプレートを通さず、サーバ経由の測定は思考を伴う応答を返すテンプレートを通る。測ったトークン数の範囲では思考部分しか返っていないため、サーバ側の値は生成速度であって、回答が返るまでの速さではない。二つは別々に見る。

画像入力も使いたい場合、この記事の数字は使えるか

使えない。画像入力には知覚エンコーダのファイルを別に読み込ませる必要があり、公式の目安ではテキストのみの約17GBが約19GBへ上がる。本記事はテキスト入力のみの構成しか測っていない。

出力の品質はどうか

本記事が測ったのは生成速度・プロンプト処理速度・起動時の確保量だけになる。出力品質・回答の正しさ・エージェントとしての実用性は測っていないため、本記事からは何も言えない。

llama.cpp を新しくしても同じ数字になるか

測定に使ったのは llama.cpp b10356 と GPUドライバ 610.47で、どちらも計測した時点のもの。llama.cpp はほぼ毎日ビルドが出ているので、記事を読んでいる時点ではもっと新しいものが入っているはず。速度に関わる変更が入れば数字は動く。モデル側の配布ファイルが差し替わった場合も同じ。

まとめ

公式が想定として示すのは24GB。それに対して本記事で観測されたのは、16GB 1枚でも構成次第で起動し、速度は同居していた使用量や総コンテキスト指定によって大きく動くという範囲になる。16GBのGPU一般に当てはまる結論ではなく、特定の2枚のカード・特定の総コンテキスト指定・テキスト入力のみ・ドラフタなし (DFlashの節を除く) という断面での観測にとどまる。

判断の順序は、起動前の使用量と増分を見る、常用する総コンテキスト指定で測り直す、生成とプロンプト処理を別々に見る、の並びになる。総コンテキスト指定を上げたときの低下は原因を特定できておらず、層数を減らして余裕を作る方法では戻らなかった。

DFlashの倍率は構成とプロンプトで変わる。公式の3.1倍はRTX 5090・バッチ1・貪欲デコードでの値で、本記事では2枚・レイヤー分割・総コンテキスト指定4,096で1.81倍、RTX 5060 Ti 単体・層数の指定46では n-max 3 の指定で1.71倍だった。

参考資料

• Meta AI Research: Introducing Muse Glimmer
• Muse-Glimmer-30B-GGUF モデルカード
• Muse-Glimmer-30B モデルカード
• llama.cpp: Muse Glimmer Support
• Ollama: muse-glimmer タグ一覧
• NVIDIA: System Memory Fallback (共有メモリへの退避)