AI/ML trên Ethernet

20/04/2024
Bookmark Tin tức

Mạng trung tâm dữ liệu AI/ML trên Ethernet

Đây là bài viết đầu tiên trong loạt blog kỹ thuật sẽ nêu rõ vai trò chính của mạng trong khối lượng công việc AI/ML – cụ thể là khối lượng công việc đào tạo và suy luận. Trong blog này, chúng tôi thảo luận về các giao thức truyền dữ liệu và các cân nhắc về tắc nghẽn cho những khối lượng công việc như vậy. Loạt bài này sẽ đề cập đến một loạt các kỹ thuật, bao gồm kiểm soát tắc nghẽn dựa trên kết cấu và cân bằng tải, cũng như các phương pháp tiếp cận dựa trên điểm cuối (hoặc được điểm cuối hỗ trợ).

Hiện trạng và sự phát triển của mạng trung tâm dữ liệu AI/ML trên Ethernet

Trong lĩnh vực khối lượng công việc AI/ML, việc xử lý các tập dữ liệu lớn là một thách thức quan trọng. Việc giảm tải tính toán cho GPU giúp tăng tốc đáng kể nhiệm vụ này. Tuy nhiên, kích thước của dữ liệu và thông thường, mô hình (như với Mô hình ngôn ngữ lớn [LLM]), thường vượt quá dung lượng bộ nhớ của một GPU và thường cần nhiều GPU để đạt được thời gian hoàn thành công việc hợp lý, đặc biệt là cho đào tạo. Để xử lý khối lượng công việc như vậy, các chiến lược khác nhau được sử dụng dựa trên các khung và trường hợp sử dụng AI/ML cụ thể, yêu cầu phân phối dữ liệu và tính toán trên một cụm nút GPU.

Như độc giả có thể đã biết, chi phí của một trung tâm dữ liệu AI chủ yếu được quyết định bởi số lượng GPU được sử dụng. Để tránh tài nguyên GPU nhàn rỗi, cần có mạng hiệu suất cao kết nối các nút GPU. Bất kỳ sự chậm lại nào trong lớp mạng này đều có thể làm giảm việc sử dụng GPU đắt tiền và tác động tiêu cực đến thời gian hoàn thành công việc.

Bắt nguồn từ cộng đồng Điện toán hiệu năng cao (HPC), các phương pháp sử dụng Truy cập bộ nhớ trực tiếp từ xa (RDMA) hiện được sử dụng rộng rãi trong giao tiếp cụm AI/ML. RDMA hỗ trợ truyền dữ liệu bằng cách cho phép truyền không sao chép giữa bộ nhớ từ xa trên nhiều tài nguyên điện toán với GPU (nút GPU) qua mạng. Điều này được thực hiện bằng cách sử dụng giao thức truyền tải Kết nối đáng tin cậy (RC) được triển khai trong thẻ giao diện mạng (NIC), giao thức này áp đặt ít hoặc không tải lên CPU hoặc GPU. Được thiết kế ban đầu cho mạng InfiniBand, RC có các yêu cầu nghiêm ngặt, bao gồm mạng không mất dữ liệu và phân phối gói theo thứ tự.

RDMA + Ethernet = ROCEv2

Trong bối cảnh mạng cụm đào tạo AI/ML, ngày càng có nhiều mối quan tâm đến việc coi mạng dựa trên Ethernet như một giải pháp thay thế cho InfiniBand. Để kích hoạt RDMA trong mạng Ethernet, RDMA qua Ethernet hội tụ phiên bản 2 (ROCEv2) đã được phát triển, một giao thức đóng gói các gói giao thức RDMA/RC trong các gói UDP để truyền qua mạng Ethernet.

Sự tắc nghẽn trong các kết cấu Ethernet dựa trên Clos

Các loại vải Ethernet, trong kiến trúc điển hình cho các ứng dụng này, sử dụng cấu trúc liên kết Clos, bao gồm các lớp lá và gai. Để cung cấp một mạng không chặn, băng thông tích lũy của tất cả các cổng từ lá tới nút phải bằng hoặc nhỏ hơn băng thông tổng hợp của tất cả các cổng đường lên từ lá đến cột sống. Thiết lập này đảm bảo rằng các nút có thể sử dụng toàn bộ băng thông của chúng mà không bị chậm lại do kết nối giữa các thiết bị chuyển mạch lá và cột sống.

Trong các kiến trúc cột sống lá, tắc nghẽn có thể biểu hiện ở ba khu vực chính:

  1. Giữa lá và cột sống (hàng đợi TX của cổng lá về phía cột sống): Tắc nghẽn phát sinh trong quá trình truyền dữ liệu từ các chuyển mạch lá đến các chuyển mạch cột sống. Hàng đợi TX của cổng lá có thể bị tắc nghẽn, ảnh hưởng đến giao tiếp giữa các thiết bị chuyển mạch này.
  2. Giữa gáy và lá (hàng đợi TX của cổng gai về phía lá): Tắc nghẽn biểu hiện trong quá trình truyền dữ liệu từ các switch cột sống đến các switch lá. Hàng đợi TX của cổng trục có thể gặp phải tình trạng tắc nghẽn, ảnh hưởng đến khả năng liên lạc giữa các thiết bị chuyển mạch này.
  3. Giữa lá và nút (hàng đợi TX của cổng lá về phía nút): Tắc nghẽn có thể xảy ra trong luồng dữ liệu từ các chuyển mạch lá đến các nút riêng lẻ. Hàng đợi TX của cổng lá có thể bị tắc nghẽn, ảnh hưởng đến giao tiếp giữa các switch lá và các nút được kết nối.

Tắc nghẽn lá đến cột sống

Trong ví dụ này, các nút GPU được kết nối với một nút chuyển mạch lá có hai tuyến tiềm năng để giao tiếp với các nút GPU được liên kết với một nút chuyển mạch lá khác. Các nút GPU 1 và 2 có thể thiết lập kết nối với các nút GPU 3 và 4 thông qua “lá 1, cột sống 1 và lá 2” hoặc “lá 1, cột sống 2 và lá 2”. Quyết định về đường dẫn sẽ được thực hiện bởi switch lá, sử dụng thuật toán cân bằng tải đa đường chi phí bằng nhau (ECMP).

ECMP hoạt động bằng cách tạo ra hàm băm dựa trên các thuộc tính cụ thể (chẳng hạn như địa chỉ IP nguồn/đích, cổng nguồn/đích và giao thức) của các gói đến. Các gói tiếp theo có giá trị băm phù hợp sẽ được chuyển hướng đến cùng một đường dẫn lên tới cột sống, tạo thành cái được gọi là “dòng” trong ECMP. Ánh xạ luồng tới đường lên này có thể được xác định bằng nhiều phương pháp khác nhau như ánh xạ Hash-Threshold hoặc ánh xạ Modulo-N. ECMP nhằm mục đích phân phối đồng đều các gói trên các đường lên có sẵn trong khi vẫn duy trì thứ tự gói trong mỗi luồng. Phương pháp này hoạt động hiệu quả đối với các ứng dụng dựa trên TCP điển hình trong đó nhiều phiên tồn tại trong thời gian ngắn trải rộng trên nhiều nút tạo ra các giá trị băm khác nhau cho mỗi phiên, đảm bảo phân phối trên các đường lên khác nhau.

Tuy nhiên, những thách thức nảy sinh với dòng chảy kéo dài. Trong trường hợp nhiều luồng băng thông cao được băm để chia sẻ cùng một đường lên, chúng có thể vượt quá băng thông sẵn có của liên kết cụ thể đó, dẫn đến sự cố tắc nghẽn.

 Xem xét sơ đồ trên, lớp từ lá đến cột sống cung cấp băng thông kết hợp 200Gbps trên hai đường dẫn. Nút GPU 1 tạo ra hai luồng tồn tại lâu dài: một luồng tiêu thụ 70Gbps qua đường dẫn đầu tiên và một luồng khác tiêu thụ 30Gbps qua đường dẫn thứ hai. Nút GPU 2 tạo ra luồng tồn tại lâu dài sử dụng tốc độ 70Gbps. Mặc dù đường dẫn thứ hai có đủ dung lượng cho luồng này nhưng thuật toán ECMP có thể đặt nó trên đường dẫn thứ nhất, chỉ còn lại dung lượng 30Gbps. Sự không khớp này có thể làm quá tải đường dẫn đầu tiên, gây tắc nghẽn trong hàng đợi TX của các cổng lá và cuối cùng dẫn đến các gói bị rớt. Nguyên nhân cốt lõi của sự phân phối dưới mức tối ưu này nằm ở tính đơn giản của ECMP; nó thiếu các cân nhắc về việc sử dụng liên kết và chất lượng trong việc lựa chọn đường dẫn, thay vào đó dựa vào cơ chế cơ bản dựa trên số lượng luồng.

Tắc nghẽn từ cột sống đến lá

Trong cấu hình này, nút GPU 2, được liên kết với lá 2 và nút GPU 3, được kết nối với lá 3, đang đồng thời truyền dữ liệu ở băng thông tối đa, mỗi nút đóng góp lưu lượng 100Gbps cho nút GPU 1 được kết nối với lá 1. Lá 1, 2 và 3 kết nối dự phòng với hai gai, mỗi gai được trang bị kết nối 100Gbps. Tổng băng thông khả dụng giữa mỗi lá và lớp gai là 200Gpbs.

Tuy nhiên, nếu cả lá 2 và lá 3 đều sử dụng các đường lên của chúng tới cùng một trục, hàng đợi TX của cổng trục hướng tới bộ chuyển mạch lá được kết nối với nút GPU nhận sẽ bị tắc nghẽn.

Tắc nghẽn từ nút đến nút

Điểm tắc nghẽn tiềm ẩn thứ hai xảy ra trong giao tiếp giữa switch lá và nút, đặc biệt khi nhiều người gửi truyền dữ liệu đến một người nhận, vượt quá dung lượng băng thông của người nhận. Điều này được gọi là tắc nghẽn “incast”.

Giả sử tất cả các cổng nút đều có dung lượng băng thông 100Gbps, các nút GPU 1 và 2 cùng nhau truyền hết công suất, tổng cộng là 200Gbps. Lớp leaf-to-spin có thể xử lý đầy đủ lưu lượng dành cho switch lá mà bộ thu được kết nối. Tuy nhiên, cổng lá mà nút GPU 3 được gắn vào có dung lượng băng thông chỉ 100Gbps. Do đó, một nửa lưu lượng đến cảng này sẽ bị giảm do năng lực hạn chế của cảng (giả sử không có kiểm soát luồng hoặc quản lý tắc nghẽn).

Tác động đến ROCEv2

  • ECMP truyền thống có thể dẫn đến việc sử dụng mạng dưới mức tối ưu, tắc nghẽn và rớt gói giữa các thiết bị chuyển mạch lá và cột sống, đặc biệt là với các luồng băng thông cao (“voi”) tồn tại lâu dài phổ biến trong khối lượng công việc AI/ML.
  • Sự tắc nghẽn tại các cổng từ lá đến nút có thể dẫn đến giảm gói khi băng thông kết hợp của người gửi vượt quá khả năng của người nhận.

Để đạt được mức sử dụng mạng tốt hơn, một số kỹ thuật phân phối tải nâng cao đã xuất hiện, chẳng hạn như Cân bằng tải động (DLB) cung cấp cân bằng dựa trên “dòng chảy” hoặc phân bổ gói để phân phối lưu lượng truy cập trên cơ sở từng gói. Tuy nhiên, DLB có thể không áp dụng được cho lưu lượng RDMA và việc rải gói có thể gây ra việc phân phối gói không theo thứ tự. Chúng ta sẽ thảo luận sâu hơn về những kỹ thuật như vậy và ý nghĩa của chúng trong blog tiếp theo của loạt bài này.

Trong kết cấu Ethernet, những thách thức của mạng bị mất dữ liệu thường được quản lý ở cấp độ giao thức (ví dụ: TCP) hoặc cấp độ ứng dụng (ví dụ: VoIP với UDP). Các giao thức và ứng dụng này được thiết kế đặc biệt để hoạt động hiệu quả trong môi trường Ethernet.

Tuy nhiên, RDMA sử dụng giao thức RC đặt ra một thách thức vì ban đầu nó được thiết kế cho các loại vải InfiniBand cung cấp khả năng phân phối gói không bị mất và theo thứ tự. Giao thức RC rất nhạy cảm với việc mất gói và gửi gói không theo thứ tự. Trong RC, các gói được sắp xếp theo thứ tự và nếu chúng bị mất hoặc không theo thứ tự, NIC có thể yêu cầu truyền lại dựa trên cơ chế “go-back-N”, truyền lại tất cả các gói từ gói được xác nhận cuối cùng. Các kết nối thậm chí có thể cần phải được gỡ bỏ và thiết lập lại do hết thời gian chờ do các gói bị rơi. Điều này làm giảm đáng kể hiệu suất giao tiếp, dẫn đến giảm mức sử dụng GPU và thời gian hoàn thành công việc lâu hơn trong các cụm AI/ML.

Để giải quyết các vấn đề về mất gói, phân phối không theo thứ tự và tắc nghẽn trong Ethernet cho ROCEv2, các cơ chế thay thế phải được sử dụng.

Hiện tại các yêu cầu về vải của RoCEv2 đã đạt được như thế nào?

Yêu cầu chính của kết cấu này là phân phối gói tin không bị mất dữ liệu. Điều này đạt được nhờ kỹ thuật kiểm soát luồng được gọi là Kiểm soát luồng dựa trên mức độ ưu tiên (PFC). Kỹ thuật này hoạt động độc lập theo mức độ ưu tiên (có 8 mức độ ưu tiên). Điều này cho phép người nhận tạm dừng người gửi được kết nối trực tiếp với nó. Khi bộ đệm nhận trên máy thu lấp đầy đến mức ngưỡng, máy thu sẽ truyền khung tạm dừng cho người gửi để tạm thời ngăn người gửi truyền thêm khung hình. Ngưỡng bộ đệm phải đủ thấp để bên gửi có thời gian dừng truyền khung và bên nhận có thể chấp nhận các khung đã có trên dây trước khi bộ đệm tràn. Khung tạm dừng bao gồm thời gian chờ có thể được đặt thành 0 (có nghĩa là tiếp tục gửi). Khi bộ đệm nhận trống đến mức dưới ngưỡng khác, người nhận sẽ gửi một tin nhắn như vậy để tiếp tục gửi.

PFC có thể dẫn đến hành vi mạng không mong muốn, chẳng hạn như chặn đường truyền, lan truyền tắc nghẽn và thậm chí bế tắc. Điều này thúc đẩy việc sử dụng Thông báo tắc nghẽn rõ ràng (ECN) kết hợp với PFC. Với kỹ thuật này, tắc nghẽn sắp xảy ra trong mạng sẽ được báo cáo lại cho các nguồn lưu lượng để họ giảm tốc độ tiêm. Tốc độ chèn được kiểm soát theo cặp hàng đợi RoCE (QP), là tài nguyên phần cứng NIC tương ứng với hàng đợi gửi và nhận giao tiếp được ứng dụng sử dụng.

ECN được bật trên cả hai điểm cuối (NIC) và tất cả các thiết bị chuyển mạch trung gian giữa các điểm cuối. Các thiết bị mạng đánh dấu các gói bằng trường ECN của trường TOS trong tiêu đề IP. Khi gói được đánh dấu ECN đến NIC đích, gói thông báo tắc nghẽn (CNP) sẽ được gửi đến NIC nguồn và NIC nguồn sẽ phản ứng bằng cách giảm tốc độ tiêm của nó trên QP được chỉ định trong CNP. Ngưỡng ECN được đặt trên các thiết bị chuyển mạch. Đây là ngưỡng đầu ra. Khi hàng đợi đầu ra vượt quá ngưỡng này, bộ chuyển mạch sẽ bắt đầu ECN đánh dấu các gói trên hàng đợi đó.

Sự kết hợp giữa PFC và ECN cho RoCEv2 đôi khi được gọi là Thông báo tắc nghẽn lượng tử hóa trung tâm dữ liệu (DCQCN) hoặc Quản lý tắc nghẽn RoCEv2 (RCM). Hoạt động chính xác của kỹ thuật này đòi hỏi phải thiết lập ngưỡng PFC và ECN một cách cẩn thận để cân bằng các yêu cầu sau:

  • Đảm bảo rằng PFC không được kích hoạt quá sớm – nghĩa là trước khi cho ECN cơ hội gửi phản hồi tắc nghẽn để làm chậm luồng.
  • Đảm bảo rằng PFC không được kích hoạt quá muộn, do đó gây ra hiện tượng gói tin bị lỗi.

Kết luận

Kỹ thuật DCQCN là phương pháp phổ biến nhất và đã được sử dụng thành công trong triển khai RoCEv2. Tuy nhiên, việc đặt ngưỡng PFC và ECN một cách chính xác có thể là một thách thức. Ngoài ra, chúng tôi lưu ý rằng để đạt được mức sử dụng mạng tốt nhất đòi hỏi phải cân bằng tải tốt trên mạng. Những thách thức kép này thúc đẩy các phương pháp tiếp cận dựa vào các cải tiến ở điểm cuối (NIC) để tạo điều kiện cho các giải pháp được cải tiến. Những cách tiếp cận như vậy sẽ là chủ đề chính của blog trong loạt bài này trong tương lai.

CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH

  • Địa chỉ:Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
  • Điện thoại: 02432012368
  • Hotline: 098 115 6699
  • Email: info@datech.vn
  • Website:https://datech.vn