Qwen 3.6 vs Gemma 4, Pac-Man 한 판에서 갈린 local LLM 평가축

이번 비교가 LocalLLaMA에서 크게 퍼진 이유는 숫자 한 줄 때문이 아니다. 실험 조건이 꽤 거칠었기 때문이다. 작성자는 MacBook Pro M5 Max 64GB 한 대에서 두 모델에게 Pac-Man 스타일 게임을 단일 HTML 파일로 끝까지 생성하라고 시켰다. 그것도 절차적 21×21 미로, 네 마리 ghost의 pathfinding, 모바일·키보드 조작, localStorage 점수 저장, requestAnimationFrame 기반 루프, particle 효과, 막히는 엔티티와 unreachable pellet 금지까지 한꺼번에 요구하는 긴 프롬프트였다.

결과는 단순한 tokens per second 비교로 정리되지 않았다. Qwen 3.6 27B는 초당 32토큰으로 18분 04초 동안 33,946토큰을 썼고, 더 화려하고 길게 답했다. 반면 Gemma 4 31B는 초당 27토큰으로 3분 51초, 6,209토큰만 쓰고도 클릭 반응, 벽 충돌, ghost 상호작용, particle 효과 같은 게임 로직을 더 또렷하게 정리했다는 평가를 받았다. 작성자는 이 one-shot 대결에서는 Gemma가 분명한 승자였다고 적었다.

댓글도 그 지점을 파고들었다. 높은 추천을 받은 반응 하나는 “성능은 안정적이어야 하고 버그가 없어야 한다”는 요구가 프롬프트에 들어간 것 자체가 웃기다고 했고, 다른 쪽은 이런 식의 덜 규정된 프롬프트가 결국 모델이 Pac-Man을 얼마나 이미 알고 있느냐를 보는 benchmaxxing에 가깝다고 지적했다. 또 다른 사용자는 훨씬 느슨한 프롬프트로 Qwen을 다시 돌렸더니 전혀 다른 화면이 나왔다며, 평가 설계에 따라 인상도 크게 달라진다고 보여줬다.

그래서 이 글의 핵심은 Gemma가 이겼다는 선언보다, local LLM을 어디서 평가하느냐에 있다. 토큰 속도와 총 토큰 수는 여전히 중요하지만, agent처럼 긴 지시를 받고 브라우저에서 바로 돌아갈 결과물을 내놓는 상황에서는 완성도, 오류 회피, 상호작용 품질이 따로 점수판을 만든다. LocalLLaMA가 이 실험에 붙은 이유도 벤치마크 숫자보다 그 새로운 평가축이 더 실감났기 때문이다.

Source: Reddit discussion