Ngày 21 tháng 8, đội SGLang và đội Ling Infra của Ant Group công bố một báo cáo tối ưu chung: khi chạy Ling-3.0-flash trên bốn GPU Blackwell, họ đã giảm thời gian mỗi token đầu ra (TPOT) ở mức đồng thời 1 từ 3,33 mili giây xuống 1,53 mili giây, giảm 54%, trong khi thông lượng tăng từ 288 lên 606 token mỗi giây. Khi chuyển sang mô hình nháp DSpark do họ tự huấn luyện, TPOT trung bình tiếp tục giảm xuống 0,78 mili giây, thông lượng đạt 1120 token mỗi giây, và trung bình mỗi lượt chấp nhận được 9,95 token nháp.
Ling-3.0-flash là mô hình MoE dùng cơ chế attention tuyến tính lai: trong 42 lớp, 35 lớp dùng attention tuyến tính KDA, 7 lớp dùng attention đầy đủ MLA, với 512 chuyên gia định tuyến, độ rộng lớp ẩn 2560, từ vựng khoảng 157.000 token. Ở bf16, mỗi card cần nạp khoảng 63 GB trọng số. Bài kiểm tra chia mô hình thành 4 phần bằng song song tensor, cũng ở bf16.
Thứ thực sự rảnh rỗi là GPU
Tối ưu lần này nhắm vào tình huống batch size bằng 1. Phần lớn các kết quả tối ưu suy luận công khai đều nhắm tới việc đẩy thông lượng tổng ở mức đồng thời cao, vì đó là cách các nhà cung cấp đám mây tính phí. Một dạng tải khác lại cho cảm giác trực tiếp hơn nhiều: đồng thời bằng 1 — chạy mô hình cục bộ, hoàn thiện mã, một agent thực thi tuần tự một chuỗi dài — chỉ có một yêu cầu chạy tại một thời điểm, và người dùng nhìn màn hình chờ từng chữ hiện ra.
Khi mức đồng thời giảm xuống, GPU trở nên rảnh rỗi. Khối lượng tính toán ở mỗi bước giải mã nhỏ đến mức không đáng kể; GPU làm xong việc rồi chờ lô lệnh tiếp theo, mà lệnh lại do CPU phát ra. Chỉ cần phía host có một chỗ cần đọc lại giá trị trong bộ nhớ GPU để quyết định bước tiếp theo, toàn bộ pipeline sẽ phải dừng lại chờ đồng bộ hoàn tất.
"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."
Ở mức đồng thời 1, việc đầu tiên cần làm là tìm các lượt đọc chặn (blocking read) giá trị bộ nhớ GPU trên đường xử lý phía host — mỗi lượt như vậy sẽ biến phần việc vốn ẩn của host thành một khoảng trống (bubble) trên GPU.
Gỡ bỏ từng điểm chờ một
Loại thứ nhất là thời gian host rảnh rỗi vô ích. Cách làm là loại bỏ các điểm đồng bộ GPU ở mỗi bước: trong backend attention KDA, khai báo rằng không cần đọc độ dài chuỗi về CPU, để các chỉ số liên quan luôn nằm trong bộ nhớ GPU. Nhờ vậy lệnh của bước k+1 có thể được phát đi ngay cả khi chưa biết bước k đã chấp nhận bao nhiêu token nháp, host không còn phải xếp hàng chờ kết quả.
Loại thứ hai là rút ngắn công việc trên đường găng (critical path) của GPU. Dùng khởi chạy phụ thuộc theo chương trình (Programmatic Dependent Launch - PDL) để phát sớm việc nạp trọng số không phụ thuộc vào đầu ra của kernel trước đó; gộp định tuyến và MoE từ hai lần khởi chạy kernel thành một, với quy mô 512 chuyên gia thì riêng chi phí khởi chạy đã đáng kể; đổi độ chính xác tính toán của router gate và lm_head từ fp32 sang bf16, riêng thay đổi này đã mang lại khoảng 10% cải thiện. Trạng thái vòng lặp của KDA dưới giải mã suy đoán (speculative decoding) được đổi thành cập nhật theo giai đoạn, chỉ chốt sau khi vượt qua kiểm chứng.
Tất cả các thay đổi này đều đã được đưa vào SGLang: gộp metadata vào đồ thị capture, kernel kiểm chứng KDA đã hợp nhất, kế hoạch FlashInfer do host phát trực tiếp (bỏ qua việc đọc lại bộ nhớ GPU theo kiểu chặn), cùng thứ tự lập lịch gộp ba bước nháp, kiểm chứng và mở rộng.
Quy đổi ra thời gian con người cảm nhận được
Thử tính nhẩm cho một câu trả lời dài 5000 token: với 3,33 mili giây mỗi token, viết xong mất 16,6 giây; với 1,53 mili giây là 7,7 giây; với 0,78 mili giây là 3,9 giây. Cùng một máy, cùng một mô hình, cùng một người đang chờ — sự khác biệt đi từ 'đủ thời gian pha tách trà rồi quay lại' thành 'chưa nói hết câu đã viết xong'. Khác biệt này không đến từ việc đổi GPU, mà từ việc dọn sạch hoàn toàn thời gian chờ phía host.
Con số then chốt ở DSpark là độ dài chấp nhận trung bình 9,95. Logic của giải mã suy đoán là để mô hình nhỏ đoán trước một chuỗi, mô hình lớn kiểm chứng một lần, đoán trúng càng nhiều thì càng lời thêm bước. Độ dài chấp nhận gần 10 nghĩa là mỗi lần kiểm chứng của mô hình lớn tương đương gần mười bước giải mã thông thường. Con số này liên quan trực tiếp đến cách huấn luyện mô hình nháp — mô hình nháp của DSpark được chưng cất từ phân phối đầu ra của Ling-3.0-flash sau giai đoạn hậu huấn luyện, hàm mất mát còn có riêng một số hạng tối ưu cho độ dài chấp nhận. Đoán trúng chuẩn là nhờ được huấn luyện ra, không phải may rủi.
Một hợp tác ở thượng nguồn
Đứng sau báo cáo này là ba bên đồng đứng tên: RadixArk phía SGLang, đội Ling Infra của Ant, và inclusionAI của Ant. Trọng số mô hình cùng các lệnh tái lập được công bố cùng lúc, bao gồm cả biến thể DSpark.
Việc các mô hình mã nguồn mở của Trung Quốc xuất hiện trên bảng xếp hạng những năm gần đây không còn gì lạ; điều đáng chú ý là tiếng nói của họ ở tầng ngăn xếp suy luận (inference stack). Lần tối ưu này không dừng lại ở việc chờ framework thượng nguồn thích ứng, mà tự mang theo bài toán chi phí phần cứng và tải thực tế để sửa trực tiếp mã nguồn thượng nguồn rồi hợp nhất trở lại. Với những ai triển khai bằng cùng framework đó, các công tắc này chỉ cần bật lên là dùng được, không phụ thuộc vào việc mô hình thuộc về ai.
Nguồn tham khảo: blog kỹ thuật chính thức của SGLang, CocoLoop, model card công khai của Ant inclusionAI; ba chỉ số TPOT, thông lượng và độ dài chấp nhận được kiểm chứng theo lệnh tái lập và kết quả benchmark công bố trong blog, đều đo ở mức đồng thời 1, song song tensor 4 card, độ chính xác bf16.