Name: Tăng tốc quy trình giới thiệu sản phẩm mới phần cứng AI: Xác thực cụm GPU và mạng (Accelerating AI Hardware NPI Cluster less Validation of GPUs and Networking)
Uploaded: 2025-11-15T00:37:16.000Z
Duration: 19 min 15 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ảm ơn các bạn đã đến với buổi nói chuyện của chúng tôi.

We might be keeping you between lunch, so hopefully we don't drown on too much.

Chúng tôi có thể sẽ giữ chân các bạn trước giờ ăn trưa, nên hy vọng chúng tôi sẽ không nói quá nhiều.

So we're going to Talk about validating GPUs and NICs or GPUs and networking or AI accelerators, depending on what you want to call them.

Vì vậy, chúng ta sẽ nói về việc xác thực GPUs và NICs hoặc GPUs và mạng hoặc AI accelerators, tùy thuộc vào cách bạn muốn gọi chúng.

XPUs, Broadcom, like CUs, without clusters, without.

XPUs, Broadcom, giống như CUs, không có cụm, không có.

Which is really hard because fundamentally you need a cluster.

Điều này thực sự khó khăn vì về cơ bản bạn cần một cụm.

So this work is on behalf of what we've done at Meta, myself and a few of my colleagues.

Vì vậy, công việc này là thay mặt cho những gì chúng tôi đã làm tại Meta, tôi và một vài đồng nghiệp của tôi.

Arvind couldn't make it today, but there's multiple people behind us.

Arvind hôm nay không đến được, nhưng có nhiều người đứng sau chúng tôi.

Có hàng chục người đứng sau anh ấy.

So I wanna thank everyone who contributed to this.

Vì vậy, tôi muốn cảm ơn tất cả những người đã đóng góp vào điều này.

So this is somewhat of a continuation from the talk we gave in 2023.

Vì vậy, đây là sự tiếp nối của bài nói chuyện chúng tôi đã thực hiện vào năm 2023.

We talked about evalu all to all collectives on our Zion systems.

Chúng tôi đã nói về việc đánh giá tất cả các collective all-to-all trên Zion systems của chúng tôi.

It was much harder than we thought when we started.

Nó khó hơn nhiều so với chúng tôi nghĩ khi bắt đầu.

It started with, okay, the performance isn't anywhere near roofline.

Nó bắt đầu với, ồ, hiệu suất không hề gần với roofline.

Chúng ta sẽ làm gì về điều đó?

Ultimately, we dug into the collective state machine, how the network was configured.

Cuối cùng, chúng tôi đã đi sâu vào collective state machine, cách mạng được cấu hình.

We built a complex test bed with multiple racks.

Chúng tôi đã xây dựng một khu vực thử nghiệm phức tạp với nhiều rack.

In the end, you know, we had to drill into packet captures because we're getting switches from the signal or signals from our switches that indicated that the buffers are filling up.

Cuối cùng, bạn biết đấy, chúng tôi đã phải xem xét kỹ các packet captures vì chúng tôi nhận được tín hiệu từ các switches cho thấy các buffers đang đầy lên.

Incast was due to microbursts and ultimately it was very complicated.

Incast là do microbursts và cuối cùng nó rất phức tạp.

So one of the call to actions there is how do we do it better?

Vì vậy, một trong những call to actions ở đó là làm thế nào để chúng ta làm tốt hơn?

In that test bed, we were limited by a few racks and it was very hard to measure.

Trong khu vực thử nghiệm đó, chúng tôi bị giới hạn bởi một vài rack và rất khó để đo lường.

How can we go about this a different way?

Làm thế nào chúng ta có thể tiếp cận điều này theo một cách khác?

So that's kind of the subject of this talk.

Vì vậy, đó là chủ đề của bài nói chuyện này.

So there has to be a better way than we did last time.

Vì vậy, phải có một cách tốt hơn so với những gì chúng ta đã làm lần trước.

Vì vậy, chúng tôi đã làm việc đó nội bộ.

We collaborated with keysight and this is what we came up with.

Chúng tôi đã hợp tác với Keysight và đây là những gì chúng tôi đã nghĩ ra.

Like, normally in a collective's test, you have a bunch of nodes.

Bình thường trong bài kiểm tra collective, bạn có một loạt các node.

By definition, the job of the collectives is to exchange data between them.

Theo định nghĩa, nhiệm vụ của collective là trao đổi dữ liệu giữa chúng.

But there's no reason why you have to simultaneously test every NIC and accelerator.

Nhưng không có lý do gì mà bạn phải kiểm tra đồng thời mọi NIC và accelerator.

So the idea here is to focus on testing one NIC and one accelerator and mock everything else.

Vì vậy, ý tưởng ở đây là tập trung vào việc kiểm tra một NIC và một accelerator, còn lại thì giả lập hết.

So imagine magical device that can behave just like your switch or just be like your rack.

Hãy tưởng tượng một thiết bị kỳ diệu có thể hoạt động giống hệt như switch của bạn hoặc giống như rack của bạn.

Think of it as a hardware collectives emulator, or a traffic generator, whatever you want to call it.

Hãy coi nó như một hardware collectives emulator, hoặc một traffic generator, tùy bạn gọi nó là gì.

And instead of doing a cluster level test, you reduce your like sort of cluster under test to system under test, or even device under test.

Và thay vì thực hiện kiểm tra cấp cluster, bạn thu nhỏ cluster đang kiểm tra của mình thành hệ thống đang kiểm tra, hoặc thậm chí là thiết bị đang kiểm tra.

And then there's some questions, like there's no perfect Answer to.

Và rồi có một vài câu hỏi, giống như không có câu trả lời hoàn hảo nào cho nó.

It's like when I'm testing a NIC in an accelerator, do I also test the network, like the switch?

Giống như khi tôi kiểm tra một NIC trong một accelerator, tôi có nên kiểm tra cả mạng, như là switch không?

The signaling from the switch is fundamentally part of it.

Tín hiệu từ switch về cơ bản là một phần của nó.

Vì vậy, chúng tôi xem xét nó theo cả hai cách.

We're gonna both present data on a system under test with just mocking different endpoints and just a device under test, just the accelerator and the NIC by itself.

Chúng tôi sẽ trình bày dữ liệu trên một hệ thống đang kiểm tra với việc giả lập các điểm cuối khác nhau và chỉ một thiết bị đang kiểm tra, chỉ riêng bộ tăng tốc và NIC.

And there's one other thing I wanna talk about.

Và có một điều nữa tôi muốn nói.

One of the complexities that we talked about last time is how the collective communications library works.

Một trong những điểm phức tạp mà chúng ta đã thảo luận lần trước là cách thư viện truyền thông tập thể hoạt động.

So, so we went over the collective state machine, how buffers are exchanged, and

Vì vậy, chúng tôi đã xem qua collective state machine, cách các bộ đệm được trao đổi, và

that was actually a contributing factor to some of what we were seeing with InCast.

điều đó thực sự đã góp phần vào một số vấn đề chúng tôi thấy với InCast.

So in these results, we replaced the vendor CCL with our own.

Vì vậy, trong những kết quả này, chúng tôi đã thay thế CCL của nhà cung cấp bằng CCL của riêng mình.

We have our own collective communications library, at least for all to all.

Chúng tôi có thư viện truyền thông tập thể của riêng mình, ít nhất là cho all to all.

So we wanted to reduce one factor from the equation.

Vì vậy, chúng tôi muốn giảm bớt một yếu tố khỏi phương trình.

We're calling this one arm, you know, AI validation or one ARM testing, whatever you want to call it.

Chúng tôi gọi cái này là one arm, bạn biết đấy, AI validation hoặc one ARM testing, tùy bạn muốn gọi thế nào.

The idea is you mock, like I said before, everything but the device under test.

Ý tưởng là bạn giả lập, như tôi đã nói trước đây, mọi thứ trừ thiết bị đang được kiểm tra.

And you might think, how is this possible?

Và bạn có thể nghĩ, làm sao điều này có thể xảy ra?

Like, how can I make my device running a complex collective algorithm or an AI workload talk to something else?

Kiểu như, làm sao tôi có thể làm cho thiết bị của mình chạy một thuật toán tập thể phức tạp hoặc một workload AI giao tiếp với thứ khác?

It's actually simpler than you think when you get into it.

Thực ra nó đơn giản hơn bạn nghĩ khi bạn đi sâu vào nó.

The nice thing about collectives is, is the whole everyone participating in that collective is aware of what everyone else is doing.

Điều hay về collectives là, toàn bộ mọi người tham gia vào collective đó đều nhận thức được những gì mọi người khác đang làm.

So like node A is sending to node B, node B knows it's receiving from node A and so on and so forth.

Vì vậy, ví dụ node A đang gửi cho node B, node B biết nó đang nhận từ node A và cứ thế tiếp diễn.

So you kind of know at the beginning of a test, you know what all the patterns are.

Vì vậy, bạn có thể biết vào đầu một bài kiểm tra, bạn biết tất cả các mẫu là gì.

So all you have to do to make this work is your mocks need to do what the device under test is expecting.

Vì vậy, tất cả những gì bạn phải làm để làm cho việc này hoạt động là các bản mô phỏng của bạn cần làm những gì thiết bị đang được kiểm tra mong đợi.

Basically it's got to pass the duck test.

Về cơ bản, nó phải vượt qua bài kiểm tra con vịt.

Like from the accelerator under test point of view, if it looks like a duck, quacks like a duck, it must be a duck.

Giống như từ góc nhìn của bộ tăng tốc đang được kiểm tra, nếu nó trông giống con vịt, kêu như con vịt, thì nó phải là con vịt.

So in this case, keysight is a very expensive.

Vì vậy, trong trường hợp này, Keysight rất đắt.

So Ashutosh will talk more about how exactly this works and some of the details of it, but

Vì vậy, Ashutosh sẽ nói thêm về cách chính xác điều này hoạt động và một số chi tiết của nó, nhưng

think of it as a collective emulator that can take input from our collective communications library and execute it in a similar fashion.

hãy coi nó như một trình giả lập collective có thể nhận đầu vào từ thư viện giao tiếp collective của chúng tôi và thực thi nó theo cách tương tự.

Okay, so now we're going to talk about some applications of this.

Được rồi, bây giờ chúng ta sẽ nói về một số ứng dụng của điều này.

Application we're going to talk about is measuring collective completion time.

Ứng dụng chúng ta sẽ nói đến là đo thời gian hoàn thành collective.

So one thing you commonly do in NPI is you'll measure the performance and you know, just functionality.

Vì vậy, một điều bạn thường làm trong NPI là đo hiệu suất và chức năng.

Sometimes just getting to performance is hard of.

Đôi khi việc đạt được hiệu suất là rất khó.

Of all to all collectives or some other collective with different rank sizes.

Các collective all-to-all hoặc các collective khác với kích thước rank khác nhau.

In this example here, we used a fixed message size.

Trong ví dụ này, chúng tôi đã sử dụng kích thước tin nhắn cố định.

So then the all to all size changes to correspond to that and we evaluate it.

Vì vậy, kích thước all-to-all thay đổi để tương ứng với điều đó và chúng tôi đánh giá nó.

I can't read our first data point here, but you know, anywhere from.

Tôi không đọc được điểm dữ liệu đầu tiên của chúng tôi ở đây, nhưng bạn biết đấy, bất kỳ đâu.

So with that I'm going to hand it off to Ashutosh, who's going to go into more details of the results and interesting things we've discovered.

Với đó, tôi sẽ chuyển lời cho Ashutosh, người sẽ đi sâu hơn vào chi tiết kết quả và những điều thú vị chúng tôi đã khám phá.

So we have the accelerator and the neck surrounded by the mocks.

Vì vậy, chúng ta có bộ tăng tốc và NIC được bao quanh bởi các mock.

So we usually care about two kinds of flows, right?

Vì vậy, chúng ta thường quan tâm đến hai loại luồng, đúng không?

Ones that originate from the NIC and land on the mocks, which is NIC TX in red.

Những luồng bắt nguồn từ NIC và đi vào các mock, đó là NIC TX màu đỏ.

And the ones that originate from the mocks and land on the nic, which is NIC rx.

Và những luồng bắt nguồn từ các mock và đi vào NIC, đó là NIC rx.

This of course flows between the mocks themselves, but that's not conjugation for now.

Tất nhiên, điều này chảy giữa các mock với nhau, nhưng hiện tại không phải là sự liên hợp.

You see a green line which represents the ideal trend as we go from 8 ranks all the way to 24 ranks, right?

Bạn thấy một đường màu xanh lá cây đại diện cho xu hướng lý tưởng khi chúng ta đi từ 8 rank đến 24 rank, đúng không?

Chúng ta hãy xem xét đường màu xanh lam 1.

Nick RX we see as we go from 8 ranks to 24 ranks, we're able to achieve 90 to 97% of the ideal line rate.

Nick RX chúng ta thấy khi đi từ 8 rank lên 24 rank, chúng ta đạt được 90 đến 97% tốc độ đường truyền lý tưởng.

And the observation for NICK TX trend here is we see that there are some flows that are actually outliers, which is they unexpectedly achieve or exercise higher bandwidth rate than we expect them to.

Và quan sát về xu hướng NICK TX ở đây là chúng ta thấy có một số luồng thực sự là ngoại lệ, đó là chúng đạt hoặc sử dụng tốc độ băng thông cao hơn mong đợi.

Chúng ta làm điều này như thế nào?

So let's first look at the observation with NIC rx, which is the blue line, right, where we were able to achieve 90 to 97% of the ideal rate.

Vậy chúng ta hãy xem xét trước quan sát với NIC rx, đó là đường màu xanh lam, đúng không, nơi chúng ta đạt được 90 đến 97% tốc độ lý tưởng.

Let's pick up the use case for 24 ranks, where we have one accelerator and NIC surrounded by 23 physical mocks.

Hãy xem xét trường hợp sử dụng cho 24 rank, nơi chúng ta có một accelerator và NIC được bao quanh bởi 23 mock vật lý.

Tất cả chúng đều có tốc độ cổng 400 gig.

Now, since this is all to all, each mock should be transmitting at 17.4 Gbps, to the NIC, right?

Bây giờ, vì đây là all to all, mỗi mock sẽ truyền với tốc độ 17,4 Gbps, đến NIC, đúng không?

And based on the trend we saw before this, we're achieving around 97% of the rate, which is 17.0 Gbps.

Và dựa trên xu hướng chúng ta thấy trước đó, chúng ta đạt khoảng 97% tốc độ, tức là 17,0 Gbps.

Tăng tốc quy trình giới thiệu sản phẩm mới phần cứng AI: Xác thực cụm GPU và mạng (Accelerating AI Hardware NPI Cluster less Validation of GPUs and Networking)