Qwen3.8-Flash-Next 정리: Qwen4 구조를 먼저 공개한 125B 모델

Qwen3.8-Flash-Next는 알리바바 Qwen 팀이 2026년 8월 26일 공개한 125B 멀티모달 MoE 모델이자, 다음 세대인 Qwen4에 쓸 구조를 미리 여는 오픈 웨이트 모델입니다. 완성된 제품을 내놓은 것이 아니라 구조를 먼저 공개해 커뮤니티가 살펴보게 하는 쪽에 가깝습니다.

새 모델 발표에서 먼저 보게 되는 것은 대개 벤치마크 점수입니다. 그런데 이번 공개에서 Qwen 팀이 앞세운 것은 점수가 아니라 비용이었습니다. 같은 일을 더 적은 연산으로 끝내려고 어텐션과 잔차, 임베딩, 최적화 네 군데를 한꺼번에 바꿨습니다. 그 결과를 Qwen4가 나오기 전에 먼저 검증받겠다는 것입니다.

Qwen 공식 블로그와 허깅페이스 모델 카드, Arena 리더보드와 Unsloth 실행 문서를 근거로 2026년 8월 27일 기준으로 정리하겠습니다.

Qwen3.8-Flash-Next 공식 사양

공개된 사양은 다음과 같습니다.

이름이 둘로 나뉘어 있어 헷갈리기 쉽습니다. 가중치를 공개한 실험판이 Qwen3.8-Flash-Next이고, QwenCloud에서 파는 정식판은 컨텍스트 100만 토큰을 기본으로 켜고 내장 도구를 붙인 Qwen3.8-Flash입니다.

라이선스도 함께 봐야 합니다. 같은 시기의 Qwen3.8-27B가 Apache 2.0인 것과 달리 Flash-Next는 qwen-community-1.0이라는 자체 조건을 답니다. 오픈 웨이트라는 말만 보고 두 모델의 이용 조건이 같다고 넘기면 나중에 확인할 일이 생깁니다.

1,250억 개 가운데 60억 개만 쓰는 구조

전문가 혼합(Mixture of Experts, MoE)이라는 구조는 파라미터를 전부 쓰는 일반적인 모델보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 파라미터를 잔뜩 갖춰 두되 토큰 하나를 처리할 때는 그중 일부만 골라 계산하는 방식입니다.

재료를 창고에 가득 쌓아 두고 요리할 때마다 필요한 것만 작업대로 꺼내 오듯, 이 모델은 1,250억 개를 모두 갖고 있으면서 토큰마다 60억 개 분량만 계산에 넣습니다. 창고가 커도 작업대에 올리는 양이 적으면 그만큼 계산도 줄어듭니다. 대신 창고 자체는 어딘가에 있어야 하므로 저장 공간은 큰 모델만큼 듭니다. 로컬 구동에 메모리가 많이 필요한 이유가 여기에 있습니다.

여기에 510억 개짜리 N-gram 임베딩이 따로 붙습니다. 이 부분은 계산에 참여하지 않고 앞뒤 맥락으로 표를 찾아보는 방식이라, 창고 옆방에 색인 서랍을 하나 더 둔 것에 가깝습니다. 공식 문서는 이 서랍을 호스트 메모리로 옮겨 두고 필요할 때 미리 가져오는 방식도 함께 설명합니다.

Qwen4를 미리 여는 네 가지 변경

Qwen 팀은 이번 공개를 Qwen3-Next가 Qwen3.5에 했던 역할과 같다고 밝혔습니다. 그때 내놓은 하이브리드 구조가 이후 Qwen3.5부터 3.8까지 쓰였듯, 이번 변경도 Qwen4 계열의 바탕이 될 예정입니다. 바뀐 곳은 네 군데입니다.

• 어텐션: 네 개 층 가운데 세 개는 Gated DeltaNet으로 지난 내용을 고정 크기 상태에 압축하고, 나머지 한 층만 전체 문맥을 정확히 찾아보는 데 씁니다. 여기에 Qwen Sparse Attention을 더해 문맥을 작은 단위로 나눈 뒤 중요한 부분만 골라 봅니다.
• 잔차: 층마다 정보가 오가는 통로를 하나에서 네 개로 넓히고, 통로마다 얼마나 읽고 쓸지를 그때그때 정합니다. 초반에 만들어진 신호가 뒤로 갈수록 흐려지는 것을 줄이려는 변경입니다.
• 임베딩: 앞서 설명한 N-gram 임베딩으로 계산량을 거의 늘리지 않고 모델이 담는 정보량을 키웁니다.
• 최적화: 학습에 Muon 옵티마이저를 쓰고, 새 구조에 맞춰 스케일링 법칙을 다시 맞췄습니다.

이 변경들이 겨냥한 것은 점수보다 비용입니다. 공식 발표는 이전 세대인 Qwen3.7-Plus와 견줘 학습에 든 비용이 약 9분의 1이면서 코딩과 사무 작업에서는 더 나은 결과를 냈다고 밝혔습니다.

컨텍스트가 길수록 벌어지는 처리량 차이

위 그래프는 Qwen 팀이 공개한 처리량 측정입니다. 캐시 적중률 90%라는 실제 서비스에 가까운 조건에서 이전 세대를 1배로 놓고 잰 값입니다.

읽을 때 중요한 것은 곡선의 모양입니다. 16K 컨텍스트에서는 2.1배로 시작하지만 100만 토큰에서는 8.6배까지 벌어집니다. 긴 문맥을 다룰수록 이득이 커지는 구조라는 뜻이고, 반대로 짧은 질문을 주고받는 작업이라면 이 차이가 크게 느껴지지 않습니다. 어텐션 커널만 따로 재면 100만 토큰에서 프리필 7.6배, 디코드 4.9배의 속도 향상이 나왔습니다.

저장소 전체를 넣고 코드를 고치거나 긴 문서를 통째로 읽게 하는 작업이라면 이 특성이 그대로 비용으로 돌아옵니다. 짧은 대화가 대부분인 서비스라면 응답 속도나 단가를 기준으로 고르는 편이 맞겠습니다.

공식 벤치마크와 27B의 Arena 성적

Qwen 팀이 공개한 자체 측정 가운데 코딩과 에이전트 항목은 다음과 같습니다.

눈에 띄는 것은 SWE-bench Pro입니다. 125B인 Flash-Next가 62.5, 27B가 61.7로 차이가 0.8에 그칩니다. 다만 DeepSWE 1.1에서는 58.7 대 42.2로 크게 벌어지므로, 항목에 따라 두 모델의 거리가 달라진다고 보는 편이 정확합니다. 만든 곳이 직접 고른 항목과 조건이라는 점도 함께 두고 봐야 합니다.

만든 곳이 아닌 쪽의 측정으로는 Arena의 사람 투표 결과가 있습니다.

위 화면은 2026년 8월 22일 집계 기준 Arena의 Code WebDev 리더보드에서 참고 이미지를 보고 화면을 만드는 카테고리를 열고 오픈소스만 걸러낸 결과입니다. Qwen3.8-27B가 1,614점으로 오픈 모델 가운데 3위, 전체 117개 모델 가운데 9위에 있습니다.

이 성적을 어떻게 읽을지는 무엇과 견주느냐에 따라 달라집니다. 앞에 있는 모델들이 대부분 훨씬 큰 규모라는 점을 놓고 보면, 27B 크기로 상위 10위 안에 든 것은 눈여겨볼 만합니다. 다만 오픈 모델 중 1위는 아니고, 같은 표에서 Z.ai의 GLM-5.3 계열이 앞서 있습니다.

로컬에서 돌리는 데 필요한 메모리

가중치가 공개됐으니 자기 장비에서 돌리는 것도 선택지가 됩니다. Unsloth가 정리한 양자화별 메모리 요구량은 다음과 같습니다. 단위는 램과 VRAM을 합한 값이거나 통합 메모리 용량입니다.

가장 작은 1비트가 75GB이고 문서는 96GB 기기를 권합니다. 1비트치고 용량이 큰 이유는 앞서 본 N-gram 임베딩 때문인데, 그만큼 양자화를 덜 세게 밀어붙여 원래 정확도를 더 남긴다는 설명이 함께 붙습니다.

한 가지 특이한 점이 있습니다. 보통은 GPU 메모리에 올리지 못하면 속도가 크게 떨어지는데, 이 구조는 램이나 통합 메모리로 돌려도 GPU 메모리에 가까운 속도가 나온다고 합니다. 문서가 맥이나 대용량 메모리 기기를 따로 언급하는 이유입니다. 다만 이것은 만든 쪽과 도구 쪽의 설명이고, 실제 속도는 기기마다 다르게 나올 수 있습니다.

메모리 24GB짜리 맥에서 27B를 돌렸을 때 어떤 일이 벌어지는지는 Qwen3.8 27B 로컬 실행 기록에 실측으로 정리해 두었습니다. 27B도 24GB에서는 GPU에 올라가지 못했으니, 125B를 로컬로 옮기는 계획이라면 메모리부터 확인하는 편이 안전합니다.

실무에서 확인할 순서

• 라이선스를 모델별로 따로 확인합니다. Qwen3.8-27B는 Apache 2.0이지만 Flash-Next는 qwen-community-1.0입니다. 상업적으로 쓸 계획이면 조건을 먼저 읽습니다.
• 평소 쓰는 컨텍스트 길이를 재 봅니다. 처리량 이득이 16K에서 2.1배, 100만 토큰에서 8.6배로 벌어지므로 짧은 요청만 다루는 서비스라면 이 모델을 고를 이유가 줄어듭니다.
• 로컬로 옮길지 API로 쓸지 메모리로 판단합니다. 1비트라도 75GB가 필요하고 권장은 96GB입니다. 이 조건을 넘기지 못하면 100만 토큰당 입력 0.16달러인 API 쪽이 현실적입니다.
• 27B와 Flash-Next를 항목별로 견줍니다. SWE-bench Pro에서는 차이가 0.8에 그쳤지만 DeepSWE에서는 16.5가 벌어졌습니다. 쓰려는 작업에 가까운 항목을 골라 확인합니다.

Qwen3.8-Flash-Next를 API로 쓰려면 모델 이름을 무엇으로 적나요?

QwenCloud에서는 qwen3.8-flash로 부릅니다. 가중치를 내려받아 쓸 때의 이름인 Qwen3.8-Flash-Next와 달라서 문서를 찾을 때 헷갈리기 쉽습니다. API는 OpenAI 호환 형식과 Anthropic 호환 형식을 모두 받으므로 기존 코드에서 모델 이름과 주소만 바꿔 붙일 수 있습니다. 추론 강도는 xhigh, medium, low로 조절하는데 기본값이 xhigh라 추론을 길게 합니다. 출력 토큰과 응답 시간을 줄이려면 낮춰서 재 보는 편이 좋습니다.

Qwen3.8-27B와 Flash-Next 가운데 무엇을 고르는 편이 나을까요?

작업의 성격과 실행 환경이 기준입니다. 자기 장비에서 돌릴 생각이라면 27B 쪽이 현실적입니다. Flash-Next는 1비트로 줄여도 75GB가 필요하지만 27B는 그보다 훨씬 작고 라이선스도 Apache 2.0으로 느슨합니다. 반대로 긴 문맥을 다루거나 오래 걸리는 에이전트 작업을 API로 돌린다면 Flash-Next가 맞습니다. 코드 수정 능력을 재는 DeepSWE에서 두 모델의 차이가 16.5까지 벌어졌으므로, 저장소를 읽고 고치는 작업이 많다면 이 항목을 기준으로 삼는 방법도 있습니다.

Sources:

• Qwen3.8-Flash-Next 공식 발표 (Qwen)
• Qwen/Qwen3.8-Flash-Next 모델 카드 (Hugging Face)
• Code Arena WebDev 리더보드 (Arena)
• Qwen3.8-Flash-Next 로컬 실행 문서 (Unsloth)