NVIDIA Didn''t Want Me to Do This…Linux on RTX Spark

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

RTX Spark 노트북에서 Linux는 구동되지만, 전원 제어 지원 부족으로 전원 연결 시 AI 성능이 크게 떨어져 현재는 WSL이 현실적인 선택이다.

📌 핵심 요점

1. MSI Prestige N16 Flip AI Plus의 RTX Spark N1X는 Windows on ARM과 CUDA를 결합한 플랫폼이다. 최대 128GB 메모리를 제공하지만, Linux 사용 가능성은 하드웨어 사양만으로 판단하기 어렵다.
2. 네이티브 Linux에서 데스크톱과 CUDA 실행에는 성공했다. 다만 설치 과정에서 화면 출력, Wi-Fi, 키보드·터치패드 인식 문제가 발생했고, 지원 커널과 드라이버를 확보하는 과정이 필요했다.
3. 메모리 예약 설정도 제약이었다. GPU용으로 96GB가 예약된 상태에서는 Linux가 약 28GB만 인식했고, Windows에서 예약량을 4GB로 줄인 뒤에는 약 120GB를 사용할 수 있었다.
4. 핵심 문제는 전원 연결 시 GPU 클록 하락이었다. GPTOSS120B 비교에서 Windows는 65.4토큰/초, WSL은 65.1토큰/초였지만 네이티브 Linux는 13.9토큰/초에 그쳤다. 별도의 배터리 구동 시험에서는 Linux에서도 61~67토큰/초가 관찰됐다.
5. 발표자는 Windows의 NVIDIA Platform Controllers and Framework를 끄면 GPU 클록과 처리량이 함께 떨어지는 현상을 확인했다. Linux에 대응 지원이 없는 점을 핵심 원인으로 지목하며, 당장은 Windows 드라이버를 사용하는 WSL을 권했다.

🧩 배경과 문제 정의

영상은 Windows를 기본 운영체제로 사용하는 RTX Spark 노트북에서 네이티브 Linux를 실행할 수 있는지 검증한다. 시험 장비는 NVIDIA RTX Spark N1X를 탑재한 MSI Prestige N16 Flip AI Plus다. 발표자는 이 계열이 Linux를 사용하는 DGX Spark와 같은 GPU 설계를 공유한다고 설명하며, Linux 중심 AI 개발 도구를 노트북에서도 활용하려 한다.

문제는 부팅 성공을 넘어선다. Windows on ARM에서의 패키지 호환성, WSL의 실행 성능, 통합 메모리 배분, 노트북의 CPU·GPU 전력 배분까지 확인해야 실제 개발 장비로 사용할 수 있다. 발표자는 Windows를 유지하는 듀얼 부팅부터 시도하고, 설치 성공 뒤에는 AI 추론 성능과 전원 연결에 따른 차이를 조사한다.

🕒 시간순 섹션별 상세정리

1. RTX Spark 노트북에서 Linux를 실행하려는 이유

• 발표자는 RTX Spark 노트북과 Linux 기반 DGX Spark의 GPU 설계 공통점을 출발점으로 삼는다. Linux 실행을 확인하는 데 사흘이 걸렸으며, 검은 화면과 시스템 멈춤, 커널 패닉을 겪었다고 보여준다. [00:48]
• 시험 장비는 MSI Prestige N16 Flip AI Plus이며, RTX Spark N1X와 Windows on ARM을 사용한다. 이 계열은 최대 128GB 메모리를 제공한다고 보여준다. [01:29]

2. 기존 성능과 Linux 검증의 필요성

• 협찬 구간에서는 음성 입력 도구 Whisper Flow가 발화 중 수정과 군더더기를 정리하고, 코드 편집기나 메일 등에서 사용할 수 있다고 보여준다. 이후 하드웨어 검증으로 돌아간다. [02:57]
• 기존 GPTOSS120B GPU 시험에서 Windows는 65.4토큰/초, WSL은 65.1토큰/초, DGX Spark는 61토큰/초를 기록했다. 발표자는 이 비교에서 노트북의 Windows 성능이 충분히 높았다고 평가한다. [03:38]
• Linux 우선 AI 도구의 실행 여부, Windows ARM64용 Python 패키지 부족, WSL 성능, GPU 예약 메모리 배분이 주요 검증 과제로 드러난다. [04:40]

3. 듀얼 부팅 설치와 하드웨어 인식 문제

• Windows를 유지하는 듀얼 부팅을 시도하고, Claude Code가 JetKVM을 통해 재부팅과 입력을 수행하도록 구성한다. 설치 중 HDMI 출력이 나오지 않아 MacBook Air 카메라로 노트북 화면을 촬영하는 우회 방법까지 사용한다. [05:44]
• 전사에 ‘Omari’로 표기된 환경을 먼저 시도하지만 화면이 반복해서 바뀌며 정상 동작하지 않는다. 다른 제조사 노트북에서의 지원이 MSI 기종에서도 그대로 적용되지는 않았다. [06:11]
• Debian 설치에서는 Wi-Fi에 연결하지 못해 USB Ethernet을 사용했고, 기본 상태에서 키보드·터치패드·GPU가 인식되지 않았다. 이후 NVIDIA 오픈 드라이버가 포함된 커널을 갖춘 환경으로 다시 전환한다. [06:37]

4. 메모리 예약 조정과 Linux 실행 성공

• 128GB 장비인데 Linux에서는 약 28GB만 보였다. 발표자는 GPU용 96GB 예약이 원인이라고 설명하며, Windows에서 예약량을 4GB로 낮춘 뒤 Linux가 약 120GB를 인식했다고 보고한다. [06:58]
• NVIDIA GPU로 4K·120Hz 데스크톱을 실행하고, 키보드·터치패드·오디오·CUDA 동작을 확인한다. YouTube 영상도 소리와 함께 정상 재생됐다. [07:17]
• ARM64 Linux와 CUDA를 지원하는 LM Studio에서 텍스트 생성을 실행한다. GPU 사용률이 거의 100%에 도달해 실제 GPU 추론이 동작하는 것을 확인한다. [07:48]

5. 전원 연결 시 드러난 성능 역전

• 초기 LM Studio 시험에서 배터리 구동은 61토큰/초였지만 전원을 연결하자 약 15토큰/초로 떨어졌다. 다시 분리하면 67토큰/초로 회복됐고, 두 경우 모두 전원 모드는 균형 설정이었다. [08:21]
• 부하 중 GPU 클록은 배터리 구동 시 약 1,800MHz, 전원 연결 시 약 780MHz로 관찰됐다. GPTOSS120B 비교에서는 Windows 65.4토큰/초, WSL 65.1토큰/초에 비해 Linux가 13.9토큰/초를 기록했다. [09:16]
• 전사상 ‘VLM’의 8개 클라이언트 시험에서도 WSL은 127토큰/초, Linux는 39.5토큰/초였다. 온도는 40~47°C 수준이었으며, 다른 비교 실행에서는 Windows가 약 2.2GHz로 8분, Linux가 약 790MHz로 37분 걸렸다고 보여준다. [09:49]

6. Windows 전원 제어 컨트롤러 추적

• 발표자는 노트북의 CPU와 GPU가 전력 예산을 공유한다는 점에 주목한다. Windows 장치 관리자에서 NVIDIA Platform Controllers and Framework를 찾고, 이에 대응하는 Linux 버전이 없다고 보여준다. [10:30]
• Windows에서 컨트롤러를 끄자 한 시험의 처리량이 약 68토큰/초에서 31토큰/초로 떨어졌다. 별도 반복에서도 활성화·비활성화·재활성화에 따라 처리량과 클록이 함께 변했고, 비활성화 시 약 786MHz로 Linux의 낮은 클록과 유사해졌다. [11:11]
• 발표자는 펌웨어가 전달하는 전원 설정표가 암호화돼 Linux에서 읽지 못한다고 보고한다. 접근 시도로 클록을 높이지 못했고 커널 패닉도 발생했으며, 범용 해결에는 NVIDIA의 구현이 필요하다고 판단한다. [11:44]

7. 현재의 실용적 선택과 남은 조건

• 발표자는 전원 연결 상태의 Linux 성능이 시험에 따라 Windows의 약 6분의 1에서 절반 수준이었다고 정리한다. Windows 드라이버를 통해 전원 연결 여부와 관계없이 부스트를 유지하는 WSL을 현재의 실용적인 대안으로 제시한다. [12:08]
• WSL에서는 기본 14GB 메모리 할당을 조정해야 했다고 보여준다. Linux는 펌웨어의 GPU 예약 설정을 그대로 받는 반면, Windows에서는 해당 메모리 배분 문제가 개선됐다는 Wendell의 설명도 보여준다. [12:31]
• 발표자는 현재 Linux 용도로 이 노트북을 구매하지 않겠다고 결론짓는다. NVIDIA가 Linux 드라이버에 컨트롤러 지원을 추가하면 휴대형 DGX Spark처럼 활용할 수 있다는 기대를 밝히고, 의견 요청과 후속 리뷰 안내로 마무리한다. [12:54]

🧾 결론

• Linux 설치와 AI 추론 실행은 가능했지만, 전원을 연결하고 지속적으로 사용하는 개발 환경으로는 성능 제약이 컸다.
• Windows에서 컨트롤러를 비활성화했을 때 Linux와 유사한 낮은 클록이 재현됐다. 이는 전원 관리 지원의 중요성을 보여주지만, 모든 원인을 분리한 검증은 아니다.
• 영상의 테스트에서는 WSL이 Windows에 가까운 처리량과 Linux 도구 실행 환경을 함께 제공했다. 발표자는 Linux 전용 용도로 이 노트북을 구매하는 데 부정적이었다.

📈 투자·시사 포인트

• AI 노트북의 활용 가치는 메모리 용량과 GPU 설계뿐 아니라 운영체제별 드라이버, 전원 관리, 개발 도구 지원에 좌우된다. 구매와 도입 평가에 실제 작업 부하 검증을 포함필요가 있다.
• 이 사례에서는 Windows와 WSL의 소프트웨어 지원이 하드웨어 성능을 실사용으로 연결했다. Linux 중심 조직은 설치 가능 여부와 지속적인 추론 성능을 별도로 평가해야 한다.
• NVIDIA가 Linux용 전원 제어 지원을 제공한다면 휴대형 AI 개발 장비로서의 활용 범위가 넓어질 수 있다. 다만 영상에는 지원 일정이나 제공 약속이 제시되지 않았다.

⚠️ 불확실하거나 확인이 필요한 부분

• 결과는 발표자가 사용한 MSI 노트북과 당시 소프트웨어 구성에서 나온 관찰이다. 다른 제조사의 RTX Spark 노트북이나 다른 커널·드라이버 조합에서도 동일하다고 단정할 수 없다.
• 전원 제어 컨트롤러와 성능 저하의 연관성은 Windows 비활성화 실험으로 뒷받침된다. 그러나 Linux에서 정식 지원을 적용해 성능 회복을 확인한 것은 아니며, 암호화된 전원 설정표에 관한 설명도 발표자의 조사 결과다.
• LM Studio 초기 시험과 GPTOSS120B 비교 시험은 같은 조건으로 묶어 해석하면 안 된다. 초기 시험의 모델명과 전체 실행 조건은 전사에 충분히 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 구매 전 해당 제조사·모델의 Linux 커널, GPU 드라이버, 입력 장치와 외부 화면 출력 지원 상태를 확인한다.
• 같은 모델·양자화·동시 요청 수를 고정하고 Windows, WSL, 네이티브 Linux의 처리량을 비교한다. 전원 연결 여부와 GPU 클록도 함께 기록한다.
• Linux 설치 전 복구 수단과 유선 네트워크·외부 입력 장치를 준비하고, Windows를 유지하는 듀얼 부팅 구성을 검토한다.
• GPU 예약 메모리와 운영체제에서 실제로 보이는 메모리를 확인한다. WSL도 영상의 시험 환경에서는 기본 할당이 14GB였으므로 작업에 필요한 할당량을 점검한다.

❓ 열린 질문

• NVIDIA는 이 플랫폼의 전원 제어 기능을 Linux 드라이버에 제공할 것인가? 제공한다면 어떤 기종과 버전부터 지원할 것인가?
• Linux에서 전원을 연결할 때 GPU 클록이 더 낮아지는 동작은 정식 지원으로 완전히 해소될 수 있는가?
• 다른 RTX Spark 노트북에서도 같은 메모리 예약 제약과 성능 저하가 재현되는가?