農家のローカルLLM　ハング再びの件

画像解析用にGPUで運用しているQwen3-VL-30B-Q4_K_M（以下Qwen3-VL）ですが、いつの間にかハングと言うかクラッシュしていた。調査と修正を行いました。ちなみに以前の記事から読むとわかりやすいというか、読んでる前提で話していますのでこちらから順番に（下から？）ご確認ください。

とりあえず、問題なく動いていたはずでは？

特に気づいていなかったというか、裏でサーバーが動いているだけで処理した際にあまり確認をしていなかったので止まっているかどうかも定かでは無かった。普通に使っていたので問題は感じなかったのですが、ただ、処理を見ていた時に、なんかおかしいぞとなってチェックしてみるとどうも処理が落ちている。と言うことでチェックスタート。

困った時のClaudeCode

ここでいつもの話なのですが、何でもClaudeCodeに丸投げ。なんか答えてくれるが、私がよく分かっていないので選択ができない。VRAMに何か異常が起きている？ClaudeCodeの提案では

Qwen3-VLの処理を
A　Vision処理をCPU、Text処理（LLM層）をGPU
B　Text処理（LLM層）をCPU、Vision処理をGPU
C　全てCPU

の三つ。こうしたところでどう改善されるのか。何に問題があるのかよく分からないので調査依頼。

問題点は既知の問題

llama.cpp開発者による説明では、"kqv計算時にkqをFP16に変換するためのバッファ割り当てが発生。大規模コンテキストではkqサイズがあらゆる重みサイズを上回り、メモリプール管理の限界に達する"

1. メモリリークではない - 設計上の制限

2. Vision処理特有 - 画像トークン化でFP16バッファが累積

3. 連続使用で悪化 - メモリプールの断片化

4. コンテキストサイズ依存 - 大きいほど問題が顕在化

何を言っているのか分からないが、問題があるのは分かった。

ではどうするか？

Cは論外として、AとBのどちらが良いのか。ClaudeCodeはBを勧めてくるが、よく分からない。ただ、Bの場合、Vision処理をGPUに置くと言っても、1GBもいかないくらいなのでVRAMががら空き。今回のシステム全体を考えて、Bを選んで、空いたGPUにQwen3-30B-Q4_K_M.gguf（以下Qwen3-30B）を入れることとする。Qwen3-30Bがそこそこ高速化するようなので（動作チェックでは2.4倍に）全体の処理としてどっちが最適なのかは分からない部分があるが、これで進めてみようと思う。

再度ClaudeCodeに聞いてみたが、Text処理（LLM層）が約2倍の速度差（上と大体同じ）でBが遅いが、実際の画像のサイズの処理を行うとVision処理の差が顕著（8～10倍差）なので、どう考えてもBらしい。

まとめ

今回の問題点はllama.cppで「Vision処理をGPUでやると問題」ではなく、「Qwen3-VLのような大規模MoEモデルをGPU-fullで実行し、かつVision処理を行うとメモリプール管理に問題が発生する」が正確です。なので、Vision処理をCPUに出すか、Vision処理部分のみをGPUに残してメモリプールの管理を単純化させれば問題はない。

これは既知の問題で修正は検討されているとのことですが、いつになるのだろうか。こんなの修正が発表されても私は気づかないだろうし、ClaudeCodeに丸投げするしかないな。