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 추론 후 대답안을 예시로 들겠습니다.

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

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

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

9. BC-250 40-CU Unlock 적용

9-1. 적용 전 환경 확인

40-CU 패치는 현재 부팅된 Fedora 커널과 정확히 일치하는 kernel-devel 환경에서 amdgpu 모듈을 다시 빌드하는 방식으로 진행했습니다.

현재 커널을 확인했습니다.

uname -r

확인된 커널은 아래와 같습니다.

7.0.12-101.fc43.x86_64

BC-250 장치를 확인했습니다.

lspci -nn | grep -iE 'BC-250|Cyan Skillfish|1002:13fe'

확인 결과:

AMD Cyan Skillfish [BC-250] [1002:13fe]

Secure Boot 상태도 확인했습니다.

mokutil --sb-state

확인 결과:

This system doesn't support Secure Boot

Secure Boot를 지원하지 않는 시스템으로 확인되어 별도의 커널 모듈 서명 작업은 진행하지 않았습니다.

9-2. 빌드 의존성 설치

40-CU 패치 스크립트 실행에 필요한 기본 패키지를 설치했습니다.

sudo dnf install -y \
  git \
  gcc \
  make \
  zstd \
  curl

처음에는 현재 커널용 kernel-devel을 저장소에서 직접 설치하려고 했습니다.

sudo dnf install -y kernel-devel-$(uname -r)

그러나 당시 활성화된 Fedora 저장소에서는 아래 버전이 검색되지 않았습니다.

kernel-devel-7.0.12-101.fc43.x86_64

커널 모듈은 실행 중인 커널과 kernel-devel 버전이 정확히 일치해야 하므로 다른 버전으로 대체하지 않고 동일 버전 RPM을 준비했습니다.

9-3. 현재 커널과 일치하는 kernel-devel 설치

사용한 RPM 파일은 아래와 같습니다.

kernel-devel-7.0.12-101.fc43.x86_64.rpm

동일 버전 RPM을 내려받은 뒤 설치했습니다.

cd ~/Downloads

sudo dnf install -y \
  ./kernel-devel-7.0.12-101.fc43.x86_64.rpm

설치 여부를 확인했습니다.

rpm -q kernel-devel-$(uname -r)

정상 확인 결과:

kernel-devel-7.0.12-101.fc43.x86_64

커널 모듈 빌드 경로도 확인했습니다.

ls -l /usr/lib/modules/$(uname -r)/build
readlink -f /usr/lib/modules/$(uname -r)/build
ls -ld /usr/src/kernels/$(uname -r)

최종적으로 아래 경로가 정상적으로 연결된 상태를 확인했습니다.

/usr/lib/modules/7.0.12-101.fc43.x86_64/build
/usr/src/kernels/7.0.12-101.fc43.x86_64

9-4. bc250-40cu-unlock 다운로드

40-CU 패치는 아래 GitHub 프로젝트를 사용했습니다.

cd ~

git clone https://github.com/duggasco/bc250-40cu-unlock.git

cd ~/bc250-40cu-unlock
chmod +x scripts/bc250-enable-40cu-fedora.sh

적용 전 상태를 확인했습니다.

sudo ./scripts/bc250-enable-40cu-fedora.sh status

적용 전에는 stock amdgpu 모듈과 24CU 상태로 확인되었습니다.

9-5. 패치된 amdgpu 모듈 빌드 및 설치

현재 실행 중인 Fedora 커널용 amdgpu 모듈을 패치하고 다시 빌드했습니다.

cd ~/bc250-40cu-unlock

sudo ./scripts/bc250-enable-40cu-fedora.sh build

스크립트가 수행한 작업은 아래와 같습니다.

• BC-250 PCI ID 13fe 확인
• 필수 빌드 도구와 kernel-devel 확인
• 현재 커널 버전의 AMDGPU 소스 준비
• gfx_v10_0.c에 40-CU 활성화 코드 삽입
• 현재 커널용 amdgpu.ko 빌드
• 기존 amdgpu 모듈 백업
• 패치 모듈 압축 및 설치
• depmod 실행

패치 모듈 설치 여부를 확인했습니다.

modinfo amdgpu | grep -i bc250
modinfo amdgpu | grep bc250_cc_write_mode

bc250_cc_write_mode 항목이 표시되면 디스크에 설치된 amdgpu 모듈은 패치된 상태입니다.

9-6. 40-CU 모드 활성화

패치 모듈 빌드가 끝난 뒤 40-CU 모드를 활성화했습니다.

cd ~/bc250-40cu-unlock

sudo ./scripts/bc250-enable-40cu-fedora.sh enable

이 명령으로 아래 설정 파일이 생성되었습니다.

/etc/modprobe.d/bc250-40cu.conf

파일 내용:

# BC-250 40 CU re-enablement
options amdgpu bc250_cc_write_mode=3

설정 파일을 확인했습니다.

cat /etc/modprobe.d/bc250-40cu.conf

enable 명령 실행 후 시스템은 자동으로 재부팅되었습니다.

9-7. 첫 재부팅 후 24CU로 남은 문제

첫 재부팅 후 상태를 확인했습니다.

cd ~/bc250-40cu-unlock

sudo ./scripts/bc250-enable-40cu-fedora.sh status

확인 결과:

amdgpu module: patched
write_mode: N/A
active CUs: 24
modprobe conf: /etc/modprobe.d/bc250-40cu.conf

디스크의 amdgpu 모듈은 패치되었고 modprobe 설정도 존재했지만, 부팅 과정에서 기존 initramfs 내부의 stock amdgpu 모듈이 먼저 로드된 상태였습니다.

따라서 initramfs를 다시 생성했습니다.

9-8. initramfs 백업 및 재생성

현재 커널 버전을 변수로 지정했습니다.

KVER="$(uname -r)"

기존 initramfs를 백업했습니다.

sudo cp -a \
  /boot/initramfs-${KVER}.img \
  /boot/initramfs-${KVER}.img.pre40cu

백업 파일을 확인했습니다.

ls -lh \
  /boot/initramfs-${KVER}.img \
  /boot/initramfs-${KVER}.img.pre40cu

패치된 amdgpu 모듈이 포함되도록 initramfs를 강제로 다시 생성했습니다.

sudo dracut --force \
  /boot/initramfs-${KVER}.img \
  ${KVER}

initramfs 내부의 amdgpu 모듈을 확인했습니다.

sudo lsinitrd /boot/initramfs-${KVER}.img \
  | grep -E 'amdgpu\.ko'

재부팅했습니다.

sudo reboot

9-9. 최종 40-CU 적용 확인

재부팅 후 상태를 다시 확인했습니다.

cd ~/bc250-40cu-unlock

sudo ./scripts/bc250-enable-40cu-fedora.sh status

최종 성공 결과:

amdgpu module: patched
write_mode: 3
active CUs: 40 (full die)
modprobe conf: /etc/modprobe.d/bc250-40cu.conf (40 CU enabled)

현재 로드된 모듈 파라미터를 직접 확인했습니다.

cat /sys/module/amdgpu/parameters/bc250_cc_write_mode

정상 출력:

3

커널 로그에서도 활성 CU 수를 확인했습니다.

sudo dmesg | grep active_cu_number

sudo journalctl -k -b 0 \
  | grep active_cu_number

정상 확인 결과:

active_cu_number 40

40-CU 패치 동작 로그도 확인했습니다.

sudo dmesg | grep bc250-40cu

RADV Vulkan 기준 CU 수를 확인했습니다.

RADV_DEBUG=info vulkaninfo --summary 2>&1 \
  | grep -iE 'num_cu|num_cu_per_sh'

정상 확인 결과:

num_cu = 40
num_cu_per_sh = 10

디스크의 커널 모듈만 패치된 것이 아니라 실제 부팅된 amdgpu 모듈과 RADV Vulkan 백엔드에서도 40CU가 활성화된 것을 확인했습니다.

9-10. 연산 및 추론 확인

40-CU 활성화 후 Vulkan compute 검증 결과는 아래와 같습니다.

total_checked=100663296
errors=0
int_errors=0
fp_errors=0

llama.cpp Vulkan 백엔드에서도 BC-250가 정상 인식되었습니다.

ggml_vulkan: AMD BC-250 (RADV GFX1013)
backend: Vulkan
ngl: 999

Qwen2.5 3B Q4_K_M 기준 llama-bench 결과는 아래와 같습니다.

pp512: 875.72 ± 1.26 token/s
tg128: 123.75 ± 0.05 token/s

현재 사용 중인 케이스는 별도 제작한 케이스와
NOCTUA NF-A6x25 PWM 팬 두개를 사용 중입니다.

케이스가 완성되고 나면, DIY 탭에 글을 추가하도록 하겠습니다.

BC-250 케이스 제작

방열판 개조 없이 BC-250 온도 잡기

Sonny_Blogsonny

40CU 기능과 Vulkan 추론은 정상 동작했지만
실 사용으로 사용하기엔 높은 온도가 확인되었습니다.

• idle 상태 : 약 65°C
• 지속 TG 부하: 5분만에 약 90°C까지 상승

현재 팬은 저소음 제품으로 최대 정압이 2.18 mmH₂O에 불과합니다.

BC-250의 히트싱크는 길이가 길고 공기가 통과해야 하는 저항도 있기 때문에,
팬에서 발생한 바람이 히트싱크 후단까지 충분히 도달하지 못하는 것으로 추정됩니다.

장시간 추론 운용을 위해서는 팬 또는 전체 냉각 구조 보강이 별도로 필요합니다.

10. 현재까지의 최종 결론

성공한 것

• BIOS 패치 성공
• 패치 메뉴 표시 성공
• Fedora Server 43 설치 성공
• amdgpu 인식 성공
• Mesa RADV Vulkan 인식 성공
• TTM / swap 방향 설정
• llama.cpp Vulkan 빌드 성공
• Qwen2.5 3B Q4 모델 다운로드 성공
• llama.cpp 모델 실행 성공
• 로그 분석 테스트 성공
• BC-250 40-CU unlock 커널 패치 성공
• 부팅된 amdgpu 모듈에서 write_mode=3 적용 성공
• 커널 및 RADV Vulkan에서 40CU 인식 성공
• Vulkan compute 검증 100,663,296회 오류 0 확인

제외 또는 보류한 것

• ACPI Fix 적용: 미진행
• CPU governor 설정: ACPI Fix 미적용 상태에서 cpufreq 인터페이스가 노출되지 않아 제외
• GPU governor 설정: 이번 글에서는 미진행
• 쿨링 시스템 정비: 40CU 지속 TG 부하에서 약 90°C까지 상승해 팬 교체 진행 예정
• 전처리 및 로그 자동 수집: 아직 미구현
• 자동 차단: 오탐 가능성 때문에 보류
• LLM 단독 보안 판정: 오탐 존재로 보류

현재 실사용 가능 범위

• 로컬 LLM 실행: 가능
• 40CU 1500MHz Vulkan 추론: 가능
• 로그 요약 / 보조 분석: 가능
• 룰 기반 전처리 + LLM 보고서: 가능
• 장시간 연속 추론: 냉각 보강 후 권장

정리하면, BC-250을 Fedora Server 43 + Mesa RADV + llama.cpp Vulkan 기반 로그 분석 노드로 구성했고 Fedora 커널용 amdgpu 40-CU 패치까지 적용하는 데 성공했습니다.

현재 기능과 연산 검증은 정상이며, 남은 핵심 과제는 장시간 추론 부하를 위한 냉각 보강입니다.