PaperlayerView exact revision on arXiv

Source-linked AI summary

Architecting for Hardware Diversity: Meta's End-to-End Co-Design for High-Performance AI Training on AMD GPUs

Haoyu Zhang, Arshad Rahman, Adnan Aziz, Ajith Prabhudev, Amin Farmahini, Ben Rhoads, Benson Ma, Brian Shi, Cen Zhao, CK Luk, Dingming Wu, Emad El-Haraty, Eric Chen, Frank Li, Gary Huang, Gefei Zuo, Haoran Zhang, Hiwot Kassa, Hongyi Zeng, Jack Taylor, Jeremy Hadidjojo, John Donati, Jonathan Sheffield, Julio Machado Silva, Karthik Ganesan, Kent Russell, KR Kishore, Lei Tian, Liu Ke, Muhammad Osama, Peng Chen, Rakesh Hemnani, Ryan Swann, Saleel Kudchadker, Shankar Yanamandram, Shobhit Kanaujia, Shucai Xiao, Srinath Bayareddy, Srinivas Vaidyanathan, Sudharssun Subramanian, Supadchaya Puangpontip, Taylor Robie, Tianhao Huang, Tyler Hart, Viswesh Sankaran, Weijun Jiang, Wenkai Du, Xiaodong Wang, Xiaohu Guo, Yao Rong, Yinbin Ma, Yue Dong, Yuzhen Huang, Yvonne Liu, Zhan Shu, Dan Rabinovitsj, Ajit Mathews, Chunqiang Tang

arXiv:2610.22230v1cs.DCcs.ARcs.LG

TL;DR

NVIDIA-specific optimization history limits performance portability across Meta’s heterogeneous accelerator fleet. This paper combines hardware–model co-design, analytical kernel selection, and agentic optimization to train production DLRMs on AMD GPUs. Across representative production workloads, MI350X achieves 101.2% of B200 throughput at equal GPU count and batch size.

  • Problem

    NVIDIA-specific optimizations hinder portability, while hardware differences make direct migration particularly challenging for DLRMs.

    Source: §I · p. 1

  • Method

    The paper combines hardware–model co-design, analytical kernel and tile selection, and agentic workflows for kernel optimization and hardware-specific bottlenecks.

    Source: §I · pp. 1–2

  • Results

    101.2% geometric-mean throughput relative to B200 was measured across ten production workloads at equal GPU count and batch size.

    Source: §I · p. 2, A. Production Results · p. 12

  • Takeaways & Limitations

    The study presents production-scale AMD DLRM training as a viable multi-vendor approach and reports that its optimizations were upstreamed and open-sourced.

    Source: §I · p. 2, §VIII · p. 14

    MI350X GEMM performance remains an improvement area because TF32 GEMMs are emulated and hipBLAS is less mature than cuBLAS for irregular matrix shapes.

    Source: §I · p. 2

Abstract

from arXiv · show

Meta deploys a heterogeneous fleet comprising NVIDIA GPUs, AMD GPUs, and proprietary MTIA accelerators to reduce costs and mitigate vendor lock-in. However, the extensive history of NVIDIA-specific optimizations hinders performance portability to other hardware. This paper presents our methods for optimizing alternative accelerators, using AMD Instinct MI350X versus NVIDIA B200 for recommendation model training as a case study. We propose three reusable principles. First, hardware-model co-design is essential: rather than directly porting models from NVIDIA GPUs, revising model structures and software recipes allows full exploitation of accelerator-specific strengths (e.g., MI350X's 1.6x HBM capacity relative to B200). Second, our analytical performance model enables zero-warmup optimal kernel selection across diverse datatypes and matrix shapes in production models, drastically simplifying tuning. Third, increasingly mature agentic workflows have lowered the barrier to porting from the CUDA ecosystem; we extend these workflows for microarchitecture-aware kernel optimizations and custom shim generation. Compared to the directly ported baseline, these methods deliver up to 1.5x improvement in end-to-end training throughput. To our knowledge, this is the first hyperscaler report on productionizing AMD GPUs for large-scale training. Our contributions have been upstreamed to the open-source PyTorch, Triton, and ROCm ecosystems.

I. INTRODUCTION

Meta’s heterogeneous fleet supports cost, supply-chain, and hardware–model matching goals, but NVIDIA-specific optimization history impedes portability. The paper develops co-design, analytical kernel selection, and agentic optimization methods for AMD training, reporting production-scale throughput comparable to B200.

I. INTRODUCTION

  • NVIDIA-specific optimizations hinder portability, while GPU memory-hierarchy and execution-unit differences make direct migration especially challenging for DLRMs.DLRMs combine diverse architectures, fragmented kernel sets, irregular matrix dimensions, and complex memory access patterns.Source: §I · p. 1
  • Hardware–model co-design uses MI350X’s 1.6× HBM capacity relative to B200 to revise model structure and software recipes, yielding 20% training speedup and >0.1% normalized entropy improvement.The approach expands per-GPU batches, reduces activation checkpointing, and supports longer sequences, larger hidden dimensions, and expanded embedding tables.Source: §I · p. 1
  • Origami predicts optimal GEMM tile configurations in microseconds and achieves 93% accuracy relative to exhaustively autotuned kernels across diverse matrix shapes.It extends analytical performance modeling to multi-chiplet architectures and is validated at production scale.Source: §I · pp. 1–2
  • Agentic workflows automate microarchitecture-aware kernel choices and hardware-specific fixes, delivering 1.6×–2× speedups across hand-written and compiler-generated kernels.For MI350X atomics, a shared-memory tree reduction delivers up to 4× speedup in custom kernels.Source: §I · p. 2
  • 101% geometric-mean throughput relative to the established B200 baseline was achieved across representative production models, with training supported on tens of thousands of MI350X GPUs.The authors identify MI350X GEMM performance as a remaining improvement area, citing emulated TF32 overhead and hipBLAS handling of irregular shapes.Source: §I · p. 2
  • The paper presents production-scale AMD training methods and upstreams its contributions to PyTorch, Triton, and ROCm; its optimization principles are described as generalizable beyond DLRMs, including to LLMs.A comprehensive analysis of LLM-specific performance is reserved for future work.Source: §I · p. 2

A. DLRM Evolution

DLRMs have evolved across sparse and dense computation, while AMD and NVIDIA GPUs offer distinct hardware characteristics. AMD training therefore requires more than code translation: it faces distributed-training challenges and hardware-specific portability constraints.

A. DLRM Evolution

  • DLRMs combine sparse embeddings with dense feature-interaction learning, and their evolution expands both sparse-system parallelism and dense computation.Sparse evolution includes pipelining and two-dimensional parallelism; dense evolution includes scaling dense-side FLOPs and Transformer-like modules for long interaction histories.Source: A. DLRM Evolution · p. 2

B. AMD MI350X vs NVIDIA B200

  • MI350X provides 288 GB HBM versus B200’s 180 GB, while B200 leads on scale-up bandwidth and native TF32 support.The GPU comparison also identifies differences in interconnect, shared memory per SM, and power.Source: B. AMD MI350X vs NVIDIA B200 · p. 3
  • Hipification translates CUDA code into HIP, but warp-size differences mean functional compatibility alone does not ensure performance portability.The text describes compile-time hipify-clang and source-rewriting hipify_torch as two translation approaches.Source: B. AMD MI350X vs NVIDIA B200 · p. 3
  • Distributed DLRM training requires synchronization and network efficiency, backward kernels and optimizer support, and generalized performance across repeated training trials.The paper addresses these demands through optimizations spanning libraries, kernel tuning, and model co-design.Source: B. AMD MI350X vs NVIDIA B200 · p. 3

III. ROOFLINE-DRIVEN OPTIMIZATION OF ROCM LIBRARIES

The section optimizes ROCm libraries for diverse DLRM workloads using hardware-aware GEMM kernels and Origami, an analytical model that selects configurations across memory and compute constraints. The approach combines runtime kernel selection with chiplet-aware mapping to improve performance across production matrix shapes.

III. ROOFLINE-DRIVEN OPTIMIZATION OF ROCM LIBRARIES

  • ROCm optimization uses roofline models and hardware constraints to guide GEMM kernel selection and RCCL communication targets across AI workloads.For GEMM, the section illustrates pipelined loads and compute and strategies for reducing underutilized CUs from wave quantization.Source: §III · p. 3, Figure 3 · p. 5, Figure 4 · p. 5

A. GEMM Kernels for AMD MI350X

  • MI350X GEMM kernels combine CDNA 4 capabilities with finer-grained runtime parameter selection to cover diverse compute- and memory-bound tensor sizes.A single GEMM kernel can achieve performance previously requiring multiple specialized kernels.Source: A. GEMM Kernels for AMD MI350X · pp. 3–4
  • Stream-K partitions GEMM work along the K dimension, while runtime dispatch and reduction strategies improve load balance and robustness across irregular tensor sizes.Space-filling-curve workgroup mapping co-locates nearby tiles on MI350X XCDs to improve spatial locality, cache utilization, and power efficiency.Source: A. GEMM Kernels for AMD MI350X · p. 4

B. Origami: Analytical Kernel Selection

  • Origami replaces impractical offline autotuning for thousands of unique DLRM GEMM shapes by evaluating candidate tile configurations analytically and selecting the one minimizing total latency.Its model captures compute, memory traffic and cache reuse, issue-rate limits, pipelined execution, and wave-quantization effects; candidate evaluation takes nanoseconds and a full search takes microseconds.Source: B. Origami: Analytical Kernel Selection · p. 4
  • Origami predicts cache hit rates from workgroup sharing and models memory and compute latency to select tile configurations and Stream-K grid sizes.Its chiplet-aware tiling and workgroup-ID swizzling target L2 reuse across MI350X's eight XCDs.Source: B. Origami: Analytical Kernel Selection · pp. 4–5
  • Origami achieves 93% average selection efficiency versus exhaustively autotuned GEMM performance across datatypes and transpose configurations.Integrated into tritonBLAS, it enables zero-warmup runtime selection for arbitrary matrix shapes and can be retargeted by substituting hardware parameters.Source: B. Origami: Analytical Kernel Selection · p. 5

C. GPU Power Excursion Boost

The section uses MI350X transient power excursions to boost compute-heavy phases in DLRM training. Production training sees 3–6% end-to-end performance gains, with the benefit depending on workload phase patterns.

C. GPU Power Excursion Boost

  • MI350X transient excursions let compute-heavy kernels exceed the nominal roofline limit by leveraging thermal headroom between lower-power operations.The OAM specification permits short-duration power excursions beyond nominal total board power.Source: C. GPU Power Excursion Boost · pp. 5–6
  • Up to 1.33× performance gain was achieved in a synthetic benchmark by tuning MI350X power-control response across kernel durations and GEMM duty ratios.The benchmark compares against steady-state operation at 1000 W with back-to-back GEMMs while respecting excursion design power limits.Source: C. GPU Power Excursion Boost · p. 6
  • 3–6% end-to-end performance gains resulted in Meta’s DLRM production training from higher excursion limits.The benefit depends on the frequency and duration of compute-intensive phases, intervening low-power operations, and sensitivity to clock frequency.Source: C. GPU Power Excursion Boost · p. 6

D. Collective Communication with RCCL

The section co-designs RCCL transport, GPU kernels, and protocols using hardware-derived performance projections. The resulting optimizations narrow the communication gap with NCCL and improve collective performance at production scale.

D. Collective Communication with RCCL

  • RCCL refinements narrowed the communication gap from 2× slower than NCCL to within 10–15% of NCCL performance.The work was guided by hardware-level projections and supported production-scale DLRM training.Source: D. Collective Communication with RCCL · p. 6
  • Collective-specific queue-pair scaling, LL64, Direct AllGather, and P2P batching target bandwidth, latency, and protocol efficiency.P2P batching reduced AllToAll latency by 40% at 128-GPU scale; LL64 delivered 2× AllGather/ReduceScatter and 1.2×–1.4× AllReduce speedups.Source: D. Collective Communication with RCCL · p. 6
  • A warp-per-GPU communication model and occupancy changes reduced resource contention and improved collective performance.The optimizations delivered gains of 63% for ReduceScatter and 48% for AllReduce, while reducing the penalty of restricted CU allocations.Source: D. Collective Communication with RCCL · p. 6

E. Shampoo Optimizer and rocSOLVER

Shampoo’s matrix fourth-root updates make eigen decomposition a major training cost for large models. The rocSOLVER implementation improves divide-and-conquer load balance and data locality, achieving performance comparable to B200 at practical block sizes.

E. Shampoo Optimizer and rocSOLVER

  • For large models, matrix fourth-root computations for Shampoo’s preconditioners can dominate optimizer overhead, making rocSOLVER performance critical to training throughput.Shampoo maintains Kronecker-factored preconditioner matrices and periodically computes their fourth roots.Source: E. Shampoo Optimizer and rocSOLVER · p. 6
  • The eigen-decomposition algorithm reduces the symmetric matrix to tridiagonal form, computes its eigenpairs, then backtransforms the eigenvectors.The paper focuses its optimizations on the divide-and-conquer computation of the tridiagonal matrix’s eigenpairs.Source: E. Shampoo Optimizer and rocSOLVER · p. 6
  • The optimized divide-and-conquer implementation lifts the restriction to unreduced sub-blocks, enabling precise control over compute-unit allocation.The restriction can cause load imbalance because sub-block sizes depend on the input.Source: E. Shampoo Optimizer and rocSOLVER · pp. 6–7
  • The implementation orders eigenvalues and associated eigenvectors to improve locality, specializes handling of repeated eigenvalues, and merges eigenvectors with batched GEMMs.These optimizations target data movement and preprocessing costs during merge steps.Source: E. Shampoo Optimizer and rocSOLVER · p. 7
  • rocSOLVER achieves comparable eigen-decomposition performance to B200 at the 4K and 8K block sizes used in distributed Shampoo.These block sizes balance preconditioning quality with tractable, parallel eigen decomposition.Source: E. Shampoo Optimizer and rocSOLVER · p. 7, Figure 8 · p. 7

IV. KERNEL TUNING AND AGENTIC AI WORKFLOWS

The paper examines GDPA and HSTU Triton kernels in production DLRMs, then distills MI350X-specific tuning techniques into reusable kernel optimizations. These techniques address cache locality, occupancy, matrix-instruction selection, configuration choices, and GeLU computation.

IV. KERNEL TUNING AND AGENTIC AI WORKFLOWS

  • MI350X-specific tuning of GDPA and HSTU kernels illustrates optimization techniques intended to apply broadly to Triton kernels for ML models.The workflow identifies principles through production-kernel case studies and encodes them as reusable skills for an agentic workflow.Source: §IV · p. 7, 2) Optimization Techniques · p. 7

1) Attention Kernels in DLRM:

  • GDPA fuses GeLU-activated attention with a feed-forward network, while HSTU handles variable-length, sparse user interaction histories.GDPA is used in Meta’s Kunlun and Interformer models; HSTU is designed for large-scale recommendation systems.Source: 1) Attention Kernels in DLRM · p. 7

2) Optimization Techniques:

  • PID swizzling remaps Triton’s two-dimensional program-ID grid so adjacent tiles run on the same XCD, improving shared-L2 locality.MI350X has eight XCDs sharing an L2 cache, and default linear mapping can send XCDs to disjoint L2 regions.Source: 2) Optimization Techniques · p. 7
  • Setting waves_per_eu trades per-wavefront performance for higher occupancy, which can help kernels that are not fully compute-bound.GDPA uses waves_per_eu=3; HSTU exposes values 0–4 as an autotunable parameter.Source: 2) Optimization Techniques · p. 7
  • A 16 × 16 MFMA tile can outperform the default 32 × 32 tile on CDNA 4 for certain matrix shapes.The tile size is selected with the matrix_instr_nonkdim parameter.Source: 2) Optimization Techniques · p. 7
  • AMD kernels favor larger num_warps and shallower pipelines, while a direct sigmoid-based GeLU approximation avoids the tanh-based path’s extra arithmetic.The paper reports better AMD performance with num_stages ≈2; fast_expf and fast_dividef map to single hardware instructions.Source: 2) Optimization Techniques · p. 7

3) Performance Results:

Incremental MI350X kernel tuning improves GDPA and HSTU performance, with HSTU’s optimized kernels faster than B200 on both passes. The section also frames CUDA-to-AMD kernel migration as a portability challenge, particularly for atomic operations.

3) Performance Results:

  • The evaluation incrementally applies tuning techniques to GDPA and HSTU forward and backward kernels.GDPA results use a representative GEM-model configuration; HSTU results sweep sequence lengths from 256 to 4096.Source: 3) Performance Results · p. 7, B. CUDA Kernel Optimizations · p. 8
  • 1.69× combined advantage over B200: optimized MI350X HSTU kernels are 1.22× faster forward and 1.80× faster backward, averaged across sequence lengths.The forward result uses block-size tuning, occupancy hints, and PID swizzling; MFMA tuning provides a 1.21× backward speedup.Source: 3) Performance Results · p. 8, Figure 10 · p. 8
  • 60.0% lower latency and 2.5× throughput: GDPA forward tuning reduces latency from 1.47 ms to 0.59 ms; the backward pass falls 40.9%, from 3.67 ms to 2.17 ms.The cited GDPA configuration is a representative GEM-model setup; optimized MI350X GDPA kernels outperform B200.Source: 3) Performance Results · p. 8, Figure 9 · p. 8

B. CUDA Kernel Optimizations

  • HIP translation enables CUDA kernel portability to AMD GPUs, but CUDA idioms involving atomics can perform poorly on MI350X’s multi-chiplet architecture.The section examines architectural differences and algorithmic strategies to address the resulting performance gaps.Source: B. CUDA Kernel Optimizations · p. 8

1) Atomic Operations on Multi-Chiplet GPUs:

MI350X’s cross-chiplet atomic coordination can serialize contended updates, so the paper uses reductions or local caching to reduce global atomics. These approaches improve bounds-check, GIS, and TBE workloads, with TBE results depending on index distribution.

1) Atomic Operations on Multi-Chiplet GPUs:

  • Cross-chiplet coordination makes contended atomics a serialization bottleneck; hierarchical reduction or register caching reduces global atomic traffic, with possible overhead when contention is rare.Hierarchical reduction can reduce N global atomics to ⌈N/block_size⌉; caching merges repeated updates to addresses with temporal locality.Source: 1) Atomic Operations on Multi-Chiplet… · p. 8
  • At 10% violations, tree reduction delivers 4.26× speedup; at 20%, it delivers 4.34×, and MI350X is 1.75× faster than B200.A block-level shared-memory reduction cuts global atomics from approximately 10^6 to approximately 10^3 per batch in the typical workload.Source: Figure 11 · p. 9
  • GIS forward multi-row packing delivers 1.16×–1.24× speedup, while backward register caching delivers 1.04×–1.11× speedup.The forward path packs rows into wavefronts; the backward path locally combines repeated row updates before issuing atomic adds.Source: 3) Example: Grouped Index Select (GIS)… · p. 9, Figure 12 · p. 9

4) Table Batched Embeddings (TBE):

  • TBE fuses embedding lookups across tables into one kernel launch; its backward pass scatters gradients and uses atomic accumulation for repeated indices.The reported training comparison spans 12 production configurations with varying workload characteristics.Source: 4) Table Batched Embeddings (TBE) · pp. 9–10
  • TBE backward optimization delivers 1.87–3.32× speedup on MI350X; versus B200, MI350X is 1.35–1.96× faster for uniform indices but comparable on Zipf distributions.The optimized kernel uses warp-per-row processing, vectorized loads and stores, and wavefront-level accumulation.Source: Table II · p. 9, 4) Table Batched Embeddings (TBE) · p. 10

C. Agentic Kernel Optimization Workflow

The workflow encodes AMD-specific kernel-tuning expertise in reusable agentic skills, then profiles, transforms, and validates kernels. AMD-specific Inductor changes improve several kernel categories, while transformer kernels retain optimization headroom.

C. Agentic Kernel Optimization Workflow

  • The workflow profiles representative production inputs, matches bottlenecks to skills, then generates candidate changes and validates numerical equivalence and performance.Skills encode transformation templates and applicability conditions; failures outside the numerical tolerance are rejected.Source: C. Agentic Kernel Optimization Workflow · p. 10
  • 2.3× speedup in jagged flash attention’s backward pass (32 ms→14 ms) made MI350X 15–20% faster than B200 and improved end-to-end training throughput by 25%.The agent replaced contended atomic updates with per-KV-head register accumulation and a final tree reduction.Source: C. Agentic Kernel Optimization Workflow · p. 10
  • Applied to dozens of production Triton kernels, agent-generated optimizations exceed an 80% success rate and reduce development time by an order of magnitude.The skill abstraction transfers across ISAs, with an atomics-to-tree-reduction analog on MTIA.Source: C. Agentic Kernel Optimization Workflow · p. 10

1) Optimization Techniques:

2) Model-Level Results:

AMD-specific Inductor optimizations improve several kernel categories, while model-system co-design uses MI350X’s larger HBM for training-efficiency and model-quality strategies. The combined feed-ranking co-design and kernel optimizations achieve a 1.5× speedup over the initial baseline.

2) Model-Level Results:

  • AMD-specific Inductor optimizations reduce overall kernel time by 4.2% for DenseNet-121 and 3.4% for NanoGPT; transformer Inductor kernels remain 30% slower than B200.Reduction kernels improve by 6.9–11.7%, persistent reductions by 3.5–4.8%, and pointwise kernels by up to 9.2%.Source: 2) Model-Level Results · p. 11

A. Strategies for Training Efficiency

  • Larger batches, disabling activation checkpointing, and less aggressive sharding use MI350X’s HBM capacity to improve throughput and reduce communication overhead.On GPT-2 1.3B, MI350X without activation checkpointing achieves 96.4 examples/second, versus 71.5 examples/second for B200 using aggressive checkpointing; HSDP provides 6% speedup for a large Ads model at 1K-GPU scale.Source: A. Strategies for Training Efficiency · p. 11, §V · p. 11, Figure 14 · p. 12
  • 1.5× speedup over the initial baseline results from combining feed-ranking co-design with kernel optimizations.Increasing batch size, removing activation checkpointing, and optimizing embedding placement together yield a 1.26× speedup before kernel optimizations.Source: A. Strategies for Training Efficiency · p. 12
  • Moving embedding tables from host memory to HBM and changing their sharding reduces transfer and communication overhead; placement optimization yields over 10% speedup on a feed-ranking model.Combining embedding placement with batch-size increases and activation-checkpointing removal yields the reported 1.26× speedup.Source: A. Strategies for Training Efficiency · p. 12

B. Strategies for Model Quality

  • Increasing feed-ranking attention layers from 8 to 16 improves normalized entropy by 0.08%; increasing them to 20 improves it by 0.11%.These model changes fit within MI350X memory capacity, whereas B200 would require cluster expansion; the paper notes such gains are nontrivial in mature production models.Source: B. Strategies for Model Quality · p. 12

VI. EVALUATION

The evaluation compares ten production workloads on MI350X and B200, then examines throughput and kernel-latency differences. At matched GPU counts and batch sizes, MI350X reaches a 101.2% geometric-mean performance ratio against B200.

A. Production Results

  • 101.2% geometric-mean performance ratio shows MI350X matches B200 throughput across ten production workloads at equal GPU count and batch size.The workloads span single-node (8-GPU) to multi-node (128-GPU) scales.Source: A. Production Results · p. 12, Table III · p. 13
  • B200 retains a performance-per-watt edge, but the paper states that MI350X’s lower total cost of ownership drives provisioning.The comparison uses an equal number of same-generation B200 GPUs, and the authors describe that baseline as extensively optimized.Source: A. Production Results · pp. 12–13
  • MI350X achieves higher per-GPU throughput in Model-D (98% to 102%), Model-E (94% to 110%), and Model-F (92% to 95%) by leveraging larger HBM and batch sizes.Kernel comparisons intentionally hold batch sizes equal, which underutilizes MI350X but provides consistent shapes.Source: A. Production Results · p. 13

B. Kernel Category Analysis

Kernel-category analysis finds consistent MI350X advantages in hand-written Triton kernels, but mixed results for collectives, embeddings, GEMM, and Inductor kernels. The paper also describes operational measures for reliability and observability and positions its optimizations as a transferable, open-source framework.

B. Kernel Category Analysis

  • Hand-written Triton kernels reduce execution latency by 6%–52% on MI350X, while GEMM latency is 1.3×–1.7× higher than B200 and Inductor results vary by model.Model-H’s Triton category achieves 2.1× speedup; collective latency comparisons can diverge from throughput because multi-stream overlap masks some costs.Source: B. Kernel Category Analysis · p. 13

C. Operational Considerations

  • MI350X’s training-failure rate has more than halved from its peak as the team addressed HBM RAS, multi-chiplet memory-access faults, and silent data corruption.The paper also describes checksum-and-replay checks, device-voting quarantine, host screening, cross-vendor telemetry, and trace analysis.Source: C. Operational Considerations · pp. 13–14

VII. RELATED WORK

  • Related work includes KernelEvolve’s general agentic framework; this paper adds AMD-specific tuning skills validated on production DLRM training workloads.The cited background also covers accelerators, distributed training infrastructure, embedding placement, and kernel-level optimization.Source: §VII · p. 14

VIII. CONCLUSION

  • The authors present MI350X–B200 production DLRM performance parity as the outcome of cross-stack optimization spanning ROCm libraries, kernel tuning, and model co-design.They report that the optimizations have been upstreamed and open-sourced.Source: §VIII · p. 14

Related papers

Loading 2610.22230v1…