hipify를 활용한 CUDA에서 ROCm으로의 전환

2025-10-17, G25DR

1. 요약 (Executive Summary)

본 보고서는 NVIDIA CUDA 생태계에 의존해 온 개발자와 조직이 AMD ROCm 플랫폼으로의 전환을 고려할 때 필요한 기술적 지침과 전략적 통찰을 제공하는 것을 목표로 한다. 보고서는 크게 두 부분으로 구성된다.

1부: 자동 변환 가이드: 첫 번째 부분에서는 AMD의 hipify 도구를 사용하여 기존 CUDA 코드를 HIP(Heterogeneous-compute Interface for Portability) 코드로 자동 변환하는 실무적 절차를 상세히 다룬다. 환경 설정부터 코드 변환, 컴파일, 검증까지의 전 과정을 단계별로 안내하며, 자동화 도구의 효과성과 명백한 한계를 분석한다. hipify는 코드 포팅의 초기 장벽을 획기적으로 낮추는 강력한 도구이지만, 완벽한 ‘원클릭’ 솔루션이 아니며, 성공적인 전환을 위해서는 변환 후 수동 검증 및 성능 최적화가 필수적임을 강조한다.

2부: 생태계 심층 비교: 두 번째 부분에서는 ROCm과 CUDA를 하드웨어 아키텍처, 프로그래밍 모델, 성능 벤치마크, 핵심 라이브러리, AI 프레임워크 지원, 개발자 도구 등 다각적인 관점에서 심층 비교 분석한다. 단순한 기능 나열을 넘어, 각 생태계의 철학, 강점, 약점, 그리고 시장에서의 전략적 의미를 해석한다.

주요 결론: AMD ROCm은 특히 대용량 메모리가 필수적인 최신 AI 워크로드에서 하드웨어적으로 NVIDIA와 대등하거나 우월한 경쟁력을 확보했으며, 주요 클라우드 기업들의 채택으로 시장 입지를 빠르게 넓히고 있다. 그러나 CUDA가 수십 년간 구축해온 소프트웨어 생태계의 성숙도, 안정성, 개발자 경험은 여전히 NVIDIA의 가장 강력한 ’해자(moat)’로 남아있다. 본 보고서는 이러한 복합적인 상황을 종합적으로 평가하여, 조직의 특정 요구사항에 맞는 최적의 의사결정을 지원하기 위한 구체적인 권고 사항을 제시한다.

2. 서론: 이종 컴퓨팅 환경의 현재와 미래

2.1 GPU 컴퓨팅의 패러다임과 NVIDIA CUDA의 지배력

GPU를 범용 병렬 처리 장치로 활용하는 GPGPU(General-Purpose computing on Graphics Processing Units) 기술의 등장은 고성능 컴퓨팅(HPC)과 인공지능(AI) 분야에 혁명을 가져왔다. 이 혁명의 중심에는 NVIDIA의 CUDA(Compute Unified Device Architecture)가 있었다. CUDA는 단순한 하드웨어 기술을 넘어, 개발자 친화적인 프로그래밍 모델, 방대한 가속 라이브러리, 그리고 성숙한 개발 도구 생태계를 아우르는 통합 플랫폼이다.1 이러한 통합적 접근 방식은 개발자들이 복잡한 GPU 아키텍처를 비교적 쉽게 활용할 수 있게 해주었고, 결과적으로 CUDA는 HPC 및 AI 분야의 사실상 표준(de facto standard)으로 자리매김했다.4

CUDA의 성공은 기술적 우위뿐만 아니라 강력한 네트워크 효과와 높은 전환 비용을 통해 구축된 경제적 해자에 기인한다. 개발자들이 CUDA를 사용하여 애플리케이션과 라이브러리를 개발함에 따라, CUDA를 지원하는 소프트웨어 자산이 기하급수적으로 증가했다.1 이는 새로운 개발자들이 다른 플랫폼보다 CUDA를 선택하게 만드는 강력한 유인(네트워크 효과)으로 작용했으며, 기존 CUDA 기반 프로젝트들은 다른 플랫폼으로 이전하기 어려운 높은 전환 비용에 직면하게 되었다. GPU 컴퓨팅 시장의 경쟁 구도는 단순한 하드웨어 성능 대결을 넘어, ’생태계 대 생태계’의 전쟁으로 심화되었다.

2.2 AMD ROCm의 도전: 개방성과 대안의 가치

NVIDIA의 독점적 생태계에 대한 대안으로 등장한 것이 바로 AMD의 ROCm(Radeon Open Compute) 플랫폼이다. ROCm은 하드웨어 드라이버부터 컴파일러, 라이브러리에 이르기까지 전체 소프트웨어 스택을 오픈소스로 제공하는 전략적 차별점을 가진다.2 이러한 개방성은 특정 벤더에 대한 종속성(vendor lock-in)을 우려하는 시장, 특히 자체적으로 대규모 인프라를 운영하며 높은 수준의 제어와 사용자 정의를 원하는 하이퍼스케일러(hyperscaler)들에게 매력적인 요소로 작용한다.6 AMD는 ROCm을 통해 CUDA가 구축한 폐쇄적인 성벽에 균열을 내고, 개방성과 유연성을 무기로 새로운 생태계를 구축하고자 한다.

2.3 코드 이식성의 중요성과 HIP의 역할

특정 하드웨어 플랫폼에 종속된 코드를 다른 플랫폼으로 이전하는 작업은 막대한 시간과 비용을 수반한다. CUDA로 작성된 수많은 코드 자산은 NVIDIA의 강력한 경쟁력이자, 다른 GPU 벤더에게는 넘어야 할 거대한 장벽이다. AMD는 이 문제를 해결하기 위한 핵심 전략으로 HIP(Heterogeneous-compute Interface for Portability)를 제시했다.

HIP는 CUDA와 매우 유사한 문법을 가진 C++ 런타임 API 및 커널 언어이다. 개발자는 HIP를 사용하여 단일 소스 코드를 작성하고, 이 코드를 컴파일하여 AMD GPU와 NVIDIA GPU 모두에서 실행할 수 있다.2 AMD의 ROCm과 HIP 전략은 CUDA의 높은 전환 비용을 직접적으로 공략하는 것이다. 특히, hipify라는 자동 변환 도구는 기존 CUDA 코드를 HIP 코드로 변환하는 과정을 자동화하여 기술적 전환 비용을 획기적으로 낮추는 역할을 한다. hipify의 성공 여부와 ROCm 생태계의 성숙 속도는 향후 GPU 시장의 경쟁 지형을 결정할 핵심 변수라 할 수 있다.

3. hipify를 활용한 CUDA 코드 자동 변환 실무 가이드

기존 CUDA 코드베이스를 AMD ROCm 플랫폼으로 이전하는 과정에서 가장 중요한 첫 단계는 코드를 HIP 형식으로 변환하는 것이다. AMD는 이 과정을 자동화하기 위해 HIPIFY라는 도구 모음을 제공하며, 여기에는 hipify-clang과 hipify-perl이라는 두 가지 주요 도구가 포함된다.

3.1 HIPIFY 도구 선택: hipify-clang vs. hipify-perl

두 도구는 변환 방식과 장단점에서 차이를 보이므로, 프로젝트의 특성에 맞게 선택해야 한다.

• hipify-perl: 이 도구는 펄(Perl) 스크립트로 작성되었으며, 정규 표현식(Regular Expression)을 기반으로 CUDA API 호출과 문법을 HIP에 대응하는 형태로 텍스트를 치환한다.

• 장점: 별도의 CUDA 설치가 필요 없으며, 구문적으로 완벽하지 않은 코드에도 적용할 수 있어 설정이 간편하고 빠르다. 코드베이스를 빠르게 스캔하여 포팅 범위를 예측하는 --examine 옵션과 함께 사용하기에 유용하다.10

• 단점: 텍스트 치환 방식의 한계로 인해 복잡한 매크로나 C++ 템플릿으로 구성된 코드를 정확하게 변환하지 못할 수 있다.8

• hipify-clang: Clang 컴파일러 프론트엔드를 기반으로 동작하는 강력한 변환기이다. 소스 코드를 구문 분석하여 AST(Abstract Syntax Tree)를 생성하고, 이를 기반으로 의미론적 변환(semantic translation)을 수행한다.

• 장점: 코드의 문맥을 이해하고 변환하므로 hipify-perl보다 훨씬 정확하고 신뢰성 높은 결과를 제공한다. 복잡한 C++ 구조와 템플릿 코드 변환에 강점을 보여 대규모 프로젝트 포팅에 적합하다.8

• 단점: 변환을 위해서는 입력 CUDA 코드가 구문적으로 완벽해야 하며, 컴파일에 필요한 모든 헤더 파일과 컴파일러 정의(-I, -D 등)를 제공해야 한다. 또한, 시스템에 호환되는 버전의 CUDA 툴킷이 설치되어 있어야 한다.12

권장 사항: 초기 범위 분석이나 간단한 코드 조각 변환에는 hipify-perl을 사용할 수 있지만, 실제 대규모 애플리케이션의 안정적인 포팅을 위해서는 hipify-clang 사용이 강력하게 권장된다.

3.2 개발 환경 구축 및 종속성 해결

hipify-clang을 성공적으로 사용하기 위해서는 몇 가지 핵심적인 종속성을 정확하게 설정해야 한다.

• 필수 구성 요소: hipify-clang은 특정 버전의 CUDA Toolkit과 LLVM+Clang에 의존한다. ROCm 공식 문서에 따르면, 최신 버전의 hipify-clang은 CUDA 12.8.1과 LLVM 20.1.8의 조합을 권장하며, 최소 CUDA 7.0과 LLVM 4.0.0 이상이 필요하다.12 이 버전 호환성은 변환의 성공 여부를 결정하는 중요한 요소이다.

• 설치 및 경로 설정: 대부분의 리눅스 배포판에서는 패키지 관리자를 통해 LLVM+Clang을 설치할 수 있다. 시스템에 여러 버전의 CUDA나 LLVM이 설치된 경우, hipify-clang 실행 시 --cuda-path와 --clang-resource-directory 옵션을 사용하여 변환에 사용할 특정 버전을 명시적으로 지정해야 한다. 이는 변환 과정의 예측 가능성과 일관성을 보장하는 데 매우 중요하다.12

• ROCm 설치: 변환된 HIP 코드를 컴파일하고 실행할 대상 시스템(예: AMD Instinct GPU 탑재 서버)에는 ROCm 드라이버 및 툴킷이 설치되어 있어야 한다. apt(Ubuntu)나 yum(RHEL/CentOS)과 같은 시스템 패키지 관리자를 통해 공식 저장소를 등록하고 설치하는 것이 가장 안정적인 방법이다.14 설치 후 rocminfo 명령어를 실행하여 시스템이 GPU를 올바르게 인식하는지 확인해야 한다.

3.3 자동 변환 실행 단계별 절차 (hipify-clang 중심)

hipify-clang을 이용한 변환 과정은 명확한 명령어 구조를 따른다.

• 기본 명령어 구조: hipify-clang [hipify_options] <source_file(s)> -- [clang_options]

• [hipify_options]: -o <output_file>, --inplace, --print-stats 등 hipify-clang 자체의 동작을 제어하는 옵션이다.

• <source_file(s)>: 변환할 하나 이상의 CUDA 소스 파일(.cu)이다.

• --: hipify-clang 옵션과 Clang 컴파일러 옵션을 구분하는 구분자이다.

• [clang_options]: 원본 CUDA 코드를 컴파일하는 데 필요한 모든 Clang 옵션이다. 예를 들어, 헤더 검색 경로(-I/path/to/includes), 매크로 정의(-DNDEBUG), C++ 표준 버전(-std=c++17) 등이 포함된다.12

• 실행 예시:

# 단일 파일 변환: my_kernel.cu를 my_kernel.hip.cpp로 변환
hipify-clang my_kernel.cu -o my_kernel.hip.cpp --cuda-path=/usr/local/cuda-12.1 -- -I./includes -std=c++17

# 현재 디렉토리의 모든.cu 파일을.hip 파일로 변환 (in-place)
hipify-clang *.cu --inplace --cuda-path=/usr/local/cuda-12.1 -- -I./includes

• JSON 컴파일 데이터베이스 활용: 대규모 프로젝트에서는 각 소스 파일마다 다른 컴파일 옵션이 필요할 수 있다. CMake와 같은 현대적인 빌드 시스템은 compile_commands.json이라는 파일을 생성하여 이 정보를 저장한다. hipify-clang은 -p 옵션을 통해 이 파일을 직접 읽어 각 파일에 맞는 컴파일 옵션을 자동으로 적용할 수 있어, 변환 과정을 획기적으로 간소화한다.

# build 디렉토리에 생성된 compile_commands.json을 사용하여 프로젝트 전체 변환
cd build
# -p 옵션 사용 시 '--' 구분자는 사용하지 않음
hipify-clang -p. my_project/src/kernel1.cu my_project/src/kernel2.cu --inplace

이 방식은 복잡한 의존성을 가진 대규모 프로젝트를 변환할 때 매우 효과적이다.12

3.4 변환 후 코드 컴파일 및 검증

hipify-clang을 통해 생성된 HIP 소스 코드는 hipcc 컴파일러를 사용하여 AMD GPU용 실행 파일로 빌드된다.

• hipcc 컴파일러: hipcc는 실제 컴파일러가 아닌, 백엔드에서 amdclang++(AMD 플랫폼) 또는 nvcc(NVIDIA 플랫폼)를 적절한 옵션과 함께 호출하는 컴파일러 래퍼이다.16 이를 통해 HIP 코드의 이식성을 실현한다.

• 타겟 아키텍처 지정: 컴파일 시 가장 중요한 옵션 중 하나는 --offload-arch이다. 이 옵션은 코드가 실행될 특정 AMD GPU 아키텍처를 지정하여 해당 하드웨어에 최적화된 바이너리를 생성하도록 한다. 이 옵션을 생략하면 hipcc가 시스템에 설치된 GPU를 자동 감지하려 시도하지만, 여러 종류의 GPU가 혼재하거나 크로스 컴파일하는 환경에서는 명시적으로 지정하는 것이 안정적이다.17

• 사용자가 질의한 MI450 모델은 AMD의 공식 데이터센터 GPU 라인업에 존재하지 않으며, 이는 MI50 또는 MI25와 같은 유사한 번호의 모델을 잘못 기재했을 가능성이 높다. 예를 들어, AMD Instinct MI50은 GCN 5.1 아키텍처를 사용하며, 이에 해당하는 코드명은 gfx906이다.19 대상 시스템에서 rocminfo | grep Name 명령어를 실행하면 gfx로 시작하는 정확한 아키텍처 코드명을 확인할 수 있다.

# MI50 (gfx906) GPU를 타겟으로 컴파일하는 예시
hipcc --offload-arch=gfx906 my_kernel.hip.cpp -o my_application

• 컴파일 및 검증: 컴파일이 성공적으로 완료되면, 생성된 실행 파일을 대상 AMD GPU 시스템에서 실행한다. 이후 원본 CUDA 애플리케이션의 결과와 비교하여 기능적 정확성을 반드시 검증해야 한다. 기존에 구축된 단위 테스트, 통합 테스트, 리그레션 테스트 스위트를 활용하여 이 과정을 자동화하는 것이 이상적이다.14

3.4.1 표 2-1: 주요 AMD GPU 아키텍처 코드명

개발자가 --offload-arch 옵션을 정확하게 사용하여 자신의 하드웨어에 최적화된 코드를 생성할 수 있도록, 주요 데이터센터 GPU 모델과 해당 코드명을 아래 표에 정리했다.

데이터 출처: 19

3.5 변환 결과 분석 및 한계점 대응

hipify는 매우 강력한 도구이지만, 모든 것을 해결해주는 만능 솔루션은 아니다. 자동 변환 후에는 반드시 그 결과를 분석하고 잠재적인 문제에 대응해야 한다.

• 정량적 평가: hipify-clang --print-stats 또는 --print-stats-csv 옵션은 변환된 API 호출 수, 변환되지 않은 호출 수, 변환 성공률(%) 등의 통계를 제공한다. 이를 통해 어떤 API(예: CUDA Runtime, cuBLAS)가 주로 변환되었는지, 수동 작업이 필요한 부분이 얼마나 되는지 정량적으로 파악할 수 있다.12

• 자동 변환의 한계와 대응 방안:

• API 미지원: hipify는 CUDA 런타임/드라이버 API, cuBLAS, cuFFT, cuSPARSE 등 광범위한 라이브러리를 지원하지만 12, 일부 최신 CUDA 기능이나 특수한 라이브러리 호출은 HIP에 직접 대응하는 기능이 없을 수 있다. 이 경우, 해당 기능이 왜 필요한지 분석하고, HIP에서 제공하는 다른 함수를 조합하여 유사한 기능을 구현하거나 알고리즘 자체를 수정해야 할 수 있다.14

• 수치적 불일치 (Numerical Inconsistencies): 최근 연구에 따르면, hipify로 자동 변환된 코드는 부동 소수점 정밀도(FP64 vs FP32)나 수학 라이브러리(sin, exp 등)의 내부 구현 차이로 인해 원본 CUDA 코드와 미묘한 수치적 차이를 유발할 수 있다.21 이는 IEEE 754 표준을 따르더라도 발생할 수 있는 문제이다. 따라서 금융 모델링이나 정밀 과학 계산과 같이 결과의 비트 단위 일관성이 중요한 애플리케이션에서는 변환 후 결과 값에 대한 철저한 검증이 필수적이다.

• 성능 문제: hipify는 기능적 변환에 초점을 맞춘 ’번역기’이지, 성능 ’최적화기’가 아니다. 자동 변환된 코드는 기능적으로는 동일하게 동작하더라도 AMD GPU 아키텍처에 최적화되지 않아 기대보다 낮은 성능을 보일 수 있다. 예를 들어, CUDA의 warp (보통 32개 스레드) 개념은 AMD의 wavefront (32 또는 64개 스레드)에 해당하는데, 이러한 하드웨어 기본 단위의 차이를 고려한 코드 튜닝이 필요할 수 있다.10 변환 후에는 rocprof와 같은 프로파일링 도구를 사용하여 병목 구간을 찾아내고 수동으로 성능을 최적화하는 과정이 반드시 필요하다.

• 알려진 버그 및 환경 문제: 특정 개발 환경에서는 hipify-clang 도구 자체가 불안정할 수 있다. 예를 들어, Windows 환경에서 Visual Studio 2019 MSVC 툴체인을 사용할 경우 hipify-clang이 실패할 수 있다는 알려진 문제가 보고된 바 있다.22

결론적으로, hipify는 코드 포팅 작업의 약 95% 이상을 자동화하여 개발자의 초기 부담을 극적으로 줄여주는 매우 효과적인 도구이다.11 그러나 나머지 5%의 수동 수정, 그리고 눈에 보이지 않는 성능 최적화와 결과 검증 과정이 프로젝트의 최종적인 성공을 좌우하는 핵심 단계임을 명심해야 한다.

4. ROCm vs. CUDA 생태계 심층 비교 분석

CUDA에서 ROCm으로의 전환은 단순히 코드를 변환하는 기술적 문제를 넘어, 두 개의 거대한 컴퓨팅 생태계 중 하나를 선택하는 전략적 의사결정이다. 이 장에서는 하드웨어 아키텍처부터 개발자 도구에 이르기까지 두 생태계를 다각적으로 심층 비교 분석한다.

4.1 아키텍처 및 프로그래밍 모델

두 플랫폼은 근본적인 철학에서 차이를 보인다.

• CUDA: NVIDIA의 CUDA는 하드웨어, 드라이버, 컴파일러, 라이브러리가 긴밀하게 통합된 수직적, 폐쇄형(proprietary) 모델이다.1 이러한 접근 방식은 하드웨어와 소프트웨어 간의 최적화를 극대화하여 개발자에게 안정적이고 예측 가능한 고성능을 제공하는 강력한 장점을 가진다. 모든 것이 NVIDIA의 통제 하에 있으므로, 호환성 문제나 예기치 않은 버그가 발생할 확률이 상대적으로 낮다.

• ROCm: 반면, AMD의 ROCm은 리눅스 커널 드라이버부터 상위 레벨 라이브러리까지 거의 모든 구성 요소가 개방형(open-source)으로 제공되는 모듈식 플랫폼이다.2 이는 특정 벤더에 대한 기술적 종속을 피하고, 커뮤니티 기반의 개선과 높은 수준의 사용자 정의를 가능하게 한다는 점에서 매력적이다. 개발자는 필요에 따라 스택의 특정 부분을 수정하거나 대체할 수 있는 유연성을 갖는다.

• HIP 프로그래밍 모델: ROCm 생태계의 핵심은 HIP이다. HIP는 개발자가 단일 C++ 소스 코드를 작성하면, hipcc 컴파일러 래퍼가 컴파일 타겟에 따라 백엔드에서 NVIDIA의 nvcc 또는 AMD의 amdclang++를 호출하여 각 플랫폼에 맞는 바이너리를 생성하는 방식으로 동작한다.8 이는 CUDA 개발자들이 최소한의 학습 곡선으로 AMD 플랫폼에 진입할 수 있도록 설계된 전략적인 다리 역할을 한다.

4.2 성능 심층 분석: 하드웨어와 소프트웨어의 시너지

최신 AI 및 HPC 워크로드의 성능은 하드웨어의 이론적 성능과 이를 얼마나 효율적으로 활용하는 소프트웨어 스택의 시너지에 의해 결정된다.

4.2.1 최신 GPU 아키텍처 비교 (CDNA 3 vs. Hopper)

현재 데이터센터 시장의 주력 제품인 AMD Instinct MI300X (CDNA 3 아키텍처)와 NVIDIA H100 (Hopper 아키텍처)을 비교하면 각자의 강점이 명확히 드러난다.

• AMD Instinct MI300X (CDNA 3): 가장 두드러진 특징은 192GB에 달하는 방대한 HBM3 메모리 용량과 5.3 TB/s의 압도적인 메모리 대역폭이다.23 이는 수백억에서 수천억 개의 파라미터를 가진 거대 언어 모델(LLM)을 여러 GPU에 걸쳐 분할(model parallelism)하지 않고 단일 또는 소수의 GPU에 로드할 수 있게 해준다. 이는 추론 시 지연 시간(latency)을 줄이고 시스템 복잡성을 낮추는 데 결정적인 이점을 제공한다.6

• NVIDIA H100 (Hopper): 80GB의 HBM3 메모리를 탑재하여 MI300X보다 용량은 작지만, 4세대 텐서 코어(Tensor Core)와 Transformer 모델의 연산을 하드웨어 수준에서 가속하는 Transformer Engine과 같은 특화된 AI 가속 유닛을 갖추고 있다.1 또한, TensorRT-LLM과 같이 고도로 최적화된 추론 라이브러리를 통해 실제 애플리케이션에서 하드웨어의 잠재력을 극대화하여 높은 효율을 보여준다.23

4.2.2 표 3-1: AMD MI300X vs. NVIDIA H100 SXM 주요 제원 비교

두 플래그십 GPU의 핵심 하드웨어 사양을 비교하면, 성능 벤치마크 결과의 근본적인 원인을 이해하는 데 도움이 된다.

데이터 출처: 23

4.2.3 AI 워크로드 벤치마크 분석

• LLM 추론 (Inference): 벤치마크 결과는 워크로드의 특성에 따라 두 GPU의 우위가 달라짐을 보여준다. Mixtral 8x7B 모델 추론 벤치마크에 따르면, AMD MI300X는 매우 작은 배치 사이즈(1~4)와 매우 큰 배치 사이즈(256 이상)에서 NVIDIA H100 대비 더 높은 처리량(tokens/sec)과 비용 효율성(cost/token)을 보인다. 이는 MI300X의 넓은 메모리 대역폭이 단일 요청을 빠르게 처리하거나, 대용량 메모리가 많은 요청을 한 번에 처리하는 데 유리하기 때문이다. 반면, H100은 중간 크기(예: 32~128)의 배치 사이즈에서 더 강력한 성능을 보여주는데, 이는 텐서 코어와 최적화된 소프트웨어가 꾸준히 높은 연산 효율을 유지하기 때문이다.29

• LLM 학습 (Training): AI 모델 학습은 추론보다 훨씬 더 복잡한 연산과 GPU 간 통신을 요구한다. 현재까지는 NVIDIA가 이 분야에서 명백한 우위를 점하고 있다. 이는 성숙하고 고도로 최적화된 cuDNN(딥러닝 프리미티브) 및 NCCL(통신 라이브러리) 덕분이다.1 여러 분석에 따르면, AMD의 소프트웨어 스택(MIOpen, RCCL)은 아직 미성숙하여 MI300X 하드웨어의 막대한 이론적 연산 성능(TFLOPS)을 실제 학습 워크로드에서 완전히 활용하지 못하는 경향이 있다. 즉, 하드웨어의 잠재력 대비 실제 성능 달성률이 NVIDIA보다 낮게 나타난다.6

4.3 핵심 라이브러리 생태계 비교

소프트웨어 라이브러리는 GPU의 성능을 애플리케이션으로 전달하는 필수적인 통로이다. CUDA의 가장 큰 강점은 10년 이상 축적되어 온 방대하고 성숙하며 안정적인 라이브러리 생태계이다. ROCm은 이에 대응하는 라이브러리들을 대부분 갖추고 있지만, 기능의 폭, 성능, 안정성 면에서 아직 격차가 존재한다.

4.3.1 표 3-2: CUDA 라이브러리와 ROCm 대응 라이브러리 매핑

CUDA 개발자가 ROCm으로 전환할 때 필요한 라이브러리를 쉽게 찾고, 그 기능적 대응 관계와 주요 차이점을 이해하는 것은 매우 중요하다.

데이터 출처: 2

4.4 AI 프레임워크 통합 및 지원 현황

현대 AI 개발은 PyTorch, TensorFlow와 같은 고수준 프레임워크를 통해 이루어진다. 따라서 이들 프레임워크에 대한 지원 수준은 플랫폼의 실용성을 결정하는 핵심 요소이다.

• PyTorch: ROCm 지원이 공식 PyTorch 저장소에 업스트림되어 있어, 기술적으로 ’공식 지원’이 이루어지고 있다.36 하지만 실제 개발 현장에서는 두 가지 복잡성이 존재한다. 첫째, AMD가 유지하는 ROCm PyTorch 릴리스(최신 ROCm 기능 지원에 중점)와 PyTorch 커뮤니티의 공식 PyTorch 릴리스(최신 PyTorch 기능 지원에 중점)가 별도로 존재한다.36 이로 인해 개발자는 최신 ROCm 기능과 최신 PyTorch 기능을 동시에 사용하지 못하는 ‘버전 파편화’ 문제에 직면할 수 있다. 둘째, 최근 ROCm 6.4.4부터 Windows 환경에서의 PyTorch 지원이 추가되는 등 지원 범위가 빠르게 확대되고 있지만, 이는 아직 ‘미리보기(preview)’ 단계로 안정성 검증이 더 필요하다.37

• TensorFlow: TensorFlow 또한 공식적으로 ROCm을 지원하며, AMD는 버그 수정 및 최신 ROCm 지원을 위해 별도의 ROCm/tensorflow-upstream 저장소를 유지하고 있다.39 그러나 ROCm 환경에서 TensorFlow를 설치하고 사용하는 가장 안정적이고 권장되는 방법은 AMD가 제공하는 사전 빌드된 Docker 이미지를 사용하는 것이다.39 이는 호스트 시스템에 직접 설치할 경우 발생할 수 있는 복잡한 라이브러리 의존성 문제를 암시하며, CUDA 환경에서 pip install tensorflow-gpu 한 줄로 설치가 끝나는 간결한 경험과는 차이가 있다.

이러한 상황은 ROCm의 AI 프레임워크 지원이 ’공식 지원’이라는 표면적 사실 이면에, ’버전 파편화’와 ’최적화 지연’이라는 실질적인 도전과제를 안고 있음을 보여준다. 개발자는 CUDA 환경보다 더 높은 수준의 환경 설정 및 관리 부담을 감수해야 할 수 있으며, 특히 최신 소비자용 GPU(예: Radeon RX 7000 시리즈)에 대한 지원이 공식 프레임워크 빌드에는 즉시 포함되지 않아 사용자가 직접 소스에서 컴파일해야 하는 경우도 있다.41

4.5 개발자 경험: 도구 및 디버깅 환경

개발 생산성은 프로파일링 및 디버깅 도구의 품질에 크게 좌우된다.

• 프로파일링:

• NVIDIA: Nsight Systems (시스템 전체 동작 분석), Nsight Compute (커널 수준 심층 분석) 등 강력한 GUI 기반의 통합 프로파일링 도구 모음을 제공한다. 이들은 직관적인 시각화와 상세한 분석 데이터를 통해 병목 현상을 쉽게 식별할 수 있도록 돕는다.

• AMD: rocprof라는 커맨드 라인 기반 프로파일러를 제공한다.42 rocprof는 커널 실행 시간, 하드웨어 성능 카운터(PMC), API 호출 등을 트레이싱하여 CSV 파일로 출력하거나, Perfetto 또는 Chrome Tracing 형식의 JSON 파일을 생성하여 타임라인 기반으로 시각화할 수 있다.43 기능적으로는 매우 상세한 데이터를 수집할 수 있지만, Nsight 제품군이 제공하는 통합된 GUI 환경과 사용자 경험에는 아직 미치지 못한다는 것이 일반적인 평가이다.

• 디버깅:

• NVIDIA: cuda-gdb는 GDB를 확장하여 GPU 커널 내부를 디버깅할 수 있는 강력하고 성숙한 환경을 제공한다.

• AMD: ROCgdb는 GDB(GNU Debugger)의 확장으로, CPU 코드와 GPU 코드를 동일한 디버깅 세션 내에서 동시에 디버깅할 수 있는 이기종 디버깅 환경을 제공한다.46 개발자는 GPU의 웨이브프론트(wavefront) 단위로 중단점(breakpoint)을 설정하고, 코드를 한 줄씩 실행(single-step)하며, 레지스터와 메모리 값을 확인할 수 있다.48 다만, 초기 버전에서는 심볼릭 변수(소스 코드의 변수명) 디버깅과 같은 고급 기능 지원이 제한적이었으며, 지속적으로 기능이 개선되고 있다.50

5. 전략적 함의 및 미래 전망

ROCm과 CUDA의 경쟁은 단순한 기술 대결을 넘어, AI 및 HPC 인프라의 미래 방향성을 결정하는 중요한 전략적 의미를 지닌다.

5.1 개방형 생태계의 기회와 도전

• 기회: ROCm의 가장 큰 전략적 가치는 ’개방성’에 있다. 전체 소프트웨어 스택을 오픈소스로 제공함으로써, 특정 기업에 대한 기술적 종속을 피하고 장기적으로 총소유비용(TCO)을 절감할 수 있는 잠재력을 제공한다.4 특히, 자체적으로 소프트웨어 스택을 수정하고 최적화할 수 있는 역량을 갖춘 대규모 클라우드 기업이나 국립 연구소에게 이는 큰 매력이다. 또한, 학계 및 연구 기관에서 새로운 GPU 아키텍처를 탐구하고 하드웨어 수준의 혁신을 이루는 데 기여할 수 있다.5

• 도전: 반면, 개방형 생태계는 파편화(fragmentation)와 품질 관리의 어려움이라는 고질적인 문제를 안고 있다. 다양한 하드웨어, 운영체제, 라이브러리 버전의 조합 속에서 일관된 안정성과 성능을 보장하는 것은 매우 어려운 과제이다. 현재 ROCm의 소프트웨어 안정성, 문서의 완성도, 그리고 사용자 경험은 수십 년간 단일 기업의 통제 하에 발전해 온 CUDA에 비해 부족하다는 인식이 여전히 존재한다.6 이러한 ’소프트웨어의 격차’를 줄이기 위해서는 AMD의 지속적인 투자와 강력한 커뮤니티 거버넌스가 필수적이다.

5.2 시장 동향과 주요 기업의 선택

최근 데이터센터 GPU 시장은 NVIDIA의 독점에서 양강 구도로의 전환 가능성을 보이는 변곡점을 맞이하고 있다.

• 시장 점유율: 2023년까지 NVIDIA는 데이터센터 GPU 시장의 98%를 차지하며 사실상 독점적인 지위를 누렸다.52 그러나 2024년부터 AMD의 점유율이 의미 있는 수준으로 상승하기 시작했다. 생성 AI의 폭발적인 성장으로 인한 GPU 수요 급증과 NVIDIA H100의 공급 부족 현상이 맞물리면서, 대안을 찾던 시장의 수요가 AMD로 몰렸다.

• 하이퍼스케일러의 전략적 선택: 이러한 변화의 핵심 동력은 Microsoft, Meta, Oracle과 같은 대형 클라우드 기업들의 전략적 선택이다. 이들은 공급망 다변화를 통해 리스크를 분산하고, 경쟁 구도를 형성하여 GPU 구매 비용을 절감하고자 하는 경제적 동기를 가지고 있다.7 Omdia의 추정에 따르면, 2024년 Meta가 구매한 데이터센터 GPU의 43%, Microsoft가 구매한 GPU의 약 17%(1/6)가 AMD Instinct 제품이었다.53 특히 Meta는 자사의 Llama 3.1 405B 모델의 실시간 트래픽을 전적으로 AMD MI300X GPU로 처리하고 있다고 밝혔는데, 이는 MI300X의 대용량 메모리가 기술적으로 필수적이었음을 시사한다.52

• AMD의 가파른 성장: 시장의 이러한 변화에 힘입어 AMD의 데이터센터 GPU 사업은 가파른 성장세를 보이고 있다. AMD는 2024년 Instinct GPU 매출이 50억 달러에 이를 것으로 예상하며, 이는 전년 대비 폭발적인 성장이다.53 이는 AMD가 단순한 2위 공급자를 넘어, 시장의 주요 플레이어로 부상하고 있음을 보여주는 명백한 증거이다.

5.3 미래 기술 로드맵: 차세대 아키텍처 경쟁

GPU 시장의 경쟁은 멈추지 않고 차세대 아키텍처로 이어지고 있다.

• AMD: CDNA 3 아키텍처(MI300 시리즈)의 성공을 발판으로, 차세대 CDNA 4 아키텍처 기반의 MI350 시리즈를 발표했다. MI350 시리즈는 새로운 FP4 및 FP6 데이터 포맷 지원과 아키텍처 개선을 통해 AI 추론 성능을 이전 세대 대비 최대 35배까지 향상시키는 것을 목표로 한다.55

• NVIDIA: Hopper 아키텍처의 다음 세대인 **Blackwell (B100/B200)**을 이미 시장에 출시했으며, 그 이후의 로드맵으로 Rubin 플랫폼을 예고하며 기술 리더십을 유지하기 위한 빠른 혁신 주기를 이어가고 있다.57

향후 아키텍처 경쟁의 본질은 단순 연산 성능(TFLOPS)을 넘어, 변화하는 AI 모델(예: Mixture-of-Experts, AI 에이전트)에 최적화된 연산 능력, 에너지 효율성, 그리고 CPU와 GPU 간의 데이터 이동을 최소화하는 긴밀한 통합(예: AMD MI300A APU, NVIDIA Grace Hopper Superchip)이 핵심 경쟁 요소가 될 것이다.55

결론적으로, 현재 AI 가속기 시장은 ’NVIDIA 독점’에서 ‘NVIDIA 주도 하의 과점’ 체제로 전환되는 중요한 변곡점에 있다. 이 변화는 대규모 LLM이라는 새로운 기술적 요구사항과, 공급망 안정 및 비용 절감이라는 경제적 필요가 맞물려 하이퍼스케일러들의 전략적 선택에 의해 주도되고 있다. AMD는 MI300X의 압도적인 메모리 용량으로 이 기회를 성공적으로 포착했으며, 이는 향후 시장 경쟁을 더욱 가속화할 것이다.

6. 결론 및 권고 사항

6.1 종합 평가: CUDA의 견고한 성 vs. ROCm의 파상 공세

본 보고서의 심층 분석을 통해 CUDA와 ROCm 생태계는 각각 명확한 강점과 약점을 가지고 있음을 확인했다.

• CUDA의 강점: CUDA 생태계는 현재 시점에서 가장 안정적이고, 예측 가능하며, 개발 생산성이 높은 선택지이다. 10년 이상 축적된 방대한 라이브러리, 성숙한 개발 및 디버깅 도구, 풍부한 문서와 거대한 개발자 커뮤니티는 개발 과정에서 마주치는 문제를 해결하는 데 드는 시간을 크게 절약해준다. 특히 다양한 종류의 소규모 워크로드를 다루거나, 최신 AI 연구 논문의 코드를 즉시 재현하고 빠른 프로토타이핑이 중요한 환경에서 CUDA의 ‘그냥 작동하는(just works)’ 경험은 절대적인 강점이다.

• ROCm의 강점: ROCm 생태계는 하드웨어 성능, 특히 메모리 용량과 대역폭에서 NVIDIA의 최신 제품을 능가하며, 이를 바탕으로 특정 워크로드(대규모 LLM 추론)에서 명백한 총소유비용(TCO) 우위를 점하기 시작했다. 전체 스택이 오픈소스라는 점은 장기적인 관점에서 기술적 유연성을 확보하고 벤더 종속성을 탈피할 수 있는 중요한 전략적 가치를 제공한다. 하이퍼스케일러들의 대규모 채택은 ROCm 생태계의 미래 성장 가능성을 뒷받침하는 강력한 신호이다.

6.2 조직의 특성을 고려한 맞춤형 권고안

어떤 플랫폼을 선택할 것인가는 모든 조직에 동일하게 적용될 수 있는 단일 정답이 존재하지 않는다. 조직의 워크로드 특성, 내부 기술 역량, 그리고 장기적인 전략 목표에 따라 최적의 선택은 달라진다.

6.2.1 CUDA 유지 및 최적화가 유리한 경우:

• 다양한 워크로드를 다루는 연구 기관 및 중소기업: 특정 워크로드에 국한되지 않고 다양한 종류의 AI/HPC 애플리케이션을 실행해야 하는 환경에서는 광범위한 소프트웨어 호환성과 안정성을 제공하는 CUDA가 여전히 가장 효율적인 선택이다.

• 기존 CUDA 자산이 핵심인 조직: 개발팀의 CUDA 숙련도가 매우 높고, 수년간 축적된 방대한 CUDA 코드 자산을 최대한 활용해야 하는 경우, ROCm으로의 전환은 높은 비용과 위험을 수반할 수 있다.

• 최신 연구 동향의 빠른 도입이 중요한 경우: 대부분의 최신 AI 연구 논문과 오픈소스 프로젝트는 CUDA 기반으로 공개된다.1 이러한 코드를 즉시 재현하고 실험하는 것이 중요한 연구 개발 조직에게는 CUDA가 필수적이다.

6.2.2 ROCm으로의 단계적 전환을 고려할 만한 경우:

• 메모리 집약적 워크로드가 중심인 대규모 서비스 제공업체: 주요 워크로드가 대규모 LLM 추론/서비스와 같이 GPU 메모리 용량과 대역폭이 성능을 좌우하는 애플리케이션에 집중된 경우, AMD Instinct GPU는 TCO 측면에서 상당한 이점을 제공할 수 있다.

• 벤더 종속성 탈피가 전략적 목표인 기업: 장기적인 관점에서 특정 벤더에 대한 의존도를 낮추고, 공급망을 다변화하며, 인프라 비용 협상력을 높이고자 하는 전략적 목표를 가진 대기업 및 하이퍼스케일러에게 ROCm은 매력적인 대안이다.

• 높은 수준의 내부 기술 역량을 보유한 조직: ROCm의 오픈소스 특성을 최대한 활용하여 커널 수준의 튜닝, 소프트웨어 스택 수정, 소스 코드 직접 빌드 및 디버깅을 수행할 수 있는 높은 수준의 내부 기술 역량을 보유한 조직은 ROCm을 통해 경쟁사보다 높은 수준의 최적화를 달성할 수 있다.

6.3 성공적인 전환을 위한 전략 제안

ROCm으로의 전환을 결정한 조직이 위험을 최소화하고 성공 확률을 높이기 위해 다음과 같은 단계적 전략을 제안한다.

1. 점진적 파일럿 프로젝트 접근: 전체 인프라나 핵심 애플리케이션을 한 번에 전환하는 것은 매우 위험하다. hipify를 사용하여 상대적으로 중요도가 낮은 비핵심적인(non-critical) 애플리케이션부터 포팅을 시작하여, 전환 과정에서 발생할 수 있는 문제들을 파악하고 내부 경험과 기술 역량을 축적하는 ‘파일럿 프로젝트’ 전략을 권장한다.14

2. NVIDIA 플랫폼에서의 1차 포팅 및 검증: HIP 코드는 NVIDIA GPU에서도 hipcc를 통해 컴파일 및 실행이 가능하다. 따라서, 기존에 보유한 NVIDIA 인프라를 활용하여 CUDA에서 HIP로의 1차 포팅을 완료하고, 원본 CUDA 코드와의 성능 및 기능 비교 검증을 수행하는 것이 효율적이다. 이 단계에서 코드의 기능적 정확성을 확보한 후, AMD 플랫폼으로 옮겨 성능 최적화에 집중할 수 있다.8

3. 지속적인 교육 및 커뮤니티 참여: ROCm 생태계는 매우 빠르게 변화하고 발전하고 있다. 개발자들이 AMD의 공식 문서, 개발자 포럼, GitHub 저장소를 통해 최신 정보를 지속적으로 습득하고, 문제 해결 과정에서 오픈소스 커뮤니티에 적극적으로 질문하고 기여하도록 장려하는 문화가 중요하다.14

6.4 최종 전망

GPU 컴퓨팅 시장은 향후 몇 년간 NVIDIA와 AMD의 치열한 경쟁 속에서 더욱 역동적으로 발전할 것이다. ROCm이 단기간에 CUDA의 아성을 무너뜨리기는 현실적으로 어렵다. CUDA가 수십 년간 쌓아 올린 소프트웨어 생태계와 개발자 충성도는 쉽게 흔들리지 않을 것이다.

하지만 AMD는 하드웨어 혁신(특히 메모리)을 통해 AI 시장의 핵심적인 병목 지점을 성공적으로 공략했으며, 이를 바탕으로 시장의 가장 큰 고객인 하이퍼스케일러들의 신뢰를 얻는 데 성공했다. 이는 ROCm 생태계에 더 많은 투자와 개발자 참여를 유도하는 선순환 구조를 만들어낼 잠재력을 가지고 있다.

결론적으로, GPU 시장은 ’하나의 표준’이 지배하던 시대에서 벗어나, ’두 개의 강력한 생태계’가 특정 워크로드와 시장을 중심으로 경쟁하는 시대로 진입하고 있다. 이 건강한 경쟁은 기술 혁신을 가속화하고, 최종적으로는 개발자와 사용자 모두에게 더 많은 선택권과 더 나은 가치를 제공하게 될 것이다. 최종 승자는 하드웨어 성능, 소프트웨어 완성도, 그리고 개발자 생태계라는 세 가지 전장에서 모두 승리하는 자가 될 것이다.

7. 참고 자료

1. What are the main advantages of using NVIDIA’s CUDA over AMD’s ROCm for high-performance computing?, https://massedcompute.com/faq-answers/?question=What%20are%20the%20main%20advantages%20of%20using%20NVIDIA%27s%20CUDA%20over%20AMD%27s%20ROCm%20for%20high-performance%20computing?
2. What are the key differences between NVIDIA's CUDA and AMD's …, https://massedcompute.com/faq-answers/?question=What%20are%20the%20key%20differences%20between%20NVIDIA%27s%20CUDA%20and%20AMD%27s%20ROCm%20programming%20models?
3. ROCm vs CUDA: A Practical Comparison for AI Developers - SCIMUS, https://thescimus.com/blog/rocm-vs-cuda-a-practical-comparison-for-ai-developers/
4. What’s the Difference Between CUDA and ROCm for GPGPU Apps? | Electronic Design, https://www.electronicdesign.com/technologies/embedded/article/21254328/electronic-design-whats-the-difference-between-cuda-and-rocm-for-gpgpu-apps
5. AMD Talks ROCm: What It Is & Where It’s Going | TFN Extra Edition : r/AMD_Stock - Reddit, https://www.reddit.com/r/AMD_Stock/comments/1n76v31/amd_talks_rocm_what_it_is_where_its_going_tfn/
6. ROCm vs CUDA: A Performance Showdown for Modern AI Workloads - TensorWave, https://tensorwave.com/blog/rocm-vs-cuda-a-performance-showdown-for-modern-ai-workloads
7. Repeat after me: MI300X is not equivalent to H100, it’s a lot better! : r/AMD_Stock - Reddit, https://www.reddit.com/r/AMD_Stock/comments/19bf4mq/repeat_after_me_mi300x_is_not_equivalent_to_h100/
8. Application portability with HIP - AMD GPUOpen, https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-hipify-readme/
9. CASS: Nvidia to AMD Transpilation with Data, Models, and Benchmark - arXiv, https://arxiv.org/html/2505.16968v3
10. HIP porting guide - ROCm Documentation - AMD, https://rocm.docs.amd.com/projects/HIP/en/latest/how-to/hip_porting_guide.html
11. Porting CUDA to HIP » ADMIN Magazine, https://www.admin-magazine.com/HPC/Articles/Porting-CUDA-to-HIP
12. Using hipify-clang — HIPIFY Documentation - ROCm Documentation, https://rocm.docs.amd.com/projects/HIPIFY/en/latest/hipify-clang.html
13. Preparing code for GPU porting — GPU programming: why, when and how? documentation, https://enccs.github.io/gpu-programming/11-gpu-porting/
14. Transitioning from CUDA to ROCm: A Step-by-Step Guide - SCIMUS, https://thescimus.com/blog/transitioning-from-cuda-to-rocm/
15. Build HIP from source — HIP 7.1.0 Documentation - AMD ROCm documentation, https://rocm.docs.amd.com/projects/HIP/en/docs-develop/install/build.html
16. HIP compilers — HIP 6.2.41134 Documentation, https://rocm.docs.amd.com/projects/HIP/en/docs-6.2.4/understand/compilers.html
17. Compiler reference guide - AMD ROCm documentation, https://rocm.docs.amd.com/en/docs-6.0.2/reference/rocmcc.html
18. AMD HIP Programming Guide - GitHub, https://raw.githubusercontent.com/RadeonOpenCompute/ROCm/rocm-4.5.2/AMD_HIP_Programming_Guide.pdf
19. Accelerator and GPU hardware specifications - AMD ROCm documentation, https://rocm.docs.amd.com/en/latest/reference/gpu-arch-specs.html
20. Building HIP from Source - ROCm Documentation - AMD, https://rocm.docs.amd.com/projects/HIP/en/docs-5.7.0/developer_guide/build.html
21. Finding Numerical Differences Between NVIDIA and AMD GPUs This work was performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344 (LLNL-CONF-868447). - arXiv, https://arxiv.org/html/2410.09172v1
22. Limitations — HIP SDK installation (Windows), https://rocm.docs.amd.com/projects/install-on-windows/en/latest/reference/limitations.html
23. Comparison of the Latest AI Chips: NVIDIA H100, AMD MI300, Intel Gaudi3, and Apple M3, https://dolphinstudios.co/comparing-the-ai-chips-nvidia-h100-amd-mi300/
24. amd-cdna-3-white-paper.pdf, https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/white-papers/amd-cdna-3-white-paper.pdf
25. In Depth Benchmarking tests of AMD MX300 vs Nvidia H100 and H200 by SemiAnalysis, https://www.reddit.com/r/NVDA_Stock/comments/1hk9txw/in_depth_benchmarking_tests_of_amd_mx300_vs/
26. NVIDIA Hopper Architecture In-Depth | NVIDIA Technical Blog, https://developer.nvidia.com/blog/nvidia-hopper-architecture-in-depth/
27. AMD Instinct MI300X vs. NVIDIA H100 - TRG Datacenters, https://www.trgdatacenters.com/resource/mi300x-vs-h100/
28. How AMD’s MI300 Series May Revolutionize AI: In-depth Comparison with NVIDIA’s Grace Hopper Superchip - Reddit, https://www.reddit.com/r/Amd/comments/149dbpr/how_amds_mi300_series_may_revolutionize_ai/
29. AMD MI300X vs. Nvidia H100 SXM: Performance Comparison on …, https://www.runpod.io/blog/amd-mi300x-vs-nvidia-h100-sxm-performance-comparison
30. MI300X vs H100 vs H200 Benchmark Part 1: Training – CUDA Moat Still Alive - Reddit, https://www.reddit.com/r/AMD_Stock/comments/1hkasgk/mi300x_vs_h100_vs_h200_benchmark_part_1_training/
31. CuDNN vs Other Deep Learning Libraries - Which One Should You Choose for Optimal Performance? - MoldStud, https://moldstud.com/articles/p-cudnn-vs-other-deep-learning-libraries-which-one-should-you-choose-for-optimal-performance
32. Can cuDNN be used with AMD or Intel GPUs? - Massed Compute, https://massedcompute.com/faq-answers/?question=Can%20cuDNN%20be%20used%20with%20AMD%20or%20Intel%20GPUs?
33. 1월 1, 1970에 액세스, https.moldstud.com/articles/p-cudnn-vs-other-deep-learning-libraries-which-one-should-you-choose-for-optimal-performance
34. What is cuBLAS? Competitors, Complementary Techs & Usage - Sumble, https://sumble.com/tech/cublas
35. rocBLAS design and usage notes - AMD ROCm documentation, https://rocm.docs.amd.com/projects/rocBLAS/en/latest/how-to/what-is-rocblas.html
36. PyTorch compatibility — ROCm Documentation, https://rocm.docs.amd.com/en/latest/compatibility/ml-compatibility/pytorch-compatibility.html
37. ROCm 6.4.4: AMD’s Official PyTorch for Windows — See the Supported Radeon 9000/7000 GPUs & Ryzen AI APUs - Wccftech, https://wccftech.com/amd-rocm-6-4-4-pytorch-support-windows-radeon-9000-radeon-7000-gpus-ryzen-ai-apus/
38. AMD ROCm 6.4.4 Brings PyTorch Support On Windows For Radeon 9000, Radeon 7000 GPUs, & Ryzen AI APUs - Reddit, https://www.reddit.com/r/ROCm/comments/1npn4as/amd_rocm_644_brings_pytorch_support_on_windows/
39. TensorFlow compatibility — ROCm Documentation, https://rocm.docs.amd.com/en/latest/compatibility/ml-compatibility/tensorflow-compatibility.html
40. How to Install TensorFlow with ROCm Acceleration on Ubuntu 24.04 | Vultr Docs, https://docs.vultr.com/how-to-install-tensorflow-with-rocm-acceleration-on-ubuntu-24-04
41. Minimal requirements for ROCm support of AMD GPUs - Reddit, https://www.reddit.com/r/ROCm/comments/1ahcf38/minimal_requirements_for_rocm_support_of_amd_gpus/
42. Introduction to ROC-Profiler (rocprof), https://462000265.lumidata.eu/4day-20241028/files/LUMI-4day-20241028-3_09_Introduction_to_Rocprof_Profiling_Tool.pdf
43. ROC-profiler and debugger: An Overview of AMD ROCmTM Tools, https://extremecomputingtraining.anl.gov/wp-content/uploads/sites/96/2022/11/ATPESC-2022-Track-6-Talk-4-Tandon-AMD.pdf
44. rocprofiler Documentation, https://rocm.docs.amd.com/_/downloads/rocprofiler/en/latest/pdf/
45. rocprof — ROC Profiler Documentation - AMD ROCm documentation, https://rocm.docs.amd.com/projects/rocprofiler/en/docs-5.1.3/
46. ROCgdb 16.3 Documentation - AMD ROCm documentation, https://rocm.docs.amd.com/projects/ROCgdb/en/latest/
47. ROCgdb 1.2.12 Documentation - AMD ROCm documentation, https://rocm.docs.amd.com/projects/ROCgdb/en/docs-6.3.1/
48. Debugger tutorial — ROCgdb 1.2.11 Documentation, https://rocm.docs.amd.com/projects/ROCgdb/en/docs-6.1.5/tutorials/tutorial.html
49. HIP Training Workshop – Day 3 - ROCgdb & HIP math libraries Justin Chang, https://www.olcf.ornl.gov/wp-content/uploads/2021/04/rocgdb_hipmath_ornl_2021_v2.pdf
50. ROCm/ROCdbgapi: The AMD Debugger API is a library that provides all the support necessary for a debugger and other tools to perform low level control of the execution and inspection of execution state of AMD’s commercially available GPU architectures. - GitHub, https://github.com/ROCm/ROCdbgapi
51. ROCgdb Documentation, https://rocm.docs.amd.com/_/downloads/ROCgdb/en/latest/pdf/
52. 5 REASONS TO CHOOSE AMD INSTINCT™ GPUS OVER NVIDIA GPUs, https://www.amd.com/content/dam/amd/en/documents/partner-hub/instinct/instinct-over-nvidia.pdf
53. AMD Instinct, cloudy silicon vie for a slice of Nvidia’s pie - The Register, https://www.theregister.com/2024/12/23/nvidia_ai_hardware_competition/
54. 1월 1, 1970에 액세스, https.www.theregister.com/2024/12/23/nvidia_ai_hardware_competition/
55. AMD Instinct MI350 Series GPUs: A Game Changer for Inference, Training and HPC Workloads, https://www.amd.com/en/blogs/2025/amd-instinct-mi350-series-game-changer.html
56. advancing-ai-2025-distribution-deck.pdf - AMD, https://www.amd.com/content/dam/amd/en/documents/corporate/events/advancing-ai-2025-distribution-deck.pdf
57. Roadmap: GPU Migration and Portability - Cornell Virtual Workshop, https://cvw.cac.cornell.edu/gpu-migration-portability
58. GTC March 2025 Keynote with NVIDIA CEO Jensen Huang - YouTube, https://www.youtube.com/watch?v=_waPvOwL9Z8