Name: AIファブリックのソースルーティング (Source Routing for AI Fabrics)
Uploaded: 2025-10-25T00:04:14.000Z
Duration: 15 min 41 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

なるほど、これは分かりにくいですね。

程度の副詞

デビッドさん、とても素晴らしいスピーカーです。

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

MarvellでデータセンターソフトウェアのSonic Insideを担当しているプロダクトマネージャーです。

I am also Director of Software Product Management at Marvell.

私もMarvellでソフトウェアプロダクトマネジメントディレクターをしています。

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

今日はAIクラスターにおけるフロー管理の代替アプローチをご紹介します。

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

代替アプローチと言っても、より良いという意味ではなく、単に違うアプローチだということを明確にしておきたいと思います。

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

Davidがすでに触れたかもしれませんが、AIトレーニングトラフィックの背景、ファブリックについて簡単に紹介します。

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

特にコンジェスチョンが発生した場合のジョブ完了時間への影響。

Other latency dynamics within the fabric.

ファブリック内の他のレイテンシダイナミクス。

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

JCTを改善するための既存のアプローチ、そして私たちの提案と行動喚起についてです。

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

それでは、パートナーに引き継ぎます。

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.

さて、提案するソリューションに入る前に、さまざまなAIモデルの基盤を説明したいと思います。

We have different network architectures required.

それぞれ異なるネットワークアーキテクチャが必要です。

このスライドをご覧ください。

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.

古い世代のものは、CPUやGPU、PCIeリンクすべてが必要な小規模なAIトレーニングを、1つのシャーシに収めることができたようなものでした。

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

そして次の世代では、モデルが拡大し、より大きなクラスターが必要になりました。

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

そこで、専用のAIファブリックを備えた、中規模および大規模のAIトレーニングファブリックへと移行しました。

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

これはAIトレーニング専用であり、AIワークロードのみが実行されるよう常に保証されていました。

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

そのため、専用ネットワークや、さらに独自のネットワークを持つこともできました。

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.

しかし、そこから、2023年の多くの部分が生成AIとなり、ますます多くのAIアプリケーションが市場に登場し、より多くの人々がアプリケーションにAIを統合していく中で、私たちが目にしているのは、

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.

あらゆるアプリケーション、あらゆるソフトウェアアプリケーション、クラウドかエンタープライズかを問わず、AIをソフトウェア全体に統合しようとしているため、マルチテナントファブリックが必要になるということです。

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

つまり、AIのためだけに完全に専用のネットワークを持つことはできないということです。

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

そこでネットワークのマルチテナントという側面が登場します。

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

さまざまな種類のアプリケーション、さまざまな種類のAIワークロードに対応しなければなりません。

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

そしてAIの中でも、各AIアプリケーションの要件は異なります。

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?

ですから、これらすべてに対応する必要があること、そして各社が専用のAIネットワークを構築するほどの帯域幅を持っていないことを確認する必要があります。なぜなら、彼らのLLMは、通常私たちがChatGPTのAIで見かけるほど巨大ではないかもしれないからです。

So that is where multi tenant networks becomes more important.

そこで、マルチテナントネットワークがより重要になってきます。

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.

そして、マルチテナントネットワークがより重要になるにつれて、イーサネットがデフォルトになるのを見ています。なぜなら、さまざまな種類のトラフィック、さまざまな種類のアプリケーションの要件があるからです。

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

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?

ですから、AIについて考えるとき、AIワークロードがどのように配置され、互いにどのようにやり取りするかを考えると、サーバーに来る前でさえ、複数のステップがあります。

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

AIのオーケストレーション全体、ジョブのオーケストレーションを計画している専用サーバーがあります。

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?

サーバー上にマッパーがいて、「このワークロードを処理する必要があり、CPUやGPUの容量はこれくらいある。どこに配置できるか、そして結果をすべて得るためにどうやり取りすればよいか？」と考えています。

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

そのための重要な要素の1つが、ジョブ完了時間です。

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

可能な限り最速でジョブを完了させるにはどうすればよいでしょうか？

ですから、これらすべてのために、実際には

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

マッパーはすでにすべてのワークロードをマッピングしており、通常はデータセンター内のラックやサーバーに完全にマッピングされています。

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.

そのため、全体像を把握しており、理想的な状態、つまりどこに配置したいか、そしてさまざまなインフラストラクチャ製品にどのようにジョブを配置できるかを知ることができます。

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

それを考えると、トレーニングは複数の段階を経て行われます。

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.

初期のテストパラメータがあり、学習モデルにすべての入力を提供し、中間結果を得て、それらを複数回反復処理して最終的なトレーニング済みモデルに到達させます。

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

これらすべてにおいて、多くの東西トラフィックが発生し、

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

これらの東西トラフィックが計画されていないと、一部のリソースでコンジェスチョンが発生しがちです。

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.

各トレーニングステップから得られるすべての結果が、これらの結果をすべて集中させるいずれかのリソースに入力されるためです。

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

そこでコンジェスチョンが発生し、これらのコンジェスチョンを緩和し、事前に計画する必要があります。

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

これらのコンジェスチョン問題をすでに解決するための複数の方法があります。

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

パケットスプレー方式、VOQ方式、テレメトリ適応方式などがあります。

All of these are great in different scenarios.

これらはそれぞれ異なるシナリオで優れています。

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.

ですから、今日提案しようとしているもう一つの代替案は、すでにマッパーがあり、ネットワークとすべてのリソースをより高いレベルで監視している人がいて、ジョブがどこに配置され、これらのジョブがどのように相互作用するかを正確に把握しているということです。

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.

ネットワークとリソースをより高いレベルで見るのが、代替アプローチとして良いかもしれない、と考えています。

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

ネットワーク、サーバー、GPU、XPUレベルからだけ考えるのではなく、

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.

そして、これらの各モジュールとどのように相互作用するかをすでに知っているなら、フローを事前に設定する方が良いかもしれません。

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.

提案全体についてさらに詳しく説明するために、Kishoreに引き継ぎます。彼はこの件についてさらに詳しく説明してくれます。

Pratyaさん、ありがとうございます。

So like Pratya mentioned, this is an alternative approach.

Pratyaが言ったように、これは代替アプローチです。

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.

ワークロードの一部を受け取り、インフラストラクチャ内のネットワークの特定のコンピューティング要素にマッピングするマッピング機能があります。

So our approach is to kind of piggyback on that.

ですので、私たちのこのアプローチは、それに便乗するような形です。

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.

コントローラーまたはマッパーが存在すると仮定すると、ファブリック内のトラフィックフローを、ある地点から別の地点へと事前にプログラムする方法があるはずです。

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

そのアプローチは、フローパスルーティングまたはソースルーティングと呼んでいるものです。

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

ワークロードを開始する前に、ファブリックを事前にプログラムして、フローにパスを割り当てるという考え方です。

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

その後、コントローラーを使用してファブリックを準備し、すべてのルートをインストールして、初期ステップとしてファブリックにパスをインストールします。

これにはいくつかの利点があります。

Your controller can load balance your flows using source routes.

コントローラーは、ソースルートを使用してフローのロードバランシングを行うことができます。

Assuming it has some information about your network.

ネットワークに関する情報を持っていると仮定します。

テレメトリを使用して調整することもできます。

We'll talk about that a little bit later.

それについては後ほど少しお話しします。

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

ファブリックで定義されたファブリックノード、つまりリーフスパインレイヤーのトップは、実際にはルックアップを行う必要はありません。

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

そして、その方法についても説明します。

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.

宛先ポートは、SRV6で見られるものと同様に、古いソースルートのように、事前にパケットに埋め込むことができます。

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

そして、この提案がSRV6とどう違うのか、後ほど少しお話しします。

And we can eliminate lookup latency in your fabric.

そして、ファブリック内のルックアップレイテンシをなくすことができます。

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

そして、ここでのアイデアは、パケット内の情報を使用して即座に決定を下すことです。

ファブリックノード内のワイヤーのようなものです。

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

では、この新しいパケットフォーマットはどのようなもので、どのように典型的なIPに埋め込まれるのでしょうか？

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

左側には、レイヤー2ヘッダー、IPヘッダー、そして通常のトランスポートプロトコルがあります。

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

UDP、TCP、Rocky、RDMAのいずれであっても、関係ありません。

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.

真ん中には、レイヤー2と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?

なぜここに配置したかというと、MACに新しいハードウェア実装を強制したくないからです。既存のものを活用するだけです。

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

IPもトランスポートも変更しません。

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

実際、スイッチングの意思決定プロセスでは、IPもトランスポートも一切使用しません。

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

右側には、私たちが定義しているヘッダーがあります。

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

ご覧の通り、ホップIDと呼んでいる5つの16ビットフィールドがあります。

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

ホップIDは、デバイス上の物理ポート番号にマッピングされます。

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

したがって、コントローラーは、ファブリックや接続先だけでなく、

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

スイッチ自体と、どの物理ポートがフロントパネルにマッピングされるかについても、詳細な知識を持っている必要があります。

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

ですので、コントローラーにとっては少し手間のかかる作業になりますが、

it's something that we believe is achievable.

実現可能なものだと考えています。

次に、コントロールパイプラインに移りましょう。

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.

この図の左側では、サーバーが2層ファブリックを経由して別のサーバーに接続し、ポイントAからポイントBへトラフィックを送信しているのがわかります。

We have defined roles for each port in this fabric.

このファブリックでは、各ポートに役割を定義しました。

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

1つの役割はアクセスポート、もう1つの役割はファブリックポートです。

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

アクセスポートの責任は、フローのルックアップを実行することです。

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

そして、フローは、ファブリックを定義するあなた次第で、最大で任意のフィールドのセットによって決定できます。

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

現在、ソースポート、sipdip、そしてRockyの場合はQペアソースとQペアデスティネーションを想定しています。

字幕リスト動画再生

AIファブリックのソースルーティング (Source Routing for AI Fabrics)

assume

approach

process

dedicated