Qwen 4 유출: SGLang의 Host-Staging PR이 47.7 GiB PLE 테이블이 단일 GPU에 들어가는 방법을 보여준다

Qwen 4가 직접 서빙할 수 있는 모델인지 결정할 숫자는 Qwen 4의 파라미터 수가 아니다. 그것은 47.7 GiB다 — Qwen4 아키텍처와 나란히 딸려 오는 n-gram 임베딩 테이블의 크기로, 가중치와는 별개이며, 모델이 디코딩하는 동안 어딘가에 존재해야 한다. 2026년 9월 18일 SGLang 저장소에 열린, 제목이 [Qwen4-Exp] Add host staging for file-backed PLE인 풀 리퀘스트는 그 테이블이 머신이 애초에 실행되기 위해 필요한 RAM 용량을 좌우하지 못하게 하려는 시도다. Qwen 4는 아직 출시되지 않았다: 모델 카드도, 가중치도, 카탈로그 항목도, 날짜도 없다. 이 아키텍처를 구현한 유일한 출시 모델은 Qwen3.8-Flash-Next로, 2026년 8월 26일 공개된 오픈 웨이트 프리뷰이며, 그 구성은 model_type=qwen4_exp를 선언한다 — 풀 리퀘스트에 이름을 붙여준 바로 그 문자열이다. 그 프로덕션 형제인 Qwen3.8-Flash는 오늘날 API 호출자가 실제로 접근할 수 있는 버전이다. 이 글에서 Qwen 4에 관한 모든 내용은 그 프리뷰와 엔진 코드로부터의 추론이다; 풀 리퀘스트는 열려 있고 병합되지 않았으니, 이 모든 것을 출시된 기능이 아니라 신호로 읽어야 한다.

신호가 실제로 무엇인지

풀 리퀘스트 sgl-project/sglang#40235는 출시된 것도 아니고 병합된 것도 아닙니다. 이는 기여자 Dev-Jahn이 연 하나의 커밋 위에 있으며, task/ple-host-staged라는 브랜치를 SGLang의 메인 라인에 병합하는 중입니다. 아홉 명의 코드 오너에게 리뷰가 요청되었고 모두 대기 중으로 표시되어, 메인에 들어가려면 최소 한 건의 승인 리뷰가 남아 있습니다. 세 개의 CI 작업 — 기본 PR 테스트, 추가 PR 테스트, AMD ROCm 실행 — 이 열린 커밋에서 실패하고 있습니다. 이는 대규모 엔진 변경이 진행 중일 때 나타나는 정상적인 상태이며, 이 PR의 흥미로운 부분이 병합되는지 여부가 아니라 작성자가 그것을 주장하기 위해 무엇을 측정해야 했는지라는 점에 있는 이유이기도 합니다. 설명에는 테스트를 포함해 약 1,400줄의 추가 라인과, 이 아키텍처를 단일 GPU에서 실행하는 것에 관해 지금까지 공개된 가장 구체적인 공개 데이터인 벤치마크 표가 담겨 있습니다.

왜 그 표가 전부인가

레이어별 임베딩은 이 세대의 구조적 특이점이다. 일반적인 모델이 앞단에 토큰 임베딩 하나를 놓는 반면, Qwen4 설계는 거대한 n-gram 테이블 — 바이그램과 트라이그램을 토크나이저의 어휘보다 훨씬 큰 어휘로 해싱한 — 을 갖추고 있으며, 스택 전체에 걸쳐 이 테이블로부터 레이어별 임베딩 조회를 공급한다. Alibaba 자체 미리보기 자료는 n-gram 구성 요소를 125B 파라미터 MoE 본체에 더해지는 수백억 개의 파라미터로 설명한다. 공개된 체크포인트에 대한 커뮤니티의 분해 분석은 테이블 파일을 47.7 GiB로 산정한다. 이 수치들은 독립적 재현이 아니라 공급업체 및 커뮤니티 출처에서 나온 것이며, 미리보기의 테이블과 Qwen 4가 실제로 출시하는 것 사이의 정확한 관계는 알려져 있지 않다.

의심할 여지가 없는 것은 엔지니어링상의 결과다. 모든 디코드 단계마다 참조해야 하는 47.7 GiB의 사이드 테이블은 VRAM 한구석에 조용히 밀어 넣을 수 있는 물건이 아니다. 96 GB 카드에서는 KV 캐시와 직접 경쟁하고, 더 작은 카드에서는 아예 들어가지 않는다. 그래서 8월 말 프리뷰에 day-0 지원을 내놓았던 SGLang이 그 뒤 3주 동안 모델 자체가 아니라 이 단일 데이터 구조에 관한 풀 리퀘스트를 잇달아 만들어낸 것이다.

이 PR 이전에는 무엇이 깨져 있었나요?

SGLang에는 이미 테이블을 유지하는 두 가지 방법이 있었고, 둘 다 날카로운 구석이 있었습니다.

• Pinned은 전체 테이블을 호스트 RAM에 보관하고 그곳에서 읽습니다. 잘 작동하고, 빠르며, 호스트 메모리 요구 사항을 절대적으로 만듭니다 — 이보다 더 작은 버전은 존재하지 않습니다.

• File-backed는 앞선 별도 풀 리퀘스트에서 추가되었으며, 테이블을 스파스 파일에 유지하고 gather 커널이 매핑을 직접 읽을 수 있게 하므로, 얼마나 많은 부분이 상주할지는 운영체제의 페이지 캐시가 결정한다. 문제는 하드웨어에 있다. 그 직접 읽기 경로는 GPU가 cudaDevAttrPageableMemoryAccessUsesHostPageTables를 보고할 것을 요구하는데, 이는 해당 PR 본문이 "GB10 클래스"라고 설명하는 기능이다. 이것이 없는 GPU에서는 파일 백엔드가 아예 거부되고, pinned만이 남은 선택지다.

그로 인해 생기는 격차는 이론적인 것이 아니다. 동일한 코드 경로를 대상으로 제출된 별도 보고서에는 두 대의 RTX 3090을 사용하는 한 사용자가 기록되어 있는데, 이 사용자의 랭크별 테이블 몫은 사용 가능한 메모리 23.56 GiB에 비해 23.84 GiB였고 — 0.28 GiB가 부족했으며, 호스트 RAM 188 GiB는 비어 있었다. 그 구성에서는 파일 백엔드가 하드웨어 검사에서 거부되었고, 일반 CPU 오프로드 플래그는 PLE 오프로드 플래그와 함께 사용하면 예외를 발생시킨다. 300메가바이트가 부족한데 180기가바이트가 남아 있는 것은 바로 이 풀 리퀘스트가 제거하고자 하는 문제의 형태다.

호스트 스테이징 변경 사항은 무엇인가요?

이 PR이 추가하는 메커니즘은 파일과 디바이스 사이의 스테이징 계층이다. GPU가 호스트 페이지를 역참조하도록 요청하는 대신, CPU 측 컴포넌트가 로더의 기존 매핑을 통해 필요한 행을 읽고 커널에 해당 페이지를 미리 가져오라고 알려준다. 환경 변수 SGLANG_QWEN4_PLE_FILE_PREFETCH를 사용하면 그것 없이 측정하고 싶을 때 이 알림을 끌 수 있다. 그런 다음 각 PLE 계층은 8,192개 행으로 이루어진 고정된 버퍼 두 개(FP8 기준 각각 약 1.25 MiB)와 워커 하나를 갖는다. 한 버퍼로 행을 모으는 동안 다른 버퍼가 디바이스로 복사되므로, 수집과 전송이 직렬화되지 않고 겹쳐서 진행된다. N-gram 식별자는 디바이스가 아니라 호스트에서 해시된다. 그래프 재생은 각 재생 전에 준비 호출을 거치며, 실행 스레드는 이전 단계를 기다린다.

마지막 세부 사항은 비용이며, PR은 이를 분명히 밝힙니다: 대략 디코드 단계당 0.5~1밀리초가 추가되며, 이는 고정된 경로 대비입니다. 나머지는 모두 이득입니다. 96 GB의 단일 RTX PRO 6000 Blackwell, 377 GiB RAM을 갖춘 AMD EPYC 호스트, CUDA 13.2에서, Qwen3.8-Flash-Next의 공개 FP8 및 NVFP4 체크포인트를 사용해 측정했습니다:

• 호스트 페이지 캐시, FP8 TP4/EP4 — 71 GB가 고정되고 상한이 없는 반면, 64 GB 상한에서는 49 GB, 32 GB에서는 15 GB, 24 GB 상한에서는 6 GB

• 디코드 지연 시간, 동일 실행 — 동시성 1로 고정했을 때 토큰당 8.62ms, 세 개의 상한 파일 실행 전반의 9.16 / 9.20 / 9.12ms와 비교

• 동시성 16 — 고정 시 16.54 ms, 제한 시 17.62 / 17.85 / 17.37 ms로, 초당 893토큰에서 827–840으로 감소

• 프리필 처리량 — 8k 고정 시 초당 620토큰, 상한 설정 시 624 / 630 / 631; 32k에서는 1,347 대 1,358 / 1,359 / 1,361

• NVFP4 TP2 — 32 GB 상한에서 파일 백엔드는 24 GB인 데 반해 69 GB가 고정되며, 8.87 ms 대 9.18 ms

• 단일 GPU NVFP4 — 64 GB 상한에서 69 GB 고정 대 51 GB, 6.44 ms 대 6.73 ms

• 이것이 앞서는 대안 — 해당 GPU에서 호스트 메모리 관리를 통해 같은 파일을 읽은 경우 동시성 1에서 10.8ms, 동시성 16에서 46.5ms가 나왔으며, PR에서는 이를 해당 동시성에서 고정 지연 시간의 2.8배라고 설명합니다

정확도 측면은 깨끗한 것으로 보고된다. FP8 TP4에서 고정된 경로와 파일 경로 간에 256토큰짜리 프롬프트 8개에 대한 결정적 그리디 출력은 토큰 단위로 동일했고, GSM8K는 64GB 상한에서 고정 경로 97.6% 대 파일 경로 98.0%로 나왔다. 이 여섯 문제 차이는 작성자가 오프로드 경로 때문이 아니라 실행 간 변동으로 돌리는 것이다. 이 모든 수치는 풀 리퀘스트 작성자 자신의 것으로, 한 대의 머신에서 한 번 측정한 것이며, 아무도 이를 재현하지 않았다.

PR이 인정하는 비용

이 풀 리퀘스트를 공정하게 읽으려면 그것이 하지 않기로 한 것까지 포함해야 합니다. 여러 실행 모드는 조용히 성능이 저하되는 대신 구성 시점에 거부되며, 각 거부는 고정된 백엔드를 폴백으로 명시합니다. prefill CUDA 그래프, 데이터 병렬 어텐션, prefill-decode 멀티플렉싱 경로, two-batch 오버랩, DLLM decode 그래프, compact ragged verify 그래프는 모두 제외됩니다. 그만큼 중요한 점은, 새로운 플래그나 새로운 사용자 대상 스위치를 추가하지 않는다는 것입니다 — 스테이징 경로는 이전에는 전혀 사용할 수 없었던 하드웨어에서 파일 백엔드가 수행하는 작업입니다. 그리고 정확도 실행에는 저자가 자발적으로 밝힌 주의 사항이 있습니다. 상한이 적용된 실행은 전체 테이블을 한 번도 담지 못했습니다. 테이블이 47.7GiB이고 상한이 24GB까지 낮아지기 때문입니다. 따라서 전체 테이블에 걸쳐 진정으로 평탄하고 예측 불가능한 접근 패턴을 가진 워크로드는 측정된 대상이 아닙니다.

이것이 특히 Qwen 4에 중요한 이유

엔진 세부 사항을 걷어내면 패턴이 읽힌다. Alibaba는 8월 26일 아키텍처 프리뷰를 공개하면서, 전체 제품군에 앞서 오픈소스 커뮤니티가 런타임과 양자화, 추론 엔진을 준비하도록 지침을 내놨다. SGLang은 그렇게 했고, 그다음 3주 동안 이 아키텍처를 배포하기 까다롭게 만드는 단 하나의 구성 요소에 관한 풀 리퀘스트를 올리는 데 시간을 썼다. 예측으로 읽자면, 이는 Qwen 4가 벤치마크에서 무엇을 할 수 있는지가 아니라 Qwen 4가 여러분의 하드웨어에 무엇을 요구하게 될지에 관한 진술이다.

또한 일정 문제를 더욱 선명하게 부각한다. Qwen 4는 아직 출시되지 않았고, 이를 둘러싼 9월 추측은 9월 22~24일 항저우에서 열리는 Alibaba의 Apsara Conference를 가리킨다 — 이전 Qwen 세대들이 발표된 장소다. 그 어떤 것도 확인되지 않았으며, 지난 프리뷰 주기에서 나타난 패턴은 아키텍처 프리뷰가 전체 패밀리보다 몇 주가 아니라 몇 달 앞선다는 것이다. 그 컨퍼런스 사흘 전에 열린 풀 리퀘스트는 시사하는 바가 있을 뿐, 그 이상은 아니다.

독자에게 이것이 남기는 바를 솔직하게 요약하면 다음과 같다: Qwen 4는 존재하지 않고, Qwen3.8-Flash-Next는 존재하며, 후자는 전자를 실행하는 데 얼마의 비용이 들지 알려준다. 47.7 GiB 테이블의 실효 풋프린트가 계속 줄어든다면 — 그리고 3주간의 풀 리퀘스트는 이 작업이 열심히 진행 중임을 말해준다 — Qwen 4 패밀리의 배포 장벽은 프리뷰의 출시 주간이 시사했던 것보다 낮다.

오늘 이걸로 실제로 할 수 있는 것

이 풀 리퀘스트의 어떤 내용도 main에서 사용할 수 없으며, 이것이 대상으로 하는 모델은 API로 호출할 수 있는 것이 아닙니다. 오픈 웨이트 Qwen3.8-Flash-Next 체크포인트는 셀프 호스팅 이야기입니다. 가중치를 직접 내려받아 직접 서빙하는 것이며, 지금 다루고 있는 것은 파일 기반 PLE 경로입니다. 이 모델은 여기로 라우팅되지 않습니다. 라우팅되는 것은 프로덕션 변형, 즉 Qwen3.8-Flash이며, qwen/qwen3.8-flash로 접근할 수 있습니다. 100만 입력 토큰당 $0.15, 100만 출력 토큰당 $0.47이고, 1M 토큰 컨텍스트와 텍스트, 이미지, 비디오 입력을 지원하며, 더 큰 Qwen3.8-Max는 $2.00 및 $6.00입니다.

그 구분은 이번 주에 무엇을 해야 할지 판단하는 독자에게 유용한 기준이다. 프리뷰는 직접 돌려보는 리서치이고, 서빙 변형은 같은 아키텍처의 프로덕션 경로이며, 엔드포인트 하나만 떨어져 있다. OrcaRouter는 제공업체의 정가를 0% 마크업으로 그대로 전달하므로, 해당 엔드포인트에서 공급업체 가격이 바뀌면 다음 결제 주기가 아니라 같은 날 바로 반영되고, 키에 있는 모든 모델은 공급업체마다 별도의 계약과 SDK, 자격 증명을 두는 대신 하나의 OpenAI 호환 베이스 URL로 접근할 수 있다. 아직 엔진 작업이 매주 이루어지고 로드맵도 공개되지 않은 이렇게 어린 아키텍처에서는, 프로바이더 간 자동 페일오버가 프로덕션 경로를 단일 프로바이더의 가동 시간에 걸지 않고 서빙 변형에 의존하는 실용적인 방법이다. 이 모든 것은 오늘 호출할 수 있는 모델에 관한 이야기다. 그중 하나가 아닌 Qwen 4에 대해서는 아무것도 말해주지 않는다.

우리가 아직 모르는 것

Qwen 4가 같은 표를 같은 크기로 공개할지. 풀 리퀘스트가 병합되긴 할지 — 세 번의 CI 실행이 실패했고 아직 리뷰가 하나도 없다. 스텝당 0.5~1밀리초의 페널티가 저자의 낮은 동시성 구성 밖에서도 유지될지. 그리고 Alibaba가 9월 22일 Apsara에서 무언가를 말할지. 현재 증거로 볼 때, Qwen 4에 대해 내릴 수 있는 가장 안전한 결론은 그것이 어떤 점수를 받는지가 아니라, 그것을 맞추기 위해 업계가 얼마나 많은 기계장치를 짓고 있는지이다 — 이는 모델이 어떤 카탈로그에서든 이름을 얻기도 전에 알아두면 그 자체로 유용한 사실이다.