NVIDIA Put a DGX Spark in a Laptop…Almost
Quick Summary
MSI의 RTX Spark 노트북은 DGX Spark급 대형 로컬 AI 실행을 휴대 가능한 형태로 구현했지만, 실제 선택은 작업 방식과 상시 운용 여부에 달려 있다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론
MSI의 RTX Spark 노트북은 DGX Spark급 대형 로컬 AI 실행을 휴대 가능한 형태로 구현했지만, 실제 선택은 작업 방식과 상시 운용 여부에 달려 있다.
📌 핵심 요점
- MSI Prestige N16 Flip AI Plus의 128GB 모델에서 120B·125B급 모델 실행을 시연했다. 다만 시스템 메모리 전체를 GPU에 사용하는 것은 아니며, 영상에서는 주로 96GB를 GPU에 할당했다.
- GPT-OSS 120B 비교에서 빈 컨텍스트 기준 생성 속도는 Windows 65.4토큰/초, WSL 65.1토큰/초, DGX Spark 50.6토큰/초였다. 특정 모델과 동일한 llama.cpp 버전에서 얻은 결과다.
- Windows on ARM에서 주요 개발 도구가 네이티브로 실행됐지만, Python 계산 작업은 WSL이 더 빨랐다. 운영체제 전체의 우열보다 언어·런타임별 선택이 중요했다.
- llama.cpp는 단일 사용자 생성 속도에, 전사에서 ‘VLM’으로 표기된 서빙 엔진은 프롬프트 처리와 동시 요청 처리에 강점을 보였다. 로컬 채팅과 여러 에이전트 운용은 서로 다른 실행 환경을 요구한다.
- CPU·GPU 동시 부하를 20분간 유지해도 측정 성능은 떨어지지 않았다. 다만 칩 온도는 평균 약 93°C, 최고 약 98.6°C였으며, 배터리 지속시간은 제시되지 않았다.
🧩 배경과 문제 정의
영상은 DGX Spark와 같은 대형 로컬 AI 실행 환경을 노트북으로 옮길 수 있는지 검증한다. 대상은 MSI Prestige N16 Flip AI Plus의 128GB 구성으로, 제조사가 제시한 120B 모델 실행과 열에 따른 성능 저하 없는 지속 성능을 확인하는 것이 출발점이다.
검증은 외형과 입력 장치에서 시작해 Windows on ARM 호환성, CPU 성능, 메모리 대역폭, 모델별 추론 속도, 실행 엔진별 특성, 배터리 상태의 성능과 지속 부하로 이어진다. 핵심 판단 기준은 개발과 로컬 AI를 휴대 가능한 한 기기로 처리할 수 있는지, 그리고 고정형 DGX Spark와 어떤 용도로 구분되는지다.
🕒 시간순 섹션별 상세정리
1. DGX Spark를 닮은 노트북의 첫인상
- 발표자는 128GB 메모리를 갖춘 MSI Prestige N16 Flip AI Plus를 소개하고, 120B 모델 실행과 스로틀링 없는 성능이라는 제조사 주장을 검증하겠다고 드러낸다. [00:39]
- 뒤로 접히는 구조와 견고한 만듦새, 클릭감 있는 키보드를 긍정적으로 평가한다. 큰 터치패드는 잘 반응하지만 햅틱 방식이 아닌 점을 아쉬워하며, USB-A를 포함한 여러 포트와 작은 140W 충전기를 살펴본다. [02:03]
- 화면은 16인치 4K 탠덤 OLED, 120Hz 터치스크린으로 묶인다. 접이식 활용을 확인한 뒤 성능 검증으로 넘어간다. [02:31]
2. Windows on ARM에서 개발 도구가 실행되는가
- 작업 관리자에서 N1X 칩, 20코어 CPU, 128GB LPDDR5 메모리를 확인하고 Windows on ARM 환경임을 보여준다. [02:52]
- 대부분의 개발 도구가 지원된다고 소개하면서도 일부 예외가 있다고 덧붙인다. Adobe 제품은 대체로 네이티브이며, Premiere Pro는 에뮬레이션으로 실행된다고 보여준다. [03:28]
- Photoshop의 ARM64 실행과 함께 Visual Studio, VS Code, Zed, Python, Node의 네이티브 실행을 확인한다. 실행 중인 250개 이상의 서비스·워커 가운데 x64는 네 개라고 드러낸다. [03:57]
3. CPU 성능은 언어와 실행 환경에 따라 달라진다
- Speedometer 3.1은 네 차례 시험에서 35~37점을 기록했다. 20개 코어를 사용하는 Python 계산 시험은 Windows에서 평균 약 22초가 걸렸고 팬 소리가 들렸다. [05:02]
- 같은 계산은 WSL에서 더 빨랐으며, 발표자는 DGX Spark의 16초 결과와 비슷한 수준이라고 보여준다. 단일 코어 JavaScript 시험은 Windows와 Linux 모두 1.24초여서, 이 사례의 차이를 Python 실행 환경에서 찾는다. [06:49]
- 전원 연결 시 약 22초였던 CPU 시험은 배터리에서 23.2초로 소폭 느려졌다. 두 경우 모두 최고 성능 설정을 사용했으며, MSI Center의 에코 모드는 성능을 양보하는 대신 조용하다고 보여준다. [07:26]
4. 메모리 대역폭과 GPU 연산을 분리해 비교한다
- 발표자는 LLM 추론을 프롬프트 처리와 토큰 생성으로 나누고, 생성 속도에서는 메모리 이동 속도가 중요하다고 보여준다. [07:42]
- 자체 GPU 메모리 시험의 8GB 복사에서는 노트북 143GB/s, DGX Spark 113GB/s를 기록했다. 읽기 결과는 각각 309GB/s와 234GB/s였다. [08:02]
- 행렬 연산 측정값은 노트북 101, Spark 97로 비슷했다. 발표자는 이를 바탕으로 프롬프트 처리는 비슷하고 토큰 생성은 노트북이 조금 빠를 것으로 예상한다. [08:34]
5. 코드 편집기에서 대형 로컬 모델을 사용한다
- Zed의 에이전트에 120B 모델을 연결해 실행한다. 발표자는 VS Code 등에도 연결할 수 있으며 모델이 기기 안에서 로컬로 실행된다고 보여준다. [08:54]
- 제조사의 120B 기준보다 더 큰 모델도 시험하겠다고 예고한다. Windows와 Linux 중 하나를 고를 필요 없이 WSL로 함께 사용할 수 있다는 점도 강조한다. [09:15]
- nvidia-smi 화면에서 GPU가 사용할 수 있는 메모리를 98GB로 보여준다. 이후 모델 시험에서는 96GB를 기준으로 사용량을 보여준다. [09:22]
6. 모델 크기와 구조가 생성 속도를 바꾼다
- 이름이 ‘Quen 3.827B’로 전사된 밀집 모델은 약 22GB 크기이며 13.4토큰/초를 기록한다. 발표자는 64GB 구성에도 들어갈 수 있다고 설명하고, 밀집 모델은 토큰마다 모든 파라미터를 사용한다고 덧붙인다. [09:46]
- GPT-OSS 120B는 MoE 모델로 소개되며, 로딩에 28초가 걸리고 96GB 중 61GB를 사용한다. 동일 모델·동일 llama.cpp 버전의 빈 컨텍스트 비교에서 Windows 65.4, WSL 65.1, DGX Spark 50.6토큰/초를 기록한다. [10:48]
- 컨텍스트가 차면 모든 환경에서 속도가 떨어지지만 Windows가 우위를 유지했다고 보여준다. 배터리의 Windows 결과는 65.9토큰/초였고, WSL은 조금 느려졌으나 큰 하락은 아니었다. [11:25]
7. 단일 사용자와 동시 요청에 맞는 엔진이 다르다
- CUDA를 활용하는 서빙 엔진을 전사에서는 ‘VLM’으로 부른다. 발표자는 이 엔진을 Windows에서 빌드할 수 없어 WSL에서 사용하며, 데이터센터의 모델 서빙에도 쓰인다고 보여준다. [12:02]
- 프롬프트 처리는 llama.cpp가 약 1,800토큰/초, 해당 서빙 엔진이 4,681토큰/초였다. 반면 GPT-OSS 120B의 단일 사용자 생성은 각각 약 65토큰/초와 35토큰/초로 llama.cpp가 빨랐다. [12:44]
- 해당 서빙 엔진은 동시 사용자가 늘면 전체 처리량이 개선돼, 8개 동시 요청에서 127.5토큰/초를 기록했다. 발표자는 이를 여러 사용자뿐 아니라 여러 에이전트가 함께 사용하는 상황과 연결한다. [13:29]
8. 125B 모델과 GPU 메모리 할당의 한계
- ‘Quen 3.8 Flash Next’로 전사된 125B 모델은 36초에 로딩되고 96GB 중 81GB를 사용하며, 생성 속도는 33.7토큰/초였다. 발표자는 메모리 한계에 가까워졌다고 평가한다. [13:54]
- Windows의 파일명 길이 문제를 보여주고 긴 경로 사용 설정이 필요하다고 지적한다. [14:14]
- NVIDIA 앱에서 GPU 메모리 할당량을 조정할 수 있다. 작은 모델을 사용하거나 에이전트 등 시스템 작업에 메모리가 많이 필요하다면 배분을 바꿀 수 있다고 보여준다. [14:44]
9. CPU·GPU 동시 부하를 20분간 유지한다
- GPU의 모델 생성과 CPU 20코어 작업을 동시에 실행했다. 모델 생성은 처음 5분 약 50토큰/초, 마지막 5분 약 52토큰/초였고, CPU 계산은 시작과 끝 모두 26.3초였다. [15:22]
- 모델만 실행할 때의 약 68토큰/초가 동시 부하에서 약 50토큰/초로 내려갔지만, 하락은 처음부터 나타났다. 발표자는 이를 시간이 지나 열 때문에 느려지는 현상과 구분한다. [15:43]
- 칩 온도는 평균 약 93°C, 최고 약 98.6°C였다. 뜨겁게 작동했지만 시험 중 열 스로틀링은 보고되지 않았다고 정리한다. [15:58]
10. 휴대형 개발 환경과 상시 실행 장비의 선택
- 발표자는 개발 도구와 120B·125B 모델을 이동 중 한 기기에서 사용하려는 사람에게 이 노트북이 역할을 할 수 있다고 결론짓는다. [16:15]
- 고정된 장소에서 에이전트를 계속 실행하려는 용도에는 DGX Spark를 선택지로 제시한다. MSI 제품에는 시험한 128GB 외에 64GB·32GB 구성도 있다고 보여준다. [16:28]
- 매장에서 직접 접이식 구조를 확인할 수 있다고 안내하고, 다른 RTX Spark 기기도 추가로 다룰 예정이라고 예고하며 영상을 마친다. [16:42]
🧾 결론
- 이 제품은 개발 도구와 대형 로컬 모델을 한 기기에서 사용하는 이동형 개발 환경으로 가능성을 보였다.
- 일부 추론 시험에서는 DGX Spark보다 빨랐지만, 이를 모든 모델·작업에서의 우위로 확대할 수는 없다.
- 전원을 분리한 시험에서도 성능 저하는 작았지만, 이동 중 얼마나 오래 사용할 수 있는지는 별도 확인이 필요하다.
- 발표자는 휴대 작업에는 노트북을, 고정된 장소에서 에이전트를 상시 실행하는 용도에는 DGX Spark를 선택지로 제시했다.
📈 투자·시사 포인트
- AI 하드웨어의 비교 기준은 모델을 메모리에 올릴 수 있는지에서 실제 생성 속도, 긴 컨텍스트, 동시 요청 처리 능력으로 확장된다.
- 메모리 용량만큼 대역폭과 시스템·GPU 간 메모리 배분이 중요하다. 이번 시험에서는 메모리 대역폭 우위와 높은 토큰 생성 속도가 함께 관찰됐다.
- Windows on ARM의 개발 도구 호환성과 WSL 활용은 로컬 AI 노트북의 실용성을 판단할 핵심 요소다.
- 가격, 배터리 지속시간, 장기 운용 비용이 없어 제품의 경제성이나 관련 기업의 투자 매력까지 판단할 근거는 부족하다.
⚠️ 불확실하거나 확인이 필요한 부분
- 전사에는 ‘DGX’가 ‘DJX’로, 서빙 엔진이 ‘VLM’으로 표기되는 등 명칭 혼선이 있다. 일부 모델명도 불명확하므로 실제 제품·모델·엔진 이름과 버전을 확인해야 한다.
- GPT-OSS는 문맥상 120B 모델이지만 10:28에는 ‘12B’로 전사됐다. GPU 사용 가능 메모리도 앞부분의 98GB와 이후의 96GB가 혼재한다.
- 양자화 방식, 전체 컨텍스트 길이, 추론 설정, 소프트웨어 구성의 세부 조건이 제공되지 않아 수치를 그대로 재현하기 어렵다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- 구매 검토 모델의 메모리 구성을 확인하고, 시스템용 메모리와 GPU 할당량을 나눠 실제 모델·컨텍스트가 들어가는지 계산한다.
- 사용하는 개발 도구와 의존성의 Windows on ARM 지원을 확인하고, Python 작업은 Windows와 WSL에서 각각 측정한다.
- 실제 사용할 모델의 양자화·컨텍스트 조건을 고정한 뒤 프롬프트 처리 속도와 생성 속도를 따로 비교한다.
- 단일 사용자와 여러 에이전트 동시 실행을 구분해 llama.cpp와 영상에서 소개한 서빙 엔진을 시험한다.
❓ 열린 질문
- 긴 컨텍스트와 여러 에이전트가 동시에 메모리를 사용할 때 실질적인 처리량과 응답 지연은 어떻게 달라질까?
- 배터리로 대형 모델을 연속 실행하면 어느 정도의 작업 시간을 확보할 수 있을까?
- 32GB·64GB 구성에서는 어떤 모델과 개발 작업을 함께 실행할 수 있을까?