LocalLLaMA共有のllama.cpp調整法、小さなn_ubatchでQwen 27Bのprompt processingが大幅高速化

今週末のr/LocalLLaMAでは、多くのユーザーが一度決めたまま触らないllama.cppの設定項目ひとつに注目が集まった。--ubatch-sizeだ。投稿者はWindows 11上のROCm buildでQwen3.5-27B Q3_K_Sを動かしているAMD RX 9070 XTユーザーで、n_ubatchを64まで下げたところ、prompt processingがClaude Code系workflowで実用と感じられる速度になったと書いている。より大きい値ではかなり重かったという。

この投稿で重要なのはbenchmark tableである。投稿者はllama-benchを使い、-b 8192の条件でn_ubatchを4、8、64、128と比較した。その結果、当該マシンではpp512のprompt-processing throughputが4で約59.5 tokens/s、8で83.3 tokens/sだったものが、64では約582.4 tokens/sまで跳ね上がった。一方で128では約14.7 tokens/sまで急落した。これに対してtg128のtoken generation throughputは26.8〜27.1 tokens/s付近でほぼ横ばいだった。つまり、これは全体的なinference高速化というより、prompt ingestion側に強く効いた事例だ。

llama.cpp側にも概念的な手がかりがある。projectのGitHub discussionと現在のcommon.hの説明では、n_batchはprompt processingのlogical batch size、n_ubatchは実計算に使うphysical batch sizeとされている。現在のcommon.hのdefaultはn_batch = 2048、n_ubatch = 512だ。したがって、このReddit報告を“64が常に最適”と読むべきではない。より正確には、physical compute batchが特定のGPU、backend、model quantization、prompt-heavy workloadと鋭く相互作用しうることを示す例と見るべきだ。

この注意点は投稿者自身も認めている。sweet spotがRX 9070 XTのcache behaviorに結びつくのか、別のhardware-specific条件なのかは確信していないという。それでもこの結果が有益なのは、多くの利用者が一緒くたにしがちな二つの問題を分けて見せたからだ。prompt processingの高速化とtoken generationの高速化は同じ最適化問題ではない。長いcontextを頻繁に流し込むlocal workflowなら、n_ubatchは直接profilingする価値がある。

このスレッドが反応を集めた理由もそこにある。大きな理論を語ったのではなく、数値があり、再現条件があり、どこでボトルネックが崩れたのかが見える実践的なtuning anecdoteだったからだ。大きめのQwen checkpointをllama.cppで回すbuilderにとっては、それだけで十分にhigh-signalと言える。

コミュニティ出典: r/LocalLLaMA thread
参照資料: llama.cpp batch vs ubatch discussion, current common.h defaults