1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการวัด macOS 26.4.1 VM ใหม่อีกครั้งบน Mac mini M4 Pro พบว่าแม้จะตั้งค่าเป็น 5 virtual cores และ 16GB vRAM ประสิทธิภาพ CPU แบบ single-core และ GPU ก็ยังใกล้เคียงกับโฮสต์
  • อ้างอิง Geekbench 6.7.1 ค่า single-core CPU อยู่ที่ VM 3,855 / โฮสต์ 3,948 และ GPU Metal อยู่ที่ VM 106,896 / โฮสต์ 111,970 หรือคิดเป็นราว 98% และ 95% ของโฮสต์ตามลำดับ
  • ส่วน CPU แบบ multi-core อยู่ที่ VM 13,222 / โฮสต์ 23,342 โดยโฮสต์มี 14 คอร์ (10 P + 4 E) ขณะที่ VM มี 5 virtual cores จึงเทียบตรง ๆ ได้ยาก แต่ประสิทธิภาพของ VM ก็ถือว่าดีพอสมควร
  • จุดที่อ่อนที่สุดคือ virtual Neural Engine ซึ่งช้ากว่าโฮสต์มากในการทดสอบ CoreML แบบ half-precision และ quantized และใน VM จึงพอคาดได้ว่างาน AI จะถูกประมวลผลด้วย CPU และ GPU
  • ในการทดสอบสเปกขั้นต่ำ พบว่าใช้เพียง 2 virtual cores และหน่วยความจำ 4GB ก็ยังจัดการงานเบา ๆ เช่น Safari และการวิเคราะห์พื้นที่จัดเก็บใน Settings ได้ตามปกติ และเมื่อคำนึงถึงการอัปเดต macOS แล้ว พื้นที่เก็บข้อมูลของ VM ควรมีอย่างน้อย 60GB

พื้นหลังการทดสอบ

  • ตัวเลขประสิทธิภาพที่ใช้ใน บทความทบทวนการทำ virtualization บน Apple silicon เป็นค่าที่วัดไว้ก่อนหน้านี้ และยังไม่ได้พูดถึงสเปกขั้นต่ำของ VM ที่ใช้งานได้จริง
  • เมื่อความสนใจในการรัน VM บน MacBook Neo เพิ่มขึ้น จึงมีการตรวจสอบประสิทธิภาพและสเปกขั้นต่ำอีกครั้งโดยอิงตาม macOS Tahoe

การวัดประสิทธิภาพและการตีความ

  • เครื่องโฮสต์ที่ใช้ทดสอบคือ Mac mini M4 Pro พร้อม macOS 26.4.1, ซีพียู 14 คอร์ (10 P + 4 E), RAM 48GB และ SSD ภายใน 2TB
  • สำหรับ guest VM ได้จัดสรร 5 virtual cores และ virtual RAM 16GB
  • คะแนน Geekbench 6.7.1 ของทั้งโฮสต์และ VM สูงขึ้นเล็กน้อยจากเดิม
  • ผลการวัดมีดังนี้
    • CPU single-core: VM 3,855, โฮสต์ 3,948
    • CPU multi-core: 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 เรียงตามลำดับคือผลการทดสอบ single precision, half precision และ quantized
  • ผล CPU multi-core เปรียบเทียบตรง ๆ ได้ยาก เพราะโฮสต์มีจำนวนคอร์มากกว่า VM เกินเท่าตัว และในนั้นมี 4 คอร์เป็น E cores
  • การเปรียบเทียบประสิทธิภาพ GPU เป็นผลที่ได้ภายใต้เงื่อนไขที่โฮสต์ไม่ได้ใช้งาน GPU แข่งขันร่วมกัน
  • เมื่อรันใน VM จึงคาดได้ว่า macOS จะประมวลผลงาน AI ด้วย CPU และ GPU แทน Neural Engine

การทดสอบสเปกขั้นต่ำ

  • หลังการมาของ MacBook Neo มีความสนใจว่าอุปกรณ์นี้จะรัน VM ได้หรือไม่
  • สำหรับการเป็นโฮสต์ของ Linux ดูเหมือนจะไม่มีปัญหา แต่เคยมีข้อสงสัยว่าจะใช้งาน macOS VM ให้เกิดประโยชน์ได้จริงหรือไม่ ซึ่งจากการทดสอบพบว่าทำได้
  • เพื่อตรวจสอบสเปกขั้นต่ำ จึงรัน macOS 26.4.1 VM เดิมบน Viable โดยค่อย ๆ ลดจำนวนคอร์ CPU และการจัดสรรหน่วยความจำลง
  • หน้าต่างแสดงผลของ VM ถูกตั้งไว้ที่มาตรฐาน 1600 × 1000
  • มีการใช้งาน Safari หลายรูปแบบ และทำงานเบา ๆ ในชีวิตประจำวัน รวมถึงการวิเคราะห์พื้นที่จัดเก็บใน Settings
  • ผลลัพธ์ของแต่ละสเปกมีดังนี้
    • ที่ 4 virtual cores และ 8GB vRAM ตัว VM ทำงานได้ลื่นเต็มที่ และใช้หน่วยความจำราว 5GB
    • ที่ 3 คอร์และ 6GB การใช้หน่วยความจำลดลงเหลือ 3.9GB และทุกงานยังทำงานได้ดี
    • ที่ 2 คอร์และหน่วยความจำ 4GB ใช้จริงเพียง 3.1GB และยังทำงานเบา ๆ ได้ตามปกติอย่างต่อเนื่อง
  • macOS VM ที่จัดสรรเพียง 2 virtual cores และหน่วยความจำ 4GB ก็น่าจะเป็นไปได้บน MacBook Neo และเพียงพอสำหรับงานทั่วไปในชีวิตประจำวัน
  • VM ลักษณะนี้ไม่ใช่ที่สำหรับลองรัน LLM แต่ก็ใช้งานงาน macOS เบา ๆ ได้ดีพอ

ข้อจำกัดด้านพื้นที่เก็บข้อมูลและการอัปเดต

  • เมื่อต้องสร้าง VM บน Mac ที่มี SSD ภายในขนาดเล็ก ควรระวังเรื่องขนาดของ VM
  • macOS VM ที่เล็กกว่า 50GB มาก จะไม่สามารถอัปเดต macOS ได้
  • เพื่อเผื่อพื้นที่และความปลอดภัย ควรตั้งเป้าขั้นต่ำที่ 60GB
  • บน APFS นั้น VM จะถูกเก็บเป็น sparse file ดังนั้นแม้ตั้งค่า VM เริ่มต้นไว้ที่ 100GB ก็ใช้พื้นที่ดิสก์จริงเพียงประมาณ 54GB
  • สเปกแบบนี้จึงน่าจะรองรับได้เหมาะสมกว่าบน MacBook Neo ที่มี SSD 512GB

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความเห็นจาก Hacker News
  • นี่เป็นเครื่องเตือนใจที่ดีว่ามีหน่วยความจำบางส่วนที่ผูกกับแต่ละคอร์อยู่พอสมควร น่าจะเป็นพวก page cache หรือการจัดการ concurrency เป็นหลัก

    • ผมขอวางเดิมพันกับสมมติฐานศูนย์ คิดว่าต่อให้ตรึงจำนวนคอร์ไว้แล้วปรับแค่ ขนาดหน่วยความจำของ VM ก็น่าจะเห็นการเปลี่ยนแปลงของการใช้หน่วยความจำแบบเดียวกัน
    • โดยทั่วไปแล้ว ปริมาณหน่วยความจำจริง ที่ติดตั้งในเครื่องก็ควรเป็นสัดส่วนกับจำนวน hardware threads ที่ CPU มีให้ด้วย
      ไม่ใช่แค่ระบบปฏิบัติการอาจจัดสรรหน่วยความจำบางส่วนต่อเธรดเท่านั้น แต่แอปแบบมัลติเธรดที่ใช้ทุกเธรด เช่นการคอมไพล์โปรเจ็กต์ซอฟต์แวร์ขนาดใหญ่ ก็มักจะกิน working memory ตามจำนวน worker threads ด้วย
      ผมเคยเห็นแอปมัลติเธรดหลายตัวที่ต้องมีอย่างมากราว 2GB ต่อเธรดถึงจะทำงานได้ดี และถ้าเป็นเดสก์ท็อป CPU 32 เธรดอย่าง Ryzen 9 9950X ก็ถือว่า 64GB ลงตัวพอดี
      เวลาคอมไพล์โปรเจ็กต์อย่าง Chrome/Chromium บน CPU 16 คอร์/32 เธรด ถ้ามีแค่ 32GB ก็ต้องลดจำนวนงานคอมไพล์พร้อมกันด้วยพารามิเตอร์ที่เหมาะสมอย่าง make -j เพื่อปล่อยบางคอร์ว่างไว้ ไม่อย่างนั้นอาจเจอ ข้อผิดพลาดหน่วยความจำไม่พอ ได้
    • ถึงจะมี overhead ต่อคอร์จริง แต่การใช้หน่วยความจำที่ลดลงนี้ดูน่าจะเกิดจาก วิธีจัดสรรหน่วยความจำของเคอร์เนล ที่เปลี่ยนไปเมื่อหน่วยความจำที่ใช้งานได้ลดลงมากกว่า
      ถ้ามีหน่วยความจำเยอะ เคอร์เนลจะเก็บ read cache ไว้นานขึ้น เลือกใช้ memory compression มากกว่าสลับข้อมูลลงดิสก์ และกวาดล้างหน่วยความจำที่ reclaim ได้ไม่ถี่นัก ขนาดของ internal buffers และ vnode table ก็จะปรับตามหน่วยความจำรวมด้วย
      มันเป็นเรื่องดีในแง่ที่ใช้ทรัพยากรที่มีให้คุ้มที่สุดแบบไดนามิก แต่ข้อเสียคือทำให้มอง baseline ขั้นต่ำที่ต้องใช้ในการทำงานจริงได้ยาก
      คำสั่งที่น่าลองดูคือ vm_stat ซึ่งจะเห็นค่าอย่าง free/active/inactive/wired/purgeable pages, compressor, pagein/pageout, swapin/swapout แก้ไข: ไม่แน่ใจว่า Markdown ไม่รองรับ code fence หรือว่าผมทำอะไรผิดเอง
  • เพิ่งซื้อ M5 Air มาไม่นาน และนี่เป็นครั้งแรกที่ใช้ macOS เลยกำลังหาคำตอบเรื่องนี้อยู่ แต่ดูเหมือนว่าการได้ทั้ง pytorch, การเร่งด้วย GPU และการแยกระดับ VM/คอนเทนเนอร์พร้อมกันนั้นแทบเป็นไปไม่ได้
    ชั้น virtio-gpu ดูใกล้เคียงที่สุด แต่เหมือนจะส่งผ่านได้แค่ GPU สำหรับกราฟิก ไม่ใช่ GPU สำหรับงานคำนวณ เลยใช้กับ pytorch ไม่ได้

    • ผมก็ต้องการแบบนี้เหมือนกัน เลยค้นอยู่พอสมควรเมื่อปีก่อน แต่ยังไม่มีเวลาตรวจดูความเปลี่ยนแปลงล่าสุดฝั่ง Docker Model Runner (vllm-metal) หรือ podman libkrun เลย ทั้งคู่ยังใช้ไม่ได้หรือ?
    • ผมรัน torch ได้สำเร็จบนอินสแตนซ์ Cirruslabs Tart
  • บน macOS ผมเคยใช้ VM แค่ colima+docker ซึ่งค่อนข้างทรมานและไม่มีประสิทธิภาพ แต่ก็ยังพอใช้งานได้

    • ลองใช้ container CLI ของ Apple ดูก็ดี ช่วงสุดสัปดาห์เมื่อไม่กี่สัปดาห์ก่อนผมย้ายโปรเจ็กต์หนึ่งของตัวเองจาก colima+docker มาได้ค่อนข้างง่าย
      https://github.com/apple/container
    • ผมซื้อ Mac Mini มาใช้เป็น local CI และกะจะใช้กับ Forgejo Actions เลยไล่ดู ecosystem ค่อนข้างกว้าง สุดท้ายก็ลงเอยด้วยการ build บนโฮสต์
      การแยกการตั้งค่า signing กับ notarization ออกจากโฮสต์ดูเป็นเรื่องที่รับมือยาก แม้จะใช้เอเจนต์ก็ตาม แต่ตอนนี้การ build บน macOS เร็วมากจริง ๆ และเรื่อง signing/notarization ก็ใช้ Bash แค่ราว 200 บรรทัด
    • OrbStack ค่อนข้างดีเลย ผมไม่ค่อยรู้สึกว่ามันไม่มีประสิทธิภาพอะไร
  • https://github.com/trycua/cua/tree/main/libs/lume แสดงแนวทางที่น่าสนใจต่อปัญหานี้

  • ต่อให้ตอนเริ่ม VM จะใช้แค่ 5GB แต่พอรันแอปใน VM แล้ว มันจะไม่ได้ต้องการแค่ 5GB ตอนเริ่มต้น แต่จะอยากได้ 8GB ที่จัดสรรไว้ทั้งหมด อยู่ดีไม่ใช่หรือ?

    • ผมไม่คิดว่า virtualization ของ macOS จะล้ำพอรองรับ memory ballooning นี่ไม่ใช่เรื่องนั้นเหรอ?
      แก้ไข: ผมเข้าใจผิดเอง
  • ดูเหมือนผมจะมีตัวที่เล็กที่สุด docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB และใช้สำหรับ Darwin cross-build

  • พูดตามตรง macOS น่าจะลดลงได้ต่ำกว่านั้นมาก ถ้าปิดสิ่งที่ไม่จำเป็นจริง ๆ สำหรับ VM
    iPhone รุ่นแรกมี RAM แค่ 128MiB และถ้าจำไม่ผิดมันรัน macOS Tiger เวอร์ชันที่ตัดทอนแล้วได้ จนถึงตอนนี้ RAM ค่อนข้างเหลือเฟือมาตลอด เลยไม่มีเหตุผลให้ต้องย่อมันลง แต่ทำได้แน่และคงไม่ได้ยากขนาดนั้น แค่ต้องมีคนลองอีกครั้ง

    • iPhone ยุคแรกไม่มี การทำงานหลายแอปพร้อมกัน เลยต่างกันมาก แอปจะถูกปิดไปเมื่อปิดแอปนั้น
  • บน PC สามารถ รัน macOS ได้ไหม? หรืออย่างน้อยพอจะพัฒนาแอปสำหรับ Mac บน PC ได้ด้วยวิธีใดวิธีหนึ่งหรือเปล่า?

    • บูต macOS ด้วย QEMU ได้ แต่จะใช้ กราฟิกเร่งด้วยฮาร์ดแวร์ และฟีเจอร์บางอย่างไม่ได้
  • ขอถามนอกเรื่องหน่อย เป็นไปได้ไหมที่จะ ลงทะเบียน Intune สำหรับ macOS VM เป็นอุปกรณ์ส่วนตัว?

  • สงสัยว่าทำไมไม่มีใครทำสภาพแวดล้อมเอเจนต์เฉพาะสำหรับ macOS เลย คงดีถ้าเอเจนต์สามารถ spawn ขึ้นมาในสภาพแวดล้อม Mac ได้