로컬 코딩 테스트에서의 Qwen 35B-A3B MoE vs 27B dense 비교: 예상보다 4배 빠르고 품질 차이는 훨씬 적음
Qwen 35B-A3B MoE vs 27B dense in local coding tests: ~4× faster, much smaller quality gap than I expected
핵심 요약
로컬 환경에서 MoE 모델이 dense 모델보다 4배 빠른 속도를 보이면서도 코딩 성능 차이는 미미하다는 실험 결과입니다.
- 성능 비교 — MoE 모델이 dense 모델 대비 약 4배 빠른 속도 기록함
- 코딩 품질 — 기본적인 버그 수정 능력은 비슷하며 dense 모델은 복잡한 엣지 케이스에서만 우위를 보임
- 실험 환경 — Radeon R9700 및 llama.cpp를 활용한 로컬 환경에서 테스트 진행됨
- 모델 평가 — 활성 파라미터 수만으로 실제 성능을 판단하는 것에 대한 회의적 시각 제시
저는 Qwen 35B-A3B MoE 모델을 Qwen 27B dense 모델과 비교하여 일련의 로컬 코딩 유지보수 작업을 수행했습니다. 제 R9700/llama.cpp 환경에서 MoE 모델은 약 3.9배 더 빠르게 (~116 vs ~30 tok/s) 생성되었지만, 코딩 품질 차이는 제가 예상했던 것보다 훨씬 작았습니다.
두 모델 모두 일반적인 버그 수정이나 다중 파일 변경은 대체로 정확하게 처리했습니다. 테스트 난이도를 점진적으로 높였을 때 dense 모델이 우위를 보이긴 했지만, 기본적인 정확성보다는 암시적 불변성, 흔치 않은 엣지 케이스, 그리고 문자 그대로의 요청을 넘어선 결과 측면에서 주로 나타났습니다.
모델
- Qwen 3.6 35B-A3B — Q5_K_M (MoE)
- Qwen 3.6 27B BASE — Q4_K_XL (dense)
하드웨어/런타임
- Radeon AI PRO R9700 32 GB
- Ryzen 9 5950X
- llama.cpp, Vulkan, 전체 GPU 오프로드
- 이번 코딩 테스트를 위해 8K 컨텍스트 사용
초기에 수행한 제어된 파서 복구 테스트가 이를 잘 보여줍니다:
- 35B-A3B: ~116 tok/s, 잠정 점수 7/10
- 27B dense: ~30 tok/s, 잠정 점수 7/10
이 결과 하나만으로 제 주장을 펼치는 것은 아닙니다. 저는 이후 임포트, 안정적인 ID, 충돌 처리, 데이터 보존, 그리고 ID가 재매핑될 때 유효하게 유지되어야 하는 참조 등을 포함하는 점진적으로 더 어려운 다중 파일 테스트를 진행했습니다.
지금까지의 결론은 의도적으로 좁게 정의하자면 이렇습니다: 이 작업들에서 약 4배의 처리량 차이는 제가 관찰한 실제 코딩 품질 차이보다 훨씬 컸습니다.
이것은 MoE와 dense 아키텍처에 대한 보편적인 주장이 아니라 작은 로컬 실험일 뿐입니다. 양자화 방식도 다르기 때문에 학술적으로 통제된 아키텍처 비교라고 할 수는 없습니다. 하지만 이 결과로 인해 활성 파라미터 수를 실제 성능의 직접적인 지표로 취급하는 것에 대해 회의적이게 되었습니다.
원본 프롬프트, 소스 픽스처, 정확한 llama.cpp 명령어, 원시 터미널 기록, 그리고 점진적으로 어려워지는 통합 테스트 자료를 가지고 있습니다. 세부 사항을 파고들고 싶으신 분들을 위해 아래 댓글에 방법론과 예시를 더 추가하겠습니다.
