<![CDATA[The selection of network fabrics for large-scale artificial intelligence (AI) training has traditionally favored InfiniBand because of its high-performance computing heritage and tightly integrated communication capabilities. This study evaluates whether Ethernet-based fabrics, particularly Remote Direct Memory Access over Converged Ethernet version 2 (RoCEv2) and the emerging Ultra Ethernet architecture, can provide a credible alternative for large-scale AI training. The study employs a structured literature-based comparative analysis rather than an original hardware benchmark. The evaluation considers five dimensions: latency and tail latency behavior, scalability beyond 10,000 graphics processing units (GPUs), congestion control maturity, ecosystem and vendor openness, and total cost of ownership. Evidence from production deployment reports, congestion-control studies, and comparative analyses of Ethernet, Ultra Ethernet, and InfiniBand is synthesized to identify performance characteristics, architectural trade-offs, and infrastructure implications. The analysis indicates that modern lossless Ethernet fabrics have substantially reduced the performance gap for collective-communication workloads encountered in large-scale distributed AI training. RoCEv2-based architectures can achieve competitive communication performance when congestion management, quality-of-service mechanisms, and network configuration are carefully engineered. InfiniBand retains advantages in highly coupled and latency-sensitive training environments where predictable communication behavior and mature end-to-end optimization are prioritized. Ethernet-based approaches, however, provide greater vendor diversity, broader interoperability, and potentially more flexible cost structures. The emergence and standardization of Ultra Ethernet further extend Ethernet's suitability for AI-oriented networking by targeting the communication patterns and congestion characteristics of large-scale accelerator clusters. The findings indicate that network fabric selection should be based on workload characteristics, cluster scale, performance requirements, and infrastructure priorities, rather than on a universal preference for a single technology]]>
