GPU-unlock: FP/BF16 instruction issue rate on Nvidia 3000's cards
GPU-unlock: 엔비디아 RTX 3000 카드의 FP/BF16 명령 발행률 잠금 해제
Linux 커널 모듈로 RTX 3000 일부 카드의 FP/BF16 FMA 명령 발행률 제한을 우회합니다. 보고된 카드에서는 BF16 GEMM 성능이 25~80% 높아졌지만, 전력 한도와 작업 특성에 따라 차이가 크며 메모리 대역폭이 병목인 작업은 개선 폭이 작습니다.
- 주제
에디터 노트
성능 향상은 명령 발행률을 두 배로 만든다는 설명만으로 예측하기 어렵습니다. 저장소의 카드별 BF16 GEMM 수치는 25~80%지만 작업마다 측정 조건이 다르고, 프로젝트도 전력 한도가 낮을수록 이득이 줄 수 있다고 밝힙니다. 메모리 대역폭에 묶인 decode와 INT8은 거의 달라지지 않는다는 조건까지 포함하면, 수치는 특정 연산의 잠재 성능이지 모든 AI 작업의 속도 향상이 아닙니다. 댓글에서는 450W 전력 한도를 높여야 큰 이득을 본다는 경험과 기본 전력 한도에서도 향상을 얻었다는 경험이 맞섭니다. 작성자는 전력 한도와 작업별 여유에 따라 결과가 달라진다고 설명하므로, 이 반응은 모순이라기보다 카드 냉각과 작업 조건의 차이를 보여줍니다. 펌웨어 취약점을 이용한다는 점과 initramfs 단계에서 실행한다는 구조는 성능 수치와 별도로 살펴야 할 기술적 조건입니다. 직접 확인된 적용 범위는 보고된 카드에 한정되며 GA103 사례는 아직 없습니다.
AI 요약
NVIDIA가 GeForce RTX 3000 일부 제품에서 제한한 FP/BF16 FMA 명령 발행률을 Linux 커널 모듈로 해제하는 프로젝트입니다. 드라이버를 패치하지 않고 GPU의 드라이버가 카드를 초기화하기 전에 동작하며, 보고된 카드에서 BF16 GEMM은 25~80% 빨라졌습니다. 다만 전력 한도와 작업 특성에 따라 성능 차이가 큽니다.
작동 방식
모듈은 CMP unlocker의 V67/PLM 기법과 UEFI 방식의 드라이버 로딩 전 실행 시점을 결합합니다. GPU의 속도 선택 레지스터에 SS0 0x88888888과 4비트 SS1 0x8을 기록하고 FLR(Function Level Reset)을 수행한 뒤 NVIDIA 드라이버가 카드를 초기화하게 합니다. SS0 설정은 BF16 전체 발행률을 선택하고 SS1은 IMLA4 설정에 쓰입니다. 패치한 NVIDIA 드라이버가 아니라 부팅 과정에서 먼저 실행하는 커널 모듈이므로 NVIDIA 드라이버가 갱신돼도 매번 드라이버를 다시 패치할 필요가 없습니다.
프로젝트 설명에 따르면 GA102, GA103, GA104, GA106 카드에서 FP/BF16 FMA를 FP32로 누산하는 명령의 발행 속도를 두 배로 높입니다. 문서에 제시된 입력별 수치는 FP16 87.46에서 118.39 TFLOPS, BF16 87.50에서 157.41 TFLOPS, TF32 42.58에서 82.61 TFLOPS입니다. 카드를 사용한 사람들의 자체 벤치마크를 모은 값이라 서로 직접 비교할 수 없습니다.
지원 카드와 성능 조건
RTX 3090 Ti에서는 BF16 GEMM이 68~80%, RTX 3090에서는 25~67%, RTX 3080 10GB에서는 70~73%, RTX 3070에서는 73~81%, RTX 3060 12GB에서는 약 80% 향상됐다는 보고가 있습니다. RTX 3080 Ti 20GB OEM 모델은 잠금 해제 절차가 끝나도 BF16 속도가 절반에 머문 사례가 있습니다. RTX 3070 Ti는 이 모듈로 시험한 보고가 없고, Windows UEFI 포트에서는 같은 잠금 해제가 작동했다는 보고만 있습니다. GA103은 아직 성공 보고가 없습니다. 가장 낮은 25% 수치는 전력 한도를 225W로 제한한 카드에서 나왔습니다.
행렬 연산 비중이 큰 LLM prefill은 보고된 사례에서 14~36% 빨라졌고, diffusion과 FlashAttention도 이득을 볼 수 있습니다. 반면 메모리 대역폭에 좌우되는 LLM decode와 INT8 작업은 대체로 변화가 없습니다. 출력값을 비교한 보고에서는 잠금 해제 전후 결과가 비트 단위로 같았습니다. 보고에는 최대 네 장을 장착한 시스템, 화면 출력에 쓰는 카드, vfio-pci로 가상 머신에 전달한 카드도 포함됩니다.
설치와 부팅 설정
저장소를 내려받아 make install을 실행한 뒤 커널 명령행에 gpu_unlock.targets=all을 추가합니다. 배포판에 따라 GRUB 설정을 고치거나 grubby를 실행하고, systemd-boot에서는 부팅 항목의 options 행을 수정합니다. UKI에서는 /etc/kernel/cmdline을 고친 뒤 부팅 이미지를 다시 생성합니다. 설치 과정은 배포판을 감지해 Arch, Debian/Ubuntu 또는 Fedora/RHEL 계열 패키지를 선택하며, 명시적으로 make install-arch, make install-deb, make install-rpm을 지정할 수도 있습니다.
패키지는 모듈과 펌웨어를 initramfs에 넣어 NVIDIA 드라이버보다 먼저 실행합니다. mkinitcpio에서는 설정에 따라 nvidia보다 앞서 모듈을 삽입하고, initramfs-tools와 dracut도 지원합니다. 매 빌드에서 고정된 NVIDIA/CachyOS 입력을 HTTPS로 내려받고 SHA-256을 확인합니다. 생성한 펌웨어는 빌드 디렉터리와 바이너리 패키지에만 둡니다. 소스 배포물과 Debian 소스 패키지, .nosrc.rpm에는 NVIDIA 아카이브나 생성 펌웨어가 들어가지 않습니다.
대상 지정과 동작 제약
gpu_unlock.targets=all은 미초기화 상태인 지원 카드 모두를 대상으로 합니다. 특정 카드를 지정하려면 lspci -D 형식의 PCI 주소를 쉼표로 나열합니다. 이미 다른 드라이버에 연결됐거나 전원이 꺼진 카드는 건너뜁니다. 잠금 해제는 카드별로 병렬 실행해 전체 작업에 약 1초가 걸립니다. 화면 출력 카드도 지원하지만 재설정 시점부터 nvidia-drm이 화면을 다시 맡을 때까지 화면이 꺼집니다. 부팅 뒤 모듈을 수동으로 불러도 이미 NVIDIA 드라이버가 연결한 카드는 바뀌지 않습니다.
RAM suspend 뒤 카드 전원이 끊기면 속도 선택 설정이 초기화되므로 모듈이 재개 과정에서 다시 잠금을 풉니다. 이 과정은 약 1초를 더하고 현재 드라이버의 기본 suspend notifier 순서를 전제로 합니다. 재개 시 이미 NVIDIA가 카드를 다시 초기화했거나 다른 드라이버가 연결했다면 건너뜁니다. hibernation은 지원 범위에 없습니다. 펌웨어가 멈추지 않는 카드에서는 모듈이 로그를 남기고 펌웨어가 쓸 수 있는 DMA 버퍼를 다음 전원 차단까지 유지합니다. 문제를 다시 시도하기 전에 전원을 꺼야 합니다.
Hacker News 반응
- @Tiberium — 직접 시험했고 결과는 진짜입니다. 펌웨어 취약점을 이용한다는 점에서 조금 위험하긴 하지만 놀랍습니다.
- @jacquesm — 다른 비슷한 모드와 잘 어울리지 않습니다. 이 프로젝트와 달리 드라이버 버전을 고정해야 합니다.
- @jacquesm — 실제로 작동하지만 몇 가지 조건이 있습니다. 카드를 더 뜨겁게 운용해야 할 수 있고, 일부 카드에서 큰 이득을 내려면 최대 전력을 450W까지 올려야 합니다. 기본 쿨러가 감당하도록 설계된 수준을 넘으니 냉각을 보강하는 편이 낫습니다. 먼저 로드되는 이 모드는 기존 P2P 모드와 함께 쓸 수 있습니다.
- @Tiberium — 전력 한도를 바꾸지 않아도 제 GPU에서는 그대로 작동했습니다. 전력 사용이 최대치에 머무는 시간이 늘 수는 있어도 한도 안에 있습니다.
- @Zagitta — 이 모드는 NVIDIA가 전문용·데이터센터용 카드에만 전체 속도로 열어 둔 특정 명령의 발행률을 절반으로 낮추는 두 비트를 바꿉니다. 계산량이 늘면 전력을 더 쓰지만 전력 한도에 닿으면 클록이 낮아져 소비 전력을 맞춥니다. 실제 상승 폭은 작업에 남은 전력 여유에 따라 달라집니다. 수랭식 RTX 3090 두 장에서 한 달간 문제없이 사용했습니다.
- @Scene_Cast2 — 흥미롭지만 적용되는 작업이 제한적입니다. 학습도 메모리 대역폭에 막히는 경우가 많습니다. 전력 소비가 어떻게 달라지는지도 궁금합니다.
- @Zagitta — 추론의 prefill에도 유용합니다. vLLM에서는 커널과 prefill 크기에 따라 최대 30% 향상을 봤습니다.
- @superkuh — 제목이 틀렸습니다. FP16 연산이 아니라 절반으로 제한된 FP32 발행률을 푸는 것입니다. 지난주 찾아본 범위에서는 RTX 3090/3090 Ti 외의 RTX 3000 카드에 적용했다는 보고도 보지 못했습니다.
- @Tiberium — 저장소에는 다른 RTX 3000 카드의 보고도 있습니다. RTX 3080 Ti, 3070 Ti, 3070, 3060 사례가 있습니다.
- @Zagitta — FP/BF16 FMA를 FP32로 누산하는 명령입니다. 대부분의 RTX 3000 카드가 같은 GA102 부트로더를 사용해 작동합니다. VBIOS 배치가 특이한 카드에는 문제가 있다는 보고가 있어 수정하려고 합니다.
- @blagui — 실제 이득은 광고보다 작습니다. 200W 전력 한도에서 TFLOPS 시험은 25% 향상이었지만, prefill 위주인 사용 사례에서 decode를 덜 하는 효과까지 고려하면 실제 향상은 7~8%였습니다. RTX 3090 네 장으로 Qwen 27B Int4와 vLLM 최대 배치를 사용한 시험입니다.
- @chromaton — RTX 3060으로 nanochat 학습이 약 6% 빨라졌습니다. 저장소는 Linux 커널 6.x 기준이라 5.15에서 코드와 시작 스크립트를 수정해야 했습니다. 현재 170W에서 전력 한도에 걸리며 카드를 손상시키거나 과열할 생각은 없습니다.
- @londons_explore — 다음 버전에서는 이런 설정을 막도록 서명된 펌웨어를 넣을 것 같습니다.
- @Zagitta — 펌웨어는 이미 암호화돼 있지만 공개 테스트 키로 복호화되는 NVIDIA의 암호화된 디버그 이미지가 있었습니다. 디버그 펌웨어가 제품 펌웨어와 충분히 비슷해 취약점을 만들 수 있었습니다. DMA 버퍼 오버플로로 스택을 덮어 ROP를 실행하며, 서명되지 않은 코드를 직접 실행하는 방식은 아닙니다.
- @RachelF — 다중 카드 소비자용 GPU에서 카드 간 속도를 약 20% 높이는 관련 라이브러리도 있습니다. 하드웨어는 지원하지만 NVIDIA가 저가형 카드로 판단하면 드라이버에서 막습니다.
원문: GitHub / 번역·요약: Trawling