RTX 20 / 30 / 40 텐서 코어 언락을 위한 크로스 플랫폼 GUI 및 자동화된 UEFI/DKMS 빌더 제작 후 RTX 4070 Ti

지난 며칠 동안 저는 Windows 11 환경의 Palit RTX 4070 Ti (10de:2782, 12 GB, 300W 전력 제한)에서 FMLA32 (FP16/BF16/TF32 -> FP32 누적) 언락을 테스트해 왔습니다. 이 언락 자체는 광고된 대로 작동하지만, 특정 하드웨어에 맞춰진 리포지토리를 찾기 어렵다면 설정 과정이 매우 불편했습니다. Linux 사용자는 Turing, Ampere, Ada용으로 별도의 리포지토리 사이를 이동해야 했습니다. Windows의 경우, 기존 UEFI 빌드는 대부분 단일 특정 보드의 프로필에 묶여 있었습니다. 이를 자신의 카드에서 실행하려면 PCI Device/Subsystem ID, VRAM 오프셋, 그리고 Windows EFI 부트 파티션 GUID를 수동으로 가져와 local_profile.h 파일을 직접 수정하고 BOOTX64.EFI를 컴파일해야 했습니다.

이 과정을 제가 사용하는 GPU에 맞게 조정하던 중, 기존 작업을 개선하고 모든 것을 단일 도구로 통합하여 프로세스를 단순화할 아이디어가 떠올랐습니다. 그 결과는 Windows 10/11 및 Linux에서 RTX 40 (Ada), RTX 30 (Ampere), RTX 20 (Turing) 시리즈 카드를 모두 지원하는 통일된 크로스 플랫폼 패키지입니다: https://github.com/MindAllik/GPU-Tensor-Unlock-Universal

이 프로젝트는 근간이 되는 연구, 페이로드(payloads), 그리고 로더 코드의 저자들에게 공로를 돌립니다: TOTORONG/AD103_win_unlocker, Zagitta/gpu-unlock, elias-gaeros/gpu-unlock, JustAResearcher/gpu-unlock-ada, KohakuBlueleaf/KohakUnlock, impacifist/Windows-GPU-UNLOCK, Goldlionren/gpu-unlock-4080s, haohervchb/Turing-unlock, 그리고 물론 Jon Pry.

Windows 환경(Windows_Launch_UI.bat)에서 core_detector.py 스크립트는 NVML, CUDA Driver API (sm_89 / sm_86 / sm_75), 및 pci.sys를 교차 조회하여 PCI Device ID, Subsystem ID, 버스 번호, VRAM 크기, 그리고 부트 드라이브의 EFI 파티션 GUID를 자동으로 감지합니다. 이 스크립트는 PCI ID -> Silicon Die -> PMC_BOOT_0 매핑을 확인하여 프로필이 정확한지 검사하고, 임시 폴더에 헤더를 생성하며, FAT32 USB 드라이브에 BOOTX64.EFI를 컴파일합니다 (부팅 시 U를 누르면 30초 카운트다운 타이머가 작동함).

검은 화면 정지(black-screen hangs) 현상을 방지하기 위해 2단계 사전 점검(PromCheck)이 추가되었습니다. 더 이상 단일 하드코딩된 ROM 해시 값에 의존하거나 디스플레이를 무작정 분리하는 대신, 로더는 먼저 카드에 있는 VBIOS (BAR0 + 0x300000)를 읽고, BIT 테이블, Falcon descriptor (Ada/Ampere의 경우 V3 RSA-3K, Turing의 경우 V2 AES-128), 그리고 DMAP 구조를 검증한 다음, DisconnectController를 호출하기 전에 RAM에서 건식 실행(dry-run) FRTS 패치를 수행합니다. 만약 벤더의 VBIOS 레이아웃이 비표준인 경우, 안전하게 작업을 중단하고 정상적으로 Windows로 부팅됩니다. Linux 환경에서는 (Linux_Launch_UI.sh 또는 CLI make install을 통해) gpu_unlock.ko DKMS 모듈을 설치하고 mkinitcpio, dracut, 또는 initramfs-tools를 위한 초기 RAM 파일 시스템(initramfs)을 재구축합니다. 실험적인 Ada 및 Turing 카드의 경우, targets=all 대신 명시적인 단일 카드 PCI BDF (0000:xx:00.0)가 필요하여 다중 GPU 빌드가 인접한 카드를 건드리지 않도록 합니다. 또한 CUDA 컨텍스트를 생성하지 않고도 ioctl 0x20801230을 통해 /dev/nvidiactl에서 fmla32 = 0 (full) 상태를 직접 확인하는 tools/read_sm_rates.py가 포함되어 있습니다. 콘솔에는 7개 커널 PTX JIT(Just-In-Time) 벤치마크도 내장되었습니다 (tensor_benchmark.py: FP16 -> FP16, FP16 -> FP32, BF16 -> FP32, TF32 -> FP32, FP8 E4M3 -> FP32, INT8 -> INT32, 및 Scalar FP32). KohakuBlueleaf가 이전에 언급했듯이, 표준 mmapeak은 컴파일 타임 제로(compile-time zeros)로 채워진 행렬 조각을 사용하여 ptxas가 루프 내부의 계산을 최적화할 수 있게 했습니다. 이 벤치마크는 런타임에 무작위 비제로 데이터를 생성하고, 루프 반복 서명 (iter ^ 0x67b05a5a)과 유한 IEEE-754 누산기 값(accumulator values)을 모두 검증합니다 (또한 NVML을 통해 전력 제한(Power Limit)을 VBIOS 최대값으로 올릴 수 있는 버튼이 인터페이스에 추가되었습니다). 제 테스트 벤치(Palit RTX 4070 Ti 10de:2782, Windows 11 UEFI, 300W 제한)에서 언스로틀링된 FP16 -> FP16 속도 (FMLA16 control kernel)는 172.8 TF/s입니다. 스톡 상태에서는 FP16 -> FP32가 약 86.4 TF/s였으나, UEFI 잠금 해제 후에는 FP16 -> FP32(172.8 TF/s)와 BF16 -> FP32(172.7 TF/s) 모두 최대치인 2.00배 속도에 도달했습니다.

비교용: GPU PCI ID / Die FP16->FP16 (제어) FP16->FP32 기본(Stock) FP16->FP32 언락 BF16->FP32 언락 출처 RTX 4070 Ti 10de:2782 (AD104) 172.8 TF/s 86.4 TF/s 172.8 TF/s (2.00x) 172.7 TF/s (2.00x) 제가 테스트함 (Win 11 UEFI, Palit 300W) RTX 4090 10de:2684 (AD102) ~331.6 TF/s 165.6 TF/s 331.6 TF/s (2.00x) 330.6 TF/s (2.00x) 상위 보고서 (elias-gaeros, Linux 450W) RTX 4070 Ti SUPER 10de:2705 (AD103) ~190.0 TF/s 95.0 TF/s 189.9 TF/s (2.00x) 189.7 TF/s (2.00x) 상위 보고서 (JustAResearcher, Linux 240W)

모든 작업은 OS 드라이버 로드 이전에 휘발성(volatile) MMIO 레지스터에서 발생하며, 전원 차단 후 리셋됩니다 (VBIOS 플래시 메모리는 전혀 건드리지 않으며, 스크립트는 공식 610.43.03 패키지에서 독점 NVIDIA 펌웨어 바이너리를 직접 다운로드하고 로컬에서 SHA-256을 검증합니다). 현재 RTX 4070 Ti (10de:2782), RTX 4090 (2684), RTX 4070 Ti SUPER (2705), RTX 3090 (2204), RTX 3080 (2206), 그리고 RTX 3060 12GB (2504)는 실제 하드웨어에서 검증되었습니다. 매트릭스에 남아 있는 데스크톱용 AD10x(40 시리즈), GA10x(30 시리즈), 및 TU10x(20 시리즈 / CMP) 프로파일은 현재 experimental_simulated 상태입니다 (GCC ASan/UBSan 하의 106 시나리오 시뮬레이터에서 검증됨). 만약 실험용 카드 중 하나를 Windows 또는 Linux에서 테스트하기로 결정한다면, 보고서가 성공했을 때나 사전 점검(pre-flight check) 단계에서 멈췄을 때 모두 중요하므로 GitHub Issues나 댓글에 EFI\UNLOCK\REPORT.TXT (또는 dmesg) 및 벤치마크 숫자를 공유해 주십시오. 별도로 언급하자면, 이것이 단일 스트림 토큰 생성(배치=1 디코드는 메모리 대역폭에 의해 제한됨)을 눈에 띄게 가속할 가능성은 낮으며, llama.cpp에서의 순수 정수 INT8/INT4 매트멀(matmuls)에도 영향을 미칠 가능성은 낮습니다.

실제로 도움이 되는 부분은 FP32 누적을 사용하는 연산 집약적인(compute-bound) FP16, BF16, 및 FP8 행렬 수학입니다. 예시로는 긴 프롬프트 읽기(vLLM의 prefill, ExLlamaV2, FlashAttention, 그리고 Marlin의 INT4 -> FP16 커널), BF16에서의 LoRA/QLoRA 미세 조정, 그리고 확산 모델(diffusion models) 등이 있습니다. P.S. 이 텍스트를 영어로 번역하고 더 보기 좋고 간결하게 만들기 위해 Gemini를 사용했습니다 :) 제출자: /u/MindAllik [링크] [댓글]