Gemma 4 26B A4B는 245K context에서도 버틸까
Original: Gemma 4 26B A4B is still fully capable at 245283/262144 (94%) contex ! View original →
커뮤니티가 본 Gemma 4의 긴 context
2026년 4월 12일 기준 r/LocalLLaMA에서 161 score와 71 comments를 모은 이 글은, Gemma 4 26B A4B를 262,144 context window에 가깝게 밀어붙인 실사용 stress test를 공유한다. 작성자는 Reddit posts, documentation, 그리고 llama.cpp raw files를 대량으로 넣어 VRAM 사용량과 응답 일관성을 확인했고, 245,283 / 262,144, 즉 약 94% 수준에서도 특정 사용자의 발언을 정확히 찾아 답할 수 있었다고 적었다.
글은 단순한 자랑보다 failure mode와 tuning 과정을 함께 적었다는 점이 눈에 띈다. 작성자에 따르면 100K context를 넘기면 model이 자기 생각을 반복하거나 self-questioning loop에 빠지는 일이 있었고, 이를 줄이기 위해 temperature를 낮추고 repeat penalty를 1.17 또는 1.18까지 올렸다. 이런 조정 뒤에는 2초에서 5초 사이에 관련 내용을 되짚는 응답을 얻을 수 있었다고 한다.
포스트에 포함된 실전 설정
- context size는 262144, GPU layers는 99로 설정했다.
top_p0.95,top_k40,min_p0.05,repeat_penalty1.17을 사용했다.- batch와 microbatch는 512, cache RAM은 2048로 맞췄고, 최신
llama.cpp와 최신 Unsloth GGUF를 사용했다고 적었다. - 작성자는 같은 세션에서 real-time NVIDIA SMI script 문제를 해결했으며, Gemini 3.1은 fresh session에서 이 문제를 고치지 못했다고 덧붙였다.
어떻게 읽어야 하나
이 결과는 재현성까지 검증된 논문형 benchmark가 아니라 개인 환경의 community report다. 하지만 local model 사용자는 바로 이런 디테일을 원한다. 어디서 model이 무너지는지, 어떤 sampling 값이 loop를 줄였는지, 최신 build가 얼마나 중요한지 같은 운영 단서가 들어 있기 때문이다. 긴 context marketing이 넘치는 시점에, 실제 실패 패턴과 설정 값을 같이 공개한 사례라는 점에서 참고 가치가 있다.
원문: r/LocalLLaMA post.
Related Articles
LocalLLaMA에서는 Gemma 4 초기 문제의 일부가 model 자체보다 llama.cpp runtime bugs와 support lag에서 비롯됐을 수 있다는 지적이 나왔다. 여러 pull request와 user report가 early benchmark를 다시 해석해야 한다는 근거로 제시됐다.
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를 다시 내려받을 필요가 생겼다고 주장하며, 로컬 추론 사용자들이 주목해야 할 변경점을 정리했다.
Comments (0)
No comments yet. Be the first to comment!