llama.cpp 맞춤 백엔드, AMD XDNA2 NPU로 LLM 행렬 곱셈 오프로딩

AMD XDNA2 NPU 오프로드를 위한 맞춤형 백엔드

한 개발자가 Ryzen AI MAX 385(Strix Halo)의 AMD XDNA2 NPU에 GEMM 연산을 직접 전달하는 맞춤형 llama.cpp 백엔드를 만들었습니다. 이 접근 방식은 iGPU 사용과 공유 메모리 경합을 피합니다.

하드웨어 및 소프트웨어 구성

모델: Meta-Llama-3.1-8B-Instruct Q4_K_M

하드웨어: Ryzen AI MAX 385, CachyOS 6.19, amdxdna 드라이버, XRT 2.21.75

성능 결과

Vulkan 프리필 + NPU 디코딩: 930 t/s 프리필(pp512), 43.7 t/s 디코딩(tg64), 41.5W 평균 전력, 0.947 J/tok
Vulkan 전용: 833 t/s 프리필, 41.6 t/s 디코딩, 52.2W 평균 전력, 1.3 J/tok
CPU 전용: 4.6 t/s 프리필, 3.76 t/s 디코딩

NPU 디코딩 경로는 Vulkan 전용 대비 약 10W를 절약하면서 디코딩 처리량을 유지(약간 상회)하며, iGPU는 다른 작업을 위해 여유롭게 유지됩니다.

기술 스택

커널: mlir-aie xclbins (Xilinx/mlir-aie, Apache 2.0)
런타임 디스패치: XRT 2.21.75
기반: ggml-org/llama.cpp 포크 (MIT)
커널 라우팅: 다양한 K-차원 타일을 커버하는 4개의 xclbin 슬롯과 런타임에 적절한 커널을 선택하기 위한 MIN_N/MAX_N 라우팅

성능 한계 조사

개발자는 43.7 t/s 디코딩 속도를 넘어서기 위해 여러 접근 방식을 시도했습니다:

배치 스윕 N=1..64: 개선 없음(평탄한 성능)
Int4 이중 양자화: SNR 저하(44.8 → 19.7 dB) - 막다른 길
캐스케이드 오프로드: AMD 문서에 의해 배제됨
Llama-3.2-1B 드래프트를 이용한 추측 디코딩: 44% 수용률, 212 t/s 드래프트, 그러나 효과적인 이득 없음

추측 디코딩에서의 개선 부재(일반적으로 44% 수용률로 이득을 제공함)는 병목이 컴퓨팅이 아닌 LPDDR5 대역폭임을 나타냅니다. NPU는 이미 메모리 벽에 도달하여 43.7 t/s가 이 하드웨어에서 이 모델의 한계입니다.

프로젝트 링크

GitHub: https://github.com/BrandedTamarasu-glitch/OllamaAMDNPU
변경 로그: https://brandedtamarasu-glitch.github.io/OllamaAMDNPU/xdna-npu/

이 프로젝트는 재현성을 위해 Claude Sonnet 4.6 / Claude Code로 구축되었으며 공개되었습니다. 개발자는 amdxdna 드라이버를 실행하는 Strix Halo 또는 Phoenix 사용자들로부터 피드백을 구하여 유사한 양자화에서 디코딩 처리량을 비교하고 다른 XDNA2 구성에서 동일한 성능 한계에 직면하는지 확인하려 합니다.

📖 Read the full source: r/LocalLLaMA