This article represents only the author's personal views and is not related to the author's affiliated institution.
TL;DR
Recently, I've seen some articles and had some discussions with GPU and network chip vendors. Many disagreements about Scale-Up have not yet converged. These discussions are heavily influenced by the interests of various companies, and while each opinion seems correct from its own standpoint, the entire system has reached an impasse.
For example, is the principle of "Smart Edge, Dumb Core," often emphasized by the networking engineers, still correct in a Scale-Up scenario? As the person who first pioneered Ethernet Scale-Up globally(NetDAM in 2020), I'd like to elaborate further. Any design choice or trade-off made without considering the microarchitecture of the compute chip and its memory model is inherently flawed.
As for simplifying Ethernet headers, like Broadcom's AFH, back in 2021 when we completed NetDAM development, I had already proposed to a switch chip company to add some UDF (User-Defined Field) capabilities to the MAC field to support LPM (Longest Prefix Match) processing.
Let me state my personal opinion: I am more inclined to agree with link-layer cost amortization solutions like ESUN, but I am less convinced by SUE or other transport-layer solutions.
1. Smart Edge, Dumb Core? Starting with Scale-Out
As a side note, it seems that today's Scale-Out networks have become a loyalty test for the "Smart Edge, Dumb Core" principle. Interestingly, in the Scale-Out context, this creed seems to be abandoned as people discuss end-to-end co-design, PacketSpray, Adaptive Routing, DLB (Dynamic Load Balancing), GLB (Global Load Balancing), and a series of "Smart Core" capabilities. For instance, a certain vendor constantly hypes its 102.4T solution. I looked at their SGLB paper, which was published in a top conference, showing that for All-to-All traffic at 80% link load, the bandwidth utilization was merely 50%...
It feels like their loyalty is not absolute. A true network engineer must face the grim reality of a Dumb Fabric Core!
If we adhere to "Smart Edge, Dumb Core," can we solve all transport congestion and multi-path hash collision problems purely on the end-host NIC, without using any advanced switch features (including INT/PacketSpray), not even ECN/PFC? Furthermore, for long-distance transport, can we achieve full bandwidth utilization across availability zones without needing deeper switch buffers or switch QoS policies?
The answer is yes. If you can't do it, it's just because your algorithm guys need to study more math. We achieved this years ago. A year later, I saw a company that was getting close to the idea and protectively filed a patent in 2024. Now that the patent has been public for 18 months, I still haven't seen these companies produce a usable product... quite disappointing...
Recently, people from several companies have been asking me how to notify the end-host of a switch link failure by adding switch functionality. In truth, if your end-host algorithm is sound, you really don't need it.
On the other hand, we went from changing topologies to Rail-Based deployments to avoid hash collisions, and now with the rise of MoE (Mixture of Experts) models with large expert parallelism (EP), it seems we are back to wrangling with multi-plane CLOS architectures and confronting multi-pathing head-on. This signals that attempts to solve these problems by changing the topology have likely reached their endgame.
For Scale-Out, the trade-offs for adhering to the "Smart Edge, Dumb Core" principle by solving all multi-path load balancing, reliable transport, and congestion control at the end-host are as follows:
- For the end-host NIC chip, for example, an 800Gbps NIC with an integrated PCIe Switch, the surrounding Serdes (e.g., 48x PCIe lanes and 800G Ethernet Serdes) dominate the chip's die area. Adding some "Smart" functionality does not significantly increase the die size.
- For the switch chip, Scale-Out chips typically require a certain depth of buffer. The implementation complexity of a Traffic Manager's MMU with multi-port read/write access is very high. However, considering a deployment of tens of thousands, hundreds of thousands, or even a million GPUs, the switch chip is primarily valued for its higher radix and throughput. For example, a 102.4Tbps switch chip is expected to provide 1024x 112G Serdes or 512x 224G Serdes, and in the future, expand to a 200Tbps switch chip.
Under these two constraints, placing functions like multi-path load balancing, reliable transport, and congestion control on the end-host to build a "Smart Edge, Dumb Core" system is an inevitable choice.
2. Discussing Scale-Up: Dumb Edge, Dumb Core?
Should Scale-Up also adhere to the "Smart Edge, Dumb Core" principle?
2.1 Scale-Up Node Count
First, regarding the scale of Scale-Up, looking at the number of experts in MoE models and the feasible scale for Tensor Parallelism (TP) within model architectures, a Scale-Up size of at most 256 GPU nodes is sufficient. Particularly in inference scenarios, factors like fault domain isolation and the need for elastic deployment based on workload will typically further reduce the deployment scale.
For example, with a 256-accelerators cluster, if a MaaS (Model-as-a-Service) platform expands by 256 accelerators at a time, the newly added super-node might have a load of less than 5%, causing the overall cluster load to be, for instance, below 70%. In this case, if we instead expand incrementally in 32-accelerators units, although the peak performance of eight 32-accelerators super-nodes might only reach 80-90% of a single 256-accelerators super-node, the elastic, on-demand expansion offers greater cost benefits.
On the other hand, super-nodes with thousands of cards are meaningless. To support such massive-scale networking, the switching network would require two layers, introducing more load balancing and reliability problems. A single-layer switch network structure is therefore preferred. Similarly, Broadcom's GM also emphasizes single-layer networking.
Conclusion: Scale-Up node counts of 64 / 128 / 256 accelerators are sufficient.
2.2 Scale-Up Transport from a Chip Perspective
From a chip perspective, the required radix for a Scale-Up switch is determined by the node count. With 224G Serdes interconnects, a switch chip with a radix of 256 would have a capacity of 51.2Tbps, which is sufficient. On the other hand, we need to look at the GPU side. With a Scale-Up bus of 1.8TB/s, the unidirectional bandwidth is 900GB/s, or 7.2Tbps. This means the bandwidth ratio between the endpoint and the switch is approximately 1:7.
We need to make trade-offs in this scenario. Considering the power/thermal issues of the GPU die itself, as well as the die area occupied by Scale-Up logic, would it be better to shift some of the power budget to the switch side? This would also reduce the overall cooling difficulty and make power management easier. At the same time, a simpler endpoint function could free up more die area to further increase compute power. Under this view, it seems we should choose "Dumb Edge, Smart Core."
But how should the Core Switch be handled? How should the chip architecture be designed, and how should the transport layer be constructed?
I feel I wasn't clear enough when I gave advice to Broadcom in early 2024. I just told them they could reference the method proposed in Nvidia's 2023 paper, "FinePack: Transparently Improving the Efficiency of Fine-Grained Transfers in Multi-GPU Systems," which involves packing multiple Load/Store (LD/ST) operations into a single packet.
However, throughout this process, I did not elaborate on how multiple LD/STs should be dispatched across the switch. Consequently, SUE's transport layer did not handle the packing of multiple LD/STs very well.
In fact, this implies another switch chip architecture problem: which buffer architecture to choose for the switch chip. Much of the criticism from the networking community about UALink comes from the fact that UALink requires the switch to disassemble a Data Link (DL) Flit, perform lookups, and forward multiple Transport Layer (TL) Flits. The conventional wisdom is that a switch cannot maintain line-rate forwarding at such high bandwidths as 51.2Tbps/102.4Tbps. In reality, this constraint comes from the switch's microarchitecture. If a Shared Buffer Switch is used, designing the Traffic Manager's MMU to achieve line-rate PPS at 51.2T/102.4T is extremely difficult. However, using a Port-Based Buffer design, especially in the Scale-Up domain with simple Accelerator ID lookups, is very easy. Specifically:
Shared Buffer Switch
This architecture typically stores received packets in a centralized buffer, then extracts the packet header, parses it, performs a table lookup, and instructs the egress port to forward. If the payload needs to be parsed and processed, this buffer requires a higher operational speed because it's an MMU composed of multi-ported SRAM. Multi-ported SRAM incurs very high overhead, and the parsing and multiple lookups also demand higher access rates. Therefore, the industry consensus is that processing payloads on this type of switch would severely impact the chip's overall throughput.
Port-Based Buffer Switch
To avoid the die area, bandwidth, and operational speed overhead of a large, centralized, multi-ported SRAM buffer, a buffer structure based on each port or a group of ports (PortLogic) can be used. Forwarding via Cut-Through also reduces latency.
In fact, we can see that the Tomahawk Ultra can achieve 51.2Tbps line rate with 64B packets.
Latency is also further reduced to < 250ns, and the overall system jitter is relatively small.
From the chip's structure, it is a long, flat die.
Its architecture actually consists of 32 independent PortLogic units, each with its own independent buffer for buffering and Link-Level Retry (LLR).
In practice, for a UALink DL FLIT, using a Cut-Through approach, the payload can be processed one 64B TL FLIT at a time for address lookups, and then dispatched to the egress PortLogic. Once the egress PortLogic has accumulated 640B, it can pack it into a DL FLIT and send it to the GPU.
From the switch chip's perspective, the cost of adding this processing is not large. The buffer on the PortLogic can be reused, and the overall die area increase to support UALink-style TL FLIT parsing and forwarding is not significant, while bandwidth evolution is also guaranteed.
2.3 The Point of Contention: Cut-Through
As mentioned in the previous section, the trade-off between Cut-Through and Store-and-Forward is more about the choice between Shared Buffer and Port-Based Buffer at the chip architecture level. Does UALink count as Cut-Through?
In fact, for many networking professionals, their initial reaction to the UALink standard is to complain about how complex it makes the switch, requiring both disassembly and reassembly of packets, raising significant concerns about switch complexity and latency. And indeed, building a good UALink switch is quite difficult. On the other hand, even making a standard Ethernet switch at 51.2Tbps / 102.4Tbps is immensely challenging, especially the centralized Traffic Manager's MMU. One vendor encountered many problems trying to use two ingress TMs, while another domestic vendor using a multi-die architecture faced difficult load-balancing issues.
In reality, the bar to build a 51.2Tbps / 102.4Tbps switch chip, whether it's a UALink switch or an Ethernet switch, is very high, especially for a single-die implementation.
On the other hand, in many high-end routers, especially chassis-based routers with cell-based forwarding, the forwarding mechanism is actually similar to UALink: packets are sliced into cells, a self-routing header is attached, and they are forwarded to the egress for reassembly.
2.4 The Impact of Latency
Another dimension of the spat between UALink and SUE focuses on latency. Is a latency difference of around 100ns important? This depends on the microarchitecture of the compute chip. Is it a monolithic 200MB SRAM like in many DSAs? Or is it like a GPGPU with only 256KB of SRAM inside each SM? Does it allow direct LD/ST from GPU A's SRAM to GPU B's SRAM, or must it go through GPU A's SRAM to GPU B's DRAM, followed by a LD from DRAM to SRAM on GPU B?
For a compute chip, adding 100ns of latency at a Scale-Up bandwidth of 1.8TB/s would require an additional 100KB of SRAM. This might not be an issue for a DSA architecture with a single 200MB SRAM, but for GPGPU architectures, it may need further evaluation. Perhaps the impact is not significant there either?
I actually care more about fabric jitter. For SUE, because it needs to build queues at the endpoint for different destination GPUs and then pack them into a single data packet via a scheduling/polling mechanism, the packet length is variable as it traverses the switch. This will introduce some jitter.
For example, if we calculate the peak jitter for a 1500B packet on a 224G Serdes, it introduces an additional 53.5ns of serialization delay (jitter), whereas for a UALink 64B FLIT, the jitter is only ~2.3ns. Additionally, we have to consider jitter caused by the switch fabric's scheduling, and in an incast scenario, there might be even more jitter.
For UALink, in an incast situation, because it internally forwards 64B FLITs, a receiving port can encapsulate 64B TL FLITs from multiple source GPUs into a single DL FLIT. The overall jitter would be much smaller compared to the SUE approach.
2.5 In-Network Computing: Another "Smart Core"?
Although Nvidia has added NVLS (NVLink Switch Scalable) capabilities to its NVLink Switch, it's clear that it cannot support the very important MoE Dispatch/Combine functions. To support in-network computing, many block-based quantization formats like MXFP4, NVFP4, and FP8 would need to be supported. Also, considering the precision issue for addition, an FP32 accumulator might still be necessary. Implementing these functions would greatly increase the complexity of the switch. I remain skeptical about the specific end-to-end business benefits.
3. ESUN / SUE / UALink
Of course, I think there's no need to analyze Ethernet Scale-Up and UALink in such an adversarial way. From a transport layer perspective, the counterpart to UALink is SUE. We need to evaluate the comparison of die area and power consumption on the accelerator side for both under the same 1.8TB/s Scale-Up scenario, and make a thorough trade-off regarding the implementation complexity of the switch.
As for the physical link layer, whether it's SUE, UALink, or NVLink, it's not out of the question for them to unify on ESUN in the future. UALink over Ethernet or IFoE.
On another note, within the ecosystem, there has been some noise recently about using CXL 4.0 for Scale-Up. The real question we must answer is: which mainstream GPU / CPU vendors will support this solution? Of course, UALink also has some ecosystem gaps. For example, what if AMD's own GPUs don't pull their weight?
The wheel of time has rolled over many bus standards. For instance, the transition from ISA to PCI, then to AGP, and then to PCIe, each was a decade-long replacement cycle. PCIe itself is old and overburdened. Although many domestic GPU vendors still hope for a PCIe-like Scale-Up bus, it is already beyond redemption...
A good ecosystem is not about big companies fighting each other to the death, but about sincere cooperation with shared benefits. See also two other related articles:
"On Reliable Transport for RDMA and Scale-Up"
"On ESUN, SUE, and UALink"
This article represents only the author's personal views and is not related to the author's affiliated institution.TL;DR
Recently, I've seen some articles and had some discussions with GPU and network chip vendors. Many disagreements about Scale-Up have not yet converged. These discussions are heavily influenced by the interests of various companies, and while each opinion seems correct from its own standpoint, the entire system has reached an impasse.
For example, is the principle of "Smart Edge, Dumb Core," often emphasized by the networking engineers, still correct in a Scale-Up scenario? As the person who first pioneered Ethernet Scale-Up globally(NetDAM in 2020), I'd like to elaborate further. Any design choice or trade-off made without considering the microarchitecture of the compute chip and its memory model is inherently flawed.
As for simplifying Ethernet headers, like Broadcom's AFH, back in 2021 when we completed NetDAM development, I had already proposed to a switch chip company to add some UDF (User-Defined Field) capabilities to the MAC field to support LPM (Longest Prefix Match) processing.
Let me state my personal opinion: I am more inclined to agree with link-layer cost amortization solutions like ESUN, but I am less convinced by SUE or other transport-layer solutions.
1. Smart Edge, Dumb Core? Starting with Scale-Out
As a side note, it seems that today's Scale-Out networks have become a loyalty test for the "Smart Edge, Dumb Core" principle. Interestingly, in the Scale-Out context, this creed seems to be abandoned as people discuss end-to-end co-design, PacketSpray, Adaptive Routing, DLB (Dynamic Load Balancing), GLB (Global Load Balancing), and a series of "Smart Core" capabilities. For instance, a certain vendor constantly hypes its 102.4T solution. I looked at their SGLB paper, which was published in a top conference, showing that for All-to-All traffic at 80% link load, the bandwidth utilization was merely 50%...
It feels like their loyalty is not absolute. A true network engineer must face the grim reality of a Dumb Fabric Core!
If we adhere to "Smart Edge, Dumb Core," can we solve all transport congestion and multi-path hash collision problems purely on the end-host NIC, without using any advanced switch features (including INT/PacketSpray), not even ECN/PFC? Furthermore, for long-distance transport, can we achieve full bandwidth utilization across availability zones without needing deeper switch buffers or switch QoS policies?
The answer is yes. If you can't do it, it's just because your algorithm guys need to study more math. We achieved this years ago. A year later, I saw a company that was getting close to the idea and protectively filed a patent in 2024. Now that the patent has been public for 18 months, I still haven't seen these companies produce a usable product... quite disappointing...
Recently, people from several companies have been asking me how to notify the end-host of a switch link failure by adding switch functionality. In truth, if your end-host algorithm is sound, you really don't need it.
On the other hand, we went from changing topologies to Rail-Based deployments to avoid hash collisions, and now with the rise of MoE (Mixture of Experts) models with large expert parallelism (EP), it seems we are back to wrangling with multi-plane CLOS architectures and confronting multi-pathing head-on. This signals that attempts to solve these problems by changing the topology have likely reached their endgame.
For Scale-Out, the trade-offs for adhering to the "Smart Edge, Dumb Core" principle by solving all multi-path load balancing, reliable transport, and congestion control at the end-host are as follows:
Under these two constraints, placing functions like multi-path load balancing, reliable transport, and congestion control on the end-host to build a "Smart Edge, Dumb Core" system is an inevitable choice.
2. Discussing Scale-Up: Dumb Edge, Dumb Core?
Should Scale-Up also adhere to the "Smart Edge, Dumb Core" principle?
2.1 Scale-Up Node Count
First, regarding the scale of Scale-Up, looking at the number of experts in MoE models and the feasible scale for Tensor Parallelism (TP) within model architectures, a Scale-Up size of at most 256 GPU nodes is sufficient. Particularly in inference scenarios, factors like fault domain isolation and the need for elastic deployment based on workload will typically further reduce the deployment scale.
For example, with a 256-accelerators cluster, if a MaaS (Model-as-a-Service) platform expands by 256 accelerators at a time, the newly added super-node might have a load of less than 5%, causing the overall cluster load to be, for instance, below 70%. In this case, if we instead expand incrementally in 32-accelerators units, although the peak performance of eight 32-accelerators super-nodes might only reach 80-90% of a single 256-accelerators super-node, the elastic, on-demand expansion offers greater cost benefits.
On the other hand, super-nodes with thousands of cards are meaningless. To support such massive-scale networking, the switching network would require two layers, introducing more load balancing and reliability problems. A single-layer switch network structure is therefore preferred. Similarly, Broadcom's GM also emphasizes single-layer networking.
Conclusion: Scale-Up node counts of 64 / 128 / 256 accelerators are sufficient.
2.2 Scale-Up Transport from a Chip Perspective
From a chip perspective, the required radix for a Scale-Up switch is determined by the node count. With 224G Serdes interconnects, a switch chip with a radix of 256 would have a capacity of 51.2Tbps, which is sufficient. On the other hand, we need to look at the GPU side. With a Scale-Up bus of 1.8TB/s, the unidirectional bandwidth is 900GB/s, or 7.2Tbps. This means the bandwidth ratio between the endpoint and the switch is approximately 1:7.
We need to make trade-offs in this scenario. Considering the power/thermal issues of the GPU die itself, as well as the die area occupied by Scale-Up logic, would it be better to shift some of the power budget to the switch side? This would also reduce the overall cooling difficulty and make power management easier. At the same time, a simpler endpoint function could free up more die area to further increase compute power. Under this view, it seems we should choose "Dumb Edge, Smart Core."
But how should the Core Switch be handled? How should the chip architecture be designed, and how should the transport layer be constructed?
I feel I wasn't clear enough when I gave advice to Broadcom in early 2024. I just told them they could reference the method proposed in Nvidia's 2023 paper, "FinePack: Transparently Improving the Efficiency of Fine-Grained Transfers in Multi-GPU Systems," which involves packing multiple Load/Store (LD/ST) operations into a single packet.
However, throughout this process, I did not elaborate on how multiple LD/STs should be dispatched across the switch. Consequently, SUE's transport layer did not handle the packing of multiple LD/STs very well.
In fact, this implies another switch chip architecture problem: which buffer architecture to choose for the switch chip. Much of the criticism from the networking community about UALink comes from the fact that UALink requires the switch to disassemble a Data Link (DL) Flit, perform lookups, and forward multiple Transport Layer (TL) Flits. The conventional wisdom is that a switch cannot maintain line-rate forwarding at such high bandwidths as 51.2Tbps/102.4Tbps. In reality, this constraint comes from the switch's microarchitecture. If a Shared Buffer Switch is used, designing the Traffic Manager's MMU to achieve line-rate PPS at 51.2T/102.4T is extremely difficult. However, using a Port-Based Buffer design, especially in the Scale-Up domain with simple Accelerator ID lookups, is very easy. Specifically:
Shared Buffer Switch
This architecture typically stores received packets in a centralized buffer, then extracts the packet header, parses it, performs a table lookup, and instructs the egress port to forward. If the payload needs to be parsed and processed, this buffer requires a higher operational speed because it's an MMU composed of multi-ported SRAM. Multi-ported SRAM incurs very high overhead, and the parsing and multiple lookups also demand higher access rates. Therefore, the industry consensus is that processing payloads on this type of switch would severely impact the chip's overall throughput.
Port-Based Buffer Switch
To avoid the die area, bandwidth, and operational speed overhead of a large, centralized, multi-ported SRAM buffer, a buffer structure based on each port or a group of ports (PortLogic) can be used. Forwarding via Cut-Through also reduces latency.
In fact, we can see that the Tomahawk Ultra can achieve 51.2Tbps line rate with 64B packets.
Latency is also further reduced to < 250ns, and the overall system jitter is relatively small.
From the chip's structure, it is a long, flat die.
Its architecture actually consists of 32 independent PortLogic units, each with its own independent buffer for buffering and Link-Level Retry (LLR).
In practice, for a UALink DL FLIT, using a Cut-Through approach, the payload can be processed one 64B TL FLIT at a time for address lookups, and then dispatched to the egress PortLogic. Once the egress PortLogic has accumulated 640B, it can pack it into a DL FLIT and send it to the GPU.
From the switch chip's perspective, the cost of adding this processing is not large. The buffer on the PortLogic can be reused, and the overall die area increase to support UALink-style TL FLIT parsing and forwarding is not significant, while bandwidth evolution is also guaranteed.
2.3 The Point of Contention: Cut-Through
As mentioned in the previous section, the trade-off between Cut-Through and Store-and-Forward is more about the choice between Shared Buffer and Port-Based Buffer at the chip architecture level. Does UALink count as Cut-Through?
In fact, for many networking professionals, their initial reaction to the UALink standard is to complain about how complex it makes the switch, requiring both disassembly and reassembly of packets, raising significant concerns about switch complexity and latency. And indeed, building a good UALink switch is quite difficult. On the other hand, even making a standard Ethernet switch at 51.2Tbps / 102.4Tbps is immensely challenging, especially the centralized Traffic Manager's MMU. One vendor encountered many problems trying to use two ingress TMs, while another domestic vendor using a multi-die architecture faced difficult load-balancing issues.
In reality, the bar to build a 51.2Tbps / 102.4Tbps switch chip, whether it's a UALink switch or an Ethernet switch, is very high, especially for a single-die implementation.
On the other hand, in many high-end routers, especially chassis-based routers with cell-based forwarding, the forwarding mechanism is actually similar to UALink: packets are sliced into cells, a self-routing header is attached, and they are forwarded to the egress for reassembly.
2.4 The Impact of Latency
Another dimension of the spat between UALink and SUE focuses on latency. Is a latency difference of around 100ns important? This depends on the microarchitecture of the compute chip. Is it a monolithic 200MB SRAM like in many DSAs? Or is it like a GPGPU with only 256KB of SRAM inside each SM? Does it allow direct LD/ST from GPU A's SRAM to GPU B's SRAM, or must it go through GPU A's SRAM to GPU B's DRAM, followed by a LD from DRAM to SRAM on GPU B?
For a compute chip, adding 100ns of latency at a Scale-Up bandwidth of 1.8TB/s would require an additional 100KB of SRAM. This might not be an issue for a DSA architecture with a single 200MB SRAM, but for GPGPU architectures, it may need further evaluation. Perhaps the impact is not significant there either?
I actually care more about fabric jitter. For SUE, because it needs to build queues at the endpoint for different destination GPUs and then pack them into a single data packet via a scheduling/polling mechanism, the packet length is variable as it traverses the switch. This will introduce some jitter.
For example, if we calculate the peak jitter for a 1500B packet on a 224G Serdes, it introduces an additional 53.5ns of serialization delay (jitter), whereas for a UALink 64B FLIT, the jitter is only ~2.3ns. Additionally, we have to consider jitter caused by the switch fabric's scheduling, and in an incast scenario, there might be even more jitter.
For UALink, in an incast situation, because it internally forwards 64B FLITs, a receiving port can encapsulate 64B TL FLITs from multiple source GPUs into a single DL FLIT. The overall jitter would be much smaller compared to the SUE approach.
2.5 In-Network Computing: Another "Smart Core"?
Although Nvidia has added NVLS (NVLink Switch Scalable) capabilities to its NVLink Switch, it's clear that it cannot support the very important MoE Dispatch/Combine functions. To support in-network computing, many block-based quantization formats like MXFP4, NVFP4, and FP8 would need to be supported. Also, considering the precision issue for addition, an FP32 accumulator might still be necessary. Implementing these functions would greatly increase the complexity of the switch. I remain skeptical about the specific end-to-end business benefits.
3. ESUN / SUE / UALink
Of course, I think there's no need to analyze Ethernet Scale-Up and UALink in such an adversarial way. From a transport layer perspective, the counterpart to UALink is SUE. We need to evaluate the comparison of die area and power consumption on the accelerator side for both under the same 1.8TB/s Scale-Up scenario, and make a thorough trade-off regarding the implementation complexity of the switch.
As for the physical link layer, whether it's SUE, UALink, or NVLink, it's not out of the question for them to unify on ESUN in the future. UALink over Ethernet or IFoE.
On another note, within the ecosystem, there has been some noise recently about using CXL 4.0 for Scale-Up. The real question we must answer is: which mainstream GPU / CPU vendors will support this solution? Of course, UALink also has some ecosystem gaps. For example, what if AMD's own GPUs don't pull their weight?
The wheel of time has rolled over many bus standards. For instance, the transition from ISA to PCI, then to AGP, and then to PCIe, each was a decade-long replacement cycle. PCIe itself is old and overburdened. Although many domestic GPU vendors still hope for a PCIe-like Scale-Up bus, it is already beyond redemption...
A good ecosystem is not about big companies fighting each other to the death, but about sincere cooperation with shared benefits. See also two other related articles:
"On Reliable Transport for RDMA and Scale-Up"
"On ESUN, SUE, and UALink"