큐웬 35B(MoE)에서 27B로 교체, 코딩 성능 확연한 향상
큐웬(Qwen) 3.6 모델의 35B-a3b(MoE 구조)에서 27B(Dense 구조)로 전환해 코딩 및 디버깅 능력이 크게 향상된 로컬 AI 개발자의 사용기입니다. VRAM 한계로 압축률이 높은 IQ3 모델을 사용했음에도 불구하고 기존 모델보다 복잡한 버그를 더 잘 찾아냈으며, 전체적인 처리 속도도 안정적이었습니다.
약간의 배경 설명을 하자면, 저는 추가 웨이포인트를 배치하여 경로를 변경할 수 있는 간단한 HTML 타워 디펜스 게임을 코딩하고 있었습니다.
제 시스템 사양: 32GB RAM과 16GB VRAM을 탑재한 RTX 5070 Ti. OpenCode와 결합하여 LM Studio에서 AesSedai/Qwen3.6-35B-A3B-GGUF IQ4_XS 모델을 사용하고 있습니다. 이제 막 '원샷 무드 코딩 프롬프트(한 번의 질문으로 전체 코드를 짜달라고 하는 방식)' 수준을 졸업했습니다.
이 게임의 기획안은 꽤 복잡해서 LM Studio만으로는 처리하기 어려웠고, 그래서 OpenCode를 사용해 보았습니다. 프로젝트가 착실히 진행되고 있었고 Qwen3.6 35b-a3b 모델이 제 역할을 하고 있었는데, 마침 27b 모델이 공개된 것입니다. 당연히 시도해 볼 수밖에 없었죠. 유일한 문제는 VRAM 부족 문제로 인해 Q4 모델들을 사용할 수 없다는 점이었고, 그래서 mradermacher/Qwen3.6-27B-i1-GGUF의 IQ3_M 모델로 낮추어 사용하게 되었습니다.
IQ3_M 버전은 압축률이 너무 높아 성능 저하가 심하지 않을까 걱정했지만, 생각보다 아주 잘 작동했습니다. 심지어 IQ4_XS 버전의 Qwen3.6 35b-a3b 모델이 찾지 못했던 까다로운 버그까지 발견해 냈죠. 사람들 말로는 Dense(밀집) 모델이 MoE(전문가 혼합) 모델보다 양자화 압축을 더 잘 견딘다고 합니다. 이번 경험이 그런 이유 때문일까요? 다른 분들은 Qwen3.6의 35b-a3b 모델과 27b 버전을 비교해 보셨나요?
LM Studio에서의 체감 속도는 다음과 같습니다.
Qwen3.6 35b-a3b(AesSedai/Qwen3.6-35B-A3B-GGUF IQ4_XS)를 사용할 때는 초당 50~60 토큰이 나왔지만, 프롬프트 처리 속도가 가끔 매우 느려지는 현상이 있었습니다.
반면 mradermacher/Qwen3.6-27B-i1-GGUF IQ3_M를 사용할 때는 초당 40 토큰 정도가 나왔지만, 작업 전반에 걸쳐 속도가 꾸준하고 쾌적했습니다.
16GB VRAM 환경에서 이 두 가지 모델을 사용해 보신 분들의 경험은 어떠신가요? 혹시 27b 모델의 IQ3 버전으로 실제 작업을 하시는 분도 계신가요?
아, 참고로 웨이포인트 타워 디펜스 게임은 완성되어 htmlbin에서 직접 플레이해 보실 수 있습니다. 해당 사이트에서는 저장/불러오기 기능이 잘 작동하지 않는 것 같지만, 파일을 다운로드하여 브라우저에서 열면 정상적으로 작동합니다. 단일 HTML 파일로 만들어진 자급자족형 게임입니다. 지뢰찾기 같은 느낌을 주지만 타워 디펜스 장르입니다. 경로 생성 로직은 단순히 시작점에서 방문하지 않은 가장 가까운 웨이포인트를 찾아 연결하는 방식입니다. 모든 웨이포인트를 방문할 때까지 이 과정을 반복하죠.