LocalLLaMA가 꽂힌 자동 튜닝, Qwen3.5-27B가 40 tok/s까지 올랐다

r/LocalLLaMA 글이 170점 이상을 받은 이유는 benchmark 숫자도 크지만, 구조 자체가 커뮤니티 취향을 정확히 찔렀기 때문이다. 작성자는 llm-server v2에서 --ai-tune을 넣었고, model이 llama.cpp 계열 server flags를 읽어가며 더 빠른 설정을 찾고 cache한다고 설명했다. “LLM이 자기 runtime을 tuning한다”는 말이 meme처럼 들리지만, post에는 실제 tok/s 표가 붙었다.

공유된 rig는 3090 Ti, 4070, 3060, 128GB RAM 조합이다. 작성자 기준 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로 개선됐다.

핵심 아이디어는 search space를 사람이 전부 외우지 않아도 되게 만드는 것이다. llama.cpp와 ik_llama.cpp는 계속 새 flag와 offload option을 추가한다. multi-GPU rig에서는 tensor split, layer placement, context size, MoE 관련 option을 잘못 잡으면 성능 차이가 크다. 작성자는 llama-server --help를 tuning loop의 context로 넣으면 새 flag가 생겼을 때도 model이 후보로 고려할 수 있다고 봤다.

댓글은 기대와 의심이 섞였다. 어떤 사용자는 이전 parameter와 새 parameter를 비교해 달라고 했고, 다른 사용자는 ROCm이나 Vulkan version을 물었다. 또 다른 반응은 LLM이 꼭 필요한지, 단순 script나 brute-force search가 더 빠르지 않겠냐는 쪽이었다. 반대로 multi-GPU layer split을 손으로 맞춰 본 사용자들은 “guessing이 거의 불가능하다”는 데 공감했고, consumer hardware에서 이런 최적화가 나오는 것을 반겼다.

이 post의 가치는 universal benchmark가 아니라 workflow 신호에 있다. 특정 rig에서 나온 숫자이고, 다른 model, driver, context requirement에서는 결과가 달라질 수 있다. 그래도 LocalLLaMA가 여기에 반응한 이유는 명확하다. local LLM 성능 경쟁이 이제 model file만의 문제가 아니라, runtime flags, hardware topology, cache된 config, 그리고 그 조합을 얼마나 빨리 탐색하느냐의 문제로 옮겨가고 있다.