작성일: 2026-02-20
환경: AMD Ryzen AI Max+ 395 (Strix Halo) · Ubuntu · Ollama source build
모델: GLM-4.7-Flash (24 GB quantized)
개요
AMD AI Max+ 395의 내장 GPU(GFX1151, RDNA 3.5)는 Ollama에서 ROCm과 Vulkan 두 경로로 GPU 추론을 수행할 수 있다. 이 글에서는 두 백엔드의 실측 토큰 생성 속도를 비교하고, Vulkan 빌드 과정에서 발생한 기술적 문제와 해결 방법을 정리한다. 마지막으로 별도 서버에서 실행 중인 AMD AI Pro R9700(RDNA 4)과의 수치 비교를 덧붙인다.
1. 테스트 환경
| 항목 | 값 |
|---|---|
| CPU | AMD Ryzen AI Max+ 395 (Strix Halo) |
| iGPU | AMD Radeon GFX1151 (RDNA 3.5) |
| GPU 메모리 | 111.5 GiB (UMA — 시스템 RAM 공유) |
| Vulkan API | 1.4.318 (RADV 드라이버) |
| OS | Ubuntu |
| Ollama | Source build (Clang + Vulkan preset) |
| 모델 | glm-4.7-flash (Q6_K_XL, ~24 GB) |
| 측정 방식 | /api/generate 응답의 eval_count / eval_duration (3회 평균) |
2. 벤치마크 결과
2.1 Vulkan vs ROCm (AI Max+ 395 내부)
동일 머신, 동일 모델, 동일 프롬프트("한국의 수도는 어디인가요? 자세히 설명해줘.")로 측정했다.
| 백엔드 | eval_rate (t/s) | prompt_rate (t/s) |
|---|---|---|
| Vulkan (RADV GFX1151) | 45.93 | 767.62 |
| ROCm (표준 배포판) | 37.33 | 670.63 |
| 차이 | +23.0% | +14.5% |
Run별 상세 — Vulkan
| Run | eval_rate (t/s) | prompt_rate (t/s) | eval_tokens | duration |
|---|---|---|---|---|
| 1 | 45.98 | 169.26 | 2,097 | 46.53s |
| 2 | 45.70 | 1,073.02 | 2,297 | 51.19s |
| 3 | 46.13 | 1,060.58 | 1,715 | 37.90s |
Run별 상세 — ROCm
| Run | eval_rate (t/s) | prompt_rate (t/s) | eval_tokens | duration |
|---|---|---|---|---|
| 1 | 37.34 | 224.02 | 1,845 | 50.14s |
| 2 | 37.33 | 896.36 | 1,877 | 51.07s |
| 3 | 37.32 | 891.52 | 1,816 | 49.52s |
토큰 생성 속도(eval_rate) 기준으로 Vulkan이 약 +23% 앞선다. ROCm의 수치는 런별 편차가 거의 없는 반면, Vulkan은 1번 런의 prompt_rate가 현저히 낮은 것이 눈에 띄지만 eval_rate 자체는 세 런 모두 균일하다(45.70–46.13).
2.2 AI Pro R9700 참조 수치
별도 서버에서 동일 소프트웨어 스택(Ollama 공식 배포판)으로 실행한 glm4.7flash-pro:latest 모델 기준이다. 프롬프트는 다양한 주제 3가지를 순환하여 3회 측정했다.
| 항목 | 값 |
|---|---|
| GPU | AMD AI Pro R9700 (RDNA 4) |
| 모델 | glm4.7flash-pro:latest (24.4 GB) |
| 평균 eval_rate | 64.12 t/s |
| 평균 prompt_rate | 378.04 t/s |
| Run | 프롬프트 | eval_rate (t/s) | eval_tokens | duration |
|---|---|---|---|---|
| 1 | 한국의 수도 | 63.72 | 2,778 | 44.07s |
| 2 | 양자 컴퓨팅 | 63.83 | 2,395 | 37.93s |
| 3 | 피보나치 코드 | 64.83 | 1,114 | 17.46s |
2.3 세 구성 비교
| 구성 | GPU | eval_rate (t/s) | ROCm 대비 |
|---|---|---|---|
| AI Max+ 395 · Vulkan | GFX1151 RDNA 3.5 iGPU | 45.93 | +23% |
| AI Max+ 395 · ROCm | GFX1151 RDNA 3.5 iGPU | 37.33 | 기준 |
| AI Pro R9700 · ROCm | RDNA 4 dGPU | 64.12 | +72% |
모델 버전이 완전히 동일하지 않고 측정 조건(프롬프트, 로드 상태)이 다를 수 있으므로 AI Pro R9700 수치는 절대 비교보다 참조 수준으로 해석하는 것이 적절하다. 단순 비율로만 보면 RDNA 4 전용 dGPU가 RDNA 3.5 iGPU Vulkan 대비 약 40% 높은 토큰 처리량을 보인다.
3. Vulkan 빌드 절차
Ollama의 공식 배포판은 ROCm 백엔드 기준으로 제공된다. Vulkan 백엔드를 사용하려면 소스 빌드가 필요하다.
3.1 의존성
| 항목 | 버전 | 비고 |
|---|---|---|
| Go | 1.24.1 | go.mod 최소 요구 충족 |
| CMake | 3.28.3 | |
| Clang | 18.1.3 | CGO 컴파일러로 지정 |
| Ninja | 1.11.1 | |
| libvulkan-dev | 1.3.275.0 | |
| glslc (shaderc) | v2026.2-dev | 소스 빌드 필수 — 아래 참조 |
3.2 빌드 명령
# CMake 구성
CC=clang CXX=clang++ cmake --preset 'Vulkan' \
-DCMAKE_HIP_COMPILER=FALSE \
-DVulkan_GLSLC_EXECUTABLE=~/project/shaderc_dist/bin/glslc
# 빌드
cmake --build --preset 'Vulkan' --parallel $(nproc)
# Go 바이너리
CC=clang CXX=clang++ \
LD_LIBRARY_PATH=~/project/ollama/build/lib/ollama \
go build -o ~/project/ollama_vulkan/ollama .필수 플래그 두 가지:
-DCMAKE_HIP_COMPILER=FALSE— ROCm(/opt/rocm)이 설치된 환경에서 CMake의check_language(HIP)가 ROCm의 clang++을 자동 탐색하여 빌드 오류를 낸다.-DVulkan_GLSLC_EXECUTABLE— 시스템 패키지 glslc(2023.8)는 성능에 관여하는 핵심 셰이더를 잘못 컴파일한다. 소스 빌드 버전을 명시해야 한다.
4. 빌드 과정에서 발생한 주요 문제
4.1 증상
Vulkan 빌드가 완료됐음에도 ollama serve 실행 시 GPU가 인식되지 않고 CPU 폴백이 발생했다.
inference compute id=cpu library=cpu total="31.0 GiB"GPU가 인식된 정상 상태:
inference compute library=Vulkan name=Vulkan0
description="AMD Radeon Graphics (RADV GFX1151)"
type=iGPU total="111.5 GiB" available="111.3 GiB"4.2 원인 추적
GPU 미인식
└─ /info API → [] (빈 GPU 목록)
└─ ggml Vulkan 백엔드 미등록
└─ dlopen 실패: undefined symbol
mul_mat_vec_id_q4_1_q8_1_f32_subgroup_len
└─ mul_mat_vecq.comp 셰이더 컴파일 실패
└─ GL_EXT_integer_dot_product + vulkan1.2 + -O 조합
└─ 시스템 glslc 2023.8 버그핵심 경위:
- ggml은 하위 호환성을 위해 대부분의 셰이더를
--target-env=vulkan1.2로 컴파일한다. GL_EXT_integer_dot_product(VK_KHR_shader_integer_dot_product)는 Vulkan 1.3 core로 승격된 확장이다.- 시스템 glslc 2023.8은
vulkan1.2타겟에서 이 확장을 처리하지 못한다. - ggml의 셰이더 생성기(
vulkan-shaders-gen.cpp)는 컴파일 실패 시 해당 셰이더를 건너뛰고 빌드를 계속 진행한다. 결과적으로.so파일 안에 undefined symbol이 잔존한다. dlopen()단계에서 실패하여 Vulkan 백엔드가 등록되지 않는다.
GFX1151은 Vulkan 1.4를 지원하므로 하드웨어 자체는 문제가 없다. 문제는 전적으로 glslc 버전에 있다.
4.3 해결
시스템 glslc 대신 shaderc를 소스에서 직접 빌드하여 사용한다.
cd ~/project && mkdir -p shaderc_build && cd shaderc_build
git clone https://github.com/google/shaderc.git
cd shaderc && python3 utils/git-sync-deps
mkdir -p ../build && cd ../build
cmake ../shaderc -GNinja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=~/project/shaderc_dist \
-DSHADERC_SKIP_TESTS=ON -DSHADERC_SKIP_EXAMPLES=ON -DSPIRV_SKIP_TESTS=ON
ninja -j$(nproc) && ninja install
# 결과: ~/project/shaderc_dist/bin/glslc (v2026.2-dev)이후 위 3.2 절의 CMake 명령에서 -DVulkan_GLSLC_EXECUTABLE로 이 경로를 지정하면 integer dot product 가속(int dot: 1)이 정상 활성화된다.
4.4 비활성화 옵션과의 비교
CMake 플래그 -DGGML_VULKAN_INTEGER_DOT_GLSLC_SUPPORT=OFF를 사용하면 glslc 버그를 회피할 수 있지만, INT8 dot product 하드웨어 가속이 비활성화된다. 양자화 모델(Q4/Q8) 성능에 직접 영향을 주므로 이 글에서는 소스 빌드(방법 B)를 채택했다.
5. 서비스 통합
격리 테스트(포트 11435) 완료 후 기존 ollama.service를 Vulkan 빌드로 교체했다.
# /etc/systemd/system/ollama.service.d/env.conf
[Service]
ExecStart=
ExecStart=/home/onechips/project/ollama_vulkan/ollama serve
Environment="OLLAMA_VULKAN=1"표준 포트(11434)를 그대로 사용하므로 클라이언트 측 변경은 없다.
6. 결론
- AI Max+ 395에서 Vulkan 백엔드는 ROCm 대비 토큰 생성 속도 기준 약 23% 높은 처리량을 보였다.
- 빌드 자체는 공개된 소스 코드와 표준 도구로 가능하지만, 시스템 패키지의 glslc 버전 문제로 인해 추가 단계(shaderc 소스 빌드)가 필요하다. Ubuntu의 경우 패키지 관리자 버전(2023.8)이 현재 ggml 셰이더와 호환되지 않는다.
- AI Pro R9700(RDNA 4)은 동일 모델 기준 약 64 t/s로, AI Max+ 395 Vulkan(약 46 t/s)보다 약 40% 높은 수치를 보였다. 다만 두 측정은 프롬프트·조건·모델 버전이 완전히 동일하지 않으므로 직접 비교 시 주의가 필요하다.
- AI Max+ 395의 UMA 구조(시스템 RAM을 VRAM으로 공유, 111 GiB)는 VRAM 용량 면에서는 유리하지만 메모리 대역폭은 전용 HBM/GDDR 기반 dGPU와 다르다.
※ AMD AI 칩셋 지원 ROCm 최적화가 더 진행될 경우 Vulkan 성능을 역전할 가능성이 높다는 주장들이 많지만, 이미 ROCm 빌드는 매우 안정적으로 이루어지고 있다.
Pro 라인업과 달리 내장 iGPU인 8060S는 게임용 리테일 GPU와 같이 앞으로도 Vulkan 우위가 계속될 가능성이 높아보인다.
오히려 llama 코어를 사용하는 경우 Vulkan 최적화 여지가 있다는 추정을 해본다.
ROCm 빌드는 Warning 하나 뜨지 않지만, Vulkan 빌드 시 성공하더라도 Warning을 지우기는 쉽지 않았다.
※AMD CPU+AI Pro R9700은 AOCC + Clang++ 빌드가 가장 성능이 좋다.
Fedora 43에서 Distrobox로 우분투 24.04로 빌드테스트 결과 동일 모델에 대해 70t/s 이상을 뽑아냈기 때문에 현재 Ubuntu Server 24.04 LTS HWE로 Native 운용을 위한 작업이 진행중이다.
※해외 커뮤니티에서 Fedora 43이 LLM 모델 컨테이너 올리기 가장 좋다는 글이 많은데, 온전한 사실이 아니다.
Fedora가 유리한 이유는 단지 최신 커널과 최신 드라이버 때문에 기본 옵션만으로 설치와 운용이 매끄럽게 잘 된다는게 전부다.
정작 최신 안정판 라이브러리와 런타임의 지원은 안되고 있고, 억지로 적용하려 한다면 지옥문이 열린다.
실제로 대부분 공개된 성공적인 빌드들은 모두 podman이나 docker나 toolbox나 distrobox에 올린 방식인데, 결론적으로는 구형 런타임, 라이브러리, 드라이버 아래에 최신 라이브러리를 포팅하는 방식 뿐이다.
실제로 성능을 뽑기 위해서는 아직까지는 우분투 24.04 LTS HWE로 CPU와 GPU에 맞는 빌드를 안정적인 지원 런타임과 SDK를 활용해서 진행하는게 성능 면에서 유리하다.
데스크탑 환경이 아니라 서버로 Headless 모드로 LLM 노드를 운용하겠다면, 기본 배포판의 드라이버가 아무리 문제가 많아도 HWE에 독점 드라이버를 올리고 빌드하는게 가장 좋다.