SGLang và Miles hỗ trợ ngay lập tức cho siêu mô hình Qwen3.8-2.4T-A95B

Chúng tôi rất vui mừng thông báo về việc hỗ trợ Day-0 cho Qwen3.8-2.4T-A95B trong SGLang và Miles. Đây là mô hình mã nguồn mở lớn nhất của Qwen, với tổng cộng 2,4 nghìn tỷ tham số và 95 tỷ tham số kích hoạt trên mỗi token, cùng kiến trúc hybrid attention gây áp lực lên hầu hết các giả định của một hệ thống phục vụ (serving stack) về trạng thái. Với sự hợp tác từ các đội ngũ Qwen, NVIDIA và AMD, SGLang đã hỗ trợ đầy đủ mô hình này ngay trong ngày ra mắt. Bài viết này sẽ đề cập đến những công việc cần thiết để đạt được điều đó.

Các điểm nổi bật

Các lệnh khởi chạy và hướng dẫn cấu hình theo từng khối lượng công việc (per-workload) đã có sẵn trong Qwen3.8 cookbook.

Kiến trúc mô hình

Qwen3.8-2.4T-A95B tiếp tục kế thừa thiết kế hybrid attention của dòng Qwen3.5/3.6. Thế hệ này mở rộng quy mô lên tổng cộng 2,4 nghìn tỷ tham số, với 95 tỷ tham số được kích hoạt trên mỗi token qua 92 lớp.

Các điểm nổi bật về kiến trúc

Kiến trúc Qwen3.8-2.4T-A95B bao gồm:

Hybrid Attention. Kiến trúc này kết hợp 69 lớp linear-attention (GDN) và 23 lớp full-attention (GQA) theo mô hình xen kẽ 3:1. Thiết kế này tạo ra sự cân bằng giữa độ phức tạp tính toán tuyến tính và hiệu suất mô hình hóa ngữ cảnh dài.

GDN (Gated Delta Network). Các lớp linear-attention kết hợp State Space Model (SSM) với causal convolution (CausalConv1d). Một trạng thái tái phát (recurrent state) có kích thước cố định thay thế cho KV cache đang tăng dần, do đó mỗi lớp GDN sử dụng bộ nhớ O(1) trong khi tính toán của nó mở rộng theo O(N).

Sparse Mixture-of-Experts (MoE). Mỗi lớp MoE cung cấp 512 chuyên gia được định tuyến (routed experts) cộng với một chuyên gia dùng chung, với cơ chế định tuyến top-k=10.

Hỗ trợ tính năng

Mỗi yêu cầu Qwen3.8 duy trì ba dạng trạng thái phục vụ: KV cache cho các lớp full-attention, trạng thái tái phát cho các lớp GDN và các cửa sổ tích chập (convolution windows) của GDN. Các tính năng dưới đây phải quản lý nhất quán cả ba trạng thái này trên các cơ chế prefix caching, speculative decoding và PD disaggregation.

ReplaySSM cho trạng thái GDN

Việc xác thực MTP tạo ra vấn đề khôi phục trạng thái cho các lớp GDN. Mỗi lớp cập nhật trạng thái tái phát của nó tại chỗ trong khi xác thực nhiều draft token, nhưng chỉ trạng thái tương ứng với tiền tố (prefix) được chấp nhận mới được commit. Qwen3.8 áp dụng ReplaySSM cho vấn đề này. Chúng tôi đã mô tả chi tiết cơ chế phát lại dữ liệu đầu vào thô này trong bài viết trước. Trong quá trình xác thực, nó ghi lại các đầu vào tái phát thay vì chụp nhanh (snapshot) toàn bộ trạng thái GDN tại mỗi vị trí draft. Khi bộ lấy mẫu (sampler) xác định được độ dài được chấp nhận, một fold kernel sẽ phát lại tiền tố đã chấp nhận từ checkpoint đã commit và tiến hành cập nhật trạng thái tại chỗ.

Chúng tôi đã tích hợp đường dẫn ghi vào kernel GDN MTP của FlashInfer's CuTe DSL cho các trạng thái BF16. Phần mở đầu xác thực (verify prologue) đã có sẵn các giá trị cần thiết trong các thanh ghi, vì vậy ReplaySSM chỉ bổ sung thêm các thao tác lưu trữ ring-buffer tương ứng. Nó giữ nguyên kết quả xác thực ở cấp độ bit và không gây ra sự suy giảm đáng kể nào về thông lượng xác thực. Đường dẫn lưu trữ trạng thái có thể thay đổi (mutable-state caching path) tương tự cho phép MTP kết hợp với prefix caching, overlap scheduling và PD disaggregation.

Phân tách Prefill-Decode (PD disaggregation)

PD disaggregation chuyển cả ba loại trạng thái từ worker prefill sang worker decode thông qua một registry trạng thái có kiểu dữ liệu (typed state registry). Mỗi trình xử lý đã đăng ký sẽ di chuyển trạng thái tương ứng của nó, bao gồm KV cache, trạng thái tái phát GDN và các cửa sổ tích chập GDN. Các khối con q, k và v của mỗi cửa sổ tích chập được phân mảnh độc lập trên các tensor-parallel rank, vì vậy lớp truyền tải sẽ cắt và lắp ráp lại chúng cho bố cục đích.

Cùng một payload mang theo KV cache, các trạng thái ẩn (hidden states) và metadata top-k của mô hình draft MTP, cho phép speculative decoding tiếp tục thực hiện trên worker decode. Khi prefill và decode sử dụng các bố cục phân mảnh attention khác nhau, một bộ đệm staging GPU sẽ gộp các lát cắt theo từng lớp thành một lần truyền RDMA lớn cho mỗi chunk thay vì thực hiện các lần truyền riêng biệt cho từng lát cắt.

Radix Cache và HiCache

Qwen3.8 sử dụng Unified Radix Cache của SGLang để kích hoạt prefix caching cho cả KV full-attention và trạng thái GDN. Thành phần FULL quản lý KV cache full-attention, trong khi thành phần MAMBA quản lý các checkpoint GDN. Mỗi checkpoint GDN bao gồm trạng thái tái phát và các cửa sổ tích chập.

Trước khi một forward pass làm thay đổi một checkpoint GDN dùng chung, cơ chế copy-on-write sẽ khôi phục nó vào một khe yêu cầu riêng. SGLang tạo các checkpoint mới tại các ranh giới chunk prefill và các khoảng thời gian decode định kỳ. Một bộ điều khiển cache dùng chung điều phối các thành phần KV và GDN trên các tầng thiết bị và máy chủ, cho phép prefix caching và HiCache kết hợp với MTP và PD disaggregation.

Prefill song song theo đường ống (Pipeline-Parallel) dạng chunk

Decode và prefill ưu tiên các bố cục song song khác nhau trong các cấu hình được đo lường ở đây. Đối với decode, chúng tôi sử dụng expert parallelism rộng để phân mảnh tất cả 512 chuyên gia trên các rank. Cả hai cấu hình wide-EP bên dưới đều đã bật EPLB. Tại các điểm vận hành prefill 8K được đo lường, các cấu hình wide-EP, bao gồm các tập lệnh dispatch và combine, cho thấy thông lượng thấp hơn so với PP thuần túy. PD disaggregation cho phép hai giai đoạn chạy trên các worker riêng biệt và sử dụng các bố cục khác nhau.

Với prefill pipeline-parallel thuần túy, mỗi giai đoạn sở hữu một lát cắt liên tục của 92 lớp và thực thi lát cắt đó trên một rank, sử dụng các GEMM toàn chiều rộng mà không cần MoE dispatch, combine hoặc EPLB. Giao tiếp chính giữa các giai đoạn là việc truyền activation tại mỗi ranh giới giai đoạn. Việc chia một yêu cầu thành các chunk cho phép quá trình chuyển giao cho chunk i chồng lấp với quá trình tính toán của chunk i+1 khi các chunk luân chuyển qua các giai đoạn một cách liên tục.

Được đo lường trên prefill 8K tại các điểm vận hành hiển thị, tính bằng token đầu vào trên giây trên mỗi GPU:

Prefill Pipeline-Parallel với MTP

Pipelined prefill và speculative decoding trước đây là hai khái niệm loại trừ lẫn nhau, nghĩa là phải chọn giữa thông lượng ở trên và tốc độ trên mỗi người dùng ở dưới. Sự cản trở mang tính cấu trúc: trong quá trình pipelining, embedding nằm ở giai đoạn đầu và LM head nằm ở giai đoạn cuối, vì vậy không có giai đoạn đơn lẻ nào giữ cả hai, trong khi draft head lại cần cả hai. Chúng tôi đặt draft head ở giai đoạn cuối với bản sao riêng của phần mà nó không nhận được, staging draft KV qua ranh giới PD cùng với target KV, và để các rank không chứa draft không sở hữu pool draft KV nào. Cấu trúc liên kết prefill trở thành một biến tự do: worker decode giữ lại speculative decoding của nó bất kể worker prefill được cắt như thế nào.

Staging Buffer: Tách biệt bố cục Prefill và Decode

Một worker prefill PP16 và một worker decode wide-EP không thống nhất về cách phân vùng KV, và việc yêu cầu một bố cục TP dùng chung sẽ kéo prefill quay lại cấu trúc liên kết của decode và làm mất đi tất cả những lợi ích trên.

Staging buffer thay đổi những gì mà hai bên thống nhất. Prefill ghi các chunk đã hoàn thành vào staging buffer và công bố watermark cho mỗi peer; decode phân tán dữ liệu từ đó vào bất kỳ bố cục nào nó sử dụng, prefetching từng chunk một. Hợp đồng ở đây là chỉ số chunk và watermark thay vì phân vùng, cho phép quá trình truyền tải chồng lấp với phần prefill còn lại. Do đó, tỷ lệ prefill:decode, độ sâu pipeline và độ rộng decode EP có thể được điều chỉnh riêng biệt. Cùng một đường dẫn đó mang theo draft KV.

Hiệu suất

Đường cong Pareto trên 8K/1K

Tất cả các con số dưới đây là 8.192 đầu vào / 1.024 đầu ra trên GB300. Hình vẽ bao gồm các kết quả PD-disaggregated cho NVFP4 và FP8, cộng với các kết quả TP tổng hợp cho FP8. Thông lượng là tổng số token (đầu vào + đầu ra) trên giây trên mỗi GPU phục vụ mô hình đang hoạt động; tốc độ trên mỗi người dùng là số token đầu ra trên giây trên mỗi yêu cầu.

Các nhãn endpoint đại diện báo cáo số lượng GPU đang hoạt động/được cấp phát; P và D hiển thị sự phân chia prefill/decode đang hoạt động. Mức tối đa PP6 sử dụng 20 GPU đang hoạt động (12P + 8D) trong số 24 GPU được cấp phát, và TPS/GPU được chia cho các GPU phục vụ mô hình đang hoạt động.

Các điểm PD-disaggregated hiển thị ở đây sử dụng độ dài chấp nhận bắt buộc là 3,3. Các điểm tổng hợp FP8 báo cáo TPOT được đo trong các lần chạy tương ứng của chúng. Các endpoint là:

Đỉnh NVFP4 sử dụng hai worker prefill PP6 cung cấp cho một worker decode DP2-attn / TP4 / EP8. Ở mức độ trễ thấp, NVFP4 sử dụng worker prefill PD-disaggregated PP2×TP4 với worker decode TP16 (334 tok/s/người dùng), trong khi FP8 sử dụng worker tổng hợp TP16 ở mức đồng thời 1 (362 tok/s/người dùng).

Trên nền tảng NVFP4 dual-PP6 tương ứng, việc thêm MTP giúp tăng thông lượng +10,0% và tốc độ trên mỗi người dùng lên 2,33 lần. Điểm 5,126 đã cập nhật không được sử dụng cho so sánh tương ứng đó. Sự bất đối xứng là hình dạng dự kiến: trong một worker decode bão hòa, số token mỗi bước xấp xỉ bằng running_requests × draft_tokens và được cố định bởi ngân sách bộ nhớ, vì vậy speculative decoding chủ yếu chuyển đổi một ngân sách bước cố định thành ít bước hơn nhưng dài hơn trên mỗi yêu cầu.

Tối ưu hóa Kernel