Qwen3.8-Max - 2.4T MoE에 활성 95B, PaperBench에서 프런티어를 앞선 빌드

🏷️ 정보 LLM 벤치마크 에이전트

알리바바 Qwen 팀이 2026년 8월 3일 Qwen3.8-Max를 공개했습니다. 총 2.4조 파라미터 MoE이고 요청당 950억 개만 활성화합니다.

발표 자료의 벤치마크 표를 그대로 읽으면 "프런티어급"이라는 결론이 나옵니다. 그런데 표를 항목별로 뜯으면 이야기가 달라집니다.

벤치마크

벤치마크

Qwen3.8-Max

GPT-5.6 Sol

Claude Fable 5

Claude Opus 4.8

Terminal-Bench 2.1

86.6

88.8

84.6

84.6

SWE-bench Pro

67.7

64.6

80.0

69.2

FrontierSWE

73.5

-

88.8

70.0

PaperBench

93.0

90.5

88.8

80.3

Terminal-Bench에서는 Claude Opus 4.8과 Claude Fable 5(둘 다 84.6)를 앞서고 GPT-5.6 Sol(88.8)에 뒤집니다. 2.2점 차이라 실질적으로 붙어 있습니다.

문제는 SWE-bench Pro와 FrontierSWE에서 Claude Fable 5에게 밀린다는 점입니다. 67.7 대 80.0, 73.5 대 88.8입니다. 12점, 15점 차이면 붙어 있다고 말하기 어렵습니다. 다만 이 열세는 Fable 5에 한정됩니다. SWE-bench Pro에서는 GPT-5.6 Sol(64.6), Opus 4.8(69.2) 모두 Qwen3.8-Max(67.7)보다 낮고, FrontierSWE에서도 Opus 4.8(70.0)을 근소하게 앞섭니다. 실제 저장소에서 이슈를 받아 패치를 만드는 과제 전반이 아니라, Fable 5라는 특정 모델에게만 확실히 밀립니다.

그런데 PaperBench 하나만 뒤집힙니다. 93.0으로 Sol(90.5), Fable 5(88.8), Opus 4.8(80.3)을 전부 앞섭니다.

비대칭

이 비대칭이 이 모델의 진짜 이야기입니다.

PaperBench는 논문을 주고 그 결과를 처음부터 재현하게 하는 벤치마크입니다. 논문 본문에서 설정을 읽어내고, 실험 코드를 새로 짜고, 보고된 수치에 도달해야 합니다. 긴 문서 이해와 사양대로 구현하는 능력이 주로 걸립니다.

SWE-bench Pro와 FrontierSWE는 다릅니다. 남이 쓴 저장소의 코드베이스를 탐색하고, 어디가 문제인지 찾아내고, 주변 코드 관례에 맞춰 최소한으로 고쳐야 합니다. 기존 코드와의 정합성이 걸립니다.

Qwen3.8-Max가 앞서는 곳은 사양을 읽고 새로 짓는 쪽이고, 밀리는 곳은 남의 코드에 들어가 고치는 쪽입니다. 이건 학습 데이터와 포스트트레이닝 설계가 어디에 무게를 실었는지를 보여줍니다. 논문 재현 계열 데이터는 합성하기 쉽고 정답 판정도 명확합니다. 실제 저장소의 이슈-패치 쌍은 그렇지 않습니다.

에이전트로 쓸 때 이 차이는 실무에서 바로 드러납니다. 사양서를 주고 새 모듈을 만들게 하는 작업에는 강하고, 레거시 코드베이스에 붙여 버그를 잡게 하는 작업에는 약할 가능성이 큽니다.

희소도

총 2.4T에 활성 95B이면 희소도가 약 4%입니다. MoE 설계에서 이 비율은 서빙 비용과 직결됩니다.

토큰당 계산량은 활성 파라미터에 비례하므로 95B 밀집 모델 수준입니다. 반면 메모리에는 2.4조 개 전부가 올라가 있어야 합니다. 라우터가 어느 전문가를 고를지 미리 알 수 없기 때문입니다.

그래서 이 설계의 이득은 지연시간에서 나오고 비용은 메모리에서 나갑니다. 배치를 크게 묶어 돌리는 클라우드 사업자에게는 유리한 트레이드오프입니다. 요청이 많으면 서로 다른 전문가들이 고루 쓰이므로 메모리에 올려둔 파라미터가 놀지 않습니다.

반대로 개인이나 소규모 팀이 자체 서빙하기에는 최악의 형태입니다. 2.4조 개를 올려둘 메모리를 확보해도 요청이 드문드문 들어오면 대부분의 전문가가 놀고 있습니다. 밀집 95B 모델을 돌리는 것과 품질은 비슷한데 하드웨어 비용은 수십 배입니다.

클라우드 선출시

공개 순서도 이 구조와 맞물립니다. 현재는 QwenCloud로만 제공하고, 가중치는 다음 주에 HuggingFace와 ModelScope에 올린다고 예고했습니다.

오픈웨이트 모델이 클라우드 API를 먼저 여는 순서는 요즘 흔해졌습니다. 이유는 몇 가지가 겹칩니다.

발표 시점에 벤치마크 수치를 검증할 수 있는 창구가 자사 API뿐이면, 초기 여론이 자사가 제시한 표를 중심으로 형성됩니다. 서드파티가 독립적으로 재현해 반박 수치를 내놓기까지 시간이 벌립니다.

그리고 앞서 본 희소도 구조를 감안하면, 가중치를 받아도 개인이 제대로 돌리기 어렵습니다. 오픈웨이트로 공개하되 실질적인 서빙 수요는 자사 클라우드로 오게 되는 구조입니다. 라이선스를 열어두는 것과 실제로 남이 돌릴 수 있게 하는 것은 다른 문제입니다.

이건 Qwen만의 이야기가 아닙니다. 오픈웨이트 프런티어 모델이 커질수록 "공개"의 실질적 의미가 옅어집니다. 가중치가 공개돼 있어도 그것을 돌릴 수 있는 곳이 하이퍼스케일러뿐이라면, 검증 가능성 측면에서는 닫힌 모델과 크게 다르지 않습니다.

정리

멀티모달 36개를 포함한 벤치 표가 붙어 있지만, 이 모델에서 실제로 읽어야 할 것은 SWE 계열과 PaperBench의 갈림입니다. 사양대로 새로 짓는 데 강하고 남의 코드에 들어가 고치는 데 약합니다.

다음 주 가중치 공개 후 서드파티 재현 수치가 나오면 이 비대칭이 진짜인지 표 구성의 결과인지 갈릴 것 같습니다. 특히 SWE-bench Pro에서 Fable 5와의 12점 차이가 어떻게 나오는지가 확인 지점입니다.

출처: Qwen3.8-Max: A New Bar for Coding and Cowork, MarkTechPost 정리