はじめに

プロンプトキャッシュの回で、サーバの起動ログにこの行を見つけました。

srv    load_model: cache_reuse is not supported by multimodal, it will be disabled

使っている Qwen3.6-35B-A3B は画像も扱えるモデルで、-hf で指定すると画像用の mmproj（約 0.9 GB のファイル）が自動で読み込まれます。

ところが、llm コマンドも dev-orchestra のレビューも、テキストしか使っていません。使わない機能のために、毎回ファイルを読んでメモリを使っていたことになります。

外したら何が変わるのか。候補は 3 つありました。

メモリが減る（ほぼ確実）
起動が速くなる（読むファイルが 1 つ減る）
読み込み・生成が速くなる（llama-bench と実サーバの速度差、約 2 割の原因かもしれない）

3 つ目が当たれば、毎日の llm がそのまま速くなります。

チェックリストから設計する

前回、測定で 19 回間違えた経験をチェックリストにまとめました。今回はそれを最初から当てはめています。

チェック項目	今回の対応
設定が本当に有効か	起動ログに mmproj の読み込み行が出ていないことを確かめ、想定と違えば止まる
比べ方	あり → なし → あり → なし → ありと交互に 5 回。最初と最後の「あり」が揃うかでずれを見る
本番と同じ条件	`serve.ps1` と同じ引数（`-c 65536`、MTP あり）。違いは `--no-mmproj` だけ
割り込み	llama 以外が使った CPU・GPU を 10 秒ごとに記録
安全装置	スリープ抑止が効かなければ止まる。サーバが起動しなければ止まる
生データ	生成した文章の冒頭を記録し、両条件でまともな出力かを見る

1 つ目は --cache-reuse の件の反省です。「入れた設定が効いているはず」で 4 日間間違えていたので、効いていなければ計測自体を止めるようにしました。

測ったのは、起動時間、メモリ、32K トークンの読み込み時間、生成速度（256 トークン × 3 回）です。

1 回目の結果

#	mmproj	起動	メモリ（起動後）	生成（平均）	32K の読み込み
1	あり	9.7 秒	25.11 GiB	18.00 t/s	140.4 秒
2	なし	8.3 秒	24.12 GiB	19.13 t/s	133.6 秒
3	あり	9.4 秒	25.21 GiB	18.42 t/s	144.9 秒
4	なし	9.6 秒	24.12 GiB	17.25 t/s	134.9 秒
5	あり	10.1 秒	25.21 GiB	19.22 t/s	125.5 秒

メモリは、はっきり 1 GiB 減った

「あり」は 25.11〜25.21 GiB、「なし」は 2 回とも 24.12 GiB。差は約 1.0 GiB です。5 回の中で値がほとんど動かず、両者の範囲は重なりません。これは言い切れます。

速度は、何も言えなかった

一方で速度は、表を見ても方向が定まりません。生成は「なし」の 1 回目が速く、2 回目が遅い。読み込みは「なし」が真ん中あたりに来ています。

決め手は、最初と最後の「あり」が揃っていないことでした。

	#1（あり）	#5（あり）	ずれ
32K の読み込み	140.4 秒	125.5 秒	−11%
生成	18.00 t/s	19.22 t/s	+7%

同じ条件なのに、計測の始めと終わりで 1 割動いています。「あり」どうしのばらつき（読み込み 125〜145 秒）の中に、「なし」の 134 秒がすっぽり収まっています。

条件の差より、計測中のずれのほうが大きい。 この状態で「速くなった」とも「変わらない」とも言えません。挟み込みで測ったおかげで、それが分かったとも言えます。1 回ずつの比較だったら、#4 と #5 を並べて「mmproj ありのほうが速い」と書いていたかもしれません。

監視に引っかかったもの

監視ログを見ると、16:14〜16:20 に llama 以外の CPU が 13〜22% まで上がっていました。上位は python3.13 と StreamDeck です。python3.13 は計測スクリプトではありません。

調べると、この PC の Python は Microsoft Store 版の 3.13 で、プロセス名が python3.13 と見えます。そして同じ時間帯に、別の Claude のセッションが dev-orchestra で作業していました。dev-orchestra はこの Python で動くツールです。裏で動いていたのは、それだと見ています（別セッションのログまでは確かめていないので、状況からの判断です）。

この区間は #3 の終盤と #4 にあたります。#4 の生成（17.25 t/s）が低いのは、その影響かもしれません。ただ、重なっていない #1 と #5 のあいだでも 1 割ずれているので、ずれの原因がこれだけとは言えません。

裏を止めて、測り直した

チェックリストの「割り込み」に**「別の Claude のセッションが動いていないか確かめる」**を足し、測り直しました。

測り始める前に確かめると、dev-orchestra のセッションの最終操作が 40 秒前でした。まさに使われていたわけです。そのセッションを止めてもらい、python のプロセスが無いことを確かめてから始めました。

回数も増やしています。あり → なしを交互に 7 回（あり 4 回、なし 3 回）。こうすると「なし」の各回を、前後の「あり」の平均と比べられます。計測中にゆっくりずれていっても、前後で挟めば打ち消せます。

#	mmproj	起動	メモリ（起動後）	生成（平均）	32K の読み込み
1	あり	25.0 秒 ※	25.06 GiB	18.91 t/s	133.2 秒
2	なし	8.3 秒	23.97 GiB	19.39 t/s	136.6 秒
3	あり	8.0 秒	25.06 GiB	18.87 t/s	136.0 秒
4	なし	7.1 秒	23.97 GiB	18.77 t/s	134.7 秒
5	あり	8.1 秒	25.06 GiB	18.91 t/s	136.8 秒
6	なし	7.3 秒	23.97 GiB	18.85 t/s	136.9 秒
7	あり	7.8 秒	25.06 GiB	18.86 t/s	136.3 秒

※ #1 は、直前まで動いていたサーバを止めた直後の起動です。

監視では、llama 以外の CPU は中央値 7.1% で、1 回目のような連続した山はありませんでした。

ずれが、1 割から 2% 前後まで縮みました。

	生成	32K の読み込み
最初と最後の「あり」（#1 と #7）	−0.2%	+2.3%
#2（なし）と前後の「あり」	+2.6%	+1.5%
#4（なし）と前後の「あり」	−0.6%	−1.2%
#6（なし）と前後の「あり」	−0.2%	+0.3%

「なし」と前後の「あり」の差は、向きが回ごとにばらばらで、大きさは 3% 以内です。mmproj を外しても速度は変わらない、と言ってよさそうです。正確には、差があったとしても 3% 未満です。

メモリは今回も、7 回とも同じ値でした（あり 25.06 GiB、なし 23.97 GiB、差 1.09 GiB）。

1 回目の 1 割のずれが、すべて dev-orchestra のせいだったのかは分かりません。重なっていない #1 と #5 のあいだでもずれていたからです。ただ、裏を静かにしただけで、同じスクリプトのばらつきが 5 分の 1 になったのは確かです。

出力は一字一句同じ

2 回の計測の計 12 回とも、生成した文章は冒頭から同じでした。

ローカルLLMをiGPU（統合グラフィックス）で動作させる最大の利点は、専用メモリ（VRAM）を必要とせず、…

mmproj は画像を読むための部品なので、テキストだけなら影響しないのは予想どおりです。ただ、予想どおりかどうかも確かめておくのが、今回のやり方です。

期待していた 2 つは外れた

--cache-reuse は、外しても使えませんでした。

srv    load_model: cache_reuse is not supported by this context, it will be disabled

理由が「マルチモーダルだから」から「このコンテキストでは非対応」に変わるだけです。このモデルは SSM とのハイブリッド構成で、KV をずらして使い回す仕組みとは両立しません。前回確かめたとおりでした。

**llama-bench と実サーバの速度差も、mmproj では説明できませんでした。**読み込みが 2 割速くなれば当たりでしたが、測り直した結果は 3% 未満の差です。原因は未解明のままです。

既定を変えた

既定は mmproj なしにしました。

	あり	なし
メモリ	約 25.1 GiB	約 24.0 GiB
起動	約 8 秒	約 7〜8 秒
テキストの出力	—	同じ
画像の入力	使える	使えない

失うのは画像の入力だけで、今は使っていません。93.6 GiB 積んだ機体で 1 GiB は小さな差です。それでも、使わない機能のためにメモリを使い続ける理由もありません。

serve.ps1 には -Vision を足し、画像が必要なときだけ読み込めるようにしました。

# 普段（llm の自動起動もこちら）
pwsh -File scripts\serve.ps1            # --no-mmproj が付く

# 画像を使うとき
llm -Stop
pwsh -File scripts\serve.ps1 -Vision    # mmproj を読み込む

変更後に llm から自動起動させ、--no-mmproj 付きで立ち上がって応答が返ること、メモリが 24.27 GiB になっていることを確認しています。

まとめ

テキストしか使わないのに、画像用の mmproj を毎回読み込んでいた
外すとメモリが約 1 GiB 減る。2 回の計測の 12 回ともほぼ同じ値で、言い切れる
1 回目は同じ条件の最初と最後が 1 割ずれ、速度について何も言えなかった
裏で別の Claude のセッションが dev-orchestra を動かしていた。止めて測り直すと、ずれは 2% 前後に縮んだ
測り直した結果、速度の差は 3% 未満。mmproj を外しても速くも遅くもならない
--cache-reuse は外しても使えず、llama-bench との速度差の原因でもなかった
既定は mmproj なしに変更。画像を使うときは -Vision

速くなる話を期待して測り始めましたが、速さは変わらず、確かに得たのは 1 GiB のメモリでした。

1 回目で「分からない」と書けたのも、2 回目で「変わらない」と言えるようになったのも、挟み込みで測って、ずれの大きさを見ていたからです。そして、ずれを 5 分の 1 にしたのは、測り方ではなく裏を静かにしたことでした。

この記事は tk3.biz のブログからの転載です。