▲

CUDA에 도전하는 ROCm: ‘한 걸음씩 나아가기’

 (eetimes.com)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • AMD는 Nvidia CUDA 생태계에 대응하기 위해 AI 소프트웨어 스택 ROCm을 중심으로 데이터센터 GPU 전략을 강화하고 있음
  • ROCm은 초기의 단순 펌웨어 묶음에서 완전한 소프트웨어 플랫폼으로 발전했으며, 6주 주기 릴리스 체계를 도입해 안정적 사용성을 확보 중임
  • OneROCm을 통해 CPU, GPU, FPGA 간 AI 스택 통합과 이식성 확보를 추진하며, Triton·MLIR 기반 코드 재활용으로 개발 효율을 높이고 있음
  • ROCm은 펌웨어를 제외한 전 구성요소를 오픈소스화해 커뮤니티 혁신 속도를 흡수하고, Strix Halo 노트북과 Windows 버전에서도 기본 지원됨
  • AMD는 개발자 피드백 대응과 커뮤니티 신뢰 회복을 중시하며, ROCm을 향후 10년간 지속 가능한 개발자 중심 플랫폼으로 발전시키는 것을 목표로 함

AMD ROCm의 진화와 CUDA 경쟁 전략

  • AMD는 데이터센터 GPU 시장에서 Nvidia의 CUDA 생태계에 대응하기 위해 AI 소프트웨어 스택 ROCm을 핵심 전략으로 추진 중임
  • AI 소프트웨어 부문 부사장 Anush Elangovan은 ROCm 개발을 “산을 오르는 일처럼 한 걸음씩 나아가는 과정”으로 표현하며, 지속적 개선과 통합을 강조함
  • 그는 스타트업 Nod.ai 인수를 통해 AMD에 합류했으며, Nod 팀은 Shark, Torch.MLIR, IREE 등 주요 오픈소스 프로젝트에 기여한 경력을 보유함
  • AMD는 ROCm을 통해 CPU, GPU, FPGA 간 AI 스택 통합(OneROCm) 을 추진하며, 소프트웨어 개발 주기를 6주 단위로 단축해 “사용자가 버전을 의식하지 않아도 되는 수준”을 목표로 함
  • ROCm은 현재 AI 지원 엔지니어링 전환을 준비 중이며, 오픈소스 생태계와 개발자 커뮤니티 중심의 확장을 가속화하고 있음

ROCm의 발전과 소프트웨어 전략

  • ROCm은 초기에는 여러 펌웨어 조각을 묶은 형태였으나, 2년 반의 투자 이후 완전한 소프트웨어 플랫폼으로 발전함
    • Elangovan은 Google Chrome 팀의 개발 문화를 벤치마킹해 정기적 릴리스 주기와 안정적 사용자 경험을 목표로 함
    • ROCm은 “그냥 작동하는” 소프트웨어로 자리 잡았으며, 향후 6주 주기 릴리스 체계로 전환 예정임
  • AMD는 하드웨어 중심 기업에서 소프트웨어 중심 기업으로 전환 중이며, 다음 단계로 AI 보조 엔지니어링(AI-assisted engineering) 을 핵심 전환점으로 삼고 있음

AI 스택 통합과 이식성

  • AMD는 OneROCm을 통해 CPU, GPU, FPGA 등 다양한 하드웨어 간 AI 스택 통합을 실현함
    • 일부 구성요소는 여전히 하드웨어 종속적이지만, 모든 가속은 ROCm 스택을 통해 수행되어 이식성(portability) 확보
  • Triton 프레임워크 확산으로 GPU 간 호환성 문제가 완화됨
    • 과거에는 CUDA 커널을 HIP 커널로 변환했으나, 현재는 Triton 커널을 작성해 AMD와 Nvidia 모두에서 실행 가능
    • AMD는 Triton 및 MLIR 컴파일러 인프라에 적극 투자하며, Torch.MLIR 유지보수를 통해 다양한 하드웨어로 코드 재타깃팅 지원
  • 대부분의 추론 고객은 vLLM, SGLang 등 LLM 프레임워크를 사용하며, CUDA 코드 변환 요청은 감소함
    • 새로운 주의(attention) 알고리듬이 등장하면 Triton 기반 커널을 하루이틀 내 최적화 가능
    • HIPify는 여전히 HPC 고객용으로 제공되며, 새로운 커널 작성에는 Claude AI를 활용해 검증 및 코드 생성을 수행함

오픈소스 전략

  • ROCm은 펌웨어를 제외한 전 구성요소를 100% 오픈소스로 공개함
    • 오픈소스화로 개발자 커뮤니티의 검증을 받는 동시에 AMD보다 빠른 커뮤니티 혁신 속도를 활용 가능
    • 누구나 컴파일러, 런타임 등 원하는 지점에서 참여할 수 있으며, AMD의 협업 속도에 제한받지 않음
  • AMD는 개발자 커뮤니티 확장을 적극 추진 중이며, Strix Halo 탑재 노트북에서 ROCm이 기본 지원됨
    • Instinct 데이터센터 하드웨어와 동일한 날에 Windows 버전 ROCm 업데이트를 배포함

개발자 커뮤니티와 피드백 문화

  • Elangovan은 개발자와의 직접 소통을 중시하며, X(Twitter) 를 통해 실시간 피드백을 수집함
    • “ROCm”, “ROCm sucks”, “AMD software not working” 등의 키워드를 모니터링하며, 모든 게시물에 직접 응답
    • 대부분의 문제는 교육과 지원 부족에서 비롯되며, 익명 개발자에게도 직접 조언을 제공함
  • AMD는 GitHub에서 ROCm 관련 1,000건 이상의 불만 조사를 진행했고, 1년 내 모두 해결함
    • 구형 하드웨어 지원 요청이 많았으며, 현재는 AMD 또는 커뮤니티가 유지보수 중
    • 이러한 대응으로 개발자 신뢰가 회복되었으며, “AMD는 문제를 해결한다”는 인식이 확산됨
  • Elangovan은 MI450 GPU(2026년 하반기 출시 예정) 에 기대를 표하며, ROCm을 향후 10년간 지속 가능한 플랫폼으로 발전시키겠다고 강조함
    • 새로운 하드웨어 등장 시에도 개발자가 걱정하지 않아도 되는 안정적 생태계 구축을 목표로 함

미래 방향과 철학

  • Elangovan은 Nod.ai 시절의 경험을 바탕으로, 컴파일러 기술이 거의 모든 가속기 기업에 채택된 사례를 언급함
    • 그는 “확신을 가지고 한 걸음씩 나아가야 한다”며, ROCm의 발전을 지속적 실행의 결과로 정의함
  • AMD는 CUDA를 단순히 복제하는 수준을 넘어, 차별화된 ROCm 기능을 개발 중이며, 장기적으로 개발자 중심 플랫폼으로 자리매김을 목표로 함

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 지난주 동안 TheRock를 stagex로 포팅하면서 ROCm을 musl/mimalloc 기반 툴체인으로 빌드하려고 시도했음
    보안·프라이버시가 중요한 워크로드에서 단일 컴파일러로만 빌드된 바이너리를 신뢰할 수 없기 때문임
    30개 이상의 의존성과 커스텀 LLVM을 패키징하느라 악몽 같은 시간이었지만, 오늘 아침 드디어 런타임 빌드에 성공했음
    AMD 하드웨어가 완전한 오픈 환경에서 동작한다는 점 덕분에 고보안 워크로드에 희망이 보임

    • 나도 ROCm을 musl 위에서 패키징하려고 했음, 특히 Alpine Linux용으로
      커스텀 LLVM 포크와 여러 패키지를 넘기긴 했지만 결국 시간 낭비라 포기했음
      지금은 Vulkan 지원이 있는 llama.cpp를 쓰는데 충분히 만족스러움
      혹시 빌드 레시피를 공유해준다면 Alpine 포팅의 마지막 단계를 넘기는 데 도움이 될 것 같음
    • 이런 상황을 반복해서 보는 게 안타까움
      작년에 AMD의 약속을 믿고 주주 캠페인을 멈췄지만, 이제는 정말 행동이 필요하다고 느낌
      unlockgpu.com/action-plan
    • 이슈 #3477을 보면 마음이 아픔
      이런 식이면 안 됨, 이 작업은 분명히 활용 가능해야 함
    • 혹시 Nvidia를 신뢰하지 않는 이유가 드라이버가 폐쇄형이라서인가?
      Nvidia도 오픈소스 드라이버를 개선하겠다고 약속했음
      개인적으로는 Intel이 32GB VRAM을 1000달러 수준에 제공하는 점이 더 매력적임
    • “단일 컴파일러로만 빌드된 바이너리를 신뢰할 수 없다”는 말이 흥미로움
      서로 다른 컴파일러로 .o 파일을 섞어 링크하는 방식인가?
      혹시 Reflections on Trusting Trust 문제를 실제로 회피하려는 워크로드인지 궁금함

  • 2월부터 AMD에 gfx1201용 튜닝된 Tensile 커널을 rcom-libs에 포함해달라고 요청 중인데, 아무도 담당자를 모름
    개발자 Discord에서도 답이 없어 답답함. 기술적 문제 외에도 AMD의 조직적 병목이 드러나는 사례 같음

  • AMD는 ROCm 관련해서 아직 수년의 격차를 따라잡아야 함
    AI 연산이 가능한 자사 GPU조차 전부 지원하지 않고, 지원되는 경우에도 버그가 많음
    Linux용 AMDGPU 드라이버는 6.6 이후 계속 불안정함

    • 인재를 못 구하는 이유는 단순함. 세계 최고 기업들과 인재 경쟁을 해야 하는데, AMD는 불과 10년 전까지만 해도 회사 존폐 위기였음
    • 결국 급여를 충분히 주지 않기 때문 아닐까
    • ROCm을 너무 오래 방치했음. 5년 전 내 친구들이 내부에서 투자 확대를 설득했지만 실패했음
      AI가 중요해지는 걸 못 본 건 명백한 실책임
      AMD가 경쟁력을 갖추면 업계 전체가 좋아질 텐데, 이건 스스로 자초한 일임
    • 이건 문화적 문제일 수도 있음
      예전 ATI 시절부터 버그 많은 드라이버로 악명이 있었고, AMD가 인수한 뒤에도 그 문화가 바뀌지 않은 듯함

  • 작년에 AMD가 GitHub에서 ROCm 관련 불만을 수집했는데, 1000건 모두 해결됐다고 발표했음
    하지만 실제로는 옛 하드웨어 지원이 거의 늘지 않았음

    • 여러 위키를 뒤져서 수동으로 카드 지원을 해킹해야 하는 수준이라면, 그걸 “지원 추가”라고 부를 수 있을지 의문임

  • ROCm이 모든 AMD 카드에서 출시 즉시 지원되는 날이 오면 그때야 비로소 홍보를 믿을 수 있을 것 같음
    예전에 400 시리즈 같은 최신 카드도 버려버린 건 큰 실수였음
    경영진이 소프트웨어 스택에 더 투자하길 바람

    • CUDA도 완벽하진 않음. 예를 들어 GB10은 출시된 지 꽤 됐지만 여전히 미구현 기능이 많음

  • ROCm은 일반 소비자용 GPU, 예를 들어 RX 580 같은 카드에서는 지원되지 않음
    대신 Vulkan 백엔드는 잘 작동함

    • 2018년에 RX 580을 샀는데, RDNA1·RDNA2 GPU 지원이 부족한 점이 아쉬움
      GCN 아키텍처는 이제 지원이 끊긴 게 당연하다고 생각하지만, RDNA 세대는 여전히 지원 부족이 문제임
    • ROCm은 보통 두 세대의 GPU만 지원함
      현재는 RDNA3·RDNA4만 가능하고, CUDA는 여전히 Turing까지 지원함
      공식 문서 참고
    • RX 5700을 쓰는데, 지원되는 ROCm 버전이 너무 오래돼 Ollama를 돌릴 수 없음
      Vulkan 백엔드는 잘 되지만, 공식 지원까지 1~2년이 걸렸음
    • Vulkan은 잘 작동하지만, C++·Fortran·Python JIT 커널이나 IDE 통합, 디버깅, 라이브러리 지원이 부족함
    • 예전에는 RX580으로 ROCm을 썼던 것 같은데, 지금은 지원 종료된 건가?

  • ROCm 스택을 정리(clean-up) 해줬으면 함
    단순히 git clone --recurse-submodules rocm 후 configure/make로 빌드할 수 있게 하고, 누락된 의존성을 명확히 출력해줬으면 함
    지금은 구조 없이 여러 구성요소를 던져놓은 수준이라, 일관된 아키텍처가 보이지 않음

  • 나는 OpenVINO와 SYCL로 CUDA에 맞서는 팀임
    Intel의 iGPU·dGPU가 최근 가격도 합리적이고 소프트웨어 지원도 좋아졌음
    게임용이 아니라 CV나 데이터 사이언스 워크로드에서는 꽤 잘 스케일링됨

  • AMD 경영진에게 전하고 싶은 ROCm 관련 피드백임
    (1) 서버급 GPU만 지원하고 소비자용 GPU/APU를 무시한 건 전략적 실수임
    개발자 대부분은 개인 노트북에서 실험하고 나중에 서버로 확장함
    CUDA처럼 성능이 낮더라도 소비자용 GPU에서 돌아가게 해야 함
    (2) 두 세대만 지원하는 정책은 고객 입장에서 비합리적임
    공식 문서 참고
    CUDA는 강력한 하위 호환성을 유지함
    (3) Triton에만 집중하고 HIP을 2등급 취급하는 건 잘못된 방향임
    여전히 C/C++ 기반 HPC·시뮬레이션·과학 코드가 많음
    AMD GPU는 FP64 성능이 강점인데, 그걸 스스로 버리는 셈임
    (4) 마지막으로 패키징 품질을 개선해야 함
    배포판 패키저와 협력하는 게 큰 비용이 들지 않으며, Nvidia 대비 경쟁 우위를 줄 수 있음

    • CUDA는 polyglot 지원이 강점임
      Python, Julia 등 다양한 언어에서 커널을 직접 작성할 수 있고, IDE·디버거·라이브러리 통합도 훌륭함
      GPGPU 생태계 전체를 보면 AMD와 Intel은 아직 CUDA의 에코시스템 완성도를 따라가지 못함
    • 패키징은 사실 쉬운 일이 아님
      대부분의 기업은 /opt/foo/ 같은 벤더 설치 방식을 택함
      이렇게 하면 배포판이 나중에 자체 패키징하기도 쉬워짐
      하지만 이를 이해하려면 오픈소스 생태계 경험이 있는 인력이 필요함
    • NVIDIA도 비슷한 실수를 하고 있음
      소비자용 고 VRAM GPU 출시를 늦추며 서버 시장에 집중 중임
      AMD가 이 틈을 잘 활용하면 기회가 될 수 있음
    • 사실 ROCm은 공식 지원이 아니어도 비공식적으로 동작함
      예를 들어 7900 XT에서도 잘 돌아감
      단지 AMD가 테스트 리소스를 투자하지 않아 “공식 지원”으로 표기하지 않을 뿐임

  • 예전에 컴퓨트 셰이더를 다뤄본 경험으로는 CUDA, ROCm, OpenCV 모두 설치가 너무 번거로움
    의존성도 크고, CUDA는 11GB나 됨
    그냥 Vulkan을 쓰는 게 낫다고 생각함. 플랫폼 종속도 없고 “그냥 작동함”

    • Vulkan은 설치는 쉽지만 코드가 복잡함
      셰이더 컴파일과 리소스 설정만 해도 수백 줄이 필요하고, GPU 주소를 다루려면 확장이 필요함
    • Windows에서는 3GB짜리 exe 설치, Linux에서는 저장소 추가 후 설치면 끝임
      그게 몇 시간씩 걸릴 일인가 싶음
    • Vulkan은 저수준 API라 단순한 작업도 200줄 이상 필요함
      예전에는 NVIDIA에서 그래픽 모드로 전환하면 성능이 20% 향상되는 버그(?)도 있었음
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.