はじめに
プロンプトキャッシュの回で、サーバの起動ログにこの行を見つけました。
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 のブログ からの転載です。