M4 맥북 에어에 RTX 5090을 물렸더니 게임도 AI도 돌아감

맥북 에어에 RTX 5090을 붙인다는 말도 안 되는 실험

• 작성자의 목표는 단순함. M4 맥북 에어에 데스크톱용 엔비디아 RTX 5090을 붙여서 게임과 AI 추론이 되는지 확인하는 것

  • 연결은 썬더볼트 eGPU 독을 사용함
  • 썬더볼트는 USB-C 케이블 위로 PCIe를 터널링해서, 컴퓨터 입장에서는 외부 장치가 느린 PCIe 장치처럼 보임
  • 썬더볼트 4 기준 PCIe 4레인, 최대 40Gbps라 네이티브 PCIe보다 손해는 있음

• 첫 번째 문제는 macOS가 애플 실리콘에서 엔비디아·AMD GPU 드라이버를 제공하지 않는다는 점임

  • tinygrad가 macOS eGPU 드라이버를 만들긴 했지만, tinygrad 스택 안에서만 쓸 수 있고 게임이나 일반 AI 추론용 해법은 아님
  • 리눅스는 엔비디아 GPU를 지원하지만, 애플 실리콘 리눅스 커널은 아직 썬더볼트를 지원하지 않음
  • 그래서 macOS 호스트 위에 ARM 리눅스 VM을 띄우고, GPU를 그 VM 안으로 패스스루하는 구성이 나옴

sequenceDiagram
    participant 맥OS as 맥OS 호스트
    participant 큐이엠유 as QEMU
    participant 리눅스 as ARM 리눅스 VM
    participant 드라이버 as 게스트 커널 드라이버
    participant GPU as RTX 5090
    맥OS->>큐이엠유: 썬더볼트 GPU 장치 노출
    큐이엠유->>리눅스: PCI 장치로 패스스루
    리눅스->>드라이버: 엔비디아 DMA 매핑 요청
    드라이버->>큐이엠유: apple-dma-pci로 매핑 요청 전달
    큐이엠유->>맥OS: DART 매핑 생성 요청
    맥OS-->>GPU: 안전한 DMA 주소 제공
    GPU-->>리눅스: CUDA·그래픽 워크로드 실행

패스스루 구현이 진짜 본편임

• PCI 장치를 VM에 넘기려면 두 가지가 중요함

  • PCI BAR(Base Address Register)는 장치와 통신하는 메모리 영역이고, 게스트가 이 영역을 읽고 쓸 수 있어야 함
  • DMA(Direct Memory Access)는 GPU가 CPU를 거치지 않고 메모리를 직접 읽고 쓰는 방식이라, 고성능 GPU 작업에서는 필수임

• BAR 매핑부터 함정이 있었음

  • QEMU가 장치 메모리를 게스트에 직접 매핑하자 호스트 커널이 패닉을 일으킴
  • 작은 재현 코드는 멀쩡했는데, 차이는 QEMU가 HV_MEMORY_EXEC 플래그까지 붙였다는 점이었음
  • 실행 권한 플래그를 빼니 동작했고, 트랩 방식보다 약 30배 빨라졌지만 정상적인 BAR 쓰기보다는 약 10배 느렸다고 함

• DMA는 더 빡셌음

  • 애플 실리콘에는 IOMMU 비슷한 DART가 있지만, PCIDriverKit 경유 썬더볼트 장치에는 제약이 큼
  • 매핑 가능한 메모리가 약 1.5GB로 제한되고, 매핑 개수도 약 6만4천 개에서 막힘
  • 주소나 정렬도 직접 제어할 수 없어서 일반적인 가상 IOMMU 방식이 어려웠음

• 작성자는 QEMU에 apple-dma-pci라는 가상 PCI 장치를 새로 만들었음

  • 게스트 리눅스 안의 커널 드라이버가 엔비디아 드라이버의 DMA 매핑 호출을 가로챔
  • 요청을 가상 BAR로 전달하면 QEMU가 macOS 쪽 PCIDriverKit 드라이버에 DART 매핑을 요청함
  • 이렇게 전체 VM 메모리를 미리 매핑하지 않고, 실제 살아 있는 DMA 버퍼만 그때그때 매핑함

• 엔비디아 드라이버의 정렬 조건도 걸림돌이었음

  • 특정 CUDA 워크로드에서 16MB 시스템 메모리 할당이 2MB huge page 정렬을 기대하다가 NV_ERR_INVALID_OFFSET 오류로 실패함
  • 드라이버를 직접 패치하면 되지만, 버전이 바뀔 때마다 다시 패치해야 함
  • 작성자는 리눅스 kprobes로 nvUvmInterfaceMemoryAllocSys() 호출 인자를 바꿔 작은 페이지 크기를 쓰게 만드는 우회책을 넣음

• 매핑 개수 제한은 클러스터링으로 줄였음

  • 로그를 보니 매핑의 90% 이상이 4KB였고, 서로 완전히 연속되진 않아도 군집처럼 나타남
  • 게스트 메모리를 256KB 같은 고정 크기 클러스터로 나누고, 4KB 버퍼 하나가 들어오면 해당 클러스터 전체를 매핑함
  • 이 방식으로 라이브 매핑 수가 약 4배 줄어들어 고사양 게임 설정도 돌릴 여유가 생김

게임 성능은 됨. 근데 공짜는 아님

• 사이버펑크 2077 테스트는 여섯 구성으로 비교함

  • M4 에어 네이티브 macOS, M4 에어 eGPU 리눅스 VM, 2020 인텔 맥북 프로 eGPU, M5 맥스 네이티브 macOS, M5 맥스 eGPU 리눅스 VM, 그리고 i5-12600K 게이밍 PC 네이티브 PCIe 구성
  • eGPU·PC 구성은 DLSS 4배 프레임 생성, macOS 네이티브 구성은 FSR 2배 프레임 생성을 사용함

• 720p 낮음 설정에서는 eGPU가 오히려 손해였음

  • M5 맥스 네이티브 macOS가 200fps로 가장 빨랐고, 게이밍 PC는 180fps였음
  • M4 에어 네이티브는 61fps인데, M4 에어 eGPU는 49fps로 더 낮았음
  • GPU가 놀고 CPU·가상화·에뮬레이션 비용이 지배하는 구간이라 그럼

• 4K로 가면 얘기가 달라짐

  • 게이밍 PC는 4K 레이트레이싱 울트라에서 100fps, DLSS 프레임 생성으로 282fps를 냄
  • M5 맥스 네이티브는 25fps, FSR 프레임 생성으로 42fps라 간신히 플레이 가능 수준
  • M5 맥스 eGPU는 47fps, 프레임 생성으로 145fps까지 올라감
  • M4 에어 eGPU는 27fps, 프레임 생성으로 111fps가 나와서 ‘불가능’에서 ‘가능’으로 바뀜

• 그래도 같은 RTX 5090을 꽂은 PC가 훨씬 빠름

  • 게임에 따라 PC가 M5 맥스 eGPU보다 대략 2배 빠르고, M4 에어 eGPU보다는 더 벌어짐
  • 이유는 썬더볼트, VM, FEX-Emu, Proton, BAR 접근 지연이 전부 누적되기 때문임
  • Horizon Zero Dawn Remastered는 1.5GB DART 매핑 한도를 넘어서 벤치마크 시작조차 못 했음

AI 추론은 오히려 더 실용적인 결과가 나옴

• Qwen 3.6 35B 혼합 전문가(MoE) 모델을 4비트 양자화로 테스트함

  • 엔비디아 쪽은 vLLM과 NVFP4, 애플 실리콘 쪽은 MLX 4비트 양자화와 vllm-mlx를 사용함
  • 완전히 같은 백엔드는 아니지만, 각 플랫폼에서 가능한 빠른 구성을 고른 셈임

• 토큰 생성 속도는 RTX 5090이 확실히 앞섬

  • RTX 5090은 M4 에어보다 6.5배, M4 맥스 맥 스튜디오보다 2.1배, M5 맥스 맥북 프로보다 1.2배 빨랐음
  • 썬더볼트 eGPU는 네이티브 PCIe 대비 약 9% 성능 손실로 비교적 잘 버팀
  • 프롬프트 길이는 생성 속도에 큰 영향을 주지 않았고, 주로 모델 가중치를 GPU 메모리에서 스트리밍하는 대역폭 문제가 됨

• 진짜 차이는 프리필(prefill)에서 터짐

  • 4K 토큰 프롬프트를 처리할 때 M4 맥북 에어는 생성 시작 전 약 17초가 걸림
  • 같은 상황에서 eGPU는 약 150ms로 끝남
  • 작성자는 이 차이를 약 120배로 봤고, 긴 컨텍스트를 한 번에 넣는 로컬 LLM 작업에서는 체감이 엄청날 수밖에 없음

• 동시 처리에서도 RTX 5090이 유리함

  • 1개 요청에서 4개 동시 요청으로 늘리면 5090 구성은 처리량이 약 3배까지 증가함
  • M4 맥스는 약 2배, M5 맥스는 약 1.7배 수준에 그침
  • 애플 실리콘 MLX 구성은 저전력 단일 사용자 추론에 강하고, 5090은 배치 처리와 서빙 쪽에 강한 그림임

• Gemma 4 31B에서는 격차가 더 뚜렷함

  • Gemma 4는 조밀(dense) 모델이라 Qwen처럼 일부 전문가만 활성화하지 않고 310억 파라미터 전체를 매번 통과함
  • RTX 5090 기반 vLLM 구성들은 약 50토큰/초 수준으로 서로 비슷했음
  • M4 맥스는 약 22토큰/초, M5 맥스는 약 27토큰/초까지 떨어짐
  • 4K 토큰 프리필은 M4 맥스가 최대 21초, M5 맥스가 약 7.5초였고, RTX 5090은 항상 400ms 미만이었음

결론은 “가능하지만 추천은 아님”

• 설치도 아직 일반 사용자용이 아님

  • 애플의 특수 권한(entitlement)이 필요하고, 작성자는 요청했지만 몇 달이 걸릴 수 있다고 들었다고 함
  • 직접 빌드하면 SIP 비활성화나 보안 낮춤 없이도 로드할 수 있지만, 코드 서명 계정에 대상 맥이 들어 있어야 함
  • 런처는 특수 드라이버가 설치된 우분투 이미지를 자동으로 내려받는 방식임

• 안정성도 아직 취미 프로젝트 수준임

  • FEX 버그 때문에 스팀이 반복 크래시할 수 있음
  • 어떤 게임은 시작하는 데 몇 분이 걸릴 수 있음
  • DMA 매핑이 시간이 지나며 조각나면 VM을 종료하고 GPU를 뺐다 꽂아야 할 수도 있음

• 작성자의 최종 평가는 꽤 냉정함

  • 게임은 돌아가지만 같은 GPU를 꽂은 일반 PC가 2~4배 빠름
  • 로컬 AI 추론은 훨씬 그럴듯하고, M4 에어의 Qwen 단일 스트림 생성이 약 22토큰/초에서 약 155토큰/초로 오른 게 대표적임
  • 애플 실리콘 리눅스가 썬더볼트를 직접 지원하면 VM 오버헤드, BAR 지연, DMA 제한 중 상당수가 사라질 수 있음
  • 지금은 ‘사야 할 구성’이 아니라 ‘어디까지 가능한가’에 대한 멋진 증명임

기술 맥락

• 이 글의 기술적 선택은 macOS에서 직접 GPU를 쓰는 대신 ARM 리눅스 VM에 RTX 5090을 넘기는 거예요. macOS가 애플 실리콘용 엔비디아 드라이버를 제공하지 않으니, CUDA와 엔비디아 리눅스 드라이버가 있는 환경을 VM 안에 만든 셈이에요.

• 어려운 부분은 GPU가 메모리를 직접 읽고 쓰는 DMA예요. 일반 PC의 IOMMU 패스스루처럼 전체 게스트 메모리를 안정적으로 매핑하면 편한데, 애플의 DART 경로에는 1.5GB와 약 6만4천 개 매핑 제한이 있어서 그대로는 최신 게임과 CUDA 워크로드가 못 버텨요.

• apple-dma-pci는 이 제한을 피하려는 중간 장치예요. 게스트 커널 드라이버가 엔비디아 드라이버의 DMA 요청을 가로채고, QEMU가 필요한 순간에만 macOS 쪽 DART 매핑을 만들어줘요. 전체 메모리를 다 열어두지 않으니 제한 안에서 버틸 수 있는 거죠.

• 게임 성능이 크게 깎이는 이유는 GPU만 빨라서는 부족하기 때문이에요. x86 게임은 FEX-Emu로 ARM에 맞게 번역되고, Windows API는 Proton으로 리눅스에 맞춰지고, GPU는 썬더볼트와 VM을 거쳐요. 병목이 GPU가 아니라 CPU와 변환 계층으로 넘어가는 순간 RTX 5090도 힘을 다 못 써요.

• AI 추론이 더 잘 나온 이유는 CUDA 워크로드가 상대적으로 GPU 안에서 오래 머물기 때문이에요. 특히 프리필은 계산량이 커서 RTX 5090의 병렬 연산 능력이 바로 드러나고, 썬더볼트 손실보다 GPU 자체 성능 이득이 훨씬 커져요.