Kích hoạt các mô hình hàng nghìn tỷ tham số trên AWS EFA

Tại Perplexity, chúng tôi sử dụng các mô hình tốt nhất cho sản phẩm, các API và các đội ngũ nghiên cứu của mình. Các mô hình Hỗn hợp Chuyên gia (Mixture-of-Experts) mã nguồn mở lớn, chẳng hạn như Kimi-K2 đặt ra những thách thức đặc biệt, vì các nút suy luận lớn nhất với 8 GPU NVIDIA H200 không thể chứa chúng một cách hiệu quả, đòi hỏi phải triển khai đa nút. Chúng tôi trình bày một tập hợp các nhân (kernel) cho tính song song chuyên gia đạt độ trễ tiên tiến trên ConnectX-7, vượt qua hiệu suất của DeepEP. Các nhân tương tự cũng là những nhân đầu tiên đạt được độ trễ khả thi trên Bộ điều hợp Vải Đàn hồi AWS (EFA), cho phép triển khai mô hình hàng nghìn tỷ tham số.

Hãy thử nghiệm các nhân của chúng tôi trên GitHub và đọc toàn bộ bài báo nghiên cứu trên arXiv.

Giới thiệu

Hỗn hợp Chuyên gia (MoE) đã nổi lên như kiến trúc tiêu chuẩn để mở rộng quy mô lên hàng trăm tỷ hoặc hàng nghìn tỷ tham số đồng thời cung cấp độ trễ hợp lý tại thời điểm suy luận. Các mô hình MoE thay thế lớp dày (dense layer) của mô hình transformer bằng một tập hợp các chuyên gia và một lớp định tuyến tuyến tính nhỏ quyết định nhân mã thông báo (token) với chuyên gia nào. Bằng cách nhóm các mã thông báo liên quan đến cùng một chuyên gia, bài toán trở nên thưa thớt và có thể song song hóa một cách đơn giản, vì các chuyên gia khác nhau giờ đây có thể được lưu trữ trên các GPU khác nhau được phân bổ trên nhiều nút.

Không giống như các hình thức tính song song khác, chẳng hạn như Tính song song Tensor (TP) và Tính song song Dữ liệu (DP) có thể dễ dàng được triển khai bằng cách sử dụng các thư viện giao tiếp tập thể như torch.distributed và NCCL, việc định tuyến MoE liên quan đến giao tiếp ngang hàng thưa thớt. Một nhân điều phối (dispatch kernel) phải chia tập hợp các mã thông báo đến và điều phối chúng đến các hàng (rank) lưu trữ các chuyên gia, trong khi bài toán đối ngẫu của nó, nhân kết hợp (combine kernel), phải nhận các bản sao đã được xử lý của chúng và tính toán mức trung bình có trọng số của chúng. Các hoạt động truyền tải này không ánh xạ tới các hoạt động tập thể và đòi hỏi các nhân tùy chỉnh để đạt được độ trễ thấp.

Tại Perplexity, chúng tôi đã phát triển cả nhân di động giữa các nút và nhân chuyên biệt trong một nút, trình bày công việc của mình chi tiết hơn trong một bài viết trước đây về giao tiếp MoE. Chúng tôi cũng đã chỉ ra trong một bài đăng blog khác rằng việc triển khai đa nút có thể mang lại độ trễ thấp hơn và thông lượng cao hơn cho các mô hình MoE lớn.

Trong bài viết này, chúng tôi đi sâu vào việc triển khai các nhân giữa các nút mới của mình, giúp cải thiện đáng kể hiệu suất của công việc trước đó dựa trên NVSHMEM. Bên cạnh việc trưng bày các kết quả tiên tiến trên ConnectX-7, chúng tôi cũng chứng minh rằng trong thời gian chạy suy luận của mình, các nhân này có thể được sử dụng để phục vụ hiệu quả các mô hình mã nguồn mở lớn nhất.

Suy luận qua InfiniBand

Tính song song tensor và tính song song chuyên gia có thể mở rộng quy mô hiệu quả trong một nút duy nhất, vì NVLink cung cấp thông lượng cao (900GB/s) ở độ trễ tính bằng micro giây. Mặc dù các hệ thống NVIDIA GB200 và GB300 được trang bị đủ bộ nhớ để giữ trọng số và bộ nhớ đệm KV của các mô hình hàng nghìn tỷ tham số, việc triển khai trên thể hiện (instance) AWS p5en với tối đa 8 GPU H200 bị giới hạn ở 1120GB HBM, phải được chia nhỏ cho cả trọng số mô hình và bộ nhớ đệm KV. Do đó, một số mô hình đòi hỏi phải triển khai đa nút qua InfiniBand.

Mặc dù InfiniBand vẫn cực kỳ nhanh, nó chỉ cung cấp thông lượng 400Gbps (50GB/s), thêm độ trễ từ hàng chục đến hàng trăm micro giây cho việc định tuyến MoE. May mắn thay, các độ trễ bổ sung có thể được ẩn đi thông qua việc sử dụng các chuyên gia được chia sẻ, vi lô (micro-batching) và chồng chéo tính toán-giao tiếp để mang lại thông lượng khả thi với chi phí cạnh tranh. DeepSeek đã tiên phong trong các kỹ thuật này thông qua DeepSeek-R1, được triển khai trên các cụm GPU H800 và bộ điều hợp NVIDIA ConnectX-7 InfiniBand.

Trên các cụm AWS, tình hình lại khác do việc sử dụng Bộ điều hợp Vải Đàn hồi (EFA) tùy chỉnh của họ. Mặc dù các bộ điều hợp này đạt đỉnh thông lượng 400Gbps trên các hoạt động tập thể thường được sử dụng trong khối lượng công việc đào tạo, chúng lại kém hơn một chút so với ConnectX-7 về kích thước thông điệp được trao đổi trong quá trình điều phối và kết hợp MoE. Ngoài ra, EFA không hỗ trợ GPUDirect Async, đòi hỏi một chuỗi proxy CPU bắc cầu giữa GPU và NIC để khởi tạo việc truyền tải. Bên cạnh độ phức tạp bổ sung, các giao dịch PCIe bổ sung tạo ra chi phí chung (overhead) trị giá bằng micro giây cho tất cả các hoạt động truyền tải. Các framework như NVSHMEM cho phép các nhà viết nhân cung cấp các triển khai độc lập với thiết bị, tuy nhiên các API chung sẽ phát sinh chi phí chung khiến việc triển khai trở nên kém hiệu quả về cả chi phí và độ trễ.

pplx-kernels dựa trên NVSHMEM

Các nhân trước đây của chúng tôi đã trừu tượng hóa việc triển khai truyền tải cơ bản thông qua NVSHMEM. Chúng dựa vào nvshmemx_putmem_signal_nbi_warp để truyền các mã thông báo từng cái một, sử dụng các bộ đếm nguyên tử để đồng bộ hóa các bên. Mặc dù điều này mang lại hiệu suất hợp lý trên các NIC ConnectX-7 với IBGDA, việc triển khai ConnectX-7 IBRC dựa trên proxy lại chậm hơn đáng kể, trong khi việc triển khai EFA không thể cung cấp độ trễ dưới một mili giây.

Chúng tôi đã sử dụng các nhân làm nền tảng thử nghiệm cho phần cứng bên dưới, đồng thời xác định giao diện phù hợp nhất để hiển thị cho các mô hình của mình. Chúng tôi giả định rằng việc truyền tải và tương tác thường xuyên giữa các nhân và các NIC hoặc các chuỗi proxy đã cản trở hiệu suất. Ngoài ra, việc triển khai của chúng tôi không dựa vào bất kỳ đảm bảo nào từ phần cứng ngoài độ tin cậy, điều này cho thấy rằng chúng tôi có thể tăng tốc mọi thứ bằng cách giảm chi phí chung của các nguyên hàm đồng bộ hóa.

Sau những quan sát này, chúng tôi đã thiết kế các nhân dựa trên EFA hiển thị cùng một giao diện, tối ưu hóa các tương tác giữa nhân thiết bị và proxy máy chủ bên trong để đạt hiệu suất đỉnh.

Tất cả-đến-tất cả MoE qua EFA

Phóng to

Các nhân mới tuân theo kiến trúc lai CPU-GPU, trong đó các nhân GPU tương tác với mô hình trên thiết bị và một chuỗi proxy chạy trên CPU máy chủ xử lý các tương tác với NIC. Các nhân mới tái sử dụng cùng một TransferEngine mà chúng tôi đã xây dựng cho việc truyền bộ nhớ đệm KV.

Việc định tuyến MoE được thực hiện bởi một nhân điều phối, nhận các mã thông báo và các chuyên gia trên mỗi mã thông báo để định tuyến chúng từ mô hình, chuyển chúng qua mạng đến các hàng lưu trữ các chuyên gia. Sau khi các nhân GEMM được nhóm nhân các mã thông báo với trọng số chuyên gia, nhân kết hợp sẽ truyền các mã thông báo sang các hàng nguồn của chúng và tính toán mức trung bình có trọng số của chúng trước khi trả chúng về cho mô hình.

Cả nhân điều phối và kết hợp đều được chia thành một nửa bên gửi và một nửa bên nhận để hỗ trợ việc chồng chéo và vi lô. Bên gửi xáo trộn các mã thông báo vào các bộ đệm gửi để chúng có thể được ghi vào các bên ngang hàng thông qua một thao tác ghi RDMA duy nhất. Sau khi thực thi bên gửi, GPU có thể thực hiện công việc khác (chẳng hạn như phép nhân chuyên gia được chia sẻ) trong khi việc truyền qua mạng đang chờ xử lý ở chế độ nền. Các nhân bên nhận chặn cho đến khi tất cả các bản truyền đã được nhận. Ở chế độ nền, một chuỗi công nhân phía máy chủ xử lý việc truyền: nó nhận tín hiệu từ GPU khi các bộ đệm gửi đã được điền, sau đó nó điều phối các bản ghi RDMA. Khi NIC báo hiệu hoàn tất, nó bỏ chặn bên nhận, trả các mã thông báo về cho mô hình.

Các nhân được ghép nối chặt chẽ với máy chủ, giao tiếp với nhau thông qua cả bộ nhớ hợp nhất và GDRCopy. Bộ nhớ hợp nhất CUDA cho phép bộ nhớ thiết bị hoặc bộ nhớ máy chủ được ánh xạ vào không gian địa chỉ của cả hai, xử lý minh bạch việc giao tiếp thông qua PCIe.

Mặc dù bộ nhớ hợp nhất phù hợp cho việc truyền tải hàng loạt, việc thăm dò độ trễ thấp được thực hiện thông qua GDRCopy. GDRCopy sử dụng GPUDirect RDMA để đọc và ghi vào bộ nhớ GPU ở độ trễ micro giây.

Ngoài RDMA, trong một nút, các nhân cũng tận dụng NVLink để trao đổi mã thông báo. Điều này có thể giảm tải một phần đáng kể lưu lượng truy cập, lên tới một phần tư đối với EP32 và lên tới một phần tám đối với EP64, đạt được độ trễ tổng thể thấp hơn.

Bộ đệm Gửi và Nhận

Thiết kế của các bộ đệm gửi cho nhân điều phối đóng vai trò quan trọng trong việc đạt được độ trễ khả thi liên quan đến proxy máy chủ. Nếu có N hàng, mỗi hàng điều phối T mã thông báo, mỗi mã thông báo được định tuyến đến R chuyên gia trong tổng số E chuyên gia, một hàng có thể nhận tới N * T * max(R, E / N) mã thông báo trong trường hợp xấu nhất, nếu tất cả được định tuyến đến nó. Hơn nữa, giới hạn tối thiểu này chỉ có thể đạt được khi bên gửi sắp xếp các bản ghi của chúng liên tiếp, vì các bộ đệm nhận riêng sẽ sử dụng quá nhiều bộ nhớ. Để bên gửi có thể sắp xếp các bản ghi của chúng liên tiếp mà không có xung đột, toàn bộ kiến thức về thông tin định tuyến phải được phân phối đến từng hàng. Do đó, các nhân điều phối của chúng tôi trước tiên trao đổi số lượng mã thông báo trên mỗi chuyên gia, sau đó mỗi nhân có thể xác định vị trí các bản ghi của chúng đi đến và độ lệch mà chúng nhận mã thông báo từ mỗi hàng.

Việc đơn giản trao đổi thông tin định tuyến sẽ dẫn đến độ trễ cao không cần thiết, vì mỗi hàng sẽ phải đợi các bản ghi đến trước khi điều phối bất kỳ bản ghi nào của chính mình. Thay vào đó, chúng tôi dự trữ một lượng nhỏ Space riêng trên mỗi hàng nhận cho mỗi bên gửi và điều phối một số mã thông báo cùng với các bản ghi của thông tin định tuyến. Điều này đảm bảo việc sử dụng băng thông đầy đủ trong hầu hết quá trình điều phối. Sau khi các tuyến đường được trao đổi, các mã thông báo còn lại được truyền qua một lần ghi duy nhất cho mỗi bên ngang hàng từ xa. Việc trao đổi thông tin định tuyến và các bộ đệm có kích thước cố định, cùng với việc truyền điền vào chúng, được minh họa trong hình bên dưới.

Phóng to

Các nhân kết hợp đơn giản hơn đáng kể, vì thông tin định tuyến đã có sẵn cho chúng từ giai đoạn điều phối. Chúng có thể sao chép các mã thông báo qua trong một lần ghi duy nhất cho mỗi bên ngang hàng, sau đó chúng đọc từ bộ đệm nhận để tính toán mức trung bình có trọng số của các mã thông báo vào các tensor đầu ra.

Đối với NVLink, các bộ đệm gửi và nhận trong một nút được ánh xạ vào các bên ngang hàng để chúng có thể trực tiếp đẩy hoặc kéo mã thông báo từ các hàng lân cận.

Điều phối và Kết hợp

Các hình dưới đây trình bày chi tiết về thời gian và các tương tác giữa GPU, CPU và NIC, cho thấy một lần lặp điều phối và kết hợp đan xen với các nhân của mô hình.

Công việc bắt đầu ở quá trình gửi điều phối, với nhân tổng hợp thông tin định tuyến và tính toán số lượng mã thông báo trên mỗi chuyên gia thông qua tích lũy nguyên tử trong bộ nhớ chia sẻ trong một khối duy nhất. Khi số lượng mã thông báo khả dụng, chúng được sao chép vào bộ nhớ máy chủ và proxy được thông báo ngay lập tức để bắt đầu điều phối thông tin định tuyến đến tất cả các hàng ngang hàng khác. Song song đó, quá trình điều phối tiếp tục tính tổng tích lũy của số lượng mã thông báo, xác định các độ lệch cần thiết để đóng gói mã thông báo vào các bộ đệm gửi liên tiếp trên mỗi người. Khi các độ lệch khả dụng, tất cả các mã thông báo cần gửi qua EFA được đóng gói vào các bộ đệm gửi. Proxy được thông báo để đăng các bản ghi vào các bộ đệm gửi của các bên ngang hàng giữa các nút. Trong cùng một nút, các nhân cũng ngay lập tức đẩy mã thông báo vào các bộ đệm riêng trong cùng một nút thông qua NVLink.

Phóng to

Phóng to

Khi một hàng nhận được thông tin định tuyến từ tất cả các bên ngang hàng, nó tập trung hóa thông tin đó và tính toán các độ lệch khác nhau cần thiết để xác định mã thông báo cho việc điều phối và kết hợp. Công việc này được thực hiện trên CPU trong khi việc truyền đã đang chờ xử lý, do đó nó không quan trọng về độ trễ. Sau đó, khi tất cả các độ lệch đã được biết, các bản ghi cho phần còn lại của mã thông báo, vượt quá kích thước bộ nhớ đệm riêng, được đăng và giai đoạn gửi của quá trình điều phối hoàn tất.

Ở đầu nhận, nhân trước tiên kéo các mã thông báo từ cùng một nút vượt quá dung lượng của các bộ đệm riêng thông qua NVLink. Tiếp theo, nó chặn cho đến khi proxy máy chủ báo hiệu hoàn tất tất cả các hoạt động truyền tải. Khi nhận được tín hiệu, các mã thông báo được xáo trộn từ các bộ đệm nhận vào tensor đầu ra được truyền tới nhóm GEMM. Vì các bộ đệm được tái sử dụng giữa điều phối và kết hợp, cả rào cản NVLink và RDMA đều đảm bảo rằng các bộ đệm nhận đã được đọc trước khi cho phép nhân tiếp theo ghi đè lên chúng.

Các nhân kết hợp tuân theo một mẫu tương tự khoảng, xáo trộn mã thông báo, báo hiệu proxy và đợi hoàn tất. Tuy nhiên, siêu dữ liệu để đăng các bản ghi của chúng đã sẵn có và tất cả các độ lệch từ xa đều được biết, do đó tất cả các mã thông báo được truyền trong nội bộ nút được đẩy qua NVLink đến các bên nhận và các mã thông báo giữa các nút được truyền qua một lần ghi duy nhất. Trước khi trả về kết quả, nhân tích lũy các mã thông báo từ các bộ đệm nhận, ghi chúng vào các tensor đầu ra.

TransferEngine cho định tuyến MoE

Để tạo mẫu cho việc triển khai của mình, ban đầu chúng tôi đã tái sử dụng Transfer Engine được xây dựng cho việc tiền điền và giải mã phân tách nhằm phát hành và theo dõi các bản ghi RDMA. Tuy nhiên, không giống như giải mã phân tách nơi mỗi nút đăng một số lượng lớn các bản ghi đến cùng một bên ngang hàng, việc điều phối MoE đăng các bản truyền nhỏ đến tất cả các bên ngang hàng trong một thao tác duy nhất. Ngay lập tức, hiệu suất không đạt mức tối ưu và việc triển khai của chúng tôi chậm hơn DeepEP trên ConnectX-7 khoảng 20us. Do đó, chúng tôi đã chuyên biệt hóa TransferEngine để hỗ trợ hai thao tác, rải (scatter) và rào cản (barrier), nhằm tối ưu hóa các tương tác với số lượng lớn các bên ngang hàng.

Cả hai thao tác rải và rào cản đều hiển thị các nhóm bên ngang hàng có thể được đăng ký trước để điền trước các cấu trúc dữ liệu được sử dụng bởi việc triển khai truyền tải cơ bản (tạo mẫu Yêu cầu Công việc (WR)). Rải sao chép các lát cắt khác nhau từ cùng một bộ đệm nguồn vào các độ lệch khác nhau trên tất cả các thành viên của một nhóm bên ngang hàng. Rào cản báo hiệu tất cả các bên ngang hàng thông qua một tín hiệu tức thời. Việc xếp hàng và xử lý các thao tác này theo lô giúp tiết kiệm micro giây quý giá trên đường dẫn quan trọng. Trên EFA, nơi hai NIC 200Gbps tổng hợp để cung cấp băng thông 400Gbps, chúng tôi phân đoạn các bên ngang hàng trong nhóm trên hai NIC thay vì phân đoạn các byte của mỗi lần truyền.

Mặc dù ban đầu chúng tôi phát triển TransferEngine độc quyền trên EFA bằng cách sử dụng libfabric, các nhân MoE hoạt động trên ConnectX-7 mà không cần thay đổi một dòng mã nào sau khi thêm hỗ trợ ConnectX-7 vào TransferEngine bằng cách sử dụng libibverbs. So với EFA dựa trên Datagram Tin cậy Có thể mở rộng (SRD), ConnectX-7 đòi hỏi công việc bổ sung để thiết lập kết nối và quản lý bên ngang hàng. Chúng tôi sử dụng một cặp hàng đợi Datagram Không đáng tin cậy (UD) để khởi động Kết nối Đáng tin cậy (RC). Chúng tôi tạo hai cặp hàng đợi cho mỗi bên ngang hàng từ xa, một cho GỬI/NHẬN hai chiều và một cho WRITE_IMM một chiều, bởi vì cả RECV và WRITE_IMM đều tiêu thụ thao tác RECV theo thứ tự trong khi hai thao tác yêu cầu kích thước bộ nhớ đệm khác nhau. Bên cạnh đó, chúng tôi nới lỏng thứ tự giao dịch PCIe giữa ConnectX-7 và bộ nhớ GPU. Tương tự như EFA, chúng tôi triển khai tối ưu hóa tạo mẫu WR. Ngoài ra, khi gửi nhiều thông điệp nhỏ đến cùng một bên ngang hàng, chúng tôi sử dụng chuỗi WR để cải thiện tốc độ thông điệp.

Vì công việc phía GPU giống hệt nhau trên cả hai bộ điều hợp, chúng tôi đã đẩy việc triển khai truyền tải cơ bản đến giới hạn của nó để vượt qua hiệu suất của DeepEP nhằm làm nổi bật rằng khoảng cách giữa định tuyến MoE của EFA và ConnectX-7 được quyết định bởi các khả năng của phần cứng cơ bản.

Đánh giá

Độ trễ Điều phối/Kết hợp

Chúng tôi đã đánh giá độ trễ điều phối và kết hợp trên các hệ thống H200 được trang bị bộ điều hợp ConnectX-7 và EFA trên cấu hình DeepSeek-V3 và Kimi-K2 tiêu chuẩn với kích thước ẩn là 7168, điều phối fp8 được chia tỷ lệ theo khối và kết hợp bf16. Chúng tôi xem xét kích thước lô là 128 cho điều phối và 4096 cho kết hợp. Trên ConnectX-7, chúng tôi so sánh với DeepEP và các pplx-kernels dựa trên NVSHMEM trước đây của chúng tôi, sử dụng cả GPUDirect Async (IBGDA) và proxy máy chủ (IBRC). Chúng tôi đạt được độ trễ kết hợp lần lượt là 459us, 582us và 692us trên EP16, EP32 và EP64. Chúng tôi vượt trội hơn các nhân dựa trên EFA khác dựa vào các proxy chung, chẳng hạn như UCCL-EP, đạt 519us, 966us và 1159us.

Phóng to

Về giải mã, mặc dù các nhân của chúng tôi chậm hơn DeepEP vài micro giây, chúng tôi đạt được độ trễ tổng thể thấp hơn vì các nhân kết hợp của chúng tôi nhanh hơn đáng kể. Mặc dù chúng tôi sử dụng proxy máy chủ, do việc truyền tải hàng loạt của mình, chúng tôi vượt qua hiệu suất của tất cả các triển khai không có proxy dựa trên IBGDA. Chúng tôi cũng chỉ ra rằng việc triển khai proxy rất quan trọng, vì proxy chuyên biệt cao của chúng tôi nhanh hơn một bậc độ lớn so với việc triển khai NVSHMEM chung. Mặc dù thực tế là EFA chậm gấp đôi so với ConnectX-7 khi truyền các gói 256KB, vốn gần với kích thước gói điển hình được trao đổi bởi định tuyến MoE, khoảng cách giữa hai bộ điều hợp nhìn chung ít đáng kể hơn.

Phóng to

Mặc dù các nhân được tối ưu hóa giải mã của chúng tôi có thể mở rộng quy mô cho các kích thước lô tiền điền mà không cần bất kỳ tinh chỉnh bổ sung nào, hiệu suất vẫn kém hơn DeepEP. Điều này chủ yếu là do thực tế là chúng tôi chỉ tích lũy mã thông báo ở phía nhận của quá trình kết hợp, trong khi DeepEP tích lũy ở bên gửi để giảm lượng dữ liệu được truyền. Tuy nhiên, sự tối ưu hóa này có thể có tác động đến độ chính xác. Ngoài ra, vì các nhân truyền dữ liệu trong một lần ghi, chúng tôi tận dụng nhiều bộ nhớ hơn cho bộ nhớ đệm gửi và nhận.

Thông lượng Kimi-K2 / DeepSeek-V3

Để chứng minh tính khả thi của các nhân của mình, chúng tôi đánh giá hiệu suất từ đầu đến cuối của công cụ suy luận nội bộ của mình phục vụ DeepSeek-V3 (671B tham số) và Kimi-K2 (1T tham số) trên nhiều thể hiện p5en được trang bị Bộ điều hợp Vải Đàn hồi (EFA) và GPU H200. Chúng tôi chạy mô hình ở chế độ xác minh bản nháp và báo cáo độ trễ giả định tỷ lệ chấp nhận là 80% sử dụng một lớp MTP duy nhất.

Trên DeepSeek-V3, chúng tôi so sánh với đường cơ sở trong một nút EP=8 chạy các nhân điều phối và kết hợp chỉ sử dụng NVLink hiệu quả. Các triển khai đa nút tổng thể hoặc khớp hoặc vượt quá hiệu suất của việc triển khai một nút, đặc biệt là trên các lô cỡ trung bình, chứng minh rằng việc mở rộng quy mô trên các nút mang lại những cải thiện cho thông lượng tổng thể.

Trên Kimi-K2, các nhân cho phép phục vụ. Do kích thước của nó, mô hình không thể vừa vặn trong cùng một nút bằng cách sử dụng Tính song song Dữ liệu (DP) trên một nút H200, do đó cần phải triển khai đa nút để phục vụ mô hình. Vì mô hình có ít đầu chú ý (attention head) hơn, chúng tôi đạt được độ trễ tốtกว่า DeepSeek-V3 và chúng tôi có thể phục vụ mô hình trên EFA ở độ trễ khả thi.

Phóng to

Phóng to

Chúng tôi cũng đã xem xét vi lô, mặc dù nó chỉ cải thiện độ trễ ở kích thước lô rất cao hoặc khi sử dụng nhiều hơn một mã thông báo nháp. Để hưởng lợi từ việc chia các bài toán GEMM được nhóm thành hai, kích thước lô mã thông báo phải đủ dày. Phần lớn thời gian vẫn dành cho việc điều phối và kết hợp MoE, cho thấy rằng bất kỳ cải tiến nào nữa đối với các nhân sẽ do đó cải thiện độ trễ và tạo điều kiện cho vi lô.

Công việc trong tương lai

Chúng tôi đang hợp tác chặt chẽ với các kỹ sư AWS để cải thiện hiệu suất trên EFA. Về phần mình, chúng tôi sẽ theo dõi các cập nhật đối với libfabric nhằm giúp giảm chi phí chung của mặt phẳng dữ liệu. Ngoài ra, chúng tôi sẽ thử nghiệm với efa-direct để giảm hơn nữa chi phí chung của không gian người dùng và giao tiếp trực tiếp với phần cứng.

Tài liệu tham khảo

Báo cáo Kỹ thuật DeepSeek R1

Báo cáo Kỹ thuật Kimi K2

DeepEP

UCCL-EP

Cải thiện Hiệu suất Mạng của Hệ thống HPC Sử dụng NVIDIA Magnum IO NVSHMEM và GPUDirect Async

Trích dẫn

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}