Tối ưu hóa DeepSeek-V4-Pro trên GPU H20: Đột phá hiệu năng tiệm cận chip B300

1. Giới thiệu

DeepSeek-V4-Pro là mô hình Mixture-of-Experts (MoE) với 1,6 nghìn tỷ tham số, được phát hành với cả trọng số FP8 và FP4. Các mô hình ở quy mô này đương nhiên được hưởng lợi từ các bộ tăng tốc như GPU NVIDIA Blackwell, vốn cung cấp nhiều HBM hơn, thông lượng tính toán cao hơn và các Tensor Core hỗ trợ FP4 nguyên bản. Tuy nhiên, GPU H20 vẫn được triển khai rộng rãi dù thiếu những ưu điểm đó.

Các hạn chế về phần cứng không làm giảm bớt các yêu cầu về phục vụ (serving). Việc xử lý prefill cho ngữ cảnh dài vẫn phải kiểm soát thời gian đến token đầu tiên (TTFT). Quá trình giải mã (decode) tương tác phải đáp ứng mục tiêu thời gian trên mỗi token đầu ra (TPOT) của từng cấp độ dịch vụ. Lưu lượng truy cập duy trì phải cân bằng giữa thông lượng tổng thể và dung lượng KV-cache. Các đầu vào ngắn, ngữ cảnh dài, yêu cầu nhạy cảm với độ trễ và tính đồng thời cao gây áp lực lên hệ thống theo những cách khác nhau; không có cấu hình vạn năng nào có thể phục vụ tốt tất cả các trường hợp này.

Một mô hình cần nhiều cấu hình phục vụ (serving profiles). Các đặc điểm của khối lượng công việc, mục tiêu cấp độ dịch vụ (SLO) và hành vi phần cứng đo lường được cùng nhau định hình cấu trúc triển khai và đường dẫn thực thi:

Đẩy giới hạn độ trễ. Ở kích thước batch bằng 1, cấu hình tham chiếu H20-141GB đơn nút đạt 271 token đầu ra/giây, so với 383,7 token/giây được báo cáo trên B300. Bất chấp khoảng cách đáng kể về phần cứng, việc tối ưu hóa hệ thống dành riêng cho khối lượng công việc đã thu hẹp tỷ lệ hiệu suất giải mã quan sát được xuống còn 1,42 lần. Các thiết lập benchmark chi tiết và phương pháp trích xuất thông lượng dựa trên log được cung cấp trong Phụ lục B.3.

Bao phủ phạm vi phục vụ. Kết quả độ trễ chỉ đại diện cho một khía cạnh của hệ thống. Trên phạm vi cấu hình rộng hơn, prefill được tối ưu hóa đạt 8,45 nghìn token đầu vào/giây mỗi nút và xử lý prompt 1 triệu token trong 43,7 giây. Đối với giải mã hướng tới thông lượng, cấu hình tham chiếu hiệu suất DP16-EP16 đạt 4,67 nghìn token đầu ra/giây mỗi nút, tương ứng với TPOT trung bình là 27,4 ms. Những kết quả này được cố ý lấy từ các cấu hình khác nhau, mỗi cấu hình được chọn và tối ưu hóa cho một sự kết hợp khác nhau giữa độ dài ngữ cảnh, độ trễ, thông lượng và các hạn chế về dung lượng.

Đóng góp của bài viết này là một phương pháp luận, không phải là một benchmark đơn lẻ. Việc phục vụ theo kịch bản cụ thể cho phép mỗi khối lượng công việc tiến tới điểm vận hành đo lường tốt hơn trong số các cấu hình được đánh giá trên phần cứng hiện có. Chúng tôi hy vọng các lựa chọn triển khai, phương pháp tối ưu hóa và các phép đo được trình bày ở đây sẽ cung cấp một tài liệu tham khảo thực tế cho các nhóm đang phục vụ các mô hình tiên tiến dưới những hạn chế về tính toán, bộ nhớ, băng thông hoặc kết nối.

2. Từ hạn chế phần cứng đến các cấu hình phục vụ

2.1 Hạn chế phần cứng và vai trò phục vụ

Hình 1. Khoảng cách phần cứng: H20 so với B300.

Blackwell cung cấp hiệu suất thô; H20 cung cấp quy mô có thể triển khai. B300 cung cấp Tensor Core hỗ trợ FP4 nguyên bản, thông lượng FP8 cao hơn nhiều và HBM lớn hơn đáng kể. H20 không thể sánh bằng về khả năng tính toán, nhưng nó vẫn khả dụng ở quy mô lớn và cung cấp băng thông bộ nhớ cao cùng NVLink 900 GB/s. Mỗi nút trong nghiên cứu này chứa tám GPU được kết nối bằng NVLink. Prefill không lưu giữ trạng thái lâu dài cho mỗi yêu cầu, vì vậy lựa chọn phần cứng của nó chủ yếu được quyết định bởi TTFT, khả năng tính toán và hiệu quả truyền thông. Giải mã phải lưu giữ KV cache của mọi yêu cầu đang hoạt động trong suốt quá trình tạo, khiến dung lượng HBM trở thành giới hạn trực tiếp đối với độ dài ngữ cảnh và tính đồng thời. Đối với việc triển khai được nghiên cứu ở đây, điều này dẫn chúng tôi đến việc sử dụng H20-141GB cho giải mã và H20-96GB—với dung lượng đủ cho khối lượng công việc prefill của chúng tôi—cho prefill.

Hình 2. Phân bổ phần cứng theo vai trò phục vụ.

2.2 Lựa chọn dung lượng

Dung lượng phục vụ cuối cùng đến từ ngân sách HBM dùng chung: trọng số mô hình và trạng thái KV cho mỗi yêu cầu cạnh tranh cùng một bộ nhớ. Chúng tôi định nghĩa dung lượng full-token là số lượng token KV full-attention tối đa mà mỗi rank có thể chứa sau khi trọng số mô hình và các bộ đệm runtime đã được phân bổ. Đây là mức trần bộ nhớ thay vì là sự đảm bảo trực tiếp về kích thước batch cho phép.

Giảm dấu chân trọng số với Humming MXFP4AFP8

Giảm dấu chân trọng số trước tiên. Humming MXFP4AFP8 sử dụng trọng số chuyên gia MXFP4 với các kích hoạt FP8 trực tuyến để giảm dấu chân trọng số và lưu lượng bộ nhớ trên GPU H20, vốn thiếu Tensor Core hỗ trợ FP4 nguyên bản. Tích hợp SGLang có sẵn trong sglang#23754. Chúng tôi sẽ đề cập đến việc tích hợp Humming/SGLang trong một bài viết tiếp theo chuyên biệt. Kết quả độ chính xác ở cấp độ mô hình và các phép đo tham chiếu công khai được cung cấp trong Phụ lục D.2.

Mở rộng dung lượng KV với Online C128

Tạo không gian cho KV cache phát triển. Baseline Offline C128 giữ lại trạng thái cho mỗi chỉ mục đối với từng trang nén. Thay vào đó, Online C128 duy trì một trạng thái tổng hợp nhỏ gọn, giải phóng nhiều HBM hơn cho nhóm KV-cache. Nó giới thiệu thêm công việc duy trì trạng thái và xác minh suy đoán, nhưng chúng tôi không quan sát thấy sự suy giảm TPOT nào trong các thử nghiệm của mình.

Lợi ích dung lượng kết hợp

Hình 3. Mở rộng dung lượng với Humming MXFP4AFP8 và Online C128.

Lợi ích dung lượng cộng hưởng trên cả trọng số và trạng thái KV. Bằng cách giảm dấu chân trọng số, Humming MXFP4AFP8 mở rộng dung lượng full-token lên 1,71 lần so với cấu hình Baseline FP8 + Offline C128 cho DP32-EP32 và 4,47 lần cho PP2-TP8. Sau đó, Online C128 giảm dấu chân trạng thái phụ C128, cung cấp thêm mức tăng 2,268 lần trên nền tảng Humming. Kết hợp lại, hai kỹ thuật này nâng dung lượng lên 3,88 lần so với baseline cho DP32-EP32 và 10,14 lần cho PP2-TP8. Phụ lục D.1 cung cấp dữ liệu đầy đủ.

2.3 Các cấu hình phục vụ theo kịch bản cụ thể

Cấu hình Prefill

Hình 4. Cấu hình Prefill: Cùng đường dẫn thực thi, độ sâu pipeline khác nhau.

Độ sâu pipeline phù hợp phụ thuộc vào khối lượng công việc cần xử lý theo pipeline. PP2-CP8-TP8 và PP4-CP8-TP8 chia sẻ cùng một đường dẫn thực thi Attention-CP8 → MoE-TP8. Ở cấp độ cấu trúc, sự khác biệt chính của chúng là độ sâu pipeline: PP2 phân phối mô hình qua hai giai đoạn, trong khi PP4 sử dụng bốn giai đoạn.

Ngữ cảnh ngắn ưu tiên chi phí pipeline thấp hơn; ngữ cảnh dài bộc lộ nhiều tính song song hơn. Đầu vào ngắn tạo ra ít khối (chunks) hơn, khiến pipeline sâu hơn bị thiếu tải và làm cho chi phí nạp, xả và chuyển giao giữa các giai đoạn trở nên rõ rệt hơn. Ngữ cảnh dài cung cấp đủ khối để giữ cho bốn giai đoạn luôn bận rộn; với ít lớp hơn trên mỗi giai đoạn, các nút bổ sung chuyển thành tính song song prefill cao hơn. Trong quá trình triển khai của chúng tôi, những đặc điểm này dẫn đến việc sử dụng PP2-CP8-TP8 cho các ngữ cảnh ngắn hơn và PP4-CP8-TP8 cho các khối lượng công việc ngữ cảnh dài.

Cấu hình giải mã độ trễ thấp

Hình 5. Giải mã độ trễ thấp: Tham chiếu TP8 và cấu hình phục vụ PP2-TP8.

Độ trễ thấp bắt đầu với đường dẫn thực thi ngắn nhất. TP8 đơn nút và PP2-TP8 chia sẻ cùng một đường dẫn thực thi Attention-TP8 → MoE-TP8; sự khác biệt nằm ở việc mô hình có được phân vùng qua các nút hay không. TP8 đơn nút đặt tất cả các lớp trên một nút H20-141GB và tránh được việc giao tiếp và đồng bộ hóa giữa các giai đoạn. PP2-TP8 phân vùng mô hình qua hai giai đoạn pipeline.

Cấu trúc nhanh nhất không phải lúc nào cũng là cấu trúc dễ phục vụ nhất. TP8 đơn nút có đường dẫn thực thi ngắn hơn, nhưng trọng số mô hình và trạng thái phục vụ chia sẻ HBM của một nút, để lại không gian hạn chế cho KV cache. Nó không thể đồng thời hỗ trợ ngữ cảnh dài và kích thước batch lớn hơn. PP2-TP8 phải trả thêm chi phí pipeline nhưng phân phối trọng số mô hình qua hai nút, giải phóng nhiều HBM hơn cho trạng thái KV. Đối với các mục tiêu về độ trễ và dung lượng của mình, chúng tôi sử dụng TP8 đơn nút làm tham chiếu độ trễ cho batch-size-1 và PP2-TP8 làm cấu hình phục vụ độ trễ thấp.

Cấu hình giải mã thông lượng cao

Hình 6. Giải mã thông lượng cao: Tham chiếu DP16-EP16 và cấu hình dung lượng DP32-EP32.

Giải mã thông lượng cao mở rộng song song dữ liệu và song song chuyên gia cùng nhau. Cả hai cấu hình đều sử dụng đường dẫn thực thi Attention-DP → MoE-EP. DP16-EP16 là đơn vị triển khai nhỏ nhất; DP32-EP32 mở rộng cả DP và EP trong cùng một cấu trúc.

Mở rộng quy mô (scale-out) ưu tiên dung lượng yêu cầu hơn là thông lượng trên mỗi GPU. Một nhóm EP lớn hơn phân phối trọng số chuyên gia trên nhiều GPU hơn, giải phóng HBM cho KV cache và tiếp nhận nhiều yêu cầu đồng thời hơn. Đồng thời, một phần nhỏ hơn của lưu lượng MoE vẫn nằm trong mỗi nút, trong khi một phần lớn hơn đi qua các nút, điều này có thể làm giảm hiệu suất trên mỗi GPU. Trong các cấu hình được đánh giá ở đây, chúng tôi sử dụng DP16-EP16 làm đơn vị triển khai nhỏ nhất và tham chiếu hiệu suất, và DP32-EP32 để mở rộng dung lượng yêu cầu.

3. Prefill: Cân bằng giữa tính toán và truyền thông

Hiệu suất prefill là một vấn đề hệ thống. Sự mất cân bằng chuyên gia, truyền thông song song ngữ cảnh và định tuyến trong sản xuất cùng nhau quyết định TTFT; tối ưu hóa một kernel riêng lẻ là không đủ.

3.1 Tại sao chọn MoE-TP thay vì MoE-EP

Hình 7. Thay thế MoE-EP bằng MoE-TP.

Lưu lượng ít hơn vẫn có thể mất nhiều thời gian hơn. MoE-EP chỉ trao đổi các token đã được định tuyến, nhưng lưu lượng prefill thực tế cho thấy sự lệch chuyên gia đáng kể. Các rank sở hữu các chuyên gia "nóng" thực hiện nhiều tính toán hơn và trở thành các nút thắt (stragglers); tất cả các rank khác phải chờ đợi đường dẫn chậm nhất tại bước kết hợp. Khối lượng truyền thông thấp hơn không đồng nghĩa với TTFT thấp hơn.