2026년 3월 22일 r/LocalLLaMA에 올라온 벤치마크 글은 AMD Mi50 32GB 카드에서 llama.cpp를 돌릴 때 ROCm 7 nightly와 Vulkan 중 무엇이 더 나은지 비교한 실측 기록이다. 글 작성자는 Ubuntu Server 24.04, Proxmox 가상화, EPYC 7532, llama.cpp build 8467 환경에서 Qwen 3.5 9B, Qwen 3.5 27B, Qwen 3.5 122B, Nemotron Cascade 2 같은 모델을 같은 조건으로 시험했다고 정리했다. 단순한 “체감상 빠르다” 수준이 아니라, prompt processing과 token generation을 context depth별로 나눠 적어 커뮤니티에서 참고용 자료로 소비되고 있다.

게시물이 말하는 핵심 결과

작성자의 결론은 비교적 명확하다. 짧은 context, 특히 dense model 위주 대화형 사용에서는 Vulkan이 더 빠른 경우가 많지만, context가 16k를 넘어가거나 MoE 모델, 혹은 CPU와 GPU를 섞는 추론에서는 ROCm이 더 강하다는 것이다. 즉 “어느 백엔드가 무조건 승자냐”가 아니라, workload에 따라 답이 바뀐다는 식이다. 이 점이 LocalLLaMA 커뮤니티에서 의미가 큰 이유는, AMD GPU를 쓰는 local inference 사용자들이 실제로 가장 많이 고민하는 질문이 설치 난이도보다도 workload별 효율이기 때문이다.

dense model의 짧은 context prompt processing에서는 Vulkan 우세라는 관찰이 반복됐다.
긴 context나 MoE 계열에서는 ROCm이 prompt processing과 generation을 합친 전체 체감 성능에서 더 낫다고 적었다.
작성자는 TheRock nightly 기반 ROCm 7 빌드가 안정성 면에서는 여전히 불안정하다고 경고했다.

댓글에서 나온 보강 정보

토론 댓글도 꽤 실용적이다. 한 사용자는 Mi60에서 Nemotron Cascade 2 Q4_1 기준 65K context에서 약 726 tokens/s 수준의 prompt processing 수치를 공유했고, 다른 사용자는 ROCm이 Vulkan보다 컴파일과 운용이 훨씬 까다롭고 실제 안정성도 떨어졌다고 적었다. 또 다른 댓글은 RDNA 4 세대에서는 결과가 달라질 수 있다고 지적한다. 즉, 원문 자체도 유용하지만 댓글까지 포함해야 “지금 어떤 AMD 스택을 선택할 것인가”에 대한 현실적인 판단 자료가 된다.

제약과 해석

이 벤치마크는 어디까지나 단일 장비, nightly 드라이버, hobbyist 세팅에서 나온 측정값이다. 글 작성자도 ROCm llama-server가 8GB prompt cache를 VRAM에 잘못 잡아 OOM을 내는 문제와 이전 nightly에서의 memory leak 의심 사례를 언급했다. 따라서 절대적인 승부표로 받아들이기보다는, AMD local LLM 환경에서 “Vulkan은 단순하고 안정적, ROCm은 긴 문맥과 일부 모델에서 더 빠를 수 있지만 운영 리스크가 있다”는 방향성을 보여주는 커뮤니티 리포트로 보는 편이 정확하다.

게시물이 말하는 핵심 결과

댓글에서 나온 보강 정보

제약과 해석

출처

#vulkan

LocalLLaMA, Mi50에서 ROCm 7과 Vulkan을 비교한 llama.cpp 벤치마크 공유