
Qwen 4 QSA, 디코드 컨텍스트 병렬화 지원: vLLM의 Qwen3.8-Flash-Next 초안 PR 살펴보기
- typesafeNEWTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 100만 토큰당 · 397 tok/s
- OpenAINEWOpenAI: GPT-6 Luna2026-09-2237지능
- OpenAINEWOpenAI: GPT-6 Sol2026-09-2248지능
- AnthropicNEWAnthropic: Claude Opus 5.52026-09-2258지능
- xAINEWGrok 4.72026-09-2146지능
- OrcaNEWOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 100만 토큰당 · 195 tok/s
- OrcaNEWOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 100만 토큰당 · 1136 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040지능
- OpenAIOpenAI: GPT-6 Astra2026-09-0453지능77코딩
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241지능76코딩
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245지능76코딩
- AnthropicAnthropic: Claude Fable 5.12026-09-0153지능82코딩
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 100만 토큰당 · 51 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 100만 토큰당 · 106 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642지능72코딩
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 100만 토큰당 · 220 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845지능75코딩
- obsidianQwen3.8 27B2026-08-1534지능68코딩
- DeepSeekDeepSeek: DeepSeek V4 Pro 08132026-08-1236지능69코딩
- xAISpaceXAI: Grok 4.62026-08-1244지능77코딩
2026-09-29, vLLM 저장소에 “[Model][DCP] Support Qwen4Exp QSA”라는 제목의 초안 풀 리퀘스트가 올라왔고, 그것이 설명하는 모델에 관해 이번 달 누구든 공개한 것 중 가장 구체적인 서빙 수치를 담고 있습니다. 4개 GPU에서 Qwen3.8-Flash-Next를 짝지어 실행한 결과 KV 토큰 용량은 9,759,529에서 17,603,636으로, 최대 동시성은 37.23×에서 67.15×로, 첫 토큰까지의 시간은 1,869ms에서 767ms로 단축되었습니다. Qwen3.8-Flash-Next는 Hugging Face 카드에서 “A Preview of the Qwen4 Architecture”라고 설명하는, 오픈 가중치 1,250억 매개변수 전문가 혼합(MoE) 미리보기이며, 이 풀 리퀘스트는 해당 아키텍처의 기반이 되는 희소 어텐션 경로에 디코드 컨텍스트 병렬성을 추가합니다. Qwen4 자체, 즉 벤더가 2026-09-22 아프사라 콘퍼런스에서 이름을 밝힌 Qwen4 Max, Flash, Plus 및 27B 등급은 아직 출시되지 않았으며, 가중치도, 식별자도, 가격도, 날짜도 없습니다. 그러니 이것을 있는 그대로 읽으십시오. 출시도, 벤치마크도 아니라, Qwen4 제품군이 존재하기 전에 Qwen4 서빙 범위가 어떻게 넓어지고 있는지 알려주는 엔지니어링 산출물입니다.
이 글은 지금까지 알려진 바를 정리한 글입니다. 그리고 출처 확인은 평소보다 더 중요합니다. 이 풀 리퀘스트는 초안이며, 열려 있고, 병합되지 않았습니다 — vllm-project/vllm#59279는 2026-09-29에 NVIDIA 소프트웨어 엔지니어인 Sungsoo Ha가 열었으며, 여전히 초안 상태에 머물러 있습니다. 아래의 모든 수치는 동일 작업의 이전 리비전에서 측정되어 PR 본문에 보고된, 저자가 짝지어 측정한 값입니다. 여기 어떤 것도 독립적으로 감사되지 않았고, 어떤 것도 릴리스에 포함되지 않았으며, 저자가 덧붙인 주의 사항은 충분히 중대하여 아래에서 별도 섹션을 차지합니다.
pull request가 실제로 변경하는 내용
Decode context parallelism — DCP —는 모델 변경이 아니라 서빙 기법입니다. 하나의 GPU 그룹이 전체 KV 캐시를 보유하는 대신, DCP는 그 캐시를 랭크 전반에 분할하므로 각 랭크는 컨텍스트에서 자신의 조각만 읽고, 어텐션 결과는 마지막에 랭크 전반에 걸쳐 결합됩니다. 핵심은 용량입니다. 캐시가 분할되면 배포는 동일한 하드웨어에서 훨씬 더 많은 동시 긴 컨텍스트 트래픽을 감당할 수 있으며, 이는 모든 요청이 25만 개의 토큰을 운반할 때 바로 발목을 잡는 제약입니다.
문제는 Qwen Sparse Attention — QSA —는 일반적인 어텐션 레이어가 아니라는 점입니다. Qwen3.8-Flash-Next 모델 카드에 명시된 대로, 경량 인덱서가 키를 압축 비율 4로 마이크로 블록으로 압축하고 점수를 매긴 다음, 가장 좋은 512개 블록, 대략 2,048개 토큰 위치를 유지하는 반면, 최종 소프트맥스와 값 집계는 여전히 압축되지 않은 K와 V에서 실행됩니다. 이는 QSA가 KV 캐시보다 더 많은 상태를 갖는다는 뜻입니다. 메인 캐시가 있고, 인덱서가 유지하는 셀렉터 및 사이드 캐시도 있습니다. vLLM의 일반 DCP 구현은 이 중 어느 것도 알지 못합니다.
#59279가 설명에 따르면 하는 일은 DCP에게 QSA 관련 부분들을 알려주는 것입니다:
• 각 랭크는 메인 KV 캐시에서 자신의 부분을 읽지만, QSA의 선택기와 사이드 캐시는 복제된 상태로 랭크 전반에 유지되며 샤딩되지 않습니다.
• 분할 읽기 후 어텐션 결과가 랭크 간에 결합됩니다.
• 선택자와 메인 KV 캐시는 하나의 캐시 그룹에 함께 유지되므로 서로 어긋날 수 없습니다.
• 합성 V2 배치는 QSA 사이드 캐시에 기록하지 못하도록 방지됩니다.
![A capture of the vLLM GitHub pull request #59279, titled '[Model][DCP] Support Qwen4Exp QSA', showing an Open state with a Draft badge, the head branch sungsooha:n4/qsa-dcp-clean-20260929, the description of how decode context parallelism is enabled for Qwen4Exp QSA, and the labels kv-cache-manager, mrv2, speculative-decoding, dflash, nvidia, qwen and ci/build.](https://cms.orcarouter.ai/api/media/file/2-1437.png)
그 마지막 두 세부 사항은 처리량보다 정확성을 중시한다면 흥미로운 부분입니다. 복제된 셀렉터와 조용히 불일치하는 샤딩된 어텐션 캐시는 긴 컨텍스트에서 크래시가 아니라 느린 정확도 저하로 나타나는 유형의 버그이며, 이 변경은 둘을 동기화 상태로 유지하는 점을 분명히 밝히고 있습니다. 저자는 또한 AI 지원이 사용되었으며 Codex가 공동 저자로 명시되었다고 밝힙니다 — 이런 형태의 초안 PR에서는 누가 무엇을 썼는지 묻는 것이 타당한 질문이기 때문에, 이 점을 솔직히 말하는 것은 가치가 있습니다.
쌍을 이룬 숫자들과 그것들이 어떻게 얻어졌는지
테스트 계획은 검증할 수 있을 만큼 구체적이며, 그래서 그 결과는 인용할 가치가 있다. 두 arm 모두 4개의 GPU에서 텐서 병렬 처리 4와 전문가 병렬 처리를 활성화한 상태로 Qwen/Qwen3.8-Flash-Next-FP8을 서빙하며, --gpu-memory-utilization 0.90에 프리픽스 캐싱을 켠 상태이다. 두 arm 사이의 유일한 차이는 --decode-context-parallel-size이다: DCP=1일 때는 생략하고, DCP=2일 때는 2로 설정하며, arm 사이에 재시작하여 벤치마크가 콜드 캐시에서 시작되도록 한다. 부하는 128명의 사용자로 900초 동안 실행되는 AgentX 256k 트레이스이고, 정확도는 GSM8K용 EvalScope와 리포지토리에 체크인된 MRCR 평가기로 측정하며, arm당 6회 실행하되 재시작 후 첫 번째 실행은 버린다.
보고된 처리량 차이, DCP=2 대 DCP=1:
• KV 토큰 — 9,759,529 vs 17,603,636, 캐시 용량이 1.80배 증가했습니다.
• 최대 동시성 — 37.23× 대 67.15×, 또한 1.80×.
• 초당 요청 수 — 1.69 vs 2.30, 1.36×.
• 초당 입력 토큰 — 128,730 vs 179,702, 1.0×.
• 첫 토큰까지 걸리는 시간 — 1,869ms 대 767ms, 2.44배 더 낮습니다.
• 토큰 간 지연 시간 — 43.48 ms vs 26.27 ms, 1.66배 낮음.
• 정상 상태에서의 프리픽스 캐시 적중률 — 67.85% 대 88.98%, 21.1퍼센트 포인트 향상.

정확도는 워밍업 이후 실행 전반에 걸쳐 평균 ± 표본 표준편차로 보고되었으며, 사실상 평평했다: MRCR 집계값은 DCP=1에서 0.8630 ± 0.0005, DCP=2에서 0.8697 ± 0.0153이었고, GSM8K는 0.9788 ± 0.0020 대 0.9790 ± 0.0016이었다. 2-needle 및 4-needle MRCR 샘플은 두 실험군 모두에서 0.9960과 0.9906으로 고정되어 있었으므로, 실행 간 변동은 전부 8-needle 샘플에서 비롯되었다. 그리고 DCP=2 집계 실행 하나는 0.8970을 기록한 반면 나머지 네 번은 0.8620에서 0.8632 사이에 머물렀다. 이는 휙 넘겨버릴 수 있는 잡음이 아니라 실제 산포이며, PR에는 이를 뭉개지 않고 그대로 명시했다.
이 숫자들이 입증하지 못하는 것
주의사항은 PR 텍스트에 있으며 결코 사소하지 않습니다. 짝을 이룬 AgentX 및 정확도 결과는 이전 QSA DCP 리비전에서, 커밋 3df4ae153eb을 기반으로 한 vLLM nightly를 사용해 측정되었습니다. 풀 리퀘스트의 최종 클린 커밋에는 이후의 QSA 로컬라이제이션 커널 수정이 포함되어 있으며 집중적인 B200 검증을 통과했습니다. 그러나 전체 AgentX 및 정확도 평가는 바로 그 소스에서 반복되지 않았습니다. 다시 말해: 처리량 이야기와 배포된 diff는 동일한 산출물이 아니며, 작성자도 그렇게 말합니다.
그 외에도 일반적인 원칙이 적용되며, 여기서는 그 원칙이 특히 엄격하게 적용됩니다. 이 수치들은 단일 기여자가 단일 4-GPU 환경에서 측정한 단일 구성 수치입니다. 이는 중립적이라기보다는 벤더에 가깝습니다. 프레임워크 기여자가 프레임워크 변경을 측정하는 것은 정상적이고 유용한 일이지만, 독립적인 감사는 아니며 제3자가 이 실행을 재현한 적도 없습니다. 이 변경은 아직 병합되지 않았기 때문에, 오늘 설치할 수 있는 출시된 vLLM 버전 중 이 변경을 포함한 버전은 없습니다. 그리고 DCP=2는 하나의 특정 셰이프를 양방향으로 분할한 것입니다. 여기서 나온 델타는 DCP=4나 DCP=8이 어떻게 동작할지에 대한 약속이 아니며, PR 어디에도 그렇다고 주장하는 내용은 없습니다.
아직 공개되지 않은 아키텍처에 관한 서빙 PR이 여전히 시간을 들일 가치가 있는 이유
당연한 반론이 있다: 제목에 있는 모델은 존재하지 않는데, 왜 신경 써야 할까? 왜냐하면 튜닝되는 대상은 Qwen 4가 아니기 때문이다. 그것은 Qwen3.8-Flash-Next이며, 그 모델은 실제로 존재한다 — 알리바바가 2026-08-24에 125B 파라미터 MoE로 공개했는데, 6B가 활성화되고, 510억 파라미터 n-gram 임베딩 테이블, 추측 디코딩용 4B MTP 헤드, 3개의 Gated DeltaNet 블록을 12회 반복한 뒤 1개의 QSA 블록이 이어지는 구성으로 배열된 48개 레이어, 10개가 라우팅되고 1개가 공유되어 활성화되는 512개 전문가, 그리고 카드에 따르면 1,000,000까지 확장 가능하다고 하는 262,144 토큰의 네이티브 컨텍스트를 갖추고 있다. 이는 오픈 가중치로 공개된 Qwen4 아키텍처의 참조 구현이며, QSA — 이 풀 리퀘스트가 DCP로 하여금 샤딩하도록 가르치는 마이크로 블록 희소 어텐션 — 는 그중 단연 가장 독특한 부분이다.
숫자들이 설명하는 것은 그 262K 컨텍스트를 하나의 GPU 그룹이 통째로 들고 있어야 하는 대상으로 취급하지 않을 때 벌어지는 일이다. KV 토큰 용량과 동시성에서의 1.80배 도약은 캐시를 둘로 쪼개는 산술이며, 이 목록에서 가장 놀랍지 않은 결과다. 더 흥미로운 수치는 지연 시간 관련 수치들이다: 동일한 제공 부하에서 첫 토큰까지 걸리는 시간은 2.44배 더 짧고 토큰 간 지연 시간은 1.66배 더 낮으며, 정상 상태 프리픽스 캐시 적중률은 21포인트 개선됐다. 이는 DCP 경로가 지연 비용을 치르고 용량을 사는 데 그치지 않는다는 뜻이다 — 이 짝지어진 실행에서는 둘 다를 얻었다. 바로 이것이 매우 긴 시스템 프롬프트로 에이전트 트래픽을 서비스하는 누구에게나 중요한 변화의 형태다. 왜냐하면 긴 컨텍스트에서의 프리픽스 캐시 동작은 대개 장문 컨텍스트 처리량이 조용히 무너지는 지점이기 때문이다.
그리고 이것은 고립된 패치가 아니다. 같은 주에 Qwen4Exp 엔진 작업이 한 묶음 나왔다. #59214는 B200 형상용 SM100 저지연 디코드 GEMM 플랜을 추가하고, #59010은 Hopper의 QSA 경로를 위한 SM90 네이티브 스파스 프리필 커널을 추가하며, #58977은 BF16 INC PLE 임베딩을 다루고, 그리고 #58961 — 2026-09-28에 실제로 병합된 — 은 QSA 키 뷰가 계속 살려 두던 프로파일링 KV 캐시를 수정했다. 함께 읽으면, 이것들은 Qwen4 아키텍처가 대중 앞에서, 런타임에서, 패밀리가 출시되기 몇 달 전에 구축되고 있는 서빙 엔벨로프다. Qwen 4를 계획하고 있다면, 유용한 신호는 출시일이 아니다 — 출시일은 없다 — 그것은 커널과 캐시 레이아웃이 여러분이 이를 어떻게 서빙해야 할지에 대해 이미 전제하고 있는 내용이다.
오늘 전화할 수 있는 것
이 PR이 다루는 아키텍처에서 롱컨텍스트(long-context) 동작을 테스트해 보고 싶다면, 선택해야 할 모델은 알리바바가 실제로 서비스하는 Flash 티어입니다. Qwen3.8-Flash — Qwen3.8-Flash-Next를 기반으로 구축된, 1,000,000 토큰 컨텍스트와 131,072 토큰 최대 출력을 갖추고 텍스트, 이미지, 동영상 입력을 받는 프로덕션 배포 — 는 현재 라이브 상태이며, 그것은 오늘날 Qwen4Exp 아키텍처를 실제로 구동하는 모델을 위한 하나의 엔드포인트, 등록명 qwen/qwen3.8-flash, 가격은 입력 토큰 100만 개당 $0.15, 출력 토큰 100만 개당 $0.47, 캐시 읽기는 $0.0184입니다. 이는 저희 측에서 마크업 없이 그대로 전달되는 제공업체 정가이므로, 해당 모델의 가격이나 한도가 변경되면 발표되는 당일 여러분께 그대로 전달됩니다.

두 가지 솔직한 유보 사항이 있습니다. 첫째, Qwen3.8-Flash-Next 자체 — 풀 리퀘스트의 테스트 계획에 있는 FP8 가중치, 즉 이러한 측정값 중 어느 것이든 로컬에서 재현하려면 필요한 것들 — 은 우리 카탈로그에 없습니다. 서빙되는 Flash 티어는 QwenCloud 프로덕션 라인이지, 원시 프리뷰 체크포인트가 아닙니다. PR의 정확한 구성을 실행하려면 4개 GPU에서 자체 호스팅하는 것입니다. 둘째, DCP 변경 사항은 병합되지 않았으므로 오늘 어디서든 호출할 수 있는 어떤 것도 그것을 실행하고 있지 않습니다. 서빙 티어가 여러분에게 주는 것은 여러분의 워크로드가 DCP가 해결하는 문제에 맞는 형태이기는 한지 알아내는 방법입니다: 프롬프트가 길고, 에이전트형이며, 프리픽스가 있는 편이라면, 1.80× 용량과 프리픽스 캐시 델타가 여러분 자신의 트레이스에서 주목해야 할 수치입니다.
그리고 만약 당신에게 흥미로운 부분이 하나의 모델이 아니라 전환 문제 — Qwen 4 라인업이 아직 이름조차 없을 때 어느 티어를 기반으로 구축할지 하는 문제 — 라면, 그것은 서빙 문제가 아니라 라우팅 문제이며, 200개 이상의 모델을 위한 단일 API가 바로 그 패밀리가 마침내 출시되었을 때 두 번째 계약이나 코드 변경 없이 선택지를 열어둘 수 있는 방법입니다.
직접 답변할 가치가 있는 질문들
#59279는 Qwen 4가 출시된 걸 의미하나요, 아니면 곧 출시된다는 건가요?
아니요. 이 풀 리퀘스트는 Alibaba가 2026-08-24에 출시한 Qwen3.8-Flash-Next에 구현된 Qwen4Exp 아키텍처에 관한 것입니다. Qwen 4 제품군 — Max, Flash, Plus, 27B — 은 2026-09-22 Apsara 무대에서 이름이 공개되었고, 후속 라인이 5조~10조 파라미터로 예상되는 회사 로드맵에 올라갔지만, 여전히 모델 카드도, 가중치도, API 식별자도, 컨텍스트 윈도도, 가격도, 날짜도 없습니다. 프리뷰 아키텍처에 병렬화 모드를 추가하는 프레임워크 PR은 Qwen 4를 잘 서빙하기 위한 한 걸음입니다. Qwen 4가 존재하게 만들기 위한 한 걸음은 아닙니다.
디코드 컨텍스트 병렬 처리(parallelism)는 텐서 병렬 처리와 어떻게 다른가요?
이 둘은 서로 다른 것을 나누고 서로 다른 방식으로 실패합니다. 텐서 병렬 처리(TP)는 각 계층의 가중치와 연산을 여러 GPU에 분할하므로, 모든 랭크가 모든 토큰에 참여하되 전체 시퀀스를 보게 됩니다. 디코드 컨텍스트 병렬 처리(DCP)는 KV 캐시 자체를 분할하므로, 각 랭크는 컨텍스트의 일부 슬라이스만 보유하고 읽으며, 부분 어텐션 결과는 나중에 병합됩니다. TP는 모델을 담는 문제이고, DCP는 컨텍스트와 그 위에 실리는 동시 트래픽을 담는 문제입니다. 바로 이 차이 때문에 이 PR이 사소하지 않은 것입니다. QSA의 선택기와 사이드 캐시는 메인 KV 캐시처럼 단순히 샤딩할 수 없으므로, 이 변경은 하나는 샤딩하고 나머지는 복제한 다음, 둘이 일관성을 유지한다는 것을 증명해야 합니다.
오늘 호스팅 API를 통해 Qwen3.8-Flash-Next를 호출하면 이 수치를 이미 얻을 수 있나요?
아니요, 그리고 그 격차에는 세 부분이 있습니다. 그 변경은 아직 병합되지 않았으므로, 이를 포함하는 출시된 vLLM 빌드는 없습니다. 일단 병합되더라도, 제공자가 그 빌드를 채택하고 DCP 크기를 1보다 크게 설정해 실행하기로 선택해야 합니다 — 이는 기본값이 아니라 서빙 구성입니다. 그리고 측정된 델타는 최종 커밋이 아니라 패치의 이전 리비전에서 나온 것이며, 작성자는 지금까지 집중적인 B200 검증만 수행했다고 밝혔습니다. 보고된 델타는 이 접근 방식이 한 구성에서 얻는 것에 대한 잘 문서화된 상한으로 간주해야 하며, 이번 주에 임대할 수 있는 어떤 엔드포인트의 사양으로 간주해서는 안 됩니다.
열린 질문
주목할 것은 이 특정 초안이 병합되는지 여부가 아니다 — 아마 어떤 형태로든 병합될 것이다. 왜냐하면 그것이 추가하는 QSA 특정 캐시 처리는 선호가 아니라 진정한 공백이기 때문이다. 주목할 것은 최종 커밋이 중간 리비전이 받은 것과 동일한 짝지은 평가를 받는지 여부이다. 처리량 주장은 한 빌드에서 나오고 정확성 주장은 다른 빌드에서 나오는 서빙 변경은 현재로서는 측정된 결과라기보다는 잘 논증된 제안이며, 8-needle MRCR 샘플에서의 정확도 편차는 출시된 소스에서 실행을 반복하는 것이 누구든 그것에 대해 발표할 수 있는 가장 유용한 단일 작업이 될 만큼 충분히 크다. 그때까지는: 방향은 읽을 수 있고, 원장은 닫히지 않았으며, 오픈 가중치에서 유일한 Qwen4 아키텍처 모델은 여전히 8월의 것이다.
