Lưu trữ Qwen trên Blackwell

Các rack NVIDIA GB200 NVL72 với GPU NVIDIA Blackwell được kết nối thông qua NVLink 72 chiều là lựa chọn phù hợp đặc biệt để triển khai các mô hình hỗn hợp chuyên gia (MoE) lớn. Trong bài đăng trên blog này, chúng tôi mô tả thiết lập suy luận phục vụ các mô hình Qwen3 235B đã được huấn luyện tinh chỉnh, hỗ trợ một phần lưu lượng truy cập của Perplexity. Chúng tôi cho thấy cách mình tùy chỉnh công cụ suy luận nội bộ để tận dụng các nhân tensor tiên tiến và kết nối tốc độ cao của GPU NVIDIA Blackwell. Với phần cứng này, chúng tôi xử lý nhiều lưu lượng hơn với chi phí thấp hơn mà không làm giảm độ chính xác của các mô hình nền tảng.

Các rack GB200 NVL72 bao gồm 18 node với 2 CPU NVIDIA Grace dựa trên kiến trúc ARM và 4 GPU dựa trên kiến trúc Blackwell, mỗi GPU được trang bị 180GB HBM. 72 GPU được kết nối với nhau thông qua NVLink và 18 ASIC NVLink Switch, mang lại băng thông 1800 GB/s giữa bất kỳ hai thiết bị ngang hàng nào và chia sẻ đủ bộ nhớ để lưu trữ các mô hình có quy mô hàng nghìn tỷ tham số. Ngoài ra, các bộ chuyển đổi ConnectX-7 InfiniBand cung cấp thêm băng thông 400 Gb/s cả trong các node của một rack và giữa các rack lân cận.

Để xử lý lưu lượng truy cập, chúng tôi đã chọn huấn luyện tinh chỉnh và phục vụ các mô hình Qwen. Trong bài đăng trên blog này, chúng tôi tập trung vào Qwen3 235B, nhưng nhiều kỹ thuật phục vụ và đặc tính hiệu suất được thảo luận tương tự như các mô hình Qwen3.5 397B và 122B mới hơn mà chúng tôi đang chuyển sang. Về tính song song, cơ chế chú ý tuyến tính tương tự như cơ chế tự chú ý toàn phần và việc triển khai lớp MoE hiện tại có thể dễ dàng điều chỉnh để đáp ứng các thuật ngữ cổng mới. Để duy trì tốc độ giải mã nhất quán đồng thời tối đa hóa thông lượng, chúng tôi đã chọn tách biệt giai đoạn tiền nạp (prefill) khỏi giai đoạn giải mã (decode), triển khai các chiến lược song song khác nhau cho hai loại node. Giao tiếp giữa bộ tiền nạp và bộ giải mã được xử lý qua InfiniBand, trong khi băng thông NVLink được dành riêng cho giao tiếp bên trong các bộ tiền nạp và bộ giải mã. Các đặc tính hiệu suất của thiết bị Blackwell khi thực hiện phép nhân ma trận và giao tiếp giữa các thiết bị, được khám phá trong bài đăng trên blog này, quyết định các chiến lược phân mảnh được sử dụng. So với GPU NVIDIA Hopper, chúng tôi thấy các cải tiến theo từng kernel nhờ số lượng multiprocessor phát streaming cao hơn, băng thông bộ nhớ tăng và độ trễ ngang hàng thấp hơn.

Phân tách prefill và decode, với InfiniBand giữa các bộ prefill và decoder và NVLink trong mỗi triển khai.

TransferEngine của chúng tôi, thực hiện việc tiền nạp tách rời, xử lý việc phân mảnh tùy ý và có khả năng không khớp giữa các bộ tiền nạp và bộ giải mã. Các bộ đệm KV được bố trí trong bộ nhớ theo thứ tự HND, với các đầu ở chiều dẫn đầu và các token được giữ liên tục, cho phép bộ đệm KV được phân mảnh trên một bộ tiền nạp có thể được chia nhỏ hoặc nối tiếp trong quá trình truyền tải đến node giải mã.

Các node tiền nạp nhận các token đầu vào của một yêu cầu, điền vào các bộ đệm KV và chuyển chúng sang các bộ giải mã để tiếp tục tạo văn bản. Giai đoạn tiền nạp đòi hỏi nhiều tính toán, vì hàng nghìn token thuộc một chuỗi được xử lý cùng một lúc.

Do đó, chúng tôi nhận thấy rằng việc triển khai song song tensor là phù hợp, với mô hình được phân mảnh trên 4 GPU trong một node GB200 duy nhất và các phép chiếu cùng chuyên gia được phân mảnh (TP=4, EP=4). Vì cả cơ chế chú ý và MLP đều bị giới hạn bởi tính toán, cả hai đều hưởng lợi từ tính song song, phân phối các chuyên gia và đầu chú ý trên các xếp hạng riêng biệt. Tính song song bổ sung sẽ mang lại lợi ích giảm dần, vì cải thiện thông lượng từ việc lưu trữ ít chuyên gia hơn trên mỗi xếp hạng (16 so với 32) sẽ không bù đắp được chi phí bổ sung của quá trình all-reduce 8 chiều và chi phí quản lý việc chia nhỏ mã phía máy chủ trên hai node, đòi hỏi giao tiếp qua Ethernet.

Qwen3 235B chỉ có 4 đầu khóa-giá trị, yêu cầu các phép chiếu k và v phải được nhân bản trên các cặp xếp hạng nếu sử dụng 8 thiết bị. Chúng tôi có thể đã cân nhắc việc phân mảnh mạnh mẽ hơn để giảm lượng bộ nhớ cần thiết để lưu trữ trọng số trên mỗi xếp hạng, giải phóng không gian cho nhiều token hơn trong bộ đệm KV. Tuy nhiên, chúng tôi thấy rằng việc triển khai rộng hơn là không đáng giá.

Giả sử độ dài đầu vào khoảng 6000 token, mỗi trong số 128 chuyên gia có khoảng 6000 * 8 / 128 = 375 token được định tuyến tới, đảm bảo một bài toán dày đặc cho MoE GEMM. Vì điều này đã làm bão hòa thông lượng tính toán của thiết bị, tính song song dữ liệu là không cần thiết cho quá trình tiền nạp.

Mặc dù chi phí của cơ chế chú ý tăng theo bình phương, các bộ tiền nạp vẫn mang lại thông lượng nhất quán, cho phép ước tính sơ bộ về số lượng token đầu vào có thể được xử lý bởi một node trong một giây. Dựa vào các số liệu theo dõi tổng số token đầu vào từ các yêu cầu, số lượng node tiền nạp có thể được mở rộng để đảm bảo thông lượng tiền nạp tổng thể được định 크 thước phù hợp. Để tránh việc xếp hàng, số lượng bản sao tiền nạp được khớp với tổng số token đầu vào nhận được.

Các node giải mã nhận các bộ đệm KV từ các bộ tiền nạp và tạo ra các token từng cái một. Giai đoạn giải mã nhìn chung bị giới hạn bởi bộ nhớ: với ít token đầu vào, phép nhân ma trận bị giới hạn hoàn toàn bởi chi phí tải trọng số từ HBM vào Tensor Cores. Bên cạnh việc áp dụng chiến lược phân mảnh khác, một số kernel phải được tinh chỉnh để song song hóa tốt hơn các phép tính và quyền truy cập bộ nhớ.

Không giống như giai đoạn tiền nạp, việc phân mảnh cơ chế chú ý không còn mang lại lợi ích: việc chia nhỏ các đầu chú ý trên nhiều thiết bị có nghĩa là sẽ có ít cơ hội hơn cho tính song song trong một thiết bị duy nhất. Do đó, chỉ có tính song song dữ liệu và tính song song chuyên gia được sử dụng: các chuyên gia được phân mảnh trên nhiều thiết bị, nhưng mỗi thiết bị quản lý các bộ đệm KV và yêu cầu của riêng mình. Không có tính song song tensor, kích thước bộ đệm KV trên mỗi token của thiết bị sẽ lớn hơn. Tuy nhiên, không gian trong bộ nhớ được giải phóng bằng cách đặt ít chuyên gia hơn trên một node duy nhất. Không giống như Hopper, nơi chúng tôi giới hạn tính song song tensor trong một miền NVLink duy nhất trong node 8-GPU, trên Blackwell, chúng tôi thấy rằng việc mở rộng trên nhiều node trong một miền, sử dụng tối đa 16 thiết bị, mang lại hiệu quả.

Để tối đa hóa thông lượng, các bộ giải mã xử lý số lượng lớn hơn các yêu cầu đồng thời. Mặc dù các yêu cầu bổ sung tạo ra chi phí quản lý tối thiểu trong các lớp MoE và các phép chiếu khác, chúng làm tăng không cân xứng chi phí của cơ chế chú ý. Để duy trì tốc độ giải mã tối thiểu hợp lý, số lượng node giải mã được mở rộng để giữ kích thước lô trên mỗi bộ giải mã dưới một ngưỡng nhất định.

Tương tự như các triển khai Hopper trước đây, chúng tôi sử dụng cơ chế giải mã dự đoán (speculative decoding) với các lớp MTP được huấn luyện nội bộ để tăng tốc độ giải mã. May mắn thay, phần cứng nền tảng và các framework lập trình đủ tương tự để chia sẻ hoàn toàn việc triển khai giữa hai kiến trúc.

Điểm khác biệt chính giữa GB200 NVL72 và các node Hopper trước đây là miền NVLink lớn, cho phép giao tiếp ngang hàng vượt quá giới hạn trước đây là 8 thiết bị. Mặc dù các thiết bị Blackwell đã được triển khai trong các node 8-GPU, việc mở rộng quy mô trên nhiều node qua NVLink mang lại rất nhiều giá trị so với mạng InfiniBand chậm hơn.

Trên các node tiền nạp, chúng tôi dựa vào giao tiếp all-reduce trong các lớp chú ý và việc giảm song song chuyên gia giống chặt chẽ với all-reduce. Trên 4 GPU, chúng tôi tận dụng cả NVLink và NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): ngoài băng thông ngang hàng, chúng tôi cũng khai thác các phép giảm trong NVLink Switches để giảm độ trễ hơn nữa và triển khai phát sóng nhanh. Trên các node giải mã, việc triển khai điều phối và kết hợp all-to-all tùy chỉnh qua NVLink được sử dụng. Các kernel đã được triển khai nội bộ bằng cách sử dụng ánh xạ CuTeDSL và cuMem hoặc ánh xạ multicast.

Các bộ tiền nạp thực hiện thao tác all-reduce trong phép chiếu đầu ra của lớp chú ý, tổng hợp các đóng góp của các đầu được phân mảnh trên các xếp hạng tham gia. Tính song song tensor chỉ hiệu quả khi chi phí quản lý của all-reduce được bù đắp bởi độ trễ giảm của các bài toán nhân ma trận nhỏ hơn. Giả định này thường đúng đối với giai đoạn tiền nạp.

Trên các hệ thống cấp trung tâm dữ liệu NVIDIA HGX H200 và GB200 NVL72, các GPU thường được kết nối thông qua NVLink Switches. Bên cạnh việc định tuyến, các switch có thể thực hiện các thao tác giảm trên các thiết bị được kết nối thông qua SHARP. Sau khi tạo các ánh xạ bộ nhớ và đăng ký chúng vào một nhóm multicast bằng cách sử dụng các API CUDA, các kernel có thể sử dụng multicast.ld_reduce và multicast.st để tổng hợp và phát sóng các giá trị thông qua các switch. Để tạo ra nền tảng và các thành phần có thể tái sử dụng có thể được hợp nhất thành các kernel khác, chúng tôi duy trì nội bộ một kernel all-reduce CuTeDSL sử dụng các nguyên thủy này.

Trong một hệ thống có N GPU giảm B byte, việc triển khai đơn giản sẽ có một thiết bị ngang hàng tải các giá trị từ tất cả các thiết bị ngang hàng khác, tổng cộng là N * (N - 1) * B byte lưu lượng đọc. Việc triển khai hiệu quả hơn sẽ chia dữ liệu cần giảm trên các thiết bị ngang hàng, mỗi thiết bị giảm một lát của đầu vào, sau đó phát sóng nó cho phần còn lại. Điều này dẫn đến (N - 1) * (B / N) byte được đọc vào một thiết bị ngang hàng và phát sóng cho phần còn lại, tổng cộng là (N - 1) * B * 2 lần đọc và ghi, làm giảm lưu lượng truy cập qua các switch.

Lưu lượng all-reduce của NVSwitch với cộng dồn ở phía GPU và giảm trừ có hỗ trợ từ switch.

Với SHARP, quá trình giảm và phát sóng có thể được thực hiện hiệu quả hơn: thay vì đọc (N - 1) * (B / N) byte vào một thiết bị để tích lũy cục bộ, chỉ có B / N byte được chuyển từ switch, vì nó tự thực hiện việc giảm bằng cách sử dụng dữ liệu từ các thiết bị ngang hàng. Đối với việc phát sóng, có một sự cải thiện tương tự, vì số lượng giao dịch giữa GPU và switch qua các kênh NVLink giảm đáng kể. Nếu không có SHARP, thiết bị tích lũy sẽ thực hiện (N - 1) * (B / N) giao dịch qua NVLink với switch, với switch đọc cùng một lượng dữ liệu từ các thiết bị ngang hàng, tổng cộng là 2 * (N - 1) * (B / N) giao dịch. Với SHARP, B / N giao dịch được thực hiện giữa GPU và switch, và thêm (N - 1) * (B / N) giao dịch với các thiết bị ngang hàng, tổng cộng là B giao dịch.

Do tính đơn giản của nó, SHARP là một công cụ có giá trị, vì nó cung cấp việc triển khai phần cứng đơn giản cho một thuật toán. Mặc dù các bản truyền được giảm đi một phần lý thuyết N / (2 * (N - 1)) (tương đương 33% với 4 thiết bị ngang hàng), trong thực tế, chúng tôi quan sát thấy độ cải thiện 10% về độ trễ tiền nạp và giải mã trên cả hệ thống H200 và GB200 NVL72.

Độ trễ dispatch của NVLink và NVLS trên H200 và GB200 ở TP=4 với 16K token.

Đối với các mô hình MoE, các kernel dispatch và combine di chuyển và nhóm các token cho các bài toán MoE GEMM tiếp theo giữa các thiết bị ngang hàng, sau đó thực hiện tích lũy có trọng số trong combine. Chúng tôi đã điều chỉnh các kernel Dispatch và Combine hiện có của mình sang Blackwell, bằng cách port chúng sang CuTeDSL, tinh chỉnh việc phân bổ block và chuyên biệt hóa chúng mạnh mẽ giữa tiền nạp và giải mã.

Kernel song song chuyên gia (EP) được sử dụng trong các bộ tiền nạp. Vì các đầu vào của nó được nhân bản trên tất cả các xếp hạng, kernel dispatch chỉ cần chọn các token được định tuyến tới các chuyên gia trên xếp hạng hiện tại. Nó tổng hợp thông tin định tuyến và chuẩn bị các token vào các bộ đệm được sử dụng làm đầu vào cho MoE GEMM. Kernel combine trước tiên thực hiện tích lũy cục bộ giữa các đóng góp của các token được định tuyến tới các chuyên gia trên xếp hạng hiện tại, sau đó thực hiện all-reduce trên tất cả các xếp hạng.

Đối với giải mã, toàn bộ kernel được hợp thành một. Kernel tiền nạp được chia thành nhiều kernel, vì việc định tuyến và all-reduce yêu cầu ít block hơn bước combine cục bộ. Với CuTeDSL, chúng tôi có thể xây dựng một thư viện chung cho cả SHARP và NVLink all-reduce cũng như đồng bộ hóa ngang hàng, kết hợp nó vào cả kernel all-reduce và song song chuyên gia.

Độ trễ dispatch và combine prefill song song chuyên gia trên H200 và GB200 trên các cấu hình song song chuyên gia.

Về mặt hiệu suất, chúng tôi quan sát thấy Blackwell nhanh hơn đáng kể so với Hopper, nhờ tốc độ truyền tải được cải thiện, băng thông bộ nhớ cao hơn và thông lượng tính toán tốt hơn. Được phân mảnh trên 8 thiết bị và nhiều node trên GB200 (EP=8), các kernel trở nên nhanh hơn vì quá trình tích lũy cục bộ chạy trên ít token hơn trên mỗi thiết bị và với SHARP, chi phí giảm trên nhiều xếp hạng mở rộng tốt hơn. Tuy nhiên, trong thực tế, chúng tôi giới hạn tính song song ở 4 thiết bị, vì các mức tăng tốc này không phổ biến trên tất cả các kernel.

Kernel song song dữ liệu và song song chuyên gia (DP-EP) được sử dụng trong các bộ giải mã song song dữ liệu. Nó phát sóng các token khác nhau từ tất cả các xếp hạng tới các chuyên gia, chuyển kết quả về các xếp hạng nguồn và tích lũy chúng. Vì nó thực hiện bài toán all-to-all thưa thớt, nó chỉ dựa hoàn toàn vào NVLink.

Trên Hopper, kernel này bị giới hạn ở 8 thiết bị trong miền NVLink của một node duy nhất. Tuy nhiên, trên các hệ thống GB200, chúng tôi có thể mở rộng nó trên toàn bộ rack. Hầu hết mã nguồn được tái sử dụng. Sự khác biệt duy nhất là việc sử dụng các tay cầm fabric để trao đổi thông tin ngang hàng qua IMEX cho thiết lập ban đầu.

Độ trễ dispatch và combine trên GB200 trên các cấu hình song song dữ liệu và song song chuyên gia.

Vì kích thước truyền tải phát sinh trong quá trình giải mã rất nhỏ, chúng còn lâu mới làm bão hòa băng thông NVLink và thay vào đó bị giới hạn bởi độ trễ. Độ trễ ở mức hàng chục micro giây và duy trì tương đối ổn định khi số lượng thiết bị ngang hàng tăng lên, cho phép chúng tôi trải rộng việc triển khai trên số lượng thiết bị lớn hơn mà không phát sinh độ trễ bổ sung đáng kể.

Các mô hình MoE hưởng lợi từ tính song song chuyên gia, vì chi phí nhân tất cả các token với tất cả các chuyên gia có thể dễ dàng được song song hóa trên nhiều thiết bị. Với tính song song tensor trên các bộ tiền nạp, đối với các bài toán dày đặc, lợi ích khá trực tiếp, vì mỗi xếp hạng giờ đây phải thực hiện ít phép tính hơn. Trong trường hợp giải mã, tính song song dữ liệu mang lại lợi ích bổ sung trên cơ sở tính song song chuyên gia, vì số lượng lớn hơn các yêu cầu song song định tuyến nhiều token hơn tới mỗi chuyên gia, làm dày đặc các bài toán.

Trong việc triển khai của mình, hiện tại chúng tôi dựa vào các kernel CUTLASS CUDA/C++ cho phép nhân ma trận. Chúng tôi đã benchmark chúng trên các đầu vào giải mã thưa thớt với các lược đồ lượng tử hóa và mức độ song song khác nhau để quyết định chiến lược phân mảnh tối ưu cho các bộ giải mã. Trong các benchmark dưới đây, tất cả các chuyên gia đều được kích hoạt với một token duy nhất.

Độ trễ GEMM MoE theo nhóm trên các cấu hình song song chuyên gia và các lược đồ lượng tử hóa trên H200 và GB200.

Chúng tôi thấy rằng việc mở rộng 128 chuyên gia trên hơn 16 xếp hạng mang lại lợi ích giảm dần với CUTLASS, vì chi phí nhân 2 chuyên gia không thấp hơn đáng kể so với việc nhân 4. Có một sự cải thiện rõ ràng trên Blackwell so với Hopper, ngay cả trên chiến lược chia tỷ lệ block dưới mức tối ưu. Vì mức tăng độ trễ khoảng 5 us giữa EP=8 và EP=16 của dispatch/combine bị lấn át bởi mức giảm hơn 10 us trong chi phí GEMM, trên các hệ thống GB200, việc phân mảnh các bộ giải mã trên 16 xếp hạng là hợp lý, điều này cũng được xác nhận bởi các benchmark đầu cuối.

Blackwell giới thiệu hỗ trợ phần cứng cho các lược đồ lượng tử hóa 8-bit và 4-bit mới. Không giống như Hopper, phụ thuộc vào các hệ số chia tỷ lệ theo tensor hoặc theo block, Blackwell yêu cầu chia tỷ lệ vi mô (microscaling) để đạt được thông lượng tiền nạp và giải mã tốt nhất. Mặc dù lược đồ chia tỷ lệ block được sử dụng cho các mô hình như DeepSeek hoặc Kimi khả dụng, việc chia tỷ lệ vi mô hiệu quả hơn.

Chúng tôi đã triển khai Qwen3 235B với lược đồ lượng tử hóa MXFP8, chuyển đổi trọng số tĩnh sau khi tinh chỉnh mô hình. Tác động đến độ chính xác tương tự như tác động của việc chia tỷ lệ block với lượng tử hóa ngẫu nhiên, nhưng hiệu suất mang lại được cải thiện nhiều, như được minh họa bởi các microbenchmark MoE GEMM. Chúng tôi cũng đã cân nhắc các lược đồ lượng tử hóa MXFP4 và NVFP4, mặc dù tác động đến độ chính xác khi không có Quantization-Aware Training là quá lớn đối với quá trình chuyển đổi ban đầu từ Hopper sang Blackwell. Chúng tôi có kế hoạch khám phá các định dạng này kỹ lưỡng hơn trong công việc tương lai.

Chúng tôi đã benchmark các bộ giải mã của các triển khai Blackwell Qwen3 235B và so sánh chúng với các triển khai Hopper trước đây của chúng tôi. Trong thiết lập này, chúng tôi đã cân nhắc việc chia tỷ lệ block trên cả hai triển khai để tập trung vào tác động của tính song song. Các bộ tiền nạp TP=4 được tách ra cho cả hai kiến trúc nhằm cô lập hiệu suất giải mã. Hình bên dưới minh họa thông lượng giải mã giả định tỷ lệ chấp nhận bản nháp thực tế được cung cấp bởi các lớp MTP của chúng tôi.

Tốc độ giải mã và thông lượng trên mỗi GPU của Qwen3 235B FP8 trên các cấu hình song song chuyên gia H200 và GB200, giả định độ dài chấp nhận draft là 0,8.

Trên Hopper, việc phân mảnh triển khai trên hơn 8 GPU là không khả thi, vì độ trễ qua InfiniBand, đặc biệt là trên các bộ điều hợp EFA, chậm hơn đáng kể. Tuy nhiên, trên Blackwell, chúng tôi đạt được thông lượng cao hơn đáng kể, nhờ các miền NVLink lớn hơn.

Chúng tôi đã đạt được việc triển khai Blackwell ban đầu bằng cách tổng quát hóa các kernel Hopper hiện có và đẩy hiệu suất của các kernel dựa trên NVLink. Chúng tôi sẽ tiếp tục giảm chi phí phục vụ Qwen bằng cách cải thiện lượng tử hóa và tinh chỉnh hiệu suất giải mã cũng như thông lượng tiền nạp của các kernel khác trong pipeline.

Bài đăng trên blog Transfer Engine

Bài đăng trên blog CuTeDSL

Bài đăng trên blog Prefill-Disagg

Bài đăng trên blog Speculative Decoding

CUTLASS

NVLink

BibTeX

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}

Triển khai trên GB200 NVL72

Bộ tiền nạp

Bộ giải mã

Giao tiếp trong node và giữa các node

All-Reduce

MoE Dispatch - Combine

Song song chuyên gia

Song song dữ liệu và song song chuyên gia

MoE GEMM

Lượng tử hóa

Hiệu suất đầu cuối

Tài liệu tham khảo

Trích dẫn