GLM-5.3-Flash ở định dạng MXFP4: checkpoint nhẹ hơn, nhanh hơn cho AMD MI355X

Routed expert 4-bit, một pipeline serving được tối ưu tỉ mỉ tới từng kernel, cùng toàn bộ số liệu được công bố minh bạch kèm quy trình đo kiểm chi tiết. Đó là những yếu tố then chốt để khai thác tối đa hiệu năng của GLM-5.3-Flash trên AMD Instinct MI355X.

GLM-5.3-Flash là mô hình Mixture-of-Experts (MoE) với tổng cộng 320B tham số (18B tham số kích hoạt), hỗ trợ cửa sổ ngữ cảnh lên tới 1,048,576 token và tiếp nhận dữ liệu đầu vào đa phương thức (văn bản và hình ảnh). Chúng tôi đã lượng tử hóa các routed expert sang định dạng MXFP4, tối ưu hóa pipeline serving SGLang cho kiến trúc gfx950, và phát hành checkpoint theo giấy phép mã nguồn mở MIT tại OneNexus/GLM-5.3-Flash-MXFP4 trên Hugging Face.

Điểm cốt lõi được thể hiện trọn vẹn trong một biểu đồ. Trên cùng cụm 4 GPU MI355X, cùng mã nguồn SGLang, cơ chế phân bổ song song, chính sách KV cache, cấu hình speculative decoding và tập workload AgentX, checkpoint MXFP4 hoàn toàn vượt trội so với checkpoint FP8 chính thức ở mọi mức concurrency từ c1 đến c48: vừa đạt throughput tổng cao hơn, vừa mang lại tốc độ phản hồi nhanh hơn cho từng người dùng.

01Tổng quan mô hình

Mô hình gốc

zai-org/GLM-5.3-Flash 320B tham số tổng / 18B tham số kích hoạt

Định dạng trọng số

Routed expert MXFP4 Ở phần lớn các layer; các tensor khác giữ nguyên độ chính xác ban đầu

Checkpoint

182.12 GiB Payload tensor được index: 195,550,624,632 byte

Giới hạn ngữ cảnh

1,048,576 token Các lượt đo AgentX bên dưới áp dụng giới hạn 262,144 token

Stack serving đã kiểm thử

4× MI355X · SGLang trên ROCm · TP4/EP4 · FP8 KV cache Tích hợp sẵn MTP head trong checkpoint, speculative decoding EAGLE 5/1/6

Đầu vào / đầu ra

Văn bản và hình ảnh → văn bản Đã kiểm thử request xử lý ảnh và hội thoại nhiều lượt có cache; chưa đánh giá video

Giấy phép

MIT Xem ghi nhận bản quyền chi tiết trong NOTICE

Toàn bộ hỗ trợ runtime đã được đóng góp upstream trong SGLang PR #39273, bao gồm cả code triển khai và các bài test kiểm định tính đúng đắn.

02Hiệu quả của định dạng 4-bit so với FP8

Cùng cấu hình GPU, cùng phần mềm, cùng workload thử nghiệm trên hai checkpoint hoàn chỉnh. Checkpoint MXFP4 gọn hơn trên đĩa lưu trữ, chiếm ít dung lượng VRAM hơn và xử lý nhanh hơn ở mọi mức concurrency từ c1 đến c48.

Cả hai đường cong trong Hình 1 đều được đo đạc với commit SGLang 5fd4387a trên cùng container image, cùng phần cứng GPU, tokenizer, phân bổ song song TP4/EP4, chính sách FP8 KV cache, cấu hình EAGLE 5/1/6, giới hạn graph, cơ chế reset cache, tập benchmark AgentX gồm 393 mẫu và thời gian đo 900 giây cho mỗi mốc. Trên toàn bộ dải concurrency c1–c48, MXFP4 mang lại +12.4% tổng tốc độ output và +18.2% tốc độ output P90 cho từng người dùng (tính theo trung bình nhân). Cả hai đợt chạy đều không ghi nhận bất kỳ lỗi request nào: 9,734 request thành công với FP8 và 11,810 request thành công với MXFP4 xuyên suốt 8 mức đo.

Checkpoint nhỏ hơn cũng giải phóng đáng kể bộ nhớ VRAM cho ngữ cảnh. Với cùng một chính sách phân bổ bộ nhớ, trọng số mô hình giảm từ 77.69 GB xuống còn 46.99 GB trên mỗi GPU, nhờ đó dung lượng KV cache trên thiết bị tăng từ 13.97M lên 17.32M token.

03Chất lượng suy luận, đặt cạnh MXFP4 của AMD

Một checkpoint 4-bit chỉ thực sự có giá trị thực tiễn nếu vẫn duy trì được năng lực suy luận tốt. Chúng tôi đặt checkpoint của mình cạnh checkpoint MXFP4 tham chiếu của AMD trên cùng một bộ câu hỏi kiểm thử cố định.

Cả hai checkpoint — của OneNexus và amd/GLM-5.3-Flash-Quark-MXFP4 — cùng trả lời một bộ câu hỏi cố định theo chiến lược greedy (mỗi câu chạy một lần). Các phản hồi bị cắt ngắn do hết token hoặc chưa hoàn tất đều bị tính là sai. Trên các mẫu này, checkpoint của chúng tôi đạt +1.0 điểm phần trăm trên MMLU và +3.5 điểm phần trăm trên GPQA Diamond, trong khi thấp hơn −0.2 điểm phần trăm trên GSM8K.

04Tốc độ serving: ngang bằng với AMD

Khi so sánh throughput trực tiếp với checkpoint MXFP4 do chính AMD phát hành, nhận định khách quan và chuẩn xác nhất là hiệu năng của hai bên ở mức tương đương.

Chúng tôi chạy lại cả hai checkpoint trên cùng bốn MI355X VF với cùng bản build SGLang, tokenizer và cách render prompt, cách phân bổ TP4/EP4, FP8 KV cache, cấu hình EAGLE 5/1/6, chính sách cache, bộ AgentX 393 mục và 900 giây đo cho mỗi mức; mỗi checkpoint dùng độ chính xác trọng số target và MTP do chính nó khai báo. Trên dải c1–c48, OneNexus thấp hơn 0.1% về trung bình nhân tổng output và cao hơn 1.0% về trung bình nhân tốc độ P90 mỗi người dùng. Không lượt chạy nào có lỗi request (9,223 request của OneNexus và 9,264 request của AMD).

Chỉ số P90 tok/s/người dùng là phân vị thứ 90 của nghịch đảo độ trễ trung bình giữa các token của từng request hợp lệ: đây là tốc độ cảm nhận thực tế trên mỗi người dùng, không phải throughput tổng.

05Đường serving hoạt động thế nào

Phần lớn hiệu năng được quyết định bởi hai cơ chế cốt lõi: Sparse Attention dựa trên một index cache tinh gọn, và Speculative Decoding tận dụng draft head tích hợp sẵn ngay trong checkpoint.

Sparse attention và chọn lọc K-pool

GLM-5.3-Flash sử dụng các phép chiếu Sparse Attention độ rộng 256, không gắn thêm RoPE vào phần đuôi. Một K-pool index cache độc lập, tách biệt hoàn toàn với MLA attention cache độ rộng 512, sẽ quyết định mỗi token cần attend vào những phân đoạn lịch sử nào. Pipeline native trên gfx950 thực hiện đọc và ghi trên cùng một layout index đã preshuffle, giúp giới hạn phạm vi chọn lọc trong các ngữ cảnh dài mà không bỏ sót bất kỳ vị trí hợp lệ nào.

Draft, verify, commit

Trong mỗi bước suy luận, năm bước của MTP head có sẵn trong checkpoint đề xuất chuỗi token, sau đó một lượt target pass sẽ kiểm tra đồng thời tất cả các token này. Lượt kiểm tra này thực thi AITER MXFP4 expert, mHC được hỗ trợ trên gfx950 và KDA fused theo từng shape chuyên biệt, đi kèm đường tham chiếu dự phòng khi cần; phần thực thi expert vẫn bảo toàn ngữ nghĩa cổng SwiGLU và các ngưỡng clamp của mô hình. Cơ chế CUDA graph replay giúp loại bỏ hoàn toàn chi phí launch lặp lại, trong khi trạng thái KV và Mamba vẫn phải trỏ về đúng prefix đã commit và hiển thị sau khi bị từ chối hoặc bị cắt ở stop token.

06Đo trước, tối ưu sau: tinh chỉnh KDA

Bắt đầu từ chỗ thời gian verification thực sự đi đâu, rồi mới tinh chỉnh những gì trace cho thấy.

Trong target verification, bản capture ở c16 ghi nhận 535.5 ms MoE, 112.6 ms mHC và 91.4 ms KDA (device-event residence) trên mỗi rank. MoE chiếm nhiều nhất; KDA là cơ hội nhỏ hơn nhưng cụ thể để cắt bớt launch và khối lượng tính toán lặp lại.

Nghiên cứu KDA chạy trên một MI350X VF (gfx950) độc lập với các tensor tổng hợp có shape GLM TP4 — đây là nghiên cứu ở cấp operator, không phải so sánh checkpoint hay một lượt serving MI355X mới. Trường hợp đầu tiên có tám request, mỗi request tám token verification, và được cải thiện qua ba bước.

Kiểm tra đúng shape serving, giữ đường dự phòng

EAGLE 5/1/6 kiểm tra sáu token, nên kernel fused phải thắng ở đúng shape đó. Lượt quét sáu token đối chứng xác nhận xu hướng ở bảy kích thước batch, và cũng cho thấy mức lợi thu hẹp dần khi batch lớn lên. Đó là lý do việc dispatch phụ thuộc vào shape: batch 1–2 giữ tile bốn giá trị, còn các batch lớn hơn đã được kiểm định dùng tile 16 giá trị.

PR chỉ dùng lại đường KDA fused ở những nơi đã được kiểm định: gfx950, batch 1–16, sáu hoặc tám token verification, 16 local head, state rộng 128, activation BF16, trọng số convolution FP32, không có convolution bias và gate bound −5. Mọi shape ROCm khác giữ đường tham chiếu. Với mọi shape đã đo, ba lần graph replay với đầu vào thay đổi đều khớp chính xác ở output đang dùng và các buffer convolution, còn các SSM state trung gian nằm trong sai số tuyệt đối 0.004.

07Thêm hai lựa chọn đã được đo

Không phải cải thiện nào cũng cần kernel mới. Hai cải thiện đến từ việc chọn đúng đường có sẵn cho các shape của GLM-5.3-Flash.

Chọn backend mHC. GLM-5.3-Flash trộn bốn residual stream trên 4,096 kênh quanh các khối attention và MLP. Khi bật AITER trên gfx950, runtime chọn các HIP kernel của AITER cho hình học này: cùng số lần launch và cùng RMSNorm phía caller, kernel ngắn hơn, và cả hai đường đều vượt qua cùng một numerical oracle.

Vision merge dưới dạng nhân ma trận. Bước downsample thị giác có kernel size bằng stride (2×2), không padding và một group, nên mỗi patch là một phép chiếu tuyến tính độc lập. Conv2dLayer hiện có xử lý trường hợp này bằng unfold + linear, bỏ qua bước tìm kiếm convolution của MIOpen. Với layout merge không liên tục [256, 1024, 2, 2] của mô hình, một lần copy layout và một phép nhân ma trận có bias thay cho chuỗi transpose / convolution / add, và output BF16 vẫn đạt cùng ngưỡng sai số.

08MI355X đặt cạnh số ước tính B300 được cung cấp

Một minh hoạ frontier, không phải chiến thắng benchmark: một đường là số đo thực, đường còn lại là số ước tính chúng tôi được cung cấp.

Đường cyan được đo trên bốn GPU MI355X (gfx950 VF) với checkpoint này. Đường vàng cam nét đứt là số ước tính được cung cấp cho bốn GPU B300; chúng tôi không tự chạy lại B300 và không có dữ liệu thô của các lượt chạy đó. Bộ dữ liệu, giới hạn ngữ cảnh 256K, số GPU và cấu hình EAGLE khớp nhau, nhưng phần cứng, backend DSA và bản cài đặt serving khác nhau, nên đây không phải tuyên bố về tốc độ vượt trội giữa hai phần cứng trong điều kiện đối chứng.

Ở c48, MI355X đo thực có tổng tốc độ output cao hơn 36.9% nhưng tốc độ P90 mỗi người dùng thấp hơn 19.1% so với số ước tính B300. Trên tám mức MI355X, 11,810 request đã hoàn tất mà không có lỗi nào.

09Tự tái hiện

Mọi hình trong bài đều truy được về một bản tóm tắt JSON và một quy trình đo trong repository của mô hình.

Serving recipe cố định revision checkpoint, container, source, tokenizer và tham số khởi chạy. Các số đo AgentX dùng source SGLang 5fd4387a753cdc88c0c87efb1bcabab1efabfc93, và hồ sơ kiểm định ghi riêng source dùng cho kiểm định serving. Các lượt đo chất lượng dùng BF16 KV, tắt graph và speculation. Các prompt thô bị hạn chế không được phân phối lại.