Nhóm LMSYS đã công bố một loạt dữ liệu tối ưu phía máy chủ cho DeepSeek-V4-Pro, nền tảng thử nghiệm là H20, đối chứng là Nvidia B300. Tác giả gồm Tianyu Zhang, Yusong Gao và Yun Zhang, toàn bộ công việc chạy trên framework mã nguồn mở SGLang.
Trước tiên là hai con số cốt lõi. Ở giai đoạn prefill, cấu hình PP2-CP8-TP8 với ngữ cảnh 4K đạt 16900 token mỗi giây; chuyển sang PP4-CP8-TP8 chạy ngữ cảnh dài 512K, thông lượng lại tăng lên 25860 token mỗi giây, xử lý 1 triệu token mất 43,7 giây. Ở giai đoạn giải mã với kịch bản độ trễ thấp, một batch đơn trên H20 cho ra 271 token mỗi giây, B300 là 383,7, tỷ lệ giữa hai bên là 1,42 lần.
Kịch bản thông lượng cao có một bộ cấu hình khác. DP32-EP32 với ngữ cảnh 4K, 32 luồng đồng thời đạt 703,15 token mỗi giây trên mỗi card, DP16-EP16 còn cao hơn một chút, đạt 759,73. Khi kéo ngữ cảnh lên 1 triệu token, mỗi card vẫn duy trì được 66 đến 67 token mỗi giây.
1,42 lần có ý nghĩa gì
H20 là phiên bản Nvidia làm riêng để tuân thủ quy định cho thị trường Trung Quốc, khoảng cách sức mạnh tính toán trên giấy tờ so với B300 không chỉ là một bậc. Việc nén khoảng cách giải mã đơn batch xuống còn 1,42 lần cho thấy nút thắt ở đây không phải là hiệu năng đỉnh, mà là băng thông truy cập bộ nhớ, chi phí giao tiếp và thời gian chờ trong lập lịch.
Điều này cũng lý giải cơ cấu của danh sách tối ưu. Những hạng mục mang lại lợi ích lớn nhất đều không nằm ở độ chính xác của toán tử: hợp nhất đường nóng lượng tử hóa, gộp kích hoạt SwiGLU với lượng tử hóa và bỏ bộ đệm trung gian, giúp thông lượng riêng hạng mục này tăng 44,0%; thay tích vô hướng của trọng số từ vựng bằng phép GEMM chuyển vị, giảm việc đọc lặp lại khi đồng thời cao, thông lượng tăng thêm 22,8%; tái bố trí cân bằng tải theo đúng thiên hướng chuyên gia đo được trên thực tế, mang lại thêm 13,5%.
Phía prefill cũng theo logic tương tự. Gộp 7 toán tử thành 3 nhóm thực thi giúp giảm độ trễ token đầu tiên 3,5%; trích xuất các hình dạng tần suất cao từ biểu đồ định tuyến thực tế trong môi trường sản xuất, rồi tối ưu riêng cho hai nhóm trọng số chuyên gia, giúp giảm thêm 11,35% độ trễ token đầu tiên. Hạng mục cuối này đặc biệt thực dụng vì nó không giả định phân bố request đồng đều, mà bám theo thực tế lưu lượng trực tuyến vốn đã lệch.
Còn có một thay đổi mang tính cấu trúc: ở giai đoạn prefill, dùng song song tensor thay cho song song chuyên gia để chia MoE. Lý do là tải không đều giữa các chuyên gia sẽ kéo dài đuôi độ trễ, thà trả thêm một chút chi phí giao tiếp để cắt bỏ cái đuôi đó.
Bộ nhớ là thứ đánh đổi mà có
Ràng buộc còn cứng hơn cả tốc độ là dung lượng. Trong công việc này có hai hạng mục nhắm vào bộ nhớ: Humming MXFP4AFP8 dùng MXFP4 để lưu trọng số chuyên gia, kết hợp kích hoạt FP8 trực tuyến, mang lại mức tăng dung lượng từ 1,71 đến 4,47 lần so với baseline; nén KV C128 trực tuyến duy trì trạng thái tổng hợp gọn nhẹ thay vì trạng thái theo từng chỉ mục, đóng góp 2,268 lần. Cộng gộp cả hai, khoảng tăng đạt từ 3,88 đến 10,14 lần.
Với các đơn vị triển khai, đây là bài toán dễ tính nhất. Cùng một máy 8 card, số lượng đồng thời hoặc độ dài ngữ cảnh có thể xử lý tăng gấp nhiều lần, chi phí trên mỗi token giảm theo cùng tỷ lệ đó. Khi số lượng card không thể tăng thêm, hệ số dung lượng là biến số duy nhất mà đơn vị triển khai còn có thể tự quyết định.
Đóng góp của DSpark được tính riêng: sau khi phối hợp bước thực thi mục tiêu và bước xác minh giữa các giai đoạn pipeline, thời gian xuất ra mỗi token cải thiện từ 74,8% đến 78,0%.
Quy đổi các con số này ra chi phí sẽ dễ hình dung hơn. Giả sử chi phí sở hữu hằng tháng của một máy 8 card H20 không đổi, hệ số dung lượng tăng 4 lần thì cùng một hóa đơn đó có thể phục vụ lượng đồng thời gấp 4 lần, chi phí máy móc trên mỗi token giảm xuống còn khoảng một phần tư (đây là ước tính thô, chưa tính đến khối lượng tính toán phát sinh từ ngữ cảnh dài và biến động định tuyến). Với các nhà cung cấp dịch vụ định giá theo token, biên lợi nhuận vốn đã bị chiến tranh giá bào mỏng, khoảng không gian xoay xở này thường thiết thực hơn việc đổi sang thế hệ card mới, huống hồ card cũng chưa chắc đổi được.
Cái đưa ra cuối cùng là một bảng cấu hình
Điểm đến cuối cùng của công trình này không phải một lời giải tối ưu duy nhất, mà là một bảng cấu hình phân theo kịch bản: prefill dùng PP2 trong phạm vi 32K trở xuống, từ 128K trở lên chuyển sang PP4; giải mã theo đuổi độ trễ thấp thì dùng PP2-TP8, theo đuổi thông lượng thì dùng DP32-EP32, DP16-EP16 được giữ lại làm mốc tham chiếu hiệu suất.
Cách trình bày này tự nó đã là một tín hiệu. Bảng xếp hạng benchmark cần một con số, còn môi trường sản xuất cần biết lưu lượng thực tế của mình trông như thế nào và nên rơi vào cấu hình nào. Với những đội chỉ có H20 trong tay mà vẫn phải đưa mô hình 1,6 nghìn tỷ tham số vào phục vụ thực tế, bảng cấu hình này hữu ích hơn bất kỳ kỷ lục đỉnh nào.
Nguồn tham khảo: blog kỹ thuật LMSYS, CocoLoop, tài liệu dự án SGLang; các số liệu thông lượng, độ trễ và hệ số dung lượng đều lấy từ bảng cấu hình đo thực tế mà blog này công bố, dữ liệu đối chứng B300 cùng nguồn.