【ローカルLLM検証 環境構築編#8】Qwen3 32Bをサクサク動かせないのか？

　前の記事でかなり雑にQwen3:32Bを動かした検証内容を書きました。
【ローカルLLM検証 環境構築編#5】ローカルLLM：Qwen3 32Bはサクサク動くのか？

結果として処理時間がかなり掛かり、かつ、チャットに文字が出てくるのがかなり遅かったです。これを解消できる術はないか？Claudeさんに相談してみました。

課題

　前述のとおり、Qwen3:32Bのレスポンスが遅い。
　VRAMは32GB積んでおり量子化されていれば十分快適に動く（ローカルLLMとしての快適ですｗ）

解決策

　結論から言うとQwen3:32Bのレスポンスが改善されました。手順は下記です。

量子化Bitを確認する

　下記のコマンドをPowerShellから打ち込みます。

ollama show Qwen3:32b | Select-String "quantization"

　下記のような結果になり、デフォルトで4Bit量子化であることが確認できます。これは望んでいた通りで、量子化するとしても最小4Bitまでかと思っています（3Bitまでいくと理論上精度がかなり下がる見込み）
そのため量子化Bitは問題ないようです。

原因

　では何が原因かとClaudeさんに相談です。
まず、下記のコマンドでローカルLLMが動いているときのVRAM使用量を確認します。

ollama ps

すると下記の結果。VRAMが28GBも取られており、32GB積んでいるとはいえ流石にキツキツです。どうもメモリ使い過ぎの様子。

　これを元にClaudeさんに原因を聞きましたが、ざっくり下記とのこと。

対処法：num_ctxを下げる

考察用途なら記事本文＋あらすじで数千字程度のはずなので、32768という上限まるごとは不要です。

bash
ollama run qwen3:32b
/set parameter num_ctx 8192

または実行時オプションで直接指定する形でも構いません。コンテキストを絞ればKVキャッシュ用のVRAMが減り、SIZE表示も28GBから大きく下がって、GPU内で余裕を持って完結するはずです。まずこれを試して速度が変わるか確認してみてください。

　どうやらコンテキストを不必要に大きく設定しているのが原因みたいです。

コンテキストの変更

　手段というより使い方により方法は2つあるみたいです
①OpenWebUIの設定でチャット上のコンテキストを指定する
②Ollama runでモデルのコンテキストを変える（コンソールで使用している場合）

OpenWebUIで使用するので①を実施してみます。チャット右上のコントロールから下記のようにnum_ctxをカスタムで8192に指定します

これで準備完了。
さて、「こんにちは！」と打ち込みます

ん？何か遅いです

　使用量も28GBから変わってませんでした。

　新しいチャットに変えてもう1度やってみます。
　お！使用量が変わりました！

　返ってきました！

　ただもう一度見ると28GBに戻ってる。。。なんだこれは。。。

　再度チャットしてみましたがチャット中は22GBまで落ちるのですが、終わると28GBに戻ってしまいます。

　レスポンス自体は早くなっていますが、どうも挙動が不安定な気がします。念のため、パソコンを再起動して再度実施しましたが挙動は変わりませんでした。　
　Claudeさんに聞いたところ、これはOllamaの仕様というより挙動みたいです。必要なバッファを確保したりするので、メモリの開放などを繰り返しているようです。

　私の体感としては圧倒的に早くなっているのでこの運用で進めていけば使えそうです！

まとめ

　パラメータ数32B（それ以外でも）のモデルを動かす場合は

• 量子化Bitを確認する
  →　VRAM容量に近いパラメータ数（私の場合はVRAM32GBで、モデルのパラメータ数32B、この数値部分）の場合は、4bitがよい
• チャットやコンソールでモデルを使用しているときのコンテキスト長を確認する
  →　長い会話をしないのであれば、コンテキスト長を減らす。
  　　特にOllamaはデフォルトのコンテキスト長が大きめなので、実際の用途に合わせて必要なサイズまで絞ることが、VRAM使用量とレスポンス速度の両方を改善する近道でした