最近はSonnetとかのクラウドLLM使ってClineとかで遊ぶAIコーディングにかまけてて、ローカルLLMを云々するのがおろそかになっていた。
というのも、クラウドLLMでコーディングするのは相変わらずSonnetがベストだが、DeepSeekのV3やR1が出てきて、安くて性能がいいAPIが使えるようになった。私の手元で動かすローカルLLMなんかじゃ天地がひっくり返ってもV3の性能にはかないそうにない。つまりDeepSeekショックでクラウドLLMのコスパは爆上がりしている。
以前、私が「ローカルLLMがアツいらしい」みたいな記事を書いた時はクラウドLLMは高いAPIばっかりでコスパに問題があったので、だからMacとかグラボ買ってローカルLLM使う方がいい可能性が無くはなかったが、今となってはそんなん買うより素直にAPI叩いた方がいい気がする。
そんな風にスルー気味だったローカルLLMだが、この前QwQ-32Bが登場した。
QwQ-32BはQwenベースの思考モデルだが、ベンチスコアはなんとR1に匹敵するという。たった32BパラのQwQが、総パラ数671BのR1並みだって？このパラ数なら私のRTX4090でも普通に動くだろう。
QwQ-32BならローカルLLMでClineがゴリゴリ動いてしまうかもしれない（これまでのローカルLLMだと基本的に使い物になってなかった）…これは試してみる価値あるかも。
ローカルLLMを動かす環境は色々あるが、今回はLlama.cppを使う。リポジトリの公式説明によれば「デプロイには、vLLM を使用することをお勧めします」などと書かれてるが、GGUFも配布してるところからするとLlama.cppやOllamaでもいいんだろう。 ClineからはLLMプロバイダとしてOllamaが選択できるし、Ollamaの方がいんじゃね？と思うかもしれない。
Ollamaライブラリにはおあつらえ向きにCline用に設定されたQwQ-32Bなんかもある↓
実際これを試そうとしたけど、ロードしたらVRAMからはみ出たので萎えた。OllamaじゃなくてLlama.cppならkvキャッシュを量子化するとかVRAMに収めるために色々とやりようがあるが、OllamaはLlama.cppラッパーのくせにLlama.cppの機能が使えないがちで、kvキャッシュ量子化にも対応してない。Ollamaは色々面倒な事を隠蔽してて初心者にも使いやすいだろうけど、逆に凝った設定したくてもできなくて正直言って好きじゃない。
というわけでLlama.cppのサーバでQwQ-32Bをロードする。VRAM24GBの場合、Q4_K_Mだとコンテキスト長は大体16kくらいでVRAMギリギリになる。
./llama-server.exe -c 16000 -n 5000 -ngl 100 -fa -m "I:\\llama\\llamacpp\\models\\QwQ-32B-Q4_K_M.gguf" --host 0.0.0.0
パラメータについて：
-c：コンテキスト長を指定する。これを増やすほど消費するVRAMも増える。実際ロードしてみないとVRAM消費がどれくらいか分からない
-n：最大生成トークン数を指定する
-ngl：VRAMオフロードするレイヤー数を指定する。とりま100にしとけば全レイヤーがVRAMにロードされる。VRAMにオフロードされたレイヤーはCPUではなくGPUで処理される
-fa：フラッシュアテンションを使う。推論がちょっと速くなって、メモリ消費も減る