검색
← 모듈 로드맵

GPU Unlock 호환성 보고서: RTX 3090 Ubuntu 24.04

발행 출처 GitHub · github.com

사례전문가

나중에 보기좋아요
공유 · 인쇄
후기댓글

RTX 3090 Ubuntu 24.04 gpu-unlock 호환성 보고서

호환성 보고서: 기본 상태의 EVGA RTX 3090 (GA102, 10de:2204) — 콜드/웜 재부팅 모두 자동으로 다시 잠금 해제되며, per-MHz FP16/BF16 비율 ×1.9

하드웨어: LGA1700 데스크톱 보드(i5-13600KF, iGPU 없음), EVGA GeForce RTX 3090 24 GB(GA102-300-A1, PCI 10de:2204, subsystem 3842:3982, 기본 VBIOS 94.02.42.C0.05, 메모리 개조되지 않은 카드) 0000:01:00.0에 장착, 헤드리스(이 카드는 유일한 부팅 디스플레이 장치이기도 함). Ubuntu 24.04(kernel 7.0.0-38-generic, HWE), UEFI, Secure Boot 꺼짐. NVIDIA driver 610.57.04(nvidia-driver-610-open, 배포판 커널 debs, GSP firmware 켜짐), 전혀 수정하지 않음. 전력 제한은 350 W로 설정됨(기본값은 420 W). 이 시스템에는 suspend/hibernate 없음.

gpu-unlock: main HEAD 4189b17(c274e74로의 revert), 동일 호스트에서 make deb로 로컬 패키징. 빌드 관련 참고 두 가지: dpkg-checkbuilddeps가 debhelper/devscripts 외에 dh-sequence-dkms를 올바르게 요구함(그래서 make deb 전에 apt-get install dh-sequence-dkms를 해야 했음); 그리고 Ubuntu 24.04의 cloud 계열 설치에는 lsinitrd가 없음(initramfs-tools-bin 부재) — 대신 unmkinitramfs로 재생성된 initrd 안의 모듈+펌웨어 존재를 확인함. 이 머신의 기본 initramfs에는 nvidia.ko가 들어 있지 않으므로(nvidia는 나중에 udev를 통해 rootfs에서 로드됨), #11의 순서 함정은 여기에는 적용되지 않음.

kernel cmdline: gpu_unlock.targets=0000:01:00.0.

부팅 증거 — 콜드 부팅(완전 전원 차단 후 재인가, 카드 idle, FWSEC 체인이 깨끗하게 파싱됨):

코드
pci 0000:01:00.0: entry: plm=0xffffff8f ss0=0x13444106 ss1=0x7 wpr2_hi=0x0
pci 0000:01:00.0: selector write: SS0=0x88888888
pci 0000:01:00.0: selector write: SS1=0x8
pci 0000:01:00.0: post-FLR GFW result: error=0 pci=0x220410de plm=0x8b8f boot=0x3ff cpuctl=0x10 budget_us=2050000
pci 0000:01:00.0: post-FLR SEC2 reset released, GSP halted, BME=0 pending=0 WPR2=1ffffe00:00000000 SS0=88888888 SS1=00000008
pci 0000:01:00.0: gpu_unlock: unlocked

웜 재부팅 증거 — 이 보드에서 systemctl reboot를 하면 카드가 충분히 리셋되어 전체 시퀀스가 다시 실행되며, entry 시 selector가 0으로 읽힘(#1의 MSI AM4 발견과 일치, 즉 웜 재잠금 해제가 보드 의존적이며 보편적이지 않음이 확인됨):

코드
(entry, warm boot)  pci 0000:01:00.0: entry: plm=0xffffff8f ss0=0x0 ss1=0x0 wpr2_hi=0x0
pci 0000:01:00.0: gpu_unlock: unlocked

nvidia 610.57.04는 두 번의 부팅 후 모두 정상적으로 바인딩됨; 설치 이후 0개의 Xid / NVRM 오류 줄; 생산 환경 LLM 서빙 부하는 지금까지 단 한 번의 hang이나 재시작 없이 계속 실행 중임.

GEMM(torch 2.14.1+cu13의 cuBLAS 사용, 8192³ dense, fp16/bf16는 FP32 accumulation, int8는 int32 accumulate _int_mm, 15회 반복 × 3라운드의 중앙값, 두 실행 모두 GPU에서 동일한 LLM 서버가 상주한 상태, GPU는 350 W 상한):

입력 | 잠금 상태 | 잠금 해제 상태 | 절대 비율 | TFLOPS/MHz 비율 -- | -- | -- | -- | -- FP16 | 70.8 @1680 MHz | 111.3 @1380 MHz | x1.57 | 0.042 -> 0.081 (x1.94) BF16 | 72.0 @1710 MHz | 114.8 @1425 MHz | x1.60 | 0.042 -> 0.081 (x1.92) INT8 | 235.9 TOPS | 240.2 TOPS | x1.02 (대조군) | —

per-MHz 비율은 커뮤니티의 잠금 해제 후 약 0.083 수치(#1)와 정확히 일치함. 절대 비율이 2배 미만인 이유는 GEMM 동안 카드가 350 W 전력 제한에 걸려 있기 때문임(잠금 해제 후 SM clock이 ~1680 -> 1380 MHz로 떨어짐, 전력은 같고 사이클당 처리량이 더 많아짐); A/B 비교를 위해 의도적으로 제한을 올리지 않았고 -pl 420은 테스트하지 않음. INT8은 예상대로 변함이 없으며, 이는 좋은 대조군임.

실제 워크로드(GGUF 양자화 MoE LLM 서버, IQ3_S, 24/7 서빙)에 대한 하위 효과: 16K 토큰 prefill 처리량 +14.4%(2759 -> 3156 tok/s, TTFT 5.85 -> 5.12 s), decode는 변함 없음(대역폭 병목), 그리고 매우 긴 프롬프트(~32K)도 변함 없음 — 그 경우 RAM에서 expert streaming이 지배적임. 두 실행 간 출력은 비트 단위로 동일함.

명시적으로 주장하지 않는 항목: 장기 안정성(현재는 몇 시간 수준이지 몇 주는 아님), S3 suspend/resume 동작(여기서는 미사용), hibernation(설계상 미지원), multi-GPU, nvidia.ko가 initramfs에 있는 보드(이 구성 아님), 610-open 외의 다른 driver branch, 그리고 이 3090 이외의 어떤 GA102 SKU도 아님.

출처

  • 원문: https://github.com/Zagitta/gpu-unlock/issues/33 (2026-10-25 · github.com)

자료 변경 기록을 불러오는 중입니다.

다음 자료를 불러오는 중입니다.

후기

아직 후기가 없습니다

직접 적용한 결과와 주의할 점을 공유하는 공간입니다.

로그인하고 후기 쓰기

참고 자료 · 도구와 릴리스 노트

댓글