397억인데 왜 17억처럼 작동하나요

MoE 구조가 만드는 가격 역설

Qwen3.5-397B-A17B의 전체 파라미터는 397억 개입니다. 그런데 실제로 토큰 하나를 처리할 때 활성화되는 파라미터는 17억 개에 불과합니다. 이게 MoE(Mixture-of-Experts) 아키텍처의 핵심입니다. 모델은 수십 개의 ‘전문가(Expert)’ 네트워크로 나뉘어 있고, 입력이 들어올 때마다 그 중 일부만 선택적으로 호출됩니다. 나머지는 아예 연산에 참여하지 않습니다.

알리바바 공식 블로그(출처: Qwen Team, qwen.ai/blog, 2026.02.15)에는 이렇게 명시돼 있습니다: “397B total parameters, just 17B are activated per forward pass.” 클라우드 API 비용은 실제 연산량(FLOPs)에 비례하기 때문에, 397B 모델을 17B 수준의 비용으로 쓸 수 있는 구조입니다. GPT-5.2나 Claude Opus 4.5 같은 Dense 모델은 매 토큰마다 전체 파라미터가 활성화됩니다. 파라미터 수가 같다면 MoE가 훨씬 저렴합니다.

처리 속도 차이가 나오는 이유

공식 문서에는 디코딩 처리량 수치도 나옵니다. 32k 컨텍스트 기준으로 Qwen3-Max 대비 8.6배, 256k 컨텍스트 기준으로 19.0배 빠릅니다(출처: Qwen Team, qwen.ai/blog, 2026.02.15). “전작보다 8배 빠르다”는 알리바바의 주장은 이 수치에서 나온 겁니다. 긴 컨텍스트로 갈수록 속도 격차가 더 벌어지는 구조입니다.

한 가지 더 짚어두면, GitHub 공식 저장소(github.com/QwenLM/Qwen3.5) 기준으로 소형 모델들은 2026년 3월 2일에 추가 공개됐습니다. 9B, 4B, 2B, 0.8B 모두 Apache 2.0 라이선스로 오픈소스입니다. 상업적 이용도 무료입니다.

세 모델을 실전 태스크로 비교하면

ChartGen AI팀이 2026년 2월 17일 LinkedIn에 공개한 실사용 비교 데이터가 있습니다. 실제 SaaS 매출 데이터로 20가지 데이터 시각화 태스크를 돌린 결과입니다(출처: Steven Cen, LinkedIn Pulse, 2026.02.17). GPT-5.2가 200점 만점에 178점, Claude Opus 4.5가 173점, Qwen3.5가 163점. GPT-5.2 대비 91.6% 수준입니다. 품질 격차는 8.4%p입니다.

출처: Steven Cen, LinkedIn Pulse (2026.02.17) / otomatic.ai 가격 데이터 (2026.02 기준, 변동 가능)

비용 격차가 실제로 중요해지는 순간

태스크 1회 단위로는 Qwen3.5($0.003) vs GPT-5.2($0.032) 차이가 $0.029에 불과합니다. 그런데 멀티에이전트 파이프라인에서 하나의 대시보드 생성에 모델이 5~8회 호출된다고 가정하면, 단순 1회 비용의 8배가 됩니다. 하루 1만 건의 태스크를 처리한다면 — Qwen3.5는 하루 $30, GPT-5.2는 하루 $320입니다(출처: ChartGen AI 분석, LinkedIn Pulse, 2026.02.17). 월로 환산하면 $900 vs $9,600. 연간 $10,480 vs $115,200입니다.

소형 모델은 싸지만 할루시네이션이 80%입니다

4B·9B 모델에서 나온 수치

Qwen3.5 라인업에는 0.8B부터 397B까지 8개 크기가 있습니다. 로컬 PC나 스마트폰에서 실행할 수 있는 소형 모델(4B, 9B)이 특히 화제가 됐는데, 4비트 양자화 기준으로 9B는 약 6GB, 4B는 약 3GB 정도면 실행할 수 있습니다. 문제는 Artificial Analysis(artificialanalysis.ai)가 2026년 3월 5일 공개한 벤치마크 데이터입니다.

AA-Omniscience(사실 확인 정확도 측정) 기준으로 Qwen3.5 4B의 할루시네이션률은 80%, 9B는 82%입니다(출처: Artificial Analysis, artificialanalysis.ai, 2026.03.05). 직전 세대인 Qwen3 4B의 84%보다 소폭 개선됐지만 여전히 10회 중 8회가 잘못된 사실을 생성할 수 있는 수준입니다. 즉, 사실 확인이 중요한 작업에는 소형 Qwen3.5 모델을 사용할 수 없습니다.

대형 모델에서도 발생하는 코드 할루시네이션

Reddit(r/LocalLLaMA, 2026.03.01)에 올라온 실사용 보고에 따르면, Qwen3.5-122B-A10B를 스마트 컨트랙트 코드 리뷰에 사용했을 때 존재하지 않는 버그를 “치명적 오류”라고 보고하고, OpenZeppelin의 실존 함수(`forceApprove()`)가 없다고 주장했다는 사례가 있습니다. 다만 이 사례는 Q4 양자화 모델 기준이고, 같은 스레드에서 397B 풀 모델을 H100×4에서 돌린 사용자는 “완전히 다른 경험”이었다고 반박했습니다. 양자화 수준과 하드웨어 설정에 따라 결과가 크게 달라지는 구조입니다.

멀티에이전트 파이프라인에서 제자리를 찾는 방법

세 모델을 단계별로 배분하는 전략

ChartGen AI의 실험 결과를 보면, 세 모델이 각각 두드러지는 영역이 다릅니다. GPT-5.2는 인사이트 추출과 대시보드 구조 설계에서 강하고, Claude Opus 4.5는 수치 계산 정확도에서 단독 선두입니다(20개 태스크 중 수치 오류 0건). Qwen3.5는 멀티스텝 에이전트 흐름에서 가장 구조적으로 실행합니다. 이 격차를 이용한 하이브리드 전략이 나왔습니다(출처: ChartGen AI, LinkedIn Pulse, 2026.02.17).

이 전략의 핵심은 호출 빈도가 높은 중간 단계에 Qwen3.5를 배치하는 것입니다. 파이프라인의 가장 잦은 단계를 10분의 1 비용 모델로 커버하면, 전체 파이프라인 비용이 절반 이하로 내려갑니다. Qwen3.5를 “싸고 기능 다 되는 만능 모델”로 쓰기보다는, 비용이 집중되는 중간 단계 전용 모델로 운영하는 게 더 현실적입니다.

에이전트 도구 생태계가 이미 연결돼 있습니다

Qwen3.5 공식 GitHub(github.com/QwenLM/Qwen3.5)에 따르면, Alibaba Cloud ModelStudio API는 OpenAI 호환 엔드포인트를 제공하므로 Claude Code, Cline, OpenClaw 같은 코딩 에이전트 환경에 바로 연결할 수 있습니다. 알리바바는 $3/월 코딩 플랜도 제공하는데, 이 플랜으로 Qwen3.5, GLM-5, Kimi K2.5, MiniMax M2.5를 Claude Code 인터페이스에서 사용할 수 있다는 설정 가이드가 Reddit(r/ClaudeCode, 2026.02.28)에 공개돼 있습니다.

로컬 실행 — 어디서 막히는지 직접 확인했습니다

소형 모델은 소비자 GPU로 됩니다

Qwen3.5 공식 GitHub 기준(2026.03.02 릴리스)으로 소형 모델의 4비트 양자화 VRAM 요구량은 다음과 같습니다: 9B는 약 6GB, 4B는 약 3GB, 2B·0.8B는 2GB 미만. RTX 4060(8GB)이나 M3 MacBook Air(18GB 통합 메모리)에서도 9B 모델을 실행할 수 있습니다. llama.cpp, MLX(Apple Silicon 전용), vLLM, SGLang 모두 Qwen3.5를 지원합니다.

양자화 수준이 결과를 크게 바꿉니다

Reddit 실사용 스레드(r/LocalLLaMA, 2026.03.01)에서 반복적으로 나온 지적이 있습니다. 35B-A3B MoE 모델을 IQ4_XS 양자화로 실행하면 변수명 대소문자 오류 같은 “오타형 버그”가 잦고, 같은 모델을 Q8 이상으로 올리면 현저히 줄어든다는 것입니다. 코딩 용도라면 최소 Q5 이상, 이상적으로는 Q8을 권장하는 목소리가 많았습니다. 모델 크기를 줄이고 양자화를 높이는 것이 모델 크기를 늘리고 양자화를 낮추는 것보다 대체로 낫습니다.

대형 모델(122B 이상)은 멀티 GPU 필요

122B-A10B나 397B-A17B는 개인 환경에서 제대로 실행하기 어렵습니다. Q4 양자화 기준으로 122B 모델은 약 60~70GB가 필요합니다. RTX 5060 Ti 2장(VRAM 32GB)으로는 Q4_K_M 양자화로 초당 약 12토큰 정도가 나온다는 실사용 보고가 있습니다. SGLang 기준 397B 모델은 4개 이상의 고사양 GPU를 전제로 합니다. 클라우드 API 사용이 현실적인 선택입니다.

결국 언제 쓰면 되고, 언제 쓰면 안 되나요

Qwen3.5가 유리한 상황

반복 호출이 많은 멀티에이전트 파이프라인의 중간 단계, 대규모 코드 생성(신규 프로젝트, 표준 언어 기준), 시각적 에이전트 작업(화면 조작·UI 이해), 1M 토큰 이상의 장문 컨텍스트 처리, 자체 호스팅이 필요한 규정 준수 환경 — 이 다섯 가지에서 Qwen3.5는 현실적인 선택입니다. 특히 Qwen3.5-Plus는 기본 컨텍스트 창이 100만 토큰으로 설정돼 있고(출처: Qwen Team, qwen.ai/blog, 2026.02.15), 긴 문서를 반복 처리할 때 유리합니다.

Qwen3.5를 쓰면 안 되는 상황

수치 정확도가 생명인 작업(재무 계산, 의료 정보, 법률 검토), 니치한 도메인 코딩(스마트 컨트랙트·희귀 언어), 소형 모델(4B·9B)로 사실 확인이 필요한 작업 — 이 경우에는 Claude Opus 4.5나 GPT-5.2가 더 안전합니다. Claude의 수치 오류율이 실험에서 0%였다는 점, Qwen3.5 소형 모델의 할루시네이션률이 80% 이상이라는 점이 그 이유입니다. 비용을 아끼려다 오류 수정 비용이 더 나올 수 있습니다.

Q&A

마치며

“397억 파라미터가 왜 싼가”라는 질문의 답은 구조에 있습니다. 총 파라미터와 활성 파라미터가 다른 MoE 아키텍처 덕분에, 비용은 17억 수준으로 유지하면서 397억이 가진 지식을 쓸 수 있는 구조입니다. 이건 실제로 흥미로운 설계입니다.

다만 “싸니까 다 되겠지”라는 기대는 수치가 뒤집습니다. 소형 모델의 80% 할루시네이션, 코딩 작업에서의 양자화 민감도, 그리고 수치 정확도에서 Claude Opus 4.5에 뒤처지는 부분은 분명히 있습니다. Qwen3.5는 “모든 것을 GPT-5.2 수준으로 대체”하는 모델이 아니라, “비용이 높게 쌓이는 반복 단계에서 품질 손실 없이 교체할 수 있는 모델”입니다.

솔직히 말하면, Qwen3.5가 가장 돋보이는 순간은 단독으로 쓸 때가 아니라 다른 모델 옆에 섰을 때입니다. 그 역할을 명확히 정해서 운영하면 비용 구조가 완전히 달라집니다.

본 포스팅 참고 자료

1. Qwen Team — Qwen3.5: Towards Native Multimodal Agents (qwen.ai, 2026.02.15)
2. QwenLM — Qwen3.5 GitHub 공식 저장소 (github.com, 2026.02.16~03.02)
3. Reuters — Alibaba unveils new Qwen3.5 model (reuters.com, 2026.02.16)
4. Steven Cen — Qwen 3.5 vs GPT-5.2 vs Claude Opus 4.5 (LinkedIn Pulse, 2026.02.17)
5. Artificial Analysis — Qwen3.5 Small Models Analysis (artificialanalysis.ai, 2026.03.05)