BC-250를 활용한 AI 프로젝트: 환경 세팅

1. BIOS 패치

1-1. 사용한 BIOS

최종 선택한 BIOS는 아래 파일입니다.

• 문서: BIOS Flashing Guide - AMD BC250 Documentation
• 사용 파일: BC250_3.00_CHIPSETMENU.ROM

검증된 SHA256 값은 아래와 같습니다.

48fbe5d366e6a56e2fdffdca848426216ba1f083610dab63db89d2f4e6c940b5

이 파일은 Modded P3.00 / VRAM + Chipset Menu unlock / recommended 버전입니다.

사용하지 않은 파일은 아래와 같습니다.

별도로 설치 과정을 스크립트화 하여
통파일 공유합니다.

https://drive.google.com/file/d/1-DAJq46PW2cH1GvSTXQDeRBSisISpDWz/view?usp=drive_link

ROM 파일은 SHA256 검증을 통해
변조 파일이 아닌지 확인한 뒤 사용하는 것을 권장합니다.

배포 페이지에서 롬 파일이 업데이트될 경우,
위 SHA256 값과 일치하지 않을 수 있습니다.

파일 다운로드 기준일: 2026/06/17

BIOS 플래싱은 실패 시 장비가 부팅되지 않을 수 있습니다.
반드시 기존 BIOS를 백업한 뒤 진행해야 하며,

플래싱 중 전원 차단이 발생하지 않도록 주의해야 합니다.

1-2. EFI 부팅 USB 제작

USB는 FAT32로 포맷한 뒤, 최상위 경로에 필요한 파일을 복사합니다.

최종 USB 구조는 아래와 같습니다.

USB:\
├─ EFI\
├─ AfuEfix64.efi
├─ Robin5.00.rom
├─ startup.nsh
├─ 1.nsh
└─ 2.nsh

Robin5.00.rom은 실제로 BC250_3.00_CHIPSETMENU.ROM 파일명을 변경한 것입니다.

Robin5.00.rom = BC250_3.00_CHIPSETMENU.ROM

즉, 실제 내용물은 배포 페이지에서 받은 패치 BIOS입니다.

1-3. BIOS 플래싱 스크립트 실행

BIOS 플래싱은 EFI Shell에서 명령어를 직접 입력하지 않도록
startup.nsh, 1.nsh, 2.nsh로 나누어 구성했습니다.

USB 부팅 후 EFI Shell에서 startup.nsh가 자동 실행되면,
먼저 기존 BIOS 백업이 진행됩니다.

백업이 성공하면 USB에 아래 파일이 생성됩니다.

OLD.ROM
16,777,216 bytes

스크립트 역할은 아래와 같습니다.

startup.nsh : USB 위치 탐색, 파일 확인, 기존 BIOS 백업
1.nsh       : 백업만 확인하고 종료
2.nsh       : 백업 확인 후 BIOS 플래싱 진행

startup.nsh는 fs0:부터 fs5:까지 탐색하면서
AfuEfix64.efi와 Robin5.00.rom 파일이 있는지 확인합니다.

이후 기존 BIOS를 OLD.ROM으로 백업하고,
백업 파일이 생성되었는지 확인합니다.

이후 1.nsh, 2.nsh는
숫자 입력으로 선택 실행할 수 있도록 구성했습니다.

수동 명령어 방식으로 진행하려면 아래 형태를 참고하면 됩니다.

fs[번호]:
ls

AfuEfix64.efi [백업_바이오스_파일명.ROM] /O
AfuEfix64.efi [플래싱할_바이오스_파일명.rom] /P /B /N /K /X /RLC:E

전체 사용 순서는 아래와 같습니다.

1. USB를 FAT32로 포맷한다.
2. 필요한 파일을 USB 최상위 경로에 복사한다.
3. BC-250에서 EFI Shell로 부팅한다.
4. `startup.nsh`가 자동 실행되는지 확인한다.
5. `OLD.ROM` 백업 파일이 생성되었는지 확인한다.
6. 플래싱하지 않을 경우 `1.nsh`를 실행한다.
7. 플래싱할 경우 `2.nsh`를 실행한다.
8. 플래싱 완료 후 전원을 종료한다.
9. 전원 케이블을 제거한다.
10. BIOS Cell 배터리를 제거한다.
11. 전원 버튼을 몇 차례 눌러 잔류 전류를 제거한다.
12. 1분 대기 후 BIOS Cell 배터리와 전원 케이블을 다시 장착한다.
13. 부팅 후 BIOS에 진입해 필요한 옵션을 다시 설정한다.

1-4. BIOS 패치 성공 확인

패치 후 BIOS에서 아래 메뉴들이 표시되었습니다.

확인된 설정은 아래와 같습니다.

Boot Mode = UEFI는 나중에 M.2나 Fedora 설치 USB 꽂으면 다시 확인하면 됩니다.

2. OS 설치

2-1. 선택한 이미지

Workstation 대신 Server 이미지 방향으로 결정했습니다.

공식 사이트에서는 Fedora Server 44 버전으로 제공되고 있었기 때문에,
필자는 아래 미러 사이트에서 Fedora Server 43 이미지를 다운로드했습니다.

https://free.nchc.org.tw/fedora/linux/releases/43/Server/x86_64/iso/

사용한 이미지는 아래 파일입니다.

Fedora-Server-netinst-x86_64-43-1.6.iso

선택 이유는 아래와 같습니다.

DVD 이미지와 netinst 이미지의 차이는 아래와 같습니다.

이번 환경에서는 인터넷 사용이 가능했기 때문에 netinst 선택이 적합했습니다.

OS 설치 과정은 아래 사이트를 참조해주세요.

Fedora 43 (F43) Installation

This article provides a pictorial guide for performing a basic server installation of Fedora 43 (F43).

oracle-base.com

2-2. 설치 후 기본 업데이트

OS 설치 후 기본 업데이트를 진행했습니다.

sudo dnf update -y
sudo reboot

2-3. nomodeset 관련

BC-250 문서에서는 Linux 설치 과정에서 nomodeset 사용을 안내합니다.

nomodeset은 설치 중 GPU 드라이버 초기화로 인해
화면 출력이 꼬이거나 부팅이 멈추는 문제를 피하기 위한 임시 부팅 옵션입니다.

쉽게 말하면, 설치 단계에서는 GPU 모드 세팅을 막아서
일단 OS 설치를 안정적으로 진행하기 위한 옵션입니다.

다만 설치 후 Mesa RADV Vulkan 드라이버를 설치하고
amdgpu가 정상 인식되면 nomodeset은 제거해야 합니다.

nomodeset이 남아 있으면 GPU 모드 세팅이 제한되어
Vulkan 기반 llama.cpp 구동에 문제가 생길 수 있습니다.

현재 부팅 옵션은 아래 명령으로 확인할 수 있습니다.

cat /proc/cmdline

출력에 nomodeset이 없다면 별도 조치 없이 진행하면 됩니다.
출력에 nomodeset이 남아 있다면 제거 대상입니다.

Fedora 기준으로는 아래 명령으로 제거할 수 있습니다.

sudo grubby --update-kernel=ALL --remove-args="nomodeset"
sudo reboot

이번 환경에서는 최종적으로 아래 항목들이 정상 확인되었습니다.

Kernel driver in use: amdgpu
deviceName = AMD BC-250 (RADV GFX1013)
driverName = radv

따라서 최종 상태 기준으로는 amdgpu와 Mesa RADV Vulkan 경로가 정상 동작하는 상태로 판단했습니다.

정리하면 아래와 같습니다.

설치 전/설치 중: nomodeset = 안전 부팅용
드라이버 세팅 후: nomodeset 제거 = GPU 정상 사용용

3. AMD GPU / Mesa RADV Vulkan 세팅

3-1. 설치한 패키지

BC-250은 Linux 커널의 amdgpu 드라이버로 장치가 인식되며, 실제 Vulkan 기반 추론에는 Mesa RADV 드라이버를 사용합니다.

Mesa / Vulkan 관련 패키지는 아래와 같이 설치했습니다.

sudo dnf install -y \
  mesa-vulkan-drivers \
  vulkan-tools \
  vulkan-loader \
  mesa-dri-drivers \
  libdrm

기본 관리 도구도 함께 설치했습니다.

sudo dnf install -y \
  git curl wget vim nano htop btop tmux \
  pciutils usbutils lshw lm_sensors smartmontools \
  kernel-tools

3-2. GPU 인식 확인

GPU 인식 확인 명령은 아래와 같습니다.

lspci -k | grep -A4 -Ei "vga|display|amd|ati"

성공 확인 결과는 아래와 같습니다.

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cyan Skillfish [BC-250]
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

판정은 아래와 같습니다.

• BC-250 GPU 인식 성공
• amdgpu 드라이버 로드 성공

3-3. Vulkan 확인

Vulkan 확인 명령은 아래와 같습니다.

vulkaninfo --summary

성공 확인 결과는 아래와 같습니다.

deviceName         = AMD BC-250 (RADV GFX1013)
driverName         = radv
driverInfo         = Mesa 25.3.6
deviceType         = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU

판정은 아래와 같습니다.

• Vulkan / RADV 인식 성공
• GFX1013 정상 인식
• Mesa 25.3.6 사용

아래 경고가 표시되었지만, 치명적인 문제는 아니었습니다.

libvulkan_dzn.so 관련 경고
DISPLAY environment variable not set
llvmpipe 표시

각 경고에 대한 판단은 아래와 같습니다.

4. TTM / Swap

4-1. TTM 설정

목표값은 아래와 같습니다.

4194304

확인 명령은 아래와 같습니다.

cat /sys/module/ttm/parameters/pages_limit
cat /sys/module/ttm/parameters/page_pool_size

적용 명령은 아래와 같습니다.

echo 4194304 | sudo tee /sys/module/ttm/parameters/pages_limit
echo 4194304 | sudo tee /sys/module/ttm/parameters/page_pool_size

영구 적용은 아래와 같이 진행했습니다.

echo "options ttm pages_limit=4194304 page_pool_size=4194304" | \
sudo tee /etc/modprobe.d/ttm-gpu-memory.conf

printf "w /sys/module/ttm/parameters/pages_limit - - - - 4194304\nw /sys/module/ttm/parameters/page_pool_size - - - - 4194304\n" | \
sudo tee /etc/tmpfiles.d/gpu-ttm-memory.conf

sudo dracut -f
sudo reboot

4-2. Swap 상태

처음 확인 결과는 아래와 같았습니다.

Mem: 14Gi
Swap: 8.0Gi
/dev/zram0 8G

즉, Fedora 기본 zram 8GB만 활성화된 상태였습니다.

추가로 16GB swapfile을 생성했습니다.

sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon -p 10 /swapfile
echo '/swapfile none swap sw,pri=10 0 0' | sudo tee -a /etc/fstab

zram 축소 방향은 아래와 같이 잡았습니다.

sudo mkdir -p /etc/systemd/zram-generator.conf.d
cat <<'EOF' | sudo tee /etc/systemd/zram-generator.conf.d/small.conf
[zram0]
zram-size = 2048
EOF

sudo reboot

5. llama.cpp Vulkan 빌드

5-1. 빌드 의존성 설치

처음 빌드 시 SPIRV-Headers 누락으로 실패했습니다.

에러는 아래와 같았습니다.

Could not find a package configuration file provided by "SPIRV-Headers"

해결을 위해 아래 패키지를 설치했습니다.

sudo dnf install -y \
  git cmake ninja-build gcc gcc-c++ make \
  vulkan-headers vulkan-loader-devel glslc \
  python3 python3-pip \
  spirv-headers-devel \
  glslang-devel \
  spirv-tools-devel

주의할 점은 아래와 같습니다.

Fedora 패키지명은 SPIRV-Tools-devel 이 아니라 spirv-tools-devel

5-2. llama.cpp 다운로드

llama.cpp는 GitHub에서 직접 클론했습니다.

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

5-3. Vulkan 빌드

Vulkan 옵션을 켜고 빌드했습니다.

cmake -B build -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j$(nproc)

빌드 성공 확인은 아래 명령으로 진행했습니다.

ls build/bin

확인된 주요 파일은 아래와 같습니다.

llama-cli
llama-bench
llama-server
libggml-vulkan.so

Vulkan 링크 확인 명령은 아래와 같습니다.

ldd ./build/bin/llama-cli | grep -i vulkan

성공 결과는 아래와 같습니다.

libggml-vulkan.so.0 => /home/sonny/llama.cpp/build/bin/libggml-vulkan.so.0
libvulkan.so.1 => /lib64/libvulkan.so.1

판정은 아래와 같습니다.

llama.cpp Vulkan 백엔드 빌드 성공

6. 모델 다운로드

6-1. Hugging Face CLI 설치

GGUF 모델 파일은 Hugging Face에서 다운로드했습니다.

hf 명령을 사용하기 위해 Hugging Face Hub CLI를 설치했습니다.

python3 -m pip install -U "huggingface_hub[cli]" --user

설치 후 사용자 로컬 바이너리 경로를 PATH에 추가했습니다.

export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

hf 명령이 정상적으로 잡히는지 확인합니다.

hf --help

6-2. Xet 비활성화 필요

일반 hf download 명령으로 다운로드를 시도했을 때
다운로드 프로세싱 로그는 올라오지만 다운로드가 진행이 안됩니다.

따라서 아래 환경변수를 사용해 Xet 전송 경로를 비활성화했습니다.

HF_HUB_DISABLE_XET=1

성공한 다운로드 명령은 아래와 같습니다.

HF_HUB_DISABLE_XET=1 hf download Qwen/Qwen2.5-3B-Instruct-GGUF \
  qwen2.5-3b-instruct-q4_k_m.gguf \
  --local-dir ~/models

7. llama.cpp 실행 테스트

7-1. 기본 실행

기본 실행 명령은 아래와 같습니다.

cd ~/llama.cpp

./build/bin/llama-cli \
  -m ~/models/qwen2.5-3b-instruct-q4_k_m.gguf \
  -p "Explain Vulkan in one sentence." \
  -n 128 \
  -ngl 999 \
  --no-display-prompt

핵심 옵션은 아래와 같습니다.

7-2. 성능 확인

프롬프트 기반으로 실제 로그 분석을 시켜보았을 때 아래 속도를 확인했습니다.

Qwen2.5 3B Q4 기준으로는 꽤 빠른 편이며,
llama.cpp Vulkan 구동은 성공한 것으로 판단했습니다.

다만 실제 보안 로그 분석 결과에는 일부 모순과 오탐이 있었습니다.
예를 들면 전체 위험도를 위험으로 판단하면서도,

침해 성공 근거와 차단 후보가 없다고 출력하는 식입니다.

모델별 차이도 있을 것이지만,
사용 된 모델 기준으로는 LLM 단독 판단보다는

아래 방식이 적합하다고 판단했습니다.

룰 기반 전처리
→ 의심 경로 / 크롤러 / 정상 Ghost API / 성능 경고 추출
→ LLM은 해석과 보고서 작성만 담당

7-3. GPU 사용률 확인 관련

sudo dnf install -y btop

btop에서는 GPU 사용률이 0%로 보이는 경우가 있었습니다.

btop의 gpu_busy_percent 표시는 BC-250 / RADV / Vulkan 사용률을 정확히 반영하지 못할 수 있음

더 확실한 비교 방법은 llama-bench를 사용하는 것입니다.

GPU offload 사용:

cd ~/llama.cpp

./build/bin/llama-bench \
  -m ~/models/qwen2.5-3b-instruct-q4_k_m.gguf \
  -ngl 999

CPU only 비교:

cd ~/llama.cpp

./build/bin/llama-bench \
  -m ~/models/qwen2.5-3b-instruct-q4_k_m.gguf \
  -ngl 0

판정 기준은 아래와 같습니다.

-ngl 999가 -ngl 0보다 확실히 빠르면 GPU offload 정상

8. 로그 분석 테스트

8-1. 대화형 입력 문제

처음에는 llama-cli 대화형 상태에서 로그를 붙여넣으니 한 줄씩 별도 대화로 입력되는 문제가 있었습니다.

해결 방식은 아래와 같습니다.

-f prompt.txt

즉, 프롬프트 파일로 한 번에 입력하는 방식입니다.

예시는 아래와 같습니다.

./build/bin/llama-cli \
  -m ~/models/qwen2.5-3b-instruct-q4_k_m.gguf \
  -f ~/log_prompt.txt \
  -n 1024 \
  -ngl 999 \
  --no-display-prompt

8-2. 컨텍스트 초과 문제

긴 로그 전체를 한 번에 넣으면 실패했습니다.

에러는 아래와 같았습니다.

request (111650 tokens) exceeds the available context size (32768 tokens)

24시간 로그 전문을 원문 그대로 한 번에 넣는 방식은 불가능
chunk 분석 또는 룰 기반 전처리 필요

8-3. 현재 확인된 방향

LLM 단독 분석은 오탐이 있었습니다.

실제 LLM 추론 후 대답안을 예시로 들겠습니다.

## 전체 위험도: 위험

### 핵심 요약

요청 대부분은 공격 목록에 명시되지 않은 경로와 주소로 이루어져 있다.

일부 요청은 정상 Ghost API 요청으로 분류되었지만, 실제 침해 성공 근거는 확인되지 않았다.

크롤러 가능성 분석에서는 대부분의 요청이 크롤러로 분류되었다.

실제 침해 성공 근거를 찾지 못했으므로, 위협으로 단정하지는 않는다. 다만 일부 요청이 특정 경로로 접근한 것으로 보여 위험 수준은 유지한다.

---

### 정상 요청 판단

정상 API 요청은 아래 경로를 포함한다.

```text
/members/api/member/
/ghost/api/content/newsletters/
```

이 요청들은 API key 없이 호출되어 있을 경우 API key 노출로 판단된다.

---

### 크롤러 가능성 판단

크롤러로 분류된 요청은 아래 경로를 포함한다.

```text
/robots.txt
/sitemap.xml
```

크롤러 탐색으로 분류된 경로들은 크롤러 탐색으로 보았지만, 전체 위협으로 판단하지는 않았다.

---

### 스캔 또는 공격 탐색 의심 요청 판단

스캔 탐색으로 분류된 요청은 대부분 공격 목록에서 제외된 경로들을 통해 이루어진 것으로 보인다.

크롤러 탐색으로 분류된 경로들은 크롤러 탐색으로 분류되었지만, 전체 위협으로 판단하지 않았다.

---

### 실제 침해 성공 가능성

침해 성공 근거를 찾지 못했으므로, 실제 침해 성공은 없는 것으로 분석했다.

---

### Ghost 내부 작업 판단

모든 정상 요청 경로들은 Ghost 내부 작업으로 분류되었다.

---

### SLOW_GET_HELPER 성능 경고 판단

`SLOW_GET_HELPER` 성능 경고는 `{{#get}} helper`가 204ms, 206ms를 넘겨 발생한 것으로 보인다.

따라서 해당 항목은 보안 위협보다는 성능 경고로 분류했다.

---

### Content API key 판단

Content API key를 노출하는 요청은 발견되지 않았다.

---

### 즉시 차단 필요 여부

모든 요청 경로들이 Ghost 내부 작업으로 분류되었고, 위협으로 판단하지 않았다.

따라서 즉시 차단할 필요는 없다.

---

### 차단 후보 경로 또는 룰

차단 후보 경로는 없다.

---

### 추가 확인 필요 로그

더 자세한 로그 분석과 경로 확인이 필요하다.

---

### 최종 결론

Ghost 웹 로그 중 일부 요청 경로가 공격 목록에서 명시되지 않은 경로로 분류되어 있었다.

실제 침해 성공 근거는 없었으며, 대부분의 요청은 크롤러 탐색으로 분류되었다.

따라서 즉시 차단 요청은 없으며, 추가 로그 확인이 필요하다.

/members/api/member/ 를 공격으로 분류
robots.txt 를 주요 위협으로 분류
Content API key를 관리자 API key처럼 판단

따라서 개선 방향은 아래와 같습니다.

룰 기반 전처리
→ 의심 경로 / 크롤러 / 정상 Ghost API / 성능 경고 추출
→ LLM은 해석과 보고서 작성만 담당

9. 현재까지의 최종 결론

성공한 것

• BIOS 패치 성공
• 패치 메뉴 표시 성공
• Fedora Server 43 설치 성공
• amdgpu 인식 성공
• Mesa RADV Vulkan 인식 성공
• TTM / swap 방향 설정
• llama.cpp Vulkan 빌드 성공
• Qwen2.5 3B Q4 모델 다운로드 성공
• llama.cpp 모델 실행 성공
• 로그 분석 테스트 성공

제외 또는 보류한 것

• ACPI Fix 적용: 미진행
• CPU governor 설정: ACPI Fix 미적용 상태에서 cpufreq 인터페이스가 노출되지 않아 제외
• GPU governor 설정: 이번 글에서는 미진행
• 40-CU unlock: 아직 미진행
• 쿨링 시스템 정비: 별도 작업 필요
• 전처리 및 로그 자동 수집: 아직 미구현
• 자동 차단: 오탐 가능성 때문에 보류
• LLM 단독 보안 판정: 오탐 존재로 보류

현재 실사용 가능 범위

• 로컬 LLM 실행: 가능
• 로그 요약 / 보조 분석: 가능
• 룰 기반 전처리 + LLM 보고서: 가능

정리하면, BC-250을 Fedora Server 43 + Mesa RADV + llama.cpp Vulkan 기반 로그 분석 노드로 구성하는 1차 세팅은 성공했습니다.