Molayo

© 2026 Molayo

Zenn헤드라인2026. 05. 15. 11:24

로컬 LLM을 가속시키려다 Ubuntu를 매장하고, 다시 부활시키기까지

요약

Ryzen AI 9 HX370 탑재의 MINISFORUM X1 Pro 370에서 로컬 LLM 구동을 시도하며 하드웨어 및 OS 레벨의 복합적인 문제를 겪었다. 첫 번째 난관은 UMA 프레임 버퍼를 과도하게 늘리려다 발생한 PCI BAR 충돌로 인한 '의사 벽돌' 상태였으며, 두 번째는 Secure Boot 환경에서 서명되지 않은 구형 드라이버 잔해가 최신 커널 로드를 방해하여 해상도 문제를 일으킨 것이었다. 최종적으로 미서명 드라이버를 제거하고 Ubuntu 공식 OEM 커널을 도입함으로써 시스템을 안정화시키고 원하는 성능(Qwen3-coder-next 80B 구동)을 확보했다.

핵심 포인트

  • 과도한 UMA 프레임 버퍼 설정은 PCI BAR 충돌 및 IOMMU 혼란을 야기하여 시스템 부팅 실패('의사 벽돌')를 초래할 수 있다.
  • Secure Boot 환경에서는 서명되지 않은 구형 드라이버 잔해가 최신 커널 로드를 방해하는 주요 원인이 될 수 있다.
  • 시스템 안정성을 확보하고 원하는 기능을 사용하기 위해서는 미서명된 과거의 드라이버(DKMS)를 제거하고 공식 OEM 커널을 사용하는 것이 가장 확실한 해결책이다.
  • ROCm 도입과 메모리 할당 변경을 통해 대규모 LLM (예: Qwen3-coder-next 80B)을 로컬 환경에서 현실적인 속도로 구동할 수 있다.

MINISFORUM X1 Pro 370을 손에 넣었습니다.

탑재된 Ryzen AI 9 HX370은 iGPU (Radeon 890M)의 성능이 매우 높아, 로컬에서 LLM을 돌릴 수 있을까? 하는 큰 기대를 품고 있었습니다. 특히 시스템 메모리를 96GB나 탑재했으니, "VRAM (UMA Frame Buffer)을 극한까지 늘리면 70B 클래스의 모델도 돌아가지 않을까?"라고 생각하는 것은 자연스러운 흐름입니다.

하지만 그곳에 잠복해 있었던 것은 **「하드웨어의 침묵」과 「OS의 거부」**라는 이중의 함정이었습니다.

제1 페이즈: 침묵하는 PC ─ 왜 「UMA를 늘리면 벽돌이 되는가」?

사건의 발생

BIOS 설정에서 UMA Frame Buffer Size를 48GB로 부스트. 저장하고 재부팅한 순간, PC는 침묵... 제조사 로고조차 표시되지 않고 팬만 계속 돌아가는 「의사 벽돌(Pseudo-brick)」 상태가 되었습니다.

왜 거대한 프레임 버퍼는 PC를 멈추게 하는가?

원인은 **「PCI 버스의 메모리 자원 (BAR) 고갈과 충돌」**이라고 합니다.

  • PCI BAR의 충돌: GPU가 VRAM으로 사용하는 영역은 CPU에서 보이는 「창 (BAR: Base Address Register)」으로서 매핑됩니다. UMA를 크게 (32GB 등) 설정하면, BIOS가 부팅 시 이 「창」을 확보하려고 시도하지만, 다른 장치 (NVMe나 NIC)의 메모리 주소와 충돌하여 어드레스 계산을 하지 못하고 포스트 (POST: Power-On Self-Test)에 실패합니다.
  • IOMMU의 혼란: 96GB라는 광활한 어드레스 공간에서 거대한 UMA 영역을 확보하면, 메모리의 교통정리 역할을 하는 IOMMU가 정상적인 맵을 생성하지 못해 부트로더에 제어를 넘기기 전에 시스템이 행(Hang) 상태에 빠집니다.

【부활책】

이 상태에서는 키보드 조작이 전혀 통하지 않았기에, 본체 뒷면에 있는 리셋 버튼으로 CMOS 클리어. 강제로 공장 출하 시의 UMA 설정으로 되돌림으로써 부활했습니다.

제2 페이즈: 나타났다, 하지만 낮다. 해상도 1080p의 지옥

CMOS 클리어로 로고는 볼 수 있게 되었지만, Ubuntu가 실행되자 1920×1080의 흐릿한 화면이 나타났습니다. 울트라 와이드 해상도는 선택지에서 사라져 있었습니다.

조사: 범인은 「과거의 유산 (시한폭탄)」이었다

터미널에서 원인을 찾으니 다음과 같은 사실이 판명되었습니다.

$ sudo modprobe amdgpu
Error: could not insert 'amdgpu': key was rejected by service

「Key was rejected」

이것은 Secure Boot가 활성화된 환경에서, **「서명되지 않은 부정 드라이버」**를 읽어들이려 할 때 발생하는 에러입니다.

사실 이전에 설치했던 AMD 공식 DKMS 버전 드라이버의 잔해가 SSD에 남아 있었습니다. 새로운 OEM 커널이 도입되는 타이밍에 자동 빌드가 실행되었고, 「서명되지 않은 드라이버」로서 Secure Boot에 의해 차단되었던 것입니다.

공식 드라이버 (의 잔해)가 Ubuntu 표준의 「서명된 드라이버」의 경로를 가로막고 있었던 것이 저해상도의 진범이었습니다.

최종 해결책: 비공식은 버리고, 공식 OEM 커널로

결과적으로, **「Ubuntu 공식 서명된 최신 커널」**을 사용하는 것이 가장 안전하고 확실한 길이었습니다.

1. 과거의 시한폭탄 (미서명 드라이버) 제거

# DKMS에 남아 있는 미서명 드라이버 확인
sudo dkms status
# 해당 드라이버를 모두 삭제 (버전은 환경에 맞춰 읽어주세요)
...

2. 서명된 「OEM 커널」 도입

sudo apt update
sudo apt install linux-oem-24.04d # Ubuntu 24.04
sudo update-initramfs -u
...

3. 부활의 순간

재부팅 후, 드라이버를 강제 로드합니다.

sudo modprobe amdgpu

에러 없음. 다음 순간, 화면이 울트라 와이드의 선명한 표시로 전환되었습니다.

여담

이 기사 등을 참고하여 ROCm을 도입하고 메모리 할당을 변경함으로써 **Qwen3-coder-next (80B)**를 현실적인 속도로 실행할 수 있게 되었습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0