태그
#llama-cpp 태그가 달린 기사
LocalLLaMA가 반응한 포인트는 “LLM이 스스로 빨라진다”는 농담 같은 구조가 실제 benchmark 숫자로 이어졌다는 점이었다. 작성자는 llm-server v2의 --ai-tune이 llama-server help를 context로 읽고 flag 조합을 돌며 fastest config를 cache한다고 설명했고, Qwen3.5-27B Q4_K_M은 18.5 tok/s에서 40.05 tok/s까지 올라갔다고 공유했다.
HN이 크게 반응한 이유는 한 wrapper의 호불호가 아니라, local LLM stack에서 누가 credit과 control을 가져가는지에 대한 불편함이었다. Sleeping Robots의 글은 Ollama가 llama.cpp 위에서 성장했지만 attribution, model packaging, cloud routing, model storage에서 사용자 신뢰를 깎았다고 주장했고, 댓글은 “그래도 UX는 압도적으로 쉽다”는 반론까지 붙었다.
Daniel Vaughan의 Gemma 4 실험은 “local model도 Codex CLI에서 쓸 만한 agent가 될 수 있는가”를 실제 설정값과 실패 사례까지 포함해 검증했다. 핵심은 Apple Silicon에서 Ollama를 포기하고 llama.cpp와 `--jinja`, KV cache quantization, `web_search = "disabled"` 같은 세부 설정을 맞춰야 한다는 점이다.
54점 Reddit post는 merged PR #19441을 통해 qwen3-omni-moe와 qwen3-asr support가 llama.cpp에 들어왔다고 알렸고, 댓글은 local multimodal과 ASR 실사용 기대를 드러냈다.
r/LocalLLaMA의 새 벤치마크는 Gemma 4 31B와 E2B draft 조합에서 speculative decoding이 평균 29%, code 생성에서는 약 50%의 속도 향상을 낼 수 있다고 전했다.
r/LocalLLaMA의 한 stress test는 Gemma 4 26B A4B가 llama.cpp에서 262,144 context window의 약 94% 지점에서도 일관성을 유지했다고 주장한다. 정식 benchmark는 아니지만, failure mode와 tuning 값을 함께 공개했다는 점에서 현장감 있는 자료다.
LocalLLaMA의 고득점 스레드는 llama.cpp에 merge된 PR #19378을 계기로 <code>--split-mode tensor</code> 기반 multi-GPU 실행이 더 현실적인 옵션이 됐다고 봤다. 다만 현재 성숙도는 CUDA 중심이며, ROCm은 돌아가도 layer split보다 느릴 수 있고 Vulkan은 성능과 안정성 모두 과제로 남아 있다.
Hacker News에서 주목한 SkyPilot 글은 coding agent가 코드를 건드리기 전에 논문과 경쟁 구현을 읽도록 하면 llama.cpp CPU inference 최적화 품질이 실제로 올라간다고 주장했다. 4대의 cloud VM과 약 29달러 비용으로 TinyLlama 1.1B 기준 x86 text generation을 15%, ARM을 5% 끌어올렸다는 점이 핵심이다.
LocalLLaMA의 고득점 게시물은 llama.cpp PR #21534 merge 이후 Gemma 4의 current master support가 사실상 안정권에 들어섰다고 봤다. 다만 핵심은 fix 자체보다 tokenizer correctness, chat template, memory flag, 그리고 CUDA 13.2 회피 같은 운영 조건이었다.
LocalLLaMA 글은 최근 llama.cpp 수정 사항 때문에 Gemma 4 GGUF를 다시 내려받을 필요가 생겼다고 주장하며, 로컬 추론 사용자들이 주목해야 할 변경점을 정리했다.
LocalLLaMA에 공유된 Mac LLM Bench 결과는 32GB Apple Silicon 환경에서 MoE 모델이 dense 32B 계열보다 더 나은 latency-to-capability 균형을 보일 수 있음을 시사한다. 중요한 점은 숫자 하나보다 재현 가능한 benchmark workflow 자체다.
LocalLLaMA에서는 Gemma 4 초기 문제의 일부가 model 자체보다 llama.cpp runtime bugs와 support lag에서 비롯됐을 수 있다는 지적이 나왔다. 여러 pull request와 user report가 early benchmark를 다시 해석해야 한다는 근거로 제시됐다.