엔비디아 GPU를 전제로 만들어진 CUDA 소프트웨어를 AMD 그래픽카드에서 구동하려는 시도는 오래된 숙제였다. 'CUDA-for-AMD-Windows'라는 이름으로 공개된 이 프로젝트는 ZLUDA와 AMD의 HIP/ROCm 런타임을 조합해, 윈도우 환경에서 CUDA를 대상으로 작성된 컴퓨트 애플리케이션을 AMD GPU 위에서 돌릴 수 있도록 재현 가능한 설치 스택을 정리한 것이다. 특히 CUDA를 사용하는 LibTorch 기반 학습 워크로드를 실제 동기로 삼아 만들어졌다는 점에서, 단순 데모가 아니라 딥러닝 실무 시나리오를 겨냥하고 있다.
동작 방식의 핵심은 ZLUDA라는 호환 계층이다. ZLUDA는 CUDA API 호출을 가로채 AMD의 HIP/ROCm 런타임 위에서 실행되도록 매핑한다. 프로젝트가 제공하는 런처는 실행 시점에 필요한 ZLUDA 호환 DLL들을 대상 애플리케이션 옆에 배치하고, 해당 실행에 맞는 HIP/ROCm 런타임 경로를 설정한다. 사용자는 최신 AMD GPU 드라이버와 윈도우용 AMD HIP SDK를 HIP 라이브러리와 함께 설치하면 된다. 검증에 사용된 기준 버전은 HIP SDK 6.4이며, 그보다 새로운 버전은 동작할 수 있으나 별도 보고가 있기 전까지는 미검증으로 취급된다.
검증된 범위와 그 경계
중요한 것은 이 프로젝트가 무엇을 보장하고 무엇을 보장하지 않는지를 스스로 명확히 구분한다는 점이다. 현재 실제로 검증된 하드웨어는 AMD Radeon RX 9060 XT(gfx1200) 한 종뿐이다. 다른 AMD 카드는 후보일 뿐 동작이 보장되지 않는다. 함께 제공되는 GPU 스캐너는 모델명, gfx 아키텍처, 드라이버와 HIP 정보를 기록하고, 윈도우 HIP 아키텍처 계열을 인식하더라도 이를 '지원'으로 단정하지 않고 '미검증 후보'로 표시한다. 하드웨어가 감지된다는 사실이 곧 특정 워크로드가 돌아간다는 증거는 아니라는 것이다. 스캐너는 사용자명이나 토큰, 개인 파일을 의도적으로 수집하지 않는다고 밝히고 있다.
공개된 검증 경로는 사적으로 복구한 DLL 없이 순수하게 상위 업스트림 구성요소만으로 테스트를 통과했다. 다만 개발자는 이것이 '모든 CUDA 프로그램이나 AI 모델이 동작한다'는 뜻이 아님을 반복해서 강조한다. CUDA API와 라이브러리 커버리지는 워크로드에 따라 크게 달라진다.
cuDNN이라는 현실적 장벽
실무자가 가장 먼저 부딪히는 한계는 라이브러리 지원 범위다. 안정판 윈도우 HIP SDK에는 MIOpen을 비롯한 ROCm의 AI 라이브러리 스택 전체가 포함되지 않는다. 따라서 cuDNN을 요구하는 합성곱(convolution) 중심 소프트웨어는 더 새롭거나 나이틀리 버전의 HIP 스택, 혹은 추가 작업이 필요할 수 있다. 반대로 밀집 행렬 연산, 즉 GEMM 위주의 LibTorch 학습은 cuDNN이 반드시 필요하지는 않으며, 실제로 검증에 쓰인 PPO 강화학습 워크로드는 cuDNN 없이 완료됐다. 다시 말해 이미지 인식처럼 컨볼루션이 무거운 작업과 완전연결·행렬곱 위주의 작업 사이에는 지금 이 스택으로 넘을 수 있는 선이 뚜렷이 갈린다.
성능 측면에서는 통제된 비교 실험 데이터가 흥미롭다. 2026년 9월 13일 동일한 RX 9060 XT PPO 워크로드에서 런타임별로 10회씩 반복 실행하고 각 시행의 첫 반복을 웜업으로 제외한 결과, 공개 업스트림 경로는 초당 스텝 수(SPS) 중앙값 13,278을 기록했고 복구한 커스텀 오버레이는 12,876에 그쳤다. 커스텀 오버레이가 약 3.03% 느렸던 셈이다. 이 때문에 프로젝트는 업스트림 경로를 기본값으로 유지한다. 참고로 과거의 튜닝된 실행은 다른 학습 설정에서 약 7만~10만9천 스텝/초에 이르렀다고 하는데, 설정 자체가 달라 직접 비교 대상은 아니다.
초기 개발 환경에서 실험했던 커스텀 cuBLAS/cuBLASLt/HIP 오버레이는 공개 검증 경로에 필요하지 않으며, 위의 A/B 결과로 보면 현재 기준 워크로드에서는 성능 이득도 아니다. 복구한 DLL들은 manifests 폴더에 해시로 지문만 남겨두고 바이너리로 배포하지는 않는데, 원본 래퍼의 소스와 출처가 불완전하고 복구된 HIP 런타임에 제3자인 AMD 바이너리가 포함돼 있다는 라이선스·제공 이력 문제 때문이다.
실무자에게 주는 의미
이 프로젝트의 가치는 성능 수치 자체보다 태도에 있다. 검증된 하드웨어 한 종, 검증된 SDK 버전, cuDNN 유무에 따른 동작 여부, 통제된 벤치마크의 원자료까지 문서로 분리해 두고, 감지와 실제 구동을 혼동하지 않도록 반복해서 못을 박는다. AMD GPU로 CUDA 워크로드를 옮기려는 실무자라면, 자신의 작업이 컨볼루션 의존적인지 GEMM 중심인지부터 판별하는 것이 현실적인 첫 단계다. 라이선스 역시 프로젝트 소유 스크립트와 문서는 MIT지만 ZLUDA, ROCm/HIP, CUDA 구성요소, PyTorch/LibTorch는 각자의 상위 라이선스를 따르므로 배포나 상용 활용 전에 확인이 필요하다. 새 카드나 실패 사례를 테스트했다면 결과와 첫 오류 출력을 담아 GPU 호환성 보고를 남기는 것이 이 생태계가 커지는 방식이며, 실패한 테스트도 그 자체로 데이터가 된다.