Name: Đánh giá hiệu suất của các công nghệ kết nối cho tính toán AI quy mô lớn UAL so với UALoE SU (Performance Evaluation of Interconnect Technologies for AI Scale Up Computing UAL vs UALoE SU)
Uploaded: 2025-10-25T23:22:10.000Z
Duration: 19 min 49 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Chào mọi người, buổi sáng tốt lành.

So today we are going to talk about the interconnects for scale ups.

Hôm nay chúng ta sẽ nói về các kết nối cho các hệ thống scale up.

So over the last couple of days we heard a lot of keynote speakers and presentations that talk about the importance of interconnects for scale ups.

Trong vài ngày qua, chúng ta đã nghe rất nhiều bài phát biểu và bài thuyết trình nói về tầm quan trọng của các kết nối cho các hệ thống scale up.

So here we want to talk about the two technologies, what we know about the UAL and Ethernet and we're gonna talk about the three approaches to doing that UL over Sue and Rocky and I'm Sri Vengarisna and here's my colleague Srinivas Gangam.

Hôm nay chúng ta sẽ nói về hai công nghệ, đó là UAL và Ethernet, và chúng ta sẽ nói về ba phương pháp thực hiện đó là UL over Sue và Rocky. Tôi là Sri Vengarisna và đây là đồng nghiệp của tôi Srinivas Gangam.

First let's look at the two approaches of doing that.

Đầu tiên, chúng ta hãy xem xét hai phương pháp thực hiện điều đó.

Like once we have the UAL which is based on memory semantics that use load store and atomic kind of memory transactions and we have Ethernet which has UL over Ethernet or scale up Ethernet and these are basically again memory transactions which are encapsulated over optimized Ethernet header.

Ví dụ, khi chúng ta có UAL dựa trên ngữ nghĩa bộ nhớ sử dụng các giao dịch bộ nhớ kiểu load store và atomic, và chúng ta có Ethernet với UL over Ethernet hoặc scale up Ethernet. Về cơ bản, đây lại là các giao dịch bộ nhớ được đóng gói qua Ethernet header 

So as we heard it recently too that okay, the memory transactions can be multiple transactions which can be packed in a given packet so that we can amortize the overhead of the IPG and the Ethernet header.

Như chúng ta đã nghe gần đây, các giao dịch bộ nhớ có thể là nhiều giao dịch được đóng gói trong một gói tin nhất định, để chúng ta có thể phân bổ chi phí của IPG và Ethernet header.

For RDMA transport it basically has the complete header stack of IP Ethernet, IP and the IB header.

Đối với RDMA transport, nó có toàn bộ chồng header của IP, Ethernet, IP và IB header.

So this distinction is very important as we basically go over the performance results what we're going to show later.

Vì vậy, sự phân biệt này rất quan trọng khi chúng ta xem xét kết quả hiệu suất mà chúng ta sẽ trình bày sau.

So looking at the key advantages for scale up networking, the first one is load balancing.

Vì vậy, nhìn vào những lợi thế chính cho việc mở rộng quy mô mạng, điều đầu tiên là cân bằng tải.

When we say load balancing, the load balancing can happen at a very fine granular.

Khi chúng ta nói về cân bằng tải, việc cân bằng tải có thể diễn ra ở mức rất chi tiết.

Basically we can do load balancing at 256 bytes.

Về cơ bản, chúng ta có thể cân bằng tải ở mức 256 byte.

All the memory transactions that have been read from the compute can be load balanced across all the Rails.

Tất cả các giao dịch bộ nhớ đã được đọc từ compute có thể được cân bằng tải trên tất cả các Rails.

So the Rails all can be optimized for high bandwidth.

Vì vậy, tất cả các Rails đều có thể được tối ưu hóa cho băng thông cao.

The second one is the latency characteristics for UAL.

Điều thứ hai là đặc điểm độ trễ cho UAL.

If you look at it, the DL Flit is always 640 bytes.

Nếu bạn nhìn vào nó, DL Flit luôn là 640 byte.

Vì vậy, chúng ta có độ trễ không đổi cho UL.

But for Ethernet as we heard from the previous presentation too, the latency can be variable depending on the packet size, depending on how many memory transactions you're packing within a given packet.

Nhưng đối với Ethernet, như chúng ta đã nghe từ bài thuyết trình trước, độ trễ có thể thay đổi tùy thuộc vào kích thước gói tin, tùy thuộc vào số lượng giao dịch bộ nhớ bạn đóng gói trong một gói tin nhất định.

And with memory semantics one of the biggest advantage what we can have is it can be push model.

Và với ngữ nghĩa bộ nhớ, một trong những lợi thế lớn nhất mà chúng ta có thể có là nó có thể là mô hình đẩy.

When you say push model, once the COMPUTE is done, we can directly push the data from the compute tile to the networking tile and it basically doesn't incur the knock RTT delay what we see in an soc and all the transactions what are basically started at the compute tile, they all can be completed out of order.

Khi bạn nói mô hình đẩy, một khi tính toán hoàn tất, chúng ta có thể đẩy trực tiếp dữ liệu từ khối tính toán sang khối mạng và về cơ bản là không phát sinh độ trễ RTT như chúng ta thấy trong SoC và tất cả các giao dịch bắt đầu tại khối tính toán, chúng đề

When I say completed out of order, all the transactions are load balanced across the rails and all these transactions can complete by using the maximum Bandwidth and then the completion can be done after that.

Khi tôi nói hoàn thành ngoài thứ tự, tất cả các giao dịch được cân bằng tải trên các làn đường và tất cả các giao dịch này có thể hoàn thành bằng cách sử dụng băng thông tối đa và sau đó việc hoàn thành có thể được thực hiện sau đó.

So we can get the maximum utilization of the bandwidth.

Vì vậy, chúng ta có thể tận dụng tối đa băng thông.

From the implementation point of view, a lot of choices about this implementation depends on the scale up switch, what you're going to deploy the network, for example, if at all the switch is capable of doing packets per second with no limitation, then the packing logic, what you can have in the accelerator can be very efficient.

Từ góc độ triển khai, nhiều lựa chọn về việc triển khai này phụ thuộc vào switch mở rộng quy mô, nơi bạn sẽ triển khai mạng, ví dụ, nếu switch có khả năng xử lý gói tin mỗi giây mà không có giới hạn, thì logic đóng gói mà bạn có trong bộ tăng tốc có thể r

It can basically pack only one memory transaction within a packet.

Về cơ bản, nó chỉ có thể đóng gói một giao dịch bộ nhớ trong một gói tin.

But that also adds the inherent bandwidth penalty because we have the overhead for a given transaction which is the Ethernet header.

Nhưng điều đó cũng làm tăng hình phạt băng thông cố hữu vì chúng ta có chi phí cho một giao dịch nhất định, đó là tiêu đề Ethernet.

And for the QS behavior, like depending on the number of traffic classes you have, especially the no loss traffic classes.

Và đối với hành vi QS, tùy thuộc vào số lượng lớp lưu lượng bạn có, đặc biệt là các lớp lưu lượng không mất.

These traffic classes are required in Ethernet because we need to separate the request and response channels, which are different for Ethernet.

Các lớp lưu lượng này là cần thiết trong Ethernet vì chúng ta cần tách biệt các kênh yêu cầu và phản hồi, vốn khác nhau đối với Ethernet.

But for UL we already have a request and response channel which are separated out at the EPLI layer.

Nhưng đối với UL, chúng ta đã có một kênh yêu cầu và phản hồi được tách biệt ở lớp EPLI.

So it can get better performance without any QAS properties.

Vì vậy, nó có thể đạt được hiệu suất tốt hơn mà không cần bất kỳ thuộc tính QAS nào.

But here for Ethernet we need to have separate queues and these need to be scheduled properly for end to end workload.

Nhưng ở đây đối với Ethernet, chúng ta cần có các hàng đợi riêng biệt và chúng cần được lập lịch đúng cách cho khối lượng công việc đầu cuối.

All these implementation choices have a direct impact on latency and the bandwidth.

Tất cả các lựa chọn triển khai này có tác động trực tiếp đến độ trễ và băng thông.

What we can observe in the network, this is a typical simple framework.

Chúng ta có thể quan sát thấy trong mạng, đây là một khung đơn giản điển hình.

What we are showing up, we have seen it multiple flavors of it.

Những gì chúng ta đang trình bày, chúng ta đã thấy nhiều phiên bản của nó.

Here we can see on the left hand side we have a compute tile.

Ở đây chúng ta có thể thấy ở phía bên trái là một ô tính toán.

Right hand side we have a networking tile.

And within the networking tile the TX and the RX are connected to the switch.

Và bên trong ô mạng, TX và RX được kết nối với switch.

And here the switch can be any out of the shelf ethernet switch.

Và ở đây switch có thể là bất kỳ switch Ethernet nào có sẵn trên thị trường.

And here as the experience done and wanted to transfer the payload, it basically needs to load balance across all the networking tiles.

Và ở đây theo kinh nghiệm và muốn chuyển tải dữ liệu, nó về cơ bản cần cân bằng tải trên tất cả các ô mạng.

And here as I was saying before, the load balancing can happen very efficiently because it can load balance at 256 bytes.

Và ở đây như tôi đã nói trước đó, việc cân bằng tải có thể diễn ra rất hiệu quả vì nó có thể cân bằng tải ở mức 256 byte.

And as the transactions arrive at the ethernet tile, it basically needs to go to the packing logic first.

Và khi các giao dịch đến ô mạng Ethernet, nó về cơ bản cần đi đến logic đóng gói trước.

When you talk about the packing logic, what it is trying to do is pack multiple of these memory transactions within an Ethernet packet.

Khi bạn nói về logic đóng gói, nó đang cố gắng đóng gói nhiều giao dịch bộ nhớ này vào trong một gói Ethernet.

Và nó có thể bảo tồn công việc.

But at the same time work conserving and not packing basically will affect your bandwidth.

Nhưng đồng thời bảo tồn công việc và không đóng gói về cơ bản sẽ ảnh hưởng đến băng thông của bạn.

But if at all you pack more, you inherit adds latency.

Nhưng nếu bạn đóng gói nhiều hơn, bạn sẽ gặp độ trễ.

So that's kind of the drawback of packing.

Vì vậy, đó là nhược điểm của việc đóng gói.

Then it goes to the queuing and scheduling logic.

Sau đó, nó chuyển sang logic xếp hàng và lập lịch.

And here again as we talked about the queuing, we need to have separate the requests and response channels so that we basically can have the end to end workflow.

Và ở đây một lần nữa như chúng ta đã nói về việc xếp hàng, chúng ta cần tách biệt các kênh yêu cầu và phản hồi để chúng ta có thể có quy trình làm việc đầu cuối.

Here it can be an optimized L2 header, it can be etherne or it can be a SUE header.

Ở đây nó có thể là tiêu đề L2 được tối ưu hóa, nó có thể là Ethernet hoặc nó có thể là tiêu đề SUE.

Then at the link layer it basically needs to have end to end reliability.

Sau đó, ở lớp liên kết, nó về cơ bản cần có độ tin cậy đầu cuối.

So we basically need to at least support the LLR capability within the link layer so that we can at least have link to link protected.

Vì vậy, chúng ta về cơ bản cần ít nhất hỗ trợ khả năng LLR trong lớp liên kết để chúng ta có thể ít nhất có liên kết được bảo vệ.

The reason is it only corrects bit errors but not end to end reliability.

Lý do là nó chỉ sửa lỗi bit chứ không phải độ tin cậy đầu cuối.

Then defies common across Ethernet and ul.

Sau đó, định nghĩa chung trên Ethernet và UL.

And on the receive side we basically have a parsing logic that can parse the packet and then it needs to unpack and basically write the packets into the memory.

Và ở phía nhận, chúng ta về cơ bản có logic phân tích cú pháp có thể phân tích gói tin và sau đó nó cần giải nén và về cơ bản ghi các gói tin vào bộ nhớ.

Đối với khung UL, nó trông đơn giản hơn.

The reason it is simpler is that okay, it doesn't have the packing logic, it doesn't have the scheduling logic.

Lý do nó đơn giản hơn là vì, nó không có logic đóng gói, nó không có logic lập lịch.

All this stuff is to some extent incorporated in the DLNDL layer because DL inherently has separate channels for requests and responses.

Tất cả những thứ này ở một mức độ nào đó được tích hợp trong lớp DL/UL vì DL vốn dĩ có các kênh riêng biệt cho yêu cầu và phản hồi.

So here, the biggest takeaway from this here is the logic is simplified here because the interfaces are much more similar because the NOC already has an AXI kind of interface or a load store kind of interface which ties very well with the UPLI interface here.

Vì vậy, ở đây, điểm quan trọng nhất rút ra từ đây là logic được đơn giản hóa ở đây vì các giao diện tương tự nhau hơn nhiều vì NOC đã có giao diện kiểu AXI hoặc giao diện kiểu load store, vốn liên kết rất tốt với giao diện UPLI ở đây.

The amount of logic what we have and the area saving what we can have is significant because of this.

Lượng logic chúng ta có và việc tiết kiệm diện tích có thể đạt được là rất đáng kể vì điều này.

And now we go with the rocky workload here.

Và bây giờ chúng ta chuyển sang workload rocky ở đây.

Like we have a simplified rocky workload.

Giống như chúng ta có một workload rocky được đơn giản hóa.

Basically talking about the control path which is not performance critical here.

Về cơ bản là nói về đường điều khiển, vốn không quan trọng về hiệu suất ở đây.

The connection, the memory registration and the key exchanges can happen at a very slow rate.

Kết nối, đăng ký bộ nhớ và trao đổi khóa có thể diễn ra với tốc độ rất chậm.

From the core operations point of view, we only need to support RDMA write and write with immediate.

Từ góc độ các hoạt động cốt lõi, chúng ta chỉ cần hỗ trợ RDMA write và write with immediate.

The reason for that is okay, all the transactions are bulk transfers and we only wanted to do transfers by load balancing the large payload.

Lý do là vì, tất cả các giao dịch là truyền dữ liệu hàng loạt và chúng ta chỉ muốn thực hiện truyền dữ liệu bằng cách cân bằng tải cho payload lớn.

And what is not required is the send and receive operations.

Và những gì không cần thiết là các thao tác gửi và nhận.

So from the feature set point of view, multipathing is very important because large IO needs to be load balanced across all the paths.

Vì vậy, từ góc độ bộ tính năng, multipathing rất quan trọng vì các IO lớn cần được cân bằng tải trên tất cả các đường dẫn.

So all the packets need to be sprayed across all the paths which are available.

Vì vậy, tất cả các gói tin cần được phân tán trên tất cả các đường dẫn có sẵn.

Vì vậy, điều đó rất quan trọng.

Việc gửi không theo thứ tự là rất quan trọng.

When I say out of order delivery it means every packet needs to have an address so that it can be placed in the destination GPU as and when the packet arrives without waiting for reorder or any other complex logic.

Khi tôi nói gửi không theo thứ tự, điều đó có nghĩa là mỗi gói tin cần có một địa chỉ để có thể được đặt vào GPU đích ngay khi gói tin đến mà không cần chờ sắp xếp lại hoặc bất kỳ logic phức tạp nào khác.

From the congestion point of view we need to have selective acks and nacks.

Từ góc độ tắc nghẽn, chúng ta cần có các gói tin ack và nack có chọn lọc.

Các gói tin ack có chọn lọc về cơ bản là.

The packets are basically written into the memory.

Các gói tin về cơ bản được ghi vào bộ nhớ.

They can be ACK back and NACS is for any of the congestion related issues when a packet is dropped or then we can send an AC so that the end to end reliability will resend the packet and from the completion point of View we can do a RDMA write with immediate so that completion can be sent to the destination accelerator.

Chúng có thể được ACK lại và NACS là dành cho bất kỳ vấn đề nào liên quan đến tắc nghẽn khi một gói tin bị mất hoặc sau đó chúng ta có thể gửi một AC để độ tin cậy đầu cuối sẽ gửi lại gói tin và từ góc độ hoàn thành, chúng ta có thể thực hiện RDMA write v

So from the rocky semantics point of view, the biggest thing is the load balancing.

Vì vậy, từ góc độ rocky semantics, điều quan trọng nhất là load balancing.

As we talked about, a large I O now needs to be partitioned across multiple DMA engines within the networking tile.

Như chúng ta đã nói, một IO lớn giờ đây cần được phân chia trên nhiều DMA engine trong networking tile.

And depending on the I O size, the the partition of these jobs across the networking tiles can be chunky if at all.

Và tùy thuộc vào kích thước IO, việc phân chia các tác vụ này trên các networking tile có thể rất lớn nếu có.

It's a small transfer that needs to be done, then the load balancing is not efficient across the networking tiles.

Đây là một lượt truyền nhỏ cần thực hiện, khi đó việc cân bằng tải sẽ không hiệu quả trên các tile mạng.

And here most of the ROCKY engines are a pull model.

Và ở đây hầu hết các engine ROCKY là mô hình kéo.

When I say pull model, usually the transactions, the DMA thread is sitting in the networking tile wherein it needs to pull the data from the host memory or the GPU memory and then it needs to reorder the transactions and form a packet and send it over the interface.

Khi tôi nói mô hình kéo, thông thường các giao dịch, luồng DMA sẽ nằm trong tile mạng, nơi nó cần kéo dữ liệu từ bộ nhớ host hoặc bộ nhớ GPU, sau đó nó cần sắp xếp lại các giao dịch và tạo thành một gói tin rồi gửi qua giao diện.

Here from the rail optimization point of view, like the bandwidth across these rails may not be completely load balanced to the extent of what memory semantics can achieve.

Ở đây từ góc độ tối ưu hóa rail, băng thông trên các rail này có thể không được cân bằng tải hoàn toàn đến mức mà ngữ nghĩa bộ nhớ có thể đạt được.

Because here the IO chunking can be little bit more grad like little more chunkier.

Bởi vì ở đây việc chia nhỏ IO có thể hơi nhiều hơn, hơi nhiều hơn.

And for the ACK generation again we have the same issue.

Và đối với việc tạo ACK, chúng ta lại gặp vấn đề tương tự.

When we are writing the packet at the receiving side to write into the memory, it needs to wait for all the acks of the memories which memory transactions sent on the NOC for the acks to come back to generate the ack for the packet.

Khi chúng ta ghi gói tin ở phía nhận vào bộ nhớ, nó cần chờ tất cả các ACK của bộ nhớ mà các giao dịch bộ nhớ đã gửi trên NOC để các ACK quay trở lại để tạo ACK cho gói tin.

And from the resiliency point of view, again as we talked about, is a hierarchical kind of a load balancing IO chunk is basically partitioned to multiple smaller chunks within the networking tile.

Và từ góc độ khả năng phục hồi, một lần nữa như chúng ta đã nói, là một loại cân bằng tải phân cấp, khối IO về cơ bản được phân chia thành nhiều khối nhỏ hơn trong tile mạng.

And if at all a link is lost within a networking tile, then the load balancing across the networking tiles needs to be a little bit adjusted and that gets a little bit more complicated.

Và nếu có bất kỳ liên kết nào bị mất trong một tile mạng, thì việc cân bằng tải trên các tile mạng cần được điều chỉnh một chút và điều đó trở nên phức tạp hơn một chút.

Going over the simple again, the XPU kind of a framework here is the same thing what we talked about before, we have a DM engine here which is kind of reading the transactions from the memory and then sending it out.

Quay lại cái đơn giản, khung XPU ở đây cũng giống như những gì chúng ta đã nói trước đó, chúng ta có một engine DM ở đây, nó đọc các giao dịch từ bộ nhớ rồi gửi ra ngoài.

And we have the queuing and scheduling logic and most of the logic can be similar down the road here I talked about having Ethernet IP and AIB header, but

Và chúng ta có logic xếp hàng và lập lịch, và hầu hết logic có thể tương tự, như tôi đã nói về việc có Ethernet IP và AIB header, nhưng

it can be a SU optimized header too here which can reduce the load.

nó cũng có thể là một header được tối ưu hóa cho SU ở đây, giúp giảm tải.

Okay, from the workflow comparison point of view, like I'll just walk through that quickly, we went over that.

Được rồi, từ góc độ so sánh quy trình làm việc, tôi sẽ đi nhanh qua đó, chúng ta đã xem xét nó.

Like load balancing, it can be very efficient for UAL and for rocky it can be a little bit chunkier for the switch latency can be the same across all it will be the 200-300Ns the write responses are very efficient for UL and for Rocky they can be a little bit more delayed because of the ACK accumulation.

Giống như load balancing, nó có thể rất hiệu quả cho UAL và đối với rocky, nó có thể hơi cồng kềnh hơn vì độ trễ chuyển mạch có thể giống nhau trên tất cả, nó sẽ là 200-300Ns, phản hồi ghi rất hiệu quả cho UL và đối với Rocky, chúng có thể bị chậm hơn một

And the bandwidth utilization is very good for UL from the functionality comparison.

Và việc sử dụng băng thông rất tốt cho UL từ góc độ so sánh chức năng.

Again, here is the same thing what we talked about before.

Một lần nữa, ở đây cũng giống như những gì chúng ta đã nói trước đó.

The dmitradius pull and push and the packing logic is there for UL over Ethernet, which potentially can add some latency.

Logic kéo và đẩy dmitradius và logic đóng gói có sẵn cho UL over Ethernet, điều này có thể làm tăng thêm độ trễ.

And for channel based scheduling for ual, as we talked about, the requests and responses have separate channels.

Và đối với lập lịch dựa trên kênh cho UAL, như chúng ta đã nói, các yêu cầu và phản hồi có các kênh riêng biệt.

But for Ethernet we need to separate them out to separate queues from the attributes.

Nhưng đối với Ethernet, chúng ta cần tách chúng ra thành các hàng đợi riêng biệt từ các thuộc tính.

Đánh giá hiệu suất của các công nghệ kết nối cho tính toán AI quy mô lớn UAL so với UALoE SU (Performance Evaluation of Interconnect Technologies for AI Scale Up Computing UAL vs UALoE SU)

Subtitles ListPlay Video

Đánh giá hiệu suất của các công nghệ kết nối cho tính toán AI quy mô lớn UAL so với UALoE SU (Performance Evaluation of Interconnect Technologies for AI Scale Up Computing UAL vs UALoE SU)

assume

critical

multiple

basically