Name: AIスケールアップ・コンピューティングのための相互接続技術の性能評価 UAL vs 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: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

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

今日はスケールアップのインターコネクトについてお話しします。

関係詞節（制限と非制限）

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.

この数日間、多くの基調講演やプレゼンテーションで、スケールアップにおけるインターコネクトの重要性について耳にしてきました。

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.

ここでは、UALとEthernetという2つのテクノロジーについて、そしてUALをSueとRockyで実現する3つのアプローチについてお話しします。私はSri Vengarisna、こちらは同僚のSrinivas Gangamです。

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

まず、その2つのアプローチを見てみましょう。

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.

UALは、ロードストアやアトミックといったメモリトランザクションに基づいています。一方、Ethernetは、Ethernet上のUAL、つまりスケールアップEthernetがあり、これらは最適化されたイーサネットヘッダーでカプセル化されたメモリトランザクションです。

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.

最近も聞かれたように、メモリトランザクションは複数のトランザクションを1つのパケットにまとめることができ、IPGとイーサネットヘッダーのオーバーヘッドを償却できます。

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

RDMAトランスポートは、IP、Ethernet、IP、IBヘッダーの完全なヘッダースタックを持っています。

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

この区別は、後ほど示すパフォーマンス結果を見ていく上で非常に重要です。

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

まず、スケールアップネットワーキングの主な利点を見ていきましょう。最初のものはロードバランシングです。

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

ロードバランシングと言うと、ロードバランシングは非常に細かい粒度で行うことができます。

Basically we can do load balancing at 256 bytes.

基本的に256バイトでロードバランシングが可能です。

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

コンピュートから読み取られたすべてのメモリトランザクションは、すべてのレールにロードバランシングできます。

So the Rails all can be optimized for high bandwidth.

したがって、レールはすべて高帯域幅のために最適化できます。

The second one is the latency characteristics for UAL.

2つ目はUALのレイテンシ特性です。

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

見ると、DL Flitは常に640バイトです。

したがって、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.

しかし、イーサネットについては、前のプレゼンテーションでも聞いたように、レイテンシはパケットサイズや、特定のパケット内にいくつのメモリトランザクションを詰め込んでいるかによって変動する可能性があります。

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

そして、メモリセマンティクスでは、私たちが持つことができる最大の利点の1つは、プッシュモデルにできることです。

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.

プッシュモデルと言うとき、コンピュートが完了したら、データをコンピュートタイルからネットワーキングタイルに直接プッシュでき、SOCで見られるようなRTT遅延のノックインを基本的に発生させません。コンピュートタイルで開始されたすべてのトランザクションは、順不同で完了できます。

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.

順不同で完了するということは、すべてのトランザクションがレール間でロードバランシングされ、これらのトランザクションはすべて最大帯域幅を使用して完了でき、その後で完了できます。

So we can get the maximum utilization of the bandwidth.

これにより、帯域幅の利用率を最大化できます。

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.

実装の観点から、この実装に関する多くの選択肢は、スケールアップスイッチに依存します。ネットワークをどこに展開するかによって異なります。たとえば、スイッチがパケット/秒を制限なしで処理できる場合、アクセラレータに持てるパッキングロジックは非常に効率的になります。

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

パケット内に1つのメモリトランザクションのみをパッキングできます。

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

しかし、それも、トランザクションのオーバーヘッド、つまりイーサネットヘッダーがあるため、固有の帯域幅のペナルティを追加します。

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

そして、QSの動作については、トラフィッククラスの数、特にロスなしトラフィッククラスに依存します。

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

これらのトラフィッククラスはイーサネットで必要です。なぜなら、イーサネットでは異なるリクエストとレスポンスチャネルを分離する必要があるからです。

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

しかし、ULでは、EPLIレイヤーで既にリクエストとレスポンスチャネルが分離されています。

So it can get better performance without any QAS properties.

そのため、QASプロパティなしでより良いパフォーマンスを得ることができます。

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

しかし、イーサネットでは、エンドツーエンドのワークロードのために、キューを個別に用意し、適切にスケジューリングする必要があります。

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

これらの実装の選択はすべて、レイテンシと帯域幅に直接影響します。

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

ネットワークで観察できるのは、これは典型的なシンプルなフレームワークです。

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

表示しているものは、複数のバリエーションを見てきました。

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

ここでは、左側にコンピュートタイルがあります。

Right hand side we have a networking tile.

右側にはネットワーキングタイルがあります。

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

そして、ネットワーキングタイル内では、TXとRXがスイッチに接続されています。

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

そして、ここでのスイッチは、市販のイーサネットスイッチのいずれでも構いません。

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

そして、ペイロードを転送したいという経験から、基本的にすべてのネットワーキングタイル間でロードバランシングを行う必要があります。

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

そして、先ほども言いましたが、ロードバランシングは256バイトでロードバランシングできるため、非常に効率的に行うことができます。

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

そして、イーサネットタイルにトランザクションが到着すると、まずパッキングロジックに渡されます。

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

パッキングロジックについてお話しすると、これは複数のメモリトランザクションをイーサネットパケット内にパックしようとしています。

そして、これはワークコンサービング（作業節約）が可能です。

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

しかし、同時にワークコンサービングでありながらパックしないと、帯域幅に影響が出てしまいます。

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

しかし、もしパックしすぎると、レイテンシが追加されてしまいます。

So that's kind of the drawback of packing.

それがパッキングの欠点と言えます。

Then it goes to the queuing and scheduling logic.

次に、キューイングとスケジューリングロジックに渡されます。

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.

ここでも、キューイングについてお話ししたように、エンドツーエンドのワークフローを確保するために、リクエストとレスポンスのチャネルを分離する必要があります。

次はヘッダーのカプセル化です。

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

ここでは、最適化されたL2ヘッダー、イーサネット、またはSUEヘッダーになります。

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

次に、リンク層ではエンドツーエンドの信頼性が必要になります。

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.

リンク層内でLLR機能を少なくともサポートする必要があり、リンク間の保護が可能になります。

FECだけではここでは十分ではありません。

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

なぜなら、ビットエラーのみを訂正し、エンドツーエンドの信頼性には対応しないからです。

Then defies common across Ethernet and ul.

次に、Ethernetと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.

受信側では、パケットを解析できる解析ロジックがあり、パケットをアンパックしてメモリに書き込む必要があります。

ULフレームワークはよりシンプルに見えます。

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

シンプルな理由は、パッキングロジックやスケジューリングロジックがないことです。

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

これらの機能は、DLがリクエストとレスポンスのチャネルを分離しているため、ある程度DLNDL層に組み込まれています。

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.

ここでの最大のポイントは、インターフェースがより類似しているため、ロジックが簡略化されていることです。NOCにはすでにAXIやload storeのようなインターフェースがあり、これはUPLIインターフェースと非常によく連携します。

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

これによって、ロジックの量と面積の節約が大幅に実現できます。

And now we go with the rocky workload here.

そして、ここではロッキーワークロードを使用します。

Like we have a simplified rocky workload.

シンプルなロッキーワークロードがあるようなものです。

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

基本的に、ここではパフォーマンスがクリティカルではないコントロールパスについて話しています。

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

接続、メモリ登録、キー交換は非常にゆっくりとしたペースで行うことができます。

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

コアオペレーションの観点からは、RDMAライトとイミディエイト付きライトのみをサポートする必要があります。

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.

その理由は、すべてのトランザクションがバルクトランスファーであり、大きなペイロードをロードバランシングしてトランスファーを行いたかったからです。

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

そして、必要ないのは送受信オペレーションです。

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

したがって、機能セットの観点からは、マルチパスは非常に重要です。なぜなら、大きなIOはすべてのパスにロードバランシングする必要があるからです。

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

そのため、すべてのパケットは利用可能なすべてのパスにスプレーする必要があります。

アウトオブオーダーデリバリーが重要です。

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.

アウトオブオーダーデリバリーとは、すべてのパケットがアドレスを持つ必要があり、再注文やその他の複雑なロジックを待つことなく、パケットが到着したときに宛先のGPUに配置できることを意味します。

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

輻輳の観点からは、選択的ACKとNACKが必要です。

The packets are basically written into the memory.

パケットは基本的にメモリに書き込まれます。

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.

ACKバックでき、NACKはパケットがドロップされた場合の輻輳関連の問題用で、ACKを送信してエンドツーエンドの信頼性でパケットを再送信でき、完了の観点からは、RDMAライトとイミディエイトを使用して完了を宛先アクセラレータに送信できます。

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

Rockyセマンティクスの観点からは、最大のことはロードバランシングです。

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

話したように、大きなIOはネットワークタイルの複数のDMAエンジンにパーティション化する必要があります。

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

そして、IOサイズによっては、ネットワークタイル全体でのこれらのジョブのパーティションは、もしあれば、チャンキーになる可能性があります。

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

これは、ロードバランシングがネットワークタイル全体で効率的ではない、小さな転送です。

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

そして、ここのROCKYエンジンのほとんどはプルモデルです。

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.

プルモデルと言うと、通常、トランザクション、DMAスレッドはネットワークタイルにあり、ホストメモリまたはGPUメモリからデータをプルし、トランザクションを並べ替えてパケットを形成し、インターフェース経由で送信する必要があります。

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.

ここのレール最適化の観点からすると、これらのレールの帯域幅は、メモリセマンティクスが達成できる範囲で完全にロードバランシングされているとは限りません。

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

なぜなら、ここのIOチャンキングは、より段階的で、よりチャンキーになる可能性があるからです。

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

そして、ACK生成についても、同じ問題があります。

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.

受信側でパケットをメモリに書き込む際、NOCで送信されたメモリトランザクションのACKがすべて戻ってくるのを待ってから、パケットのACKを生成する必要があります。

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.

そして、レジリエンスの観点からは、前述のように、階層的なロードバランシングIOチャンクは、ネットワークタイル内で複数の小さなチャンクにパーティション化されています。

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.

そして、ネットワークタイル内でリンクが失われた場合、ネットワークタイル間のロードバランシングを少し調整する必要があり、それが少し複雑になります。

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.

単純なものに戻ると、ここのXPUのようなフレームワークは、以前話したことと同じで、メモリからトランザクションを読み取って送信するDMAエンジンがあります。

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

そして、キューイングとスケジューリングのロジックがあり、ここでも多くのロジックが同様に機能します。イーサネットIPとAIBヘッダーについて話しましたが、

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

SU最適化ヘッダーにすることもでき、これにより負荷を軽減できます。

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

ワークフロー比較の観点から、簡単に説明します。

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.

ロードバランシングのように、UALには非常に効率的で、ロッキーには少しチャンキーになる可能性があり、スイッチのレイテンシはすべて同じで200〜300Nsになり、書き込み応答はUALには非常に効率的ですが、ロッキーではACKの蓄積により少し遅れる可能性があります。

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

機能比較から、帯域幅利用率はUALにとって非常に良好です。

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

ここでも、以前話したことと同じです。

ロードバランシングは効率的です。

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

dmitradiusのプルとプッシュ、およびパッキングロジックは、イーサネット上のUALのために存在し、潜在的にレイテンシを追加する可能性があります。

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

そして、UALのチャネルベースのスケジューリングでは、話したように、リクエストとレスポンスは個別のチャネルを持っています。

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

しかし、イーサネットでは、属性から個別のキューに分離する必要があります。

字幕リスト動画再生

AIスケールアップ・コンピューティングのための相互接続技術の性能評価 UAL vs UALoE SU (Performance Evaluation of Interconnect Technologies for AI Scale Up Computing UAL vs UALoE SU)

assume

critical

multiple

basically