Qwen3.8
Qwen3.8
Qwen3.8(Qwen3.8-2.4T-A95B)은 Qwen이 현재까지 공개한 가장 큰 오픈-가중치 모델이에요: 총 2.4T 파라미터, 토큰당 95B 활성. Qwen3.5 / Qwen3.6 시리즈의 하이브리드-어텐션 설계를 이어 92개 레이어로 확장했어요.
- 하이브리드 어텐션 —
3 × (Gated DeltaNet → MoE) → 1 × (Gated Attention → MoE)의 23회 반복, 그래서 69개 선형-어텐션 레이어 대 23개 전체-어텐션 레이어. Gated Attention은 head dimension 256에서 4개 KV 헤드 위에 64개 쿼리 헤드를 실행해요. 이것이 선형 계산 복잡도와 장문 컨텍스트 모델링 품질 사이에 균형을 맞춰요. - GDN (Gated Delta Network) — 선형-어텐션 레이어가 인과 합성곱(CausalConv1d)과 함께 State Space Model을 짝지어, head dimension 128에서 128개 V 헤드와 16개 QK 헤드를 실행해요. 고정 크기 순환 상태가 커지는 KV 캐시를 대체하므로, 계산이
O(N)으로 유지되는 동안 메모리는 레이어당O(1)이에요. - 희소 Mixture-of-Experts — 512개 expert, 토큰당 10개 라우팅 + 1개 공유 활성, expert 중간 차원 2048. 히든 차원 8192, 어휘 248,320.
- MTP — 체크포인트는 여러 단계로 학습된 multi-token-prediction 가중치를 실어요. 이 페이지의 NEXTN 추측 레시피가 그것에 맞춰 디코드해요.
라이선스: Qwen3.8-2.4T-A95B. 컨텍스트 길이: 네이티브 262,144, 1,010,000 토큰까지 확장 가능.
권장 생성: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0. presence_penalty를 2쪽으로 올리면 언어 혼합의 일부 위험을 감수하고 도주성 반복을 억제해요. 에이전트 작업에서 Qwen은 추론 262,144 토큰과 최종 응답 131,072 토큰을 허용하길 제안해요.
리소스: 각 정밀도는 별도 repo예요 — BF16 · FP8 · NVFP4, NVIDIA Blackwell (RadixArk) · MXFP4, AMD CDNA4 (Qwen). 추측-디코딩 드래프트 모델: RadixArk/Qwen3.8-2.4T-A95B-DSpark(아래 3.3 참조).
출처: 문서
본문
2. 구성 팁
네 셀이 Not Verified로 표시돼 있어요 — GB300 BF16와 세 가지 GB300 DSpark 전략. 이들은 실행 레시피가 있지만 완료된 검증 실행은 없어요. 그 외 페이지의 모든 셀은 실행됐어요 (B300 NVFP4 DSpark 포함).
가중치 크기가 토폴로지를 결정해요. 2.4T 파라미터에서 BF16은 ≈4.8TB, FP8 ≈2.4TB, NVFP4 ≈1.2TB. FP8은 여기서 어떤 단일 노드에도 들어맞지 않아요 — 8 × 288GB = 2.30TB인 B300조차 턱없이 부족 — 그래서 모든 FP8 레시피는 멀티-노드예요. 단일-노드는 FP4를 의미해요: B300의 NVFP4, MI355X/MI350X의 MXFP4. B200 NVFP4는 한 노드에 맞지만 두 개로 파이프라인되는데, 가중치 후 GPU당 ~25GB는 서빙하기에 너무 적기 때문이에요. BF16도 16개 GPU에 맞지 않아, 그것의 유일한 레시피는 8개 GB300 노드에 걸친 TP32예요 — 평평한 TP32가 랙-스케일 NVLink에 머무는 유일한 플랫폼.
두 개의 별개 FP4 체크포인트. NVFP4는 Blackwell 전용이고, MXFP4는 MI350X/MI355X 전용이며 하이브리드(MXFP4 expert, FP8 어텐션/밀집)예요. MI300X는 하드웨어 MX matmul이 없는 CDNA3이므로 FP8을 서빙해요. 둘 다에서 --moe-runner-backend를 설정하지 않은 채 두면 러너가 체크포인트 자체의 quant_method에서 해결돼요 — NVFP4 wide-EP 계층은 auto가 그 조합을 해결하지 못하므로 flashinfer_trtllm_routed를 --moe-a2a-backend flashinfer와 수동으로 짝지어요.
GDN 상태가 희소 자원이에요, KV가 아니라
레이어의 3분의 2가 Gated DeltaNet이고, 그 순환 상태는 자체 풀에 살아요. 동시성을 제한하는 것은 KV가 아니라 보통 이 풀이에요 — 그리고 요청의 비용은 캐싱 전략에 달려요:
| Strategy | State slots per request |
|---|---|
--disable-radix-cache |
1 |
no\_buffer |
3 |
extra\_buffer (this model's auto) |
5, or 4 where PP disables the overlap scheduler |
그래서 --max-mamba-cache-size는 실행 중인 비율과 일치해야 해요. 그렇지 않으면 max_running_requests를 목표의 일부로 조용히 클램프해요 — GB300 FP8 Balanced와 Low Latency(그 핀이 튜닝된 용량 세트의 일부)를 제외한 모든 셀이 풀을 --mamba-full-memory-ratio에 맡겨요 — Low Latency의 --max-mamba-cache-size 80은 정확히 16개 동시 요청 × 5개 슬롯이에요. 그리고 extra_buffer는 radix 캐싱이 켜져 있어야 해요: mamba_extra_buffer_of()는 disable_radix_cache가 false일 것을 요구하므로, --disable-radix-cache를 추가하면 전략이 무력해지고 예산이 슬롯 하나로 떨어져요.
NEXTN은 동시성을 48로 제한해요
MTP 가중치가 체크포인트 안에 실려 와서 NEXTN은 드래프트 모델이 필요 없고 3/1/4 프리셋이 자동으로 채워져요. 그러나 --max-running-requests가 없는 추측 셀은 메모리에서 파생된 상한이 아니라 추측 훅에서 48을 받아요 — 더 서빙하려면 명시적으로 핀 고정하세요. pp_size > 1은 집합 서빙에서 추측 디코딩을 완전히 배제하는데, 그래서 H200, B200/B300 FP8, B200 NVFP4, MI300X 레시피가 MTP를 실지 않아요.
선형-어텐션 백엔드는 GPU 세대마다 달라요
--mamba-ssm-dtype bfloat16은 SM100에서 핵심이에요: flashinfer GDN decode 기본값이 그것에 게이트되고, 없으면 decode가 조용히 Triton으로 폴백해요. SM90에서 GDN 기본값은 두 절반 모두 Triton이므로, 그래서 H200이 --linear-attn-decode-backend flashinfer도 핀 고정하는 유일한 셀이에요. flashinfer GDN prefill 기본값은 8192까지의 청크 크기만 다루므로, 더 큰 --chunked-prefill-size를 가진 셀은 --linear-attn-prefill-backend flashinfer를 스스로 명시해야 해요.
--attention-backend trtllm_mha는 SM100 전용이에요. 이를 설정하지 않은 Blackwell 셀에서는 모델 훅이 그것을 --page-size 64와 함께 고르고 — 백엔드가 명명되면 일찍 반환하므로 명시적 백엔드는 그 짝을 이루는 페이지 크기도 떨어뜨려 버리고, 그다음 --speculative-eagle-topk가 백엔드를 Triton에서 멀어지게 유지하는 데 의존하는 것이 없어요.
GB300 계층
FP8 사다리는 4개 노드 × 4개 GPU에서 전체 곡선에 걸쳐요:
| Tier | Shape | Spec |
|---|---|---|
| Low Latency | TP16 narrow EP | NEXTN 3+1 |
| Balanced | DP4×TP4 + EP16 | NEXTN 3+1 |
| High Throughput | DP4×TP4 + EP16 | off |
Balanced와 High Throughput은 하나의 형태를 공유하고 용량에서만 달라요. Low Latency는 특별해요: narrow EP가 낮은 동시성에서 이기는데, expert 병렬성에 랭크를 쓰는 것이 돌려받는 것보다 더 비싸기 때문이에요. MTP는 드래프트-플러스-검증 오버헤드가 속도 향상을 능가하므로 포화에서 꺼져요. NVFP4는 두 계층만 있고 — 그 레시피는 다른 GPU 수(8 vs 16)에 걸치고 wide-EP 하나는 전체 동시성 목록에 걸쳐 용량을 고정하므로 — 세 번째 operating point가 없어요.
추가 빌드 요구사항: FP8 Balanced와 High Throughput은 DeepEP v2 휠(2.1.0+01dc3aa)이 필요해요. 그들의 --moe-a2a-backend deepep_v2 플래그는 업스트림에 없기 때문이에요. NVFP4 High Throughput은 먼저 nvfp4_agg_wideep_dep16_flashinfer_setup.sh를 실행해야 하고, 그 SGLANG_FLASHINFER_NUM_MAX_DISPATCH_TOKENS_PER_RANK=8192는 선택이 아니에요 — 설정하지 않으면 1024로 폴백되고, 1024 × ep_size가 가장 큰 CuteDSL MoE forward를 더 이상 덮지 않으면 시작이 오류를 내요.
GB300 PD 분리 레이아웃
PD 역할 셀렉터는 선택된 베이스 레시피에 역할과 전송 플래그를 추가해요. prefill·decode 워커 크기를 조정하지는 않아요. 측정된 GB300 operating point에는 아래 레이아웃으로 별도 워커를 사용하세요:
| Checkpoint and operating point | Prefill workers | Decode worker | Capacity setting |
|---|---|---|---|
| FP8, high throughput | 2 × TP1 / PP16 | DP4-attention / TP4 / EP16, DeepEP v2 + EPLB | Keep frontend concurrency above the decode MRR so prefill remains queued |
| NVFP4, high throughput | 2 × TP1 / PP6 | DP2-attention / TP4 / EP8, FlashInfer one-sided A2A | Prefill MRR 128 per worker; decode MRR 512; frontend concurrency 1536 |
| NVFP4, low latency | TP4 / PP2 | TP16 | Decode MRR 1 and frontend concurrency 1 at the latency endpoint |
NVFP4 + NEXTN에는 두 역할 모두에서 3/1/4 설정을 사용해 prefill 워커가 드래프트 상태를 전송하게 하세요. decode 역할에서 ReplaySSM을 활성화하세요. 생성된 라우터 명령은 prefill에 적용되는 메인 정책을 round_robin으로 설정하고 decode 정책을 명시적으로 유지해요. 서버 쪽 --load-balance-method는 라우터 워커 선택을 구성하지 않아요. 위 고정-형태 처리량 실행에는 round robin이 측정된 선택이에요. 반복-prefix 재사용이 많은 에이전트 워크로드에는 특히 prefill 쪽에서 캐시-인지 라우팅을 고려하고, 타겟 워크로드에서 캐시-국소성 대 로드-균형 트레이드오프를 검증하세요.
AllReduce 융합
하나의 평평한 TP 그룹을 실행하는 네 셀 — GB300 FP8 Low Latency, GB300 NVFP4 Low Latency, GB300 BF16, B300 NVFP4 — 은 SGLANG_FLASHINFER_MNNVL_CUTEDSL_AR_FUSION을 설정하는데, 단일 워크스페이스가 AllReduce + Residual + RMSNorm을 MoE finalize와 융합하는 Qwen3.5 CuteDSL 경로예요. 레거시 경로보다 6–13% 가치. --flashinfer-allreduce-fusion-backend를 함께 전달하지 마세요 — env가 경고와 함께 플래그를 억제해요.
그 외에는 아무것도 사용할 수 없어요: 융합은 DP-attention이 꺼져 있고 내장 TP MoE가 필요하므로, wide-EP 계층은 제외되고, 파이프라인 셀은 크로스-노드 트래픽을 NVLink가 아니라 IB에 올려요. 세 GB300 셀은 또한 NCCL_NVLS_ENABLE=1을 실어요. SGLang이 이 변수가 설정되지 않으면 NVLS 컬렉티브를 강제로 끄기 때문이에요.
AMD
권장: MI355X + MXFP4, 단일 노드, TP8. MI350X는 동일한 명령을 방출해요(같은 gfx950, 같은 288GB, 같은 mi35x 이미지). MI300X는 CDNA3이고 mi30x 이미지를 받으며, FP8 가중치에는 두 노드가 필요해요.
--mem-fraction-static은 의도적으로 공격적으로 보여요. aiter 백엔드로 8192 컨텍스트를 넘어서면 SGLang이 할당 전에 그것을 0.85로 곱하므로, MI355X의0.9는 ≈0.765에, MI300X의1.0은 ≈0.85에 자리해요. 이것들을 아래로 "고치지" 마세요. MI300X는 가중치가 맞도록 1.0에 머물러야 해요.--disable-custom-all-reduce는 모든 MI300X 랭크에 있어야 해요 — SGLang이 프로세스별로 해결하므로, 한 노드에만 설정하면 두 파이프라인 스테이지가 서로 다른 코드 경로를 통해 줄일 거예요.- MI300X는
--kv-cache-dtype fp8_e4m3을--page-size 16으로 실행해요: 노드당 8 × 192GB에서 그 형태는 메모리-제약적이에요.
ReplaySSM
GDN 레이어의 순환 상태는 매 토큰마다 스스로 덮어쓰므로, 추측 검증은 되감을 수 있어야 해요. K=V=128에서 드래프트 단계마다 전체 K×V 상태를 스냅샷하는 것은 요청·레이어·헤드당 64 KiB, 곱하기 γ+1 단계로, 지속 상태 풀과 같은 예산에서 빼내는 임시 공간이에요.
ReplaySSM은 대신 각 드래프트 단계의 원시 입력 Sᵢ = (vᵢ, kᵢ, gᵢ, βᵢ)를 저장하는데, 검증 커널이 지나가며 쓰는 몇 백 바이트예요. 샘플러가 수용 길이를 고정하면 하나의 fold 커널이 커밋된 체크포인트에서 수용된 prefix를 재생하고 제자리에서 진행해요. fold는 검증 재귀의 축어적 클론이라 재구성된 상태는 순환 베이스라인과 비트-동일해요. 드래프트-단계 임시 공간은 대략 두 자릿수로 줄고 결코 할당되지 않아요.
매 커밋마다 fold하는 것이 가변 GDN 상태에 걸쳐 radix prefix 캐싱과 합성되게 해요: --mamba-track-interval 토큰마다 상태가 radix 트리에 넘겨지고, extra_buffer 아래에서는 두 번째 슬롯으로 가서 실행 중인 요청이 자기 것을 계속 변이하게 해요. 기본적으로 꺼져 있어요 — 3.3 참조.
3. 고급 사용
Note: 아래 예제의
model인자는 BF16 repo id예요. 각 정밀도는 별도 repo이므로,model은 서버가 실제로 띄운 체크포인트여야 해요 —…-A95B-FP8,…-A95B-NVFP4, 또는…-A95B-FP8-MXFP4. Deploy 패널의 cURL 스니펫은 선택한 셀에 맞는 올바른 id를 항상 보여줘요.
3.1 추론
Qwen3.8은 항상 추론해요 — thinking을 끌 수 없고 모든 응답이 think…</think> 블록으로 열려요. qwen3 reasoning 파서(위 Playground의 Parsers 카드에서 Reasoning Parser 토글)가 그 블록을 reasoning_content로 분리하고 content는 답변만 남겨요.
깊이는 reasoning_effort로 요청별로 조절 가능해요 — xhigh(기본값), medium, low. preserve_thinking은 이전 턴의 추론을 컨텍스트로 가져오며 기본적으로 켜져 있어요.
추론 예제 (Python)
from openai import OpenAI
client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
model="Qwen/Qwen3.8-2.4T-A95B",
messages=[{"role": "user", "content": "What is 15% of 240?"}],
reasoning_effort="xhigh", # xhigh (default) | medium | low
)
msg = resp.choices[0].message
print("Reasoning:", getattr(msg, "reasoning_content", None))
print("Answer:", msg.content)
예제 출력
Pending update — a sample transcript will be added here.
3.2 툴 호출
qwen3_coder 툴-호출 파서를 활성화해(위 Playground의 Parsers 카드에서 Tool Call Parser 토글) message.tool_calls를 통해 구조화된 툴 호출을 노출하세요.
툴 호출 예제 (Python)
from openai import OpenAI
client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get the current weather for a location",
"parameters": {
"type": "object",
"properties": {
"location": {"type": "string", "description": "The city name"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
},
"required": ["location"],
},
},
}
]
resp = client.chat.completions.create(
model="Qwen/Qwen3.8-2.4T-A95B",
messages=[{"role": "user", "content": "What's the weather in Beijing?"}],
tools=tools,
)
msg = resp.choices[0].message
print("Reasoning:", getattr(msg, "reasoning_content", None))
print("Content:", msg.content)
print("Tool calls:", msg.tool_calls)
예제 출력
Pending update — a sample transcript will be added here.
3.3 DSpark와 ReplaySSM (추측 디코딩)
Qwen3.8용 DSpark 드래프트 모델을 SpecForge로 학습했어요. 위 Playground의 Speculative Decoding 카드에서 DSpark 칩으로 켜세요 — 방출돼요:
--speculative-algorithm DSPARK \
--speculative-draft-model-path RadixArk/Qwen3.8-2.4T-A95B-DSpark
ReplaySSM은 별도 옵트-인이에요. --enable-linear-replayssm-spec은 기본적으로 꺼져 있고 DSpark가 켜지 않으므로, 플래그-선택 목록의 ReplaySSM (spec) 행으로 추가하세요. 켜면(동작 방식은 위 구성 팁 참조) 검증 커널이 전체 K×V GDN 상태를 스냅샷하는 대신 각 드래프트 단계의 원시 입력을 저장하고, 단일 fold 커널이 마지막 커밋된 체크포인트에서 수용된 prefix를 재생해요. 링 버퍼 뒤의 순수한 사이드 채널이라 — 검증 출력은 비트 단위로 변하지 않아요 — 정확도 트레이드오프는 없고 메모리 트레이드오프만 있어요.
DSpark는 모든 셀과 합성되지 않아요. _handle_dspark는 저하시키지 않고 실행을 아예 거부하므로, 칩을 켜기 전에 이것들을 확인하세요:
--pp-size는 1이어야 해요. H200, B200, B300 (FP8), MI300X 셀은 모두 파이프라인되어 DSpark를 쓸 수 없어요.- DP-Attention에서 추가로
--enable-dp-lm-head, 내장 TP MoE(--moe-a2a-backend none), 컨텍스트 병렬 없음을 요구해요. 이는 DeepEP v2 또는 FlashInfer A2A 위에서 DP 어텐션을 실행하는 GB300 wide-EP 계층을 배제해요. --speculative-num-steps는 1로 강제되고, 생략된--speculative-draft-model-path는 타겟 체크포인트가 드래프트 가중치를 번들할 때만 작동해요.
Playground는 위 조합에서 DSpark 칩을 회색 처리해요.
Deploy 패널의 DSpark 전략 칩은 그 제약을 통과하는 네 가지 hw × 양자화 조합에서 이 대체를 방출해요: GB300 FP8(저-지연 형태에서 — balanced 계층의 DeepEP v2 a2a가 DSpark를 배제), GB300 NVFP4, GB300 BF16, B300 NVFP4. 페이지의 다른 모든 것은 파이프라인되거나 wide-EP예요.
드래프트 모델은 자체 가중치와 KV가 필요하므로, 그 셀들은 NEXTN 대응물보다 더 빡빡하게 돌아요 — 검증된 B300 레시피는 --mem-fraction-static을 0.80으로 낮추고 --context-length를 200000으로 줄여 여유를 되사요.
ReplaySSM은 radix prefix 캐싱, 오버랩 스케줄링, PD decode와 합성되므로 DSpark 추측 디코딩은 스택 나머지(WideEP, PD 분리, HiCache)와 함께 실행되고, 아무것도 꺼야 할 필요가 없어요.