Rò rỉ Qwen 4: SGLang chia nhỏ Prefill của Qwen4Exp để TTFT nhanh hơn 18% và lấy lại một GiB cho mỗi GPU

Một pull request được mở trong kho SGLang lúc 03:47 UTC sáng nay, 2026-10-08, hứa hẹn một thứ mà chưa có thông báo Qwen 4 nào tạo ra: một con số. Nó có tiêu đề feat(qwen4-exp): bật song song hóa chuỗi LayerNorm cho GR và PLE, và trên bốn GPU H20 đang chạy checkpoint trọng số mở Qwen3.8-Flash-Next trong FP8, tác giả của nó báo cáo mức cải thiện thời gian đến token đầu tiên là 17,7–18,4% ở đầu vào 32K và 14,6–14,7% ở đầu vào 235K, trả lại khoảng một gigabyte bộ nhớ đỉnh trên mỗi GPU, và tăng tới 22% thông lượng đầu vào. Qwen 4 — họ mô hình mà nhà cung cấp đã đặt tên nhưng không phát hành tại hội nghị Apsara ở Hàng Châu 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 và không có giá. Mô hình duy nhất hiện thực hóa kiến trúc Qwen4Exp hiện nay là Qwen3.8-Flash-Next, được công bố vào ngày 2026-08-26, và người anh em được quản lý của nó Qwen3.8-Flash là phiên bản mà người gọi API thực sự có thể truy cập. Vậy hãy đọc phần tiếp theo đúng như bản chất của nó: các phép đo theo cặp của một kỹ sư, được đính kèm vào một pull request mở, bản nháp, chưa hợp nhất, về phạm vi phục vụ của một họ mô hình chưa tồn tại.

Trước tiên là về nguồn, vì đây là một bài rò rỉ và sự phân biệt này thực sự có ý nghĩa. Tín hiệu là sgl-project/sglang#43048, được mở vào 2026-10-08 lúc 03:47 UTC bởi tài khoản GitHub shiyang814-cpu, được cập nhật lần cuối lúc 03:55 UTC, và vẫn được đánh dấu là bản nháp, không có đánh giá phê duyệt nào được ghi nhận và không được hợp nhất. Nó thay đổi sáu tệp — hai tệp kiểm thử, tệp mô hình Qwen4Exp, mô-đun LayerNorm-SP, một factory ranh giới lớp và một hook nhóm đối số — với +345 và −50 dòng. Mọi số liệu hiệu năng bên dưới đều đến từ mô tả PR, là phép đo OFF/ON theo cặp của chính tác giả, và chưa được bất kỳ ai tái lập. Ba lần chạy CI trên bản sửa đổi ở đầu nhánh đều được đánh dấu là thất bại. Không có gì ở đây là một tính năng đã được phát hành.

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

Song song theo chuỗi không phải là một thay đổi mô hình và cũng không phải là một năng lực mới. Nó là việc đấu dây lại nơi một vài lớp thực hiện phép tính của chúng. Nó có nguồn gốc từ song song theo chuỗi kiểu Megatron — thủ thuật từ arXiv:2205.05198 — và SGLang đã cung cấp nó: docstring của chính mô-đun giải thích cơ chế mà nó tái sử dụng, rằng dưới song song tensor thuần túy, một all_reduce song song theo hàng là tương đương đại số với một reduce_scatter theo sau bởi một all_gather. Bởi vì hai collective đó di chuyển đúng số byte như all_reduce duy nhất mà chúng thay thế, việc tách thao tác theo cách đó không tốn thêm dung lượng truyền thông nào cả. Thứ nó mang lại là tự do cho các vùng chuẩn hóa và phần dư chạy trên sequence-sharded activation — mỗi rank song song tensor giữ một-1/tp số hàng token — điều này cắt giảm bộ nhớ activation tạm thời mà prefill ngữ cảnh dài cần giữ sống.

Điều mà pull request cụ thể này làm là mở rộng đường dẫn hiện có đó từ kiến trúc mà nó đã được xác thực sang kiến trúc Qwen4Exp. Trong giai đoạn prefill, các activation Gated Residual và Per-Layer Embedding vẫn được shard theo chiều token trên khắp nhóm TP. Trước attention, trước GDN, trước QSA và trước khi khối Mixture-of-Experts chạy, toàn bộ các hàng token được all-gather trở lại, phép tính tensor-parallel toàn hàng hiện có vẫn chạy không đổi phía sau một fallback dùng chung, và sau đó một reduce-scatter cộng các đóng góp riêng phần và khôi phục shard của từng rank. Decode hoàn toàn không chạm tới đường dẫn mới. Tính năng này được truy cập thông qua tùy chọn vốn đã tồn tại — --enable-layernorm-sp — mà không có cờ riêng cho Qwen4Exp, và khi không có cờ đó, mã hoạt động y hệt như trước đây.

Tại sao Qwen4Exp là kiến trúc cần điều này

Lý do điều này đặc biệt quan trọng với Qwen4Exp, chứ không phải quan trọng ngang nhau với mọi mô hình, nằm ở chính thiết kế kiến trúc. Qwen3.8-Flash-Next áp dụng các phép chiếu Gated Residual cho tất cả các hàng token trong mỗi lớp decoder — cấu hình khai báo bốn luồng residual và hạng nút cổ chai là 320 trên 48 lớp — và Per-Layer Embedding bổ sung thêm một phép chiếu thứ hai được sao lặp, theo từng hàng token, lên trên đó. Dưới tensor parallelism, cả hai phép toán đó đều được nhân bản giống hệt nhau trên mỗi rank, bởi vì chúng không mang ma trận trọng số được chia theo TP của riêng mình để buộc phải tách ra. Việc sharding chiều token của chúng loại bỏ trực tiếp phần công việc bị sao lặp, và như mục động lực của PR diễn đạt, điều đó xảy ra trong khi vẫn bảo toàn bố cục tensor-parallel hiện có cùng ngữ nghĩa rút gọn của attention, GDN/QSA và MoE — và đây chính là phần khiến thay đổi này an toàn thay vì chỉ thông minh.

Cần nói thẳng điều đó có ý nghĩa gì với người đọc. Điều thú vị ở PR này không phải là SGLang đang trở nên nhanh hơn. Mà là kiến trúc Qwen4 mang các chi phí theo từng lớp tăng theo số lượng token thay vì theo số lượng tham số, và chính những chi phí đó là thứ gây ảnh hưởng nặng trong các prefill dài. Đó là một dấu vân tay thiết kế, và đó là kiểu điều mà bảng thông số kỹ thuật không bao giờ đề cập.

Các delta đo được

Bài benchmark của tác giả cố định một cấu hình và bật/tắt cờ: bốn GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, tensor parallel 4 và expert parallel 4, kích thước chunked prefill 8192, các backend prefill và decode linear-attention của FlashInfer, cùng một cấu hình máy chủ cho cả OFF và ON, khởi động lại dịch vụ luân phiên theo OFF → ON → OFF → ON, và các đầu vào token cố định kèm các request warmup. Mọi số liệu dưới đây đều đến từ thiết lập đó và chưa được kiểm toán:

• Đầu vào 32K, kích thước lô 1 — TTFT cải thiện 17,72–18,36%, độ trễ đầu cuối khoảng 16%, thông lượng đầu vào khoảng 20%

• Đầu vào 235K, kích thước lô 1 — TTFT được cải thiện 14,63–14,71%, độ trễ đầu-cuối khoảng 14%, thông lượng đầu vào khoảng 17%

• Đầu vào 32K, kích thước lô 4 — TTFT cải thiện 18,74%, độ trễ đầu-cuối 18,14%, thông lượng đầu vào 22,14%

• Bộ nhớ đỉnh — giảm khoảng 1,0 GiB trên mỗi GPU

• Giải mã, kích thước lô 1 — thời gian trên mỗi token đầu ra hầu như không thay đổi

Dòng cuối là dòng cần đọc hai lần, và tác giả thẳng thắn về lý do: tối ưu hóa này chỉ được bật cho prefill, nên decode đơn luồng chẳng nhận được gì từ nó. Cải thiện thời gian mỗi token ở batch-4, khi xuất hiện, phản ánh việc giảm độ trễ lập lịch nhờ các prefill dài chạy đồng thời chứ không phải nhờ bất kỳ kernel decode nào nhanh hơn. Nếu bạn hy vọng đây là một câu chuyện về thông lượng, thì không phải — đây là câu chuyện về độ trễ đến token đầu tiên và bộ nhớ, và đó chính là hai ràng buộc quyết định liệu một yêu cầu 235K token có thể phục vụ được hay không.

Lỗi bố cục mà họ phải sửa trước tiên

Phần giàu thông tin nhất của pull request không phải là bảng tăng tốc. Mà là phần về bố cục hàng vật lý của PLE, vì nó cho thấy ngăn xếp phục vụ Qwen4Exp vẫn còn làm sai ở điểm nào.

Per-Layer Embedding hoạt động trên một bucket CUDA-graph vật lý cố định, trong khi chỉ một tiền tố của các hàng trong bucket đó có thể chứa token thật. Do đó, phần đệm phải được áp dụng trước khi chuỗi được shard, chứ không phải sau. Trong phân đoạn cuối cùng của một yêu cầu 235K token, các con số của tác giả là 5.624 token đã xử lý bên trong một bucket vật lý 8.192 hàng tại TP 4, và cách bố trí đúng duy nhất là rank 0 giữ 2.048 hàng hợp lệ, rank 1 giữ 2.048 hàng hợp lệ, rank 2 giữ 1.528 hàng hợp lệ cộng 520 hàng đệm, và rank 3 giữ 2.048 hàng đệm. Việc chia shard 5.624 hàng đã xử lý trước — cách triển khai hiển nhiên — chèn phần đệm vào giữa các dải hợp lệ liền kề trên toàn cục và làm hỏng kết quả. Tác giả ghi lại rằng một thử nghiệm OFF/ON 235K thực tế chỉ tạo ra đầu ra tham lam 16 token giống hệt nhau sau khi bố cục này được sửa.

Đó là một chi tiết nhỏ mang hàm ý lớn. Luồng PLE trong SGLang mới được thêm vào gần đây đến mức một lỗi thứ tự token kiểu này vẫn còn có thể gặp, và người phát hiện ra nó đang viết phần mở rộng song song chuỗi. Hỗ trợ phục vụ ngay từ ngày đầu cho kiến trúc này vẫn chưa hoàn thiện; nó đang được những người đóng góp tích cực xây dựng, công khai, từng bố cục một.

Điều đó khiến bạn phải trả giá: những ràng buộc

Một cờ chỉ hỗ trợ một số triển khai nhất định thì chỉ hữu ích nếu bạn biết đó là những triển khai nào. PR nêu rõ các yêu cầu của nó, và những cấu hình nằm ngoài phạm vi đó sẽ thất bại trong quá trình xác thực đối số thay vì âm thầm suy giảm:

• Kích thước tensor song song phải lớn hơn 1 — triển khai trên một GPU duy nhất chẳng đem lại lợi ích gì, vì không có rank nào để phân mảnh.

• Expert parallel size phải bằng tensor parallel size

• Kích thước song song pipeline phải bằng 1

• Phải vô hiệu hóa attention song song dữ liệu

• Giải mã suy đoán phải được tắt.

Ràng buộc cuối cùng là ràng buộc có một quyết định thực sự đằng sau nó. Đối với một mô hình thưa chỉ kích hoạt khoảng 6B tham số mỗi token, giải mã suy đoán là một trong số ít đòn bẩy giúp tăng tốc giải mã, và tính năng này chủ động tắt đòn bẩy đó để đổi lấy lợi thế ở prefill. Nếu khối lượng công việc của bạn là prompt dài và đầu ra ngắn — phân tích tài liệu và cơ sở mã, tóm tắt video, một ngữ cảnh lớn chỉ đọc một lần — thì sự đánh đổi này rõ ràng là có lợi. Nếu khối lượng công việc của bạn là prompt ngắn và sinh dài, bạn đang từ bỏ thứ vốn đang giúp ích cho mình và mua lấy một con số không áp dụng cho bạn. Yêu cầu song song chuyên gia bằng song song tensor là điều thứ hai cần lưu ý: nó có nghĩa là hình học phân mảnh MoE phải khớp chính xác với hình học TP, điều này loại bỏ một số bố cục đa nút mà nếu không thì vẫn hợp lý.

Điều này cho thấy gì về lộ trình của Qwen 4

Đọc diff theo một cách khác và bạn sẽ có một cuốn lịch. Mô-đun LayerNorm-SP của SGLang trên nhánh chính hiện nay mang một danh sách cho phép tường minh các kiến trúc mà tính năng này đã được kiểm chứng, và tính đến thời điểm viết bài này, danh sách cho phép đó chỉ chứa đúng một mục, Qwen3ForCausalLM — mọi kiến trúc khác đều bị từ chối ngay khi khởi tạo nếu bạn truyền cờ này. Do đó, việc thêm Qwen4Exp vào đường đi đó không phải là một chỉnh sửa nhỏ đối với một trừu tượng đã trưởng thành; đây là lần đầu tiên kiến trúc Qwen4 được đưa lên một tối ưu hóa ra đời trước nó nhiều thế hệ.

Đặt điều đó bên cạnh hồ sơ công khai thì bức tranh trở nên mạch lạc. Nhà cung cấp đã công bố vào ngày 2026-09-22 rằng Qwen 4 đang được huấn luyện và giới thiệu trước bốn tên hạng — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus và Qwen 4 27B — mà không kèm thông số kỹ thuật nào cho bất kỳ tên nào trong số đó. Bản xem trước trọng số mở có cùng kiến trúc, Qwen3.8-Flash-Next, đã có thể tải xuống kể từ 2026-08-26. Những gì đang diễn ra trong ba tuần kể từ đó đúng chính xác là điều bạn sẽ mong đợi giữa "đang huấn luyện" và "ra mắt": các tác giả engine đang chạy thử runtime để hỗ trợ ngay ngày đầu là thật chứ không chỉ trên danh nghĩa. Một pull request giúp một tối ưu phục vụ hoạt động trên kiến trúc, được mở vào sáng 2026-10-08 và vẫn ở dạng nháp, là tín hiệu tốt hơn về việc Qwen 4 sắp có thể phục vụ được đến đâu so với bất kỳ ngày nào mà ai đó đã đưa ra. Và dứt khoát, đó cũng không phải là ngày phát hành — cờ bị tắt theo mặc định, thay đổi chưa được hợp nhất, và mô hình mà nó đánh giá hiệu năng là bản xem trước, không phải Qwen 4.

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

Không điều nào trong số đó thay đổi những gì thực sự có sẵn vào chiều nay. Qwen3.8-Flash-Next là thật, trọng số của nó có trên Hugging Face, và bạn có thể tự vận hành nó — nhưng nó không nằm trong danh mục của chúng tôi, và chúng tôi sẽ không giả vờ điều ngược lại. Gói mà chúng tôi thực sự cung cấp là qwen/qwen3.8-flash, phiên bản anh em được quản lý chạy cùng kiến trúc Qwen4-preview với cửa sổ ngữ cảnh 1M token và đầu vào văn bản, hình ảnh và video, có giá $0.15 mỗi triệu token đầu vào, $0.47 mỗi triệu token đầu ra và $0.0184 mỗi triệu lượt đọc bộ nhớ đệm. Đó là giá niêm yết được chuyển thẳng với mức markup 0%, nên khi nhà cung cấp thay đổi giá, con số trên hóa đơn của bạn sẽ thay đổi ngay trong cùng ngày thay vì chờ đến khi một bên trung gian đăng lại bảng giá.

Có một lý do thứ hai, ít rõ ràng hơn để quan tâm đến lớp định tuyến ở đây. Mọi thứ trong bài viết này xoay quanh một bản xem trước chưa được kiểm chứng cùng một bản vá nháp — kiểu thứ bạn muốn thử nghiệm mà không đặt cược một đường dẫn sản xuất vào đó. Đó chính là mục đích của failover: đặt bản xem trước sau cùng một khóa với mô hình bạn đã tin tưởng, theo dõi cách nó hoạt động trên lưu lượng của bạn, và để yêu cầu tự động chuyển sang tuyến đã được kiểm chứng khi nhà cung cấp gặp trục trặc hoặc điểm cuối không tồn tại. Một API cho hơn 200 mô hình, một bộ thông tin xác thực, không cần ký hợp đồng thứ hai để tìm hiểu liệu một kiến trúc mới có đáng để bạn quan tâm hay không.

Hai điều cần theo dõi từ đây, và không điều nào trong số đó chúng ta có thể dự đoán được. Điều thứ nhất là liệu bản vá này có được hợp nhất hay không: đây là một bản nháp với ba lần chạy CI thất bại trên một thay đổi gồm sáu tệp từ một tài khoản cộng tác viên không có lịch sử trước đó trong kho, và sự linh hoạt của công việc bố cục hàng PLE cho thấy tác giả vẫn đang lặp chỉnh sửa. Điều thứ hai là liệu danh sách cho phép có lớn thêm — nếu Qwen4Exp tham gia Qwen3ForCausalLM với tư cách là một kiến trúc đã được xác thực, thì điều này không còn là một rò rỉ nữa mà trở thành cách mặc định để một mô hình thuộc họ Qwen4 được phục vụ trên ngữ cảnh dài. Cho đến khi một trong những điều đó xảy ra, hãy coi 18% là một lời hứa về việc runtime sẽ đi đến đâu, chứ không phải một con số bạn có thể thuê.