Nvidia RTX Spark 노트북, 암호화된 전원 펌웨어로 인해 Linux에서 GPU 성능 65% 저하

TL;DR

RTX Spark 노트북에서 Linux를 이중 부팅하면 작동하지만, AC 전원에서 GPU가 약 780MHz로 제한되어 추론 처리량이 약 14 tokens/s로 떨어집니다.
이 제한은 Windows 전용 펌웨어 구성 요소인 Nvidia Platform Controllers and Framework 때문이며, 암호화된 전원 테이블은 Windows 드라이버만 해독할 수 있습니다.
벤치마크에 따르면 Windows와 WSL은 120B 모델에서 약 65 tokens/s를 달성하는 반면, 네이티브 Linux는 약 14 tokens/s에 불과합니다.
메모리 할당도 또 다른 장애물입니다. 노트북은 GPU에 96GB의 통합 메모리를 예약하며, 이는 Windows에서만 조정할 수 있습니다.
현재로서는 WSL이 실용적인 해결책입니다. Windows 드라이버 스택에서 실행되므로 GPU 부스트를 완전히 유지할 수 있습니다.
영구적인 해결책은 Nvidia가 Linux 드라이버에 동일한 전원 관리 로직을 제공하는 것입니다.

Linux는 부팅되지만 GPU가 잠겨 있음

MSI Prestige N16 Flip AI Plus(RTX Spark 노트북)에 Linux를 설치하면 오픈 소스 Nvidia 커널 드라이버가 올바르게 로드되고, 수동 구성 후 오디오, 키보드, 터치패드가 작동하며 4K@120Hz 출력이 가능합니다. 그러나 노트북을 전원에 연결하면 GPU 클럭이 Windows에서 관찰되는 약 2.2GHz 대신 약 780MHz에서 멈춥니다. 이 클럭 저하는 120B 모델에서 약 65 tokens/s를 처리할 수 있는 칩을 약 14 tokens/s로 떨어뜨려 5배 느려집니다.

"Linux에서 전원을 연결하면 GPU 클럭 속도가 약 780MHz로 떨어지는데, Windows에서는 약 2.2GHz입니다. 펌웨어의 전원 테이블이 암호화되어 있고 Windows 드라이버만 해독할 수 있기 때문입니다." – MindStudio 블로그

이 저하는 열 제한 때문이 아닙니다. 온도는 40°C에서 47°C 사이를 유지합니다. 순전히 전원 관리 제한입니다.

숨겨진 Windows 전용 컨트롤러

Windows의 장치 관리자에는 Nvidia Platform Controllers and Framework라는 구성 요소가 표시됩니다. 이 펌웨어-드라이버 쌍은 노트북에서 CPU와 GPU 간의 공유 전원 예산을 관리합니다(전용 GPU 레일이 있는 데스크톱 DGX Spark와 달리). 컨트롤러는 펌웨어에서 암호화된 전원 테이블을 받으며, Windows 드라이버가 해독 키를 보유합니다.

Windows에서 이 컨트롤러를 비활성화하면 Linux에서의 저하가 재현됩니다. 토큰 처리량이 약 83 tokens/s에서 약 31 tokens/s로 떨어지고 GPU 클럭이 약 786MHz로 낮아집니다. 다시 활성화하면 즉시 전체 속도가 복원됩니다. Linux에는 이에 해당하는 구성 요소가 없으므로 GPU는 더 높은 전원 할당을 받지 못합니다.

"원인은 Windows 장치 관리자에 표시되는 Nvidia Platform Controllers and Framework라는 구성 요소로 추적됩니다. Windows에서 해당 컨트롤러를 비활성화하면 저하가 직접 재현되었습니다." – MindStudio 블로그

펌웨어가 암호화된 이유

Nvidia는 독점 전원 관리 알고리즘을 보호하기 위해 전원 테이블을 암호화합니다. Windows 드라이버에는 비밀 키가 포함되어 있지만 오픈 소스 Linux 드라이버에는 없습니다. 키를 추출하거나 드라이버를 패치하려는 시도는 커널 패닉을 일으키거나 일시적인 해결책에 그쳤으며, 적절한 수정은 Nvidia가 제공해야 함을 확인시켜 주었습니다.

벤치마크로 성능 격차 확인

환경	GPU 클럭(MHz)	Tokens/s (GPT-OSS-120B)
Windows(네이티브)	약 2,200	65.4
WSL 2(Windows의 Linux)	약 2,200	65.1
Nvidia DGX Spark(Linux)	약 2,200	61
RTX Spark의 네이티브 Linux	약 780	13.9

vLLM으로 8개의 동시 클라이언트를 실행한 두 번째 테스트에서는 WSL에서 127 tokens/s, 네이티브 Linux에서 39.5 tokens/s를 기록했습니다. 노트북을 분리하면 Linux 클럭이 약 1,800MHz로 상승하고 토큰 속도가 61-67 tokens/s로 올라가 Windows와 일치합니다. 플러그를 꽂은 Linux가 더 느린 이례적인 현상은 전원 컨트롤러의 동작에서 직접 비롯됩니다.

메모리 분할도 Linux의 또 다른 장애물

RTX Spark 노트북은 CPU와 GPU가 공유하는 최대 128GB의 통합 메모리를 제공합니다. 기본적으로 펌웨어는 GPU에 96GB를 예약하고 OS에는 32GB만 남깁니다. Linux는 이 분할을 수정할 수 없습니다. 펌웨어 UI가 Windows에만 있기 때문입니다. Windows에서 GPU 예약을 4GB로 낮추면 재부팅 후 Linux에서 전체 120GB RAM을 볼 수 있습니다.

"노트북은 기본적으로 GPU에 96GB의 통합 메모리를 예약하며, Windows에서만 이 분할을 변경하는 설정을 제공합니다. Linux가 RAM의 일부만 볼 수 있으려면 이 설정이 필요합니다." – MindStudio 블로그

WSL: 실용적인 중간 지점

WSL은 Windows 드라이버 스택 위에서 실행되므로 Windows 전원 관리 로직을 상속하여 전원 공급원에 관계없이 전체 GPU 부스트를 유지합니다. WSL의 메모리 할당(기본 14GB)을 더 큰 값으로 늘린 후 벤치마크 결과는 네이티브 Windows와 구별할 수 없습니다.

"WSL은 Windows 커널과 드라이버 스택 위에서 Linux 환경을 실행하므로 Windows의 GPU 클럭 부스트 동작을 유지하고 제한 문제를 피하면서 vLLM과 같은 Linux 우선 AI 도구를 계속 지원합니다." – MindStudio 블로그

Linux 도구가 필요하지만 5배 느려지는 것을 받아들일 수 없는 개발자에게 WSL은 현재 최상의 성능 대 편의성 비율을 제공합니다.

커뮤니티 반응 및 가능한 해결 방안

Nvidia의 폐쇄적 접근 방식 – 여러 댓글 작성자(예: @jleask, @laughing_man)는 Nvidia가 중요한 펌웨어를 암호화하여 성능에 대한 독점을 강요하는 습관을 비판합니다.
역공학 기대 – @viraptor와 @bitbasher 같은 사용자는 커뮤니티가 결국 전원 테이블을 역공학할 수 있을 것이라고 제안하지만, 그러한 해킹은 취약하고 단일 시스템에만 적용될 수 있음을 인정합니다.
상위 수정 기대 – 적절한 해결책은 Nvidia가 Linux 드라이버에 전원 관리 로직을 제공하는 것이라는 데 의견이 모입니다. 과거 Dynamic Boost와 같은 기능이 지연 후 Linux에 추가된 것과 유사합니다.
대체 하드웨어 – 일부 댓글 작성자(예: @demo4567)는 역사적으로 더 개방적인 전원 관리 인터페이스를 가진 AMD GPU로 전환할 것을 암시합니다.

RTX Spark 소유자를 위한 실용 체크리스트

이중 부팅 – Nvidia 오픈 드라이버를 번들로 제공하는 배포판(예: Omarchy)을 사용하여 기능적인 데스크톱을 얻습니다.
통합 메모리 조정 – Windows로 부팅하고 Nvidia Platform Controllers 설정을 열고 GPU 메모리 예약을 줄인 후(예: 4GB) Linux로 부팅합니다.
AC 전원에서 제한 예상 – 전체 성능이 필요하면 WSL에서 워크로드를 실행하거나 노트북을 배터리로 사용합니다.
GPU 클럭 모니터링 – nvidia-smi를 사용하여 클럭이 약 2GHz에 가까운지 확인합니다. 약 780MHz로 유지되면 Linux 제한에 직면한 것입니다.
드라이버 업데이트 주시 – Nvidia 릴리스 노트에서 Linux에서 "Platform Controllers" 또는 "Power Table" 지원에 대한 언급을 확인합니다.

결론

Linux는 Nvidia RTX Spark 노트북에서 실행될 수 있지만, 암호화된 Windows 전용 전원 관리 펌웨어 구성 요소가 전원 연결 시 GPU를 약 780MHz로 제한하여 AI 추론 속도를 약 65% 감소시킵니다. Nvidia가 동등한 Linux 드라이버를 제공할 때까지 전체 성능을 유지하는 유일한 신뢰할 수 있는 방법은 WSL 또는 Windows 자체에서 워크로드를 실행하는 것입니다.