Name: AIハードウェアNPIクラスタのGPUとネットワーキングの検証を迅速化 (Accelerating AI Hardware NPI Cluster less Validation of GPUs and Networking)
Uploaded: 2025-11-15T00:37:16.000Z
Duration: 19 min 15 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

私たちのトークにご参加いただきありがとうございます。

様態の副詞

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

ランチを挟んでのお話になりますので、あまり長々と話しすぎないようにしたいと思っています。

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.

今回は、GPUやNIC、あるいはGPUとネットワーク、あるいはAIアクセラレーターと呼ばれるものを検証することについてお話しします。

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

XPUs、Broadcom、CUs、クラスターなし、といったものです。

Which is really hard because fundamentally you need a cluster.

これは非常に難しいのですが、根本的にクラスターが必要だからです。

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

この研究は、私と数人の同僚がMetaで行ったことについてです。

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

Arvindは今日来られませんでしたが、他にも多くの人が関わっています。

Ashutoshさんがkeysightからお話しします。

彼の後ろにも何十人もの人がいます。

So I wanna thank everyone who contributed to this.

ご協力いただいた皆様に感謝いたします。

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

これは2023年にお話しした内容の、ある種の続きとなります。

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

Zion systemsでのeval all to all collectivesについてお話ししました。

It was much harder than we thought when we started.

始めた当初は、想像以上に大変でした。

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

パフォーマンスがrooflineに全く届かない、というところから始まりました。

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

最終的には、collective state machineやネットワークの設定方法を深く掘り下げました。

We built a complex test bed with multiple racks.

複数のラックを備えた複雑なテストベッドを構築しました。

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.

最終的に、buffersがいっぱいになっていることを示すswitchesからの信号を調べるために、packet capturesを詳しく調べる必要がありました。

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

incast は microbursts が原因で、最終的には非常に複雑でした。

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

そこで、call to actions の一つは、どうすればもっとうまくできるか？ということです。

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

そのテストベッドでは、数個のラックに制限され、測定が非常に困難でした。

How can we go about this a different way?

どうすれば別の方法でこれを進めることができるでしょうか？

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

それが、このトークの主題です。

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

ですから、前回やった方法よりも良い方法があるはずです。

そこで、社内で取り組みました。

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

keysight と協力し、その結果がこれです。

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

通常、コレクティブのテストでは、たくさんのノードがあります。

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

定義上、コレクティブの仕事はそれらの間でデータを交換することです。

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

しかし、すべてのNICとアクセラレータを同時にテストする必要はありません。

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

ですから、ここでは1つのNICと1つのアクセラレータのテストに焦点を当て、他はすべてモックするという考え方です。

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

ですから、スイッチのように振る舞ったり、ラックのようになれる魔法のようなデバイスを想像してみてください。

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

ハードウェアのコレクティブエミュレーター、あるいはトラフィックジェネレーターとでも呼んでください。

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.

そして、クラスターレベルのテストを行う代わりに、テスト対象のクラスターをテスト対象システム、あるいはテスト対象デバイスにまで減らします。

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

そして、完璧な答えがないような質問もあります。

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

これは、NICとアクセラレータをテストしているとき、ネットワーク、例えばスイッチもテストすべきか、というようなことです。

The signaling from the switch is fundamentally part of it.

スイッチからのシグナリングは、根本的にその一部です。

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.

テスト対象システムで、さまざまなエンドポイントをモックするだけで、テスト対象デバイス、つまりアクセラレーターとNIC単体でデータを提示します。

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

そして、もう一つお話ししたいことがあります。

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

前回お話しした複雑さの一つは、コレクティブコミュニケーションライブラリがどのように機能するかということです。

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

それで、コレクティブステートマシン、バッファーがどのように交換されるかを説明しました。

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

そして、それがInCastで見られたことの一部に貢献した要因でした。

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

そこで、これらの結果では、ベンダーのCCLを私たち自身のものに置き換えました。

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

少なくとも、all-to-allについては、私たち自身のコレクティブコミュニケーションライブラリを持っています。

So we wanted to reduce one factor from the equation.

それで、方程式から一つの要因を減らしたかったのです。

それで、これを何と呼んでいるのでしょうか？

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

これは、AIバリデーション、あるいはワンARMテストと呼んでいます。お好きなように呼んでください。

ワンARM何か、ということですね？

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

アイデアは、先ほども言ったように、テスト対象のデバイス以外のすべてをモックすることです。

And you might think, how is this possible?

そして、どうやってそれが可能なのか、と思われるかもしれません。

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

例えば、複雑なコレクティブアルゴリズムやAIワークロードを実行しているデバイスを、どうやって他のものと通信させることができるのでしょうか？

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

実際には、やってみると考えているよりも簡単です。

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

コレクティブの良いところは、そのコレクティブに参加している全員が、他の全員が何をしているかを知っているということです。

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

例えば、ノードAがノードBに送信していて、ノードBはノードAから受信していることを知っている、といった具合です。

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

ですから、テストの開始時に、すべてのパターンがどうなっているかを知ることができるのです。

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

ですから、これを機能させるために必要なのは、モックがテスト対象のデバイスが期待していることを行うことです。

Basically it's got to pass the duck test.

基本的に、アヒルのテストに合格する必要があります。

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

テスト対象のアクセラレータの観点から見ると、アヒルのように見え、アヒルのように鳴くなら、それはアヒルに違いありません。

So in this case, keysight is a very expensive.

ですから、この場合、keysight は非常に高価です。

そんなことを言ってはいけませんね。

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

ですから、Ashutosh がこれがどのように機能するか、そしてその詳細についてさらに説明しますが、

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

これは、コレクティブ通信ライブラリからの入力を受け取り、同様の方法で実行できるコレクティブエミュレータと考えてください。

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

さて、このアプリケーションについていくつか話しましょう。

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

このアプリケーションは、コレクティブ通信の完了時間を測定するものです。

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

NPIでよく行うことの一つに、パフォーマンスと機能性を測定することがあります。

Sometimes just getting to performance is hard of.

パフォーマンスを出すのが難しい場合もあります。

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

全ノード間通信や、異なるランクサイズの他のコレクティブ通信などです。

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

ここでの例では、固定のメッセージサイズを使用しました。

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

そうすると、全ノード間通信のサイズがそれに合わせて変更され、評価されます。

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

最初のデータポイントは読めませんが、8ノードから。

8ノード、24ノードといった具合です。

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.

では、ここからはアシュトッシュさんにバトンタッチして、結果や興味深い発見について詳しくお話しいただきます。

ありがとうございます、マットさん。

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

アクセラレーターとネックがモックに囲まれている状態です。

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

通常、私たちは2種類のフローを気にしますよね？

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

NICから始まってモックに着地するフロー、これは赤色のNIC TXです。

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

そして、モックから始まってNICに着地するフロー、これはNIC RXです。

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

もちろん、これはモック間を流れるものですが、今は考慮しません。

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

緑の線が見えますが、これは8ランクから24ランクへと進む理想的な傾向を表しています。

ここで2つの観察点があります。

まずは青い線を見てみましょう。

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.

NIC RXで、8ランクから24ランクに進むにつれて、理想的なラインレートの90～97%を達成できていることがわかります。

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.

そして、NIC TXのトレンドの観察結果ですが、ここでは外れ値となっているフローがいくつか見られます。これは、予想よりも高い帯域幅レートを達成または利用しているということです。

どうやってこれを実現しているのでしょうか？

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.

では、まずNIC RXでの観察、つまり青い線を見てみましょう。理想的なレートの90～97%を達成できています。

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

24ランクのユースケースを取り上げてみましょう。1つのアクセラレータとNICが23個の物理モックに囲まれています。

すべて400ギガポートスピードです。

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

さて、これはオール・トゥ・オールなので、各モックはNICに対して17.4 Gbpsで送信する必要があります。

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

そして、これ以前に見たトレンドに基づくと、レートの約97%、つまり17.0 Gbpsを達成しています。