Local Qwen3.8 Muse Glimmer Test
시작하기 전에
본론 들어가기 전에 요즘 Local 에서 LLM 돌리면 돈내고 쓸 필요 없다면서 수백G 의 메모리를 가진 머신을 아무렇지도 얘기하고 있는 사람들이 있는데… 내가 여기서 찍고 간다.
Local LLM 용 HW 는 Geforce RTX 3090/4090 까지다. RTX 5090 은 왜 빼냐고? GPU 에 650만원을 태울 수 있다면 그 돈으로 그냥 Claude 나 Codex 구독하는게 훨 낫기 때문이지… 즉 Local LLM 은 게임용으로 산 PC (혹은 개발용으로 산 맥) 에서 돌릴만한 수준으로 스펙을 한정해야 한다. 그래서 나도 앞으로 옆 컴퓨터에 있는 3090 한장 빼와서 3090 2장으로 테스트하는것을 그만 두기로 했다. 흔한 상황이 아닐테니까..
자긴 회사에서 쓸거라고? 회사에서 쓸거면 전문가에 의해 다 세팅된 HW 와 SW 셋을 돈만주면 구할 수 있기 때문에 이 글을 읽을 필요가 없고, LLM 연구자면 더더욱 LLM 연구용으로 나온 머신을 쓰면 된다.
암튼 이번에 또 로컬용으로 쓸 만한 오픈가중치 모델 2개가 공개되었다. Qwen3.8 27B와 Muse Glimmer 30B다. 테스트 환경은 아래의 3가지이다. 24G 에 꽉 차도록 세팅했다. 비교를 위해 상용 모델들의 스펙도 같이 올려본다. 초당 토큰 수는 3090 기준이며, 4090은 약 10% 정도 빠르다고 생각하면 되고, 5090 은 약 50% 빠르다고 생각하면 된다.
Muse 쪽은 파라메터 대비 Layer 가 얇아 KV 캐시를 적게 먹는 편이라, KV 는 양자화를 하지 않았다. Qwen 은 KV 양자화를 안할수는 없는 소모량이라 남는 메모리를 전부 Context 에 주었다. 아래 표 외에도 파라메터를 조정해 가면서 다양하게 테스트 해 보았으며, 그 부분은 마지막에 간단히 언급하겠다.
| Model | Loader | Context | 모델 양자화 | KV 양자화 | 초당 토큰 |
|---|---|---|---|---|---|
| Qwen 3.8 27B | llama.cpp | 192K | Q4 | Q4 | 15 |
| Qwen 3.8 27B | ExLlamaV3 | 192K | Q4 | Q4 | 30 |
| Muse Glammer 30B | llama.cpp | 128K | Q4 | X | 35 |
| Claude Sonnet 5 | ? | 1M | ? | ? | 70 |
| Gemini 3.7 Flash | ? | 1M | ? | ? | 350 |
위에 Muse Glammer 의 ExLlamaV3 버전이 없는데, 현재까지 Muse Glammer 에 MuseGlimmerForConditionalGeneration 가 아직 포함되지 않아 실행이 불가능 했기 때문이다. 하지만 테스트 결과를 보면 궂이 해보진 않을 것 같다.
일단 다시한번 말하지만, 난 AI 로 프로그래밍 시키는 것 외에는 별 관심이 없다. 만약 hermes 나 openclaw 로 1회성 요청을 처리 하는것이 목적이거나, 문서를 정리하는 정도의 목적이라면 지금의 작은모델로도 충분히 잘 한다.
테스트 진행
테스트엔 OpenCode 1.18.18 을 사용했다. Codex CLI 나 Claude Code 는 자신들이 제공하는 최소 1M 의 Context 에 맞춰져 있어 시스템 프롬포트가 긴편이라, 작업이 불가능 할 정도로 Context 가 금방 소진 되기 때문이다. 추론 레벨은 xhigh 이다.
테스트로 시킨것은 개인적으로 작업하고 있는 Kotlin + SpringBoot + Exposed + React 프로젝트에서, SpringBoot 쪽에 인터셉터를 추가하고 UI 를 살짝 개선하는 정도의 작업을 진행하였다.
Qwen + llama.cpp 조합의 경우 퀄리티는 나쁘지 않았지만, 속도가 지나치게 느려 현실적으로 사용이 불가능 할 정도였다. 토큰 생성 속도와 별도로 Qwen 은 Muse 대비 Prompt Processing 이 엄청나게 느렸는데, 덕분에 초당 토큰수는 2배정도 밖에 차이나지 않지만 실제 작업 속도는 4배 이상 느렸다.
Qwen + Exl3 의 경우, 토큰 생성 속도는 빨라졌으나, Prompt Processing 속도가 빨라 진 것은 아니기때문에 실제로 2배가 빨라진것은 아니다. 기껏해야 1.5배 정도? 그런데 같은 Q4 양자화임에도 불구하고 Exl3 의 경우 사용이 불가능 할 정도로 Tool Calling 이 자주 실패하였다.
llama.cpp 의 경우는 같은 작업을 4번 반복하여 실행 하는 동안 단 한번의 실패도 관측되지 않은것과 비교된다.
Muse + llama.cpp 조합의 경우 그럭저럭 쓸만 한 수준의 속도가 나왔고, Tool Calling 의 실패 역시 없었다. 하지만 결과물이 정말로 컴파일만 되는 수준의 엉터리 코드를 만들어 냈다. 여러 문제점이 있었지만 필터의 우선순위를 높인답시고 @Order(Ordered.HIGHEST_PRECEDENCE - 1) 같은 코드를 만들어내는 도저히 봐줄 수 없는 수준의 퀄리티였다. Muse 는 그냥 못쓴다고 보면 된다.
특이한 점으로는 복잡한 작업이 필요 할 시, Qwen 은 대부분의 경우 PowerShell 을 바로 부르는 반면, Muse 는 Python 을 호출하는 경향이 강하다. 덕분에 Python 찌꺼기가 자주 남는 단점도 있다.
저번 Gemma4 테스트 때보다 훨씬 많이 돌렸는데도, 작은 모델 특유의 무한루프 현상은 발견되지 않았다.
결론
- 둘 다 Gemma4 보단 훨씬 낫다.
- 아직까지 실 개발에 쓸 정도는 아니다.
- 구리다고 욕먹는 Gemini 3.7 Flash 의 근처에도 못 따라간다. 개인적으론 Local Gemini 3.7 Flash 성능을 쓸 수 있다면, 특이점이 온 것이 아닐까 생각한다. 그게 GPU 가격이 내려서 큰 모델을 돌릴 수 있어서이든, 그냥 모델 성능이 좋아서이든…
- 모델 양자화 보다는 KV 양자화가 퀄리티를 더 치명적으로 낮춘다. KV 를 양자화 해야되는 상황이면 차라리 Context를 줄이자.
- 만약 게임용으로 5090 을 가지고 있다면
나좀빌려줘Qwen 3.8 110K Context 에 KV 양자화 없이 돌린다면 상당히 좋은 느낌일 것이다. 하지만 실제 써먹을 정도가 아닌건 여전하다. - 비슷한 모델 사이즈 일 경우 Layer 가 깊은쪽이 퀄리티가 좋은 느낌이다. 하지만 KV 캐시 용량이 커지니 단점도 크다.
- Muse 는 52 Layer, Qwen 은 65 Layer 이다
- 만약 llm 을 돌리기 위해 gpu 를 구매하려고 하고 있다면, 그 돈으로 AntiGravity 20년 구독하는게 더 효율적일거다. 더 빠르고, 더 좋은 모델을 전기비 절약하면서 쓸 수있다.
잡설
- 여러 모델을 테스트 해 보면서 느끼는 건데 MoE 모델은 그냥 딱 실제 동작하는 파라메터 만큼의 성능만 나온다. Gemma 4 26B A4B 면 4B 모델이거나 조금 나은 정도의 성능을 낼 뿐이다. 프로그래밍용 모델은 Dense 모델 쓰자.
- 같은 메모리 사이즈라면 작은 모델보단, 큰 모델을 작게 양자화 한 모델이 성능이 좋은 느낌이다.