LocalLLaMAが沸いた自動チューニング、Qwen3.5-27Bが40 tok/sへ

r/LocalLLaMAの投稿が伸びたのは、発想が面白いだけでなく数字が付いていたからだ。投稿者の llm-server v2 は --ai-tune を追加し、modelがllama-serverのoptionsを読み、設定を試し、最速configをcacheするloopを回すという。

hardwareは3090 Ti、4070、3060、128GB RAMという、いかにもLocalLLaMAらしい構成だ。投稿者の数字では、Qwen3.5-122Bは通常のllama-serverで4.1 tok/s、v1 tuningで11.2 tok/s、v2 ai-tuningで17.47 tok/sになった。Qwen3.5-27B Q4_K_Mは18.5 tok/sから25.94 tok/s、さらに40.05 tok/sへ。gemma-4-31B UD-Q4_K_XLは14.2 tok/sから24.77 tok/sへ伸びた。

狙いは、ユーザーがruntime tuningの知識をすべて抱えなくてもよくすることだ。llama.cppやik_llama.cppはoffload、tensor split、context、MoE関連のflagを増やし続ける。multi-GPU環境ではlayer splitやtensor placementを少し外すだけで速度が大きく変わる。投稿者は llama-server --help をtuning loopのcontextに入れることで、新しいflagが増えた時にも候補として扱えると見ている。

コメント欄は期待と疑いが混ざっていた。以前のparametersと新しいparametersを見せてほしいという声、ROCmやVulkan対応を求める声、LLMを使わず単純なsearch scriptで十分ではないかという疑問が出た。一方で、multi-GPUのtensor splitを手で調整したことがあるユーザーは、最適値を当てる難しさに共感していた。

この結果は万能benchmarkではない。特定のmachine、model、driver、context条件に依存する。ただしcommunity signalははっきりしている。local LLMの性能は、よいquantを落とすだけの話ではなくなっている。runtime flags、hardware topology、cacheされたconfig、そして良い組み合わせをどれだけ速く探せるかが、performance stackの一部になりつつある。