Apple Silicon กับ macOS VM: รัน llama.cpp เร็วขึ้นได้จริงไหม

รัน llama.cpp บน macOS VM ผ่าน UTM หรือ Parallels ยังมี overhead อยู่บ้าง เพราะ GPU passthrough ไปหา Metal ไม่ได้เต็มประสิทธิภาพเท่ารันตรงเครื่อง แต่ถ้าใช้ Virtualization.framework ที่ Apple ทำเองก็ลดช่องว่างได้เยอะ ชิป M-series ตัวที่มี unified memory เยอะๆ จะได้เปรียบเรื่องรันโมเดลใหญ่ในแซนด์บ็อกซ์ที่แยกจากเครื่องหลัก เหมาะกับงานที่ต้องการแยก environment ทดสอบหลายเวอร์ชัน หรือรันบน CI ที่ต้อง isolate แต่ถ้าต้องการความเร็วสูงสุดสำหรับ production ควรรันตรงเครื่อง (native) ไปเลยจะดีกว่า

สรุป: VM เหมาะกับ dev/test ที่ต้องการความยืดหยุ่นและความปลอดภัยของ sandbox มากกว่าความเร็ว ถ้างบเครื่องจำกัดและต้องการ inference เร็วสุด ให้เลี่ยง VM แล้วรันตรงบน macOS host แทน

Terminal ฝั่งซ้ายคือรันตรงบนเครื่อง Apple Silicon เห็น GPU กับ Neural Engine ทำงานเต็มที่ใน Activity Monitor ส่วนฝั่งขวาคือรันในสภาพแวดล้อม macOS VM ที่ layer virtualization กั้นกลางอยู่.

จุดที่ต้องดูคือตัวเลข token/sec ท้าย log — นี่คือตัวชี้วัดตรงที่สุดว่า inference เร็วแค่ไหน ไม่ใช่แค่ดู CPU usage เฉยๆ.

ถ้าใครจะ benchmark เองที่บ้าน แนะนำรัน llama-bench ทั้งสองฝั่งแล้ว log ตัวเลขเก็บไว้เทียบ จะเห็นภาพชัดกว่าดูจากภาพเดียว.

ตอนที่ต้องรัน LLM ในเครื่องที่ไม่ใช่เครื่องตัวเอง

สถานการณ์นี้คุ้นเคยกับสาย dev หลายคน: ต้องเทสต์โมเดลใน sandbox แยก, รัน CI pipeline, หรือ demo ให้ client ดูบน environment ที่ไม่ใช่เครื่องหลัก บางทีก็ต้องเทสต์ macOS หลายเวอร์ชันพร้อมกัน VM เลยกลายเป็นทางเลือกที่เลี่ยงไม่ได้

ปัญหาคือพอ spin up VM แล้วรัน llama.cpp inference กลับช้าลงจนใช้งานจริงไม่ได้ ทั้งที่เครื่อง host ก็เป็น Apple Silicon ตัวแรงอยู่แล้ว

คำถามที่ตามมาคือ layer virtualization กินประสิทธิภาพไปเท่าไหร่ และ VM บน Apple Silicon จะเร็วพอสำหรับงาน inference จริงหรือเปล่า ไม่ใช่แค่รันได้ แต่ต้องเร็วพอจะใช้ทำงานต่อได้จริง

ทางเลือกรัน LLM บน Mac ที่เดฟใช้กันอยู่

ทางเลือกรัน LLM บน Mac มีหลายชั้น เรียงจากเบาไปหนัก: รันตรงเครื่อง (native) เร็วสุดเพราะชนกับ GPU/Neural Engine ตรงๆ, ตามด้วย Docker container ที่บน Mac จริงๆ ก็คือ VM เบาๆ ซ่อนอยู่ข้างใน, ไปจนถึง VM เต็มรูปแบบผ่าน Apple Virtualization.framework (ตัวที่ Apple ทำเอง) หรือผ่าน UTM/Parallels/VMware Fusion ที่ครอบอีกชั้น

จุดที่น่าสนใจคือช่วงหลัง Apple เปิดให้ virtualization เข้าถึง GPU ได้มากขึ้นเรื่อยๆ ผ่าน Virtualization.framework ต่างจากยุคก่อนที่ VM แทบแตะ GPU ไม่ได้เลย เหตุผลหลักคือ demand จากงาน dev/AI ที่ต้อง isolate environment แต่ยังอยากได้แรง GPU จริงของเครื่อง host

นี่คือเหตุผลที่คำถาม “VM เร็วพอไหม” เพิ่งมีความหมายจริงในตอนนี้ ก่อนหน้านี้ไม่มีทางเลือกให้ถามด้วยซ้ำ

GPU ใน VM เปลี่ยนไปแค่ไหนหลัง Sonoma

ก่อนจะไปต่อ ลองเทียบให้เห็นภาพชัดๆ ว่า VM บน Apple Silicon เปลี่ยนไปแค่ไหน

จุดต่างที่สำคัญสุดคือ GPU passthrough — ตัวแปรที่ทำให้ “VM สำหรับรัน AI จริงจัง” เพิ่งกลายเป็นตัวเลือกที่ใช้งานได้ ไม่ใช่แค่ของเล่นทดสอบ

งานสายเดฟที่ macOS VM เข้ามาช่วยได้

สถานการณ์แรกที่เห็นชัดสุดคือ isolate environment — เวลาจะลองโมเดลใหม่หรือ build llama.cpp เวอร์ชันทดลอง ก็แยกไปรันใน VM แทนที่จะเสี่ยงพังเครื่องหลัก

ต่อมาคือ CI pipeline: ตั้ง VM หลายตัวรัน macOS คนละเวอร์ชันเพื่อทดสอบว่า build ผ่านทุกแพลตฟอร์มจริงไหม ก่อนปล่อยจริง

อีกเคสคือทำ demo ให้ client แบบ sandbox — เปิด VM ที่ config พร้อมสาธิต โดยไม่ต้องแตะข้อมูลหรือ environment งานจริงบนเครื่อง host เลย

และด้วย GPU passthrough ที่ยืดหยุ่นขึ้น ทำให้แชร์ GPU ตัวเดียวให้หลาย VM ทดลองพร้อมกันได้ เหมาะกับทีมที่อยากลองหลายโมเดลคู่ขนานโดยไม่ต้องซื้อเครื่องเพิ่ม

ทั้งหมดนี้คือจุดที่ macOS VM เปลี่ยนจาก “ของเล่นทดสอบ” มาเป็นเครื่องมือทำงานจริงได้

เทียบ macOS VM กับ Docker และ Cloud GPU

ก่อนจะปักใจใช้ macOS VM ลองดูทางเลือกอื่นที่ทำงานคล้ายกันไว้เทียบก่อน

พูดง่ายๆ คือถ้าต้องการ isolate เต็มที่บนเครื่องที่มีอยู่แล้ว macOS VM ตอบโจทย์สุด แต่ถ้าต้องการสเกลแรงๆ ชั่วคราว cloud GPU ยังจำเป็นอยู่ดี

จุดที่ VM ทำได้ดี และจุดที่ยังกิน throughput

จากที่ทดลองรัน llama.cpp บน macOS VM เทียบกับรันตรงบน host มาสักพัก สรุปเป็นข้อดี-ข้อเสียที่เห็นชัดสุด

ข้อดีหลักคือ isolate งานทดสอบโมเดลออกจากเครื่องทำงานจริงได้ ไม่ต้องกลัว dependency ชนกัน แถม snapshot/rollback ทำได้ไวกว่าตั้งเครื่องใหม่เยอะ ส่วนข้อเสียคือ overhead จาก virtualization กิน throughput ไปส่วนหนึ่ง และการ debug GPU passthrough ตอน setup แรกใช้เวลานานกว่าที่คิด บาง config ต้องลองผิดลองถูกหลายรอบกว่าจะนิ่ง

ค่าใช้จ่ายที่ไม่มีใครบอกตอนเริ่มตั้งค่า

ปัญหาแรกคือ RAM โดนกันซ้ำ — host เก็บไว้ส่วนหนึ่ง ยกให้ guest อีกก้อน โมเดลใหญ่ที่ควรพอรันได้เลยกลายเป็นรันไม่ได้เพราะ RAM ที่ใช้จริงเหลือน้อยกว่าที่คิด

ต่อมาคือ storage — VM image เก็บโมเดลซ้ำกับที่มีบน host อยู่แล้ว พื้นที่หายไปเงียบๆ โดยเฉพาะถ้าทดลองหลาย config พร้อมกัน

ถ้าไม่ใช้ UTM (ฟรี) แล้วไปเลือก Parallels หรือ VMware ก็มีค่า license เพิ่มอีกก้อนต่อปี

ที่แพงสุดคือเวลา — debug performance tax ของ virtualization layer กินเวลาไปกับการหาว่าทำไม throughput ตกกว่าที่ควร บางทีปัญหาไม่ได้อยู่ที่ config llama.cpp เลย แต่อยู่ที่ตัว virtualization เอง

รวมๆ แล้วต้นทุนแฝงพวกนี้ต้องคิดรวมก่อนตัดสินใจตั้งค่า ไม่ใช่แค่ดูสเปคเครื่องอย่างเดียว

เหมาะกับใคร ไม่เหมาะกับใคร

ทิศทางที่น่าจับตาต่อจากนี้

เรื่อง virtualization บน Apple Silicon เพิ่งเริ่มต้นเท่านั้น GPU passthrough เต็มรูปแบบยังไม่มา แต่ทิศทางของ Apple ที่ผ่านมาคือค่อยๆ เปิด API ให้ VM เข้าถึง hardware ได้ลึกขึ้นเรื่อยๆ ถ้าเทรนด์นี้ต่อเนื่อง โอกาสที่ throughput tax จะหายไปในอนาคตก็มีสูง

สำหรับคนที่กำลังจะตั้ง pipeline รัน LLM เอง คำแนะนำคือ อย่าเริ่มจาก VM ก่อน เริ่มรันตรงบน macOS host แล้ววัด performance ที่ต้องการจริงๆ ก่อน

ถ้าจำเป็นต้อง isolate environment จริงๆ (เช่น งาน dev หลาย project ชนกัน) ค่อยพิจารณาแบก virtualization layer เข้ามา แต่ต้องเผื่อเวลา debug throughput ตกไว้ในแผนด้วย เพราะนี่คือต้นทุนแฝงที่มองข้ามไม่ได้จริงๆ