Rò rỉ Qwen 4: PR Host-Staging của SGLang cho thấy cách bảng PLE 47,7 GiB vừa vặn trên một GPU

Con số sẽ quyết định liệu Qwen 4 có phải là một mô hình bạn có thể tự phục vụ hay không, chứ không phải là số lượng tham số của nó. Đó là 47,7 GiB — kích thước của bảng nhúng n-gram đi kèm kiến trúc Qwen4, tách biệt khỏi trọng số, và phải nằm ở đâu đó trong khi mô hình giải mã. Một pull request được mở trong kho SGLang vào ngày 18 tháng 9 năm 2026, có tiêu đề [Qwen4-Exp] Thêm staging trên host cho PLE dựa trên tệp, là một nỗ lực nhằm ngăn bảng đó quyết định lượng RAM mà một máy cần có trước khi nó có thể chạy được. Qwen 4 vẫn chưa phát hành: không có model card, không có trọng số, không có mục trong danh mục, không có ngày. Mô hình duy nhất đã phát hành hiện thực hóa kiến trúc này là Qwen3.8-Flash-Next, bản xem trước trọng số mở được công bố ngày 26 tháng 8 năm 2026, với cấu hình khai báo model_type=qwen4_exp — cùng chuỗi ký tự đã đặt tên cho pull request. Phiên bản sản xuất cùng dòng 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 ngày hôm nay. Mọi thứ trong bài viết này về Qwen 4 đều là suy luận từ bản xem trước đó và từ mã engine; pull request đang mở và chưa được hợp nhất, nên hãy đọc tất cả như một tín hiệu, không phải một năng lực đã được phát hành.

Tín hiệu thực sự là gì

Yêu cầu kéo sgl-project/sglang#40235 không phải là một bản ra mắt và nó chưa được hợp nhất. Nó nằm trên một commit, được mở bởi người đóng góp Dev-Jahn, hợp nhất một nhánh có tên task/ple-host-staged vào nhánh chính của SGLang. Chín code owner đã được yêu cầu đánh giá và tất cả đều hiển thị là đang chờ, vì vậy ít nhất một đánh giá phê duyệt đang nằm giữa điều này và nhánh main. Ba tác vụ CI — bài kiểm tra PR cơ sở, bài kiểm tra PR bổ sung và lượt chạy AMD ROCm — đang thất bại trên commit đang mở. Đó là tình trạng bình thường của một thay đổi engine lớn đang diễn ra, và cũng là lý do phần thú vị của PR này không phải là liệu nó có được hợp nhất hay không mà là điều mà tác giả của nó đã phải đo lường để lập luận cho nó. Phần mô tả chứa khoảng 1.400 dòng được thêm bao gồm các bài kiểm tra, và một bảng benchmark là dữ liệu công khai cụ thể nhất mà bất kỳ ai từng công bố về việc chạy kiến trúc này trên một GPU đơn.

Vì sao bảng lại là toàn bộ câu chuyện

Embedding theo từng lớp là điểm dị thường về cấu trúc của thế hệ này. Trong khi một mô hình thông thường đặt một embedding token ở phần đầu, thiết kế Qwen4 lại mang một bảng n-gram lớn — bigram và trigram, được băm vào một từ vựng lớn hơn nhiều so với từ vựng của tokenizer — và cung cấp các tra cứu embedding theo từng lớp từ đó xuyên suốt toàn bộ stack. Tài liệu xem trước của chính Alibaba mô tả thành phần n-gram này có hàng chục tỷ tham số, nằm trên phần thân MoE 125 tỷ tham số; các phân tích tháo gỡ của cộng đồng đối với checkpoint đã phát hành đặt tệp bảng ở mức 47,7 GiB. Những con số đó đến từ các nguồn của nhà cung cấp và cộng đồng chứ không phải từ tái lập độc lập, và mối quan hệ chính xác giữa bảng trong bản xem trước với bất cứ thứ gì Qwen 4 thực sự phát hành vẫn chưa được biết.

Điều không còn phải nghi ngờ chính là hệ quả kỹ thuật. Một bảng phụ 47,7 GiB phải được tra cứu ở mọi bước giải mã thì không phải là thứ bạn có thể lặng lẽ nhét vào một góc của VRAM. Trên một card 96 GB, nó cạnh tranh trực tiếp với KV cache; còn trên những card nhỏ hơn, nó đơn giản là không vừa. Đó là lý do vì sao SGLang, bên đã dựng hỗ trợ day-0 cho bản xem trước vào cuối tháng 8, đã dành ba tuần tiếp theo để liên tiếp tạo ra hết pull request này đến pull request khác về chính cấu trúc dữ liệu này, thay vì về mô hình xung quanh nó.

Điều gì đã bị hỏng trước PR này

SGLang vốn đã có hai cách để giữ bảng, và cả hai đều có một giới hạn cứng.

• Pinned giữ toàn bộ bảng trong RAM của máy chủ và đọc dữ liệu từ đó. Nó hoạt động được, nó nhanh, và nó khiến yêu cầu về bộ nhớ máy chủ trở thành tuyệt đối — không có phiên bản nào nhỏ hơn.

• Dựa trên tệp, được thêm vào trước đó trong một pull request riêng, giữ bảng trong một tệp thưa và cho phép kernel gather đọc trực tiếp phần ánh xạ, nhờ đó bộ đệm trang của hệ điều hành quyết định bao nhiêu phần của nó được nạp thường trú. Cái khó nằm ở phần cứng: đường đọc trực tiếp đó đòi hỏi GPU phải báo cáo cudaDevAttrPageableMemoryAccessUsesHostPageTables — năng lực mà chính văn bản của PR gọi nôm na là "lớp GB10". Trên một GPU không có năng lực đó, backend dựa trên tệp bị từ chối hoàn toàn và pinned là lựa chọn duy nhất còn lại.

Khoảng trống mà điều đó tạo ra không phải là vấn đề lý thuyết. Một báo cáo riêng được gửi về cùng code path đó ghi lại trường hợp một người dùng chạy trên hai RTX 3090 có phần chia sẻ bảng trên mỗi rank là 23,84 GiB so với 23,56 GiB bộ nhớ khả dụng — thiếu 0,28 GiB, trong khi 188 GiB RAM máy chủ vẫn còn trống. Trong cấu hình đó, file backend đã bị kiểm tra phần cứng từ chối và cờ CPU-offload thông thường báo lỗi khi kết hợp với cờ PLE offload. Việc thiếu ba trăm megabyte trong khi còn thừa một trăm tám mươi gigabyte chính xác là dạng vấn đề mà pull request này ra đời để loại bỏ.

Những thay đổi staging của máy chủ là gì?

Cơ chế mà PR này thêm vào là một lớp trung chuyển (staging) nằm giữa tệp và thiết bị. Thay vì yêu cầu GPU truy xuất các trang bộ nhớ host, một thành phần phía CPU sẽ đọc những hàng mà nó cần thông qua ánh xạ sẵn có của loader và gợi ý kernel nạp trước các trang đó; một biến môi trường, SGLANG_QWEN4_PLE_FILE_PREFETCH, sẽ tắt gợi ý này nếu bạn muốn đo lường mà không dùng nó. Mỗi lớp PLE sau đó nhận được hai buffer ghim (pinned) gồm 8.192 hàng — khoảng 1,25 MiB mỗi buffer ở FP8 — cùng một worker. Các hàng được gom vào một buffer trong khi buffer kia đang được sao chép sang thiết bị, nhờ đó thao tác gom và truyền tải chồng lấn lên nhau thay vì diễn ra tuần tự. Các định danh n-gram được băm trên host thay vì trên thiết bị. Việc phát lại đồ thị (graph replay) có một lệnh gọi chuẩn bị trước mỗi lần phát lại, và luồng khởi chạy phải chờ bước trước đó.

Chi tiết cuối cùng đó chính là chi phí, và PR nói rõ điều đó: khoảng 0,5 đến 1 mili giây được thêm vào mỗi bước giải mã so với đường dẫn được ghim. Mọi thứ còn lại là phần đáng giá. Được đo trên một RTX PRO 6000 Blackwell duy nhất với 96 GB, một máy chủ AMD EPYC với 377 GiB RAM, CUDA 13.2, sử dụng các checkpoint FP8 và NVFP4 công khai của Qwen3.8-Flash-Next:

• Host page cache, FP8 TP4/EP4 — 71 GB được ghim và không bị giới hạn, so với 49 GB ở mức giới hạn 64 GB, 15 GB ở mức 32 GB, và 6 GB ở mức giới hạn 24 GB

• Độ trễ giải mã, cùng các lần chạy — 8,62 ms mỗi token ở mức đồng thời 1 được ghim, so với 9,16 / 9,20 / 9,12 ms trong ba lần chạy tệp bị giới hạn

• Đồng thời 16 — 16,54 ms ở chế độ ghim so với 17,62 / 17,85 / 17,37 ms ở chế độ giới hạn, tức từ 893 token mỗi giây giảm xuống 827–840

• Thông lượng prefill — 620 token mỗi giây ở mức 8k được ghim so với 624 / 630 / 631 bị giới hạn; ở 32k, 1.347 so với 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB được ghim so với 24 GB với backend tệp ở mức giới hạn 32 GB, ở 8,87 ms so với 9,18 ms

• NVFP4 một GPU — 69 GB được ghim so với 51 GB ở mức giới hạn 64 GB, tại 6,44 ms so với 6,73 ms

• Phương án thay thế mà nó đánh bại — việc đọc cùng tệp đó thông qua quản lý bộ nhớ máy chủ trên GPU ấy đạt 10,8 ms ở mức đồng thời 1 và 46,5 ms ở mức đồng thời 16, mà PR mô tả là gấp 2,8 lần độ trễ pinned ở mức đồng thời đó

Về mặt độ chính xác, kết quả được báo cáo là sạch. Đầu ra greedy tất định trên tám prompt 256 token giống hệt nhau từng token giữa đường dẫn pinned và đường dẫn tệp trên FP8 TP4, và GSM8K đạt 97,6% với pinned so với 98,0% với tệp ở giới hạn 64 GB — một khoảng cách sáu câu hỏi mà tác giả cho là do biến thiên giữa các lần chạy chứ không phải do đường dẫn offload. Tất cả những con số này đều là của chính tác giả pull request, được đo một lần, trên một máy, và chưa ai tái lập được chúng.

Những chi phí mà PR thừa nhận

Một cách đọc công bằng về pull request này bao gồm cả những gì nó từ chối làm. Một số chế độ thực thi bị từ chối ngay tại thời điểm khởi tạo thay vì bị hạ cấp một cách âm thầm, và mỗi lần từ chối đều nêu rõ backend được ghim làm phương án dự phòng: prefill CUDA graphs, attention song song dữ liệu, đường xử lý ghép kênh prefill-decode, chồng lấp hai batch, các graph decode của DLLM, và các graph compact ragged verify đều bị loại. Quan trọng không kém, nó không thêm cờ mới nào và không thêm công tắc hướng tới người dùng mới nào — đường xử lý staging chính là điều backend tệp tin làm trên phần cứng mà trước đây hoàn toàn không thể dùng nó. Và lần chạy độ chính xác mang một lưu ý mà tác giả tự nguyện nêu ra: các lần chạy có giới hạn chưa bao giờ chứa toàn bộ bảng, vì bảng có kích thước 47,7 GiB và các giới hạn xuống thấp tới 24 GB, nên một khối lượng công việc có mẫu truy cập thực sự phẳng, không thể đoán trước trên toàn bộ bảng không phải là thứ được đo lường.

Tại sao điều này lại đặc biệt quan trọng đối với Qwen 4

Bỏ qua chi tiết về engine, quy luật trở nên rõ ràng. Alibaba đã phát hành bản xem trước kiến trúc vào ngày 26 tháng 8, kèm hướng dẫn để cộng đồng mã nguồn mở chuẩn bị runtime, lượng tử hóa và engine suy luận trước khi cả dòng sản phẩm ra mắt đầy đủ. SGLang đã làm đúng như vậy, rồi dành ba tuần để gửi các pull request về đúng một thành phần khiến kiến trúc này khó triển khai. Đọc như một dự báo, đó là phát biểu về những gì Qwen 4 sẽ cần từ phần cứng của bạn, chứ không phải về những gì nó có thể làm trên một bài benchmark.

Nó cũng làm sắc nét hơn câu hỏi về mốc thời gian. Qwen 4 vẫn chưa được phát hành, và những đồn đoán hồi tháng 9 xung quanh nó đang hướng tới Hội nghị Apsara của Alibaba diễn ra từ ngày 22–24 tháng 9 tại Hàng Châu — địa điểm mà các thế hệ Qwen trước đây từng được công bố. Chưa có gì về điều đó được xác nhận, và quy luật từ chu kỳ xem trước gần nhất là bản xem trước kiến trúc đi trước dòng mô hình đầy đủ vài tháng chứ không phải vài tuần. Một pull request được mở ba ngày trước hội nghị đó chỉ mang tính gợi ý và không hơn thế.

Tóm tắt trung thực về việc điều này đặt người đọc ở đâu: Qwen 4 không tồn tại, Qwen3.8-Flash-Next thì có, và cái thứ hai cho bạn biết bạn sẽ tốn bao nhiêu để chạy cái thứ nhất. Nếu bảng 47.7 GiB tiếp tục thu hẹp về dấu chân hiệu dụng — và ba tuần pull request cho thấy nó đang được dồn sức xử lý — thì ngưỡng triển khai cho dòng Qwen 4 thấp hơn mức mà tuần ra mắt của bản xem trước gợi ý.

Những gì bạn thực sự có thể làm với điều này ngay hôm nay

Không có gì trong pull request này hiện có trên main, và mô hình mà nó nhắm tới không phải thứ bạn có thể gọi qua API. Checkpoint Qwen3.8-Flash-Next với trọng số mở là một câu chuyện tự vận hành: bạn tải trọng số về, bạn tự phục vụ chúng, và đường dẫn PLE dựa trên tệp chính là thứ bạn đang đọc. Nó không được định tuyến ở đây. Thứ được định tuyến là biến thể production — Qwen3.8-Flash, truy cập được qua qwen/qwen3.8-flash với mức $0.15 mỗi triệu token đầu vào và $0.47 mỗi triệu token đầu ra, với ngữ cảnh 1M token cùng đầu vào văn bản, hình ảnh và video — còn Qwen3.8-Max lớn hơn ở mức $2.00 và $6.00.

Sự phân biệt đó mới là điều hữu ích đối với người đọc đang cân nhắc nên làm gì trong tuần này. Bản xem trước là phần nghiên cứu do chính bạn chạy; còn biến thể được phục vụ chính là đường đi production của cùng kiến trúc đó, và nó chỉ cách bạn một endpoint. OrcaRouter chuyển nguyên giá niêm yết của nhà cung cấp ở mức cộng thêm 0%, nên khi nhà cung cấp thay đổi giá trên endpoint đó, thay đổi sẽ hiện ra ngay trong cùng ngày thay vì đợi đến kỳ thanh toán tiếp theo, và mọi model trên key đều có thể truy cập được qua một base URL tương thích OpenAI duy nhất thay vì phải có hợp đồng, SDK và thông tin xác thực riêng cho từng nhà cung cấp. Với một kiến trúc còn non trẻ như thế này — khi phần engine vẫn đang được cập nhật hằng tuần và lộ trình vẫn chưa được công bố — tự động chuyển đổi dự phòng giữa các nhà cung cấp là cách thiết thực để phụ thuộc vào biến thể được phục vụ mà không đặt cược đường đi production vào thời gian hoạt động của một nhà cung cấp duy nhất. Tất cả những điều đó chỉ nói về các model bạn có thể gọi ngay hôm nay. Nó không nói gì về Qwen 4, vốn không nằm trong số đó.

Những gì chúng ta vẫn chưa biết

Liệu Qwen 4 có phát hành cùng một bảng ở cùng kích thước hay không. Liệu pull request có được hợp nhất hay không — nó có ba lần chạy CI thất bại và chưa có đánh giá nào. Liệu mức phạt 0,5 đến 1 mili giây mỗi bước có đứng vững bên ngoài các cấu hình đồng thời thấp của tác giả hay không. Và liệu Alibaba có nói gì tại Apsara vào ngày 22 tháng 9 hay không. Với bằng chứng hiện tại, điều an toàn nhất để kết luận về Qwen 4 không phải là nó đạt điểm bao nhiêu, mà là ngành công nghiệp đang xây dựng bao nhiêu bộ máy chỉ để làm cho nó vừa khít — điều mà tự nó đã là một thông tin hữu ích cần biết trước khi mô hình có tên trong bất kỳ danh mục nào.