QWEN 모델 분석

기준 시점 2026년 8월 10일

Qwen을 쓰기 시작하려고 마음먹으면 곧 아래 벽에 부딪힌다

• Qwen3, Qwen3.5, Qwen3.6, Qwen3.8 반년사이에 나왔는데 뭐가 표준이지
• 27B dense, 35B-A3B가 같은 세대에 있는데 무엇이 다르고 언제 어느쪽을 써야하지
• Gated DeltaNet, 얼리퓨전, MTP 같은 말이 있는데 뭐지 이게
• 공식 벤치마크에서 클로드 이겼다는데 그 숫자를 어디까지 믿어야하지
• 어떤 코딩 하네스에 물려야 모델이 제 성능을 낼까

이 것들에 답할 수 있는것을 목표로 이해해보자.

Qwen 가문 #

정체성 - 폭으로 승부하는 가문 #

Qwen은 알리바바 클라우드가 만든 모델 가문으로 중국명 통이췐원이며 영어권에서는 Qwen이다.

다른 가문과 구분되지 않는 지점은 라인업의 폭이다. DeepSeek는 플래그십 하나에 집중하고 Moonshoot은 스케일 상한을 밀어 올리는 데 집중한다. Qwen은 이와 다르게 같은 세대에서 0.8B~2.4T 까지, 전 구간을 채운다.

Qwen3.5 세대의 사이즈 스펙트럼 (2026년 2~3월 출시)

0.8B  2B  4B  9B  27B    35B-A3B   122B-A10B      397B-A17B
 │    │   │   │    │         │          │              │
휴대폰 ────────── 소비자 GPU ──── 워크스테이션 ──── 데이터센터

이 폭은 전략적인 선택이다 어떤하드웨어를 가진 조직이든 Qwen안에서 답을 ㅊ ㅏㅈ게 만들고.

그 결과 파인튜닝과 파생모델과 커뮤니티 도구가 Qwen쪽으로 많이 쏠려 1위를 차지중이다.

Open-Closed #

오픈 트랙 (Apache 2.0, 가중치 공개)
  Qwen3 → Qwen3-Next → Qwen3.5 → Qwen3.6 → (Qwen3.8-27B 예정)

클로즈드 트랙 (API 전용)
  Qwen3-Max → Qwen3.5-Plus/Flash → Qwen3.7-Max → Qwen3.8-Max

최상위 성능 Max 계열은 api 전용이었고, 오프란인은 한 세대 아래에서 따로 굴러간다.

다만 2026.8에 Qwen3.5-Max를 공개하면서 Max 등급 모델의 가중치를 처음으로 열겠다고 약속했고 함께 Qwen3.8-27B도 오픈으로 내겠다고 해서 저장소가 올라올것인데 라이선스와 모델 카드가 나오기 전까지는 로컬에서 쓸수없긴 했다.

반년사이에 세대가 세 번 바뀌었다.

이 속도가 Qwen을 다루는 실무에서 가장 성가신 부분이고 10장에서 대응 방법을 다룬다

라이선스 #

오픈 라인은 Apache 2.0이다. 딥싴 GLM은 MIT이라 제약이 사실상 없고, Kimi는 Modified MIT라 MAU 1억 또는 월매출 2천만 달러 초과시 표기 의무가 있다.

Apache 2.0은 특허 조항이 명시되어 있어 기업 법무 검토를 통과하기 가장 쉬운축에 속해서 파생 모델을 만들어 재배포할때도 원라이선스 고지만 하면 된다

라인업 #

80B-A38는 전체 800억개의 매개변수 중 토큰 처리시 단 30억개 (3B, Active 3 Billion)만 활성화하는 MoE(혼합 전문가 구조)를 뜻한다.

오픈웨이트로 지금 쓸수있는 최신은 Qwen3.6이다. 지금 기준으로.

목적별 계열 #

Qwen은 범용 모델 외에 목적별 계열을 따로 낸다.

이 구조를 모르면 범용 모델로 임베딩을 뽑는 것 같은 비효율을 하게 된다.

RAG를 만든다면 범용 모델 하나가 아니라 세 개가 필요하다.

임베딩 모델을 후보로 뽑고, 리랭커로 정렬하고, 범용 모델로 답을 쓴다.

각 단계에 맞는 크기를 고르는 것이 요령이다.

크기별 하드웨어 스펙 #

Q4_K_M 양자화 기준 대략적인 메모리 소요를 보자.

실제 값은 컨텍스트 길이에 따라 달라진다.

| 모델 | Q4_K_M 크기 | 최소 하드웨어 | 용도 |
|---|---|---|---|
| Qwen3.5-0.8B | 약 0.6 GB | 휴대폰, 라즈베리파이 | 온디바이스 분류, 라우팅 |
| Qwen3.5-2B | 약 1.5 GB | 8GB 노트북 | 간단한 요약, 임베디드 |
| Qwen3.5-4B | 약 2.8 GB | 8GB GPU | 대량 배치, 파인튜닝 기반 |
| Qwen3.5-9B | 약 6 GB | 12GB GPU | 일반 챗, 도구 호출 |
| **Qwen3.6-27B** | **약 16.8 GB** | **24GB GPU (RTX 3090/4090)** | **로컬 코딩. 이 구간의 표준** |
| Qwen3.6-35B-A3B | 약 20 GB | 32GB 통합 메모리 | 멀티모달 + 코딩, 속도 우선 |
| Qwen3.5-122B-A10B | 약 68 GB | 2×A100 80GB | 중형 서버 |
| Qwen3.5-397B-A17B | 약 220 GB | 8×H100급 | 데이터센터 |

Q4_K_M는 LLM모델을 GGUF 포맷으로 양자화할 떄 파일 이름 뒤에 붙는 표준 표기로 4비트 정밀도로 압축하되(Q4) K-quant 고급 알고리즘을 사용하고(K) 중간크기 품질 M(Medium)의 균형을 맞춘 모델이라는 뜻이다.

24GB GPU 한장이 Qwen 생태계 핵심 구간으로 Qwen3.6-27B가 이 자리를 겨냥해 설계되었고 커뮤니티 보고에 따르면 32GB RAM MackBook에서 초당 25토큰이 나온다고 한다

27B dnese와 35B-A3B 같은 세대에 두 선택지 #

Qwen 3.6은 비슷한 시기에 두 모델을 냈다. 성격이 다르고 어느쪽을 고를지 보면

위 기준으로 선택 기준을 정리하면

• 개인 개발자, 단일 GPU, 코딩 위주 -> 27B dense, batch 1에서 MoE 활성 파라미터 이점이 작고, 총 파라미터를 전부 메모리에 올려야하는 부담만 남는다. 배포도 단순화 되기에
• 동시 요청이 많은 서빙과 멀티모달 필요 -> 35B-A3B 배치가 커질수록 활성 3B의 계산 이점이 살아난다.
• 범용 에이전트 작업 -> VITA-Bench 35.6은 같은 세대 27B(41.8)나 Gemma4-31B(43.0)보다 낮고 코딩 외 에이전트 작업이 주라면 다른 후보를 함께 검토해야한다

이 선택에 얽힌 흥미로운 뒷이야기가 있다. Qwen 임원이 어떤 모델을 오픈소스로 내면 좋겠냐고 설문했을 때 27B dense가 압도적 1위였는데, 실제로 먼저 나온것은 35B-A3B였다. 27B는 엿새 뒤에 나왔다. 커뮤니티가 dense를 선호하는 이유는 MoE 오프로딩같은 추가 최적화 없이 그냥 돌아도 상관없기 때문에..

Architecture #

Qwen의 아키텍처를 알아보면서 어떤 문제를 어떻게 풀었는지 원리와 실제 배포에서 어떤 의미인지 알아보자

Qwen3 세대 - 정식 트랜스포머의 완성형 #

Qwen3 2025년 5월 새로운 아키텍처를 발명하지는 않았다.

대신 당시까지 검증된 것들을 정확히 조합했다.

Qwen3 블록 구성

입력 → RMSNorm → GQA (+ QK-Norm) → 잔차 더하기
     → RMSNorm → SwiGLU FFN 또는 MoE → 잔차 더하기 → 출력
       ↑ Pre-Norm 배치

• GQA: 어텐션 헤드들이 KV를 그룹 단위로 공유해 KV 캐시를 줄이는 기법
• SwiGLU: 게이팅이 붙은 활성화 함수로 같은 파라미터로 표현력이 좋다.
• RoPE: 벡터를 회전시켜 위치를 인코딩함, 상대 거리가 자연스럽게 표현됨
• RMSNorm + Pre-Norm: 값의 크기를 정규화 및 블록 앞에 배치해 깊은 망을 안정화한다.

Qwen2에서 3으로 넘어오면서 바뀐 두가지가 존재한다.

QKV 편향을 제거하고 QK-Norm을 넣었다 Q와 K에 정규화를 물리면서 내적인 어텐션 로짓이 폭주하지 않는다. 학습 중 로짓이 커지면 소프트맥스가 한 지점에 몰리면서 그래디언트가 사라지고 심하면 손실위 튀어 학습이 무너진다 QK-Norm은 이 사고를 원천에 막는다.

MoE에서 공유 전문가를 없앤다. Qwen2.5-MoE에서는 항상 켜지는 공유 전문가가 있었는데 Qwen3에서는 제거했다 대신 전역 배치 로드밸런싱 손실을 써서 전문가들이 더욱 뚜렷하게 전문화되도록 밀어붙였다.

다만 이결정은 또 되돌려졌다. Qwen3.5는 512개 전문가중 10개라우팅 + 1개 공유 구성으로 공유 전문가를 다시 넣었는데 전문가수가 512개까지 늘어나자 모든 토큰에 공통으로 필요한 지식을 전문가마다 넣는 중복 학습낭비가 심해졌기 때문으로 보인다. 아키텍처 결정이 규모에 따라 뒤집히는 사례다.

thinking / non-thinking 통합과 사고예산 #

Qwen3가 실제로 새로 제시한 방향성은 이쪽이다

기존 문제 #

추론 모델과 일반 모델은 따로 운영하면 두 배의 배포 비용이 들고, 사용자가 매번 어느쪽을 부를지 골라야한다. 그런데 1+1 같은것에 수천토큰을 추론모델로 돌려 생각하는것도 복잡한 증명에 일반모델이 즉답하는것도 낭비다

해법 #

하나의 모델에 두 모드를 넣고 요청 단위로 전환할 수 있게 한다. 여기에 사고 예산 thinking budget이란걸 붙여 이 문제에는 2000토큰까지만 생각하라 라고 상한을 지정할 수 있다.

# vLLM / SGLang OpenAI 호환 API에서
{
  "model": "Qwen/Qwen3.6-27B",
  "messages": [...],
  "chat_template_kwargs": {"enable_thinking": True},
  "max_tokens": 4096
}

Ollama에는 Modelfile로 고정할 수 있다.

FROM qwen3:8b
PARAMETER think false      # 항상 즉답 모드
# PARAMETER think true     # 항상 사고 모드

사고 토큰은 출력 토큰으로 과금되고 지연으로 늘린다.

분류나 추출처럼 추론이 필요없는 작업에서 사고를 끄면 비용과 지연이 즉시 줄어든다.

반대로 수학이나 코드 디버깅에서는 켜야 정확도가 오른다

작업별로 다르게 설정하는 것이 기본이다.

이 설계이후 업계 표준이 되어 GLM의 high/max effort, Qwen3.80Max low/high/xhigh가 같은 계열이다.

Gated DeltaNet 하이브리드 #

Qwen 아키텍처가 핵심 배팅한 영역이고 Qwen3-Next(2025.9)에서 도입되어

Qwen3.5 3.6 세대 전체에 적용된 구조다

풀려는 문제 #

컨텍스트를 길게 가져가게 되면 어텐션이 감당이 되지 않는다.

토큰이 N개면 Q-K쌍이 N²개라 계산이 제곱으로 늘고, KV 캐시가 길이에 비례해 쌓여 동시 사용자 수를 제한한다

DeepSeek는 KV를 압축해 MLA하거나 볼 토큰을 골라내는 DSA쪽으로 갔다.

Qwen은 다른 길을 택했다.

작동 원리 #

과거 전체를 다시 보는 대신에 고정 크기의 state에 과거를 요약해서 들고 다닌다. RNN과 같은 발상인데 현대적인 갱신 규칙을 쓴다.

비유 - 회의록을 전부 보관하고 전부 훑는게 기존 어텐션이라면 선형 어텐션은 한장짜리 현재 상황 요약본을 들고 보는거다. 회의가 열 시간 가도 요약본 한장이므로 책상이 좊아지진 않는다.

Gated DeltaNet - GDN은 이 요약본을 갱신하는 방식이 정교하다

• 델타 규칙: 기존 기억과 새 정보의 차이만으로 갱신, 오류 정정형 메모리
• 지수 게이팅: 무엇을 얼마나 잊을지 조절, 상태가 포화되는것을 막는다.
• 인과적 Conv1D: 바로 앞 몇 토큰의 지역 문맥을 포착
• Q/K L2 정규화: 소프트맥스 대신 사용, 값의 폭주 방지

델타 규칙이 핵심인데, 순진한 선형 어텐션은 새 정보를 그냥 더하기만해서 상태가 금세 뭉개진다.

델타 규칙은 ㅣ미 기억하고 있는 것과 얼마나 다른가를 계산해서 그 차이만 반영하므로 기억이 덮어써지지 않게 정정된다.

순수 선형 어텐션의 한계와 하이브리드 #

요약본만 들고다니면 정교한 지점 "300페이지 42번째줄 문구" 같은 요청은 꺼낼 수 없다.

즉 정밀 검색 능력이 떨어지기에 층을 섞는 방식으로 풀어나갔다.

Qwen3.5-397B-A17B의 실제 층 배치 (총 60층)

15 × [ GDN→MoE, GDN→MoE, GDN→MoE, Gated Attention→MoE ]
       └──────── 값싼 요약 3층 ────────┘ └ 정밀 검색 1층 ┘
              75%                              25%

3개의 층은 선형 어텐션으로 흐름을 따라가고, 4번째층에서 전체 어텐션으로 정확히 짚는 방식이다 비용의 대부분을 아끼면서 검색 능력은 남긴다.

Qwen3.5의 각 층 세부 구성이다.

Gated DeltaNet 층
  V 헤드 64개, QK 헤드 16개, 헤드 차원 128

Gated Attention 층
  Q 헤드 32개, KV 헤드 2개, 헤드 차원 256, RoPE 차원 64
  ↑ KV 헤드가 2개뿐 = 매우 공격적인 GQA. 이 층의 KV 캐시도 최소화

Gated Attention 층 조차 KV 헤드를 두개로 때려서 전체 어텐션 층 25%뿐인데 그 25%마저 최대한 줄인 설계인 것이다.

실제 효과 #

Qwen 공식 발표 기준

디코딩 처리량 (Qwen3-Max 대비)
  32K 컨텍스트  : 8.6배
  256K 컨텍스트 : 최대 19배
배포 VRAM      : 60% 감소

컨텍스트가 길어질 수록 처리량 배수가 커진다. 이는 선형 어텐션의 성질을 그대로 보여준다. 어텐션 길이에서 제곱으로, 선형 어텐션은 길이와 무관하게 작동하므로 갈수록 격차가 벌어진다.

훈련 쪽 효과도 크다. Qwen3-Next-80B-A3B는 **Qwen3-32B 훈련 컴퓨트의 9.3%**로 동등의 성능을 냈다. 10만 달러가 9,300달러가 되는 셈이다.

대가 #

정밀 검색에서는 이론적 약점이 남는다.

전체 어텐션 층 25%로 보완하지만 완전하지는 않기에 아주긴 문서에서 특정 세보를 정확히 인용해야하는 작업이라면 순수 어텐션 모델과 비교 측정할 가치가 있다.

서빙 스택 지원이 늦는다. 새 아키텍처는 새 커널과 새 KV 캐시 매니저를 요구하기에 vLLM은 Qwen3-Next 지원을 위해 Flash Linear Attention의 Triton 커널을 통합하고 선형 층과 전체 어텐션 층을 함께 관리하는 하이브리드 KV 캐시 매니저를 도입해야했다. 새 세대가 나왔을때 돌아간다와 최적화되었다 사이에 몇주에서 몇달간에 간격이 있다.

MoE 구성 #

Qwen3.5-397B-A17B MoE 내부를 보자

전문가 512개
토큰당 활성: 라우팅 10개 + 공유 1개
전문가 중간 차원: 1,024
-> 활성 파라미터 17B / 총 397B = 4.3%

전문가를 잘게 쪼개고 많이 켜는 방식이다.

큰 전문가는 8개중 2개를 켜는 초기 MoE랑 비교하면 조합의가짓수가 훨씬많아서 전문화가 잘된다.

이를 비유하면 병원에 만능의사 8명중 2명을 보내는것과 512명의 세부 전문의중 10명을 부르는 차이로 후자는 심장내과 + 영상의학 + 소아과 같은 정교한 조합을 만들 수 있다.

35B-A3B는 같은 발상을 극단으로 밀어 35B중 3B(8.6%)만 활성화한다.

이 비율 덕분에 RTX 3060급에서도 코딩 에이전트가 돌아간다.

MTP #

Qwen3.5부터 MTP로 훈련한다.

MTP는 다중 토큰 예측으로 다음 토큰 하나가 아니라 여러개를 동시에 예측하게 시킨다.

다음 두 세 단어까지 내다보라고 강제하면서 더 멀리 보는 표현을 배우게 되어 장거리 일관성에 좋아진다.

추론시에 이 MTP층을 그대로 투기적 디코딩의 드래프트 모델로 쓴다. 별도 모델을 만들 필요가 없다.

투기적 디코딩은 드래프트가 여러 토큰을 제안하고 본 모델이 한번의 포워드 패스로 검증한다.

가중치를 한 번 읽는 비용은 토큰 1개를 만들때나 6개를 검증할때나 거의 같기 때문에 남는 계산 자원으로 여러 토큰을 확정할 수 있다.

로컬 실행에서 실측된 효과를 보자. llama.cpp에서 MTP포함 GGUF를 사용하면 Qwen3.6-35B-A3B 기준 표준 146 tok/s 대비 27~29% 향상이 보고된다.

다만 VRAM TradeOff가 설정에 따라 편차가 좀 크다. 16GB 카드에서는 드래프트 깊이를 올릴수록 컨텍스트 여유가 줄어든다.

16GB VRAM에서의 실측 권장값

Qwen3.6-27B dense
  --spec-draft-n-max 2 + q8 KV  → 가장 빠름
  --spec-draft-n-max 1 + q5 KV  → 컨텍스트에 가장 여유

Qwen3.6-35B-A3B (MoE)
  --spec-draft-n-max 1 만 실용적
  q8 KV에서 평균 컨텍스트 15K에 불과
  3~4로 올리면 VRAM만 먹고 속도는 비례하지 않음

GGUF Georgi Gerganov Unified Format으로 LLM 가중치나 메타데이터를 하나의 단일 파일로 효율적으로 저장하고 실행하기 위해 만든 파일 형식(포맷)이다. 단일 파일 구조로 다양한 양자화 지원으로 VRAM 사용량을 줄이려고하고 낮은 하드웨어 사양에서도 구동하며 llama.cpp나 Ollama같은 로컬 AI 구동 프로그램에서 주로 사용한다.

MoE에서 MTP 이득이 더 크다 희소 라우팅 덕에 MTP 헤드 계산이 전체 포워드 패스 대비 상대적으로 저렴하기 때문이다.

얼리퓨전 멀티모달 #

Qwen3.5 부터 텍스트와 이미지 비디오를 처음부터 함께 학습한다.

기존 방식 레이트 퓨전은 텍스트 모델은 다 만들어놓고 비전 인코더로 어댑터를 붙이는 방식으로 만들긴 쉬웠지만 두 모달리티가 별도의 표현 공간에 살아남게되는 추론이 어색했다.

얼리퓨전은 사전학습 단계때부터 이미지 토큰과 텍스트 토큰을 같은 시퀀스에 섞어 넣는다. 모델이 처음부터 하나의 표현 공간에서 둘을 다룬다.

레이트 퓨전은 한국어를 다 배운뒤에 통역사를 붙여주는 거라면 얼리 퓨전은 어릴때부터 두 언어를 같이 배운것으로 후자가 두 언어를 섞은 사고를 자연스럽게 한다.

Qwen 공식 발표는 얼리퓨전 학습으로 텍스트 작업에서 이전 세대와 동등한 수준을 유지하면서 전용 비전 모델인 Qwen3-VL을 시각 이해에서 앞섰다고 밝혔다.

멀티모달을 넣으면 텍스트 성능이 떨어지는 일반적 트레이드오프를 피했다는 주장을 하고있다.

배포시 유의: 텍스트만 쓸거라면 비전 인코더를 로드하지 않는편이 메모리 초기화시간에 유리하다.

vllm serve Qwen/Qwen3.5-397B-A17B-FP8 \
  --language-model-only \        # 비전 인코더 미로드
  --reasoning-parser qwen3 \
  --enable-prefix-caching

백만 에이전트 환경 규모의 강화 학습 #

Qwen3.5의 ㄱ오식 소개에서 세 축중 하나로 내세우는 항목이다.

강화학습을 백만 규모의 에이전트 환경으로 확장하고, 과제 난이도를 점진적으로 올리는 커리큘럼을 적요앻ㅆ다고 밝히고 있다.

왜 이게 필요하냐면 도구를 잘 쓰는법을 배우려면 도구를 쓰는 예시 데이터가 필요한데 그런 데이터는 인터넷에 거의없고 시뮬레이션 환경을 대량으로 만들어 모델이 직접 시행착오를 겪게해야한다. 이게 유일한 확장 가능한 방법이다.

난이도 커리큘럼은 사람의 학습과 같은 발상으로 처음부터 어려운 과제만 주면 성공 사례가 없어 보상 신호가 희박해지고 학습이 진행되지 않는다. 쉬운것부터 올리면 매 단계에서 유의미한 신호가 나온다.

Strong to weak 증류 #

작은 모델을 만들 때 처음부터 따로 학습시키는것이 아닌 큰 모델의 출력을 흉내 내며 배우게 한다.

이는 정답 토큰 하나만 빌려주는 것 보다 큰 모델이 각 토큰에 부여한 확률 분포 전체를 알려주면 정보량이 훨 크다.

"정답은 A"보다 "A가 70% B가 20% C가 8% ..." 가 더 많은 것을 가르친다.

이것이 Qwen의 작은 모델들이 같은 크기의 경쟁 모델보다 강한 이유중에 하나다. 0.8B 모델이 397B의 지식을 부분적으로 물려받는다.

컨텍스트 확장 - YaRN #

Qwen3.5 오픈 모델은 네이티브 262,144 토큰이고 YaRN으로 1,010,000 토큰까지 확장한다.

Qwen 3.6은 네이티브 1M 이다.

YaRN: RoPE는 위치를 회전각으로 표현하는데, 훈련 때 본 적 없는 긴 위치에서는 회전이 과도해져 모델은 혼란스러워 한다. YaRN은 회전주기를 늘려 긴 위치에서도 훈련 범위 안의 각도로 매핑해 토큰 확장에 기여했다.

# vLLM에서 YaRN 적용
vllm serve Qwen/Qwen3.5-397B-A17B-FP8 \
  --hf-overrides '{"rope_scaling":{"rope_type":"yarn","factor":4.0,
                   "original_max_position_embeddings":262144}}' \
  --max-model-len 1010000

factor 선택에 원칙이 있는데 factor 2.0은 약 524K, 4.0은 약 1M을 커버하고

factor를 높일 수록 짧은 컨텍스트에서 품질이 떨어진다.

실제로 워크로드가 요구하는 길이에 맞춰 최소한으로 잡아야한다. 1M을 지원한다고 무조건 4.0으로 두면 대부분 짧은 요청에 손해를 본다.

factor(스케일링 펙터, s)는 원래 학습된 최대 컨텍스트 길이를 몇 배로 늘릴 것 인가를 결정하는 배율 값으로 (확장할 최대 컨텍스트 길이 / 모델의 원래 사전학습 컨텍스트 길이)가 기본값 공식이다/ 원래 4K(4,096) 토큰을 지원하던 모델이 128K(131,072) 토큰으로 확장하고싶다면 fator값은 128K/4K 로 32가 된다.

강점의 인과, 알려진 약점 #

로컬 실행 - 이 카테고리 사실상 독주 #

Qwen3.6-27B는 Q4_K_M 기준 약 16.8G로 RTX 3090, 4090 한 장에 들어가면서도 SWE-bench Verified 77.2를 낸다. 이전 세대 오픈 플래그십인 Qwen3.5-397B-A17B를 코딩 벤치마크에서 앞서기 까지 한다.

RTX 4080은 16GB~ VRAM 탑재하고 있어 Qwen3.6모델을 기동할때 KV캐시랑 다 올리려면 45 bit IQ4_XS, Q4_K_M등 고효율 양자화를 사용하고 이 경우 토큰 생성 속도 TPS는 약 1535TPS 내외를 기록한다. 4비트 이하 퀀트가 필수고 컨텍스트 길이를 길게 잡을 경우 KV 캐시 크기 수가 GB로 불어나며 VRAM초과시 오프로딩으로 인해 TPS가 급감할 수 있다. -ctk q8_0 -ctv q8_0 옵션을 주어 KV 캐시를 8비트로 압축하면 VRAM을 아끼고 처리량을 높일 수 있긴 하다.

왜 이런 결과가 나오는가 단계별로 본다면

1. 나중에 나온 세대라 학습 데이터와 사후학습 기법이 개선됨
        ↓
2. strong-to-weak 증류로 상위 모델의 능력을 물려받음
        ↓
3. 하이브리드 어텐션으로 작은 모델도 긴 컨텍스트를 감당
        ↓
4. dense 구조라 배치 1(개인 사용) 환경에서 MoE 대비 유리
   → MoE는 총 파라미터를 전부 메모리에 올려야 하는데
     배치가 작으면 활성 파라미터의 계산 이점이 살아나지 않음
        ↓
5. Apache 2.0 + 가장 두꺼운 GGUF·양자화 생태계
   → 나오자마자 Ollama, LM Studio, llama.cpp에서 돌아감

5번이 과소평가 되는데, 벤치마크 2점보다 "지금 당장 내 장비에 들어가는가"가 중요한 경우가 많고

문제가 생겼을 때 먼저 겪은 사람이 있다는 것도 큰 자산이다. 다운로드 수와 파생 모델 수가 많다는 지표는 이 지루한 장점을 이겨낸다.

다국어 - 201개 언어 #

Qwen3가 119개, Qwen 3.5가 201개 언어와 방언으로 확대되었다. 이 노트를 쓰는 지점에서 오픈 모델 중 가장 넓은 언어 커버리지다.

한국어 사용자에게는 실질적인 의미가 두 가지 존재한다.

1. CJK 처리 품질: 중국어, 일본어, 한국어에서 서구 모델 대비 우위가 오래 유지되어 왔고 학습 데이터에서 이들 언어의 비중이 높기 때문이다.
2. 토크나이저의 효율: Qwen3.5의 어휘사전은 248,320개의 다국어에 맞춰 확장되어왓고 사전이 다국어를 잘 커버하면 같은 한국어 문장을 더 적은 토큰으로 표현한다. 토큰 수가 적으면 비용과 지연이 그만큼 줄고 같은 컨텍스트 창에 더 많은 내용이 들어간다.

Qwen은 언어 지원의 정의를 넓게 잡는 편이라 201개의 언어 전부와 품질이 보장되는 것은 아니며, 저자원 언어일수록 편차가 크다 한국어처럼 데이터가 충분한 언어와 그렇지 않은언어같은 기준으로 보면 안된다.

한국어 성능은 이해와 생성을 나눠서 평가해야하고 이해는 대부분 모델이 잘하지만 자연스러운 한국어 문체 생성은 편차가 크다 반드시 자기 용도로 문체를 직접 비교하길 권장한다.

훈련 및 추론 효율 #

Qwen3-Next-80B-A3B가 Qwen3.32B 컴퓨트의 9.3%로 동등 이상 성능을 냈고, Qwen 3.5가 Qwen3-Max대비 32K에서 8.6배 256K에서는 최대 19배의 디코딩 처리량을 냈다.

이 효율은 하이브리드 어텐션 하나에서 나온다. 층의 75퍼센트가 선형 어텐션이므로 그 층들은 KV캐시가 없고 계산 길이에 선형이다. 컨텍스트가 길 수록 이득이 커진다.

배포 관점에서는 같은 GPU로 더 많은 동시 사용자를 받는다는 뜻이고, 이는 토큰당원가로 직결된다.

약점 및 논란 #

시험 문제 편향 #

한 연구자가 Qwen기반 모델 임베딩을 분석한 결과 매우 시험 문제 중심적인 분지에 위치해 LLaMA, Gemma 같은 다른 기반 모델과 뚜렷하게 구분된다고 보고했다. 학습 데이터를 시험 평가 형식의 텍스트가 많이 포함되었을 (치팅) 가능성을 시사한다.

벤치마크 점수와 실제 사용 경험의 간극을 설명하는 단서로 벤치마크는 대부분 시험형식이므로 시험 형식에 익숙한 모델이 유리하다 실무는 시험 형식이 아니다.

벤치마크 점수를 그대로 받아들이지 않고 자기 업무 형식의 케이스 20~50건으로 직접 평가해야한다. 이 원칙은 모든 모델에 적용되지만 Qwen에서는 특히 유의미하다.

범용 에이전트 능력의 상대적 약세 #

Qwen3.6-35B-A3B는 VITA-Bench에서 35.6점으로 같은세대 27B(41.8)이나 Gemma4-31B(43.0) 보다 낮다. 코딩 벤치마크의 강세가 범용 에이전트 능력으로 그대로 이어지지는 않는다.

코딩 에이전트와 범용 에이전트는 다른 능력이다. 코딩은 검증 가능한 보상으로 강화학습을 돌리기 쉬워 집중 투자의 효과가 크다. 범용 에이전트 작업은 정답이 불분명해 같은 방식이 통하지 않는다.

사고 루프 #

커뮤니티 보고에서 반복적으로 언급되는 문제로 사고모드에서 같은 추론을 맴돌며 토큰을 소모하는 현상이다.

대응: 사고 예산 상한을 명시적으로 설정해서 작업 난이도에 따라 사고모들 껐다 켰다를 라우팅해두는것이 실용적이다.

세대 회전 속도 빈번 #

1년 3개월 사이에 Qwen3 → Next → 3.5 → 3.6 → 3.7 → 3.8이 나왔다

어느 세대를 사내 표준으로 잡을지 정하기가 어렵고 파인튜닝한 모델이 금세 구세대가 된다.

대응: 세대 자체를 추격하지말고 평가셋을 자산으로 관ㄹ히ㅏ여 새 모델이 나오면 같은 평가셋을 돌려 유의미한 개선이 있을때만 이전한다. 평가셋이 없으면 매번 새 모델로 갈아타면서 실제 나아졌는지 알 수 없다.

상위 티어 접근성 #

Qwen3.7-Max, Qwen3.8-Max는 API 전용으로 오픈웨이트로 얻을 수 있는 최고 성능은 항상 한세대가 뒤처진다.

wen3.8에서 Max 등급 오픈이 예고되었지만 지금시점엔 아직 안열림..

작업별 선택 가이드 #

로컬 코딩 - 단일 GPU #

Qwen3.6-27B (Q4_K_M, 약 16.8GB)

24GB GPU 한장에서 SWE-bench Verified 77.2를 낸다.

dense라 MoE 오프로딩 설정 없이 그냥 돌아간다.

# Ollama
ollama run qwen3.6:27b

# llama.cpp (MTP 포함 GGUF 권장)
llama-server -m Qwen3.6-27B-Q4_K_M-MTP.gguf \
  --spec-draft-n-max 2 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  -c 32768 -ngl 99

메모리가 32GB 이상이라면 35B-A3B도 후보로 멀티모달이 필요하거나 생성 속도가 더 중요하면 이쪽이 낫다.

--spec-draft-n-max 2 투기적 디코딩 또는 MTP 모델을 사용할때 가볍고 빠른 모델이 한번에 미리 추측해서 생성할 최대 단어 개수를 지정한다. 너무 크게설정하면 작은 모델이 틀린 예측을 할 확률이 높아져 일단 2나 3으로속도 향상에 가장 이상적인 값으로 세팅했다

--cache-type-k q8_0 및 --cache-type-v q8_0 (KV 캐시 양자화)는 AI가 문맥을 기억하는 공간 KV 캐시 데이터 용량을 8비트(q8_0) 크기로 압축(양자화)해서 기억력 손실을 거의 없으면서도 캐시가 차지하는 VRAM용량을 딱 절반으로 줄인다.

-ngl은 Number of GPU Layers(GPU에 올릴 레이어 수)는 AI 모델의 연산을 CPU대신 성능이 빠른 GPU에서 처리하도록 하는 값이고 99 or -1 모델이 전체 레이어 개수보다 충분히 큰 숫자를 입력하 가능한 모든 레이어를 GPU에 올려라 라는 최대 가속 설정으로 주로 사용한다

-c는 컨텍스트 사이즈로 컨텍스트 크기를 의미하며 대화나 문서 등 AI가 한번에 기억하고 이해하는 최대 토큰 개수다. 096, 8192, 32768 등으로 설정한다 그 이유는 컴퓨터 과학에서 메모리를 할당하고 처리할때 2의 거듭제곱 단위를 사용해야 효율이 극대화되기 때문이다 2진법 체계를 생각하자.

서버 코딩 에이전트 #

Qwen3-Coder-Next or Qwen3.6-35B-A3B

Coder 계열은 하네스 호환성을 명시적 목표로 삼아 만들어졌다.

256K 컨텍스트에 다양한 스캐폴드 템플릿에 적응하도록 훈련되어 claude code, qwen code, qoder, kilo, trae, cline등과 통합된다.

vllm serve Qwen/Qwen3-Coder-Next \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --enable-prefix-caching \
  --port 8000

--tool-call-parser qwen3_coder 가 중요한데, 이는 모델이 내는 도구 호출 형식을 OpenAI 형식으로 변환하는 파서이며 지정하지 않으면 하네스 도구가 호출을 인식하지 못한다.

대량 배치 처리 #

Qwen3.5-4B or 9B

분류 추출 요약처럼 난이도가 낮고 양이 많은 작업은 작은 모델로 충분한 경우가 많다.

앞선 케이스북에서 다뤘듯 모델 다운사이징이 어떤 설정 튜닝보다 큰 배수를 낸다.

검증 전차를 먼저 거쳐보자.

# 사람이 라벨링한 검증셋으로 후보 비교
python eval_batch.py \
  --models Qwen3.5-27B Qwen3.5-9B Qwen3.5-4B Qwen3.5-2B \
  --testset labeled_500.jsonl \
  --metrics accuracy,rouge-l

이걸 돌려서 요구 품질을 만족하는 최소 모델을 고른다.

RAG #

세 모델을 조합해서 쓸 수 있다.

사용자 질문
    ↓
Qwen3-Embedding-0.6B ── 벡터화 → 벡터 DB에서 상위 100건 검색
    ↓
Qwen3-Reranker-4B ──── 100건을 재정렬 → 상위 5건 선별
    ↓
Qwen3.6-27B ────────── 선별된 문서로 답변 생성

임베딩과 리랭커를 나누는 이유: 임베딩은 이중 인코더라 질문과 문서를 따로 벡터화해 미리 인덱싱할 수 있다. 빠르지만 정밀도가 낮고 리랭커는 교차 인코더라 질문과 문서를 함께보고 판단한다 정확하지만 느려서 전체 문서에 적용할 수 없다.

비윤ㄴ 서류 심사와 면접의 관계로 서류(임베딩)으로 1만명을 100명으로 줄이고 면접(리랭커)로 100명을 5명으로 줄인다. 1만명을 전부 면접 볼수는 없기에.

Qwen3-Embedding-8B는 MTEB 다국어 리더보드에서 70,58점으로 1위를 기록했고 (2025년 6월 5일 기준) Qwen3-Reranker-4B는 MTEB-R 69.76점, 8B는 중국어 CMTEB_R 77,45와 코드검색 MTEB-Code 81.22를 냈다.

크기 선택: 임베딩은 색인 지점에 전체 코퍼스를 처리해야 하므로 0.6B로 시작해 필요할 때 올리는 편이 실용적이다. 리랭커는 상위 100건에만 적용되므로 4B를 써도 부담이 적다.

두 모델 모두 **지시문 인식 (instruction aware)**을 지원한다.

"법률 계약 분석 관점에서 관련성을 판단하라" 같은 지시를 넣어 도메인에 맞출 수있고 Qwen 공식 평가에서 지시문을 쓰는 편이 대부분의 다운스트림 작업에서 유리했다.

임베딩 모델은 **MRL(Matryoshka Representation Learning)**을 지원해 최종 벡터 차원을 사용자가 정할 수 있다. 벡터디비 저장비용과 검색품질을 조절할 수 있다는 뜻이다.

멀티 모달 #

Qwen3.5 이상의 범용 모델 - 얼리 퓨전이라 별도 VL 모델이 필요 없다.

Qwen3.5-397B-A17B의 공식 수치다.

문서 처리   OmniDocBench 1.5  90.8   OCRBench 93.1   CC-OCR 82.0
영상 이해   VideoMME(자막) 87.5   VideoMMMU 84.7   MLVU 86.7
수학 시각   MathVision 88.6   MathVista(mini) 90.3   We-Math 87.9
UI 조작     ScreenSpot Pro 65.6   OSWorld-Verified 62.2   AndroidWorld 66.8

문서 OCR, UI조작이 강한 축이다. 스크린샷을 보고 클릭할 좌표를 찾는 능력 ScreenSpot, OSWorld는 컴퓨터 사용 에이전트의 전제 조건이다.

멀티모달 서빙시 설정이다.

vllm serve Qwen/Qwen3.5-397B-A17B-FP8 \
  -dp 8 --enable-expert-parallel \
  --mm-encoder-tp-mode data \        # 비전 인코더를 데이터 병렬로
  --mm-processor-cache-type shm \    # 전처리 결과 공유 메모리 캐싱
  --reasoning-parser qwen3 \
  --enable-prefix-caching

--mm--processor-cache-type shm은 같은 이미지가 반복 등장할때 전처리를 건너뛰게 한다.

문서 QA처럼 같은 이미지에 여러 질문이 오는 워크로드에서 효과가 크다.

파인튜닝 기반 모델 #

Qwen 전 라인업 좋음 이 용도에서 Qwen 우위가 가장 큼 파인튜닝은 내 데이터양에 맞는 적당한 크기를 고르는 것이핵심이다.

데이터가 1,000건인데 70B를 튜닝하면 과적합하고 100만건인데 1B를 쓰면 용량이 부족하다.

Qwen만이 0.8B부터 400B까지 같은세대에서 제공하므로 이 선택이 가능하다.

Apaceh 2.0이라 파생 모델의 상업적 재배포 제약이 없다는 점도 크다.

엣지 온디바이스 #

Qwen3.5-0.8B/2B

휴대폰이나 임베디드에서 라우팅, 의도 분류, 간단한 요약을 처리한다. 복잡한 요청만 서버 모델로 넘기는 계층 구조를 만듦녀 비용과 지연을 크게 줄일 수 있다.

선택 순서도 #

멀티모달(이미지·비디오)이 필요한가?
├─ 예 ─→ Qwen3.5 이상 범용 모델 (3.6-35B-A3B 또는 3.5-397B)
└─ 아니오
    ↓
검색 파이프라인의 일부인가?
├─ 벡터화 ─→ Qwen3-Embedding (0.6B부터)
├─ 재정렬 ─→ Qwen3-Reranker (4B)
└─ 답변 생성 ─→ 아래로
    ↓
어디서 돌리나?
├─ 단일 24GB GPU ─→ Qwen3.6-27B ★
├─ 32GB+ 통합 메모리 ─→ Qwen3.6-35B-A3B
├─ 8GB 이하 / 엣지 ─→ Qwen3.5-2B / 4B
├─ 멀티 GPU 서버 ─→ Qwen3.5-122B-A10B
└─ 데이터센터 ─→ Qwen3.5-397B-A17B
    ↓
작업 성격은?
├─ 코딩 에이전트 ─→ Coder 계열 또는 3.6-27B
├─ 대량 배치 ─→ 검증 후 가능한 최소 크기
├─ 범용 에이전트 ─→ VITA-Bench 약세 확인. 다른 가문도 비교
└─ 최고 성능 필요 ─→ Qwen3.8-Max (API 전용)

하네스와 서빙 스택 #

하네스는 모델을 감싸 도구를 주고 파일을 읽게하는 명령을 실행시키는 껍데기다

코딩에이전트에서는 claude code, qwen code, cline, opnecode같은 것들이 여기에 해당한다.

같은 모델이라도 하네스에 따라 성능이 달라진다. 시스템 프롬프트로 도구 저으이 형식 컨텍스트 관리 방식이 다르기 때문이다.

NVIDIA의 Polar: Agentic RL on Any Harness at Scale 논문(2026년 5월)의 벤치마크에서 Qwen3.5-4B 기반 모델이 Qwen-Code 하네스에서 최고의 코딩 성능을 보였다.

모델과 하네스가 같은 팀에서 나온 조합이 유리했다는 뜻이다.

이유는 QwenCode는 Qwen 모델에 맞춰 프롬프트와 함수 호출 프로토콜을 조정했다고 공식적으로 밝히고있다. 모델의 사후 학습에 쓰인 도구 호출 형식과 하네스가 기대하는 형식이 일치하면 마찰이 줄어든다.

실무 원칙: 모델을 바꿀 때 하네스도 함께 검토하라. 벤치마크 점수는 특정 하네스에서 측정된값이며 다른 하네스에서는 순위가 바뀔 수 있다.

Qwen code #

Qwen팀이 Qwen3-Coder와 함께 공개한 터미널 에이전트로 Google Gemini CLI를 포크해 Qwen모델에 맞게 프롬프트와 함수 호출 프로토콜을 조정했다.

npm i -g @qwen-code/qwen-code@latest

# 로컬 vLLM/SGLang 서버를 Qwen Code에 연결
export OPENAI_BASE_URL="http://127.0.0.1:8000/v1"
export OPENAI_API_KEY="dummy"
export OPENAI_MODEL="Qwen/Qwen3.6-27B"

qwen

서빙 스택별 권장 구성 #

vLLM - Qwen3.5-397B-A17B

텍스트 전용, 8 GPU 데이터 병렬

vllm serve Qwen/Qwen3.5-397B-A17B-FP8 \
  -dp 8 \
  --enable-expert-parallel \
  --language-model-only \
  --reasoning-parser qwen3 \
  --enable-prefix-caching

• -dp 8 --enable-expert-parallel: MoE는 전문가를 통째로 배정하는 편이 통신에 유리하다.
• --language-model-only: 텍스트만 쓸 때 비전 인코더 미로드로 메모리를 절약한다.
• --reasoning-parser qwen3: 사고 토큰을 응답해서 분리해 반환한다.
• --enbale-prefix-caching: 시스템 프롬프트 반복 재사용

Blackwell(GB200)환경 이라면 NVFP4 체크포인트가 권장된다.

vllm serve nvidia/Qwen3.5-397B-A17B-NVFP4 \
  -dp 4 --enable-expert-parallel \
  --language-model-only --reasoning-parser qwen3 \
  --enable-prefix-caching

NVFP4는 Blackwell의 5세대 텐서 코어가 네이티브로 처리한다.

Hopper에서는 지원이 없어 오히려 느려지므로 FP8을 쓰는걸 추천한다.

저지연 워크로드에서는 MTP 투기적 디코딩을 켜고 접두사 캐싱을 끄는 조합이 권장된다.

NVFP4 체크포인트는 NVIDIA에서 개발한 4비트 부동 소수점 형식으로 압축, 최적화된 인공지능 모델의 가중치 및 상태 기록파일이다. 모델의 정확도 손실을 최소화하면서도 용량을 줄여 최신하드웨어와의 속도 그리고 효율성을 극대화한다.

MTP-1 투기적 디코딩
  → 높은 수용률로 TPOT(토큰당 시간) 감소
  → 대신 부하가 걸린 상황에서는 처리량 하락

동시성이 낮을때만 이득이라 이건 트래픽의 특징을 파악하고 맞게 튜닝하자.

SGLang #

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.6-27B \
  --tp-size 2 \
  --quantization fp8 --kv-cache-dtype fp8_e5m2 \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --chunked-prefill-size 4096 \
  --enable-metrics --enable-cache-report

• --tool-call-parser qwen3_coder: 이거 없이는 하네스가 도구 호출을 인식하지 못한다.
• **하이브리드 아키텍처 모델(Qwen3-Next, 3.5 3.6)**은 선형 어텐션층과 전체 어텐션 층을 함께 관리하는 KV 캐시 매니저가 필요하므로 엔진 버전이 그 세대를 지원하는지 먼저 확인해야한다.

llama.cpp / Ollama - local #

# MTP 포함 GGUF 사용 (파일명에 MTP 표기 확인)
llama-server \
  -m Qwen3.6-27B-Q4_K_M-MTP.gguf \
  --spec-draft-n-max 2 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  -c 32768 \
  -ngl 99 \
  --host 0.0.0.0 --port 8080

16GM VRAM 기준 실측 권장값은 앞서 정리한대로 27B dense는 --spec-draft-n-max 2 + q8 KV가 가장 빠르고 컨텍스트 여유가 필요하면 1 + q5 KV로 내린다.

조합 정리 #

| 상황 | 모델 | 서빙 | 하네스 |
|---|---|---|---|
| 개인 로컬 코딩 | Qwen3.6-27B Q4_K_M | Ollama / llama.cpp | Qwen Code, Cline, OpenCode |
| 팀 서버 코딩 | Qwen3-Coder-Next | vLLM / SGLang | Qwen Code, Cline |
| RAG 서비스 | Embedding 0.6B + Reranker 4B + 3.6-27B | SGLang (HiCache) | 자체 파이프라인 |
| 멀티모달 에이전트 | Qwen3.5-397B-A17B | vLLM (mm 옵션) | 자체 또는 OpenCode |
| 대량 배치 | Qwen3.5-4B/9B | SGLang (배치 극대화) | 불필요 |
| 최고 성능 | Qwen3.8-Max | API | Qwen Code, Claude Code 등 |

공식 벤치마크 자료 #

Qwen3.5-397B-A17B 공식 수치 #

Qwen 팀과 배포 파트너가 공개한 값이다.

언어·추론 #

코딩·에이전트 #

멀티모달 #

BrowseComp 69.0 78.6 두 값을 보고된 점을 눈여겨 보라

같은 모델, 같은 벤치마크인데 전략에 따라 9.6점이 갈린다

에이전트 벤치마크 점수는 모델의 순수 지능뿐 아니라 스캐폴딩과 컨텍스트 관리 방식의 함수라는 것을 보여준다.

Qwen3.6 세대 #

활성 파라미터가 3B, 27B 이 두개와 거의 같은 수학 과학 점수를 낸다

AIME 92.7 vs 92.6, GPQA 86.0 vs 85.5

반면 SWE-bench는 3.8 VITA-Bench는 6.2가 뒤진다.

이 패턴은 수학 과학 문제는 한 번의 정확한 추론으로 풀리는 반면에 에이전트 작업은 여러 단계에 걸쳐 상태를 유지해야하므로 활성 파라미터가 적으면 후자에서 불리해진다.

Artificial Analysis 지능 지수 43은 비슷한 크기 오픈웨이트 모델의 중앙값 15와 비교하면 크게 앞선값이다.

Qwen3.8-Max #

2026. 8. 3 공개와 함께 알리바바 발표한 값이다.

사양과 가격

총 파라미터   2.4T
활성 파라미터  95B
컨텍스트     1,000,000 토큰 (일부 자료는 983,616)
최대 출력    131,072 토큰
사고 모드    항상 켜짐. low / high / xhigh 조절
가격        입력 $2 / 출력 $6 / 캐시된 입력 $0.25 (100만 토큰당)
API 호환    OpenAI 사양 + Anthropic 사양

Qwen3.8-Max 발표는 벤더 벤치마크를 읽는 훈련에 좋은데

같은 표에서 두 가지 사실이 동시에 참이다

"Terminal-Bench 2.1에서 Claude Opus 4.8과 Fable 5를 앞섰다"   → 86.6 vs 84.6  ✓
"SWE-bench Pro에서 Fable 5에 크게 뒤진다"                     → 67.7 vs 80.0  ✓
"FrontierSWE에서 Fable 5에 크게 뒤진다"                        → 73.5 vs 88.8  ✓

벤치마크 읽을때 주의점은 아래와 같다

1. 전자만 헤드라인에 실린다. 벤더 발표를 읽을 때는 유리한 행과 불리한 행을 함께 보는 습관이 필요
2. 독립 검증이 없다 8월 3일 공개 시점에 Artificial Analysis를 비롯한 독립 평가 기관의 수치가 없었고, 커뮤니티 리더보드에도 오르지 않은 상태다. 벤더 표와 독립 측정치의 차이가 실제 이야기가 된다.
3. 멀티모달 표의 기준선이 다르다 알리바바 멀티모달 비교는 Qwen3.7-Max가 아니라 Qwen3.7-Plus를 기준으로 삼아서 Plus는 Max보다 낮은 등급이므로 세대간 개선폭이 실제보다 커보인다

벤더 벤치마크 체크리스트

□ 누가 측정했나
  자기 모델 점수와 경쟁사 점수를 같은 팀이 냈다면,
  경쟁사 점수 쪽에 더 큰 의심이 필요합니다.

□ 어떤 하네스와 설정인가
  에이전트 벤치마크는 하네스에 민감합니다.
  BrowseComp 69.0 vs 78.6이 그 예입니다.

□ 비교 대상이 같은 등급인가
  Plus를 기준선으로 삼고 Max와 비교하면 격차가 부풀려집니다.

□ 불리한 행이 표에 있는가
  전부 이겼다는 표는 유리한 행만 골랐을 가능성이 큽니다.

□ 독립 측정치가 나왔나
  보통 며칠에서 몇 주 걸립니다. 그때까지는 판단 보류.

□ 사고 예산이 얼마였나
  xhigh로 측정한 점수와 low로 쓰는 실사용은 다릅니다.

결국 필요한 것은 자기 평가셋 #

벤치마크 100개보다 자기업무케이스 20~50건이 정확하다

Qwen은 시험 형식 데이터 편향 의혹이 잇어 특히 그렇다

#!/usr/bin/env python3
"""blind_eval.py — 모델 후보 블라인드 비교"""
import json, random, asyncio, aiohttp

MODELS = {
    "A": "http://localhost:8001/v1",   # Qwen3.6-27B
    "B": "http://localhost:8002/v1",   # Qwen3.6-35B-A3B
    "C": "http://localhost:8003/v1",   # 비교 대상
}

async def run_one(session, base_url, prompt):
    async with session.post(f"{base_url}/chat/completions", json={
        "model": "local", "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.0, "max_tokens": 2048,
    }) as r:
        d = await r.json()
        return d["choices"][0]["message"]["content"]

async def main(cases_path, out_path):
    cases = [json.loads(l) for l in open(cases_path)]
    async with aiohttp.ClientSession() as s:
        with open(out_path, "w") as out:
            for c in cases:
                results = {}
                for key, url in MODELS.items():
                    results[key] = await run_one(s, url, c["prompt"])
                # 라벨을 섞어서 평가자가 어느 모델인지 모르게 함
                labels = list(results.keys())
                random.shuffle(labels)
                out.write(json.dumps({
                    "case_id": c["id"],
                    "prompt": c["prompt"],
                    "criteria": c["criteria"],
                    "outputs": [{"shown_as": i + 1, "hidden_model": k,
                                 "text": results[k]} for i, k in enumerate(labels)],
                }, ensure_ascii=False) + "\n")

asyncio.run(main("my_cases.jsonl", "blind_results.jsonl"))

평가케이스는 이런 형식으로 만든다.

{"id": "code-01",
 "prompt": "다음 Python 함수의 버그를 찾아 수정하세요:\n...",
 "criteria": "인덱스 오프바이원 오류를 지적하고, 수정된 코드가 실행되어야 함"}

용어 정리 #

오해와 함정 #

35B-A3B는 3B 모델만큼 가볍다? #

활성 파라미터는 속도를, 총 파라미터는 메모리를 결정한다

35B-A3B는 계산량이 3B 수준이라 빠르지만, 35B 전체 메모리를 올려야한다. Q4기준 약 20GB이다.

자체 호스팅 가능 여부 총 파라미터로 판단하자.

MoE가 항상 dense보다 효율적이다? #

배치 1 (개인 로컬 사용)에서는 dense가 유이랗ㄴ 경우가 많다.

MoE 이점은 여러 요청이 서로 다른 전문가를 쓰면서 GPU를 채울 때 나오고 요청이 하나뿐이면그 효과가 없다.

반면 총 파라미터를 메모리에 올려야하는 부담은 그대로다

Qwen3.6-27B가 커뮤니티에서 선호된 이유가 이거다.

코딩을 잘하니 에이전트 작업도 잘한다? #

Qwen3.6-35B-A3B는 SWE-bench로 73.4로 강하지만 VITA-Bench는 5.6으로 같은세대 27B(41.8) or Gemma4-31B(43.0) 보다 낮다.

즉 코딩은 컴파일러로 검증이 가능해 강화학습을 대규모로 도릴ㄹ 수 있고 그래서 집중 투자에 효과가 크다

범용 에이전트 작업은 정답이 불분명해 같은 방식이 통하지 않는다. 두 능력은 따로 측정해야한다

1M Context니까 1M을 넣으면 된다? #

YaRN factor를 높이면 긴 컨텍스트를 다룰 수 있지만 짧은 컨텍스트 품질이 떨어진다

실제 워크로드가 요구하는 길이에 맞춰 최소한으로 설정해야한다.

그리고 1M을 실제로 채우면 KV가 폭발하고 프리필이 수 초에서 수십초가 걸리니까 대부분의 경우 RAG로 줄이는 편이 더 싸고 정확하다.

추가 함정 #

--tool-call-parser qwen3_coder 없이 서빙하면 모델은 도구 호출을 정상적으로 생성하는데 하네스가 인식하지 못한다. 이 증상은 에이전트가 도구를 안쓴다로 나타나 모델 성능으로 오인하기 쉽다/

--reasoning-parser qwen3 도 마찬가지로 없으면 사고 토큰이 최종 응답에 껴져서 나온다.

하이브리드 모델 구버전 엔진 서빙 #

그리고 하이브리드 모델을 구버전 엔진으로 서빙하는 것에 대한걸 보면

Qwen3-Next에후에는 선형 어텐션 층과 전체 어텐션층을 함께 관리하는 KV 캐시 매니저가 필요하다.

엔진이 그 세대를 지원하지 않으면 로드가 실패하거나 로드되더라도 성능이 크게 떨어진다.

MTP GGUF와 GGUF를 혼동 #

llama.cpp에서 투기적 디코딩을 쓰려면 파일명에 MTP가 포함된 GGUF를 받아야한다.

일반 GGUF에 --spec-draft-n-max를 줘도 아무 효과가 없다.

그리고 MTP는 VRAM 추가로 쓴다. 16GB 카드에서 35B-A3B는 --spec-draft-n-max 1에서도 평균 컨텍스트가 15K 수준으로 ㅜㄹ어든다.

NVFP4 체크포인트를 Hopper에 올리기 #

NVFP4는 Blackwell의 5세대 텐서 코어가 네이티브로 처리한다.

Hopper H100/H200에는 하드웨어 지원이 없이 에뮬리이션이 되고 FP8보다 느려진다.

하드웨어에 맞는 체크포인트를 골라야하고 Hopper는 FP8, Blackwell은 NVFP4

세대를 무작정 따라가기 #

반년에 세대가 나오는 속도에서 매번 최신으로 갈아타면 검증에쓰는 개발시간이 넘으니

평가셋을 자산으로 관리하고 유의미한 개선이 확인될때까지 이전해야한다

서빙인자 요약 #

# 공통
--reasoning-parser qwen3              # 사고 토큰 분리
--tool-call-parser qwen3_coder        # 도구 호출 파싱
--enable-prefix-caching               # 접두사 재사용

# MoE
--enable-expert-parallel              # vLLM
--enable-ep-moe --ep-size N           # SGLang

# 멀티모달
--language-model-only                 # 텍스트만 쓸 때 비전 인코더 미로드
--mm-encoder-tp-mode data             # 비전 인코더 데이터 병렬
--mm-processor-cache-type shm         # 전처리 결과 캐싱

# 컨텍스트 확장
--hf-overrides '{"rope_scaling":{"rope_type":"yarn","factor":2.0,
                 "original_max_position_embeddings":262144}}'
--max-model-len 524288

# 양자화 (하드웨어에 맞춰)
Hopper    : FP8 체크포인트
Blackwell : NVFP4 체크포인트

llama.cpp 로컬 권장값 (16GB VRAM)

# Qwen3.6-27B dense — 속도 우선
--spec-draft-n-max 2 --cache-type-k q8_0 --cache-type-v q8_0

# Qwen3.6-27B dense — 컨텍스트 우선
--spec-draft-n-max 1 --cache-type-k q5_1 --cache-type-v q5_1

# Qwen3.6-35B-A3B MoE
--spec-draft-n-max 1 --cache-type-k q8_0 --cache-type-v q8_0
# 평균 컨텍스트 약 15K. 그 이상 드래프트 깊이는 VRAM만 소모

모델 선택 요약 #

로컬 24GB GPU, 코딩        → Qwen3.6-27B (Q4_K_M, 16.8GB)
로컬 32GB+, 멀티모달        → Qwen3.6-35B-A3B
서버, 에이전틱 코딩         → Qwen3-Coder-Next
서버, 멀티모달 + 에이전트    → Qwen3.5-397B-A17B
대량 배치                  → Qwen3.5-4B / 9B (검증 후)
엣지, 온디바이스            → Qwen3.5-0.8B / 2B
검색 벡터화                → Qwen3-Embedding-0.6B
검색 재정렬                → Qwen3-Reranker-4B
최고 성능 (API)            → Qwen3.8-Max