期待のネット新技術
「Scale-up Network」はいつ生まれたか？ その特徴とGPUに求められる性能
Scale-up Network（3）
2026年9月1日 06:00
前回、NVLink以外のScale-up Networkの話を紹介すると述べたが、今回はあらためてScale-up Networkとは？ という話から始めたい。
Scale-up Networkという用語がいつ頃定着したのかは定かではないが、2025年に入ると頻繁に使われ始めた。例えば650 GROUPの"Ethernet AI Networking Revenue Surges over 150% Y/Y, Bandwidth over 200% Y/Y in 2024"という記事を見ると、"2024 was the first time we saw scale-up networks escape the server enclosure."などと説明もなしにScale-up Networkという用語が使われている。
ちゃんとしたScale-up Networkの定義を誰が言い始めたのかは不明だが、筆者の調べた限りで言えば2025年のOCP APAC Summit（2025年8月5～6日）でAstera LabsのSharada Yeluri氏が行った"What Matters in Scale-up Fabrics?"は、この定義に対して包括的な解を示した最初の1つではないかと思う。
ラック内のGPUやAIアクセラレーターを高密度で結合する
ではYeluri氏の述べるところの定義は何か？ ということでScale-up Fundamentalの高レベルのまとめが、図01だ。あくまでラック内の配線のみで、ラック間はScale-outになるという定義であり、かつGPUやAIアクセラレータに特化したもので、帯域もScale-outに比べて大幅に高い、とする。
では物理的な実装はどんな感じか？ というのが、次の図02だ。次のスライドでもう少し細かい話が出てくるが、基本はGPU同士なりAI Processor同士の密結合に使う形だ。例えばLLMのある層の処理を行うのに、パラメータ（Weight）が多すぎてローカルメモリに乗りきらないなんて場合に、その層の処理を複数のGPUなりAI Processorに分割して行う形になる。
例えばある層のパラメータが1000万個あったら、それを4つに分割して、4枚のGPUにそれぞれ250万個ずつのパラメータを格納させ、入力された値を処理するわけだ。その際には、4つのGPUで処理が完了するタイミングを同期させた上で、結果を集めるなり別のGPUに送り込むなりするが、Scale-up Networkの一番の目的はこの同期、次いでデータの移動である。
これがこのスライドにある"XPUs exchange partial results from tensor/pipeline or sequence parallel operations"の意味である。こういう方法だから、当然Network経由でのLatencyはそのままアプリケーションに影響を及ぼす（ので、省Latencyが強く求められるわけだ）。
通信の方法はLoad/Store Semanticsである。要するにGPUなりAI Processorはあるアドレスにデータを書き込むと、それがそのまま勝手にScale-up Network経由で相手に送られる（反対に、相手からすると勝手にあるMemory Addressにデータが届いている）仕組みだ。
おそらくは各GPUのメモリアドレスはSystem全体でユニークになるように設定（ただしCacheableか？ というとそうではなく、あくまで自分のローカルメモリのみCacheableになっている:これはUMAかNUMAかという話に帰着する）されている形だろう。個々のGPUから見ると、それがLocalか（Scale-up Network経由の）Remoteかは判断できない（Addressが違うだけ）という形になる。
なので、GPUから見ると、特定のAddressをアクセスしようとすると（その先がScale-up Networkになっているので）猛烈に反応が遅いということになり、これはGPU内部のThreadが、その反応が戻ってくるまで待機することになる。これは推論の性能に結構なインパクトが発生することは間違いない。
次がNetworkのつなぎ方。これはNVLinkなども同じなのだが、Switchを経由するという意味ではEthernetなどと変わらない。ただ、そのつなぎ方の冗長度が、Ethernetなどより遥かに大きいのが特徴となる（図03）。
静的なルーティングと高い冗長性
それと、もう1つ特徴的なのが、そのSwitchでは動的なSwitchingは基本的に行わない（少なくともPacket単位での制御は行わない）という話である。図03にも"Compiler scheduling relies on stable and deterministic communication latencies."とあるが、要するにあるLLMのNetworkをシステム全体にロードする際に「どのGPUのポートとどのGPUのポートを、どのSwitchで介在して通信させるか」を静的に決めてしまうわけだ。
一度決めると、ポートが故障して通信できなくなったとか、別のLLMを稼働させるのでNetworkそのものを入れ替えるとか、そういうことがない限りSwitchの動作はずーっと同じものになる。当然Switchの中では行先を判断する必要がないし、もっと言えば理論的にはそもそもPacketの中に送信元／送信先アドレスを含む必要もなければ、Packetの目的（同期なのかデータ転送なのか制御なのか、といったもの）も不要である。これはそれだけPacketの転送時間を減らせることにもつながり、最終的にはLatencyの削減にもつながる形だ。
この際に重要なのは、どれだけ冗長経路が確保できるかという話になる。Switchが煩雑に行先を切り替えられるのなら冗長経路は不要なわけだが、ここまで説明したようにSwitchは最初にどうRoutingするかが固定される形で動作するので、煩雑にこれを切り替えるのはオーバーヘッドが大きくなるだけである。
1枚のGPUなりAIアクセラレータなりが常に別の1枚とだけ接続する、というケースであればそもそも冗長構成にしなくても足りそうなものだが、実際には内部を複数に分割してそれぞれ別々の処理を行わせる、ということが現実に起き得ており、この際には異なる相手と通信の必要があったりする。図03のケースで言えば、8枚のXPUは自分以外の4枚のXPUとの間の通信が可能なように設計されているわけだ。
求められる伝達保障をどう実現するか？
もう1つ重要なのが、確実な伝達保証である（図04）。これはもちろんデータが欠落したりしないということも必要だが、加えてデータの取りこぼしが発生しないことが求められる。
要するに、Flow Controlを確実に行う必要があるという話だ。これを担保するために、Credit-base Flow Controlが搭載される。これ、元はPCIeで実装された技術であるが、要するに各XPUにはあらかじめCreditが用意される。これは言ってみれば受信キューの深さである。
例えばCreditが4つある、という場合は4つのパケットまで受信できることが示されている。SenderがReceiverにデータを送ろうとした場合は、次のような仕組みで行われるわけだ。
- あらかじめReceiverは自身の持つCreditの数をSenderに送っておく（これは最初だけ。なのでSenderはReceiverの持つCreditを記憶しておく必要がある）。
- Senderは送信時、記憶しているCreditの数を1減らしてからデータをReceiverに送り出す。
- Receiverはデータを受け取り、処理が終わったらCreditを1、Senderに送り返す。
- Senderは受け取ったCreditを自身の記憶している領域に反映させる。
Creditを使うことで、相手が確実に受信できることが担保されているので、受信の取りこぼしがなくなるわけだ。このメカニズムはハードウェアで実装され、アプリケーションからはVC（Virtual Channel）という仮想的なポート経由で送受信を行う形を取っている。
PCIeの場合、このCreditの処理はDLLP（Data Link Layer Packet）で実装が行われているが、Scale-upの場合にこれをどこで実装するか、はインプリメント次第になっている（通常はLink Layerに相当する部分だとは思うが）。
もう1つの問題がエラー訂正である。もともとEthernetでは必ずしもデータが正しく送れることは保証されていない（だからUDPのようなプロトコルだと伝達保証がない）。なのでTCPで伝達保証を掛けているわけだが、これをやると当然プロトコルオーバーヘッドが凄く大きくなる。といってもEthernetのFECであっても伝達保証は困難である。
ちょっと古い話だが、100G EthernetでBERを10E-13と10E-14のどちらにするかという議論の話を以前紹介した（1.0E10年のMTTFPAを維持、1.0E-14のBER Targetには高コストなFECが必要に【光Ethernetの歴史と発展】）が、FECでも、方式によって処理のLatencyが53.6ns～1μsecまで変動するなんて話があった（前掲の記事中の図参照）。現状ではDSPの性能が上がってこの辺もう少し異なる数値になっていると思うが、それでもオーバーヘッドが大きいのは間違いない。
で、図04の中に"FEC and link-level retries are must"とあるが、このLink-level retriesというのはFLIT（Flow Control Unit）というLink Layerの再送機構で、これもPCIe（正確にはPCIe 6.0）で導入された仕組みである。
FLITによる確実性とLatencyとのトレードオフ
PCIeも6.0になって64GT/secまで信号速度が引きあがったことで、BERが無視できないほど大きくなった。かといってここに強力なFECを入れるとLatencyが大幅に増える（当時のPCI-SIGの試算では100nsオーダー）。そこで発想を切り替え、物理層では軽量なFEC（BERが10E-6程度）を利用するに留める（これに要するLatencyは～10nsオーダー）。そしてエラーが発生した場合のみ、Link Layerで再送メカニズム（FLIT）を利用してエラーのあったデータを送り直すという仕組みだ。
FLITによる再送はやはり100ns程度のLatencyが掛かるのだが、「常時100nsのLatencyがかかるのと、たまに100nsのLatencyがかかるのと、どちらがマシか？」という判断でこれが導入された形だ。Scale-up Networkでも、物理層であまり強力なFECを利用するとやはりLatencyが洒落にならないので程々のFECに留めておき、伝達保証はFLITでやるというのが現実的な方針になっている。
ちなみにNVLinkは筆者の知る限り、少なくともNVLink 5まではFLITを使っていない（※1）。そもそもNVLinkの実装は、信号速度を引き上げるのではなくLinkの本数を増やす方向でこれまでは実装されていたからだ。例えばNVLink 5なら信号速度は50Gbaud PAM-4で1レーン、片方あたり100Gbps。これを4本束ねて400Gbpsで1本のNVLinkが構成されていた。信号速度が50Gbaudだとまだそれほど強力なFECが必要なく、FLITを使わなくてもカバーできたからだと思われる。ただNVLink 6ではついにFLITが採用されたらしい。
話をScale-up Networkに戻すと、こうした特徴を持つNetworkに求められるFabricは？ という要件をまとめたのが図05になる。概ね「ごもっとも」な内容ばかりだ。
Memory Orderingが要件に入っているのは、パケットの再構成とかをやっていたらそれだけでオーバーヘッドが激増するからだ。TCPではないので、パケットサイズは256Bytesの倍数に固定であり、これを一発で転送することが求められるというわけだ。
Yeluri氏はこのあと実際にいくつかのScale-outの規格の仕様比較などを行っているが、仕様というか要件定義はこの辺りまでである。従来のEthernetとは色々異なる要件が求められている、ということが分かるかと思う。
※1：「少なくともNVLink 5まではFLITを使っていない」に関して補足。正確に言えば、FLITという用語そのものはPascal世代のNVLink 1.0で既に利用されている（図06）。だが、これはどうも意味が違うというか、少なくともPCIeで実装された再送メカニズムのことではなく、128bitの塊のことをFLITと称しているように思われる。
