[온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계] 2/14화: Qwen3 아키텍처 해부 — Dense·MoE·양자화 변형 결정 가이드
이 글은 「온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계」 시리즈 2일차로, Dense·MoE·양자화 등 Qwen3의 변형 결정에 필요한 아키텍처 핵심을 해부합니다.
어제 1일차에서는 클라우드 대비 온프레미스의 트레이드오프를 짚고, Qwen3을 기준 모델로 선정한 6가지 이유(Apache 2.0 라이선스, 한국어 다국어, 사이즈 스펙트럼, vLLM·MLX 생태계, LLM·VLM 동일 패밀리, Thinking 모드)를 정리했습니다. 오늘은 그 Qwen3의 내부 구조를 해부합니다.
오늘의 핵심 3가지
- Dense vs MoE — Qwen3은 같은 패밀리 안에 Dense(0.6B~32B)와 MoE(30B-A3B, 235B-A22B) 두 갈래 아키텍처가 공존한다. MoE는 전체 파라미터 중 일부만 활성화해 “큰 모델의 품질, 작은 모델의 추론 비용”을 노린다.
- Thinking 모드 — Qwen3 Instruct 모델은 별도 에디션이 아닌 단일 모델 안에서 Thinking(추론 토큰 생성)과 Non-Thinking을 토글할 수 있다. 복잡한 문제엔 켜고, 단순 대화엔 꺼서 지연과 비용을 제어한다.
- 변형 결정 트리 — 사이즈(8B·14B·30B-A3B·32B·235B-A22B) × 양자화(FP16·FP8·AWQ·GGUF·MLX) × 하드웨어(Apple Silicon·NVIDIA CUDA)의 조합에서 우리 시스템에 맞는 변형을 고르는 의사결정 플로우를 제공한다.
Qwen3 아키텍처 기초 — Transformer 디코더의 현대적 변형
Qwen3은 GPT 계열과 마찬가지로 디코더 전용(decoder-only) Transformer 아키텍처를 기반으로 한다. 다만 2024~2025년 시점의 최신 기법이 대거 반영되어, 기존 GPT-2/3 시절의 구조와는 상당한 차이가 있다. 온프레미스 서빙 관점에서 특히 중요한 구조적 특성 네 가지를 먼저 짚겠다.
1. GQA (Grouped Query Attention)
전통적인 Multi-Head Attention(MHA)은 Query·Key·Value가 동일한 수의 헤드를 갖는다. Qwen3은 Grouped Query Attention(GQA)을 채택해 Key·Value 헤드 수를 Query 헤드 수보다 적게 설정한다. 예컨대 Qwen3-8B는 Query 헤드 32개에 KV 헤드 8개(4:1 비율)를 사용한다.
GQA가 온프레미스 서빙에서 중요한 이유는 KV 캐시 메모리다. 긴 컨텍스트(32K~128K 토큰)를 처리할 때 KV 캐시는 수 GB 단위로 불어나는데, GQA 덕분에 MHA 대비 KV 캐시 크기가 1/4로 줄어든다. 제한된 VRAM이나 통합 메모리 환경에서 이 차이는 동시 요청 수(concurrency)에 직접적으로 영향을 미친다.
2. RoPE (Rotary Position Embedding)
Qwen3은 위치 인코딩으로 RoPE(Rotary Position Embedding)를 사용한다. RoPE는 상대적 위치 정보를 회전 행렬로 인코딩해, 학습 시 보지 못한 긴 시퀀스에도 외삽(extrapolation)이 가능하다. Qwen3은 여기에 YaRN(Yet another RoPE extensioN) 스케일링을 결합해 기본 컨텍스트 길이(32K)를 128K까지 확장한다.
운영 관점에서의 시사점: 128K 컨텍스트를 실제로 쓰려면 KV 캐시만으로도 상당한 메모리가 필요하다. Qwen3-8B 기준 128K 토큰의 KV 캐시는 FP16에서 약 4 GB, Qwen3-32B에서는 약 10 GB에 달한다. “모델 가중치가 메모리에 들어간다”와 “긴 컨텍스트에서 실제 서빙 가능하다”는 별개의 문제다.
3. SwiGLU 활성화 함수
Qwen3의 FFN(Feed-Forward Network) 블록은 SwiGLU 활성화 함수를 사용한다. 기존 ReLU나 GELU 대비 파라미터 효율이 높아 같은 모델 크기에서 더 나은 성능을 낸다. 구조적으로 SwiGLU FFN은 gate 프로젝션(Wgate), up 프로젝션(Wup), down 프로젝션(Wdown) 세 개의 가중치 행렬을 갖는다. 이 때문에 전통적 FFN(2개 행렬) 대비 파라미터 수가 약 50% 더 많은데, Qwen3은 hidden dimension을 조정해 총 파라미터 수를 목표 범위에 맞춘다.
4. RMSNorm (Pre-Normalization)
각 Transformer 블록의 입력에 RMSNorm(Root Mean Square Normalization)을 적용한다. LayerNorm 대비 연산이 단순해 추론 속도에 미세하게 유리하고, 학습 안정성도 확보된다. 모든 Qwen3 변형(Dense·MoE 무관)이 동일하게 RMSNorm을 사용하므로, 서빙 스택에서 커스텀 커널 최적화를 적용할 때 일관성이 보장된다.
Dense vs MoE — 두 갈래 아키텍처
Qwen3 패밀리의 가장 큰 구조적 분기점은 Dense 모델과 MoE(Mixture of Experts) 모델의 공존이다. 같은 패밀리 안에서 두 아키텍처를 모두 제공하는 것은 온프레미스 배포에서 핵심적인 설계 자유도를 부여한다.
Dense 모델 — 모든 파라미터가 매번 활성화
Dense 모델은 전통적인 Transformer 구조 그대로다. 입력 토큰이 들어오면 모델의 모든 파라미터가 연산에 참여한다. Qwen3의 Dense 변형은 다음과 같다:
- Qwen3-0.6B — 6억 파라미터. 임베딩·분류 등 극경량 태스크용.
- Qwen3-1.7B — 17억 파라미터. 모바일·엣지 디바이스 타깃.
- Qwen3-4B — 40억 파라미터. 경량 서버 또는 데스크탑 로컬 추론.
- Qwen3-8B — 80억 파라미터. 라우팅·분류·간단한 대화. 가성비 구간.
- Qwen3-14B — 140억 파라미터. 범용 대화·요약·번역. 단일 GPU 서빙 가능 구간의 상한.
- Qwen3-32B — 320억 파라미터. 복잡한 추론·코딩·분석. Dense 모델 중 최대.
Dense 모델의 장점은 예측 가능성이다. 메모리 사용량 = 파라미터 수 × 정밀도별 바이트 크기(+ KV 캐시). 추론 연산량도 토큰당 일정하다. vLLM, mlx-lm, llama.cpp 등 모든 서빙 프레임워크가 안정적으로 지원한다.
반면 단점은 스케일링의 비효율이다. 8B → 14B → 32B로 올리면 품질은 좋아지지만, 추론 비용(지연·메모리·전력)이 파라미터 수에 비례해 증가한다. 32B를 넘어서면 단일 GPU에 담기 어려워지고, 이때부터 MoE의 가치가 드러난다.
MoE 모델 — 전문가 라우팅으로 효율성 확보
MoE(Mixture of Experts)는 모델의 FFN 블록을 여러 개의 전문가(Expert) 네트워크로 분할하고, 각 토큰에 대해 소수의 전문가만 선택적으로 활성화하는 구조다. Qwen3의 MoE 변형 두 가지를 해부해 보자.
Qwen3-30B-A3B — “30B 규모, 3B 비용”
모델명의 A3B는 “Active 3B”, 즉 토큰당 활성 파라미터가 약 30억이라는 뜻이다.
- 전체 파라미터: 약 300억 (30B)
- 토큰당 활성 파라미터: 약 30억 (3B)
- 전문가 구성: 각 MoE 레이어에 다수의 세분화된(fine-grained) 전문가 + 공유 전문가(shared expert)
- 라우팅: 상위-k(top-k) 라우팅. 각 토큰이 통과하는 전문가가 동적으로 결정됨
- 레이어 수: 48개 Transformer 블록
핵심 트레이드오프: 메모리에는 30B 전체가 올라가야 하지만(모든 전문가의 가중치가 필요), 실제 연산량은 3B Dense 모델 수준이다. 즉 FP16 기준 약 60 GB 메모리가 필요하지만, 추론 속도(tok/s)는 Qwen3-4B에 가깝거나 오히려 더 빠를 수 있다.
이 비대칭이 온프레미스에서 매력적인 이유: Mac Studio M2/M4 Ultra처럼 메모리는 넉넉하지만(192 GB 통합 메모리) GPU 연산력은 제한된 환경에서, 30B 품질을 3B 수준의 지연으로 얻을 수 있다. 메모리 대역폭이 병목인 단일 요청 시나리오에서 특히 유리하다.
Qwen3-235B-A22B — 최대 규모 MoE
- 전체 파라미터: 약 2,350억 (235B)
- 토큰당 활성 파라미터: 약 220억 (22B)
- 메모리 요구량: FP16 기준 약 470 GB, FP8 기준 약 235 GB, INT4(GGUF Q4) 기준 약 130 GB
온프레미스에서 235B-A22B를 돌리려면 최소 H100 80 GB × 3~4장(FP8 텐서 병렬), 또는 Mac Studio M2 Ultra 192 GB에 GGUF Q4_K_M으로 겨우 올릴 수 있는 수준이다. “올릴 수 있다”와 “실용적인 속도로 서빙할 수 있다”는 다르다는 점을 강조한다. 현실적으로 14일 시리즈에서 메인 모델로 쓰기엔 하드웨어 요구가 과하므로, 235B-A22B는 특수 용도(오프라인 배치 추론, 벤치마크 비교)로 위치시키고, 실전 메인은 30B-A3B 또는 32B를 기준으로 삼는다.
MoE의 구조적 특성 — 서빙 관점에서 꼭 알아야 할 것
MoE 모델은 Dense와 서빙 특성이 다르다. 온프레미스 운영자가 반드시 인지해야 할 차이점 세 가지:
① 메모리 vs 연산의 비대칭
앞서 설명한 대로, 메모리에는 전체 파라미터가 올라가지만 연산은 활성 파라미터만 사용한다. 이 비대칭 때문에 “모델이 메모리에 들어가니까 빠르겠지?”라는 기대와 실제 성능 사이에 괴리가 생길 수 있다. 특히 배치(batch) 추론에서는 서로 다른 토큰이 서로 다른 전문가를 활성화하므로, 배치 내 모든 전문가가 “한 번씩은” 사용될 가능성이 높다. 배치 크기가 커질수록 MoE의 연산 효율 이점이 줄어든다.
② 전문가 로드 밸런싱
학습 과정에서 특정 전문가에 토큰이 몰리는 현상(expert collapse)을 방지하기 위해 로드 밸런싱 로스(auxiliary loss)가 적용된다. 추론 시에는 이 문제가 직접 드러나지 않지만, 특정 도메인의 입력(예: 코드만, 또는 한국어만)이 편향되면 일부 전문가에 부하가 집중될 수 있다. vLLM의 MoE 커널은 이를 고려한 최적화가 내장되어 있지만, 커스텀 서빙 스택에서는 주의가 필요하다.
③ 양자화 시 전문가별 정밀도 차이
MoE 모델을 양자화하면 각 전문가의 가중치 분포가 다르기 때문에 전문가마다 양자화 오차가 다를 수 있다. AWQ(Activation-aware Weight Quantization)처럼 활성화 기반 양자화가 특히 유리한 이유다. 단순 RTN(Round-To-Nearest) 양자화는 MoE에서 품질 저하가 더 크게 나타날 수 있다.
Qwen3 사이즈 스펙트럼 — 용도 매핑
Qwen3 패밀리는 0.6B부터 235B까지 8개 사이즈를 제공한다. “큰 모델이 무조건 좋다”가 아니라, 온프레미스 시스템의 각 역할(role)에 적합한 사이즈를 배치하는 것이 핵심이다. 아래 표는 14일 시리즈에서 사용할 용도 매핑이다.
| 모델 | 아키텍처 | FP16 메모리 | INT4 메모리 | 권장 용도 | 배치 노드 |
|---|---|---|---|---|---|
| Qwen3-0.6B | Dense | ~1.2 GB | ~0.5 GB | 임베딩 전처리, 토큰 분류 | CPU / 엣지 |
| Qwen3-1.7B | Dense | ~3.4 GB | ~1.2 GB | 의도 분류, 키워드 추출 | CPU / 엣지 |
| Qwen3-4B | Dense | ~8 GB | ~2.5 GB | 경량 대화, 요약 보조 | 단일 GPU / Mac |
| Qwen3-8B | Dense | ~16 GB | ~5 GB | 라우팅·분류·가드레일 | 단일 GPU / Mac |
| Qwen3-14B | Dense | ~28 GB | ~8.5 GB | 범용 대화·번역·요약 | 단일 GPU / Mac |
| Qwen3-30B-A3B | MoE | ~60 GB | ~17 GB | 메인 생성기 (MoE 트랙) | Mac Studio / 단일 GPU |
| Qwen3-32B | Dense | ~64 GB | ~19 GB | 메인 생성기 (Dense 트랙) | 단일~듀얼 GPU |
| Qwen3-235B-A22B | MoE | ~470 GB | ~130 GB | 오프라인 배치·벤치마크 전용 | 멀티 GPU 클러스터 |
메모리 수치는 모델 가중치만의 이론값이다. 실제 서빙 시에는 KV 캐시, 활성화 텐서, 프레임워크 오버헤드가 추가되므로 1.2~1.5배를 곱해야 실전 요구량에 가깝다.
멀티 모델 배치의 논리
온프레미스 AI Assistant를 설계할 때 단일 거대 모델로 모든 요청을 처리하는 것은 비효율적이다. 대신 역할별로 모델을 분리하는 멀티 모델 아키텍처를 권장한다:
- 라우터(Router): Qwen3-8B — 들어온 요청의 복잡도를 판단해 경량 모델로 처리할지 대형 모델로 보낼지 결정. 지연 10ms 이내 목표.
- 범용 생성기(General Generator): Qwen3-14B — 단순 대화, FAQ 응답, 번역 등. 전체 트래픽의 60~70%를 처리.
- 심화 생성기(Deep Generator): Qwen3-30B-A3B 또는 32B — 복잡한 추론, 코드 생성, 장문 분석. 전체 트래픽의 20~30%.
- 비전 전문가(Vision Expert): Qwen3-VL — 이미지·문서·차트 이해가 필요한 요청만 라우팅.
이 구조는 6일차(하이브리드 게이트웨이)에서 LiteLLM 기반으로 구현할 예정이다. 오늘은 각 역할에 어떤 변형이 적합한지의 선택 논리에 집중한다.
Instruct 모드와 Thinking 모드 — 하나의 모델, 두 가지 추론 전략
Qwen3의 독특한 설계 중 하나가 Thinking 모드의 통합이다. 다른 모델 패밀리(예: DeepSeek-R1)가 별도의 “Reasoning 모델”을 따로 학습시키는 것과 달리, Qwen3 Instruct 모델은 단일 체크포인트 안에서 Thinking과 Non-Thinking을 토글할 수 있다.
Non-Thinking 모드 (기본)
일반적인 Instruct 모델과 동일하게 동작한다. 사용자 프롬프트를 받아 바로 응답을 생성한다. 지연이 짧고 토큰 소모가 적다.
Thinking 모드
모델이 응답을 생성하기 전에 내부 추론 토큰(reasoning tokens)을 먼저 생성한다. 이 추론 과정은 <think>...</think> 태그로 감싸져 출력되며, 최종 응답은 그 뒤에 이어진다.
Thinking 모드의 동작 흐름:
- 사용자 입력 수신
<think>태그 시작 — 모델이 문제를 분해하고, 가설을 세우고, 검증하는 과정을 텍스트로 생성</think>태그 종료- 최종 응답 생성 — 추론 과정을 바탕으로 정제된 답변 출력
Thinking 모드 활성화 방법
Qwen3 Instruct 모델에서 Thinking 모드를 제어하는 방법은 두 가지다:
방법 1: 생성 파라미터로 제어
vLLM이나 mlx-lm의 OpenAI 호환 API에서 extra_body 또는 서빙 프레임워크별 파라미터로 enable_thinking=true를 전달한다. 이 방법이 프로그래밍 방식의 제어에 가장 적합하다.
방법 2: 시스템 프롬프트로 유도
시스템 프롬프트에 /think 또는 /no_think를 포함해 모델의 동작을 유도할 수 있다. 서빙 프레임워크가 enable_thinking 파라미터를 지원하지 않는 경우의 대안이다.
Thinking 모드의 비용과 수익
| 항목 | Non-Thinking | Thinking | 비고 |
|---|---|---|---|
| 출력 토큰 수 | 1x | 2~10x | 추론 토큰이 추가됨 |
| 응답 지연(TTFT → 완료) | 기준 | 2~8x 증가 | 추론 토큰 생성 시간 |
| 복잡한 수학 문제 정확도 | 기준 | 10~30%p 향상 | 벤치마크 의존 |
| 코드 생성 품질 | 기준 | 유의미한 향상 | 디버깅·최적화에서 차이 큼 |
| 단순 대화·인사 | 기준 | 거의 동일 | 불필요한 비용 발생 |
정확도 향상 수치는 Qwen3 기술 보고서 및 벤치마크(AIME 2024, LiveCodeBench 등)를 기반으로 한 범위다. 실제 성능은 태스크, 프롬프트, 양자화 수준에 따라 달라진다.
Thinking 모드 운영 전략
온프레미스 AI Assistant에서 Thinking 모드를 효과적으로 활용하는 전략은 라우터 기반 동적 전환이다:
- 라우터(Qwen3-8B)가 요청의 복잡도를 분류한다 (예: simple / complex / reasoning_required).
- simple → 메인 모델 Non-Thinking 모드로 전달. 지연 최소화.
- complex → 메인 모델 Non-Thinking 모드 + 더 긴 컨텍스트(RAG 결과 포함).
- reasoning_required → 메인 모델 Thinking 모드. 추론 토큰을 스트리밍할지 숨길지는 UX 설계에 따라 결정.
이 전략의 핵심은 모델 자체를 바꾸지 않고 같은 모델의 모드만 전환한다는 점이다. 하나의 서빙 인스턴스(vLLM 또는 mlx-lm)로 두 모드를 모두 처리할 수 있어 리소스 효율이 높다. 8일차(프롬프트 설계)에서 이 전략을 구체적으로 구현한다.
Qwen3-VL — 같은 패밀리의 비전-언어 모델
Qwen3-VL은 Qwen3의 텍스트 LLM 백본에 비전 인코더(Vision Transformer)를 결합한 멀티모달 모델이다. 별도의 모델을 따로 호스팅하는 것이 아니라, Qwen3과 동일한 텍스트 처리 능력에 이미지·비디오·문서 이해 능력이 추가된 확장 변형이다.
아키텍처 구조
Qwen3-VL의 전체 구조는 세 블록으로 나뉜다:
① 비전 인코더 (ViT)
입력 이미지를 패치(patch)로 분할하고, 각 패치를 Vision Transformer가 임베딩 벡터로 변환한다. Qwen3-VL은 동적 해상도(dynamic resolution)를 지원해, 입력 이미지의 원본 종횡비를 유지하면서 해상도에 따라 패치 수를 조절한다. 고해상도 문서 스캔이나 차트도 리사이징 없이 처리할 수 있다는 의미다.
② 비전-언어 프로젝터
ViT의 출력 벡터를 LLM의 임베딩 공간으로 투영(projection)하는 어댑터 레이어. 시각 정보가 텍스트 토큰과 같은 차원의 벡터가 되어, LLM의 어텐션 메커니즘이 텍스트와 이미지를 통합적으로 처리할 수 있다.
③ 텍스트 LLM 백본
Qwen3과 동일한 디코더 Transformer. 비전 토큰과 텍스트 토큰이 하나의 시퀀스로 결합되어 처리된다. Qwen3-VL은 MRoPE(Multimodal Rotary Position Embedding)를 사용해, 텍스트의 1차원 위치와 이미지의 2차원 공간 위치를 단일 위치 인코딩 체계로 통합한다.
Qwen3-VL 변형 비교
| 모델 | 아키텍처 | FP16 메모리 | 강점 | 제약 |
|---|---|---|---|---|
| Qwen3-VL-8B | Dense | ~16 GB | 가벼움, 단일 GPU 서빙 가능 | 복잡한 문서 레이아웃에서 정확도 제한 |
| Qwen3-VL-30B-A3B | MoE | ~60 GB | 고해상도 문서·차트·UI 이해, Visual Agent 수준 | MoE 전체 파라미터의 메모리 필요 |
Qwen3-VL의 핵심 능력
- 문서 이해(Document Understanding): 스캔된 문서, PDF 렌더 이미지, 복잡한 표(table)에서 정보를 추출. OCR 없이 이미지를 직접 “읽는다.”
- 차트·그래프 분석: 막대 그래프, 라인 차트, 파이 차트 등의 시각 자료를 해석하고, 수치를 기반으로 질의에 응답.
- UI 이해(GUI Grounding): 스크린샷에서 UI 요소(버튼, 텍스트 필드, 메뉴)의 위치를 인식하고 클릭 좌표를 반환. Visual Agent의 기반 능력.
- Visual Coding: 와이어프레임이나 디자인 목업(mockup) 이미지를 보고 HTML/CSS 코드를 생성.
- 비디오 이해: 비디오의 프레임을 시계열로 처리해 내용을 요약하거나 특정 시점의 정보를 추출.
7일차에서 Qwen3-VL의 서빙과 실전 파이프라인을 깊이 다루지만, 오늘 기억할 핵심은 VL 모델도 같은 Qwen3 패밀리이므로 동일한 양자화·서빙 스택을 공유한다는 점이다. vLLM은 Qwen3-VL을 네이티브 지원하고, mlx-lm도 mlx-vlm 패키지를 통해 Apple Silicon에서 서빙할 수 있다.
양자화 포맷 비교 — FP8·AWQ·GGUF·MLX
온프레미스에서 LLM을 서빙할 때 양자화(quantization)는 선택이 아닌 필수다. Qwen3-32B를 FP16으로 서빙하려면 64 GB 이상의 메모리가 필요하지만, INT4 양자화를 적용하면 19 GB 수준으로 줄어든다. 문제는 양자화 포맷이 여러 가지이고, 각각 지원 플랫폼과 트레이드오프가 다르다는 것이다.
FP8 (8-bit Floating Point)
정밀도: 8비트 부동소수점 (E4M3 또는 E5M2 형식)
메모리 절감: FP16 대비 약 50% (파라미터당 1바이트)
품질 영향: FP16 대비 거의 무손실 (1% 미만의 벤치마크 차이가 일반적)
지원 플랫폼: NVIDIA H100, Ada Lovelace(RTX 4090 등), Hopper 아키텍처 이상. vLLM 네이티브 지원.
장점: 품질 손실 거의 없이 메모리를 절반으로. NVIDIA의 하드웨어 가속(FP8 Tensor Core)을 활용해 FP16보다 오히려 처리량(throughput)이 높을 수 있다.
단점: Ampere 이전 GPU(V100, RTX 3090)에서는 하드웨어 미지원. Apple Silicon 미지원. 양자화 자체가 FP16보다 복잡한 캘리브레이션이 필요할 수 있다.
AWQ (Activation-aware Weight Quantization)
정밀도: 4비트 정수 (INT4)
메모리 절감: FP16 대비 약 75% (파라미터당 약 0.5바이트 + 스케일 오버헤드)
품질 영향: 잘 캘리브레이션된 AWQ는 INT4 중 최고 수준의 품질 유지. 특히 활성화 값이 큰(salient) 채널을 보호하는 전략이 MoE 모델에서도 효과적.
지원 플랫폼: NVIDIA GPU (Ampere 이상 권장). vLLM에서 AutoAWQ를 통해 지원. CUDA 커널 최적화.
장점: INT4 수준의 공격적 메모리 절감과 상대적으로 높은 품질 유지의 균형. vLLM 생태계에서 가장 성숙한 INT4 포맷.
단점: Apple Silicon에서는 직접 사용 불가 (CUDA 전용 커널). 양자화 시 캘리브레이션 데이터셋이 필요하고, 도메인에 따라 캘리브레이션 품질이 결과에 영향.
GGUF (GPT-Generated Unified Format)
정밀도: 다양 — Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0 등 세분화된 양자화 수준 제공
메모리 절감: Q4_K_M 기준 FP16 대비 약 70~75%
품질 영향: 양자화 수준에 따라 상이. Q4_K_M은 실용적 품질, Q6_K 이상은 거의 FP16에 근접.
지원 플랫폼: llama.cpp 기반 — 모든 플랫폼(Windows, macOS, Linux). CPU, NVIDIA GPU(CUDA), Apple Silicon(Metal), AMD GPU(ROCm) 모두 지원.
장점: 최고의 호환성. 단일 파일로 모델 배포 가능. CPU+GPU 하이브리드 추론(GPU에 일부 레이어, 나머지는 CPU)으로 VRAM 부족 환경에서도 구동 가능. Ollama가 GGUF를 기본 포맷으로 사용.
단점: llama.cpp의 추론 엔진이 vLLM 대비 배치 처리 효율이 낮다. 동시 요청이 많은 프로덕션 서빙에서는 처리량 병목. PagedAttention 같은 고급 메모리 관리가 제한적.
MLX 포맷
정밀도: 4비트(INT4) 또는 8비트(INT8) 양자화. mlx-community 허브에서 사전 양자화 모델 제공.
메모리 절감: INT4 기준 FP16 대비 약 70~75%
품질 영향: mlx-lm의 양자화는 group quantization을 적용해 INT4에서도 합리적 품질 유지.
지원 플랫폼: Apple Silicon 전용 (M1/M2/M3/M4 시리즈). MLX 프레임워크 기반.
장점: Apple Silicon의 통합 메모리(Unified Memory)와 Metal GPU를 최적 활용. mlx-lm이 OpenAI 호환 서버를 내장해 즉시 서빙 가능. 통합 메모리 특성상 CPU↔GPU 간 데이터 복사가 없어 대형 모델(30B+)에서 GGUF/llama.cpp 대비 유리.
단점: Apple Silicon 이외의 하드웨어에서 완전히 사용 불가. NVIDIA GPU 환경과 모델 파일을 공유할 수 없다. 커뮤니티·생태계 규모가 vLLM 대비 작다.
양자화 포맷 비교 종합표
| 항목 | FP8 | AWQ (INT4) | GGUF (Q4_K_M) | MLX (INT4) |
|---|---|---|---|---|
| 비트 수 | 8 | 4 | 4 (가변) | 4 |
| FP16 대비 메모리 | ~50% | ~25% | ~25~30% | ~25~30% |
| 품질 유지도 | ★★★★★ | ★★★★☆ | ★★★☆☆~★★★★☆ | ★★★☆☆~★★★★☆ |
| 추론 속도 이점 | FP16보다 빠를 수 있음 | 메모리 절감 → 배치↑ | 보통 | Apple Silicon 최적 |
| NVIDIA GPU | ✅ (Hopper/Ada+) | ✅ (Ampere+) | ✅ (CUDA backend) | ❌ |
| Apple Silicon | ❌ | ❌ | ✅ (Metal backend) | ✅ (네이티브) |
| CPU | ❌ | ❌ | ✅ | ❌ |
| 서빙 프레임워크 | vLLM | vLLM | llama.cpp, Ollama | mlx-lm |
| MoE 적합도 | 높음 | 높음 | 보통 | 보통 |
| 배치 처리 효율 | 높음 (vLLM) | 높음 (vLLM) | 낮음 | 보통 |
양자화 선택의 실전 원칙
위 표만으로는 결정이 어려울 수 있다. 실전에서 적용하는 원칙 세 가지:
원칙 1: 하드웨어가 포맷을 결정한다
Mac Studio라면 MLX 또는 GGUF. NVIDIA GPU라면 FP8(가능한 경우) 또는 AWQ. “최고의 양자화 포맷”은 없고, 내 하드웨어에서 최적인 포맷이 있을 뿐이다.
원칙 2: 먼저 FP8으로, 안 되면 INT4로
품질 유지가 중요한 메인 생성기에는 가능한 한 높은 정밀도를 쓴다. NVIDIA Hopper/Ada GPU가 있다면 FP8이 품질과 성능의 최적 교점이다. 메모리가 부족할 때만 INT4(AWQ)로 내린다.
원칙 3: 라우터·분류기에는 공격적 양자화를 적용한다
라우팅 모델(Qwen3-8B)이 수행하는 태스크는 복잡한 생성이 아니라 분류다. INT4 양자화의 품질 손실이 분류 정확도에 미치는 영향은 미미하다. 메모리를 아껴서 메인 생성기에 더 많은 리소스를 할당하는 것이 시스템 전체 성능에 유리하다.
Qwen3 변형 결정 트리 — “어떤 모델을 어디에 배치할 것인가”
지금까지 Dense vs MoE, 사이즈 스펙트럼, Thinking 모드, 양자화 포맷을 모두 살펴봤다. 이제 이 모든 축을 하나의 의사결정 플로우로 통합한다.
결정 트리의 핵심 질문 5단계
Q1. 이 모델의 역할(role)은 무엇인가?
- 라우터·분류 → Qwen3-8B (또는 4B). 작고 빨라야 한다.
- 범용 대화·요약 → Qwen3-14B. 품질과 비용의 균형.
- 심화 추론·코딩 → Qwen3-30B-A3B(MoE) 또는 Qwen3-32B(Dense). 메인 생성기.
- 비전·멀티모달 → Qwen3-VL-8B 또는 Qwen3-VL-30B-A3B.
- 오프라인 배치·벤치마크 → Qwen3-235B-A22B. 실시간 서빙 비권장.
Q2. 사용 가능한 하드웨어는?
- Mac Studio (M2/M4 Ultra, 통합 메모리 128~192 GB) → MLX 포맷 우선. 30B-A3B MoE가 특히 유리 (메모리 넉넉, 연산은 3B 수준).
- NVIDIA GPU 1장 (RTX 4090 24 GB / A6000 48 GB) → AWQ INT4 또는 FP8. 24 GB면 14B FP8 또는 32B AWQ.
- NVIDIA GPU 2장+ (A100 80 GB × 2 등) → 텐서 병렬. 32B FP8 또는 30B-A3B FP16.
- CPU 전용 / 혼합 → GGUF. 단, 프로덕션 서빙 속도 제한 인지.
Q3. 메모리 예산은 얼마인가?
모델 가중치 + KV 캐시 + 프레임워크 오버헤드를 합산한다. 경험적으로 모델 가중치의 1.3~1.5배를 실제 소요로 잡는다. 32K 컨텍스트 기준이며, 128K를 쓸 경우 KV 캐시가 추가로 커진다.
| 모델 | FP16 (실전) | FP8 (실전) | INT4 (실전) |
|---|---|---|---|
| Qwen3-8B | ~21 GB | ~11 GB | ~7 GB |
| Qwen3-14B | ~36 GB | ~18 GB | ~11 GB |
| Qwen3-30B-A3B | ~78 GB | ~39 GB | ~22 GB |
| Qwen3-32B | ~83 GB | ~42 GB | ~25 GB |
| Qwen3-235B-A22B | ~610 GB | ~305 GB | ~169 GB |
실전 = 가중치 × 1.3 (32K 컨텍스트, 단일 요청 기준 KV 캐시 + 프레임워크 오버헤드 포함 근사치). 동시 요청이 늘면 KV 캐시가 요청 수에 비례해 증가한다.
Q4. Thinking 모드가 필요한가?
- 항상 필요 → 해당 모델의 Thinking 모드를 기본 활성화. 지연 증가를 감수.
- 조건부 필요 → 라우터가 판단해 동적 전환. 가장 권장하는 패턴.
- 불필요 → Non-Thinking 고정. 라우터·분류기에 적합.
Q5. MoE vs Dense — 30B-A3B와 32B 사이에서
메인 생성기를 고를 때 가장 자주 마주하는 갈림길이다. 판단 기준:
| 기준 | Qwen3-30B-A3B (MoE) | Qwen3-32B (Dense) |
|---|---|---|
| 단일 요청 지연 | 낮음 (3B 활성) | 높음 (32B 전체 연산) |
| 배치 처리 효율 | MoE 오버헤드로 상대 이점 감소 | vLLM continuous batching에 최적 |
| 메모리 요구 | ~60 GB FP16 (30B 전체) | ~64 GB FP16 |
| Mac Studio 적합도 | ★★★★★ (메모리 넉넉, 연산 경량) | ★★★☆☆ (연산 부담 큼) |
| NVIDIA 듀얼 GPU 적합도 | ★★★☆☆ (MoE 통신 오버헤드) | ★★★★★ (TP 효율 높음) |
| 품질 (벤치마크 기준) | 14B Dense급~그 이상 | 30B-A3B보다 일반적으로 우위 |
결론적 권장:
- Mac Studio 메인 → Qwen3-30B-A3B MLX INT4. 통합 메모리의 대역폭을 활성 3B 파라미터에 집중해 빠른 단일 요청 응답.
- NVIDIA GPU 메인 → Qwen3-32B FP8 (또는 AWQ). vLLM의 continuous batching으로 높은 처리량 확보.
- 두 노드 병행 → Mac Studio에 30B-A3B, CUDA에 32B를 각각 올리고 게이트웨이가 부하와 태스크에 따라 라우팅. (6일차 주제)
시나리오별 변형 추천
결정 트리를 세 가지 대표 시나리오에 적용해 보자.
시나리오 A: Mac Studio M2 Ultra 192 GB 단일 노드
| 역할 | 모델 | 포맷 | 예상 메모리 | 비고 |
|---|---|---|---|---|
| 라우터 | Qwen3-8B | MLX INT4 | ~7 GB | 의도 분류, 복잡도 판단 |
| 메인 생성기 | Qwen3-30B-A3B | MLX INT4 | ~22 GB | MoE, 단일 요청 고속 |
| 비전 | Qwen3-VL-8B | MLX INT4 | ~7 GB | 이미지·문서 이해 |
| 합계 | ~36 GB | 192 GB 중 19% 사용. 충분한 여유. |
192 GB 통합 메모리 중 36 GB만 사용하므로, 나머지를 KV 캐시와 동시 요청에 활용할 수 있다. 128K 컨텍스트를 적극 활용하거나, 모든 모델을 동시에 올려놓고 요청에 따라 즉시 응답하는 구성이 가능하다.
시나리오 B: NVIDIA RTX 4090 24 GB × 1
| 역할 | 모델 | 포맷 | 예상 메모리 | 비고 |
|---|---|---|---|---|
| 라우터 + 범용 | Qwen3-14B | AWQ INT4 | ~11 GB | 라우팅과 범용 대화를 겸함 |
| 합계 | ~11 GB | KV 캐시용 ~13 GB 여유 |
24 GB 단일 GPU에서는 모델을 여러 개 올리기 어렵다. Qwen3-14B AWQ를 라우터 겸 범용 생성기로 쓰고, 복잡한 추론이 필요할 때만 Thinking 모드를 활성화하는 전략이 현실적이다. 32B를 올리려면 AWQ로도 25 GB로 VRAM 초과이므로, 32B는 이 환경에서 실전 서빙에 적합하지 않다.
시나리오 C: NVIDIA A100 80 GB × 2 (NVLink)
| 역할 | 모델 | 포맷 | 예상 메모리 | 비고 |
|---|---|---|---|---|
| 라우터 | Qwen3-8B | FP8 | ~11 GB (GPU 0 일부) | 별도 vLLM 인스턴스 |
| 메인 생성기 | Qwen3-32B | FP8 | ~42 GB (TP=2) | 두 GPU에 텐서 병렬 |
| 비전 | Qwen3-VL-8B | FP16 | ~21 GB (GPU 0 나머지) | FP16으로 최고 품질 |
| 합계 | ~74 GB / 160 GB | 배치 처리와 128K KV 캐시에 충분한 여유 |
A100 듀얼 환경에서는 Qwen3-32B를 FP8 텐서 병렬로 올리면서 동시에 8B 라우터와 VL 모델까지 수용할 수 있다. vLLM의 continuous batching(연속 배치)과 PagedAttention을 최대한 활용해 높은 동시성을 확보한다. 이 구성의 상세 구현은 5일차(vLLM 서빙)에서 다룬다.
핸즈온 — 모델 아키텍처 확인과 메모리 계산 스크립트
오늘의 핸즈온은 두 가지다. 첫째, Hugging Face에서 모델의 config.json을 확인해 아키텍처 세부사항을 직접 읽는 방법. 둘째, 양자화 수준별 메모리 요구량을 계산하는 Python 스크립트.
1. config.json에서 아키텍처 읽기
Qwen3 모델의 config.json은 오늘 설명한 모든 구조적 특성을 숫자로 확인할 수 있는 1차 소스다. Hugging Face CLI로 가져오거나, 모델 페이지에서 직접 열어 볼 수 있다.
# huggingface-cli로 config.json만 다운로드 (모델 전체를 받을 필요 없음)
pip install huggingface_hub
huggingface-cli download Qwen/Qwen3-30B-A3B config.json --local-dir ./qwen3-config
cat ./qwen3-config/config.json | python -m json.toolQwen3-30B-A3B의 config.json에서 주요 필드를 해석하면:
{
"architectures": ["Qwen3MoeForCausalLM"],
"hidden_size": 2048,
"intermediate_size": 768,
"num_attention_heads": 32,
"num_key_value_heads": 4,
"num_hidden_layers": 48,
"num_experts": 128,
"num_experts_per_tok": 8,
"num_shared_experts": 1,
"vocab_size": 151936,
"max_position_embeddings": 40960,
"rope_scaling": {
"type": "yarn",
"factor": 4.0,
"original_max_position_embeddings": 40960
},
"head_dim": 64,
"rms_norm_eps": 1e-06
}이 JSON에서 오늘 배운 개념이 직접 확인된다:
"architectures": ["Qwen3MoeForCausalLM"]— MoE 아키텍처임을 명시."num_attention_heads": 32, "num_key_value_heads": 4— GQA 8:1 비율."num_experts": 128, "num_experts_per_tok": 8— 128개 전문가 중 토큰당 8개 활성화 (fine-grained expert)."num_shared_experts": 1— 항상 활성화되는 공유 전문가 1개."rope_scaling"— YaRN 기반 RoPE 스케일링."num_hidden_layers": 48— 48개 Transformer 블록.
Dense 모델(예: Qwen3-32B)의 config는 "architectures": ["Qwen3ForCausalLM"]이며, num_experts 관련 필드가 없다.
2. 메모리 요구량 계산 스크립트
"""Qwen3 변형별 메모리 요구량 계산기.
사용법:
python qwen3_memory_calc.py
각 모델의 가중치 메모리 + 32K 컨텍스트 KV 캐시 예상치를 출력한다.
"""
from dataclasses import dataclass
@dataclass(frozen=True)
class ModelSpec:
name: str
params_b: float # 전체 파라미터 (십억)
active_b: float # 활성 파라미터 (십억, Dense면 전체와 동일)
is_moe: bool
num_layers: int
hidden_size: int
num_kv_heads: int
head_dim: int
# Qwen3 모델 스펙 (config.json 기반 근사값)
MODELS: list[ModelSpec] = [
ModelSpec("Qwen3-0.6B", 0.6, 0.6, False, 28, 1024, 2, 64),
ModelSpec("Qwen3-1.7B", 1.7, 1.7, False, 28, 1536, 4, 64),
ModelSpec("Qwen3-4B", 4.0, 4.0, False, 36, 2560, 4, 128),
ModelSpec("Qwen3-8B", 8.0, 8.0, False, 36, 4096, 8, 128),
ModelSpec("Qwen3-14B", 14.0, 14.0, False, 40, 5120, 8, 128),
ModelSpec("Qwen3-30B-A3B", 30.0, 3.0, True, 48, 2048, 4, 64),
ModelSpec("Qwen3-32B", 32.0, 32.0, False, 64, 5120, 8, 128),
ModelSpec("Qwen3-235B-A22B", 235.0, 22.0, True, 94, 4096, 8, 128),
]
# 양자화별 파라미터당 바이트 수
QUANT_BYTES: dict[str, float] = {
"FP16": 2.0,
"FP8": 1.0,
"INT4 (AWQ/MLX/GGUF Q4_K_M)": 0.55, # 4bit + 스케일/오프셋 오버헤드
}
def calc_kv_cache_gb(
spec: ModelSpec,
seq_len: int = 32768,
batch_size: int = 1,
dtype_bytes: float = 2.0, # FP16 KV 캐시 기본
) -> float:
"""KV 캐시 메모리를 GB로 계산한다."""
# KV cache per layer = 2 (K, V) × batch × seq_len × kv_heads × head_dim × dtype
kv_per_layer = 2 * batch_size * seq_len * spec.num_kv_heads * spec.head_dim * dtype_bytes
total_bytes = kv_per_layer * spec.num_layers
return total_bytes / (1024 ** 3)
def main() -> None:
print(f"{'모델':<22} {'아키텍처':<8}", end="")
for q_name in QUANT_BYTES:
print(f" {q_name:>12}", end="")
print(f" {'KV캐시(32K)':>12} {'비고'}")
print("-" * 120)
for spec in MODELS:
arch = "MoE" if spec.is_moe else "Dense"
kv_gb = calc_kv_cache_gb(spec)
print(f"{spec.name:<22} {arch:<8}", end="")
for q_name, q_bytes in QUANT_BYTES.items():
weight_gb = spec.params_b * q_bytes # 파라미터 × 바이트/파라미터 ≈ GB
total_gb = weight_gb + kv_gb
print(f" {total_gb:>10.1f}GB", end="")
note = ""
if spec.is_moe:
note = f"활성 {spec.active_b}B, 연산은 경량"
print(f" {kv_gb:>10.2f}GB {note}")
print()
print("※ 위 수치는 가중치 + KV캐시(32K, 배치1, FP16)의 합산 근사값.")
print("※ 실전에서는 프레임워크 오버헤드(10~30%)를 추가로 반영해야 합니다.")
if __name__ == "__main__":
main()이 스크립트를 실행하면 각 Qwen3 변형의 양자화별 메모리 요구량을 한눈에 비교할 수 있다. 하드웨어의 가용 메모리와 대조해 어떤 변형이 올라가는지 빠르게 판단하는 데 활용한다.
모델 아키텍처 FP16 FP8 INT4 (...) KV캐시(32K) 비고
------------------------------------------------------------------------------------------------------------------------
Qwen3-0.6B Dense 1.3GB 0.7GB 0.4GB 0.11GB
Qwen3-1.7B Dense 3.5GB 1.8GB 1.1GB 0.14GB
Qwen3-4B Dense 8.3GB 4.3GB 2.5GB 0.28GB
Qwen3-8B Dense 16.3GB 8.3GB 4.7GB 0.28GB
Qwen3-14B Dense 28.3GB 14.3GB 8.0GB 0.31GB
Qwen3-30B-A3B MoE 60.2GB 30.2GB 16.7GB 0.19GB 활성 3.0B, 연산은 경량
Qwen3-32B Dense 64.6GB 32.6GB 18.2GB 0.63GB
Qwen3-235B-A22B MoE 470.6GB 235.6GB 129.8GB 0.59GB 활성 22.0B, 연산은 경량특히 주목할 점: Qwen3-30B-A3B의 KV 캐시(0.19 GB)가 Qwen3-32B(0.63 GB)보다 훨씬 작다. MoE 모델은 hidden_size가 작고(2048 vs 5120) KV 헤드도 적어(4 vs 8), 긴 컨텍스트에서 메모리 효율이 더 좋다. 이 차이는 동시 요청 수가 늘어날수록 벌어진다.
운영 함정 (Pitfall) — “MoE 모델은 메모리만 보고 고르면 안 된다”
증상: Qwen3-30B-A3B를 Mac Studio에 MLX INT4(약 17 GB)로 올렸다. 메모리 여유 충분. 단일 요청 응답 속도도 좋다. 그런데 동시 요청 3~4개가 겹치자 갑자기 응답 지연이 5배로 뛰었다.
원인: MoE 모델의 “활성 파라미터 3B”는 단일 토큰 기준이다. 배치 추론에서 여러 요청의 토큰이 동시에 처리되면, 각 토큰이 서로 다른 전문가를 활성화한다. 128개 전문가 중 토큰당 8개를 쓰는 Qwen3-30B-A3B에서, 배치 내 토큰 수가 16개만 넘어도 128개 전문가 대부분이 “한 번씩은” 활성화될 확률이 높다. 결과적으로 배치 추론에서는 30B 전체 파라미터가 연산에 참여하는 것과 비슷한 부하가 걸린다.
교훈: MoE의 “활성 파라미터 절감” 이점은 동시성이 낮은 단일/소수 요청 환경에서 최대로 발휘된다. Mac Studio 같은 단일 사용자 워크스테이션에서는 유리하지만, 동시 10+ 요청을 처리하는 서빙 환경에서는 Dense 32B와 MoE 30B-A3B의 실질 처리량 차이가 예상보다 작을 수 있다. 동시성이 높은 환경에서는 Dense 모델 + vLLM continuous batching이 더 효율적이다.
대응: 멀티 모델 아키텍처에서 MoE(Mac Studio)는 “지연 민감 단일 요청” 전용, Dense(NVIDIA)는 “처리량 지향 배치” 전용으로 역할을 분리한다. 이 분리가 6일차(하이브리드 게이트웨이)의 핵심 설계 원리가 된다.
내일 예고
모델 변형을 골랐으면 다음 질문은 “이걸 어떤 하드웨어에 올릴 것인가“다. 3일차에서는 Mac Studio(통합 메모리·MLX·Metal) vs 듀얼 NVIDIA GPU(VRAM·CUDA·NVLink) 비교 매트릭스를 펼치고, 오늘 매핑한 Qwen3 변형을 실제 노드에 배치하는 구체적인 하드웨어 설계를 다룬다. 메모리 대역폭 계산, 전력·발열 현실, 그리고 두 트랙(4회 MLX · 5회 vLLM)의 분기점이 결정된다.
◀ 이전 1화 (다음 차수는 아직 게시되지 않았습니다)
참고 자료
- Qwen3 공식 블로그 — Qwen Team — Qwen3 모델 패밀리의 아키텍처·벤치마크·사용법을 다룬 공식 발표 문서
- Mixture of Experts — Wikipedia — MoE 아키텍처의 개념·역사·동작 원리를 설명하는 백과사전 문서
[…] 온프레미스 AI Assistant 아키텍처 — Qwen3·Qwen3-VL 14일 설계 (총 14화 중 3화)◀ 이전 2화 (다음 차수는 아직 게시되지 […]