요약
Nvidia RTX Spark 노트북에 리눅스를 깔면 전원을 꽂았을 때 GPU 클럭이 묶여 추론이 몇 배 느려집니다.
마인드스튜디오 블로그가 RTX Spark 노트북인 MSI Prestige N16 Flip AI Plus에 리눅스를 듀얼 부팅으로 깔아 본 사용기입니다. 이 플랫폼은 데스크톱용 DGX Spark와 같은 GPU 설계를 쓰지만, 노트북은 ARM용 윈도를 깔고 출시됩니다.
왜 중요한가
- 같은 하드웨어인데도 운영체제에 따라 추론 성능이 다섯 배 가까이 벌어집니다.
- 원인이 커널이나 배포판이 아니라 암호화된 펌웨어라서, 사용자나 커뮤니티가 고칠 길이 사실상 막혀 있습니다.
- 리눅스로 로컬 AI를 돌리려던 사람은 엔비디아가 리눅스 드라이버를 보완할 때까지 WSL(윈도 안에서 리눅스를 돌리는 기능)을 거쳐야 합니다.
핵심 내용
- 리눅스에서 GPU는 전원을 연결하면 약 780MHz에 묶이고, 오히려 배터리로 돌릴 때 1,800MHz 안팎까지 올라갑니다.
- 전원을 꽂은 상태의 GPT-OSS-120B 추론 속도는 윈도가 초당 65.4토큰, 리눅스가 13.9토큰이었습니다.
- 원인은 CPU와 GPU에 전력을 나눠 주는 윈도 전용 구성 요소이며, 윈도에서 이를 끄자 같은 현상이 나타났습니다.
- 펌웨어의 전력 테이블은 암호화돼 있어 윈도 드라이버만 풀 수 있고, 리눅스에서 시도한 방법은 모두 실패했습니다.
- WSL은 윈도 드라이버를 그대로 써서 초당 65.1토큰을 냈고, 필자는 당분간 이쪽을 현실적인 선택으로 권했습니다.
HN 반응
- 윈도 전용 신제품이라 리눅스 지원이 늦을 뿐이라는 옹호와, 사업 대부분이 리눅스에서 도는 엔비디아라면 첫날부터 지원해야 한다는 반론이 맞섰습니다.
- 전력 테이블 암호화는 외부 드라이버 개발을 막을 뿐이라는 비판과, 배터리에서 오히려 빠른 것을 보면 의도보다 버그에 가깝다는 시각이 함께 나왔습니다.
기사부터 읽으세요. 여기 댓글들은 완전히 잘못 알고 쓴 얘기투성이입니다.
윈도 노트북용으로 설계된 펌웨어를 리눅스 드라이버가 아직 지원하지 않는 것뿐입니다.
문제가 확인된 건 RTX Spark 플랫폼을 쓰는 MSI Prestige 노트북입니다. RTX Spark를 쓰는 에이수스와 델 제품도 마찬가지일 거라고 가정해 보죠.
RTX Spark는 새 플랫폼이고 이 노트북들은 전부 윈도를 깔아서 출고됩니다. 공장 출하 상태로 리눅스가 깔린 제품은 하나도 없습니다. 엔비디아가 윈도보다 한참 늦게 리눅스를 지원한 전례도 있고요(전력 분배 기능이 비슷한 Dynamic Boost는 2년이 걸렸습니다).
윈도용으로 설계됐든 말든 상관없습니다. 리눅스에서도 똑같이 잘 돌아가야 합니다.
모든 OS와의 호환성을 보장하는 건 OEM의 일이 아닙니다. 예를 들어 윈도 XP에서 잘 돌아가도록 해야 할 의무는 없잖습니까.
윈도 XP는 2014년 4월 8일에 지원이 끝났습니다. "리눅스"는, 최신 리눅스 커널을 말씀하시는 거라면, 아직 아닙니다.
그럼 macOS, Chrome OS, FreeBSD도 전부 지원해야 하나요? 이 노트북은 윈도에서 쓰라고 만든 겁니다. 판매할 때 내세운 범위를 넘어서까지 호환성을 책임질 이유는 없습니다.
사실상 해야 합니다. ChromeOS는 리눅스 커널을 쓰니까 CUDA를 돌리는 데 필요한 유저랜드는 다 갖춰져 있습니다. FreeBSD는 엔비디아 드라이버의 1순위 지원 대상이고, macOS도 예전에는 지원했는데 엔비디아 코드에 서명해 주는 걸 중단했습니다. 그래도 CUDA 등은 AArch64를 여전히 지원합니다.
사용자가 어떤 플랫폼을 쓰게 할지는 엔비디아가 정할 일입니다. 엔비디아의 경우에는 그게 여러 OS를 지원한다는 뜻이고요.
기사에는 이런 대목이 있습니다. "진짜 해결책은 엔비디아에 달려 있다. 구체적으로는 플랫폼 컨트롤러의 전력 관리 로직을 리눅스 드라이버로 옮겨야 하며, 그렇게 되면 사실상 이 노트북은 휴대용 DGX Spark가 된다."
제 요점은 그게 엔비디아의 책임이 아니라는 겁니다. 기사 스스로 이 노트북이 "Windows on ARM을 탑재해 출고된다"고 인정하고 있으니, 엔비디아가 다른 플랫폼이나 다른 제품군은 다르게 지원한다 해도 다른 OS 지원을 기대해서는 안 됩니다.
그런데 이건 "다른 제품군"이 아닙니다. RTX와 Spark SoC 제품은 하드웨어 전체에서 리눅스를 1순위로 지원합니다. RTX Spark만 예외인 거고, 문제가 생긴 곳도 GPU 제품이 아니라 SoC 디바이스트리 드라이버입니다. 엔비디아가 ACPI/UEFI 같은 표준 윈도 전력 관리를 피했기 때문에 생긴 문제고, 나머지를 직접 손으로 리눅스에 이식해야 하는 겁니다. DGX Spark 같은 비노트북 제품은 UEFI로 이걸 기본 지원합니다.
이런 책임을 거부하는 OEM이 있긴 합니다. 그걸로 입증하고 싶으셨던 거라면 그렇게 하시죠. 다만 이번 문제가 치명적인 실수는 아닙니다.
제가 마지막으로 확인했을 때 HaikuOS와 React OS는 지금도 활발히 개발되고 있습니다.
적어도 사람들이 산 하드웨어를 원하는 대로 쓸 수 있을 만큼의 하드웨어 사양은 공개해야 합니다.
의도하지 않은 OS용 드라이버를 만들 생각이 없어서 좋은 드라이버가 없는 정도의 문제가 아닙니다. 펌웨어의 전력 테이블을 암호화하는 건 서드파티가 좋은 드라이버를 개발하는 걸 방해하는 것 말고는 아무 목적이 없습니다.
왜 그렇게까지 하고 싶었는지 저는 잘 모르겠습니다.
개인적으로는 알 바 아닙니다. 오픈 드라이버를 지원하지 않을 거면, 첫날부터 리눅스용 1급 드라이버를 반드시 내놔야 합니다. 엔비디아 사업의 대부분이 이미 리눅스 위에서 돌아가고 있으니까요.
게다가 엔비디아는 자기들이 리눅스 지원이 최고고, 동급에서 가장 좋은 드라이버를 만든다고 주장합니다.
그러니 그 말대로 행동하고 지원을 제공하는 게 맞습니다. 다른 회사가 이랬다면 벌써 인터넷의 증오에 세 번은 불타 없어졌을 겁니다.
엔비디아가 늘 하던 대로 하고 있네요. 독점 비공개 드라이버요. 전력 설정을 암호로 보호한다는 건 이상한 선택이지만요. 진짜 문제는 이런 짓을 늘 해 온 회사가 독점을 이루도록 우리가 놔뒀다는 겁니다. 다른 브랜드도 있으니, 이제는 힘들더라도 갈아타서 다른 곳에서 새로 쌓아 볼 만하지 않을까요.
누가 "놔뒀다"고는 생각하지 않습니다. 오히려 정반대죠. 엔비디아는 세대를 건 도박을 했고 그게 맞아떨어졌습니다. 제가 기억하기로 업계는 오랫동안 그 도박에 동의하지 않았고요. CUDA를 밀어붙이다가 기업 가치가 75%쯤 빠지는 말도 안 되는 일까지 겪었습니다. 지금 자리에 오르기까지 전 재산을 여러 번 걸었고, 그게 "뻔해" 보이는 건 결과를 알고 난 뒤의 일입니다.
사람들이 세대를 건 도박을 당연하게 하길 바란다면(대부분 그렇게 생각하는 것 같습니다), 그 도박의 손실은 한곳에 모으고 이익은 모두가 나눠 가지게 하는 건 좋은 전략이 아닙니다. 손실까지 모두가 나눠 지는 것과 별 차이가 없을 정도로 나쁘죠.
결국 경쟁이 그 격차를 좁힐 겁니다. 이제 막 몇 년 지났을 뿐이잖아요.
독점은 저절로 무너지지 않아요. 경쟁자를 사들이거나 말려 죽일 수 있는 거대 기업을 상대로 경쟁이 격차를 좁힐 수는 없습니다.
엔비디아가 시장을 장악한 건 알지만, AMD, 인텔, 구글에 쓸 만한 대안이 없는 건 아닙니다. Hipify, OneAPI, MLIR(Jax 등)은 지금도 쓸 수 있습니다. 다만 CUDA만큼 편하지 않을 뿐이죠.
20초만 찾아봤어도 "독점은 저절로 무너지지 않는다"는 말이 틀렸다는 걸 알았을 겁니다.
US 스틸, IBM, 코닥, 웨스턴 유니언 들어 보셨나요?
그 독점들은 경쟁 같은 시장의 힘이 아니라, 자신들이 제때 받아들이지 못한 새 기술 때문에 무너지거나 약해진 겁니다.
새 기술이야말로 자연스러운 경쟁이라는 시장의 힘이 주로 작동하는 방식입니다.
음... 그건 동의하기 어렵네요. 기술적 돌파구는 "자연스러운" 게 아닙니다. 엔비디아를 쓸모없게 만들 무언가를 누가 발견해 주길 바라고 기다리는 처지가 되어서는 안 됩니다.
Blackwell 같은 새 세대는 오픈소스 커널 모듈을 쓰고, 독점 옵션은 아예 없습니다. 이쪽으로 가는 흐름이 있는 줄 알았는데요?
https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules
엔비디아는 예전에 독점 드라이버에 있던 기능을 여전히 독점인 GPU 펌웨어로 넘겨서 그걸 가능하게 했습니다. 오히려 오픈소스 성격이 더 약해진 셈입니다. 이제는 커널조차 손댈 수 없는 곳으로 넘어가 버려서, 런타임에 무슨 일을 하는지 들여다보기가 더 어려워졌으니까요.
제가 알기로는 오픈소스 커널 드라이버가 서명된 독점 500Mb짜리 펌웨어 덩어리를 GPU에 밀어 넣습니다.
Archlinux의 linux-firmware-nvidia 패키지 전체를 압축 해제하면(바깥쪽 기준이고, 펌웨어 덩어리는 그 안에서도 따로 압축돼 있습니다) 약 160MB입니다(Mb는 메가비트입니다). 개별 덩어리 중 가장 큰 것도 압축된 상태로 약 50MB고요.
맞습니다, 펌웨어 패키지는 더 작네요. 로드된 뒤 GSP가 쓰는 VRAM과 헷갈렸습니다.
제 요점은 커널 드라이버가 오픈소스라고 해서 해킹이 가능해지는 건 아니라는 겁니다. 카드 하드웨어는 예전만큼이나 닫혀 있어요.
50MB면 코드가 엄청 많은 겁니다. 최소 구성의 리눅스 커널은 그보다 훨씬 적게 씁니다.
그렇지 않다고 말하려던 건 아니었습니다. AMDGPU 펌웨어 패키지는 전체가 27MB이고 가장 큰 덩어리가 1.5MB입니다.
전혀 이상하지 않아요. 사람들이 이 노트북을 사서 리눅스를 깔고 데이터센터에 쟁여 둘 걸 아니까 그걸 막으려는 겁니다.
이 노트북들은 아닙니다.
저도 사양을 보기 전에는 이 기기가 정말 기대됐습니다. 6년 전 나온 rtx3090 같은 GPU가 900GB/s 넘는 메모리 대역폭을 냈는데, 이건 아직도 300GB/s도 안 됩니다.
이건 로컬 추론 사용자들에게 빵 부스러기나 던져 주는 겁니다.
이제는 메모리 대역폭을 TB 단위로 재야 합니다. 이 부분에 진지해 보이는 회사는 애플뿐입니다(m5 ultra studio 등).
그게 비용 면에서 효율적이라면 왜 굳이 이 노트북을 사겠습니까? 비슷한 가격에 성능도 비슷하고 폼팩터도 더 편한 DGX Spark를 사면 되는데요.
아니면 RTX Spark를 사서 WSL로 워크로드를 돌려도 되고요. 기사에서도 WSL은 리눅스를 직접 돌릴 때와 비교해 오버헤드가 거의 없다고 했잖아요.
이건 기능이라기보다 버그 같은데요. 특히 리눅스에서는 배터리일 때 최대 클럭으로 돌고 전원을 연결하면 클럭이 내려가는 반면, 윈도는 그 반대라는 점을 보면 더 그렇습니다. 그렇다면 펌웨어에서 조건문 하나만 뒤집고, 윈도에는 이미 있는 것으로 보이는 메모리 할당 제어용 커널 파라미터를 리눅스에 추가하면, 소프트웨어 스택은 건드리지 않고도 적어도 문제를 완화할 수 있다는 얘기니까요.