Qwen3.5-397B-A17B 기준
IT/AI
Qwen 3.5, 저렴하다고요? 이 조건 먼저 보세요
Qwen 3.5 Plus API가 Claude Sonnet 4.6보다 7.5배 저렴하다는 건 사실입니다. 그런데 Thinking 모드를 켠 채로 쓰면 그 차이가 빠르게 좁혀집니다. 397B 파라미터 모델인데 실제 추론에 쓰이는 파라미터는 17B, 즉 전체의 4.3%뿐이라는 구조적 이유까지 — 공식 수치로 직접 정리했습니다.
397B인데 왜 17B처럼 빠른가요?
결론부터 말씀드리면, Qwen 3.5는 모든 파라미터를 동시에 쓰지 않습니다. 총 397B 파라미터 중에서 각 추론 단계마다 실제로 활성화되는 것은 17B, 전체의 4.3%뿐입니다. (출처: Qwen 공식 GitHub, 2026.02.16)
이게 가능한 이유는 스파스 Mixture-of-Experts(MoE) 아키텍처 때문입니다. 512개의 전문가(Expert) 중에서 입력 토큰에 따라 소수의 전문가만 선택적으로 활성화하는 방식입니다. 직전 세대 Qwen3 MoE가 128개 전문가였던 것에 비해 512개로 4배 확장되면서 동일 입력에 더 전문화된 응답이 가능해졌습니다.
그 결과로 256K 컨텍스트 기준 디코딩 처리량이 Qwen3-Max보다 19배, Qwen3-235B-A22B보다 7.2배 빠릅니다. (출처: Qwen 공식 블로그, 2026.02.15) 파라미터 수만 보고 “무거운 모델”이라고 판단하면 이 구조적 차이를 놓칩니다.
💡 공식 벤치마크와 아키텍처 문서를 같이 놓고 보니 이런 차이가 보였습니다. 397B 모델이 17B 모델과 비슷한 추론 비용을 내는 이유는 단순히 “효율화”가 아니라 아예 설계 원칙이 다른 겁니다. 이 구조는 토큰당 비용 계산 방식에도 직접 영향을 줍니다.
가격 차이가 실제로 얼마나 나나요?
수치를 직접 보겠습니다. 2026년 3월 기준 주요 모델의 API 가격입니다.
| 모델 | 입력 (100만 토큰) | 출력 (100만 토큰) |
|---|---|---|
| Claude Opus 4.6 | $5.00 | $25.00 |
| Claude Sonnet 4.6 | $3.00 | $15.00 |
| GPT-5.3 Codex | $1.75 | $14.00 |
| ✅ Qwen 3.5 Plus | $0.40 | $2.40 |
(출처: @alex_prompter X 포스트, 2026.03.08 / Anthropic 공식 가격 페이지)
Claude Sonnet 4.6 대비 입력 토큰은 7.5배, 출력 토큰은 6.25배 저렴합니다. 월 1,000만 토큰을 사용하는 팀이라면 Claude Sonnet 기준 약 $180(입력 기준)이 드는 것을 Qwen 3.5 Plus로 $40에 처리할 수 있다는 계산입니다. 이 차이는 단순한 할인이 아니라, MoE 아키텍처로 인한 구조적 비용 차이에서 비롯된 겁니다.
💡 “가격이 싸다 = 성능이 낮다”는 전제가 여기서 흔들립니다. Qwen 3.5는 벤치마크 기준으로 Claude Opus 4.5, GPT-5.2와 경쟁하는 수준이면서 가격은 Claude Sonnet보다 낮습니다. 단, 이 비교는 API 가격이며, Thinking 모드를 켜면 달라집니다(다음 섹션 참고).
Thinking 모드, 켜면 비용이 오릅니다
Qwen 3.5 Plus에는 세 가지 모드가 있습니다: Fast(빠른 응답), Auto(적응형), Thinking(심층 추론). (출처: Qwen 공식 블로그, 2026.02.15) 문제는 Thinking 모드를 켜면 토큰 소비량이 크게 늘어난다는 점입니다.
공식 블로그에서 Qwen3 계열의 Thinking 모드를 비교한 연구 결과를 보면, 같은 평가를 완료하는 데 Qwen 3.5가 Qwen 3에 비해 토큰을 2~5배 더 사용합니다. (출처: Reddit r/LocalLLaMA, Qwen3 vs Qwen3.5 performance, 2026.03.10) — 구체적으로는 Qwen 3이 40~50M 토큰을 썼다면 Qwen 3.5는 86~260M 토큰을 소비한다는 측정값이 보고됐습니다.
숫자로 계산해 보면: Thinking 모드로 260M 출력 토큰을 생성했을 때 Qwen 3.5 Plus 기준 비용은 약 $0.624입니다. 같은 작업을 Fast 모드(50M 토큰 가정)로 했다면 $0.12입니다. 한 번의 복잡한 추론 작업에서 5배 이상 차이가 납니다. Thinking 모드는 복잡한 수학·코딩 작업에서 정확도가 올라가는 건 맞지만, “항상 켜두는” 방식은 비용 측면에서 비효율적입니다.
⚠️ 로컬에서 소형 모델(4B, 9B)을 Thinking 모드로 실행하면 속도 문제도 함께 옵니다. M1 Mac 16GB 사용자들 사이에서 “생각 단계만 몇 분씩 걸린다”는 보고가 다수 올라와 있습니다. (출처: Facebook OpenClaw Korea 그룹, 2026.03.06) 소형 모델에서 Thinking 모드는 Fast 모드보다 결과가 오히려 더 나쁜 경우도 있다는 점은 확인이 필요합니다.
로컬로 돌리려면 어떤 장비가 필요한가요?
Qwen 3.5 오픈 웨이트 모델은 Apache 2.0 라이선스로 완전 무료 사용이 가능합니다. (출처: GitHub QwenLM/Qwen3.5) 로컬 실행 시 모델 크기별 최소 RAM 요구사항은 아래와 같습니다.
| 모델 | 최소 RAM (Q4 양자화) | 실용적 장비 |
|---|---|---|
| Qwen3.5-0.8B | 8GB | M1 MacBook Air |
| Qwen3.5-4B | 8GB | M1 MacBook Air |
| Qwen3.5-9B | 16GB | M1 Pro/16GB 기기 |
| Qwen3.5-27B / 35B-A3B | 22GB | M2 Pro/24GB 이상 |
| Qwen3.5-397B-A17B | 512GB (권장) | 서버급 멀티 GPU |
(출처: Unsloth 공식 문서 qwen3.5, 2026.03.05 / apxml.com GPU 가이드)
35B-A3B 모델의 경우 총 파라미터는 35B지만 MoE 구조로 실제 활성 파라미터는 3B밖에 안 됩니다. 그래서 22GB RAM으로 실행이 됩니다. M2 Pro MacBook에서 약 27 토큰/초 속도가 나온다는 실측값이 있습니다. (출처: Reddit r/LocalLLaMA, 2026.03.03) 이 속도는 실용적인 코딩 세션에 충분한 수준입니다.
단, 플래그십 397B 모델의 경우 FP16 기준 약 917GB RAM이 필요하며, 이는 멀티노드 서버 환경이 아니면 현실적으로 돌리기 어렵습니다. 로컬 실행을 고려한다면 27B 또는 35B-A3B가 현실적인 선택입니다.
코딩 작업에서 멈추는 지점이 있습니다
벤치마크 수치가 좋다고 해서 모든 코딩 작업에서 동등하게 작동하지는 않습니다. 70개의 실제 GitHub 레포지토리를 기반으로 한 독립 벤치마크(APEX Testing, 2026.02.25)에서 Qwen 3.5 397B는 쉬운 작업에서 ELO 1,550점을 기록했지만, 마스터 수준(여러 파일을 걸친 복잡한 장기 작업)에서는 ELO 1,194점으로 급락했습니다. 같은 테스트에서 Claude Opus 4.6은 상위권을 유지했습니다.
쉽게 말하면, “버그 하나 고치기”나 “엔드포인트 추가하기” 같은 단일 파일 작업은 잘 처리하는데, 여러 파일과 여러 단계를 넘나드는 복잡한 리팩토링이나 대규모 기능 구현에서는 맥락을 잃어버리는 현상이 발생합니다. 이는 구조적 제약이라기보다 현재 버전의 한계로 보이며, 추후 업데이트로 개선될 가능성은 있습니다(확인 필요).
💡 35B-A3B MoE 모델의 경우 상황이 더 명확합니다. ELO 1,256점으로 27B 밀집 모델(1,384점)보다 오히려 낮았습니다. MoE 구조에서 활성 파라미터가 3B밖에 안 되는 것이 멀티스텝 에이전트 작업에서 한계로 드러난 겁니다. 파라미터 효율이 추론 속도에서는 장점이지만, 복잡한 장기 맥락 유지에서는 아직 과제가 남아 있다는 뜻입니다.
한국어 처리가 달라진 이유
Qwen 3.5에서 어휘 사전(vocabulary) 크기가 기존 150k에서 250k 토큰으로 67% 늘었습니다. (출처: Qwen 공식 블로그, 2026.02.15) 이 숫자가 한국어 사용자에게 직접적으로 의미 있는 이유가 있습니다.
어휘 사전이 클수록 한국어처럼 복잡한 형태소 구조를 가진 언어를 더 적은 토큰으로 표현할 수 있습니다. 공식 기술 문서에 따르면 대부분의 언어에서 인코딩·디코딩 효율이 10~60% 향상됐습니다. (출처: Qwen 공식 블로그) 한국어 기준으로 계산하면, 동일한 텍스트를 처리하는 데 소비되는 토큰 수가 줄어들어 같은 API 가격에서 더 많은 내용을 처리할 수 있습니다.
지원 언어도 Qwen 3의 119개에서 201개 언어/방언으로 확장됐습니다. 한국어는 이미 Qwen 3에서도 지원됐지만, 토크나이저 효율 개선으로 실질적인 비용 절감 효과가 추가됐습니다. 멀티링구얼 벤치마크(MMMLU)에서 88.5점, MMLU-ProX(29개 언어 평균)에서 84.7점으로 GPT-5.2(83.7)를 소폭 넘어서는 수치가 나왔습니다. (출처: Qwen 공식 블로그 벤치마크 테이블)
Q&A
마치며
Qwen 3.5를 쓸 이유는 충분합니다. Claude Sonnet 4.6보다 7.5배 저렴하고, 256K 컨텍스트에서 전작보다 19배 빠르며, 멀티모달 추론도 기본 탑재됩니다. 솔직히 말하면, 가성비라는 단어가 어울리는 모델입니다.
하지만 “무조건 켜두면 싸다”는 접근은 맞지 않습니다. Thinking 모드는 토큰을 2~5배 더 씁니다. 로컬 실행은 27B/35B 모델은 실용적이지만 397B는 서버 환경이 필요합니다. 복잡한 멀티파일 코딩은 아직 Claude Opus 계열보다 일관성이 낮습니다.
조건을 알고 쓰면 상당히 매력적인 모델입니다. API로 빠르게 프로토타입을 만들 때, 멀티링구얼 서비스를 구축할 때, 또는 로컬에서 무료로 실험하고 싶을 때 — Qwen 3.5는 지금 시점에서 선택지로 충분히 올려놓을 수 있습니다.
본 포스팅 참고 자료
- Qwen Team, “Qwen3.5: Towards Native Multimodal Agents” — https://qwen.ai/blog?id=qwen3.5 (2026.02.15)
- QwenLM GitHub 공식 저장소 — https://github.com/QwenLM/Qwen3.5
- VentureBeat, “Alibaba’s Qwen 3.5-397B-A17B beats its larger trillion-parameter model” — VentureBeat 기사 (2026.02.18)
- APEX Testing, “Qwen 3.5 craters on hard coding tasks” — Reddit r/LocalLLaMA (2026.02.25)
- Unsloth 공식 문서, “Qwen3.5 – How to Run Locally Guide” — https://unsloth.ai/docs/models/qwen3.5
⚠️ 본 포스팅은 2026년 03월 17일 기준으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능·가격이 변경될 수 있습니다. API 가격은 Alibaba Cloud 공식 페이지에서 반드시 최신 정보를 확인하시기 바랍니다. 벤치마크 수치는 공식 발표 기준이며 실사용 환경에 따라 결과가 다를 수 있습니다.
댓글 남기기