<aside> 🎯

한 줄 요약 — AMD Strix Halo (Ryzen AI MAX+ 395, Radeon 8060S iGPU) 위에서 동일 모델 Qwen3-30B-A3B Q4_K_M를 돌렸을 때, HIP/ROCm은 원시 throughput에서 압도적 우위(pp512 354 vs 78 t/s, tg 48 vs 36 t/s) 였지만 모델 로드만으로 CPU 2.5코어가 상시 burn되는 HSA polling 때문에, 24/7 idle 비중이 큰 워크로드에서는 Windows Vulkan(Ollama)이 약 35% 적은 에너지/토큰으로 역전한다. dGPU의 직관을 APU에 그대로 옮기면 안 된다는 사례.

</aside>

<aside> 📊

[이미지 #1 — Hero] Strix Halo APU 위에서 마주 선 ROCm과 Vulkan

파일: 2026-05-31-strixhalo-hero.png

</aside>


📌 도입 — Strix Halo, 새로 등장한 "중간 지대"

이 글의 독자 — Strix Halo / Ryzen AI MAX+ 시리즈로 로컬 LLM 서빙을 운영하는 인프라/ML 엔지니어, 그리고 "AMD GPU에는 ROCm" 직관을 검증해야 하는 백엔드 의사결정자. throughput 표 한 장만 보고 백엔드를 고르는 모든 운영자에게 해당하는 케이스 스터디.

AMD Strix Halo (Ryzen AI MAX+ 395 + Radeon 8060S iGPU, gfx1151)는 데스크탑 dGPU도, 노트북 iGPU도 아닌 중간 지대다. 65 GB까지 끌어올릴 수 있는 통합 메모리(UMA/GTT) 위에서 30B급 LLM이 GPU에 풀로 올라가고, "데스크탑 한 대로 MoE 30B를 돌린다"가 마케팅이 아니라 실측 가능한 영역으로 들어왔다.

문제는 이 새 변종 위에 dGPU 시절의 직관 — "AMD GPU = ROCm 정답" — 을 그대로 옮기는 순간 운영 메트릭이 거꾸로 뒤집힌다는 것이다. 이 글은 ROCm 7.2.4 + 자체 빌드 HIP llama.cpp와 Windows-native Ollama (Vulkan)를 같은 모델·같은 PC에서 4라운드에 걸쳐 측정한 기록이다.

용어 짧게 정리:

측정 환경 요약 — ASUS Strix Halo / Ryzen AI MAX+ 395 (32c) / Radeon 8060S gfx1151 / 64 GB RAM / BIOS UMA 65 GB / 모델 Qwen3-30B-A3B-Instruct-2507 Q4_K_M (17.28 GiB, MoE active 3B) / 측정일 2026-05-31.


🔬 1라운드 — VRAM 인식 문제 ("ROCm은 4 GB만 본다"의 진실)

처음 부딪힌 벽은 정해진 결말이었다. 기본 BIOS 할당으로는 ROCm이 dedicated VRAM만 보고 4 GB로 잘라 30B 모델을 GPU에 올리지 못했다. BIOS UMA/GTT를 65 GB로 늘리니 rocminfo Pool 1 GLOBAL ≈ 95.83 GiB, llama-bench도 정상적으로 device를 인식했다.

<aside> 🧩

[이미지 #2] BIOS UMA 다이얼 — 4 GB에서 65 GB로

파일: 2026-05-31-strixhalo-vram-dial.png

</aside>

rocminfo (gfx1151 agent, Pool 1):
  Segment: GLOBAL; FLAGS: COARSE GRAINED
  Size:    100,478,882 KB  ≈ 95.83 GiB

llama-bench device discovery:
  Device 0: AMD Radeon(TM) 8060S Graphics, gfx1151 (0x1151)
  VRAM: 98123 MiB,  free: 97044 MiB

여기까지는 평범하다. "이제 쓸 수 있다"가 결론이고, 보통은 여기서 끝낸다.