Qwen3.8-27B 공개, 벤치표를 믿어도 되나

어제까지 비어 있던 리포에 파일이 찼다
Qwen/Qwen3.8-27B 리포는 2026년 8월 5일 08시 22분(UTC) 에 만들어졌다. 그런데 그 안에 가중치는 없었다. 커뮤니티에서 공개 날짜가 올라왔다 내려가기를 반복하는 동안 리포는 열흘 가까이 껍데기로 남아 있었다.
그게 8월 14일 15시 00분(UTC), 한국 시각으로 오늘 자정 정각에 채워졌다. Hugging Face API가 돌려주는 lastModified가 정확히 그 시각이고, 17분 뒤인 15시 17분에는 Unsloth의 GGUF 변환본까지 올라왔다.
숫자 하나가 이 열흘을 잘 보여준다. 어제 이 리포를 확인했을 때 좋아요는 5,686개였다. 가중치가 아직 하나도 없는 리포였다. 오늘 확인한 값은 8,163개다. 하루 사이에 2,477개가 붙었는데, 그중 상당수는 파일이 아니라 “언제 올라오나”를 보러 온 사람들이 눌러 둔 것이다.
이 글은 그 실물을 놓고 세 가지를 본다. 벤치표에서 실제로 무엇을 이겼고 무엇에 밀렸는지, 그 표 아래 붙은 각주가 무슨 조건을 걸고 있는지, 그리고 이걸 정말 내 장비에서 돌릴 수 있는지다.
무엇이 올라왔나
먼저 사실 관계부터 정리한다.
| 항목 | 값 |
|---|---|
| 라이선스 | Apache-2.0 |
| 파라미터 | 27B (조밀 모델, MoE 아님) |
| 원본 파일 | safetensors 18개, 합계 55.6GB |
| 아키텍처 | Qwen3_5ForConditionalGeneration |
| 파이프라인 태그 | image-text-to-text |
| 컨텍스트 | 네이티브 262,144, 최대 1,000,000까지 확장 |
| 변형 | FP8 공식판, Unsloth GGUF |
라이선스가 Apache-2.0이라는 게 첫 번째 확인 사항이다. 공식 BF16 리포와 FP8 리포 양쪽 태그에 license:apache-2.0이 그대로 박혀 있다. 상업적 사용에 별도 조건을 다는 커스텀 라이선스가 아니다. 이 시리즈의 상위 모델에서 라이선스 조항 때문에 발이 묶였던 경험이 있다면, 27B는 그 문제가 없다.
두 번째는 조밀(dense) 모델이라는 점이다. 요즘 큰 오픈웨이트는 대부분 MoE라 총 파라미터와 활성 파라미터가 따로 논다. 27B는 그런 게 없다. 27B가 곧 27B다. 그래서 메모리 계산이 단순해지고, 양자화 결과도 예측 가능하다.
아키텍처 — 완전한 어텐션이 아니다
모델 카드에 적힌 레이어 구성이 특이하다.
64층 = 16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))
읽어 보면 이렇다. 네 층짜리 블록을 16번 반복하는데, 그중 세 층은 Gated DeltaNet(선형 어텐션 계열)이고 한 층만 Gated Attention(일반적인 소프트맥스 어텐션)이다. 전체 64층 중 진짜 어텐션은 16층뿐이라는 뜻이다.
세부 수치는 이렇다.
- Gated DeltaNet: 선형 어텐션 헤드가 V에 48개, QK에 16개. 헤드 차원 128
- Gated Attention: Q 헤드 24개, KV 헤드 4개. 헤드 차원 256, RoPE 차원 64
- FFN 중간 차원: 17,408
- 은닉 차원: 5,120
- 토큰 임베딩: 248,320 (패딩 포함)
- MTP(Multi-Token Prediction): 여러 스텝으로 학습됨
이 구성이 중요한 이유는 컨텍스트 비용 때문이다. 소프트맥스 어텐션은 길이에 제곱으로 붙지만 선형 어텐션은 선형으로 붙는다. 64층 중 16층만 제곱 항을 갖는 구조라서, 26만 토큰을 네이티브로 감당하고 100만까지 확장한다는 주장이 구조적으로 말이 된다. KV 헤드가 4개뿐인 것도 같은 방향이다.
바꿔 말하면, 긴 컨텍스트에서 이 모델이 쓰는 KV 캐시는 같은 크기의 순수 트랜스포머보다 훨씬 작다. 로컬에서 돌릴 때 실제로 체감되는 부분이다.
비전이 옵션이 아니라 기본이다
파이프라인 태그가 text-generation이 아니라 image-text-to-text다. 별도 VL 버전이 따로 있는 게 아니라, 27B 본체가 비전 인코더를 달고 나온다.
모델 카드는 “STEM 다이어그램과 문서부터 시간 단위 길이의 영상까지” 이해한다고 적었다. 이미지만이 아니라 영상까지 범위에 넣은 표현이다.
사고 모드는 켜진 채로 출고된다
기본값이 사고 모드 켜짐이다. 응답 앞에 <think>\n...</think>\n\n 블록이 먼저 나온다. 끄려면 요청마다 명시해야 한다.
깊이는 reasoning_effort로 조절한다. 지원 값은 세 개다.
xhigh— 기본값. 철저한 분석이 필요한 복잡한 작업용medium— 정확도와 속도의 균형low— 속도와 비용 최적화
여기에 preserve_thinking이 모든 워크로드에서 기본으로 켜져 있다. 이전 턴의 사고 맥락을 다음 턴까지 끌고 간다는 뜻이다.
기본값이 xhigh인 것은 실무에서 반드시 알아야 할 부분이다. 아무 설정 없이 붙이면 가장 비싼 모드로 돈다. 그런데 모델 카드가 여기에 반직관적인 경고를 하나 달아 놨다. 멀티턴 에이전트 작업에서는 사고 강도를 낮춘다고 총 소요 시간이 줄지 않을 수 있다는 것이다. 턴당 응답은 빨라지지만 분석이 부족해져 실패와 재시도가 늘고, 결과적으로 총 지연과 토큰 소모가 더 커질 수 있다고 적혀 있다.
샘플링 파라미터도 모드별로 권장값이 다르다.
| 모드 | temperature | top_p | top_k | presence_penalty |
|---|---|---|---|---|
| 사고 모드 | 1.0 | 0.95 | 20 | 0.0 |
| 인스트럭트(비사고) | 0.7 | 0.80 | 20 | 1.5 |
서빙은 SGLang, vLLM, TokenSpeed를 권장하고 각각 레시피 문서가 붙어 있다.
벤치표에서 이긴 칸
모델 카드의 비교 대상은 네 개다. 자사 이전 세대인 Qwen3.6-27B, 자사 상위 모델 Qwen3.7-Plus, 그리고 Muse Glimmer-30B와 Opus4.6 Max다.
먼저 Opus4.6 Max를 넘긴 칸을 모아 본다.
| 벤치마크 | Qwen3.8-27B | Opus4.6 Max |
|---|---|---|
| SWE-bench Pro | 61.7 | 53.4 |
| QwenSWEBench | 79.0 | 63.8 |
| CoWorkBench | 70.7 | 68.2 |
| IFBench (지시 따르기) | 79.5 | 62.5 |
| LiveCodeBench v6 | 90.3 | 88.8 |
| OSWorld-Verified (컴퓨터 사용) | 84.3 | 72.7 |
| AndroidWorld (모바일 사용) | 81.9 | 62.0 |
| SWE-MM (멀티모달 SWE) | 38.6 | 27.1 |
| MathVision | 90.0 | 65.5 |
| BabyVision | 65.7 | 12.6 |
| CharXiv (RQ) | 83.7 | 66.0 |
| OmniDocBench 1.5 | 91.1 | 86.6 |
| RealWorldQA | 85.9 | 73.9 |
| ERQA (체화 지능) | 65.5 | 40.8 |
27B짜리 오픈웨이트가 프런티어 모델을 열네 칸에서 앞선 표다. 특히 시각 관련 항목의 격차가 크다. BabyVision 65.7 대 12.6은 오타가 아니다.
자사 상위 모델과의 비교도 눈에 띈다. Qwen3.7-Plus보다 27B가 앞선 항목이 상당수다.
| 벤치마크 | Qwen3.8-27B | Qwen3.7-Plus |
|---|---|---|
| Terminal Bench 2.1 | 73.0 | 64.0 |
| SWE-bench Pro | 61.7 | 57.6 |
| DeepSWE 1.1 | 42.2 | 14.2 |
| QwenSWEBench | 79.0 | 59.2 |
| CoWorkBench | 70.7 | 65.1 |
| JobBench | 33.4 | 27.6 |
| OSWorld-Verified | 84.3 | 73.3 |
| WebArena-Verified | 64.8 | 55.3 |
| RecreationBench | 47.1 | 30.2 |
| Vision2Web | 62.9 | 42.1 |
| SWE-MM | 38.6 | 30.0 |
세대 간 점프도 크다. DeepSWE 1.1에서 Qwen3.6-27B가 13.3인데 3.8-27B가 42.2다. 같은 27B에서 세 배가 넘는다. QwenSWEBench도 49.3에서 79.0으로 뛰었다. Agents’ Last Exam은 Pass@1이 10.6에서 20.4로, 점수가 27.3에서 42.9로 올랐다.
벤치표에서 밀린 칸
이 표에서 Opus4.6 Max에 진 칸은 세 개다.
| 벤치마크 | Qwen3.8-27B | Opus4.6 Max |
|---|---|---|
| Terminal Bench 2.1 | 73.0 | 78.2 |
| GPQA Diamond | 89.2 | 91.3 |
| HLE | 30.8 | 40.0 |
| NL2Repo-Bench | 42.3 | 47.6 |
HLE의 30.8 대 40.0이 가장 크게 벌어진 칸이다. 9.2포인트 차이는 반올림으로 메울 수 있는 수준이 아니다.
그리고 자사 상위 모델에도 진 칸이 있다.
| 벤치마크 | Qwen3.8-27B | Qwen3.7-Plus |
|---|---|---|
| NL2Repo-Bench | 42.3 | 41.1 (앞섬) |
| GPQA Diamond | 89.2 | 90.3 |
| HLE | 30.8 | 34.7 |
| ClawEval-MM (평균) | 56.9 | 60.1 |
| CharXiv (RQ) | 83.7 | 85.8 |
| OmniDocBench 1.5 | 91.1 | 91.4 |
| RealWorldQA | 85.9 | 86.9 |
| ERQA | 65.5 | 69.8 |
| AndroidWorld | 81.9 | 81.0 (앞섬) |
패턴이 보인다. 에이전트·코딩·컴퓨터 조작 계열은 27B가 앞서고, 순수 지식·추론 계열은 여전히 큰 모델이 앞선다. GPQA Diamond와 HLE가 대표적이다.
이게 실무에서 무슨 뜻이냐면, 터미널을 돌리고 파일을 고치고 브라우저를 조작하는 일에는 27B로 충분할 가능성이 높지만, 어려운 과학 문제를 풀거나 폭넓은 지식을 요구하는 질의응답에는 여전히 프런티어 모델이 필요하다는 것이다. 27B를 도입한다면 이 경계를 어디에 그을지가 실제 설계 문제가 된다.
그 표 아래 각주를 읽어야 한다
여기서부터가 이 글의 본론이다. 벤치표에는 각주가 여덟 개 붙어 있는데, 그중 몇 개는 표를 읽는 방식을 바꾼다.
첫째, SWE-bench Pro 각주가 이렇게 적혀 있다. “Opus4.6 Max를 제외한 모든 모델은 Claude Code 하네스에서 temp=1.0, top_p=0.95, 256K 컨텍스트로 평가했다. 문제가 있는 태스크를 수정했고, 모든 베이스라인 모델을 그 정제된 벤치마크에서 재평가했다.”
두 가지가 걸린다. Opus4.6 Max의 SWE-bench Pro 점수 53.4는 재평가한 값이 아니라 공식 발표 값을 그대로 가져온 것이다. 그런데 벤치마크 자체는 Qwen이 “문제가 있다”고 판단한 태스크를 수정한 버전이다. 수정된 벤치마크에서 잰 61.7과, 원래 벤치마크의 공식 값 53.4를 같은 표의 같은 행에 놓은 셈이다. 이 비교는 조건이 다르다.
둘째, 자체 제작 벤치마크가 섞여 있다. QwenSWEBench는 각주에 “사내(in-house) 코딩 벤치마크”라고 명시돼 있고, CoWorkBench와 RecreationBench도 사내 벤치마크다. 79.0 대 63.8이라는 가장 큰 격차 중 하나가 자기가 만든 시험장에서 나온 숫자다. 자체 벤치마크가 곧 조작이라는 뜻은 아니지만, 출제자가 응시자인 시험은 가중치를 낮춰 읽는 게 맞다.
셋째, HLE는 GPT-4o가 채점했다. 각주에 “Judged by GPT-4o”라고 적혀 있다. LLM 심판 방식은 채점자 모델에 따라 결과가 흔들린다. 공교롭게도 27B가 가장 크게 진 항목이 이 방식으로 채점됐다.
넷째, MathVision의 프롬프트 조건이 비대칭이다. 각주에 따르면 Qwen3.8-27B는 “단계별로 추론하고 최종 답을 \boxed{} 안에 넣어라”는 고정 프롬프트 하나로 평가했고, 나머지 모델은 \boxed{} 요구가 있는 버전과 없는 버전 두 개를 돌려 더 높은 점수를 보고했다. 즉 경쟁 모델 쪽에 유리한 조건인데도 90.0 대 65.5가 나왔다는 뜻이다. 이 각주는 오히려 Qwen에 불리한 조건을 인정한 대목이라 신뢰도를 높인다.
다섯째, 정답 라벨을 고쳤다. MathVision과 CharXiv(RQ)에서 “수작업 검증을 거쳐 소수의 잘못된 정답 주석을 수정했고, 그 벤치마크의 모든 보고 점수는 수정된 주석으로 계산했다”고 적혀 있다. 모든 모델에 같은 수정본을 적용했다면 공정하지만, 다른 곳에서 발표된 같은 벤치마크 숫자와는 직접 비교하면 안 된다.
여섯째, Vision2Web은 gpt-5.4-2026-03-05가 채점했고 프런트엔드·웹페이지·웹사이트 세 범주의 평균이다. SWE-MM은 SWE-bench Multimodal의 공개 dev 스플릿에 Claude Opus 4.7 시스템 카드 부록 8.3의 수정을 적용해 평가했다.
정리하면 이렇다. 세대 간 비교(3.6-27B → 3.8-27B)는 조건이 통제돼 있어 신뢰할 만하다. 같은 하네스, 같은 파라미터, 같은 벤치마크 버전이다. DeepSWE 1.1이 13.3에서 42.2로 오른 것은 실제 개선으로 봐도 된다.
반면 Opus4.6 Max와의 비교는 그대로 받아들이면 안 된다. 하네스도 다르고, 일부는 공식 발표 값을 가져왔고, 일부는 벤치마크 자체가 수정본이며, 가장 큰 격차는 자체 벤치마크에서 나왔다.
“27B가 오퍼스를 이겼다”는 문장은 이 표에서 나오지 않는다. 이 표가 말할 수 있는 건 “27B가 특정 에이전트·시각 과제에서 프런티어급과 겨룰 만한 구간에 들어왔다”까지다. 그것만으로도 충분히 큰 뉴스다.
그래서 내 장비에서 도는가
이 시리즈의 상위 모델을 다룬 Qwen3.8 2.4T 오픈웨이트, 450GB의 벽에서 결론은 “개인은 이걸 기다리지 말고 27B를 기다려라”였다. 그 27B가 나왔으니 숫자로 확인한다.
Unsloth가 올린 GGUF 파일들의 실제 크기다. Unsloth Dynamic V3.0 프리뷰 양자화를 썼다고 적혀 있다.
| 양자화 | 파일 크기 |
|---|---|
| UD-IQ2_XXS | 9.01GB |
| UD-IQ2_M | 10.32GB |
| UD-Q2_K_XL | 10.68GB |
| UD-IQ3_XXS | 11.91GB |
| Q3_K_S | 12.57GB |
| UD-Q3_K_XL | 13.44GB |
| Q3_K_M | 13.82GB |
| IQ4_XS | 15.71GB |
| Q4_K_S | 16.12GB |
| Q4_0 | 16.06GB |
| IQ4_NL | 16.34GB |
| Q4_K_M | 17.11GB |
| Q4_1 | 17.54GB |
| UD-Q4_K_XL | 17.92GB |
| Q5_K_S | 19.27GB |
| Q5_K_M | 19.83GB |
| UD-Q5_K_XL | 20.22GB |
| Q6_K | 22.88GB |
| UD-Q6_K_XL | 25.92GB |
| Q8_0 | 29.05GB |
| UD-Q8_K_XL | 31.46GB |
| BF16 (2분할) | 54.66GB |
여기서 읽을 지점은 이렇다.
24GB 카드 한 장이면 Q6_K(22.88GB)까지 파일이 들어간다. 다만 파일 크기가 곧 필요 메모리는 아니다. KV 캐시와 컨텍스트가 그 위에 얹힌다. 실사용에서는 Q4_K_M(17.11GB)이나 UD-Q4_K_XL(17.92GB)을 놓고 남는 5~6GB를 컨텍스트에 쓰는 배분이 현실적이다.
16GB 카드는 IQ4_XS(15.71GB)가 아슬아슬하고, 여유를 두려면 Q3_K_M(13.82GB) 이하로 내려가야 한다.
통합 메모리 맥이라면 선택지가 넓다. 32GB에서 Q8_0(29.05GB)까지, 64GB면 BF16 원본도 올라간다.
그리고 앞서 본 아키텍처가 여기서 이득이 된다. 64층 중 48층이 선형 어텐션이고 KV 헤드가 4개뿐이라, 같은 컨텍스트 길이에서 KV 캐시가 순수 트랜스포머보다 작다. 26만 토큰을 로컬에서 쓰겠다는 계획이 아주 비현실적이지는 않다는 뜻이다.
비전을 쓰려면 파일이 하나 더 필요하다
놓치기 쉬운 부분이다. GGUF 리포에는 모델 파일 외에 mmproj-BF16.gguf와 mmproj-F16.gguf가 각각 0.93GB로 따로 올라와 있다. 이게 비전 프로젝터다.
즉 모델 파일만 받으면 텍스트 전용으로 돌아간다. 이미지와 영상 이해를 쓰려면 mmproj를 따로 받아 함께 로드해야 하고, 그만큼 VRAM 예산에 1GB 가까이를 더 잡아야 한다. “네이티브 비전 모델”이라는 표현만 보고 받았다가 이미지가 안 들어가는 상황이 여기서 나온다.
에이전트 도구에 붙일 때
Unsloth가 GGUF 리포에 적어 둔 항목 중 실무에 걸리는 게 두 개 있다.
- Developer Role 지원 — Codex 같은 에이전트 도구에서 동작하도록 처리했다고 적혀 있다
- 툴 호출 개선 — 중첩된 객체 파싱이 개선돼 툴 호출 성공률이 올라간다고 적혀 있다
오픈웨이트를 에이전트 하네스에 붙일 때 실제로 깨지는 지점이 대개 이 둘이다. 시스템/유저/어시스턴트 외의 역할을 채팅 템플릿이 처리하지 못하거나, 중첩 JSON 인자를 파싱하다 실패하는 경우다. 미리 손봤다고 명시한 건 좋은 신호지만, 자기 하네스에서 직접 확인하기 전까지는 믿을 근거가 아니다.
2.4T와 27B, 열흘 사이의 대조
같은 시리즈에서 열흘 사이에 나온 두 모델의 대조가 선명하다.
| Qwen3.8-2.4T-A95B | Qwen3.8-27B | |
|---|---|---|
| 구조 | MoE (활성 95B) | 조밀 27B |
| 원본 파일 | safetensors 213개 | safetensors 18개, 55.6GB |
| 4비트급 양자화 | 397GB | 17.11GB |
| 현실적 요구 메모리 | 450GB RAM | 24GB 카드 한 장 |
| 비전 | 없음 | 네이티브 (mmproj 별도) |
23배 차이다. 2.4T 쪽은 양자화를 끝까지 밀어도 개인 장비의 사정권 밖이었다. 27B는 게이밍 PC 한 대면 끝난다.
그리고 벤치표를 보면 이 23배가 성능 23배로 돌아오지 않는다. 오히려 27B가 자사 상위 모델인 3.7-Plus를 에이전트·코딩 항목에서 여럿 앞섰다. 크기를 키우는 것보다 사후 학습을 다듬는 쪽이 이 구간에서 더 남는다는 신호로 읽힌다.
아직 확인되지 않은 것
공정하게 적어 둘 것들이 있다.
첫째, 서드파티 검증이 없다. 이 글의 모든 벤치 숫자는 Qwen이 자기 모델 카드에 올린 값이다. 공개된 지 몇 시간밖에 안 됐으니 독립적인 재현 결과가 나올 시간이 없었다. 하루 이틀 뒤 커뮤니티 측정치와 비교해 보는 게 맞다.
둘째, 양자화 품질 손실이 측정되지 않았다. 위 표의 벤치 점수는 전부 원본 정밀도 기준이다. Q4_K_M으로 내렸을 때 SWE-bench Pro 61.7이 얼마나 유지되는지는 아무도 아직 모른다. 특히 Dynamic V3.0은 프리뷰라고 명시돼 있다.
셋째, 100만 컨텍스트는 조건부다. 모델 카드는 네이티브 262,144에 “최대 100만까지 확장 가능”이라고 적었다. 그리고 100만 컨텍스트를 기본으로 제공하는 건 곧 나올 Qwen Cloud 호스팅판이라고 따로 안내한다. 로컬에서 100만을 그냥 쓸 수 있다는 뜻이 아니다.
넷째, Qwen Cloud는 아직 열리지 않았다. 모델 카드에 “coming soon”으로 적혀 있다. 공식 API로 쓰려는 계획이라면 아직 기다려야 한다.
지금 무엇을 하면 되나
로컬 LLM을 돌리는 개인. 오늘 받아도 되는 첫 오픈웨이트다. 24GB 카드면 Q4_K_M이나 UD-Q4_K_XL, 16GB면 IQ4_XS나 Q3_K_M부터 시작한다. 비전을 쓸 거면 mmproj를 잊지 말 것. Dynamic V3.0이 프리뷰라는 점은 감안한다.
에이전트를 만드는 팀. 벤치표의 에이전트·컴퓨터 조작 항목이 강한 건 사실이지만, 그 표를 도입 근거로 쓰지는 말자. 자기 태스크로 재보는 게 훨씬 빠르다. 붙이기 전에 두 가지를 먼저 확인한다. 사고 모드 기본값이 xhigh라 아무 설정 없이 붙이면 가장 비싼 모드로 돈다는 것, 그리고 preserve_thinking이 기본으로 켜져 있어 멀티턴에서 컨텍스트가 예상보다 빨리 찬다는 것이다.
모델 선택을 검토하는 사람. 경계선은 벤치표가 알려준다. 터미널·파일·브라우저를 조작하는 실행형 작업은 27B로 내려도 될 가능성이 크고, GPQA·HLE 같은 지식·추론 밀도가 높은 작업은 아직 프런티어 모델 쪽이다. 전면 교체가 아니라 작업 유형별 분기가 현실적인 답이다.
아무것도 안 해도 되는 경우. 이미 잘 도는 파이프라인이 있고 비용에 문제가 없다면 오늘 급할 일은 없다. 서드파티 벤치가 나오고 양자화 손실이 측정되는 데 며칠이면 충분하다. 그때 다시 봐도 늦지 않다.