Qwen 4 QSA có tính năng song song hóa ngữ cảnh giải mã: bên trong PR nháp của vLLM dành cho Qwen3-Flash-Next

Vào ngày 2026-09-29, một pull request nháp đã xuất hiện trong kho vLLM với tiêu đề “[Model][DCP] Support Qwen4Exp QSA”, và đối với mô hình mà nó mô tả, nó mang những con số phục vụ cụ thể nhất mà bất kỳ ai đã công bố trong cả tháng: các lần chạy ghép cặp Qwen3.8-Flash-Next trên bốn GPU cho thấy dung lượng token KV tăng từ 9,759,529 lên 17,603,636, mức đồng thời tối đa từ 37.23× lên 67.15×, và thời gian đến token đầu tiên giảm từ 1,869 ms xuống 767 ms. Qwen3.8-Flash-Next là bản xem trước mixture-of-experts 125 tỷ tham số, trọng số mở, mà thẻ Hugging Face của nó mô tả là “A Preview of the Qwen4 Architecture”; pull request này bổ sung decode context parallelism vào đường sparse-attention mà kiến trúc đó được xây dựng xoay quanh. Bản thân Qwen4 — các phiên bản Qwen4 Max, Flash, Plus và 27B mà nhà cung cấp đã nêu tên tại hội nghị Apsara của mình vào ngày 2026-09-22 — vẫn chưa được phát hành, không có trọng số, không có mã định danh, không có giá và không có ngày. Vậy hãy đọc điều này đúng như bản chất của nó: không phải một màn ra mắt, không phải một benchmark, mà là một hiện vật kỹ thuật cho bạn biết phạm vi phục vụ Qwen4 đang được mở rộng như thế nào trước khi dòng sản phẩm này tồn tại.

Đây là bài viết thuộc dạng những gì chúng ta biết tính đến thời điểm này, và nguồn dẫn ở đây quan trọng hơn mức thông thường. Pull request này là một bản nháp, đang mở và chưa được hợp nhất — vllm-project/vllm#59279, được mở vào 2026-09-29 bởi Sungsoo Ha, một kỹ sư phần mềm của NVIDIA, và vẫn đang ở trạng thái nháp. Mọi con số dưới đây là phép đo ghép cặp của chính tác giả, được báo cáo trong nội dung PR, lấy trên một phiên bản sửa đổi trước đó của cùng công trình. Không có gì ở đây được kiểm toán độc lập, không có gì ở đây đã vào bản phát hành, và lưu ý kèm theo của tác giả đủ quan trọng để có một mục riêng ở dưới.

Pull request thực sự thay đổi những gì

Song song hóa ngữ cảnh giải mã — DCP — là một kỹ thuật phục vụ, không phải là thay đổi mô hình. Thay vì một nhóm GPU giữ toàn bộ KV cache, DCP chia cache đó cho các rank, nhờ đó mỗi rank chỉ đọc lát ngữ cảnh của riêng mình trong khi kết quả attention được kết hợp giữa các rank ở bước cuối. Mấu chốt nằm ở dung lượng: khi cache được phân vùng, một triển khai có thể chứa nhiều hơn hẳn lưu lượng ngữ cảnh dài đồng thời trên cùng phần cứng, đây chính là ràng buộc gây khó chịu khi mỗi yêu cầu mang theo một phần tư triệu token.

Điều phức tạp nằm ở chỗ Qwen Sparse Attention — QSA — không phải là một lớp attention thông thường. Như thẻ mô hình Qwen3.8-Flash-Next nêu rõ, một bộ lập chỉ mục nhẹ nén các key thành các micro-block với tỷ lệ nén là 4, chấm điểm chúng và giữ lại 512 block tốt nhất, tương đương khoảng 2.048 vị trí token, trong khi softmax cuối cùng và việc tổng hợp value vẫn chạy trên K và V chưa được nén. Điều đó có nghĩa là QSA mang nhiều trạng thái hơn một KV cache: có cache chính, và có các cache selector cùng side cache mà bộ lập chỉ mục duy trì. Cách triển khai DCP chung trong vLLM không hề biết về bất kỳ điều nào trong số đó.

Điều mà #59279 làm, theo mô tả của nó, là dạy cho DCP về các phần đặc thù của QSA:

• Mỗi rank đọc phần của riêng nó trong chính KV cache, trong khi bộ chọn và các cache phụ của QSA vẫn được sao chép trên các rank thay vì được phân mảnh.

• Kết quả attention được kết hợp giữa các rank sau thao tác đọc tách.

• Bộ chọn và KV cache chính được giữ trong cùng một nhóm cache, nên chúng không thể lệch nhau.

• Các batch Synthetic V2 bị ngăn chặn việc ghi vào các cache phụ QSA.

Cặp chi tiết cuối cùng đó mới là phần thú vị nếu bạn quan tâm đến tính đúng đắn hơn là thông lượng. Một bộ nhớ đệm attention được phân mảnh mà âm thầm không khớp với một bộ chọn được nhân bản là kiểu lỗi biểu hiện dưới dạng sự suy giảm độ chính xác chậm ở ngữ cảnh dài thay vì một cú sập, và thay đổi này nói rõ về việc giữ hai thứ đó đồng bộ với nhau. Tác giả cũng nêu rằng có sử dụng sự hỗ trợ của AI và Codex được ghi nhận là đồng tác giả — điều này đáng nói thẳng ra, bởi vì trong một PR nháp có hình dạng như thế này, việc hỏi ai đã viết phần nào là một câu hỏi hoàn toàn hợp lý.

Các số được ghép cặp, và cách chúng được thu thập.

Kế hoạch kiểm thử đủ cụ thể để có thể kiểm chứng, đó là lý do vì sao các kết quả đáng được trích dẫn. Cả hai nhánh đều phục vụ Qwen/Qwen3.8-Flash-Next-FP8 trên bốn GPU với tensor parallelism 4 và expert parallelism được bật, ở --gpu-memory-utilization 0.90 với prefix caching được bật. Điểm khác biệt duy nhất giữa hai nhánh là --decode-context-parallel-size: bỏ qua đối với DCP=1, đặt thành 2 đối với DCP=2, kèm khởi động lại giữa hai nhánh để benchmark bắt đầu từ cache lạnh. Tải là một trace AgentX 256k ở 128 người dùng trong 900 giây; độ chính xác là EvalScope cho GSM8K cùng với trình đánh giá MRCR đã được check-in, chạy sáu lần mỗi nhánh với lần chạy đầu tiên sau khi khởi động lại bị loại bỏ.

Các mức chênh lệch thông lượng được báo cáo, DCP=2 so với DCP=1:

• KV tokens — 9.759.529 so với 17.603.636, mức tăng 1,80× về dung lượng bộ nhớ đệm.

• Mức đồng thời tối đa — 37,23× so với 67,15×, cũng là 1,80×.

• Số yêu cầu mỗi giây — 1,69 so với 2,30, 1,36×.

• Token đầu vào mỗi giây — 128.730 so với 179.702, 1,40×.

• Thời gian đến token đầu tiên — 1.869 ms so với 767 ms, thấp hơn 2,44 lần.

• Độ trễ giữa các token — 43,48 ms so với 26,27 ms, thấp hơn 1,66×.

• Tỷ lệ trúng bộ đệm tiền tố ở trạng thái ổn định — 67,85% so với 88,98%, mức tăng 21,1 điểm phần trăm.

Độ chính xác, được báo cáo dưới dạng trung bình ± độ lệch chuẩn mẫu trên các lần chạy sau khởi động, về cơ bản là không đổi: tổng hợp MRCR 0,8630 ± 0,0005 tại DCP=1 so với 0,8697 ± 0,0153 tại DCP=2, và GSM8K 0,9788 ± 0,0020 so với 0,9790 ± 0,0016. Các mẫu MRCR 2-needle và 4-needle được cố định ở 0,9960 và 0,9906 trên cả hai nhánh, vì vậy toàn bộ biến động giữa các lần chạy đều đến từ các mẫu 8-needle — và một lần chạy tổng hợp DCP=2 đạt 0,8970 trong khi bốn lần còn lại nằm trong khoảng từ 0,8620 đến 0,8632. Đó là một độ phân tán thực sự, không phải nhiễu có thể gạt đi, và nó được nêu trong PR thay vì bị làm mờ đi.

Những con số này không chứng minh được điều gì

Lưu ý cảnh báo nằm trong nội dung PR và nó không hề nhỏ. Các kết quả AgentX và độ chính xác được ghép cặp đã được đo trên một bản sửa đổi trước đó của QSA DCP, sử dụng bản vLLM nightly dựa trên commit 3df4ae153eb. Commit sạch cuối cùng trong pull request bao gồm một bản sửa lỗi kernel định vị QSA sau đó và đã vượt qua xác thực B200 tập trung — nhưng các đánh giá đầy đủ về AgentX và độ chính xác chưa được lặp lại trên chính nguồn đó. Nói cách khác: câu chuyện về thông lượng và bản diff được phát hành không phải là cùng một tạo phẩm, và tác giả đã nói rõ điều đó.

Ngoài điều đó ra, kỷ luật thông thường vẫn được áp dụng, và ở đây nó được áp dụng rất nghiêm ngặt. Đây là những con số từ một cấu hình duy nhất, do một người đóng góp duy nhất thực hiện trên một thiết lập bốn GPU duy nhất. Chúng mang tính gần gũi với nhà cung cấp hơn là trung lập: việc một người đóng góp cho framework đo lường một thay đổi của framework là điều bình thường và hữu ích, nhưng đó không phải là một cuộc kiểm toán độc lập, và chưa có bên thứ ba nào tái lập được lần chạy này. Không có phiên bản vLLM nào đã phát hành mà bạn có thể cài đặt hôm nay chứa thay đổi này, vì thay đổi đó chưa được hợp nhất. Và DCP=2 là một cách chia đôi của một hình dạng cụ thể — các mức chênh lệch không phải là lời hứa về những gì DCP=4 hay DCP=8 sẽ làm, và không có gì trong PR khẳng định chúng là như vậy.

Vì sao một PR về serving cho một kiến trúc chưa phát hành vẫn đáng để bạn dành thời gian

Phản đối hiển nhiên: mô hình trong tiêu đề không tồn tại, vậy tại sao phải quan tâm? Bởi vì thứ đang được tinh chỉnh không phải là Qwen 4. Đó là Qwen3.8-Flash-Next, và mô hình đó thực sự tồn tại — Alibaba đã công bố nó vào ngày 2026-08-24 dưới dạng một MoE 125B tham số với 6B được kích hoạt, một bảng nhúng n-gram 51 tỷ tham số, một đầu MTP 4B cho việc giải mã suy đoán, 48 lớp được sắp xếp thành mười hai lần lặp của ba khối Gated DeltaNet theo sau là một khối QSA, 512 chuyên gia với 10 chuyên gia được định tuyến và 1 chuyên gia dùng chung đang hoạt động, và ngữ cảnh gốc 262.144 token mà model card cho biết có thể mở rộng lên 1.000.000. Đây là bản triển khai tham chiếu của kiến trúc Qwen4 dưới dạng trọng số mở, và QSA — cơ chế attention thưa micro-block mà pull request này đang dạy DCP cách phân mảnh — chính là phần đặc trưng nhất của nó.

Những gì các con số mô tả là điều xảy ra khi bạn ngừng coi ngữ cảnh 262K đó như một thứ mà một nhóm GPU phải giữ nguyên vẹn. Mức tăng 1.80× về dung lượng token KV và khả năng đồng thời là phép tính của việc tách một bộ đệm làm hai, và đó là kết quả ít gây ngạc nhiên nhất trong danh sách. Những con số thú vị hơn là các chỉ số độ trễ: thời gian đến token đầu tiên thấp hơn 2.44× và độ trễ giữa các token thấp hơn 1.66× ở cùng mức tải đưa vào, cộng với mức cải thiện 21 điểm trong tỷ lệ trúng bộ đệm tiền tố ở trạng thái ổn định. Những điều đó cho thấy đường DCP không chỉ đơn thuần đạt được dung lượng với cái giá là độ trễ — trong lần chạy ghép cặp này, nó đạt được cả hai. Đó chính là dạng thay đổi có ý nghĩa với bất kỳ ai phục vụ lưu lượng agent với các system prompt rất dài, bởi vì hành vi bộ đệm tiền tố ở ngữ cảnh dài thường là nơi thông lượng ngữ cảnh dài lặng lẽ chết đi.

Và đây không phải là một bản vá đơn lẻ. Cùng tuần đó đã tạo ra một cụm công việc về engine Qwen4Exp: #59214 bổ sung các kế hoạch GEMM giải mã độ trễ thấp SM100 cho các hình dạng B200, #59010 bổ sung một kernel prefill thưa gốc SM90 cho đường QSA trên Hopper, #58977 bao gồm embeddings BF16 INC PLE, và #58961 — bản đã thực sự được hợp nhất, vào 2026-09-28 — đã sửa một KV cache dùng cho profiling mà các view khóa QSA vẫn đang giữ cho tồn tại. Đọc cùng nhau, chúng là đường bao phục vụ của kiến trúc Qwen4 đang được xây dựng công khai, trong các runtime, nhiều tháng trước khi dòng sản phẩm này ra mắt. Nếu bạn đang lập kế hoạch cho Qwen 4, tín hiệu hữu ích không phải là ngày ra mắt — vốn không có — mà là những gì các kernel và bố cục cache đã giả định về cách bạn sẽ phải phục vụ nó.

Những gì bạn có thể gọi hôm nay

Nếu bạn muốn kiểm thử hành vi ngữ cảnh dài trên kiến trúc mà PR này đề cập, mô hình bạn nên tìm đến là bậc Flash mà Alibaba thực sự cung cấp. Qwen3.8-Flash — bản triển khai production được xây dựng trên Qwen3.8-Flash-Next, với ngữ cảnh 1.000.000 token và đầu ra tối đa 131.072 token, nhận đầu vào văn bản, hình ảnh và video — đã hoạt động, và nó là một endpoint cho mô hình thực sự chạy kiến trúc Qwen4Exp ngày hôm nay, được liệt kê là qwen/qwen3.8-flash ở mức 0,15 USD mỗi triệu token đầu vào và 0,47 USD mỗi triệu token đầu ra, với giá đọc bộ nhớ đệm là 0,0184 USD. Vì đây là giá niêm yết của nhà cung cấp được chuyển tiếp mà không có phụ phí từ phía chúng tôi, nên thay đổi về giá hoặc giới hạn từ nhà cung cấp đối với mô hình này sẽ đến với bạn ngay trong ngày được công bố.

Hai lưu ý thẳng thắn. Thứ nhất, bản thân Qwen3.8-Flash-Next — trọng số FP8 trong kế hoạch kiểm thử của pull request, những trọng số mà bạn sẽ cần để tái tạo bất kỳ phép đo nào trong số này tại chỗ — không nằm trong danh mục của chúng tôi; tầng Flash được phục vụ là dòng production của QwenCloud, không phải checkpoint preview thô. Nếu bạn muốn chạy cấu hình chính xác trong PR thì bạn đang tự vận hành trên bốn GPU. Thứ hai, thay đổi DCP chưa được hợp nhất, nên không có thứ gì bạn có thể gọi ở bất cứ đâu hôm nay đang chạy nó. Điều mà tầng được phục vụ mang lại cho bạn là một cách để tìm ra liệu khối lượng công việc của bạn có thực sự được định hình cho bài toán mà DCP giải quyết hay không: nếu các prompt của bạn dài, mang tính agentic và nặng về prefix, thì dung lượng 1,80× và mức chênh lệch prefix-cache là những con số cần theo dõi trong dấu vết của chính bạn.

Và nếu phần thú vị đối với bạn không phải là một mô hình đơn lẻ mà là câu hỏi chuyển đổi — nên xây dựng trên tầng nào trong khi dòng Qwen 4 vẫn chưa có tên — thì đó là một bài toán định tuyến chứ không phải bài toán phục vụ, và một API cho hơn 200 mô hình chính là cách bạn giữ ngỏ khả năng lựa chọn mà không cần hợp đồng thứ hai hay thay đổi mã nguồn khi dòng mô hình này cuối cùng cũng ra mắt.

Những câu hỏi đáng được trả lời trực tiếp

Có phải #59279 nghĩa là Qwen 4 đã ra mắt, hay sắp ra mắt rồi?

Không. Pull request này nói về kiến trúc Qwen4Exp như được triển khai trong Qwen3.8-Flash-Next, bản mà Alibaba đã phát hành vào 2026-08-24. Gia đình Qwen 4 — Max, Flash, Plus và 27B — đã được xướng tên trên sân khấu tại Apsara vào 2026-09-22 và được đưa vào lộ trình của công ty với một dòng kế nhiệm được dự phóng ở mức 5 đến 10 nghìn tỷ tham số, và nó vẫn chưa có thẻ mô hình, chưa có trọng số, chưa có mã định danh API, chưa có cửa sổ ngữ cảnh, chưa có giá và chưa có ngày. Một PR của framework bổ sung một chế độ song song hóa vào kiến trúc xem trước là một bước tiến tới việc phục vụ Qwen 4 tốt. Đó không phải là một bước tiến tới việc Qwen 4 tồn tại.

Decode context parallelism khác gì so với tensor parallelism?

Chúng chia tách những thứ khác nhau và thất bại theo những cách khác nhau. Song song hóa tensor phân vùng trọng số và phép tính của mỗi tầng trên khắp các GPU, nên mọi rank đều tham gia vào mọi token nhưng lại nhìn thấy toàn bộ chuỗi. Song song hóa ngữ cảnh giải mã phân vùng chính bộ nhớ đệm KV, nên mỗi rank chỉ lưu giữ và đọc một lát cắt của ngữ cảnh, còn các kết quả attention từng phần sẽ được hợp nhất sau đó. TP là chuyện chứa vừa mô hình; DCP là chuyện chứa vừa ngữ cảnh cùng lưu lượng đồng thời đi kèm với nó. Chính sự khác biệt đó là lý do vì sao PR này không hề tầm thường: bộ chọn và các bộ nhớ đệm phụ của QSA không thể đơn giản bị phân mảnh theo cách bộ nhớ đệm KV chính có thể, nên thay đổi này buộc phải phân mảnh một cái và sao chép những cái còn lại, rồi chứng minh rằng cả hai vẫn nhất quán.

Nếu hôm nay tôi gọi Qwen3.8-Flash-Next qua một API được host, liệu tôi đã nhận được những con số này chưa?

Không, và khoảng cách này có ba phần. Thay đổi đó chưa được hợp nhất, nên không có bản phát hành vLLM nào chứa nó. Ngay cả khi đã được hợp nhất, nhà cung cấp vẫn phải chấp nhận bản dựng đó và chọn chạy với kích thước DCP lớn hơn một — đây là một cấu hình phục vụ, không phải mặc định. Và các mức chênh lệch đo được là từ một bản sửa đổi trước đó của bản vá, chứ không phải commit cuối cùng, mà theo tác giả thì commit cuối cùng đến nay mới chỉ được xác thực tập trung trên B200. Hãy coi các mức chênh lệch được báo cáo là một giới hạn trên được ghi chép đầy đủ về những gì cách tiếp cận này mang lại trong một cấu hình, chứ không phải là đặc tả của bất kỳ endpoint nào bạn có thể thuê trong tuần này.

Câu hỏi mở

Điều cần để mắt tới không phải là liệu bản dự thảo cụ thể này có được hợp nhất hay không — nhiều khả năng nó sẽ được hợp nhất dưới một dạng nào đó, vì phần xử lý cache dành riêng cho QSA mà nó bổ sung là một khoảng trống thực sự chứ không phải một sở thích. Điều cần để mắt tới là liệu bản commit cuối cùng có nhận được đánh giá theo cặp giống như bản sửa đổi trung gian đã nhận được hay không. Một thay đổi ở lớp serving mà các tuyên bố về thông lượng đến từ một bản build còn các tuyên bố về tính đúng đắn đến từ một bản build khác thì, hiện tại, vẫn là một đề xuất có lập luận tốt chứ không phải một kết quả được đo lường, và độ phân tán độ chính xác ở các mẫu MRCR 8-needle đủ rộng đến mức chạy lại trên nguồn đã phát hành sẽ là việc hữu ích nhất mà bất kỳ ai có thể công bố về nó. Cho đến lúc đó: hướng đi là rõ ràng, sổ sách vẫn chưa được khép lại, và mô hình kiến trúc Qwen4 duy nhất có trọng số mở vẫn là mô hình từ tháng Tám.