▲

macOS VM은 얼마나 빠르고, 얼마나 작아질 수 있을까?

 (eclecticlight.co)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Mac mini M4 Pro에서 macOS 26.4.1 VM을 다시 측정한 결과, 5개 가상 코어와 16GB vRAM 구성에서도 CPU 단일 코어와 GPU 성능이 호스트에 근접함
  • Geekbench 6.7.1 기준 단일 코어 CPU는 VM 3,855 / 호스트 3,948, GPU Metal은 VM 106,896 / 호스트 111,970으로 각각 호스트의 약 98%, 95% 수준을 보임
  • 멀티 코어 CPU는 VM 13,222 / 호스트 23,342였으며, 호스트가 14코어(10 P + 4 E)이고 VM은 5개 가상 코어라 직접 비교는 어렵지만 VM 성능은 꽤 양호함
  • 가장 약한 부분은 가상 Neural Engine으로, CoreML 반정밀도와 양자화 테스트에서 호스트보다 크게 느렸고 VM에서는 AI 작업이 CPU와 GPU로 처리되기를 기대할 수 있음
  • 최소 구성 테스트에서 2개 가상 코어와 4GB 메모리만으로도 Safari와 설정의 저장 공간 분석 같은 가벼운 작업을 정상 처리했으며, macOS 업데이트를 고려하면 VM 저장 공간은 최소 60GB가 적절함

테스트 배경

  • Apple silicon에서의 macOS 가상화 검토에 쓰인 성능 수치는 이전 측정값이었고, 사용할 만한 VM의 최소 사양은 다루지 않았음
  • MacBook Neo에서 VM을 실행하는 데 관심이 커진 상황에서, macOS Tahoe 기준 성능과 최소 구성을 다시 확인함

성능 측정과 해석

  • 테스트 호스트는 Mac mini M4 Pro이며, macOS 26.4.1, 14코어(10 P + 4 E), 48GB RAM, 2TB 내장 SSD 구성임
  • 게스트 VM에는 5개 가상 코어와 16GB 가상 RAM을 할당함
  • Geekbench 6.7.1 점수는 호스트와 VM 모두 이전보다 약간 빨라짐
  • 측정 결과는 다음과 같음
    • 단일 코어 CPU: VM 3,855, 호스트 3,948
    • 멀티 코어 CPU: VM 13,222, 호스트 23,342
    • GPU Metal: VM 106,896, 호스트 111,970
    • Neural Engine CoreML: VM 5,291 / 8,577 / 6,877, 호스트 5,973 / 41,251 / 56,616
  • Neural Engine CoreML의 세 수치는 순서대로 단정밀도, 반정밀도, 양자화 테스트 결과임
  • 멀티 코어 CPU 결과는 호스트가 VM보다 두 배 넘는 코어 수를 갖고 있고 그중 4개가 E 코어라 직접 비교가 어려움
  • GPU 성능 비교는 호스트가 GPU를 함께 경쟁적으로 쓰지 않는 조건에서의 결과임
  • VM에서 실행할 때 macOS가 AI 작업을 Neural Engine 대신 CPU와 GPU로 처리하기를 기대할 수 있음

최소 구성 테스트

  • MacBook Neo 등장 이후 해당 기기에서 VM을 실행할 수 있을지에 대한 관심이 있었음
  • Linux 호스트 용도로는 괜찮을 것으로 보였지만, macOS VM으로 유용한 작업이 가능할지는 의심됐으나 실제 테스트에서는 가능했음
  • 최소 구성을 확인하기 위해 같은 macOS 26.4.1 VM을 Viable에서 점차 더 작은 CPU 코어와 메모리 할당으로 실행함
  • VM 표시 창은 표준 1600 × 1000으로 설정함
  • Safari를 여러 방식으로 사용하고, 설정의 저장 공간 분석을 포함한 가벼운 일상 작업을 수행함
  • 구성별 결과는 다음과 같음
    • 4개 가상 코어와 8GB vRAM에서는 VM이 완전히 경쾌하게 동작했고, 메모리는 약 5GB 사용됨
    • 3개 코어와 6GB에서는 메모리 사용량이 3.9GB로 줄었고 모든 작업이 잘 동작함
    • 2개 코어와 4GB 메모리에서는 3.1GB만 사용됐으며, 가벼운 작업을 계속 정상적으로 처리함
  • 2개 가상 코어와 4GB 메모리만 할당한 macOS VM도 MacBook Neo에서 가능할 것으로 보이며, 일상 작업을 충분히 수행할 수 있음
  • 이런 VM은 LLM을 실행해볼 장소는 아니지만, 가벼운 macOS 작업에는 충분히 사용할 만함

저장 공간과 업데이트 제약

  • 내장 SSD가 작은 Mac에서 VM을 만들 때는 VM 크기를 주의해야 함
  • 50GB보다 훨씬 작은 macOS VM은 macOS 업데이트를 수행할 수 없게 됨
  • 여유와 안전성을 위해 최소 60GB를 목표로 잡는 것이 좋음
  • APFS에서는 VM이 희소 파일로 저장되므로, 기본 100GB VM도 실제 디스크에서는 약 54GB만 필요함
  • 이런 구성은 512GB SSD를 갖춘 MacBook Neo에서 더 적절하게 수용될 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 코어마다 묶이는 메모리가 어느 정도 있다는 좋은 reminder임. 아마 주로 페이지 캐시나 동시성 처리 같은 쪽일 가능성이 큼

    • 귀무가설 쪽에 걸겠음. 코어 수를 고정하고 VM 메모리 크기만 조정해도 같은 메모리 사용량 변화가 나타났을 것 같음
    • 일반적으로 컴퓨터에 장착한 물리 메모리 용량도 CPU가 제공하는 하드웨어 스레드 수에 비례해야 함
      운영체제가 스레드마다 일부 메모리를 할당할 수 있을 뿐 아니라, 큰 소프트웨어 프로젝트 컴파일처럼 모든 스레드를 쓰는 멀티스레드 앱은 작업 스레드 수에 비례해 작업 메모리를 잡는 경우가 많음
      스레드당 최대 2GB 정도가 있어야 잘 도는 멀티스레드 앱도 많이 봤고, Ryzen 9 9950X처럼 32스레드 데스크톱 CPU라면 64GB가 맞아떨어짐
      Chrome/Chromium 계열 같은 프로젝트를 컴파일할 때 16코어/32스레드 CPU에 32GB만 있으면, make -j 같은 적절한 파라미터로 동시 컴파일 수를 줄여 일부 코어를 놀려야 함. 아니면 메모리 부족 오류를 만날 수 있음
    • 코어당 오버헤드가 있는 건 맞지만, 이 사용량 감소는 사용 가능한 메모리가 줄어들면서 커널의 메모리 할당 방식이 바뀐 영향일 가능성이 더 커 보임
      메모리가 많으면 커널은 읽기 캐시를 더 오래 유지하고, 디스크 스왑보다 메모리 압축을 선호하며, 회수 가능한 메모리 정리를 덜 자주 함. 내부 버퍼 크기와 vnode 테이블도 총 메모리에 따라 조정됨
      사용 가능한 자원을 동적으로 최대한 활용한다는 점에서는 좋은데, 실제 동작에 필요한 최소 기준선을 보기 어렵게 만드는 대가가 있음
      확인해보면 재미있는 명령은 vm_stat이고, free/active/inactive/wired/purgeable 페이지, compressor, pagein/pageout, swapin/swapout 같은 값을 볼 수 있음. 편집: 코드 펜스 Markdown 지원이 안 되는 건지, 내가 뭔가 잘못한 건지 모르겠음

  • 최근 M5 Air를 샀고 macOS는 처음이라 이 부분을 파악하는 중인데, pytorch, GPU 가속, VM/컨테이너 수준 격리를 동시에 얻는 건 사실상 불가능해 보임
    virtio-gpu 계층이 가장 가까워 보이지만, 계산용 GPU가 아니라 그래픽 GPU만 넘겨주는 듯해서 pytorch는 안 됨

    • 나도 이게 필요해서 1년 전 꽤 많이 찾아봤음. 최근의 Docker Model Runner(vllm-metal)나 podman libkrun 쪽 변화는 아직 확인할 시간이 없었는데, 둘 다 안 됐나?
    • Cirruslabs Tart 인스턴스에서 torch를 실행하는 데 성공했음

  • macOS에서 VM을 써본 건 colima+docker뿐인데, 비교적 고통스럽고 비효율적임. 그래도 쓸 수는 있음

    • Apple의 container CLI를 써보면 좋음. 몇 주 전 주말 동안 내 프로젝트 하나를 colima+docker에서 꽤 쉽게 옮겼음
      https://github.com/apple/container
    • 로컬 CI 용도로 Mac Mini를 샀고 Forgejo Actions와 함께 쓰려고 생태계를 넓게 훑어봤지만, 결국 호스트에서 빌드하는 쪽으로 갔음
      서명과 공증 설정을 호스트로부터 격리하는 일은 에이전트를 써도 감당하기 어려워 보였음. 그래도 이제 macOS 빌드는 정말 빠르고, 서명/공증도 Bash 약 200줄이면 됨
    • OrbStack은 꽤 좋음. 딱히 비효율적이라고 느끼지 않음

  • https://github.com/trycua/cua/tree/main/libs/lume가 이 문제에 대해 흥미로운 접근을 보여줬음

  • VM 시작 시 5GB만 쓴다고 해도, VM 안에서 앱을 실행하면 시작 때 쓰는 5GB가 아니라 할당한 8GB 전체를 원하게 되는 것 아닌가?

    • macOS 가상화가 메모리 벌루닝을 지원할 만큼 고급이라고 생각하지 않았는데, 그 얘기가 아닌가?
      편집: 내가 틀렸음

  • 내가 가장 작은 걸 갖고 있는 것 같음. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB이고, Darwin 크로스 빌드에 쓰고 있음

  • 솔직히 macOS는 VM에 꼭 필요하지 않은 것들을 끄면 그보다 훨씬 낮게도 내려갈 수 있을 것 같음
    첫 iPhone은 RAM이 128MiB뿐이었고, 잘라낸 macOS Tiger 버전을 돌렸던 것으로 알고 있음. 지금까지는 RAM이 꽤 넉넉해서 줄일 이유가 없었을 뿐, 분명 가능하고 아마 그렇게 어렵지도 않을 것임. 다시 시도하기만 하면 됨

    • 초기 iPhone에는 앱 멀티태스킹이 없었으니 차이가 꽤 큼. 앱은 닫히면 종료됐음

  • PC에서 macOS를 실행할 수 있나? 아니면 최소한 PC에서 Mac용 개발을 어떤 식으로든 할 수 있나?

    • QEMU로 macOS 부팅은 가능하지만, 하드웨어 가속 그래픽이나 몇몇 기능은 쓸 수 없음

  • 좀 뜬금없는 질문이지만, macOS VM을 개인 기기로 Intune 등록하는 게 가능할까?

  • 왜 아무도 macOS 전용 에이전트 환경을 만들지 않는지 궁금함. 에이전트가 Mac 환경에서 spawn되는 식이면 좋을 텐데

답변달기