100GiB가 넘는 메모리를 GPU가 직접 쓸 수 있는 노트북이 소문으로 돌기 시작하자, 한 개발자는 로컬에서 강화학습과 양자화, 파인튜닝을 마음껏 돌려볼 생각에 들떴다. 문제는 하드웨어의 공식 지원이 윈도우 전용이었다는 점이다. 셋업 과정의 개인정보 양보, 광고, 작업표시줄 위치조차 오래 막아둔 정책 같은 이유로 윈도우를 피하고 싶었던 그는, 자신이 패키지 메인테이너로 참여 중인 Arch 리눅스를 대상 기기에 직접 올리기로 했다. 대상은 128GB RAM, 6,144개 CUDA 코어, 2TB SSD를 갖춘 ASUS ProArt P16(H7607BA-SE033W)이다.
드라이버와 부팅 환경을 직접 맞추다
이 빌드는 ARM용 패키지를 포팅하는 별도 프로젝트인 Arch Linux ARM 위에 하드웨어 지원을 얹는 방식이다. 출발점은 NVIDIA가 우분투용으로 진행한 커널 작업이었다. 여기에 콘솔을 띄우기 위한 ACPI 오버라이드 할당과 프레임버퍼 매핑을 고치고, 노트북 자체 테이블에서 ACPI 오버라이드를 추출했다. NVIDIA 드라이버와 ASUS 스피커 펌웨어는 공식 배포처에서 가져왔고, 키보드는 패치한 hid-asus가, 오디오는 전용 머신 드라이버가 필요했다. 이 모든 것을 부팅 가능한 USB로 묶고 Archinstall 4.5를 확장해 하드웨어 지원까지 설치하도록 만들었다. 빌드 입력은 해시로 고정했고, 주말 동안 만든 하드웨어 패키지는 본인의 Arch 패키지 메인테이너 키로 서명했다.
설치 결과물은 3840×2400 120Hz 디스플레이에서 NetworkManager, PipeWire, 그리고 NVIDIA CDI를 쓰는 루트리스 Podman로 구동된다. 커널과 NVIDIA, 전원 관리, 펌웨어 패키지는 IgnorePkg로 묶어 고정하되 일반 패키지는 Arch Linux ARM에서 계속 업데이트되도록 분리했다. 재현성과 유지보수를 동시에 고려한 구성이다.
윈도우와의 성능 비교
성능 검증은 10월 19일, 커널 7.0.0-1022-nvidia와 NVIDIA 드라이버 615.78.08 환경에서 전원 연결·성능 프로파일로 진행됐다. CPU 쪽은 32MiB 고정 딕셔너리로 네이티브 ARM64 7-Zip 26.04를 돌려 측정했다. StorageReview가 같은 20코어 N1X를 쓴 HP OmniBook Ultra 16(윈도우 ARM64)을 측정한 수치와 비교하면 싱글스레드는 사실상 동률이고, 20스레드에서는 리눅스 쪽이 압축 약 5%, 해제 약 3% 앞섰다. 다만 HP 리뷰는 7-Zip 버전과 딕셔너리 크기를 밝히지 않아, 이 수치는 두 노트북 '구성'의 비교로 봐야 한다. ComputerBase가 측정한 ProArt P16의 윈도우 점수 155.774 GIPS는 세 차례 측정의 중앙값 157.084, 범위 155.759~157.193 안에 들어온다. 이쪽은 64GB 구성에 7-Zip 26.00이었다. 즉 OS 자체의 효과를 분리한 비교라기보다 서로 다른 설정을 맞세운 결과다.
더 흥미로운 지점은 메모리다. 리눅스는 동일한 물리 풀에서 116.0GiB를 시스템 RAM으로도, CUDA의 총량으로도 보고했다. 반면 윈도우는 전용 GPU·공유·CPU 전용 영역으로 메모리를 나눠, CPU 작업은 전용 GPU 영역을 못 쓰고 GPU 할당은 CPU 전용 영역을 못 쓴다. 윈도우에서는 NVIDIA 앱으로 전용 예약량을 바꾸고 재부팅해야 하며, Frandroid의 128GB ProArt는 96GiB까지 올라갔다. 91GiB 예약 시 공유 메모리 포함 CUDA 총량은 109.7GiB였는데, 리눅스 쪽은 그보다 약 6.3GiB 많았다. 핵심은 절대 수치보다, 슬라이더를 옮기고 재부팅하는 번거로움 없이 큰 풀을 CPU 작업에도 그대로 쓸 수 있다는 점이다.
로컬 추론은 실제로 쓸 만한가
실사용 검증으로는 NVIDIA의 Qwen3.8-Flash-Next-FP4-Local 체크포인트를 vLLM(B12X CUDA 커널, 네이티브 ARM64 컨테이너)에서 혼합 양자화와 FP8 KV 캐시로 돌렸다. 사고(thinking) 기능은 껐다. 모델 로딩 전 가용 RAM은 110.9GiB였고, 모델 로딩에 68.2GiB, KV 캐시에 21.1GiB가 추가로 할당돼 노트북에서 90GiB 가까이를 모델에 쓴 셈이다. 로딩과 컴파일에 약 16분이 걸렸고, 이후 측정은 워밍업 뒤부터 집계했다. PLE 임베딩 테이블은 디스크 기반으로 페이지 캐시 덕을 보고, 일부 구성요소는 CPU 오프로드로 처리되며 추론 자체는 CUDA가 담당한다.
과제는 버그가 있는 파이썬 헬퍼 리뷰, 실패 작업 하나가 섞인 긴 장애 로그 분석, 결제 메모를 JSON으로 변환하는 세 가지였고 정답이 정해져 있었다. 약 1만 토큰을 읽는 로그 과제는 6초 안에 올바른 요청·원인·다음 조치를 39토큰으로 돌려줬는데, 전체 기준 6.8토큰/s이지만 대기 시간 대부분이 프롬프트 처리였다는 점에서 토큰 속도보다 응답 시간이 더 의미 있다. 코드 리뷰 생성 속도는 두 ProArt 모두 약 30토큰/s 수준이었다(Frandroid는 윈도우·85GiB 예약·26만 토큰 컨텍스트, 이쪽은 3만2768). 네 건을 동시에 보낸 배치는 중앙값 5.314초에 합산 86.6토큰/s를 냈다.
안정성 면에서는, 세 과제를 10분간 한 건씩 순환시켜 150건을 처리했고 모두 정답 검사를 통과했다. 코드 리뷰·로그·추출의 응답 시간 중앙값은 각각 4.036초, 5.921초, 2.046초였으며 초반 10회와 후반 10회를 비교했을 때 증가폭은 1.6% 미만이었다. 측정된 171개 응답이 전부 통과했다는 결과는 결정론적 디코딩 환경에서 반복된 것이라는 한계를 감안해 읽어야 하지만, 공식 지원 없는 OS 위에서도 대형 로컬 모델을 일상적으로 돌릴 수 있다는 사실을 보여준다. 하드웨어 벤더의 지원 범위가 곧 활용 범위의 상한은 아니라는 점, 그리고 통합 메모리 풀의 유연성이 로컬 AI 작업에서 실질적 이점이 된다는 점이 이 실험이 실무자에게 남기는 메시지다.