HPC-Ops kết hợp SGLang: Tencent Hunyuan mở mã nguồn các toán tử Attention, Router GEMM và MoE hiệu năng cao

HPC-Ops là một thư viện toán tử mã nguồn mở dành cho suy luận LLM, được triển khai trong hệ thống phục vụ sản xuất quy mô lớn của Tencent. Các toán tử cốt lõi của nó, bao gồm Dynamic Attention và Fused MoE, đóng vai trò quan trọng trong quá trình suy luận trực tuyến của Hunyuan, giúp giảm TPOT của mô hình Hy3 lên đến 48,8%. HPC-Ops Attention, Router GEMM và MoE hiện đã được tích hợp vào nhánh chính của SGLang, mang những tối ưu hóa đã được kiểm chứng trong môi trường sản xuất này đến với cộng đồng phục vụ mã nguồn mở.

Trong bài viết này, chúng tôi giới thiệu thiết kế của ba toán tử quan trọng trong HPC-Ops và sự tích hợp của chúng với SGLang. Sau đó, chúng tôi trình bày các kết quả benchmark toán tử và kết quả phục vụ trên H20 cùng với các kết quả xác thực trên H200. Các tích hợp này nhắm đến các GPU NVIDIA Hopper (SM90) và đã được xác thực với các khối lượng công việc Qwen3, Hy3 và LongCat.

Các điểm nổi bật

Attention, định tuyến (routing) và chuyên gia (experts): ba đường dẫn quan trọng trong phục vụ mô hình MoE

Việc phục vụ MoE trong môi trường sản xuất hiếm khi giống với các khối lượng công việc đồng nhất được đo lường trong các benchmark kernel biệt lập. Nó kết hợp công việc Attention với độ dài hỗn hợp, định tuyến nhạy cảm với độ chính xác và thực thi chuyên gia thưa (sparse expert execution) trong cùng một đường dẫn nhạy cảm với độ trễ; các khối lượng công việc có ngữ cảnh dài, đa lượt và tác nhân (agentic) làm tăng thêm sự phân bổ độ dài KV thực tế. Do đó, hiệu suất phục vụ không chỉ phụ thuộc vào thông lượng nhân ma trận thô, mà còn phụ thuộc vào sự cân bằng khối lượng công việc, độ trung thực số học và kiểm soát chi phí vận hành (overhead).

Những hạn chế này xuất hiện trong ba giai đoạn quan trọng về hiệu suất của việc phục vụ mô hình MoE. Trong quá trình giải mã (decode), công việc Attention mở rộng theo độ dài KV thực tế của mỗi yêu cầu, biến các batch có độ dài hỗn hợp thành một bài toán cân bằng tải. Router GEMM tạo ra các điểm số được sử dụng để lựa chọn top-k, nơi những thay đổi nhỏ về số học có thể làm thay đổi lựa chọn chuyên gia. Các chuyên gia được chọn sau đó xử lý các nhóm token nhỏ và không đồng đều, cho phép việc xây dựng siêu dữ liệu, di chuyển token, lưu trữ trung gian và chi phí khởi chạy cạnh tranh với chính các GEMM chuyên gia.

HPC-Ops giải quyết từng giai đoạn bằng một toán tử chuyên dụng: lập lịch nhận biết khối lượng công việc cho Attention, công thức nhận biết độ chính xác cho Router GEMM và pipeline hợp nhất cho MoE giúp loại bỏ việc thu thập (gather) độc lập và giảm lưu lượng khởi chạy cũng như lưu lượng trung gian. Việc tích hợp upstream kết hợp các toán tử này với runtime phục vụ của SGLang thông qua backend gốc và các giao diện điều phối của nó. Các phần sau đây giải thích cách thiết kế của từng toán tử.

Attention: cân bằng tải cho giải mã độ dài hỗn hợp

Trong quá trình giải mã, mỗi token mới sẽ chú ý (attend) trên toàn bộ KV cache của yêu cầu, vì vậy công việc Attention mở rộng theo độ dài chuỗi thực tế. Do đó, một yêu cầu với 16K token được lưu trong cache sẽ mang khối lượng công việc KV gấp khoảng 16 lần so với yêu cầu 1K. Trong sản xuất, độ dài prompt và đầu ra thay đổi rất nhiều, và continuous batching đặt các yêu cầu ở các giai đoạn tạo khác nhau trong cùng một lần khởi chạy; do đó, một batch thường trộn lẫn các KV cache ngắn với các chuỗi dài hàng chục nghìn token.

Lịch trình split-KV tĩnh ánh xạ công việc vào một lưới khởi chạy cố định trên các KV head, yêu cầu và các KV chunk, với một chính sách phân vùng được chia sẻ trên toàn bộ batch. Một bộ lập lịch split-KV tĩnh thường tuân theo một trong hai chính sách, cả hai đều không hoạt động tốt cho các batch có độ dài hỗn hợp. (1) Cố định số lượng split, và các yêu cầu dài tạo ra các chunk nặng hơn nhiều: các CTA của yêu cầu ngắn kết thúc sớm trong khi một vài CTA chạy dài xác định phần đuôi của kernel. (2) Cố định kích thước chunk, và lưới phải dự trữ đủ số lượng split cho yêu cầu dài nhất, khiến các yêu cầu ngắn hơn có các chunk trống hoặc gần như trống nhưng vẫn tiêu tốn các khe lập lịch. Một chính sách tạo ra công việc không đồng đều; chính sách kia lập lịch cho công việc không tồn tại.

Lập lịch xung quanh công việc KV thực tế

HPC-Ops thay thế việc split tĩnh trên mỗi yêu cầu bằng một kernel bền bỉ (persistent kernel) giúp cân bằng động các KV tile trên các CTA theo phân bổ độ dài thực tế của batch. Đối với mỗi batch giải mã, một kernel gán (assign kernel) xây dựng bản đồ tác vụ toàn cục từ độ dài KV thực tế: nó cắt mỗi chuỗi thành các tile 64-token đồng nhất, tính tổng số tile trên tất cả các head và yêu cầu, và chia tổng số đó cho số lượng CTA bền bỉ để thiết lập ngân sách tile cho mỗi CTA. Kernel gán lấp đầy bin của mỗi CTA đến ngân sách đó trước khi chuyển sang bin tiếp theo, vì vậy các chuỗi dài trải dài trên nhiều CTA tương ứng với độ dài của chúng trong khi các chuỗi ngắn chỉ đóng góp các tile mà chúng thực sự có. Một mức sàn công việc tối thiểu ngăn chặn việc phân vùng quá mức khi tổng công việc nhỏ, giữ cho việc kết hợp (combine) ở hạ nguồn không tốn kém. Bản đồ tác vụ được tạo một lần mỗi bước giải mã từ độ dài chuỗi phía thiết bị và được tái sử dụng qua các lớp Transformer, giúp khấu hao chi phí của nó.

Tại thời điểm thực thi, mỗi CTA rút cạn bin được chỉ định của nó. Đối với mỗi descriptor, nó tính toán Attention trên một hoặc nhiều KV tile liên tục và ghi một đầu ra một phần với thống kê log-sum-exp của nó; cùng một CTA thường trú tiếp tục đến descriptor tiếp theo cho đến khi bin của nó trống. Vì mỗi CTA chỉ tạo ra một tập con các phần một phần cho một yêu cầu nhất định, một kernel kết hợp cuối cùng sẽ đọc số lượng chunk thực tế trên mỗi yêu cầu và head và hợp nhất các phần một phần đó dưới sự chuẩn hóa softmax toàn cục chính xác. Các kích thước bin gần bằng nhau đảm bảo rằng các CTA kết thúc vào cùng một thời điểm, loại bỏ phần đuôi kernel mà một vài yêu cầu dài bất thường có thể gây ra.

Một phần mở đầu (prologue) Attention hợp nhất

Đối với Hy3 FP8, HPC-Ops hợp nhất phần mở đầu Attention sau phép chiếu QKV: nó áp dụng QK-Norm trước RoPE, phát ra Q ở định dạng FP8 với tỷ lệ trên mỗi token, mỗi head và ghi K và V trực tiếp vào paged FP8 cache. Nó truyền Q đã lượng tử hóa và tỷ lệ của nó trực tiếp đến kernel Attention chính, tránh việc lượng tử hóa lại. Đường dẫn hợp nhất loại bỏ các tensor trung gian và các vòng lặp HBM liên quan cũng như các lần khởi chạy kernel riêng biệt trong cả giai đoạn prefill và decode.

Router GEMM: cân bằng độ chính xác định tuyến và thông lượng

Độ chính xác của bộ định tuyến ảnh hưởng trực tiếp đến chất lượng mô hình MoE. Tại mỗi lớp MoE, bộ định tuyến chiếu các trạng thái ẩn thành các điểm số chuyên gia, và một lựa chọn top-k trên các điểm số này xác định chuyên gia nào sẽ thực thi. Sự khác biệt về điểm số giữa chuyên gia thứ k và thứ (k+1) có thể rất nhỏ, vì vậy độ chính xác số học của phép chiếu này quyết định liệu các chuyên gia chính xác có được chọn hay không.

Để bảo toàn độ chính xác của bộ định tuyến, một số mô hình sản xuất giữ lại trọng số bộ định tuyến FP32 ngay cả khi các trạng thái ẩn là BF16. Việc chuyển đổi các trọng số đó sang BF16 cho phép thông lượng Tensor Core BF16 nhưng loại bỏ các bit mantissa bậc thấp có thể làm thay đổi quyết định top-k. Một GEMM FP32 đầy đủ bảo toàn tất cả độ chính xác của trọng số, nhưng với thông lượng Tensor Core thấp hơn.

Công thức BF16 nhận biết độ chính xác

HPC-Ops giải quyết vấn đề này bằng cách phân tách trọng số FP32 thành hai thành phần BF16. Nó trích xuất một phần cao BF16 $W_{\mathrm{high}}$ bằng cách cắt bớt trực tiếp, sau đó tạo thành một thành phần BF16 thứ hai từ phần dư đã được chia tỷ lệ $(W - W_{\mathrm{high}}) \times 256$. Trọng số ban đầu được xấp xỉ là $W \approx W_{\mathrm{high}} + W_{\mathrm{low}} / 256$, vì vậy tích ma trận trở thành hai GEMM BF16 mà kết quả của chúng được kết hợp với một hiệu chỉnh tỷ lệ để khôi phục đóng góp của mantissa bậc thấp. Một kernel duy nhất thực thi cả hai phép nhân BF16: nó tải các tile kích hoạt một lần từ bộ nhớ chia sẻ, tích lũy cả hai kết quả một phần trong các thanh ghi FP32, áp dụng tỷ lệ 1/256 trong phần kết luận (epilogue) và ghi các điểm số bộ định tuyến FP32 cuối cùng vào bộ nhớ toàn cục. Công thức này khôi phục độ chính xác gần bằng một GEMM FP32 đầy đủ trong khi chạy phép tính số học chính trên các Tensor Core BF16.

Về phía framework, SGLang lưu trữ cặp trọng số đã phân tách tại thời điểm tải mô hình và tái sử dụng nó trên các yêu cầu và các lần phát lại CUDA graph. Một cơ chế điều phối nhận biết hình dạng (shape-aware dispatch) chọn giữa kernel HPC-Ops và đường dẫn mặc định tại các điểm giao cắt đã đo lường. Dưới các điểm này, đường dẫn FP32 đơn lẻ nhanh hơn vì chi phí vận hành của hai sản phẩm vượt quá mức tăng của Tensor Core.

MoE: giảm chi phí vận hành xung quanh các GEMM chuyên gia nhỏ

Trong quá trình giải mã, mỗi chuyên gia trong một lớp MoE chỉ nhận được một vài token. Các GEMM chuyên gia thu được rất nhỏ và bị giới hạn bởi bộ nhớ, và các SM của GPU bị sử dụng dưới mức tại các hình dạng này. Vấn đề trở nên trầm trọng hơn do sự mất cân bằng tải: số lượng token được định tuyến đến mỗi chuyên gia thay đổi giữa các chuyên gia và thay đổi từ bước này sang bước khác, gây khó khăn cho việc phân bổ các tile nhỏ, không đồng đều này một cách đồng đều trên các SM có sẵn.

Ngoài chính các GEMM chuyên gia, các hoạt động xung quanh chúng tạo ra chi phí vận hành đáng kể. Một đường dẫn MoE thông thường liên kết các kernel riêng biệt cho việc định tuyến, thu thập token vào các bộ đệm theo chuyên gia, Gate-Up GEMM, kích hoạt và lượng tử hóa, Down GEMM và giảm trọng số top-k trở lại các vị trí token. Bước thu thập hiện thực hóa một tensor token đầy đủ trong HBM trước khi bất kỳ phép nhân ma trận nào bắt đầu, và mỗi giai đoạn tiếp theo phải trả chi phí khởi chạy kernel riêng và vòng lặp HBM cho các trung gian. Khi các GEMM nhỏ, chi phí vận hành xung quanh này tiêu tốn một phần đáng kể thời gian thực thi của giai đoạn.

Một pipeline MoE hợp nhất, hướng đến độ trễ

Đối với suy luận batch-size nhỏ, backend MoE của HPC-Ops điều phối việc định tuyến và tiền xử lý chỉ mục, Gate-Up, kích hoạt và lượng tử hóa lại, Down và giảm trọng số top-k trong một pipeline độ trễ thấp được xây dựng xung quanh các GEMM chuyên gia bền bỉ được điều khiển bởi bản đồ tác vụ.

Cùng với nhau, các tối ưu hóa này làm giảm lưu lượng trung gian và chi phí khởi chạy kernel trên đường dẫn quan trọng.

Từ các kernel HPC-Ops đến SGLang

Thông qua backend gốc và các giao diện điều phối của SGLang, HPC-Ops hoạt động trực tiếp trên trạng thái hiện có của runtime phục vụ trong khi vẫn là một thư viện toán tử được duy trì độc lập. Attention tiêu thụ bộ nhớ KV được phân trang và siêu dữ liệu chuỗi phía thiết bị thực tế mà không cần chuyển đổi bố cục bổ sung; Router GEMM tái sử dụng các trọng số đã tiền xử lý và không gian làm việc trên các yêu cầu và các lần phát lại CUDA graph; và MoE tuân theo các ID chuyên gia và phân vùng của SGLang mà không cần ánh xạ lại bổ sung. Những tích hợp này bảo toàn đường dẫn dữ liệu dự kiến của từng toán tử trong khi vẫn phù hợp với mô hình thực thi hiện có của SGLang.

Ba đường dẫn toán tử tích hợp được tóm tắt dưới đây:

Bắt đầu

Hướng dẫn này mô tả cách sử dụng các toán tử HPC-Ops Attention, Router GEMM và MoE trong SGLang.

Cài đặt

Để cài đặt HPC-Ops từ mã nguồn:

HPC-Ops đã được bao gồm trong các image phát triển x86_64 chính thức của SGLang (lmsysorg/sglang:dev, hoặc lmsysorg/sglang:dev-cu12 cho CUDA 12.9), vì vậy không cần cài đặt riêng khi sử dụng các image này.

Attention và MoE

Attention và MoE là các lựa chọn backend độc lập trong SGLang và có thể được kích hoạt riêng biệt hoặc cùng nhau cho các mô hình tương thích như Qwen3 và Hy3. Ví dụ sau đây chọn cả hai backend HPC-Ops và kích hoạt đường dẫn Attention KV-cache FP8:

Đối với KV cache BF16, hãy bỏ qua --kv-cache-dtype fp8_e4m3. Để chỉ sử dụng một toán tử HPC-Ops, chỉ cần chỉ định tùy chọn backend tương ứng.

Router GEMM