Qwen4-Exp QSA có mặt trên Ascend của Huawei: bên trong PR prefill CANN dạng opt-in của SGLang

Vào ngày 30-09-2026, một người đóng góp đã mở yêu cầu kéo SGLang #41855, có tiêu đề “[NPU] Thêm tính năng chú ý thưa CANN tùy chọn cho Qwen4-Exp QSA prefill,” và phần thú vị không phải là phép toán. Mà là phần cứng. Kiến trúc Qwen4Exp hiện có một đường dẫn chú ý thưa được viết thủ công cho bộ tăng tốc Ascend 910C của Huawei, nằm sau một cờ mặc định tắt, trong một yêu cầu kéo bản nháp chưa được hợp nhất — trong khi mô hình mà tên kiến trúc đó thuộc về, Qwen4-Exp, chưa bao giờ được công bố dưới bất kỳ hình thức nào. Checkpoint duy nhất mang kiến trúc này trong trọng số mở vẫn là Qwen3.8-Flash-Next, bản xem trước hỗn hợp chuyên gia 125 tỷ tham số mà nhà cung cấp đã phát hành trên Hugging Face vào ngày 24-08-2026, và thẻ của nó thực sự khai báo kiến trúc của nó là qwen4_exp. Bản thân Qwen 4 — các hạng Max, Flash, Plus và 27B mà nhà cung cấp đã đặt tên tại hội nghị Apsara của mình vào ngày 22-09-2026 — vẫn chưa có trọng số, chưa có mã định danh, chưa có giá và chưa có ngày phát hành. Vì vậy, đây là một bài viết về những gì chúng ta biết cho đến nay về một sản phẩm kỹ thuật, không phải một buổi ra mắt: thêm một ngăn xếp phục vụ của nhà cung cấp khác âm thầm quyết định rằng một kiến trúc chưa phát hành đáng được hỗ trợ sớm.

Pull request thực sự bổ sung những gì

Thay đổi này cố tình nhỏ và cố tình hẹp. Năm tệp, một commit, +355 dòng so với nhánh main tại commit b87a241, mang nhãn SGLang npu. Tác giả, w1ida, nêu rõ ý định ngay từ đầu: một đường main-attention CANN tùy chọn bật cho Qwen4-Exp QSA eager prefill, được xây dựng trên torch_npu.npu_sparse_flash_attention, với indexer, lựa chọn Top-K, ngân sách token và nội dung KV-cache đều được giữ nguyên chính xác như cũ.

Thủ thuật mà nó sử dụng để đạt được điều đó đáng để dành một đoạn, bởi vì nó giải thích lý do tại sao đây là một bộ điều hợp bố cục chứ không phải là một hạt nhân attention mới. Đối với Q và K đã được xoay, đường dẫn đóng gói bộ nhớ đệm dưới dạng C = [K, V] và truy vấn dưới dạng Q' = [Q, 0]. Tích Q' @ C.T thì bằng Q @ K.T, và bởi vì truy vấn được đệm không đóng góp gì, softmax(scale * Q' @ C.T) @ C trả về [P @ K, P @ V] được xếp chồng — vì vậy nửa V có thể được cắt ra. Theo lời của chính tác giả, đây là “một embedding bố cục attention, không phải là sự thay đổi attention của mô hình hay nén KV hạng thấp.” Mỗi đầu KV trở thành một batch độc lập trong bố cục MLA gốc, tỷ lệ D256 ban đầu được giữ nguyên, và RoPE phụ được đặt về không.

Các chi tiết vận hành quan trọng không kém phần toán học:

• Kích hoạt — SGLANG_NPU_QSA_NATIVE_PREFILL=1, mặc định tắt. Chỉ ForwardMode.EXTEND thông thường mới bật tính năng này; decode, các chế độ speculative, mixed forward và graph capture đều giữ nguyên trên các đường đi hiện có, và graph capture bỏ qua hoàn toàn adapter.

• Phần cứng và kiểu dữ liệu — BF16 với kích thước chiều head là 256, Ascend 910C (Ascend910_93*), đã được kiểm thử với CANN 9.0 và torch-npu 2.10. Mọi kiểu dữ liệu hoặc hình dạng không được hỗ trợ sẽ tự động chuyển ngầm về đường dẫn tham chiếu.

• Hình dạng head — (số head Q, số head KV)các cặp cục bộ được hỗ trợ là (16,2), (24,2), (12,1), (6,1) và (3,1). CANN từ chối thẳng tỷ lệ query/KV là 12 — bộ tiler của nó chỉ chấp nhận lũy thừa của hai — nên số head được đệm 12→16, 6→8 hoặc 3→4 và các output thêm vào bị loại bỏ. Đây là dấu hiệu rõ ràng nhất trong toàn bộ PR cho thấy phần cứng không được thiết kế để tính đến các tỷ lệ head của sparse attention, và adapter đang hấp thụ sự không khớp đó thay vì mô hình thay đổi hình dạng vì nó.

• Giới hạn kích thước — chỉ phạm vi bộ nhớ đệm vật lý được tham chiếu mới được đóng gói, giới hạn ở 262.144 token, mà tác giả tính toán là tối đa 512 MiB cho tensor K/V BF16 đã đóng gói tại hai đầu KV. Đệm -1 bên trong được phát hiện và định tuyến đến fallback, vì CANN yêu cầu các slot hợp lệ liên tục; các hàng bị che hoàn toàn giữ quy ước đầu ra bằng không hiện có.

• Vì sao chỉ prefill — việc kiểm tra extent và layout sao chép hai scalar lên host, còn các bản sao tạm thời cùng workspace native tốn bộ nhớ. Sự đồng bộ hoá đó là lý do đường thực thi này bị giới hạn ở prefill eager và bị tắt trong lúc capture.

Chín bài kiểm tra đã đạt, và một con số tốc độ không đến từ nhánh này

Bằng chứng về tính đúng đắn rất cụ thể và có thể tái lập, hơn hẳn những gì mà hầu hết các PR kernel đưa ra. Tác giả báo cáo 9 bài kiểm thử đều đạt trong 40,772 giây trên Ascend 910C (Ascend910_9362) với CANN 9.0 và torch-npu 2.10.0, không cần checkpoint: Q/K/V BF16 ngẫu nhiên khác không so với tham chiếu FP32 CPU được tính từ chính các đầu vào BF16 đó, các slot vật lý không theo thứ tự tại các độ rộng 1/63/64/65/2051, thang đo mặc định và tường minh, các hàng được che toàn bộ, hàng bằng không, độ rộng vùng chọn bằng không, tensor không liên tục, phần dư đuôi nhân quả với tỷ lệ nén 4 từ 0 đến 3, ánh xạ vật lý hai yêu cầu với tiền tố dùng chung, tái sử dụng nội dung cache, và các hình dạng đầu cục bộ của Flash-Next tại 1 và 257 hàng truy vấn.

Trường hợp tiêu điểm là một prefill dài: 7,810 token truy vấn so với cache 65,536 token với 2,051 slot được chọn cho mỗi truy vấn, mọi đầu ra đều hữu hạn, với tám hàng được lấy mẫu đem so sánh với tham chiếu FP32. Sai số L2 tương đối quan sát được đạt 0.209% ở các trường hợp head-shape nhỏ và 0.231% ở các hàng long-prefill được lấy mẫu, so với các ngưỡng kiểm thử là atol=0.025, rtol=0.025 và L2 tương đối dưới 0.008, với các hàng rỗng bắt buộc phải đúng bằng không. Bộ nhớ NPU được cấp phát đỉnh cho lần chạy đó được nêu là 1,042.7 MiB — và tác giả ghi rõ đó là chỉ số của bộ cấp phát PyTorch, không phải HBM trên bo mạch và cũng không phải bộ nhớ toàn mô hình, đây chính xác là lưu ý đúng đắn cần kèm theo.

Rồi có con số sẽ được trích dẫn và không nên như vậy. Nội dung PR có một bảng tốc độ cho thấy đường attention cục bộ hiện có đạt 2.270,79 token mới mỗi giây và native packed main attention đạt 3.890,06 — mức tăng 1,713× / +71,3%, với thời gian trung bình đến token đầu tiên giảm từ 3,109 giây xuống 1,812 giây. Tác giả nói rõ rằng đây là các phép đo nguyên mẫu lịch sử được thực hiện vào ngày 2026-09-29 trên một Whittle-Next-26B-A3B checkpoint đã được điều chỉnh, chạy ở TP1 với trọng số W8A8 và attention BF16 trên 910C dưới CANN 9.0, sử dụng sglang.bench_serving harness chính thức ở mức đồng thời 1 với sáu yêu cầu, mỗi yêu cầu một token đầu ra, và 36.096 token tiền tố được lưu đệm bị loại trừ khỏi thông lượng token mới. Chúng không phải là một benchmark của nhánh upstream trong PR, các artifact JSON serving gốc không có trong bản checkout, và các kết quả cục bộ sau đó khoảng 5.000 token mỗi giây đã sử dụng thêm công việc native indexer và block4 mà rõ ràng không được quy cho thay đổi này. Tác giả cũng lưu ý rằng trọng số indexer của checkpoint đã được điều chỉnh là không hoạt động và ngân sách của nó khác với bản gốc, nên không có gì trong đó là bằng chứng về tính đúng đắn của indexer hay chất lượng sinh với ngân sách đầy đủ.

Một điểm cần làm rõ về cách đặt tên, vì nó sẽ khiến bất kỳ ai đang tìm kiếm checkpoint bị nhầm lẫn: mô hình benchmark là sản phẩm đã được điều chỉnh của chính người đóng góp. Riêng “Whittle-Next” cũng là tên của một chuỗi công khai gồm các bản fine-tune MoE phái sinh từ Qwen3.8 do một tài khoản Hugging Face của bên thứ ba công bố, bao gồm một biến thể 26B-A3B được tải lên vào tháng 9. Đó không phải là mô hình Qwen4Exp mà PR này hướng tới, và không nên được hiểu là cấu hình benchmark đứng sau con số 1.713× đó.

Hai lưu ý bổ sung nữa đến từ tác giả chứ không phải từ tôi. Tích hợp phục vụ đầy đủ, song song tensor phân tán và mô hình Qwen3.8-Flash-Next hoàn chỉnh chưa được xác thực trên nhánh này; người đóng góp nói rằng việc giữ nó ở dạng bản nháp trong khi câu hỏi về tích hợp và phụ thuộc đang được thảo luận là có chủ đích, và thậm chí còn hỏi trong phần nội dung PR liệu bộ điều hợp thuộc về SGLang hay thuộc về kho lưu trữ riêng sgl-kernel-npu đó. CI cũng chưa sạch — khối trạng thái trong nội dung PR cho thấy các lỗi ở PR Test (Base), PR Test (Extra) và lần chạy AMD ROCm 10. Tính đúng đắn được mô tả ở trên là ở mức toán tử; không có gì trong PR khẳng định kết quả độ chính xác hay thông lượng đầu cuối trên ngăn xếp đã tích hợp.

Vì sao QSA lại là phần khó nhằn, qua những con số

Qwen Sparse Attention không phải là một lớp attention thông thường, và cấu hình được công bố cho thấy lý do tại sao một nhà cung cấp accelerator phải viết một đường dẫn riêng cho nó. Từ cấu hình Qwen3.8-Flash-Next: 48 lớp được bố trí thành mười hai lần lặp của ba khối Gated DeltaNet, tiếp theo là một khối full-attention, full_attention_interval 4, kích thước ẩn 2.560, kích thước đầu attention 256, 24 đầu query so với 2 đầu KV, kích thước RoPE 64. Indexer khiến attention trở nên thưa là một cấu trúc multi-query với 4 đầu query chia sẻ 1 đầu key, kích thước đầu 128, tỷ lệ nén 4 và ngân sách 2.048 micro-block được chọn cho mỗi query.

Ngân sách đó là thứ mà PR giữ cố định. Kích thước khối thưa vẫn là 1, chế độ thưa vẫn là 0, chế độ attention vẫn là 2, và giao diện token được chọn không bị thay đổi; các tối ưu hóa native indexer và block4 nằm ngoài phạm vi một cách rõ ràng. Vì vậy, đây là một adapter được gắn bên dưới một cơ chế lựa chọn hiện có, chứ không phải là việc tái triển khai QSA — đó cũng là lý do tác giả có thể tuyên bố một cách đáng tin cậy rằng nội dung KV-cache không thay đổi.

Thẻ mô hình trình bày ý định thiết kế một cách rõ ràng: thay vì chọn từng token riêng lẻ, QSA hoạt động ở cấp vi khối để cắt giảm độ trễ ngữ cảnh dài, và chính độ chi tiết vi khối đó, cùng với trạng thái bộ chọn được nhân bản đi kèm, là thứ không ánh xạ một cách sạch sẽ lên một kernel paged-attention tổng quát trên silicon của cả hai nhà cung cấp.

Vị trí của điều này trong quá trình xây dựng hệ thống phục vụ Qwen4Exp

Nhìn riêng lẻ, một PR nháp trên một bộ tăng tốc là một điều lạ. Đặt cạnh phần còn lại của tháng Chín, nó là tấm ván thứ tư hoặc thứ năm của một nền tảng đang được lắp ghép công khai trước khi gia đình mà nó phục vụ ra đời:

• Kiến trúc trong open weights — Qwen3.8-Flash-Next, 2026-08-24, một MoE 125B tham số với 6B được kích hoạt, bảng embedding n-gram 51 tỷ tham số và một đầu MTP 4B, mang model_type: qwen4_exp và architectures Qwen4ExpForConditionalGeneration.

• Phía vLLM — #53909, PR “qwen4 fuse op” bổ sung các kernel HyperConnection, QSA và PLE, vẫn mở và chưa được hợp nhất kể từ 2026-08-26; #59279, PR bổ sung song song hóa ngữ cảnh giải mã vào cùng đường dẫn QSA, một bản nháp được mở ngày 2026-09-29; và công việc PLE-offload đã được đưa vào trong suốt tháng Chín.

• Phía SGLang — #38642 cho việc thu thập trạng thái ẩn của DFlash, #39548 cho việc offload PLE lên CPU của Qwen4-Exp trên Ascend, #40235 bổ sung host staging cho bảng PLE lưu bằng tệp, và giờ là #41855 cho đường attention của Ascend.

• Dòng kích hoạt NPU — sglang #37570, thêm Qwen3.8-Flash-Next vào SGLang trên NPU với graph replay, MTP và các kernel Triton (mở ngày 2026-09-02, vẫn đang mở, +2,590 dòng trên 20 tệp), và sgl-kernel-npu #807 cho các kernel Triton đi kèm (mở ngày 2026-09-17, +4,643 dòng). Cả hai đều đến từ cùng một người đóng góp. #41855 là lớp attention nằm trong nỗ lực kích hoạt lớn hơn đó.

Hai quan sát mà người đọc có thể hành động dựa trên. Thứ nhất, toàn bộ câu chuyện Ascend Qwen4Exp chỉ dựa vào một số lượng rất nhỏ người đóng góp — các PR kích hoạt và kho kernel có chung một tác giả, còn bộ điều hợp attention là một người khác. Sự tập trung đó là một ước lượng hợp lý cho thấy việc phục vụ Ascend Qwen4Exp còn cách xa việc trở thành một lộ trình sản phẩm được hỗ trợ chứ không chỉ là một thử nghiệm. Thứ hai, nút thắt cổ chai kernel không đặc thù cho nhà cung cấp: hai issue SGLang được tạo ngày 2026-08-28 ghi lại quá trình decode Qwen4Exp trên một NVIDIA DGX Spark, nơi thời gian kernel QSA, PLE và Gated DeltaNet chiếm ưu thế, và nơi một KV cache NVFP4 được đo là làm suy giảm decode khoảng 29% so với fp8_e4m3. Các tầng attention và embedding của kiến trúc này là phần khó ở mọi nơi.

Điều này không có nghĩa là gì

Điều đó không có nghĩa là Qwen 4 đã ra mắt, hay sắp ra mắt. Gia đình Qwen 4 mà Alibaba đặt tên vào ngày 22/09/2026 — Max, Flash, Plus và một bậc 27B — vẫn chỉ là một lộ trình không có model card, không có trọng số, không có định danh API, không có cửa sổ ngữ cảnh, không có giấy phép và không có giá. Một bộ điều hợp framework nhắm tới tên kiến trúc nội bộ là một bước tiến tới việc phục vụ tốt gia đình đó vào một ngày nào đó; đó không phải là một bước tiến tới việc gia đình đó tồn tại.

Điều đó không có nghĩa là bạn có thể chạy nó ngay hôm nay. PR này là bản nháp với CI đang lỗi và chưa có ngày hợp nhất. Kể cả khi đã được hợp nhất, lối chạy này vẫn cần Ascend 910C, BF16, CANN 9.0 với torch-npu 2.10, và một trong năm hình dạng head cục bộ cụ thể, đồng thời nó là tùy chọn tham gia — nghĩa là một triển khai phải tự chọn nó. Tác giả cũng từ chối khẳng định đã xác thực ở cấp máy chủ, vốn là phần thực sự cho bạn biết liệu nó có trụ vững khi xử lý theo lô thực tế hay không.

Và điều đó không có nghĩa Qwen3.8-Flash-Next là một sản phẩm được hỗ trợ trên Ascend, hay ở bất kỳ nơi nào khác trong một bản dựng engine đã phát hành. Các đường dẫn Qwen4Exp trong cả hai runtime mở lớn đều là những pull request chưa được hợp nhất. Không có phiên bản SGLang hay vLLM nào đã phát hành mà bạn có thể cài đặt để phục vụ kiến trúc này một cách native — sự tiện lợi kiểu FastAPI của một endpoint được host là một chuyện khác với một kernel mà bạn có thể tự chạy, và khoảng cách giữa hai thứ đó chính là lý do tồn tại của những PR như thế này.

Những gì bạn thực sự có thể gọi trong lúc chờ

Nếu lý do bạn quan tâm đến Qwen4Exp là vì bạn muốn kiểm tra hành vi ngữ cảnh dài của kiến trúc thay vì phần lõi kernel bên trong, thì mô hình bạn nên dùng là phiên bản mà Alibaba thực sự phục vụ. Qwen3.8-Flash — dòng sản phẩm chính thức được xây dựng trên Qwen3.8-Flash-Next, với các công cụ tích hợp chính thức và ngữ cảnh 1.000.000 token — đang hoạt động trên OrcaRouter với tên qwen/qwen3.8-flash: đầu vào văn bản, hình ảnh và video, đầu ra tối đa 131.072 token, 0,15 USD cho mỗi triệu token đầu vào và 0,47 USD cho mỗi triệu token đầu ra, với giá đọc từ cache là 0,0184 USD. Đó là giá niêm yết của nhà cung cấp được chuyển tiếp nguyên vẹn với mức markup 0% từ phía chúng tôi, nên nếu nhà cung cấp thay đổi giá hoặc giới hạn thì thông tin sẽ đến với bạn ngay trong ngày được công bố. Trong cửa sổ bảy ngày gần nhất, thẻ trực tiếp hiển thị độ trễ token đầu tiên p50 là 4.416 ms, khoảng 106 token đầu ra mỗi giây và tỷ lệ lỗi 2,68% — đúng đặc trưng của một phiên bản văn bản khối lượng lớn chứ không phải bản xem trước trong phòng thí nghiệm.

Hai lưu ý trung thực, và cũng chính là hai lưu ý mà các bài viết cùng chủ đề về kiến trúc này đều có. Bản thân Qwen3.8-Flash-Next — checkpoint xem trước FP8, thứ mà bạn sẽ cần để tái tạo bất kỳ phép đo kernel nào trong số này tại chỗ — không có trong danh mục của chúng tôi; hạng Flash được phục vụ là bản triển khai production được xây dựng từ nó, chứ không phải là hiện vật xem trước thô. Và không phần nào trong công việc Ascend hay DCP mô tả ở trên tồn tại trong bất cứ thứ gì bạn có thể gọi được, bởi vì chưa phần nào trong đó được hợp nhất. Điều mà hạng được phục vụ thực sự mang lại cho bạn là một cách rẻ để tìm hiểu xem khối lượng công việc của bạn có được định hình cho vấn đề mà các kernel này giải quyết hay không — những prompt dài, nặng về tiền tố, mang tính tác tử, đối đầu với một ngữ cảnh rất dài. Nếu đúng như vậy, thì thông lượng và hành vi bộ nhớ đệm mà bạn quan sát được ở đó cũng chính là hành vi mà ngăn xếp phục vụ Qwen 4 sẽ được tinh chỉnh để bảo vệ.

Cũng có một lập luận về hạ tầng cho việc không chờ đợi một dòng mô hình chưa có ngày ra mắt. Bất kể tầng nào cuối cùng thắng trong dòng Qwen 4, chi phí chuyển đổi là một câu hỏi về định tuyến chứ không phải một dự án tích hợp, và một API cho hơn 200 mô hình chính là cách bạn giữ lựa chọn đó luôn mở mà không cần hợp đồng thứ hai hay thay đổi mã nguồn khi trọng số được phát hành. Dự phòng chuyển đổi cũng quan trọng vì lý do tương tự ở đây theo một cách cụ thể: nếu bạn muốn xây dựng dựa trên một tầng chưa được kiểm chứng, bạn muốn yêu cầu đó tự động chuyển sang một thứ ổn định thay vì thất bại khi con đường mà bạn đặt cược đang gặp một phút khó khăn.

Ba câu hỏi đáng để trả lời trực tiếp

SGLang #41855 có nghĩa là Qwen 4 đã ra mắt, hay chỉ mới có thể xem trước?

Không, ở cả hai điểm. Pull request này nhắm đến kiến trúc Qwen4Exp như được triển khai trong Qwen3.8-Flash-Next, thứ mà Alibaba đã phát hành vào 2026-08-24. Nó không đụng đến trọng số Qwen 4, và không có hạng Qwen 4 nào có trọng số để đụng đến. Tín hiệu cần đọc ở đây là về năng lực phục vụ cho một kiến trúc xem trước, chứ không phải về tính sẵn có của dòng này.

Nếu một model card ghi qwen4_exp, thì đó có phải là Qwen 4 không?

Không — và đây chính là cái bẫy đặt tên trong toàn bộ câu chuyện. qwen4_exp là định danh kiến trúc nội bộ, và đó là thứ bạn sẽ thấy trong config.json đối với Qwen3.8-Flash-Next và phiên bản anh em FP8 của nó. “Experimental” là từ khóa cốt yếu: trọng số đã được công bố, kiến trúc là thật, và mô hình là bản xem trước của thứ mà dòng Qwen 4 được kỳ vọng sẽ được xây dựng dựa trên. Việc tìm kiếm định danh và thấy một PR SGLang hoặc vLLM có Qwen4Exp trong tiêu đề chỉ cho bạn biết về công việc của engine, không phải về một bản phát hành.

Đây có phải là câu chuyện Ascend đối đầu NVIDIA không?

Không hẳn. Cùng đường attention đó cũng cần một adapter chuyên dụng ở phía NVIDIA — song song hóa ngữ cảnh decode cho QSA trong vLLM, và một kernel prefill thưa native cho Hopper — và các vấn đề trên DGX Spark cho thấy thời gian kernel của QSA, PLE và Gated DeltaNet cũng chiếm phần lớn trong decode ở đó. Bộ đánh chỉ mục micro-block của QSA và trạng thái selector được nhân bản của nó đơn giản không phải là thứ mà các kernel paged-attention tổng quát giả định. Đóng góp của Ascend cho khuôn mẫu này là ràng buộc gay gắt hơn: một bộ tiler tỉ lệ head chỉ chấp nhận lũy thừa của hai, điều này buộc phải có padding mà adapter phải che giấu.

Điều cần chú ý

Không phải chuyện cái này có được hợp nhất hay không. Adapter trung thực về việc nó là một adapter, các kiểm thử tính đúng đắn có thể tái lập mà không cần checkpoint, và tác giả đã nêu ra câu hỏi tích hợp thay vì giả vờ rằng nó đã ngã ngũ. Điều cần để mắt tới là chuyện gì xảy ra sau khi dòng kích hoạt NPU và đường attention này được kết hợp — liệu nhánh tích hợp có nhận được lần chạy end-to-end mà cả hai đều chưa từng có hay không, trên batching thật với mô hình đầy đủ thay vì các tensor hình dạng head cục bộ. Con số 1.713× là con số sẽ được lan truyền, và nó là con số được tính trên một bản build khác, trên một checkpoint đã được thích ứng, với một indexer không hoạt động. Một con số đo được trên stack hoàn thiện sẽ đáng giá hơn đáng kể so với một con số lịch sử.

Cho đến lúc đó, bản tóm tắt trung thực chính là bản mà chính PR vẫn bám theo: phần tính toán đúng, cờ bị tắt theo mặc định, CI đang đỏ, và model trong tiêu đề vẫn chưa tồn tại.