Gemma 4 초기 평가는 섣부르다? llama.cpp 수정 이슈를 짚은 LocalLLaMA 토론
LocalLLaMA에서는 Gemma 4 초기 문제의 일부가 model 자체보다 llama.cpp runtime bugs와 support lag에서 비롯됐을 수 있다는 지적이 나왔다. 여러 pull request와 user report가 early benchmark를 다시 해석해야 한다는 근거로 제시됐다.
원문: Gemma 4 fixes in llama.cpp 원문 보기 →
LocalLLaMA에서 빠르게 퍼진 이 토론은 Gemma 4 초기 평가를 그대로 믿기 어렵다는 문제를 제기한다. 요지는 단순하다. 많은 사용자가 model 자체를 평가한다고 생각하지만, 실제로는 아직 안정화되지 않은 llama.cpp runtime을 통해 Gemma 4를 보고 있다는 것이다. local model launch에서는 weights만이 아니라 parser, tokenizer, attention handling, quantization, memory behavior까지 포함한 전체 inference stack이 동시에 성숙해야 한다.
원문은 Gemma 4 지원과 관련된 여러 llama.cpp pull request를 직접 연결한다. 예를 들어 PR #21418, PR #21390, PR #21406 등이 언급된다. 작성자는 chat에서 looping 문제가 있었지만 OpenCode에서는 문제를 거의 보지 못했다고 적었고, overthinking/looping 현상도 prompt나 runtime fix의 영향을 받을 수 있다고 본다. 핵심은 Gemma 4가 완전히 solved되었다는 선언이 아니라, launch 직후의 나쁜 impression 상당수가 model quality보다 tooling lag에서 나올 수 있다는 지적이다.
댓글도 같은 방향으로 흘러간다. 한 사용자는 “llama.cpp를 업데이트해야 한다”고 단언하면서 4B model을 RTX 3070에서 초당 60 tokens 수준으로 돌리고 있다고 적었다. 또 다른 댓글은 이 패턴이 release 때마다 반복된다고 요약한다. 처음에는 model이 형편없어 보이고, tokenizer나 inference bugs가 고쳐진 뒤에야 실제 성능이 드러난다는 것이다. local LLM ecosystem이 community builds와 forks 중심으로 움직이는 지금, 이런 operational detail은 benchmark 숫자만큼 중요해졌다.
이 스레드가 흥미로운 이유는 평가 대상을 model에서 system 전체로 확장시키기 때문이다. local inference에서는 하나의 weak link만 있어도 launch 품질이 크게 왜곡된다. 그래서 LocalLLaMA 사용자들은 Gemma 4를 둘러싼 논쟁을 “좋은 model인가, 나쁜 model인가”가 아니라 “지금 보고 있는 failure가 어느 layer에서 발생하는가”라는 질문으로 다시 정리하고 있다. 실제 deployment에 더 가까운 관점이다.
관련 기사
Qwen3.8-Flash-Next 오픈소스 공개 — Qwen4 아키텍처 미리 보기
알리바바 Qwen 팀이 Qwen4 아키텍처의 초기 프리뷰인 Qwen3.8-Flash-Next를 오픈웨이트로 공개했다. 125B 파라미터(활성 6B)와 51B N-gram 임베딩을 갖추고, Qwen3.7-Plus 대비 훈련 비용 9분의 1로 코딩·에이전트 성능에서 앞서는 결과를 보였다.
익명으로 등장해 리더보드 석권한 Ox Alpha, 정체는 Z.AI
OpenRouter에 익명으로 공개돼 각종 벤치마크 상위권을 차지한 오픈소스 모델 Ox Alpha가 GLM 시리즈를 만든 중국 AI 연구소 Z.AI의 작품으로 밝혀졌다. 코딩·장기 에이전트·멀티모달 워크플로 특화 설계가 특징이다.
700줄 C코드로 만든 현대 LLM — gemma4.c 프로젝트 공개
개발자가 Google Gemma 4 E2B 모델을 실행하는 700줄짜리 단일 C 파일 gemma4.c를 공개했다. 외부 의존성 없이 일반 CPU에서 실행되며, 코드 전체를 읽으면 LLM 추론 원리를 이해할 수 있다.