Qwen3.8 27B를 실제로 도입할지 판단하는 조건을 정리했습니다. 262K 네이티브 컨텍스트, 17GB 4bit 실행 요건, Qwen Cloud $0.50/$3.00와 OpenRouter $0.35/$2.75 가격차, xhigh 기본값이 만드는 추론 토큰 폭증까지 2026년 8월 기준 실측 자료로 대조했습니다.
Qwen3.8 27B 핵심만 먼저 정리하면
코딩·에이전트 워크로드를 자체 인프라에서 돌릴 계획이라면 Qwen3.8-27B는 지금 도입해도 되는 후보입니다. 지식 질의응답이나 문서 파싱 위주라면 순위가 내려갑니다. 근거는 자사 벤치마크 표 안에 이미 갈려 있습니다 — SWE-bench Pro 61.7로 Qwen3.7-Plus(57.6)와 Opus4.6 Max(53.4)를 앞서지만, GPQA Diamond는 89.2로 Qwen3.7-Plus 90.3에 밀리고 HLE는 30.8로 Opus4.6 Max 40.0에 크게 뒤집니다(2026-08-25 확인, Hugging Face 모델카드 기준).
도입 판단에서 실제로 발목을 잡는 것은 점수가 아니라 운영 조건입니다. 이 모델은 thinking 모드가 기본이고 reasoning_effort 기본값이 라서, 설정을 그대로 두면 출력 토큰이 비정상적으로 늘어납니다. Artificial Analysis는 인텔리전스 인덱스 52점을 산출하는 데 출력 토큰 160M을 썼습니다. 같은 인덱스의 중위값은 43M입니다. 점수당 비용이 약 네 배 든다는 뜻입니다.
이 글은 Qwen3.8-27B를 도입할 때 확인해야 할 조건을 라이선스·컨텍스트·메모리 요건·가격·서빙 스택 다섯 항목으로 정리한 것입니다. 모델 아키텍처의 학술적 해설이나 파인튜닝 방법은 다루지 않습니다. 모든 수치는 2026년 8월 25일 확인 기준이며, 공식 발표(Tier 1)와 독립 측정(Tier 2)을 구분해 표기했습니다.
Q1. 자체 서빙과 API 호출 중 어느 쪽이 비용상 유리한가요?
단가표만 보면 API가 압도적으로 싸 보이지만, 이 모델에서는 그 계산이 성립하지 않습니다. 먼저 확인된 가격을 정리하면 아래와 같습니다.
| 경로 | 입력 / 1M | 출력 / 1M | 캐시 읽기 | 컨텍스트 | 등급 |
|---|---|---|---|---|---|
| Qwen Cloud | $0.50 | $3.00 | $0.05(explicit) | 1M (입력 991K / 출력 131K) | T1 |
| Qwen Cloud (implicit cache) | $0.10 | — | — | 동일 | T1 |
| OpenRouter | $0.35 | $2.75 | $0.035 | 1M (최대 출력 65,536) | T2 |
| 타 집계 사이트 | $0.45 | $3.20 | — | — | T2(원문 미대조) |
| Qwen3.8-Max 참고 | $2.00 | $6.00 | $0.17 | 1M | T1 |
문제는 출력 단가가 입력의 6~8배인데, 이 모델은 유독 출력 토큰을 많이 쓴다는 점입니다. Simon Willison이 2026년 8월 16일 공개한 로컬 실측에서는 한 과제에 추론 토큰 22,276개를 태워 최종 출력 3,223개를 만드는 데 21분이 걸렸습니다. 추론 토큰도 과금 대상 출력이므로, 실제 청구액은 답변 길이가 아니라 사고 길이에 비례합니다.
자체 서빙 쪽은 라이선스가 Apache-2.0이라 상용 배포 제약이 없고, 4bit 양자화판이 약 17GB로 24GB급 소비자 GPU에 들어갑니다(T2, VentureBeat 보도치). 다만 절감분을 지키려면 reasoning_effort를 으로 내리고 MTP 투기 디코딩을 켜는 것이 사실상 전제조건입니다. --spec-type draft-mtp를 적용하면 LM Studio 기본 GGUF 대비 약 72% 빨랐다는 실측이 있습니다(T2). 반대로 기본값을 방치하면 자체 서빙에서도 GPU 점유 시간이 그만큼 늘어 하드웨어 감가와 전력비로 되돌아옵니다.
판단 기준을 하나로 정리하면 이렇습니다 — 월 호출량이 적고 응답 지연에 여유가 있으면 API, 사내 데이터를 외부로 못 보내거나 호출량이 상시 높으면 자체 서빙입니다. 어느 쪽이든 기본값을 그대로 두는 선택지는 없습니다.
Q2. 컨텍스트 1M이라고 나오는데, 자체 서빙에서도 그대로 쓸 수 있나요?
아니요. 여기서 발표 표기와 실제 운용 조건이 갈립니다. 모델카드가 명시한 네이티브 컨텍스트는 262,144 토큰이고, 1,000,000은 YaRN 같은 RoPE 스케일링을 적용했을 때의 조건부 최대치입니다(T1). 반면 Qwen Cloud와 OpenRouter의 모델 페이지는 둘 다 1M으로 표기하고 있어(2026-08-25 확인), 카탈로그만 보고 파이프라인을 설계하면 자체 서빙 단계에서 어긋납니다.
| 항목 | 발표 표기 | 실제 적용 조건 |
|---|---|---|
| 네이티브 컨텍스트 | 262,144 | 스케일링 없이 그대로 사용 가능 |
| 최대 컨텍스트 | 1,000,000 | RoPE 스케일링 필요 또는 호스팅 전용 |
| Qwen Cloud 표기 | 1M (입력 991K) | 호스팅판 기준 |
| OpenRouter 표기 | 1M / 최대 출력 65,536 | 프로바이더 10곳 경유 |
실측 KV 캐시 용량은 양자화 방식에 따라 크게 벌어집니다. vLLM 공식 레시피의 2×RTX 5090(TP2) 데이터를 보면 FP8은 KV 377,456토큰에 GPU당 14.28GiB, NVFP4(Inferact)는 445,875토큰에 12.02GiB, NVFP4(unsloth)는 920,517토큰에 10.64GiB입니다(T2). 단일 Blackwell NVFP4 구성에서는 24.6GiB로 1M 컨텍스트의 KV 토큰 6.6M을 다루는 수치도 함께 제시돼 있습니다.
주의할 점은 1M 컨텍스트에서 실제로 정확도가 얼마나 떨어지는지는 공식 발표와 독립 측정 모두 확인되지 않았다는 것입니다. 긴 컨텍스트를 전제로 한 설계를 검토한다면 이 부분은 자체 검증 항목으로 남겨야 합니다. 마이그레이션 기준선은 262,144 토큰으로 잡는 편이 안전합니다.
Q3. vLLM으로 올릴 때 미리 알아야 할 실패 지점이 있나요?
있습니다. vLLM 공식 레시피가 알려진 문제로 정리한 항목이 도입 초기 시간을 가장 많이 잡아먹는 지점입니다(T2, 2026-08-25 확인).
| 증상 | 조건 | 대응 |
|---|---|---|
| CUDA graph capture 단계에서 OOM | 단일 RTX 5090 + NVFP4 | 지정 |
| 모델 로드 실패 | MXFP4 양자화 + NVIDIA GPU | 해당 조합 회피 |
| 로딩 오류 | transformers 5.8.0 미만 | 5.8.0 이상으로 업그레이드 |
| 답변 전에 토큰 예산 소진 | reasoning parser 미설정 | parser 설정 필수 |
마지막 항목이 특히 조용히 망가지는 유형입니다. reasoning parser를 설정하지 않으면 추론 블록이 content 필드로 흘러 들어가, 2,048 토큰 예산을 답변에 도달하기 전에 다 써버립니다. 로그상으로는 정상 응답인데 내용이 사고 과정으로만 채워지므로, 벤치마크를 돌려보고 점수가 이상하게 낮게 나오는 형태로 뒤늦게 드러납니다.
MTP 수락률도 양자화별로 다릅니다. FP8 0.771, NVFP4(Inferact) 0.897, NVFP4(unsloth) 0.788입니다(T2). 수락률이 높을수록 투기 디코딩 이득이 커지므로, 메모리 여유와 수락률을 함께 보고 양자화를 고르는 게 맞습니다. 참고로 Ascend 950PR에서는 2,048 토큰 단일 스트림 디코드에 MTP를 켜고 64 tok/s가 측정됐습니다.
샘플링 파라미터는 모드별로 권장값이 다릅니다. thinking 모드는 temperature 1.0 / top_p 0.95 / top_k 20, instruct 모드는 0.7 / 0.80 / 20에 presence_penalty 1.5입니다(T1). 공식 FP8 양자화판이 별도 배포되며 fine-grained fp8, block size 128입니다.
Q4. 속도는 실제로 어느 정도 나오나요? 발표에는 안 나와 있습니다
발표 자료에 속도 지표가 없어서 독립 측정에 의존해야 하는 항목입니다. 그리고 여기가 이 모델의 가장 약한 지점입니다.
| 측정 주체 | 처리량 | 첫 토큰 지연 | 조건 |
|---|---|---|---|
| Artificial Analysis | 52.9 tok/s (138개 중 62위) | 3.04초 | xhigh, 총 평가비 $591.30 |
| BenchLM | 53 tok/s (필드 중위 97) | 40.79초 | 종합 72.5/100, 225개 중 14위 |
| OpenRouter | 최고 48 tok/s | 최저 0.33초 | 프로바이더 10곳, 3일 업타임 100% |
| 로컬(LM Studio) | 15~30 tok/s | — | 17GB Q4_K_M, M5 Max 128GB / DGX Spark |
지능 지표는 상위권인데 속도 순위는 138개 중 62위입니다. BenchLM 측정 처리량 53 tok/s는 같은 플랫폼 필드 중위값 97 tok/s의 절반 수준입니다. 사용자 대면 챗 인터페이스에 붙일 때는 이 격차가 체감 품질을 지배합니다.
첫 토큰 지연은 두 T2 출처가 크게 어긋납니다 — Artificial Analysis 3.04초와 BenchLM 40.79초는 10배 이상 차이인데, 어느 쪽이 어떤 측정 조건이었는지는 확인하지 못했습니다. 측정 설정 차이로 보이지만 단정할 근거가 없으므로 도입 전 자체 환경에서 재측정하는 것이 맞습니다.
VentureBeat는 추론을 켠 상태에서 대안 대비 약 30배 느리고 4.5배 비싸다고 지적하면서, harness가 비교마다 동일하지 않다는 점도 함께 문제 삼았습니다(T2). 실제로 자사 표 각주를 보면 SWE-bench Pro는 Claude Code harness에 256K 컨텍스트·temp 1.0·top_p 0.95, QwenSWEBench는 avg@3에 8시간 타임아웃, MathVision·CharXiv·BabyVision은 코드 인터프리터를 허용한 조건입니다. 벤치마크를 재현할 계획이라면 이 각주 조건을 맞춰야 숫자가 성립합니다.
Q5. Muse Glimmer-30B나 Qwen3.8-Max와 비교하면 어느 쪽을 골라야 하나요?
세 모델이 겨냥하는 자리가 다르므로 워크로드 성격으로 갈라야 합니다.
| 항목 | Qwen3.8-27B | Muse Glimmer-30B | Qwen3.8-Max |
|---|---|---|---|
| 라이선스 | Apache-2.0 | Apache-2.0 | 호스팅 API |
| 파라미터 | 27B dense | 약 29.6B(비전 약 1.8B) | 2.4T-A95B |
| 컨텍스트 | 262,144 (조건부 1M) | 131,072+ | 1M |
| 입력 형식 | 텍스트·이미지·비디오 | 이미지·텍스트 | 텍스트·이미지·비디오 |
| 가격 (입력/출력) | $0.50 / $3.00 | 자체 서빙 | $2.00 / $6.00 |
| 4bit VRAM | 약 17GB | 24GB(17GB판) / 32GB | 해당 없음 |
Muse Glimmer-30B는 컨텍스트가 131,072+로 짧고 비디오 입력이 없지만, 자사 기준으로 RTX 5090에서 DFlash 투기 디코딩 233.4 tok/s를 제시합니다(T1, Meta 모델카드). Qwen의 로컬 실측 15~30 tok/s와 대비하면 응답 지연 측면에서 격차가 큽니다. 반대로 Qwen 자사 표에서 Glimmer의 SWE-bench Pro는 51.2로 Qwen 61.7보다 낮고, OSWorld-Verified도 65.9 대 84.3으로 벌어집니다. 에이전트를 상시 돌려 지연이 중요하면 Glimmer, 긴 문서·비디오·문서 파싱이 걸리면 Qwen 쪽입니다.
Qwen3.8-Max는 같은 계열 상위 모델로 입력 단가가 27B의 4배, 출력이 2배입니다(2026년 8월 25일 기준). HLE 30.8, GPQA Diamond 89.2처럼 27B가 상대적으로 약한 지식 폭 작업만 Max로 라우팅하고 나머지를 27B로 처리하는 분리 구성이 비용상 합리적입니다.
마지막으로 확인이 필요한 항목을 남겨둡니다. 모델카드는 호스팅 서비스를 아직 미출시로 적어두고 있는데(1M 컨텍스트 기본과 공식 내장 툴을 예고), Qwen Cloud 모델 페이지에는 이미 가격이 게시된 상태입니다(2026-08-25 확인). 정식 전환 일자에 대한 공식 발표문은 확인하지 못했습니다. 리전별 가격차, 누적 다운로드 수치도 Tier 1에서 확인되지 않았으므로 단정하지 않겠습니다.
정리
Qwen3.8-27B는 2026년 8월 14일 Apache-2.0으로 공개된 27B dense 멀티모달 모델이고, SWE-bench Pro 61.7·OSWorld-Verified 84.3처럼 코딩·에이전트 지표에서 강세를 보입니다. 반면 GPQA Diamond 89.2와 HLE 30.8은 상위 모델에 밀리고, 처리량 52.9 tok/s는 138개 중 62위입니다. 도입 판단의 실질적 관문은 점수가 아니라 기본값이 만드는 출력 토큰 폭증입니다. reasoning_effort=medium·MTP 투기 디코딩·reasoning parser 설정을 전제하지 않으면 API든 자체 서빙이든 비용 계산이 어긋납니다. 마이그레이션 기준선은 1M이 아니라 262,144 토큰으로 잡고, 첫 토큰 지연과 1M 정확도 저하폭은 자체 환경에서 재측정할 항목으로 남겨두는 편이 안전합니다.
참고 자료
조사 기준일: 2026년 08월 25일
본문의 수치는 아래 자료에서 확인한 것입니다. 제조사 공식 자료(T1)와 전문 매체 실측(T2)을 구분해 표기했습니다. 가격·공급 상황은 변동이 크므로 기준일 이후의 값은 다시 확인해야 합니다.
Tier 1 (모두 2026-08-25 확인)
– Qwen3.8-27B 모델카드: https://huggingface.co/Qwen/Qwen3.8-27B
– 동 README 원본(벤치마크 표·각주): https://huggingface.co/Qwen/Qwen3.8-27B/raw/main/README.md
– FP8 공식 양자화판: https://huggingface.co/Qwen/Qwen3.8-27B-FP8
– QwenLM/Qwen3.8 공식 저장소(릴리스 일자): https://github.com/QwenLM/Qwen3.8
– Qwen Cloud 모델·가격 페이지: https://www.qwencloud.com/models/qwen3.8-27b
– Qwen Cloud Qwen3.8-Max 페이지: https://www.qwencloud.com/models/qwen3.8-max
– Muse Glimmer-30B 모델카드(Meta): https://huggingface.co/meta-models/Muse-Glimmer-30B
Tier 2 (모두 2026-08-25 확인)
– Artificial Analysis — Qwen3.8 27B (xhigh): https://artificialanalysis.ai/models/qwen3-8-27b
– OpenRouter — 가격·프로바이더·실측 처리량: https://openrouter.ai/qwen/qwen3.8-27b
– BenchLM — 종합 순위·카테고리별 점수: https://benchlm.ai/models/qwen3-8-27b
– vLLM 공식 레시피 — 서빙 실측·알려진 문제: https://recipes.vllm.ai/Qwen/Qwen3.8-27B
– Simon Willison, 2026-08-16 — 로컬 실측·과추론: https://simonwillison.net/2026/Aug/16/qwen-38-27b/
– VentureBeat — 메모리 요구량·harness 비일관성 지적: https://venturebeat.com/technology/qwen3-8-27b-runs-frontier-class-coding-agents-and-reasoning-locally-no-cloud-api-required
– alibabacloud.com/blog/…603463 — 본문 회수 실패(빈 응답)
– cybernews.com 다운로드 기사 — HTTP 403
– qwenlm.github.io/blog/ — 2025-09 이후 항목 없음, Qwen3.8 관련 게시물 미확인
답글 남기기