ASUS ProArt P16 RTX Spark N1X에서 구동하는 Arch Linux ARM: 116 GiB 통합 메모리 및 로컬 Qwen 벤치마크

한 Arch Linux 패키지 관리자가 ASUS ProArt P16 H7607BA-SE033W(128GB RTX Spark N1X 구성)에서 Arch Linux ARM을 부팅하는 데 성공했습니다. 보고서에 따르면 OS와 CUDA 모두 동일한 116.0 GiB 메모리 풀을 인식하며, 7-Zip 성능은 Windows와 거의 비슷하고, 로컬 Qwen3.8-Flash-Next-FP4-Local 체크포인트가 vLLM을 통해 약 30.9 tokens/s의 속도로 실행된다고 합니다. 이 글은 제어된 OS 비교가 아닌, 작동하는 포팅 사례를 다루고 있습니다. 저자는 이 수치가 운영 체제의 효과를 분리한 것이 아니라 두 가지 작동 구성 환경을 비교한 것임을 분명히 밝히고 있습니다.

저자인 Josie는 Arch의 패키지 관리자로서 Hugging Face에 GGUF 양자화 모델을 게시하며, 지난달에만 16만 건 이상의 다운로드를 기록했습니다. 동기는 간단했습니다. 해당 노트북의 공식 지원은 Windows 전용이며, 저자는 Microsoft 계정을 가지고 있지 않았기 때문입니다. 저자가 스스로 밝힌 이 게시물의 요약은 "아이구, Microsoft가 문제네(boo hoo microsoft bad)"입니다.

하드웨어 및 제약 사항

해당 기기는 ASUS ProArt P16 H7607BA-SE033W로, 128GB RAM, 6,144개의 CUDA 코어, 2TB SSD를 탑재하고 있습니다. ASUS는 Windows만 공식 지원합니다. 저자가 Windows를 피하는 이유로는 설정 중 개인정보 보호 문제, 작업 표시줄 위치 옵션에 대한 긴 대기 시간, OS 내 광고 등을 꼽았습니다.

Arch는 저자가 선호하는 배포판이며, 이번 빌드에는 Arch 패키지를 ARM으로 포팅하는 별도 프로젝트인 Arch Linux ARM을 사용하고 그 위에 하드웨어 지원을 추가했습니다. 저자는 이미 IBM 메인프레임에 Arch를 설치한 경험이 있어 이번에도 Arch를 시작점으로 삼았습니다.

포팅에 필요한 작업

콘솔과 작동하는 드라이버 스택을 확보하기 위해 몇 가지 구체적인 수정이 필요했습니다. 저자는 NVIDIA의 Ubuntu용 커널 작업을 기반으로 시작하여, 콘솔 확보에 필요한 ACPI 오버라이드 할당 및 프레임버퍼 매핑을 수정하고 노트북 자체 테이블에서 ACPI 오버라이드를 추출했습니다. NVIDIA 드라이버와 ASUS 스피커 펌웨어는 저자가 "인터넷상의 공식적인 장소"라고 부르는 곳에서 가져왔습니다. 키보드 지원을 위해서는 패치된 hid-asus가 필요했고, 오디오는 자체 머신 드라이버가 필요했습니다.

결과물은 부팅 가능한 USB 형태로 패키징되었으며, 하드웨어 지원을 설치하기 위해 업스트림 Archinstall 4.5를 확장했습니다. github.com/pfeifferj/archlinuxarm-proart-p16 저장소에는 자체 ACPI 테이블을 덤프하고 ASUS 드라이버 패키지에서 스피커 펌웨어를 로컬로 추출하는 단계를 포함한 빌드 스크립트와 패치가 포함되어 있습니다. 저자의 기기는 H7607BA.300 펌웨어를 실행 중입니다.

빌드 입력값은 해시로 고정되어 있습니다. 하드웨어 패키지는 저자의 Arch Linux 패키지 관리자 키로 서명되었으며, ACPI 오버라이드는 노트북 자체에서 가져왔습니다. 설치 프로그램은 커널, NVIDIA, 전원 관리 및 펌웨어 패키지를 IgnorePkg로 고정하여 유지하며, 일반 패키지는 Arch Linux ARM에서 계속 업데이트됩니다.

디스플레이는 3840 × 2400 해상도와 120Hz로 작동합니다. 저자는 NetworkManager, PipeWire, 그리고 NVIDIA CDI를 사용하는 루트리스 Podman을 사용합니다.

7-Zip 성능 대 Windows

CPU 비교에는 고정된 32 MiB 사전(dictionary)을 사용하는 네이티브 ARM64 7-Zip 26.04를 사용했습니다. 저자는 각 스레드 수에서 한 번의 웜업과 세 번의 측정 패스를 실행하여 중앙값을 취했습니다.

스레드	압축 (MiB/s)	압축 해제 (MiB/s)
1	6.18	118.26
20	141.77	1,629.60

Windows와의 비교를 위해 저자는 동일한 20코어 N1X를 탑재한 128GB HP OmniBook Ultra 16의 StorageReview 테스트 결과를 사용했습니다. StorageReview는 7-Zip 등급을 GIPS로 보고하므로, 저자는 원시 로그의 MIPS 등급을 1,000으로 나누어 맞췄습니다. 수치가 높을수록 좋습니다.

7-Zip 워크로드	ProArt, Linux (GIPS)	HP OmniBook, Windows (GIPS)	차이
1스레드 압축	7.221	7.31	−1.2%
1스레드 압축 해제	10.779	10.87	−0.8%
20스레드 압축	165.754	157.9	+5.0%
20스레드 압축 해제	148.471	144.5	+2.7%

단일 스레드 성능은 사실상 동점입니다. 20개 스레드를 모두 사용했을 때, Linux 설정이 압축에서 약 5%, 압축 해제에서 약 3% 앞섰습니다. 저자는 HP 리뷰에서 7-Zip 버전이나 사전 크기를 명시하지 않았기 때문에, 이 비율은 OS의 효과를 분리한 것이 아니라 두 노트북 설정을 비교한 것이라고 언급했습니다.

두 번째 데이터 포인트는 ComputerBase의 20코어 N1X 탑재 ProArt P16 테스트에서 나왔습니다. GIPS로 변환했을 때 Windows 7-Zip 점수는 155.774였으며, 저자의 3회 실행 중앙값은 157.084로, 155.759에서 157.193 GIPS 범위 내에 있었습니다. ComputerBase의 기기는 64GB 구성에 7-Zip 26.00을 실행 중이었으며, 차트에는 사전 크기가 나와 있지 않습니다.

메모리 분할: OS와 CUDA 모두에 116.0 GiB

메모리 구성은 가장 큰 차이점입니다. Linux 실행 시 시스템 RAM과 CUDA 총합 모두 116.0 GiB로 보고되며, 이는 동일한 물리적 풀에서 가져온 것입니다. Windows는 RAM을 전용 GPU, 공유, CPU 전용 영역으로 나눕니다. CPU 워크로드는 전용 GPU 영역을 사용할 수 없으며, GPU 할당은 CPU 전용 영역을 사용할 수 없습니다.

Windows NVIDIA 앱을 사용하면 사용자가 전용 예약 공간을 변경하고 재부팅할 수 있습니다. Frandroid의 128GB ProArt P16은 96 GiB에 도달했습니다. CUDA는 Windows의 메모리 예산 내에서 공유 RAM을 할당하여 그 이상을 사용할 수 있습니다. 91 GiB 전용 예약 설정에서 Frandroid의 Windows 설정은 공유 메모리를 포함하여 109.7 GiB의 CUDA 총합을 보고했습니다. Linux 설정은 116.0 GiB를 보고하여 약 6.3 GiB 더 많았습니다.

저자가 밝힌 우선순위는 워크로드 간에 예약 슬라이더를 옮기고 재부팅할 필요 없이 CPU 작업에도 대규모 풀을 사용할 수 있도록 하는 것입니다.

로컬에서 Qwen 실행

저자는 네이티브 ARM64 컨테이너에서 B12X CUDA 커널을 사용하여 NVIDIA의 Qwen3.8-Flash-Next-FP4-Local 체크포인트를 vLLM을 통해 실행했으며, 혼합 양자화와 FP8 KV 캐시를 사용했습니다. 실행 중에는 사고(Thinking) 기능이 꺼져 있었습니다.

모델을 로드하기 전, Linux는 110.9 GiB의 사용 가능한 RAM을 보고했습니다. vLLM은 모델 로드에 68.2 GiB를 기록했고 KV 캐시에 21.1 GiB를 추가로 할당하여, 노트북에서 모델과 KV 캐시에 거의 90 GiB가 할당되었습니다. 모델 로드 및 컴파일에는 첫 번째 요청 전까지 약 16분이 소요되었습니다. PLE 임베딩 테이블은 디스크에 백업되어 있으며 웜 페이지 캐시의 이점을 활용합니다. 다른 구성 요소는 CPU 오프로드를 사용합니다. CUDA가 추론을 처리하며, 모델의 일부는 GPU 메모리 외부에 있습니다.

테스트 작업은 검토할 두 개의 버그가 있는 Python 도우미, 실패한 작업이 하나 포함된 긴 사고 로그 찾기, JSON으로 변환할 결제 메모였습니다. 각 작업은 웜업 후 세 번씩 실행되었으며, 확인을 위해 정답을 알고 있는 상태였습니다.

작업	입력 토큰	첫 번째 토큰, 중앙값 (s)	전체 응답, 중앙값 (s)	확인 통과
Python 코드 검토	208	0.316	4.008	3/3
128개 레코드 사고 로그에서 실패 찾기	9,775	4.532	5.768	3/3
결제 메모 추출	87	0.256	2.035	3/3

사고 로그 작업은 거의 10,000개의 토큰을 읽고 6초 이내에 올바른 요청, 원인 및 다음 조치를 반환했습니다. 답변은 39토큰에 불과하여 전체 요청에 대해 6.8 tokens/s의 속도를 보였습니다. 대기 시간의 대부분은 프롬프트 처리에 소요되었으므로, 저자는 해당 작업에 대해 tokens/s 수치보다 응답 시간이 더 유익하다고 주장합니다.

코드 검토의 경우, 저자는 생성 속도를 (출력 토큰 - 1) / (응답 시간 - 첫 번째 토큰 시간)으로 추정했으며, 두 시간 모두 초 단위로 스트림 오버헤드를 포함합니다.

시스템	양자화 및 런타임	생성 (tokens/s)
ProArt P16, Linux	FP4-Local, vLLM B12X	30.9 (3회 중앙값)
Frandroid의 ProArt P16, Windows	UD-IQ4_XS, llama.cpp	29.4 및 31.4

두 ProArt 설정 모두 약 30 tokens/s를 기록합니다. Frandroid는 85 GiB 전용 예약과 262,144 토큰의 컨텍스트 제한을 사용했고, 저자의 컨텍스트 제한은 32,768 토큰이었습니다. 프롬프트, 양자화, 런타임, 타이밍 방법이 다르므로 저자는 이를 OS 효과의 분리가 아닌 두 가지 작동 구성의 비교로 명시하고 있습니다.

배치 처리 및 지속적인 부하

4개의 코드 검토를 한 번에 보냈을 때 4개 요청을 합쳐 5.314초의 중앙값 배치 시간과 86.6 output tokens/s를 기록했으며, 이 속도에는 프롬프트 처리 및 응답 오버헤드가 포함됩니다. 12개의 답변 모두 3번의 배치에 걸쳐 통과했습니다.

그 후 저자는 기기를 10분 동안 한 번에 하나의 요청씩 세 가지 작업을 순환하도록 했습니다. 총 150개의 요청(각 50개)을 완료했으며 모든 답변이 확인을 통과했습니다. 중앙값 응답 시간은 코드 검토 4.036초, 로그 5.921초, 추출 2.046초였습니다. 각 작업의 처음 10회와 마지막 10회 반복을 비교했을 때, 중앙값 응답 시간은 1.6% 미만으로 증가했습니다. 총 171개의 측정된 응답 모두 확인을 통과했으며, 저자는 모든 답변과 원시 이벤트 스트림을 보관하고 요약본과 대조했습니다.

토론에서의 반론

댓글 작성자들은 게시물의 구성에 대해 몇 가지 반론을 제기했으며, 대부분은 포팅 자체보다는 비용과 사용 사례에 관한 것이었습니다.

이 가격에 노트북이 적절한 폼팩터인가?

가장 강력한 반대는 동일한 실리콘을 더 저렴하거나 편리한 형태로 구할 수 있다는 것이었습니다. 한 댓글 작성자는 다음과 같이 적었습니다:

"6,000달러짜리 노트북에 대한 강력한 사용 사례가 있는지 잘 모르겠습니다. 비슷한 금액으로 96, 128, 192GB 메모리를 탑재한 AMD Ryzen 495 또는 395 기반 미니 PC를 구입하여 더 저렴하고 작고 배터리 효율이 좋은 노트북에서 원격으로 연결할 수 있기 때문입니다."

같은 작성자는 Microsoft가 동일한 칩을 노트북이 아닌 폼팩터로 출시한다는 점을 지적하고, "비행 중 코딩" 시나리오는 이코노미석의 전원 플러그를 차단하는 전원 어댑터와 로컬 AI 부하 시 짧은 배터리 수명으로 인해 약화된다고 주장하며, 기내 연결성이 향상되면 완전 오프라인 사용 사례가 줄어들 것이라고 제안했습니다. 게임의 경우 Asus Zephyrus와 같은 전용 GPU 탑재 노트북을 언급했습니다.

다른 댓글 작성자는 128GB 기기의 HP 버전을 3,800달러에 구입했다고 보고하며, 그 정도 RAM에 가장 좋은 거래였다고 평가했습니다.

DGX Spark 및 사전 설치된 Linux 대안

Ubuntu를 실행하는 DGX Spark 소유자는 전제를 직접적으로 의심했습니다:

"왜 DGX Spark 대신 그걸 사야 하죠? 대부분의 개발자에게 OS는 큰 차이를 만들며, DGX Spark 스택과 경험은 성숙합니다."

관련 댓글에서는 이미 여러 OEM이 NVIDIA의 Linux 배포판(NVIDIA DGX OS)을 탑재한 RTX Spark 미니 PC를 출시하고 지원하고 있으며, 여기에는 Asus도 포함된다고 주장했습니다. 또한 반복되는 메시지는 "사전 설치된 Linux 기기를 판매하는 것은 가치가 없다"는 것이라고 지적했습니다.

Microsoft 계정은 정말 피할 수 있었나?

여러 댓글 작성자는 로그인 문제에 우회 방법이 있다고 주장했습니다. 한 작성자는 Windows Pro에서는 '회사 또는 학교 계정 → 도메인 가입'을 사용한 다음 비밀번호와 복구 질문을 설정할 수 있지만, Home 에디션은 대안이 점점 줄어드는 계정이 필요하다고 언급했습니다. 다른 작성자는 완전히 스크립트화된 경로를 설명했습니다:

"파일과 최신 11 Pro 다운로드 사본이 담긴 USB 키가 있고, 새 기기를 설정할 때 새로 설치를 실행합니다. 부팅 후 개발자 구성을 실행하죠... Microsoft 로그인도 없고, Candy Crush도 없고, WSL과 필요한 모든 도구가 설치됩니다."

해당 작성자는 autounattend.xml 생성기와 Microsoft의 WindowsDeveloperConfig 저장소를 가리켰습니다. 다른 사람들은 Microsoft 계정을 만드는 것이 무료이며 더 빨랐을 것이라는 더 직설적인 의견을 냈고, 한 명은 Microsoft의 로그인 흐름 자체가 깨진 리다이렉트, 루핑 버튼, CAPTCHA 등을 인용하며 고통스럽다고 지적했습니다.

성능 회의론 및 답변되지 않은 질문

한 댓글 작성자는 추론 수치에 의문을 제기했습니다: "Qwen 3.8 Flash Next에서 겨우 30 tok/s라고요? 요즘은 특수 엔진 덕분에 RAM 오프로드를 사용하는 24GB 비디오 카드에서도 그 속도의 약 2배를 얻을 수 있습니다. 열 제한 때문이겠죠..." 또한 이 기기가 밀집 모델에서 어떻게 작동하는지 물었지만, 게시물은 이에 답하지 않았습니다.

다른 댓글 작성자는 성과의 구성을 문제 삼으며, 실제로 극복한 과제가 무엇인지, 흥미로운 부분이 arm64 작업인지 아니면 단순히 새로운 하드웨어 리뷰인지 물었습니다. 세 번째 작성자는 GPU 접근 가능 메모리가 100 GiB가 넘는 노트북은 Apple Silicon의 M3 이후 약 3년 전부터 존재했다고 지적하며, 게시물에서 Apple Silicon에 대한 언급이 전혀 없다는 점을 지적했습니다. 별도의 댓글 작성자는 이 하드웨어에서 Wayland가 어떻게 작동하는지 물었지만, 제공된 토론에는 답변이 없습니다.

벤치마크에 대한 주의 사항

게시물의 성능 주장은 제어된 실험이 아닌 두 노트북 구성 간의 비교입니다. Windows 7-Zip 수치는 StorageReview의 HP OmniBook Ultra 16 및 ComputerBase의 64GB ProArt P16과 같은 타사 리뷰에서 가져온 것이며, 두 리뷰 모두 관련 매개변수를 모두 명시하지 않았습니다. HP 리뷰는 7-Zip 버전이나 사전 크기를 명시하지 않았고, ComputerBase는 7-Zip 26.00을 실행했지만 차트에서 사전 크기를 생략했습니다. Qwen 비교는 Linux와 Windows 실행 간에 양자화, 런타임, 컨텍스트 제한, 프롬프트 및 타이밍 방법이 다릅니다. 저자는 결과를 OS 대 OS 벤치마크로 제시하는 대신 이러한 제한 사항을 직접 명시하고 있습니다.