LocalLLaMA가 공유한 llama.cpp 튜닝 팁, 작은 n_ubatch가 Qwen 27B prompt processing를 크게 끌어올렸다

이번 주말 r/LocalLLaMA에서 나온 실전 팁 하나는 많은 사용자가 한 번 정하고 지나치는 llama.cpp 옵션 하나에 집중했다. 바로 --ubatch-size다. 글 작성자는 Windows 11 환경에서 ROCm 빌드로 Qwen3.5-27B Q3_K_S를 돌리는 AMD RX 9070 XT 사용자인데, n_ubatch를 64로 낮춘 뒤 prompt processing이 Claude Code류 워크플로에 쓸 만한 수준으로 빨라졌다고 말했다. 더 높은 값에서는 체감상 상당히 느렸다는 설명이다.

이 글의 핵심은 benchmark 표에 있다. 작성자는 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 쪽에서 확인되는 개념적 기준점도 있다. 프로젝트 GitHub discussion과 현재 common.h 기본값 설명을 보면, n_batch는 prompt processing의 logical batch size이고, n_ubatch는 실제 계산에 쓰이는 physical batch size다. 현재 common.h의 기본값은 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 스레드
참고 문서: llama.cpp batch vs ubatch discussion, 현재 common.h 기본값