Name: Định tuyến nguồn cho mạng AI (Source Routing for AI Fabrics)
Uploaded: 2025-10-25T00:04:14.000Z
Duration: 15 min 41 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...

Được rồi, nên việc này không dễ để theo dõi.

David, một diễn giả rất đáng kính.

I'm a Product Manager at Marvell, handling data center software Sonic Inside.

Tôi là Quản lý Sản phẩm tại Marvell, phụ trách phần mềm trung tâm dữ liệu Sonic Inside.

I am also Director of Software Product Management at Marvell.

Tôi cũng là Giám đốc Quản lý Sản phẩm Phần mềm tại Marvell.

So today we're going to present an alternate approach to managing flows in an AI cluster.

Hôm nay chúng tôi sẽ trình bày một cách tiếp cận thay thế để quản lý các luồng trong một cụm AI.

I want to be very clear when we say alternate, we're not saying better, we're just saying different.

Tôi muốn nói rõ khi chúng tôi nói "thay thế", chúng tôi không nói là "tốt hơn", chúng tôi chỉ nói là "khác biệt".

Vậy chúng ta cứ bỏ qua phần này nhé.

So we'll give you a brief introduction to the AI training traffic background, the fabrics stuff that David has probably already mentioned.

Vậy chúng tôi sẽ giới thiệu ngắn gọn về bối cảnh luồng huấn luyện AI, những thứ về fabric mà David có lẽ đã đề cập.

The impact of job completion time, especially when it comes to congestion.

Tác động của thời gian hoàn thành tác vụ, đặc biệt là khi xảy ra tắc nghẽn.

Other latency dynamics within the fabric.

Các động lực độ trễ khác trong fabric.

Some existing approaches to improve JCT as well as our proposal and our call to action.

Một số phương pháp hiện có để cải thiện JCT cũng như đề xuất và lời kêu gọi hành động của chúng tôi.

So with that I'll hand it over to my partner here.

Vậy với đó, tôi xin chuyển lời cho đối tác của tôi ở đây.

Okay, so before we go into the solution of what we are proposing, we wanted to kind of set a base of the different AI models.

Được rồi, vậy trước khi đi vào giải pháp mà chúng tôi đề xuất, chúng tôi muốn đặt nền tảng về các mô hình AI khác nhau.

We have different network architectures required.

Chúng ta có các kiến trúc mạng khác nhau cần thiết.

So there were like typically the old generation ones where we had small AI trainings which could have been accommodated in just a single chassis with all the CPUs and the GPUs required with all the PCIe links.

Vậy có những thế hệ cũ, nơi chúng ta có các buổi huấn luyện AI nhỏ có thể được chứa trong một khung máy duy nhất với tất cả CPU và GPU cần thiết cùng tất cả các liên kết PCIe.

And then we have the next generation where our models kind of expanded, we needed bigger clusters.

Và rồi chúng ta có thế hệ tiếp theo, nơi các mô hình của chúng ta mở rộng ra, chúng ta cần các cụm lớn hơn.

So there we went into kind of the medium and large AI training fabrics where you had dedicated AI fabrics.

Vì vậy, ở đó chúng ta đi vào các kiến trúc huấn luyện AI cỡ trung và lớn, nơi bạn có các kiến trúc chuyên dụng.

It is only dedicated for AI training and it has always made sure that you have only the AI workloads running on them.

Nó chỉ dành riêng cho huấn luyện AI và luôn đảm bảo rằng chỉ có các tác vụ AI chạy trên đó.

So it could have dedicated networks and it could have even just proprietary networks.

Vì vậy, nó có thể có các mạng chuyên dụng và thậm chí có thể chỉ có các mạng độc quyền.

But what we are seeing from there, going ahead with a lot of 2023 becoming genai, more and more AI applications coming into the market and more and more people integrating AI into their applications.

Nhưng điều chúng ta thấy từ đó, tiến về phía trước với rất nhiều năm 2023 trở thành genai, ngày càng có nhiều ứng dụng AI xuất hiện trên thị trường và ngày càng có nhiều người tích hợp AI vào các ứng dụng của họ.

We see that we need a multi tenant fabric because every application today, every software application, whether it is cloud or enterprise, they are looking at integrating AI into their whole software suit.

Chúng ta thấy rằng chúng ta cần một kiến trúc đa người dùng vì mọi ứng dụng ngày nay, mọi ứng dụng phần mềm, cho dù đó là đám mây hay doanh nghiệp, họ đều đang xem xét tích hợp AI vào toàn bộ bộ phần mềm của họ.

So what that means is we can't have a completely dedicated network just for AI.

Vì vậy, điều đó có nghĩa là chúng ta không thể có một mạng hoàn toàn chuyên dụng chỉ dành cho AI.

That is where the multi tenant aspect of the network comes in.

Đó là nơi khía cạnh đa người dùng của mạng phát huy tác dụng.

We have to cater for different kinds of applications, different kinds of AI workloads.

Chúng ta phải phục vụ cho các loại ứng dụng khác nhau, các loại tác vụ AI khác nhau.

And even like even in the AI, the requirement for each AI applications are different.

Và ngay cả trong AI, yêu cầu đối với mỗi ứng dụng AI cũng khác nhau.

So what we need to make sure is that we cater for all of these and every company doesn't have the bandwidth to put dedicated AI networks because their LLMs might not be as huge as typically what we have seen in a chatgpt AI, right?

Vì vậy, điều chúng ta cần đảm bảo là chúng ta đáp ứng tất cả những điều này và mọi công ty đều không có đủ khả năng để triển khai mạng AI chuyên dụng vì các LLM của họ có thể không lớn như những gì chúng ta thường thấy ở AI ChatGPT, đúng không?

So that is where multi tenant networks becomes more important.

Đó là lý do tại sao mạng đa người dùng trở nên quan trọng hơn.

And with multi tenant networks becoming more important, what we are seeing is Ethernet becomes a default because you have different kinds of traffic, different kinds of requirements of applications.

Và khi mạng đa người dùng trở nên quan trọng hơn, điều chúng ta thấy là Ethernet trở thành lựa chọn mặc định vì bạn có các loại lưu lượng truy cập khác nhau, các loại yêu cầu ứng dụng khác nhau.

We see that Ethernet becomes more adaptable to these kind of networks instead of having a dedicated and proprietary solution into the AI networks.

Chúng ta thấy rằng Ethernet trở nên linh hoạt hơn với các loại mạng này thay vì có một giải pháp chuyên dụng và độc quyền cho mạng AI.

So when we think about AI, if you think how the AI workloads are placed, how they're interacting with each other, there are multiple steps goes even before it comes onto the server, right?

Vì vậy, khi chúng ta nghĩ về AI, nếu bạn nghĩ về cách các tác vụ AI được đặt, cách chúng tương tác với nhau, có nhiều bước diễn ra ngay cả trước khi nó đến máy chủ, đúng không?

So there are dedicated servers who are planning the whole AI orchestration, the work job orchestration.

Vì vậy, có các máy chủ chuyên dụng đang lên kế hoạch cho toàn bộ việc điều phối AI, điều phối công việc.

There is a mapper sitting on a server thinking, okay, I have this much workload which I have to work on and I have this much capacity on my CPUs and my GPUs, so where can I place them and how do I interact to get all the results?

Có một bộ ánh xạ trên máy chủ suy nghĩ, được rồi, tôi có khối lượng công việc này mà tôi phải xử lý và tôi có dung lượng này trên CPU và GPU của mình, vậy tôi có thể đặt chúng ở đâu và làm thế nào để tương tác để nhận tất cả kết quả?

One of the key factors for that is job completion time.

Một trong những yếu tố quan trọng cho điều đó là thời gian hoàn thành công việc.

How can I get the job completed at the fastest time possible?

Làm thế nào tôi có thể hoàn thành công việc trong thời gian nhanh nhất có thể?

Vì vậy, đối với tất cả những điều này, thực tế

the mapper has already mapped all the workloads, usually on your data center, very specific to the racks and the servers, everything mapped.

trình ánh xạ đã ánh xạ tất cả các khối lượng công việc, thường là trên trung tâm dữ liệu của bạn, rất cụ thể cho các giá đỡ và máy chủ, mọi thứ đều được ánh xạ.

So it has a complete view and it will make sure that it knows the ideal state, where it wants to be and how it can place its jobs on different infrastructure products.

Vì vậy, nó có một cái nhìn toàn diện và nó sẽ đảm bảo rằng nó biết trạng thái lý tưởng, nơi nó muốn ở và cách nó có thể đặt các tác vụ của mình trên các sản phẩm cơ sở hạ tầng khác nhau.

So if you think of that, the training goes in multiple stages.

Vì vậy, nếu bạn nghĩ về điều đó, quá trình huấn luyện đi qua nhiều giai đoạn.

So we have the initial testing parameters, we provide all the inputs into the learning model, we get intermediate results, we work on them multiple iterations to kind of get into the final trained model.

Vì vậy, chúng ta có các tham số kiểm tra ban đầu, chúng ta cung cấp tất cả các đầu vào vào mô hình học, chúng ta nhận được kết quả trung gian, chúng ta làm việc với chúng nhiều lần lặp để đi vào mô hình được huấn luyện cuối cùng.

All of this has a lot of east west traffic, and

Tất cả những điều này có rất nhiều lưu lượng east west, và

all of these east west traffic, if it is not planned, tends to have congestion on some of the resources.

tất cả các lưu lượng east west này, nếu không được lên kế hoạch, có xu hướng gây tắc nghẽn trên một số tài nguyên.

Because every result you are getting out of each training step is going into one or the other resource which is concentrating all these results together.

Bởi vì mọi kết quả bạn nhận được từ mỗi bước huấn luyện đều đi vào một hoặc tài nguyên khác, nơi tập trung tất cả các kết quả này lại với nhau.

What happens there is we hit the congestion and we have to mitigate these congestion and plan ahead.

Điều xảy ra ở đó là chúng ta gặp tắc nghẽn và chúng ta phải giảm thiểu các tắc nghẽn này và lên kế hoạch trước.

So there are multiple ways which is kind of addressing all these congestion issues already.

Vì vậy, có nhiều cách để giải quyết tất cả các vấn đề tắc nghẽn này.

So it is like we have the packet spraying method, we have the VOQ method, we have the telemetry adaptive method.

Vì vậy, nó giống như chúng ta có phương pháp phân tán gói tin, chúng ta có phương pháp VOQ, chúng ta có phương pháp thích ứng đo lường từ xa.

All of these are great in different scenarios.

Tất cả những điều này đều tuyệt vời trong các tình huống khác nhau.

So one of the other alternative we are trying to propose today is because you have a mapper already, you have someone who is already looking into your network and all of your resources from a higher level and it knows exactly where the job is going to be placed and how these jobs are going to interact.

Vì vậy, một trong những phương án thay thế khác mà chúng tôi đang cố gắng đề xuất hôm nay là bởi vì bạn đã có một bộ ánh xạ, bạn có người đang xem xét mạng lưới và tất cả các tài nguyên của bạn từ cấp độ cao hơn và nó biết chính xác công việc sẽ được đặt 

We are saying that it might be better or it is a alternative approach to look at the network and the resources from a higher level.

Chúng tôi đang nói rằng có thể tốt hơn hoặc đó là một cách tiếp cận thay thế để xem xét mạng lưới và các tài nguyên từ cấp độ cao hơn.

Don't just think from a network or a server or a GPU or XPU level, but

Đừng chỉ suy nghĩ từ cấp độ mạng, máy chủ, GPU hoặc XPU, mà

And if you already know how you're interacting with each of these modules, then maybe it is better to configure upfront what the flows are.

Và nếu bạn đã biết cách bạn tương tác với từng mô-đun này, thì có lẽ tốt hơn là cấu hình trước các luồng dữ liệu.

So to go deeper into the whole proposal itself, I'll hand it over to Kishore who can take you into more details on this.

Vì vậy, để đi sâu hơn vào toàn bộ đề xuất, tôi sẽ chuyển lời cho Kishore, người có thể cung cấp cho bạn thêm chi tiết về điều này.

So like Pratya mentioned, this is an alternative approach.

Vì vậy, như Pratya đã đề cập, đây là một cách tiếp cận thay thế.

Như chúng tôi đã khẳng định trước đó.

There is a mapping function that takes pieces of your workload and puts it maps it to certain compute elements in your network in your infrastructure.

Có một hàm ánh xạ lấy các phần trong quy trình làm việc của bạn và ánh xạ chúng tới các yếu tố tính toán nhất định trong mạng, trong cơ sở hạ tầng của bạn.

So our approach is to kind of piggyback on that.

Vì vậy, cách tiếp cận của chúng tôi là tận dụng điều đó.

So assuming that there is a controller or a mapper, there will be a way for us to pre program the flows, the traffic flows in the fabric from point A to point B.

Vì vậy, giả sử có một bộ điều khiển hoặc bộ ánh xạ, sẽ có cách để chúng tôi lập trình trước các luồng, các luồng lưu lượng trong mạng từ điểm A đến điểm B.

So that approach is something that we're calling flow path routing or source routing.

Vì vậy, cách tiếp cận đó là thứ mà chúng tôi gọi là định tuyến đường đi hoặc định tuyến nguồn.

The idea is to assign the paths to the flows in advance before you actually start your workload pre program your fabric.

Ý tưởng là gán các đường đi cho các luồng trước khi bạn thực sự bắt đầu quy trình làm việc, lập trình trước mạng của bạn.

Then we use the controller to prep the fabric, install all the routes and install the paths into your fabric as an initial step.

Sau đó, chúng tôi sử dụng bộ điều khiển để chuẩn bị mạng, cài đặt tất cả các tuyến đường và cài đặt các đường đi vào mạng của bạn như một bước ban đầu.

Your controller can load balance your flows using source routes.

Bộ điều khiển của bạn có thể cân bằng tải các luồng của bạn bằng cách sử dụng các tuyến nguồn.

Assuming it has some information about your network.

Giả sử nó có một số thông tin về mạng của bạn.

Bạn cũng có thể tinh chỉnh nó bằng cách sử dụng đo từ xa.

We'll talk about that a little bit later.

Chúng ta sẽ nói về điều đó sau một chút.

Your fabric nodes as defined in your fabric as the top or your leaf spine layer do not really need to do a lookup.

Các node fabric của bạn như được định nghĩa trong fabric của bạn ở lớp top hoặc lớp leaf spine thì không thực sự cần tra cứu.

And we'll talk about how we go about that.

Và chúng ta sẽ nói về cách chúng ta thực hiện điều đó.

Your destination ports can be embedded into your packet ahead of time just like any old source route, similar to what you see in SRV6.

Các cổng đích của bạn có thể được nhúng vào gói tin của bạn trước, giống như bất kỳ tuyến nguồn cũ nào, tương tự như những gì bạn thấy trong SRV6.

And we'll talk about the difference what this proposal has versus SRV6 in a little bit.

Và chúng ta sẽ nói về sự khác biệt giữa đề xuất này và SRV6 trong một lát nữa.

And we can eliminate lookup latency in your fabric.

Và chúng ta có thể loại bỏ độ trễ tra cứu trong fabric của bạn.

And the idea here is to use the information in your packet to immediately make the decision.

Và ý tưởng ở đây là sử dụng thông tin trong gói tin của bạn để đưa ra quyết định ngay lập tức.

Giống như một sợi dây trong node fabric của bạn.

So how does this new packet format look like and how is it embedded into a typical IP?

Vậy định dạng gói tin mới này trông như thế nào và nó được nhúng vào IP thông thường như thế nào?

So on the left hand side you have your layer 2 header, your IP header and your usual transport protocol of choice.

Vì vậy, ở phía bên trái bạn có header lớp 2, header IP và giao thức vận chuyển thông thường bạn chọn.

Whether it's udp, tcp, Rocky, rdma, doesn't matter.

Dù là udp, tcp, Rocky, rdma, không quan trọng.

Right in the middle we are introducing a new shim or what we're calling our flow Path routing header in between the layer 2 and IP.

Ngay ở giữa, chúng tôi giới thiệu một lớp shim mới hay còn gọi là header định tuyến flow Path của chúng tôi, nằm giữa lớp 2 và IP.

And the reason why we put it here is we do not want to dictate new hardware implementations on the Mac, just take advantage of what you already have, right?

Và lý do chúng tôi đặt nó ở đây là chúng tôi không muốn áp đặt các triển khai phần cứng mới trên MAC, chỉ tận dụng những gì bạn đã có, đúng không?

And we don't change the ip, we don't change the transport.

Và chúng tôi không thay đổi IP, chúng tôi không thay đổi transport.

In fact, we don't use the IP or the transport at all as a part of the switching decision making.

Trên thực tế, chúng tôi không sử dụng IP hoặc transport chút nào như một phần của quá trình ra quyết định chuyển mạch.

On the right hand side, this is the header that we're defining.

Ở phía bên phải, đây là header mà chúng tôi đang định nghĩa.

As you can see, there are five 16 bits fields which we're calling hop IDs.

Như bạn thấy, có năm trường 16 bit mà chúng tôi gọi là hop ID.

Now your hop ID maps to a physical port number on your device.

Bây giờ, hop ID của bạn sẽ ánh xạ tới một số cổng vật lý trên thiết bị của bạn.

So this implies that your controller has to have intimate knowledge of not just your fabric and what you're connecting to, but

Vì vậy, điều này ngụ ý rằng bộ điều khiển của bạn phải có kiến thức sâu sắc không chỉ về fabric của bạn và những gì bạn đang kết nối, mà còn

it also has to have an intimate knowledge of the actual switch itself and what physical ports map to your front panel.

nó cũng phải có kiến thức sâu sắc về chính switch và các cổng vật lý nào ánh xạ tới bảng điều khiển phía trước của bạn.

So it's a little bit more involved work onto the controller, but

Vì vậy, nó đòi hỏi nhiều công việc hơn một chút cho bộ điều khiển, nhưng

it's something that we believe is achievable.

đó là điều mà chúng tôi tin rằng có thể đạt được.

Chuyển sang đường ống điều khiển.

So on the left hand side in this diagram you'll see a server connecting through a two tier fabric to another server, sending traffic from point A to point B.

Vì vậy, ở phía bên trái trong sơ đồ này, bạn sẽ thấy một máy chủ kết nối qua một fabric hai tầng tới một máy chủ khác, gửi lưu lượng từ điểm A đến điểm B.

We have defined roles for each port in this fabric.

Chúng tôi đã định nghĩa các vai trò cho mỗi cổng trong fabric này.

One role is the access port, the other role is the fabric port.

Một vai trò là cổng truy cập, vai trò còn lại là cổng fabric.

Your access port's responsibility is to perform a lookup of your flow.

Trách nhiệm của cổng truy cập của bạn là thực hiện tra cứu luồng của bạn.

And your flow can be Flow can be determined by an arbitrary set of fields up to you, the one who defines the fabric.

Và luồng của bạn có thể được xác định bởi một tập hợp các trường tùy ý do bạn, người định nghĩa fabric, quyết định.

Right now we're assuming source port, sipdip, maybe Q pair source and Q pair destination in the case of Rocky.

Hiện tại, chúng tôi đang giả định cổng nguồn, sipdip, có thể là cặp nguồn Q và cặp đích Q trong trường hợp của Rocky.

Subtitles ListPlay Video

Định tuyến nguồn cho mạng AI (Source Routing for AI Fabrics)

assume

approach

process

dedicated