r/LocalLLaMA가 주목한 llama.cpp reasoning budget 제어
Original: Llama.cpp now with a true reasoning budget! View original →
왜 LocalLLaMA가 이 변경에 반응했나
local reasoning model은 강력하지만, 단순한 질문에도 길게 생각하면서 latency와 token을 낭비하는 일이 잦다. 그래서 r/LocalLLaMA thread가 이 llama.cpp commit에 바로 반응했다. 이번 변경은 real reasoning-budget sampler를 추가하고, parser와 chat handling을 확장해 reasoning block 내부의 token 수를 세다가 budget이 끝나면 종료를 유도할 수 있게 만든다. 기존의 --reasoning-budget가 사실상 template 쪽 disable stub에 가까웠다면, 이제는 sampler layer에서 직접 제어하는 방향으로 바뀐 셈이다.
이 post가 좋은 이유는 단순 기능 소개가 아니라 실패 데이터까지 함께 보여준다는 점이다. 작성자에 따르면 hard cutoff는 Qwen3 9B HumanEval score를 크게 망가뜨렸다. full reasoning은 94%, non-reasoning은 88%였는데, 강제 budget은 78%까지 떨어졌다. 이를 완화하려고 추가된 것이 --reasoning-budget-message다. thinking이 끝나기 직전에 짧은 handoff message를 넣어 모델이 자연스럽게 answer phase로 넘어가게 하는 방식이며, budget 1000과 transition message를 썼을 때 보고된 HumanEval score는 89%까지 회복됐다.
thread가 드러낸 실전 쟁점
comments는 금방 control problem으로 옮겨갔다. 어떤 사람은 end-of-think token의 bias를 점진적으로 올려 hard stop보다 자연스러운 종료를 만들자고 했고, 다른 사람은 CLI와 HTTP field naming 차이를 지적했다. 또 여러 사용자는 로컬 환경에서 reasoning model이 사소한 prompt에도 80초 넘게 overthink하는 문제가 실제 사용성을 크게 해친다고 말했다. 결국 필요한 것은 on/off toggle 하나가 아니라, latency, power, answer quality를 조절하는 실전용 knob라는 뜻이다.
그래서 이 commit의 의미는 parser tweak 이상이다. local inference stack이 hosted reasoning API처럼 운영 제어면을 갖추기 시작했다는 신호다. MacBook, desktop, 소형 server에서 llama.cpp를 돌리는 사람들에게 reasoning budget은 benchmark용 옵션이 아니라, 체감 사용성을 바꾸는 기능에 가깝다.
Related Articles
r/LocalLLaMA에서는 `llama.cpp` pull request #19504가 병합된 뒤 Qwen3.5와 Qwen-Next에서 token generation 속도가 좋아졌다는 보고가 올라왔다. PR은 `GATED_DELTA_NET` op의 CPU/CUDA 구현을 추가한다.
r/LocalLLaMA 게시글은 Mac 사용자를 March 11, 2026에 merge된 llama.cpp pull request #20361로 이끌었다. 이 PR은 fused GDN recurrent Metal kernel을 추가하며, Qwen 3.5 계열에서 대략 12-36% throughput 향상을 제시한다. Reddit commenters는 change가 master에는 들어갔지만 일부 local benchmark에서는 여전히 MLX가 더 빠를 수 있다고 덧붙였다.
LocalLLaMA의 한 글은 RX 9070 XT에서 llama.cpp `--ubatch-size`를 64로 낮췄더니 Qwen3.5-27B의 prompt processing 속도가 크게 뛰었다고 보고했다. 핵심은 64가 만능값이라는 것이 아니라, prompt ingestion과 token generation이 `n_ubatch`에 전혀 다르게 반응할 수 있다는 점이다.
Comments (0)
No comments yet. Be the first to comment!