Windows에서 AMD용 CUDA가 작동하지만, 제한적인 호환성 경로를 통해서만 가능

CUDA가 여전히 NVIDIA 플랫폼인 상황에서도, AMD 사용자는 이제 Windows에서 재현 가능한 AMD용 CUDA 환경을 구성할 수 있다. 이 커뮤니티 프로젝트는 선택된 CUDA 호출을 ZLUDA를 통해 변환한 뒤 AMD의 HIP 라이브러리로 실행한다. 제작자는 Radeon RX 9060 XT에서 하나의 AI 학습 워크로드를 완료했다고 보고했다.

이 성과가 중요한 이유는 난도가 높은 경계를 넘었기 때문이다. 개발자는 NVIDIA의 소프트웨어 스택을 위해 구축된 Windows 애플리케이션을 시작해, 지원되는 AMD 구성 하나에서 실행할 수 있다. 먼저 해당 애플리케이션을 HIP용으로 다시 작성할 필요는 없다.

다만 이 결과가 CUDA를 하드웨어 중립적으로 만드는 것은 아니다. 이 구성은 호환성 계층, 고정된 소프트웨어 버전, 불완전한 라이브러리 대체에 의존한다. 현재 프로젝트에서 검증 상태를 받은 GPU 모델도 하나뿐이다.

따라서 실제 경쟁은 단순히 AMD와 NVIDIA 하드웨어의 대결이 아니다. 기존 CUDA 애플리케이션과의 호환성, 그리고 네이티브 벤더 지원의 신뢰성 간 경쟁이다. 새 구성은 전자를 진전시키지만 후자를 제공하지는 않는다.

이 프로젝트는 CUDA 바이너리를 AMD 워크로드로 전환한다

핵심 변화는 CUDA를 대상으로 하는 Windows 애플리케이션에서 AMD GPU로 이어지는 문서화되고 재현 가능한 경로가 마련됐다는 점이다.

오픈소스 호환성 프로젝트는 설치, 런타임 스테이징, 진단 및 검증 스크립트를 패키징한다. 새로운 GPU 런타임을 처음부터 구현하는 대신 ZLUDA와 AMD의 Windows HIP 소프트웨어를 기반으로 한다.

ZLUDA는 애플리케이션에 CUDA 호환 인터페이스를 제공하는 변환 계층이다. 지원되는 작업을 호스트 GPU 스택에서 이용 가능한 대응 기능으로 리디렉션한다.

HIP(Heterogeneous-compute Interface for Portability)은 이식 가능한 GPU 소프트웨어를 위한 AMD의 C++ 런타임 및 커널 언어다. 이 구성에서 HIP는 궁극적으로 Radeon GPU와 통신하는 하위 계층을 제공한다.

이 경로는 NVIDIA CUDA 구성 요소를 예상하는 Windows 프로그램에서 시작된다. ZLUDA가 해당 호출을 받아 지원되는 라이브러리 작업을 AMD 대응 기능으로 연결한다.

예를 들어 cuBLAS 작업은 rocBLAS에 도달할 수 있고, cuSPARSE 호출은 rocSPARSE에 연결될 수 있다. 이 라이브러리들은 일반적인 선형대수 및 희소 행렬 워크로드를 처리한다.

저장소에는 감지된 GPU, 드라이버, HIP SDK 및 필요한 수학 라이브러리를 점검하는 PowerShell 설치 관리자가 포함돼 있다. 이어 고정된 ZLUDA 빌드를 다운로드하고 SHA-256 해시로 내려받은 파일을 검증한다.

설치 관리자는 CUDA 11.8용으로 빌드된 LibTorch 2.3.0도 가져올 수 있다. LibTorch는 Python 런타임 없이 애플리케이션이 PyTorch 기능을 내장할 때 사용되는 PyTorch의 C++ 배포판이다.

저장소에 따르면 해당 다운로드 용량은 약 2.66GB다. LibTorch가 필요하지 않은 사용자는 이를 건너뛸 수 있다.

설치 후 스크립트는 머신별 런타임 및 GPU 보고서를 생성한다. 또 다른 진단은 설치된 AMD 스택을 대상으로 ZLUDA의 cuda_check 유틸리티를 실행한다.

애플리케이션을 실행하려면 프로젝트의 래퍼 스크립트가 필요하다. 이 스크립트는 대상 실행 파일 옆에 필요한 호환성 라이브러리를 배치하고, 해당 프로세스를 위한 HIP 런타임 경로를 구성한다.

이 로컬 스테이징 모델은 시스템 전반의 변경을 제한한다. 동시에 핵심적인 약점도 드러낸다. 각 애플리케이션은 여전히 ZLUDA가 변환할 수 있는 정확한 CUDA 함수와 라이브러리에 의존한다.

프로젝트는 CUDA 드라이버 인터페이스, cuBLAS, cuBLASLt, cuSPARSE 및 cuFFT에서 성공적인 검사를 보고했다. 이 결과는 검증된 해당 머신 및 소프트웨어 조합에 적용된다.

이는 Windows 애플리케이션 전반의 일반적인 호환성을 입증하지는 않는다. 프로그램은 기본 런타임 검사를 통과한 뒤에도 다른 워크로드에서 지원되지 않는 함수에 도달할 수 있다.

저장소는 AMD의 gfx1200 타깃으로 식별되는 Radeon RX 9060 XT만 검증 기준 상태를 보유한다고 명시한다. 감지된 다른 Radeon 아키텍처는 여전히 검증되지 않은 후보로 남아 있다.

이 표현은 중요하다. 감지는 스크립트가 장치와 아키텍처를 인식한다는 뜻이다. 애플리케이션, 변환 계층 및 라이브러리가 함께 작동한다는 뜻은 아니다.

지금 Windows에서 AMD용 CUDA가 중요한 이유

이 프로젝트가 겨냥하는 것은 CUDA의 소유권이나 NVIDIA의 하드웨어 우위가 아니라 CUDA 애플리케이션 주변의 마이그레이션 비용이다.

CUDA는 NVIDIA의 병렬 컴퓨팅 플랫폼이자 프로그래밍 모델이다. 그 프로그래밍 모델은 커널 실행, 메모리 관리, 동기화 및 NVIDIA GPU에 최적화된 라이브러리를 다룬다.

많은 애플리케이션은 CUDA 스타일 소스 코드 이상에 의존한다. cuBLAS, cuFFT, cuSPARSE, cuDNN 같은 라이브러리를 호출하며 특정 런타임 동작에 의존한다.

축적된 이 소프트웨어는 전환 비용을 만든다. 다른 GPU를 구매한다고 해서 CUDA를 대상으로 한 Windows 프로그램이 자동으로 이식 가능한 것은 아니다.

개발자에게는 일반적으로 세 가지 큰 선택지가 있다. NVIDIA 하드웨어를 계속 사용하거나, 프로그램을 다른 인터페이스로 포팅하거나, 애플리케이션과 하드웨어 사이에 변환 계층을 둘 수 있다.

AMD는 HIP를 통해 포팅 경로를 지원한다. AMD의 HIPIFY 도구는 많은 CUDA 소스 구문을 이식 가능한 HIP C++로 변환한다.

개발자가 애플리케이션을 통제할 수 있다면 소스 변환은 장기적으로 타당한 선택이 될 수 있다. 하지만 테스트와 유지 관리가 필요하며, 지원되지 않는 API 주변에서는 수동 변경이 필요할 때도 있다.

이 경로는 컴파일된 Windows 바이너리만 가진 사용자에게는 거의 도움이 되지 않는다. CUDA 전용 종속성을 유지하는 소규모 팀에도 작업 부담을 만든다.

ZLUDA는 그 공백을 겨냥한다. 런타임에서 작업을 변환하면서 애플리케이션이 기대하는 CUDA 대응 인터페이스를 유지하려 시도한다.

이 접근 방식은 새로운 프로그래밍 표준이라기보다 호환성 브리지에 가깝다. 애플리케이션은 계속 CUDA를 사용하고, 브리지는 지원되는 요청을 AMD의 소프트웨어 스택으로 매핑한다.

Windows에서는 이 문제가 특히 중요하다. AMD는 이 환경에서 GPU 컴퓨팅 지원을 확대해 왔지만, Windows 스택은 역사적으로 Linux의 ROCm보다 적은 구성 요소를 제공해 왔다.

AMD는 Windows HIP SDK를 더 광범위한 ROCm 플랫폼의 하위 집합으로 설명한다. 지원 매트릭스 역시 공식 지원 범위를 나열된 운영체제와 GPU로 제한한다.

최근 ROCm 릴리스는 특정 Radeon 하드웨어에서의 PyTorch 지원을 포함해 네이티브 Windows 선택지를 개선했다. 애플리케이션이 이미 AMD 경로를 제공한다면 네이티브 지원은 변환의 필요성을 줄인다.

하지만 네이티브 PyTorch 지원이 모든 CUDA 종속성을 해결하는 것은 아니다. Windows 애플리케이션은 CUDA 전용 LibTorch 빌드를 번들로 포함하거나 NVIDIA 라이브러리를 직접 로드할 수 있다.

새 저장소는 이처럼 덜 편리한 상황을 다룬다. 명시된 동기는 AMD 데스크톱 GPU에서 실행해야 했던 CUDA 대응 LibTorch 학습 애플리케이션이었다.

프로젝트는 테스트 애플리케이션이 추론, 강화학습 업데이트 및 옵티마이저 작업을 완료했다고 보고했다. 네트워크는 2,216,347개의 파라미터로 구성됐으며, 65,536개 타임스텝을 포괄하는 검증 반복을 한 번 실행했다.

이 수치는 합성 API 프로브가 아닌 실제 워크로드 하나를 설명한다. 단순히 애플리케이션 창만 실행하는 런처보다 프로젝트에 더 큰 신뢰성을 부여한다.

그럼에도 테스트 범위는 좁다. 비교적 작은 강화학습 네트워크 하나가 모든 트랜스포머, 이미지 생성기, 과학 시뮬레이션 또는 렌더링 파이프라인을 대표할 수는 없다.

개발 압력은 AMD의 Windows 소프트웨어 경험에 가장 직접적으로 작용한다. 호환성 실험이 성공할 때마다 여전히 CUDA를 전제로 하는 애플리케이션 수요가 부각된다.

NVIDIA도 다른 종류의 압력에 직면한다. 변환 계층은 CUDA 애플리케이션 기반 중 얼마나 많은 부분이 다른 런타임이 재현할 수 있는 핵심 인터페이스에 의존하는지 시험한다.

어느 쪽의 압력도 즉각적인 플랫폼 전환을 만들지는 않는다. 다만 개발자들이 벤더 종속적인 애플리케이션 경계를 우회할 방법을 계속 찾고 있음을 보여준다.

이 메커니즘은 API를 보존하지만 전체 CUDA 플랫폼을 보존하지는 않는다

ZLUDA는 선택된 인터페이스를 변환할 수 있지만, CUDA 애플리케이션은 흔히 그 인터페이스를 훨씬 넘어서는 동작에 의존한다.

CUDA 애플리케이션은 일반적으로 CPU에서 실행되는 호스트 코드와 GPU에서 수행되는 디바이스 작업으로 구성된다. 호스트는 메모리를 할당하고, 데이터를 전송하며, 커널을 실행한다.

바이너리는 최적화된 라이브러리도 호출할 수 있다. 이 라이브러리들은 AI 또는 과학 애플리케이션이 유의미한 속도로 작동하는지를 좌우하는 경우가 많다.

ZLUDA는 CUDA 대응 구성 요소의 대체물을 제공하고 이를 비NVIDIA 백엔드에 연결한다. AMD 하드웨어에서는 이 백엔드가 HIP와 ROCm 라이브러리를 사용한다.

이 모델은 프로그램이 구현된 런타임 함수와 매핑된 라이브러리 범위 안에 머무를 때 잘 작동할 수 있다. 애플리케이션이 누락된 동작을 기대하면 취약해진다.

버전 호환성은 또 다른 계층을 더한다. CUDA 애플리케이션은 서로 다른 툴킷, 바이너리 형식, 라이브러리 및 컴파일러 가정을 대상으로 할 수 있다.

저장소는 ZLUDA v6 preview 69, AMD HIP SDK 6.4, CUDA 11.8 기반 LibTorch 2.3.0을 고정한다. 고정은 계속 변하는 종속성 모음을 하나의 테스트 가능한 조합으로 바꾼다.

이 같은 규율은 재현성을 높인다. 동시에 사용자가 더 새로운 구성 요소를 서로 교체 가능하다고 가정해서는 안 된다는 의미이기도 하다.

더 새로운 HIP SDK는 라이브러리 경로, 내보낸 심볼 또는 지원되는 디바이스 타깃을 바꿀 수 있다. 더 새로운 CUDA 대응 애플리케이션은 고정된 호환성 계층이 구현하지 않는 함수를 호출할 수 있다.

프로젝트는 cuBLAS, cuBLASLt, cuSPARSE 및 cuFFT가 런타임 검사를 통과했다고 보고했다. 이 구성 요소들은 중요한 행렬, 희소 컴퓨팅 및 푸리에 변환 작업을 포괄한다.

가장 중요한 누락 요소는 cuDNN이다. NVIDIA의 CUDA Deep Neural Network 라이브러리는 많은 신경망 워크로드에서 사용되는 최적화된 프리미티브를 제공한다.

저장소는 검증된 안정 Windows HIP SDK 구성에서 cuDNN을 사용할 수 없다고 설명한다. 또한 SDK에는 다른 환경에서 제공되는 완전한 ROCm AI 라이브러리 모음이 없다고 언급한다.

이 누락은 애플리케이션에 명확한 경계를 만든다. cuDNN을 기대하는 컨볼루션 중심 소프트웨어는 실패하거나, 더 새로운 개발 스택을 요구하거나, 추가 호환성 작업이 필요할 수 있다.

성공한 강화학습 워크로드는 테스트 경로에서 cuDNN이 필요하지 않았다. 이 워크로드가 수행한 기능에는 밀집 행렬 연산으로 충분했다.

이 세부 사항은 결과와 한계를 모두 설명한다. 프로젝트는 해당 머신에서 사용할 수 있는 라이브러리와 호환되는 워크로드를 선택했다.

런타임 변환은 소스 이식성과도 다르다. HIP 소스는 서로 다른 백엔드를 위해 컴파일 및 최적화할 수 있지만, 바이너리 호환성 계층은 기존 동작을 추론하고 리디렉션해야 한다.

소스 수준 작업은 개발자에게 아키텍처별 튜닝에 대한 더 많은 제어권을 준다. 변환은 원본 애플리케이션 수정이 비현실적일 때 더 빠른 초기 접근성을 제공한다.

어느 방식도 동일한 성능을 보장하지는 않는다. GPU마다 실행 폭, 메모리 동작, 명령어 지원 및 특수 하드웨어가 다르다.

변환된 함수는 올바른 출력을 생성하면서도 덜 효율적인 경로를 사용할 수 있다. 반대로 AMD가 기반 연산을 이미 최적화했다면 매핑된 벤더 라이브러리는 좋은 성능을 낼 수 있다.

이 때문에 하나의 벤치마크로 더 넓은 성능 문제를 결론낼 수는 없다. 변환 오버헤드는 하나의 요인일 뿐이며, 라이브러리 선택과 커널 동작이 전체 런타임을 좌우할 수 있다.

저장소는 2026년 9월 13일에 통제된 비교를 기록했다. 동일한 RX 9060 XT 강화학습 워크로드에서 런타임별로 10회 반복을 실행했다.

각 시험에서 첫 번째 워밍업 반복을 제외한 뒤, 업스트림 경로는 전체 초당 스텝 수 중앙값 13,278을 기록했다. 복원된 커스텀 오버레이는 12,876을 기록했다.

저장소는 해당 테스트에서 커스텀 오버레이가 약 3.03% 느렸다고 계산한다. 이에 따라 공개 업스트림 경로를 기본값으로 유지한다.

이 비교는 한 대의 머신에서 두 가지 호환성 구성을 평가한 것이다. Radeon 카드와 NVIDIA GPU 또는 네이티브 HIP 구현을 비교한 것은 아니다.

저장소의 과거 수치는 다른 학습 구성을 사용했다. 따라서 통제된 테스트와 직접 비교할 수 없다.

개발자에게 더 유용한 결론은 간단하다. 공개 컴포넌트만으로 선택한 워크로드가 비공개 또는 복원된 바이너리 파일 없이 완료됐다.

이는 절차를 더 쉽게 검토하고 재현할 수 있게 한다. 다른 하드웨어에서의 독립적인 결과가 이것이 단일 머신 기준 사례를 넘어설 수 있는지를 결정할 것이다.

검증된 GPU 한 종이 남긴 큰 호환성 격차

이 구성은 Radeon 카드 전반을 위한 일반적인 CUDA 지원이 아니라, 근거를 갖춘 실험이다.

현재 프로젝트가 검증된 기기로 명시한 것은 RX 9060 XT뿐이다. 스크립트는 추가 AMD 아키텍처 계열도 인식하지만 후보로 표시한다.

AMD의 공식 지원 매트릭스는 별도의 제약 조건이다. AMD는 현재 표에 없는 GPU가 관련 Windows 배포판에서 공식 지원되지 않는다고 명시한다.

목록에 포함된 GPU라고 해서 저장소의 검증을 자동으로 받는 것은 아니다. 공식 HIP 지원과 성공적인 CUDA 변환은 시스템의 서로 다른 계층을 시험한다.

사용자에게는 호환되는 AMD 드라이버, 정상 작동하는 HIP 설치, 지원되는 라이브러리, 올바른 ZLUDA 동작, 그리고 구현된 범위 안에서 작동하는 애플리케이션이 필요하다.

어느 계층에서든 실패하면 오류나 잘못된 결과가 발생할 수 있다. 일부 문제는 설치 중 드러나지만, 다른 문제는 장시간 계산 후에야 나타날 수 있다.

정확성은 애플리케이션 실행 성공 여부보다 더 주의 깊게 살펴야 한다. 수치 워크로드는 정밀도, 라이브러리 또는 구현 동작 차이로 인해 다른 출력을 내면서도 완료될 수 있다.

진지한 검증 계획은 예상 출력, 학습 동작, 재현성을 비교해야 한다. 메모리 압박, 장시간 실행, 오류 복구도 테스트해야 한다.

저장소는 스크립트와 문서화된 워크로드를 제공하므로 다른 사용자가 이 과정을 시작하는 데 도움이 된다. 다만 프로젝트가 새롭고 하드웨어 범위가 좁아 독립 검증은 여전히 드물다.

ZLUDA는 자체 소프트웨어를 NVIDIA 이외 GPU용 드롭인 CUDA 대체재로 설명한다. 공개 저장소에는 구현 변경 사항과 프리뷰 릴리스의 긴 목록도 있다.

하지만 드롭인 인터페이스가 완전한 동작 호환성을 의미하지는 않는다. ZLUDA release history는 로더, 컴파일러 동작, 데이터 유형, CUDA 버전 처리에 대한 수정이 계속되고 있음을 보여준다.

프리뷰 소프트웨어는 회귀를 유발할 수 있다. 작동하는 특정 릴리스를 고정한 프로젝트는 일부 변동을 피할 수 있지만, 이후의 호환성 수정도 놓치게 된다.

Windows 보안 소프트웨어도 또 다른 실질적 위험을 만든다. 런타임 가로채기와 라이브러리 리디렉션은 악성 소프트웨어가 사용하는 기법과 유사해 보일 수 있다.

사용자는 식별된 업스트림 릴리스에서만 바이너리를 받아야 하며 해시를 검증해야 한다. 알 수 없는 패키지를 강제로 실행하기 위해 광범위한 보안 제어를 해제해서는 안 된다.

여기서 저장소의 해시 검증은 유용하다. 변경된 다운로드가 런타임에 조용히 유입될 가능성을 낮춘다.

다만 이는 업스트림 코드를 감사하거나 모든 의존성의 안전성을 보장하지는 않는다. 조직은 일반적인 소프트웨어 검토 및 아티팩트 통제 절차를 적용해야 한다.

라이선스 역시 신중하게 다뤄야 한다. 저장소에는 자체 라이선스와 제3자 고지가 포함돼 있으며, ZLUDA는 오픈소스 라이선스를 사용한다.

CUDA는 독점 컴포넌트와 라이선스 조건을 갖춘 NVIDIA 플랫폼이다. 사용자는 자신의 애플리케이션에 어떤 재배포 가능 파일이 포함되는지, 호환성 구성이 무엇을 다운로드하는지 이해해야 한다.

저장소는 공개 업스트림 전용 경로를 강조한다. 이 선택은 현재 방법을 복원되었거나 비공개인 라이브러리가 포함된 초기 실험적 구성과 구분하는 데 도움이 된다.

기업 팀은 지원 주체라는 또 다른 문제에 직면한다. AMD는 HIP SDK를 사용한다는 이유만으로 커뮤니티 CUDA 호환성 레시피를 공식 지원하지 않는다.

NVIDIA 역시 AMD GPU에서 실행되는 CUDA 애플리케이션을 지원하지 않는다. 프로젝트 유지 관리자는 어느 벤더의 서비스 약속도 대신할 수 없다.

따라서 광범위한 내부 검증 없이 가동 시간 보장이 필요한 워크로드에는 이 구성이 적합하지 않다. 반면 이식성을 시험하는 연구실, 취미 사용자, 개발자에게는 더 매력적일 수 있다.

이를 평가하는 팀은 머신 보고서, 정확한 패키지 버전, 검증 출력, 애플리케이션 로그를 보존해야 한다. 검색 가능한 engineering knowledge base는 이러한 아티팩트를 각 테스트와 연결해 둘 수 있다.

또한 테스트 환경을 프로덕션 환경과 분리해야 한다. 전용 머신이나 폐기 가능한 Windows 이미지를 사용하면 드라이버나 라이브러리가 충돌할 때 롤백이 쉬워진다.

핵심 질문은 샘플이 실행되는지가 아니다. 정확한 애플리케이션이 팀에 필요한 하드웨어 전반에서 올바르고 재현 가능한 결과를 내는지다.

호환성 계층이 CUDA의 소프트웨어 우위를 새로운 시험대에 올리다

이 프로젝트는 주변부에서 CUDA의 애플리케이션 종속성을 흔들지만, 완전한 호환성이 얼마나 어려운지도 다시 확인시킨다.

NVIDIA의 강점에는 하드웨어, 드라이버, 컴파일러, 디버깅 도구, 최적화 라이브러리, 문서화, 그리고 수년에 걸친 애플리케이션 통합이 포함된다. CUDA는 이 요소들을 연결하는 인터페이스다.

호환성 프로젝트는 전체 개발 환경을 재현하지 않고도 일부 호출을 재현할 수 있다. 이 차이는 이러한 프로젝트가 폭넓은 신뢰성을 확보하기 전부터 주목받는 이유를 설명한다.

AMD에 호환성은 벤더가 포팅하지 않은 애플리케이션에 도달할 방법을 제공한다. 개발자가 두 백엔드를 모두 유지할 경우 네이티브 ROCm 및 HIP 지원이 더 깔끔한 경로로 남는다.

두 전략은 공존할 수 있다. 변환은 기존 CUDA 바이너리를 대상으로 하고, HIP는 크로스 벤더 배포를 위해 설계되거나 변환된 소프트웨어를 지원한다.

DirectML과 기타 Windows 인터페이스도 추가 대안을 제공한다. 이들은 벤더 중립적 가속을 제공할 수 있지만, 애플리케이션이 이를 명시적으로 채택해야 한다.

OpenCL과 SYCL도 서로 다른 수준에서 이식성을 추구한다. 그렇다고 해서 CUDA 전용 라이브러리나 애플리케이션의 전제 조건이 사라진 것은 아니다.

Hacker News 토론은 이러한 긴장을 드러냈다. 일부 댓글 작성자는 폐쇄형 인터페이스가 하드웨어 선택을 제한하므로 개방형 표준이 더 주목받아야 한다고 주장했다.

다른 이들은 이식 가능한 인터페이스가 종종 더 약한 개발자 경험을 제공한다고 강조했다. 또 다른 비판적 견해는 하드웨어별 최적화 때문에 하나의 범용 계층이 모든 벤더에 맞설 수 없다고 봤다.

두 입장은 모두 실제 제약을 설명한다. 개발자는 이식성을 원하지만, 고성능 커널은 아키텍처 세부 사항과 조정된 라이브러리에 의존한다.

ZLUDA는 순수성보다 호환성을 택한다. 애플리케이션이 CUDA 기반의 전제를 유지하게 하고, 가능한 범위에서 이를 변환한다.

이 접근법은 초기 마이그레이션 작업을 줄인다. 동시에 독립 표준으로 대체하는 대신 CUDA를 애플리케이션이 기대하는 언어로 유지한다.

이것이 프로젝트의 핵심적인 역전이다. AMD에서 CUDA 대상 프로그램을 실행하면 하드웨어 종속성은 약화될 수 있지만, 소프트웨어의 CUDA 의존성은 그대로 남는다.

더 많은 애플리케이션이 작동한다면 CUDA는 여러 백엔드에 도달하는 바이너리를 가진 광범위한 대상 인터페이스처럼 기능할 수 있다. 이는 NVIDIA의 하드웨어 독점성에 압력을 가할 수 있다.

호환성이 워크로드별로 남는다면, 이 실험들은 오히려 NVIDIA 소프트웨어 통합의 깊이를 보여줄 수 있다. 누락된 라이브러리 하나하나는 개발자가 지원되는 CUDA 하드웨어에 계속 머무를 또 다른 이유가 된다.

AMD의 네이티브 Windows 진전은 계산을 바꾼다. 더 나은 HIP 라이브러리와 더 넓어진 PyTorch 지원은 변환 프로젝트에 더 강한 기반을 제공한다.

또한 애플리케이션이 공식 AMD 패키지를 채택할 수 있을 때 변환의 필요성을 줄인다. 이는 반드시 충돌이 아니라 건강한 형태의 중복이다.

중요한 경쟁 신호는 애플리케이션 동작이 될 것이다. 지원 매트릭스도 중요하지만, 사용자는 설치되고 작업을 마치며 올바른 결과를 돌려주는 프로그램을 통해 호환성을 경험한다.

변환된 API 이름 목록은 그 증거를 대체할 수 없다. 비교 가능한 네이티브 구현이 없는 고립된 벤치마크도 마찬가지다.

가장 가치 있는 향후 보고서는 애플리케이션 버전, GPU, 드라이버, HIP SDK, ZLUDA 릴리스, 사용된 라이브러리, 출력 검증, 지속 성능을 설명할 것이다.

부정적인 보고도 똑같이 중요하다. 문서화된 실패는 유지 관리자가 해결해야 할 누락 기능이나 호환되지 않는 전제를 식별한다.

이 증거는 애플리케이션 벤더에게도 지침이 될 수 있다. 하나의 의존성에서 반복되는 실패는 네이티브 HIP 백엔드나 다른 이식 가능한 실행 경로를 정당화할 수 있다.

따라서 이 저장소는 결코 범용 런타임이 되지 않더라도 중요하다. CUDA 의존성이 어디서 시작되고 끝나는지 측정할 수 있는 재현 가능한 테스트 표면을 만든다.

다음 전개를 결정할 세 가지 신호

더 폭넓은 하드웨어 보고, 더 깊은 라이브러리 적용 범위, 안정적인 애플리케이션 결과가 이것이 실용적인 Windows 옵션이 될지를 결정할 것이다.

첫 번째 신호는 추가 Radeon GPU 전반의 독립 검증이다. RX 9060 XT 결과는 공식 지원되는 RDNA3 및 RDNA4 하드웨어에서 재현될 필요가 있다.

성공 보고에는 정확한 버전과 출력 검증이 포함돼야 한다. 단순한 스크린샷이나 감지된 기기 이름만으로는 워크로드 호환성을 입증할 수 없다.

여러 일관된 결과는 이 구성이 AMD Windows 기기 전반에서 이식 가능하다는 주장을 강화할 것이다. 아키텍처별 실패가 빈번하다면 이는 기준 구성으로 범위가 좁아질 것이다.

두 번째 신호는 cuDNN 또는 동등한 신경망 적용 범위다. 많은 AI 애플리케이션은 현재 검증된 안정 스택이 이 경로를 통해 제공하지 않는 연산에 의존한다.

지원은 더 새로운 HIP 배포판, 추가된 ZLUDA 매핑, 애플리케이션 변경 또는 다른 라이브러리 브리지를 통해 도입될 수 있다. 각 경로에는 서로 다른 유지 관리 비용이 따른다.

컨볼루션 비중이 큰 애플리케이션이 작동하면 프로젝트의 관련성이 실질적으로 확대될 것이다. 지원 부재가 계속된다면 많은 이미지 및 모델 워크로드는 실용적인 범위 밖에 머물게 된다.

세 번째 신호는 애플리케이션과 툴킷 업데이트 전반의 안정성이다. 현재의 성공은 고정된 ZLUDA, HIP, CUDA 기반 LibTorch 버전에 의존한다.

개발자는 이후 ZLUDA 릴리스가 테스트를 유지하는지, 새 Windows HIP 패키지가 계속 호환되는지, 새 애플리케이션이 지원되지 않는 호출을 도입하는지를 지켜봐야 한다.

호환성 프로젝트는 업그레이드할 때마다 취약한 조합을 다시 찾아낼 필요가 없을 때 가치를 얻는다. 회귀는 이 접근법에 여전히 집중적인 수동 유지 관리가 필요하다는 신호가 될 것이다.

그 평가에서 성능은 정확성 다음에 와야 한다. 가끔 잘못된 결과를 반환하는 변환 애플리케이션은 처리량과 무관하게 가치가 거의 없다.

정확성 이후에는 존재하는 경우 네이티브 HIP 빌드와 비교해야 한다. 동등한 애플리케이션 설정과 같은 하드웨어도 사용해야 한다.

NVIDIA와의 비교는 구매 관련 질문에 답할 수 있지만, 변환 오버헤드를 분리하지는 못한다. GPU 아키텍처, 메모리 용량, 벤더 라이브러리는 모두 결과에 영향을 줄 수 있다.

현재 프로젝트는 이미 하나의 의미 있는 문턱을 넘었다. 업스트림 컴포넌트 모음을 재현 가능한 Windows 절차로 만들었고, 이를 이끈 워크로드를 완료했다.

기억에 남는 제목이 암시하는 수준에는 아직 도달하지 못했다. Windows에서 AMD용 CUDA는 특정 소프트웨어와 검증된 하나의 GPU에 연결된 호환성 주장으로 남아 있다.

테스트에 관심 있는 개발자는 저장소에 문서화된 버전과 진단 스크립트부터 확인해야 한다. 설치하기 전에 자신의 GPU가 AMD의 최신 지원 목록에 포함되는지 검증해야 한다.

그다음에는 정답이 확인된 기준 결과를 가진 워크로드를 선택해야 한다. 프로그램이 CUDA라는 이름의 장치를 감지하는지보다 그 기준 결과가 더 중요하다.

팀은 실패 사례를 기록하고, 가능하다면 재현 가능한 호환성 보고서를 공개해야 한다. 공유된 증거를 통해 이 브리지가 하나의 애플리케이션 범주를 지원하는지, 아니면 고립된 사례만 지원하는지가 드러날 것이다.

이제 더 큰 질문은 측정 가능한 형태를 갖췄다. 소스 변경 없이 얼마나 많은 CUDA 소프트웨어를 AMD 하드웨어로 옮길 수 있으며, 무엇이 먼저 깨질까?

향후 몇 달 동안은 호환성 매트릭스, cuDNN 관련 진전, 실제 Windows 애플리케이션의 결과를 지켜봐야 한다. 이러한 신호가 Windows에서 AMD용 CUDA가 신뢰할 수 있는 기술이 될지, 아니면 교훈적인 실험으로 남을지를 결정할 것이다.