CUDA 코드를 AMD로 옮겼다면, 속도도 같아질까요?

예산 안에서 메모리가 넉넉한 Radeon 구성을 찾았는데, 꼭 써야 하는 로컬 이미지 처리 앱의 설치 안내에는 CUDA만 보인다면 어떻게 해야 할까요? “코드를 AMD용으로 옮기면 속도도 그대로 나올까?”가 자연스러운 다음 질문입니다. 소스가 HIP³ 형태로 바뀌고 로그에 GPU⁴ 이름이 찍혀도 포팅이 끝난 것은 아닙니다. 프로그램이 실행되는 것, 올바른 결과를 내는 것, 긴 세션에서도 안정적인 것, 원래 CUDA 구성과 비슷한 시간에 끝나는 것은 각각 따로 확인해야 합니다. 이 글은 그 Radeon을 사기 전에 앱의 공식 실행 경로부터 실제 작업 비교까지 점검하는 순서를 따라갑니다.

첫 단계는 포팅 도구를 알아보기 전에 앱이 공식 지원하는 실행 경로를 확인하는 것입니다. GPU를 사기 전에 프로젝트의 설치 문서, 릴리스 파일, issue나 지원 목록에서 ROCm/HIP 빌드가 있는지 찾습니다. “CUDA 지원”만 적혀 있다면 그것을 AMD 지원으로 해석할 수 없습니다. HIP은 CUDA와 비슷한 GPU 프로그래밍 API⁵를 제공하고 HIPIFY는 소스의 일부 호출을 대응하는 HIP 형태로 바꾸는 데 도움을 줍니다. 하지만 한 앱이 ROCm⁶용으로 패키지된 버전을 제공하는지, 아니면 사용자가 소스부터 직접 포팅해야 하는지에 따라 필요한 시간과 검증 범위가 크게 달라집니다. 소비자 입장에서는 공식 바이너리나 공식 설치 경로가 있는지 먼저 확인하는 것이 구매 위험을 줄이는 현실적인 출발점입니다.

가령 로컬 이미지 처리 도구가 CUDA 빌드만 제공하고, 사용자는 비슷한 구성을 Radeon에서 쓰고 싶다고 해보겠습니다. 저장소에서 실행 코드만 HIPIFY 했다고 완성된 AMD 앱이 되는 것은 아닙니다. 프로젝트는 GPU 작업을 어떻게 잘라 여러 작업단위로 보내는지, 입력과 중간 결과를 어디에 두는지, 메모리를 언제 복사하거나 재사용하는지 결정합니다. 여기에 cuBLAS 같은 CUDA 라이브러리를 호출한다면 대응 라이브러리와 함수 동작을 확인해야 합니다. 자동 변환기가 함수 이름을 바꿔도 성능에 영향을 주는 실행 단위 크기, 데이터 배치, 동기화 시점, 라이브러리 알고리즘을 자동으로 최적화하지는 않습니다. 컴파일이 성공했다는 사실만으로 속도까지 보장되지 않는 이유입니다.

먼저 정확성을 따로 확인해야 합니다. 같은 입력 파일을 양쪽에서 처리했을 때 출력이 애플리케이션의 허용 오차 안에 있는지 봅니다. 부동소수점 연산은 실행 순서나 커널 구현에 따라 마지막 몇 자리에서 차이가 날 수 있으므로, 비트 단위로 같은 출력이 항상 요구되는지 아니면 지정된 오차 범위면 충분한지 프로그램의 목적을 기준으로 정합니다. 이미지 생성이라면 같은 씨드와 설정을 맞췄더라도 모든 GPU에서 픽셀이 완전히 같다고 가정하지 말고, 앱이 기대하는 품질 기준과 실패 유형을 비교해야 합니다. 이 단계에서 결과가 틀린다면 속도 비교는 의미가 없습니다.

다음은 실행 안정성입니다. 앱이 작은 입력 한 장을 처리했다고 긴 세션에서도 안전하다는 뜻은 아닙니다. 대표 이미지를 저장해 같은 파일을 반복 처리하고, 앱을 닫았다가 새로 시작한 뒤에도 같은 결과 흐름이 재현되는지 확인합니다. 모델이나 이미지 크기를 한 번에 크게 바꾸지 말고 평소 쓸 해상도까지 단계적으로 올리세요. 메모리 사용이 계속 쌓이는지, 큰 입력에서만 오류가 나는지, 종료 뒤 자원이 반환되는지도 살핍니다. 모델 파일과 정밀도, 이미지 해상도, 함께 열어 둘 앱을 실제 사용 조건에 맞춰 고정하면 한 번의 우연한 성공과 반복 가능한 세션을 구분하기 쉽습니다.

그 다음에야 성능을 비교할 수 있습니다. NVIDIA CUDA와 AMD ROCm은 같은 PyTorch⁷ API 이름이나 비슷한 소스 코드를 사용하더라도 다른 런타임⁸과 라이브러리, 커널 구현으로 GPU를 실행합니다. 그래서 코드 줄 수가 비슷하거나 변환이 짧았다는 사실은 실행 시간이 같다는 증거가 아닙니다. 새 하드웨어를 사기 전에 조건을 먼저 적어 둡니다. 같은 이미지 입력, 출력 해상도와 처리 단계, 앱 버전과 품질 기준을 유지해야 합니다. GPU 메모리가 부족해 한쪽만 CPU⁹ 오프로딩¹⁰을 한다면 그 설정도 기록하고, 그것이 실제 사용할 구성인지 판단해야 합니다.

시간도 무엇을 포함하는지 나눕니다. 앱이 모델 파일을 읽고 준비하는 데 걸리는 시간과, 준비된 상태에서 이미지를 처리하는 시간은 다를 수 있습니다. 사용자가 실제로 기다리는 것은 실행 버튼을 누른 순간부터 결과 파일을 저장할 때까지일 수도 있습니다. 준비 시간, 첫 이미지, 반복 이미지, 저장을 포함한 전체 완료 시간을 구분해 기록하세요. 같은 이미지를 여러 번 처리해 비교하면 캐시된 세션에서만 빠른지, 매번 모델을 준비해야 하는 환경에서도 쓸 만한지 판단할 수 있습니다. 어느 쪽을 비교했는지 남겨야 숫자가 구매 후의 사용 경험과 연결됩니다.

공개 벤치마크가 빠른 구성도 내 구매 판단을 대신하지 않습니다. 앱이 다른 버전이거나 GPU 메모리를 쓰는 방식, 결과 품질 기준이 다르면 숫자를 내 작업에 그대로 적용할 수 없습니다. 드라이버와 ROCm 버전도 결과에 영향을 줄 수 있고, 메모리 부족 시 한 앱은 멈추고 다른 앱은 CPU로 일부 작업을 옮길 수 있습니다. 평소 쓰려는 이미지 작업과 같은 설정으로 확인해야 비교 결과가 구매 선택에 도움이 됩니다.

무엇을 시험할지 모르겠다면 앱이 남기는 실행 로그를 이용할 수 있습니다. 로그에 HIP 런타임 또는 AMD GPU가 보이면 어떤 경로로 실행했는지 파악하는 단서가 됩니다. 다만 이런 기록은 장치 탐지나 런타임 초기화가 성공했다는 의미일 수 있으며, 앱 전체가 정상적으로 동작하거나 GPU를 충분히 활용한다는 보장은 아닙니다. 상세 로그에서 모델 초기화, 메모리 할당, 커널 실행, 결과 저장이 모두 끝났는지 확인합니다. 프로그램이 공식적으로 ROCm 빌드를 제공하지 않는다면, 커뮤니티에서 변환한 실행 파일은 업데이트와 오류 대응 책임이 달라진다는 점도 감안해야 합니다.

비교 메모에는 GPU 모델, OS 빌드, 드라이버·ROCm 버전, 앱 릴리스, 같은 입력 이미지, 출력 해상도와 처리 단계, 품질 기준을 기록하고 설정 파일과 결과 이미지, 로그를 보관합니다. 비교 도중 앱이나 모델을 업데이트했다면 새 시험으로 구분하세요. 기존 CUDA PC와 Radeon 후보를 번갈아 테스트할 때는 같은 파일과 설정을 사용하고, 새 세션에서 모델 초기화, 첫 처리, 반복 처리, 결과 저장 시간을 따로 구분합니다. 이 구분으로 첫 로딩에만 차이가 나는지 반복 작업에서도 차이가 지속되는지 판단할 수 있습니다. 오류 재현 정보와 결과 품질도 함께 남기면 성능뿐 아니라 안정성까지 나란히 검토할 수 있습니다. 전력 제한이나 주변 작업이 달라졌다면 함께 적어 두어 같은 테스트 조건인지 되돌아볼 수 있게 하세요.

시간을 기록할 때는 화면의 첫 진행 표시만 재지 말고 앱이 완료를 알리고 파일을 저장할 때까지의 기준을 정합니다. GPU 작업이 비동기로 큐에 들어가는 앱은 버튼을 누른 순간과 계산 완료 시점이 다를 수 있으므로 앱이 제공하는 완료 로그나 저장된 출력 시각을 같이 봅니다. 두 컴퓨터에서 같은 준비 상태를 만들고 반복한 값의 편차도 확인하면, 한 번의 우연한 캐시나 백그라운드 작업이 구매 결론을 좌우할 가능성이 줄어듭니다.

구매 판단에 필요한 것은 변환 가능한 코드가 아니라 내가 사용할 바로 그 앱의 확인 가능한 AMD 경로입니다. 공식 ROCm 빌드가 있으면 해당 문서의 GPU·OS·드라이버·ROCm·프레임워크 조합을 맞추고, 대표 이미지 작업을 저장·재시작까지 반복해 보세요. 소스만 공개돼 있다면 HIPIFY가 바꿔 준 부분을 검토하고, 정확성·안정성·성능을 확인하고 이후 AMD 환경을 유지할 사람이 누구인지 판단해야 합니다. 포팅된 앱이 한 번 켜졌다는 이유로 CUDA 구성과 같은 속도를 기대할 수는 없습니다. 공식 AMD 경로가 없고 직접 변환과 검증을 맡을 계획도 없다면, 그 앱을 쓰기 위해 해당 GPU를 선택하는 판단은 보류하는 것이 현실적입니다.

관련 배경은 안될공학의 CUDA 영상에서 볼 수 있습니다. 포팅 단계와 API 차이를 실제 프로젝트에 적용할 때는 영상과 별개로 AMD의 HIP 포팅 가이드와 HIPIFY 문서를 기준으로 확인하세요.