hello

ASUS TRX50 Sage + RTX 5090 + RTX 4090/3090 다중 GPU 구성기 (Ubuntu 22.04, NVIDIA Open Kernel Module 이슈 해결)

Share

들어가며

최근 블랙웰 아키텍처 기반 RTX 5090을 메인으로, 기존 RTX 4090RTX 3090 2장을 함께 사용해야 하는 작업 환경을 구성하게 되었습니다.
메인보드는 ASUS Pro WS TRX50-SAGE WIFI, CPU는 Threadripper PRO 7960X(48 PCIe lanes).
계획은 다음과 같았습니다.

  • 1번 슬롯: RTX 5090
  • 2번 슬롯: RTX 4090
  • 4·5번 슬롯: RTX 3090 × 2

하지만 처음부터 5090이 전혀 인식되지 않는 문제가 발생했습니다.


문제 증상

  1. BIOS에서 4장의 GPU가 모두 보였으나,
    Ubuntu 22.04 부팅 후 nvidia-smi에 5090만 나타나지 않음.
  2. lspci에서는 정상적으로 5090(PCI ID: 10de:2b85) 확인 가능.
  3. 드라이버를 최신(580.65.06) 프로프라이어터리로 설치해도 마찬가지.

dmesg에 다음과 같은 에러 반복:

NVRM: The NVIDIA GPU 0000:41:00.0 (PCI ID: 10de:2b85)
NVRM: installed in this system requires use of the NVIDIA open kernel modules.

원인 분석

  • RTX 5090은 최신 세대 블랙웰 GPU로, NVIDIA Open Kernel Module(OKM) 전용 지원이 필수입니다.
  • 기존 방식(폐쇄형 커널 모듈)은 probe 단계에서 실패하여 장치를 초기화하지 못합니다.
  • Ubuntu 22.04의 기본 PPA에는 nvidia-driver-560-open까지만 제공 → 5090 미지원.

시도한 해결책

  1. BIOS 설정 점검
    • CSM Disabled
    • Secure Boot Disabled
    • Above 4G Decoding / Resizable BAR 옵션은 BIOS에 없음
    • PCIe 슬롯별 Lane 배분 및 전원(PCIE 6P, 8P) 연결 확인
  2. 커널 파라미터 추가
    • pci=realloc 부팅 옵션 적용 → PCIe MMIO 공간 재할당
  3. PPA 560-open 설치
    • 설치 및 재부팅 후에도 probe of 0000:41:00.0 failed with error -1

결국 5090 지원이 포함된 580대 Open Kernel Module 설치가 필요하다는 결론.


최종 해결 절차

아래는 NVIDIA 공식 runfile로 580 Open Kernel Module을 설치한 과정입니다.

재부팅 후 확인

cat /proc/driver/nvidia/version   # Open Kernel Module 문구 확인
nvidia-smi                        # 4 GPU 모두 인식

NVIDIA 580.x runfile 설치

chmod +x NVIDIA-Linux-x86_64-580.65.06.run
sudo ./NVIDIA-Linux-x86_64-580.65.06.run --dkms --kernel-module-type=open

텍스트 모드 전환

sudo systemctl isolate multi-user.target
sudo systemctl stop gdm   # (사용중인 디스플레이 매니저에 맞게 변경)

Nouveau 드라이버 비활성

printf "blacklist nouveau\noptions nouveau modeset=0\n" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u

커널 최신화 및 빌드 환경 준비

sudo apt install -y linux-generic-hwe-22.04
sudo apt install -y build-essential dkms linux-headers-$(uname -r)

기존 드라이버 완전 제거

sudo apt purge 'nvidia*' 'libnvidia*' 'cuda*'
sudo apt autoremove --purge -y

결과

  • nvidia-smi에서 5090 + 4090 + 3090 × 2 정상 인식.
  • CUDA 연산 및 메모리 접근 모두 정상 동작.
  • dmesg에서 더 이상 requires use of the NVIDIA open kernel modules 에러 없음.

배운 점

  • 최신 세대 GPU는 드라이버 버전뿐 아니라 커널 모듈 타입이 필수 요건이 될 수 있다.
  • Ubuntu LTS PPA는 최신 GPU 지원이 늦어질 수 있으므로, NVIDIA 공식 runfile 설치가 오히려 빠른 경우가 많다.
  • 다중 GPU 환경에서는 BIOS의 PCIe Lane 구성, 전원 연결, MMIO 할당 여유 등을 항상 체크해야 한다.

이렇게 해서 최종 완성된 모습!

이제 vllm 서빙 시 tensor-parallel-size를 짝수로 할 수 있어 4를 도전해볼 수 있게 되었습니다!

Read more

AI가 짜준 코드가 배포 속도를 높였다면, 이제는 '신뢰성 가드레일'을 세울 때입니다

최근 많은 팀이 AI 코딩 어시스턴트나 에이전트를 도입하면서 코드 생산 속도가 비약적으로 상승했습니다. 하지만 속도가 빨라졌다는 것은 그만큼 잠재적인 결함이 프로덕션 환경으로 유입되는 속도 또한 빨라졌음을 의미합니다. DevOps.com의 이번 글은 AI가 생성한 코드의 특성과 그로 인해 발생하는 새로운 유형의 리스크, 그리고 이를 제어하기 위한 '신뢰성 가드레일(Reliability Guardrails)

By JHL

LLM 시대, 프롬프트 엔지니어링보다 '도메인 전문성'이 더 강력한 무기인 이유

최근 AI 도구들이 비약적으로 발전하면서 '프롬프트 엔지니어링'이라는 기술적 기법에 많은 관심이 쏠렸습니다. 하지만 실제 현업에서 LLM을 극한으로 활용해 고도의 결과물을 만들어내는 사람들의 공통점은 정교한 프롬프트 템플릿을 쓰는 능력이 아니라, 해당 분야에 대한 깊은 '도메인 전문성'을 갖추고 있다는 점입니다. 많은 이들이 LLM이 지식의 격차를 줄여준다고

By JHL

AI 코딩 에이전트 도입 시 고려해야 할 보안 제어 프레임워크: 속도와 안전의 균형 잡기

최근 Claude Code나 Kiro와 같은 AI 코딩 에이전트들이 단순한 코드 완성을 넘어, 자연어 프롬프트 하나로 수십 개의 PR을 생성하고 인프라를 수정하는 수준까지 발전했습니다. 하지만 이러한 생산성 향상은 '기계적 속도'라는 트레이드오프를 동반합니다. AI 에이전트는 조직의 보안 리스크나 컴플라이언스를 이해하지 못한 채 오직 '작업 완료'에만 최적화되어

By JHL

AI 벤치마크의 '포화 상태'와 평가 지표의 유효기간: 우리는 무엇을 믿어야 하는가

최근 LLM의 성능이 비약적으로 상승하면서, 역설적으로 우리가 모델의 성능을 측정하는 '자' 자체가 무용지물이 되는 현상이 가속화되고 있습니다. arXiv에 게재된 "When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation" 연구는 우리가 흔히 신뢰하는 벤치마크 점수가 왜 더 이상 모델 간의 변별력을 제공하지 못하는지, 그리고 이른바 '

By JHL