AMD 로컬 LLM 호스팅: ROCm 대 Vulkan 2026 가이드

엔진별로 적합한 AMD 백엔드 선택

Page content

ROCm과 Vulkan은 모두 로컬 LLM 호스팅을 위해 AMD GPU를 가속화하지만, 서로 대체재가 될 수 없습니다. 올바른 선택은 엔진, GPU, 그리고 워크로드에 따라 달라집니다.

로컬 LLM 호스팅에서 두 백엔드는 서로 다른 계층에 위치합니다. ROCm은 PyTorch, vLLM, SGLang 아래에 있는 AMD의 컴퓨팅 플랫폼인 반면, Vulkan은 llama.cpp 계열 엔진이 다양한 하드웨어에서 양자화(quantized) 모델을 실행하기 위해 사용하는 포터블 GPU API입니다.

ROCm and Vulkan backends for AMD local LLM hosting

이 가이드는 빌드 명령어, 장치 확인, 성능 문제로 위장한 실패 모드와 함께 llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI, LocalAI를 엔진별로 비교합니다. 호스팅 환경을 처음 접하는 경우, 이 기사가 심층적으로 다루는 도구 가지를 보여주는 LLM 호스팅 개요를 먼저 시작점으로 삼으시길 권장합니다.

ROCm 대 Vulkan: 간결한 답변

상황 권장 시작점 이유
Linux에서 GGUF를 사용하는 llama.cpp Vulkan 설치 범위가 작고, GPU 호환 범위가 넓으며, 롤백이 쉽다
지원되는 RDNA 3 또는 RDNA 4 GPU에서 llama.cpp 사용 둘 다 벤치마크 커널 성능은 모델 구조, 양자화, 컨텍스트, 빌드에 따라 변한다
목록에 있는 AMD GPU에서 Ollama 사용 먼저 ROCm, Vulkan도 확인 Ollama는 둘 다 지원하지만, 순수 llama.cpp보다 백엔드 선택이 명시적이지 않다
데스크톱 AMD GPU에서 LM Studio 사용 먼저 Vulkan 런타임 전환이 쉬워 비교가 용이하고, 시스템 전체 컴퓨팅 스택 설치 없이 진행할 수 있다
vLLM 또는 SGLang ROCm, 단 GPU 패밀리 커널 커버리지 확인 필요 이들은 PyTorch/HIP 스택이며, Vulkan은 대체 백엔드가 아니다. 최신 아키텍처는 최적화 커널이 누락될 수 있다
지원되는 Instinct 하드웨어에서 TGI ROCm 공개된 AMD 컨테이너 경로는 MI210, MI250, MI300 패밀리를 대상으로 한다
구형 또는 목록에 없는 Radeon GPU Vulkan Vulkan 드라이버는 ROCm 라이브러리보다 더 많은 그래픽 하드웨어를 커버하는 경우가 많다
AMD Instinct 서버 ROCm 멀티 GPU 컴퓨팅, RCCL, 프레임워크 커널, 운영 도구가 여기에 속한다
Windows 로컬 GGUF 서빙 Vulkan llama.cpp 계열 런타임에 대해 일반적으로 가장 제한이 적은 경로이다
Ryzen AI Max 또는 기타 대용량 메모리 APU 먼저 Vulkan, 필요 시 ROCm 둘 다 작동할 수 있지만, 공유 메모리와 커널 지원은 워크로드별 테스트가 필요하다

이 표는 벤치마크 결과가 아니라 시작 정책입니다. GPU를 감지하지만 일부 작업을 CPU에서 처리하는 백엔드는 겉으로 건강해 보이지만 성능이 나쁠 수 있으므로, 모든 최종 결정은 로그 점검과 엔드투엔드 프롬프트 테스트가 필요합니다.

ROCm과 Vulkan의 실제 정체는 무엇인가

ROCm은 컴퓨팅 플랫폼입니다

ROCm에는 AMD 컴퓨팅 워크로드 실행에 필요한 HIP 런타임, 컴파일러, 수학 라이브러리, 수집 통신(collective communication), 프로파일러, 프레임워크 패키지가 포함되어 있습니다. 이는 PyTorch 빌드와 vLLM 및 SGLang과 같은 엔진 아래에 있는 AMD 측 기반이며, HIP 백엔드를 통해 llama.cpp를 가속화할 수도 있습니다.

이러한 폭넓음은 ROCm의 장점이자 비용입니다. 호스트 드라이버, GPU 대상, 사용자 공간 라이브러리, 프레임워크 휠, 커널 버전, 컨테이너 이미지가 서로 호환되는 세트를 형성해야 합니다. 호환되면 ROCm은 단일 로컬 실행 파일을 통한 토큰 생성 이상의 훨씬 많은 것을 제공합니다.

2026년 8월 26일 출시된 ROCm 10.0.0은 TheRock(ROCm 7.14부터 AMD의 빌드 및 릴리스 시스템)을 기반으로 하며, PyTorch 2.13, vLLM 0.27, SGLang 0.5.15를 검증하고, gfx1200(RX 9060/9060 XT/9050)과 gfx1201(RX 9070/9070 XT/9070 GRE, Radeon AI PRO R9700 시리즈)에 대한 RDNA 4 지원을 공식적으로 추가했습니다. 정확한 GPU와 운영체제 조합에 대한 권한은 여전히 ROCm 호환성 매트릭스이며, 우연히 같은 마케팅 패밀리명을 사용하는 포럼 게시글이 아닙니다.

Vulkan은 포터블 GPU 인터페이스입니다

Vulkan은 GPU 드라이버에 의해 구현된 그래픽 및 컴퓨팅 API입니다. 로컬 LLM 호스팅에서 이는 일반적으로 추론 엔진이 Mesa RADV(Linux)나 벤더 드라이버(Windows)와 같은 Vulkan 구현을 통해 실행되는 컴퓨트 셰이더를 배포하거나 컴파일한다는 것을 의미합니다.

Vulkan은 ROCm과 비교할 수 있는 즉석 교체 가능한 PyTorch 플랫폼을 제공하지 않습니다. 그 실용적인 강점은 더 좁고 유용합니다. llama.cpp 스타일의 엔진은 AMD, Intel, Nvidia 및 기타 Vulkan 지원 하드웨어에서 벤더 특정 머신러닝 스택을 설치하지 않고도 동일한 백엔드 설계를 사용할 수 있습니다.

이 구분이 대부분의 결정을 설명합니다. 애플리케이션이 HIP 또는 PyTorch 경로만 제공하는 경우 Vulkan으로 구제할 수 없지만, 애플리케이션이 이미 llama.cpp와 GGUF에 기반한다면 전체 ROCm 스택을 설치하는 것은 본래 가진 문제가 아니었던 것을 해결하려 할 수 있습니다.

2026년 엔진 지원 매트릭스

엔진 ROCm 또는 HIP Vulkan 일반 모델 포맷 실용적 참고 사항
llama.cpp / llama-server 예 예 GGUF 통제된 A/B 백엔드 테스트에 가장 적합한 플랫폼
Ollama 예 예 관리되는 GGUF 파생 모델 편리하지만, 백엔드 선택과 패키징이 추상화되어 있다
LM Studio 예 예 GGUF 및 제품 관리 포맷 선택 가능한 런타임이 데스크톱 테스트를 접근하기 쉽게 만든다
vLLM 예 아니오 Safetensors 및 지원되는 양자화 AMD의 매칭된 ROCm 이미지나 휠 세트 사용; 먼저 GPU 패밀리 커널 커버리지 확인
SGLang 예 아니오 Safetensors 및 지원되는 양자화 ROCm은 배포 아키텍처의 일부
TGI 예 아니오 Safetensors 및 지원되는 양자화 공개된 AMD 검증은 Instinct 중심
LocalAI 예 예 백엔드 의존, 보통 GGUF 다른 ROCm 및 Vulkan 컨테이너 이미지를 사용

ROCm이 Safetensors를 의미하는 것도, Vulkan이 공식적으로 GGUF를 의미하는 것도 아닙니다. 유용한 연관성은 엔진에서 옵니다. llama.cpp는 HIP 또는 Vulkan 빌드로 동일한 GGUF를 읽을 수 있지만, PyTorch 네이티브 서버는 ROCm을 사용하고 일반적으로 Hugging Face 모델 저장소를 소비합니다.

이는 모델 인벤토리를 아키텍처적 제약으로 만듭니다. 신중하게 선택된 GGUF 양자화 라이브러리는 자연스럽게 llama-server, Ollama, LM Studio, LocalAI를 지시하지만, 텐서 병렬성, 연속 배칭, 프레임워크 네이티브 가중치를 중심으로 구축된 배포는 vLLM 또는 SGLAM과 함께 ROCm을 지시합니다. AMD 백엔드를 넘어선 더 넓은 엔진 경향성(도구 호출, 프로덕션 준비 상태 등 10여 개 도구를 아우르는 API 성숙도)에 대해서는 우리 Ollama, vLLM, LM Studio, LocalAI 및 기타 로컬 LLM 호스팅 도구 비교를 참고하세요.

llama.cpp: 가장 깔끔한 ROCm 대 Vulkan 비교

llama.cpp는 모델 파일이나 HTTP 클라이언트를 변경하지 않고 두 백엔드를 모두 노출합니다. 토크나이저, 샘플링 설정, 채팅 템플릿, 양자화, 서버 동작이 고정될 수 있으므로 이는 ROCm과 Vulkan을 비교하기에 가장 공정한 장소입니다.

현재 llama.cpp 빌드 문서는 ROCm에 GGML_HIP, Vulkan에 GGML_VULKAN을 사용합니다. GGML_ROCM이나 제거된 Makefile 플래그를 권장하는 구형 기사는 프로젝트의 현재 CMake 옵션을 확인하지 않고 신뢰해서는 안 됩니다.

Ubuntu에서 Vulkan 백엔드 빌드

Vulkan 헤더, 셰이더 컴파일러, SPIR-V 헤더를 설치한 후, 드라이버가 의도한 GPU를 열거할 수 있는지 확인하세요:

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

iGPU와 디스크리트 GPU가 혼합된 시스템에서는 열거 순서에 주의가 필요합니다. GGML_VK_VISIBLE_DEVICES는 llama.cpp를 특정 Vulkan 장치로 제한할 수 있으며, 시작 로그는 Vulkan 장치가 존재하는 것을 단순히 보고하는 것이 아니라 선택된 카드의 이름을 명시해야 합니다.

ROCm 또는 HIP 백엔드 빌드

먼저 ROCm이 GPU를 식별하고 예상되는 gfx 타깃을 보고하는지 확인하세요. 타깃을 생략하면 현재 시스템의 GPU를 대상으로 빌드할 수 있지만, 배포 하드웨어를 알고 있다면 이를 고정(pinning)하면 컴파일 작업이 줄어듭니다.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

gfx1201은 실제 카드에서 보고된 타깃으로 대체하세요 — 이 값은 RDNA 4의 RX 9070/9070 XT/9070 GRE 및 Radeon AI PRO R9700 패밀리와 매핑되며, gfx1200은 RX 9060 시리즈를, gfx1100/gfx1101/gfx1102는 RDNA 3의 RX 7900/7800/7700/7600 라인을 커버합니다. 누군가가 미지원 GPU를 부팅하는 데 도움이 되었다는 이유만으로 HSA_OVERRIDE_GFX_VERSION을 프로덕션 서비스에 복사하지 마세요; 오버라이드는 코드가 로드되도록 만들 수 있지만, 그 하드웨어를 검증된 플랫폼으로 전환하지는 않습니다.

두 기본값이 아닌 동일한 워크로드 벤치마크

하나의 GGUF 파일, 동일한 플래시 어텐션 설정, 동일한 레이어 오프로드, 반복 실행을 사용하세요. 프롬프트 처리(pp)와 토큰 생성(tg)은 시스템을 다르게 사용하며, 긴 컨텍스트 서버는 짧은 합성 벤치마크가 놓칠 수 있는 KV 캐시 할당과 메모리 압력을 추가합니다.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

커뮤니티 결과는 왜 보편적인 승자가 오해의 소지가 있는지를 보여줍니다. RDNA 4의 gfx1201 타깃이 최근 가장 명확한 예입니다. 한 RX 9070 XT 동일 머신 제출에서, Vulkan은 7B Q4_0 생성 테스트에서 ROCm의 128 token/s 대비 약 143 token/s에 도달했지만, 빌드가 변경됨에 따라 추후 제출에서는 격차가 작아졌습니다. Vulkan과 ROCm 토론에는 또한 프롬프트 처리 결과와 테스트 조건에서 큰 차이도 포함되어 있습니다. RX 9070 XT에서 llama.cpp b6401로 실행된 별도의 더 자세한 OpenBenchmarking.org 테스트는 Vulkan이 8B급 모델(예: Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0) 여러 가지에서 디코딩(decode) 부문에서 앞서지만, 더 긴 프롬프트 길이에서는 프롬프트 처리 부문에서 HIP보다 뒤처지는 것을 발견했습니다 — 두 백엔드는 측정하는 단계에 따라 우열을 다퉁니다.

격차는 특정 모델 구조에 따라, 그리고 매우 크게 반대 방향으로 진행될 수도 있습니다. 공개된 llama.cpp 이슈는 모델의 히든 사이즈(hidden size)가 4096에 도달하거나 이를 초과하면 gfx1201의 Vulkan이 토큰 생성에서 HIP보다 4.7–6.7배 느려지는 것을 문서화했습니다 (640 GB/s 카드에서 실제 디코드 대역폭이 대략 70–100 GB/s로 붕괴), 반면 히든 사이즈가 2560인 작은 4B 모델은 어느 백엔드에서도 이러한 회귀가 없습니다. 여기 있는 모든 숫자를 하나의 빌드, 하나의 드라이버, 하나의 모델 구조의 스냅샷으로 취급하세요 — 양자화 유형, 모델 아키텍처, 플래시 어텐션, 배치 크기, 드라이버 버전, 열 상태, llama.cpp 커밋에 걸쳐 일반화되는 규칙이 아닙니다.

AMD에서의 Ollama: 편리하지만 백엔드를 확인하세요

Ollama는 ROCm을 통해 목록에 있는 AMD GPU를 공식적으로 지원하며, 현재 Windows와 Linux에서 Vulkan을 통한 추가 AMD 커버리지를 문서화합니다. 그 현재 하드웨어 지원 페이지는 백엔드가 설치되면 Vulkan이 기본적으로 활성화된다고 말하며, 장치 선택을 위해 GGML_VK_VISIBLE_DEVICES를 지원하고, OLLAMA_VULKAN=0으로 Vulkan을 비활성화할 수 있다고 합니다.

이는 Vulkan 조언이 실험적 빌드에 의존하던 시기에 비해 의미 있는 개선입니다. 또한 일부 구형 튜토리얼을 구식으로 만듭니다: 문서화되지 않은 스위치를 설정하고 서비스가 Vulkan을 선택했다고 가정하는 것은 서버 로그를 읽는 것보다 약한 증거입니다.

sudo systemctl edit ollama

진단용으로, 대화형 셸에서만 변수를 내보내는 대신 드롭 인(drop-in)을 추가하세요:

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

그런 다음 다시 로드하고, 재시작하며, 프로세스 배치와 탐색(discovery) 메시지를 검사하세요:

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

명시된 GPU, 선택된 라이브러리, 모델 할당, GPU 백분율을 확인하세요. 탐색 타임아웃이 표시된 후 성공적인 HTTP 응답을 보인 로그는 Ollama가 조용히 CPU로 폴백(fallback)했음을 의미할 수 있습니다. 이 서비스를 둘러싼 일상적인 명령 세트에 대해서는, Ollama CLI 치트시트가 더 빠른 참고 자료입니다.

Ollama는 모델 획득과 안정적인 로컬 API가 백엔드 제어보다 중요한 경우 매우 우수합니다. 반복 가능한 ROCm 대 Vulkan 테스트가 목적이라면, 빌드 디렉토리가 백엔드를 명시적으로 만들므로 순수 llama-server가 더 나은 측정 도구입니다.

vLLM과 SGLang은 ROCm을 결정하지만 — 먼저 GPU 패밀리 커널 커버리지를 확인하세요

vLLM과 SGLang은 Vulkan 애플리케이션이 아닙니다. 이들의 AMD 경로는 ROCm, PyTorch, 최적화된 HIP 커널 위에 있으므로, 이 엔진 중 하나를 선택하는 것은 이미 컴퓨팅 플랫폼을 선택한 것입니다.

AMD의 현재 ROCm에서의 vLLM 가이드는 사전 빌드된 컨테이너를 권장하며, ROCm, PyTorch, Python, vLLM에 대해 매칭된 이미지를 공개합니다. 이러한 결합은 유용합니다: 대규모 의존성 해결 연습을 버전이 지정된 배포 단위로 대체합니다.

기사의 작성 시점에, AMD는 vLLM 0.27을 위해 이 ROCm 10 이미지를 문서화합니다:

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

AMD 문서에서 정확한 GPU 패밀리ために 선택된 이미지를 사용하세요; RDNA와 CDNA 이미지는 항상 서로 교체 가능하지 않았습니다. 프로덕션 서버의 경우, 전체 태그나 다이제스트를 고정하고 vLLM을 탓하기 전에 호스트 드라이버를 검증하세요.

최신 GPU 세대는 가장 날카로운 엣지 케이스이며, RDNA 4는 이론적 위험이 아닌 실제 문書화된 예입니다. 2026년 초 RX 9070 XT (gfx1201)에 대한 독립적 테스트에서, vLLM은 ROCm 7.2에서 FP8 모델 가중치를 위한 FP32 디양자화(dequantization)로 조용히 폴백하는 것이 발견되었습니다 — gfx1201이 아직 vLLM의 플랫폼 감지에서 인식되지 않았기 때문으로 — 이는 GPU의 행렬 가속기를 완전히 우회하여 단 48 tokens/s만을 생성했으며, 이는 동일한 카드에서 동등한 모델의 GGUF 양자화를 Vulkan에서 실행한 llama-server의 62 tokens/s에 비해 낮은 수치였습니다. 교훈은 일반화됩니다: ROCm/PyTorch 스택은 새로운 아키텍처에서 로드에 성공할 수 있지만, 오류 메시지가 없는 비최적화 폴백 경로를 실행할 수 있습니다. 마지막 릴리스 사이클 또는 두 번 이내에 출시된 하드웨어에서 단일 “잘 시작됐다” 결과를 신뢰하기 전에, 실제로 어느 커널 경로가 실행되었는지 확인하세요 (rocprof, 벤더 프로파일링 노트, 또는 GPU의 알려진 정상적인 처리량 기준선 등을 통해).

커널 커버리가 확인된 후에도 ROCm의 더 큰 운영 범위를 수용해야 할 이유는 처리량 아키텍처입니다 — 단일 사용자 테스트에서 몇 토큰/s 더 나오는 것이 아닙니다. 연속 배칭, 프레임워크 네이티브 양자화, 텐서 병렬성, 스케줄러 동작, 그리고 주변의 PyTorch 도구들이 vLLM으로 이동할 때의 진짜 논리이며, 그 이동이 옳은지 저울질하고 있다면, 우리 Ollama에서 vLLM으로 마이그레이션 가이드는 워크로드 신호를 나열합니다.

TGI: 더 좁은 목표를 가진 ROCm 지원

Hugging Face는 Text Generation Inference용 AMD 이미지를 문서화했지만, 공개된 검증은 Instinct MI210, MI250, MI300 하드웨어를 중심으로 합니다. TGI AMD 가이드는 3.3.5-rocm 이미지를 사용하며 지원되지 않는 ROCm 기능을 나열하므로, 모든 Radeon 카드에 대한 약속으로 일반화해서는 안 됩니다. 우리 TGI 설치 가이드가 그 ROCm 이미지 설정을 더 자세히 다룹니다.

비교할 Vulkan TGI 경로는 없습니다. TGI가 고정된 요구 사항이라면, 지원되는 ROCm 하드웨어를 선택하고 문서화된 컨테이너를 재현하세요; 엔진이 협의 가능(변경 가능)하다면, 새로운 AMD 배포를 시작하기 전에 현재 vLLM과 SGLang 지원에 대한 평가가 가치 있습니다.

LM Studio: 재빌드 대신 런타임 전환

LM Studio는 여러 추론 런타임을 패키징하고 lms 명령을 통해 런타임 관리를 노출합니다. 그 런타임 문서는 런타임 나열, 다운로드, 선택, 업데이트, 삭제를 지원하므로, 별도 소스 트리를 유지하지 않고도 ROCm 대 Vulkan 실험을 접근 가능하게 만듭니다.

lms runtime ls
lms runtime get
lms runtime select

동일한 컨텍스트 길이, GPU 오프로드, 플래시 어텐션 설정, 프롬프트로 동일한 GGUF를 실행하세요. 짧은 채팅 응답 하나에서 백엔드를 판단하기 대신, 첫 번째 토큰까지의 시간, 생성률, 로드 시간, 피크 메모리를 비교하세요.

런타임 패키징은 백엔드 특정 결함을 제거하지 않습니다. 예를 들어, 2026년 R9700의 LM Studio 이슈는 Vulkan 런타임이 이를 로드하는 동안 ROCm 로딩이 끝부분 근처에서 큰 모델이 멈추는 것을 보고했고, 별도의 Vulkan 메모리 여유 이슈는 VRAM이 거의 가득 찼을 때 반대 결과를 설명했습니다. 이들은 개별 보고서이지만, 함께 올바른 운영적 지점을 만듭니다: 폴백 런타임을 유지하고 메모리 여유를 남겨두세요.

LocalAI: 백엔드뿐 아니라 이미지도 선택하세요

LocalAI는 별도 ROCm 또는 hipblas 및 Vulkan 컨테이너 변형을 제공합니다. 그 GPU 가속 가이드는 AMD 컴퓨팅을 위한 gpu-hipblas 이미지와 포터블 경로를 위한 gpu-vulkan 이미지를 문서화하므로, CUDA 가이드에서 복사한 컨테이너 태그가 마법처럼 올바른 백엔드를 감지하지는 않습니다. LocalAI 퀵스타트는 일반적인 설정을 다루며, 백엔드 특정 컨테이너 선택은 이 섹션에서 추가하는 것입니다.

ROCm 컨테이너는 /dev/kfd와 /dev/dri가 필요하며, Vulkan은 일반적으로 /dev/dri 하의 적절한 렌더 장치가 필요합니다. 실제 서비스를 위해 릴리스 태그를 고정하세요; latest와 master는 진단에 유용하지만, 롤백과 성능 비교를 불필요하게 모호하게 만듭니다.

# ROCm or HIP image
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Vulkan image
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

태그 예시는 게시 시점에 이용 가능한 문서를 반영합니다; 자동화한 pull을 실행하기 전에 현재 레지스트리 이름을 확인하세요.更重要的是, 컨테이너 이름만으로 가속을 추론하지 마세요 — LocalAI의 디버그 로그를 검사하고 요청 중 GPU 사용률을 관찰하세요.

ROCm 10 패키징에서 무엇이 변경되었는가

ROCm 10은 또 다른 마이너 패키지 업데이트가 아닙니다. AMD의 TheRock 전환 가이드에 따르면, ROCm Core SDK 패키지는 이제 amdrocm- 접두사를 사용하고, 버전이 지정된 설치 루트는 /opt/rocm/core-10.0이며, 여러 레거시 패키지가 통합되었습니다.

이것이 왜 구형 ROCm 기사의 명령어가 올바르게 구성된 리포지토리에서도 “패키지 찾을 수 없음"을 반환할 수 있는지입니다. 예를 들어, HIPCC는 이제 amdrocm-llvm에서 온고, BLAS 구성 요소는 amdrocm-blas에 결합되며, 전체 시스템 설치는 모든 아키텍처 또는 GPU 패밀리 특정 Core SDK 메타 패키지를 사용할 수 있습니다 — RDNA 4 카드는 gfx120X-all 패밀리 태그(패키지 접미사 -gfx1200-gfx1201)를 사용하며, 존재하지 않는 gfx1201 전용 패키지 이름을 찾기 전에는 아는 가치가 있습니다.

amdrocm 메타 패키지는 /opt/rocm 하에 어льт네이티브(alternatives)와 호환성 심볼릭 링크를 구성합니다. 최소 또는 사용자 정의 설치에서는 동일한 경로를 제공하지 않을 수 있으므로, /opt/rocm/bin/hipcc를 하드 코딩한 빌드 스크립트는 hipconfig를 사용하거나 ROCM_PATH를 명시적으로 설정해야 합니다.

쉽게 놓칠 수 있는 두 가지 진단 변경 사항이 있습니다. ROCm SMI는 AMD SMI 대신 제거되었고, ROCm Bandwidth Test는 수명 종료(end of life)되었습니다. rocm-smi나 rocm-bandwidth-test를 호출하는 스크립트는 임의의 레거시 패키지를 다시 설치하는 것이 아니라 amd-smi와 AMD의 대체 도구로 이동해야 합니다.

컨테이너는 여전히 호스트에 의존합니다

ROCm 컨테이너는 사용자 공간 라이브러리를 포함하지만, 대체 커널 드라이버는 아닙니다. 호스트는 /dev/kfd와 /dev/dri를 노출해야 하며, 그 드라이버는 컨테이너 스택과 호환되어야 하고, 서비스 사용자는 تلك 장치를 열 권한이 있어야 합니다.

Vulkan 컨테이너는 호스트 Vulkan 드라이버와 렌더 노드 주위에 유사한 경계를 가집니다. 패키징은 가벼우지만, 잘못된 ICD, 누락된 렌더 그룹 멤버십, 또는 우연히 선택된 iGPU는 여전히 작동하는 컨테이너 이미지를 CPU-bound 또는 불안정한 서비스로 만들 수 있습니다.

디스크리트 GPU, APU, 구형 Radeon 카드

RDNA 3 및 RDNA 4 디스크리트 GPU

현재 Radeon RX 7000, RX 9000 및 Radeon AI Pro 모델은 두 llama.cpp 백엔드를 모두 테스트할 가장 강력한 근거를 가지고 있습니다. ROCm 지원은 이제 많은 gfx110x 및 gfx120x 타깃에 대해 명시적이며, 현재 Mesa RADV 또는 Windows 벤더 드라이버를 통한 Vulkan은 절망적인 폴백이 아니라 1차 경로가 될 만큼 성숙했습니다. 그 결정의 하드웨어 측면(벤더에 걸친 VRAM, 대역폭, 전력, 가격)에 대해서는 우리 2026년 AI 워크로드용 GPU 비교를 참고하세요.

7B 벤치마크를 27B Dense 모델 또는 혼합 전문가(mixture-of-experts) 모델에 대한 규칙으로 전환하지 마세요. 행렬 구조, 활성 매개변수, 양자화 커널, 프롬프트 길이, 메모리 압력이 순서를 변경할 수 있으며, 백엔드 성능은 llama.cpp 리비전 사이에 상당하게 이동했습니다 — 위에서 언급한 gfx1201 히든 사이즈 회귀는 정확히 이러한 유형의 변화의 구체적 사례입니다.

Ryzen APU 및 공유 메모리

대용량 Ryzen AI Max 시스템은 GPU가 정상적인 디스크리트 소비자 카드가 제공하는 것보다 훨씬 더 큰 공유 메모리 풀에 액세스할 수 있기 때문에 특별히 흥미롭습니다. ROCm 10은 현재 Ryzen AI 패밀리가 나열되어 있으며, Vulkan 지원 llama.cpp 런타임은 PyTorch 환경을 빌드하지 않고도 iGPU를 사용할 수 있습니다.

용량은 대역폭이 아닙니다. 할당된 64GB 또는 96GB 공유 메모리에 모델이 맞춰진다는 것이 32GB 디스크리트 카드처럼 디코딩될 것이라는 의미는 아니며, 애플리케이션이 충분한 GPU 메모리를 보고하더라도 공격적인 컨텍스트 할당은 운영체제를 기아 상태로 만들 수 있습니다. 디스크리트 NVIDIA 및 AMD 카드에 적용되는 동일한 VRAM 예산 규율이 여기에도 적용됩니다 — 기본 예산 산술은 백엔드에 무관하므로, 16GB GPU의 KV 캐시를 참고하세요.

iGPU와 dGPU가 혼합된 기계는 명시적인 장치 선택이 필요합니다. 최근 llama.cpp 보고서는 R9700 옆에 사용되지 않는 iGPU가 가시적으로 남아 있을 때 과도한 시스템 메모리 예약을 설명했는데, 이는 확인되지 않은 이슈이지만, 서비스 의도로 사용하려는 장치를만 노출해야 할 좋은 이유입니다.

구형 및 미지원 Radeon 하드웨어

Vulkan은 그래픽 드라이버 커버리지가 ROCm의 지원 컴퓨팅 타깃 세트보다 넓기 때문에 구형 Radeon에 대한 1차 경로인 경우가 많습니다. ROCm 기반 프로젝트는 또한 새로운 rocBLAS 릴리스가 일부 구형 타깃에 대한 커널을 제거했음을 지적하므로, 가까운 gfx 값을 강제해도 더 이상 배송되지 않는 코드를 복구할 수 없습니다.

명확한 실패 기대치를 가진 실험실 실험에는 오버라이드가 허용됩니다. 그것은 비조작(non-unattended) API에 대해서는 좋지 않은 기초입니다. 왜냐하면 다음 ROCm 또는 애플리케이션 업데이트가 용인되던 불일치를 시작 실패나 잘못된 결과로 대체할 수 있기 때문입니다.

AMD LLM 백엔드를 위한 Linux 대 Windows

Linux는 프로덕션 추론을 위한 자연스러운 ROCm 호스트입니다. 가장 넓은 엔진 지원, 확립된 컨테이너 장치 매핑, 현재 Mesa Vulkan 드라이버, 그리고 vLLM 및 SGLang 배포에서 기대하는 운영 도구를 제공합니다.

Windows는 목록에 있는 하드웨어에 대해 진정으로 ROCm 지원을 가지고 있지만, 애플리케이션 생태계는 여전히 좁습니다. llama.cpp, Ollama, LM Studio를 통한 데스크톱 GGUF 추론에 대해, Vulkan은 일반적으로 더 안정적인 시작점입니다; 애플리케이션이 지원되는 Windows 경로를 제공하고 구체적인 기능 또는 벤치마크가 이를 정당화할 때 ROCm을 사용하세요.

WSL2는 네이티브 Linux의 동의어가 아니라 제3의 플랫폼으로 취급해야 합니다. AMD의 문서화된 Windows 드라이버, WSL 배포판, ROCm 릴리스, 프레임워크 패키지를 하나의 지원되는 조합으로 매칭하세요.

트래픽 서빙 전 검증 체크리스트

애플리케이션 아래에서 시작하세요. 드라이버가 올바른 장치를 열거할 수 없다면, 모델 플래그를 변경하는 것은 단순히 증상을 재배열하는 것입니다.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# ROCm path
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Vulkan path
vulkaninfo --summary

그런 다음 엔진을 검증하세요. 시작 출력은 ROCm 또는 Vulkan을, 의도한 GPU를, 그리고 모델 레이어나 텐서가 그것에 배치되었음을 보고해야 합니다; 마지막으로, 요청이 실행되는 동안 GPU 메모리와 사용률이 상승해야 합니다.

# Observe an AMD GPU while another terminal sends requests
watch -n1 amd-smi monitor

# Basic OpenAI-compatible API check for llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

모든 벤치마크와 함께 드라이버, 런타임, 엔진 커밋 또는 이미지 다이제스트, 모델 파일 체크섬, 컨텍스트, 배치 설정, 명령 줄을 기록하세요. 그 메타데이터 없이는, 토큰-퍼-초 숫자는 다음 업그레이드를 견디지 못하는 일화이며 — vLLM-on-gfx1201 폴백과 위의 Vulkan 히든 사이즈 회귀가 모두 보여주듯, 그럴듯해 보이는 숫자는 조용히 비최적화된 코드 경로를 감출 수 있습니다.

백엔드 성능으로 보이는 실패 모드

조용한 CPU 폴백

서버가 시작되고 올바르게 응답하지만, 생성이 의외로 느리고 GPU 사용률이 평탄합니다. 스레드나 샘플링 매개변수를 튜닝하기 전에 탐색 로그, 장치 권한, 모델 오프로드, 컨테이너 장치를 확인하세요.

조용한 정밀도 폴백 (새 하드웨어, 새 커널)

서버가 시작되고, GPU 사용률이 합리적으로 보이고, 오류가 없는데 — GPU의 컴퓨팅 능력 또는 아키텍처 문자열이 아직 인식되지 않아 프레임워크가 조용히 비최적화 숫자 경로로 드롭했습니다. 이는 정확히 gfx1201에서 vLLM의 FP8 커널에 일어난 일입니다; 수정 방안은 마지막 릴리스 사이클 또는 두 번 이내에 출시된 GPU 세대에서의 단일 처리량 숫자를 신뢰하기 전에, 정확한 GPU 문자열에 대해 프레임워크 자체의 플랫폼 감지 코드나 이슈 트랙커를 확인하는 것입니다.

잘못된 GPU 선택

Ryzen 데스크톱은 iGPU를 Vulkan device 0으로, 디스크리트 Radeon을 device 1로 노출할 수 있습니다. 가시 장치를 제한하고 로그에서 전체 장치 이름을 확인하세요; 드라이버 또는 BIOS 변경 후 번호 매김이 안정적이라고 가정하지 마세요.

ROCm 타깃 불일치

rocminfo는 하나의 gfx 타깃을 보고하지만, 애플리케이션 이미지는 다른 세트의 커널을 포함합니다. 매칭된 이미지를 사용하거나 정확한 타깃으로 재빌드하세요; HSA_OVERRIDE_GFX_VERSION은 명시적으로 미지원된 실험용으로만 예약하세요.

드라이버와 사용자 공간 불일치

컨테이너에는 현재 ROCm 라이브러리가 있지만 호스트 드라이버는 구형 릴리스 스트림에 속합니다. 탐색 중 타임아웃, 커널 런치 오류, 또는 CPU 폴백은 버전 경계를 설명하는 깔끔한 메시지보다 더 가능성이 높습니다.

Vulkan ICD 혼동

Vulkan 구현이 하나 이상 설치되어 있고, 로더가 예상하지 못한 ICD를 선택합니다. vulkaninfo를 검사하고, 우발적인 중복을 제거하거나, 의도한 ICD와 장치를 명시적으로 선택하세요; 문제를 덮기 위해 다른 SDK를 적층하지 마세요.

VRAM 추정치가 운영 마진을 남기지 않음

모델이 맞춰지는 것으로 보이지만 워밍업, 플래시 어텐션 설정, 또는 첫 번째 긴 프롬프트 중에 실패합니다. 큰 모델에서 여러 기가바이트의 여유를 남겨두세요; 그렇지 않으면 백엔드가 그 양자화를 실행할 수 없다고 결론내리기 전에 컨텍스트나 배치 크기를 줄이세요.

실용적인 백엔드 선택 절차

단계 1: 서빙 동작 선택

목표가 로컬 사용자 1~2명, GGUF 파일, 단순한 OpenAI 호환 엔드포인트라면, llama-server, Ollama, LM Studio로 시작하세요. 목표가 연속 배칭, 높은 동시성, 프레임워크 네이티브 모델, 또는 텐서 병렬성이라면, vLLM 또는 SGLang로 시작하고 설계의 일부로서 ROCm을 수용하세요.

단계 2: 공식 하드웨어 지원 확인

현재 ROCm 매트릭스에서 정확한 GPU 타깃, 운영체제 버전, 커널, 드라이버를 매칭하세요. Vulkan의 경우, vulkaninfo를 통해 의도한 GPU를 확인하고, libvulkan.so의 존재가 유용한 컴퓨팅 지원을 증명한다고 가정하기보다 현재 드라이버를 사용하세요. GPU가 최신 아키텍처 세대라면, 또한 공식 지원과 최적화 커널 지원이 항상 동시에 릴리스되는 것이 아니므로, 정확한 gfx 타깃에 대해 특정 프레임워크의 플랫폼 감지 코드 또는 오픈 이슈를 확인하세요.

단계 3: 가장 간단한 작동하는 기준선 확립

GGUF의 경우, Vulkan이 시스템 구성 요소를 덜 변경하므로 일반적으로 그 기준선입니다. PyTorch 엔진의 경우, 관련 없는 최신 버전에서 torch, Triton, AITER, vLLM을 조립하기보다 AMD의 고정된(pinned) ROCm 컨테이너를 사용하세요.

단계 4: 프로덕션 형태의 프롬프트 벤치마크

프롬프트 처리, 첫 번째 토큰까지의 시간, 디코드 속도, 피크 메모리, 동시 요청 동작을 측정하세요. 실제 서비스가 사용할 컨텍스트와 도구 호출 패턴을 포함하세요; 128-토큰 마이크로 벤치마크는 100,000-토큰 에이전트 세션을 예측하지 못합니다.

단계 5: 폴백을 배포 가능하게 유지

두 llama.cpp 빌드 디렉토리는 드라이버 회귀로 잃은 하루에 비해 비용이 거의 들지 않습니다. 마지막으로 알려진 정상적인 컨테이너 다이제스트나 런타임을 설치되어 있고, 후보가 동일한 테스트 세트를 통과한 후에만 앞으로 롤-forward 하세요.

동일한 절차를 결정 플로우로서:

flowchart LR A["서빙 엔진 선택"] --> B{"PyTorch/HIP 엔진?"} B -- 예 --> C["ROCm: 고정된 컨테이너
+ 커널-커버리지 확인"] B -- 아니오 --> D{"AMD GPU에서 GGUF?"} D -- 예 --> E["Vulkan 기준선"] E --> F{"벤치마크: ROCm이 측정 가능한
마진으로 이기나?"} F -- 예 --> G["ROCm으로 전환"] F -- 아니오 --> H["Vulkan 유지,
ROCm 빌드를 폴백으로 유지"]

최종 판단: AMD LLM 호스팅에 ROCm인가 Vulkan인가?

Vulkan은 포터빌리티, 설정 속도, Windows 지원, 또는 구형 Radeon 커버리지가 중요한 경우 로컬 GGUF 추론을 위한 가장 좋은 기본값입니다. 더 이상 본질적으로 느리다고 설명하는 것은 합리적이지 않습니다; 일부 최근 Radeon 및 llama.cpp 조합에서는 더 빠른 백엔드이며, 다른 것에서는 운영 마찰이 낮아 승리할 정도로 충분히 가깝습니다.

ROCm은 엔진이 PyTorch를 중심으로 구축되었을 때, AMD Instinct와 멀티 GPU 컴퓨팅이 중심일 때, 또는 테스트된 HIP 빌드가 실제 모델 워크로드에서 이겼을 때 올바른 선택입니다. 그 생태계는 2026년에 훨씬 더 강력하지만, 새로운 패키징과 엄격한 호환성 레이어는 여전히 고정된 버전과 규율 있는 검증을 보상합니다 — 그리고 특히 최신 RDNA 세대에서는, 최적화 커널 경로가 실제로 실행되었는지 검증하는 것은 선택이 아닙니다.

지원되는 Radeon 워크스테이션에 대한 제 권장 사항은 의도적으로 낭만적이지 않습니다: Vulkan을 먼저 설치하고, 엔진이나 벤치마크가 그 복잡성을 정당화할 때 ROCm을 추가하고, 기계가 정기적으로 다른 모델 구조를 서빙한다면 두 llama.cpp 빌드를 모두 유지하세요. 최고의 AMD 백엔드는 카드의 영구적인 속성이 아닙니다; 그것은 카드, 엔진, 모델, 드라이버, 워크로드가 함께 가진 속성입니다.

참고 문헌

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.