Tăng tốc LLM trên máy ảo macOS: Đạt hiệu suất gần như máy thật nhờ tối ưu hóa Metal

Apple Silicon và macOS VM: Suy luận LLM nhanh hơn 11–16 lần với llama.cpp

Đăng ngày 11 tháng 8 năm 2026 bởi Francesco Bonacci và Johnny Franks

Nếu bạn đã theo dõi Cua từ những ngày đầu, có lẽ bạn còn nhớ dự án bắt đầu với màn ra mắt Show HN cho Lume, ngăn xếp ảo hóa macOS của chúng tôi.

Một máy khách (guest) macOS chạy thông qua Virtualization.framework của Apple sử dụng một GPU ảo được hỗ trợ bởi Apple GPU của máy chủ (host). Trong VM Tahoe tiêu chuẩn của chúng tôi, thiết bị đó báo cáo một cấu hình khả năng Metal khá bảo thủ. Các ứng dụng sử dụng những phản hồi đó để chọn nhân (kernel) và đường dẫn kết xuất (rendering path), điều này khiến llama.cpp chạy các mã GPU chậm hơn nhiều.

Chúng tôi đã xây dựng một lớp tương thích nhỏ, giới hạn trong phạm vi tiến trình, giúp thay đổi các phản hồi về khả năng cho một tiến trình máy khách, cho phép llama.cpp chọn các nhân Metal mới hơn. Đây là kết quả đầu tiên từ nỗ lực rộng lớn hơn của chúng tôi nhằm kết nối nền tảng ảo hóa của Lume với các môi trường sử dụng máy tính cục bộ đằng sau Cua Driver và cơ sở hạ tầng đằng sau Cua Cloud và Fleets.

Chúng tôi phát hành công trình này hôm nay dưới dạng bản phát hành nghiên cứu với cùng giấy phép mở như Lume và Cua, để những người khác có thể tái lập kết quả và giúp xác định xem những chip Apple Silicon, phiên bản macOS và khối lượng công việc Metal nào được hưởng lợi.

Trên M1 Ultra, TinyLlama 1.1B chạy qua llama.cpp đã xử lý các câu lệnh (prompt) nhanh hơn 11,08 lần và tạo token nhanh hơn 16,36 lần so với cùng khối lượng công việc trong cùng một VM tiêu chuẩn. Tốc độ xử lý câu lệnh đạt 98% kết quả trên phần cứng thực (bare-metal). Mã nguồn, tập lệnh xây dựng, công cụ kiểm tra khả năng và nhật ký benchmark thô đều được đính kèm để bạn có thể kiểm tra và tái lập kết quả.

Chúng tôi đã lặp lại thí nghiệm với Gemma 4 12B QAT Q4_0 của Google, một mô hình 6,98 GB được phát hành trong năm nay. Lớp tương thích tương tự đã cải thiện tốc độ xử lý câu lệnh lên 7,20 lần và tạo token lên 14,54 lần. VM đã mở khóa đạt 99,59% tốc độ xử lý câu lệnh và 94,82% tốc độ tạo token so với phần cứng thực.

Sau đó, chúng tôi đã thử nghiệm Muse Glimmer 30B Q4_K-M GGUF chính thức của Meta trong một máy khách 64 GiB. Thông qua llama.cpp b10359, VM đã mở khóa xử lý câu lệnh 512-token nhanh hơn 7,55 lần và tạo 128 token nhanh hơn 8,87 lần so với máy khách tiêu chuẩn. Đây là bài kiểm tra llama.cpp chỉ dành cho văn bản; nó không sử dụng Ollama, bộ chiếu đa phương thức (multimodal projector) hay drafter.

Khoảng cách về khả năng tương tự cũng xuất hiện ở các giao diện Virtualization.framework khác. Tart, một CLI ảo hóa macOS khác, có một vấn đề mở là “Không có GPU passthrough trong máy khách macOS?” bao gồm cả hiệu suất đồ họa và LLM bên trong các máy khách macOS.

Giới hạn bên trong một macOS VM

Virtualization.framework của Apple cung cấp cho máy khách macOS một thiết bị đồ họa ảo. Máy khách gửi các tác vụ Metal thông qua một trình điều khiển GPU được xây dựng cho mục đích này, và ngăn xếp máy chủ của Apple thực thi chúng trên GPU vật lý. Cơ chế này là ảo hóa bán phần (paravirtualization), nơi máy chủ giữ quyền kiểm soát phần cứng và máy khách sử dụng một thiết bị nhận biết ảo hóa.

Điều này khác với các ngăn xếp ảo hóa khác được xây dựng trên QEMU và KVM, vốn có thể sử dụng một kiến trúc khác. Trên các máy chủ Linux x86, VFIO có thể gán một thiết bị PCI vật lý tương thích hoặc chức năng phần cứng cho một VM thông qua IOMMU, cho phép máy khách truy cập trực tiếp vào thiết bị đó. Đây là mô hình thường được hiểu là GPU passthrough.

Trong VM Tahoe tiêu chuẩn của chúng tôi, thiết bị ảo hóa bán phần báo cáo khoảng dòng Apple 5, bộ nhớ threadgroup tối đa 32 KB và hỗ trợ ma trận nhóm SIMD là không khả dụng. Phần mềm Metal hiện đại sử dụng các câu trả lời đó để chọn nhân, vì vậy llama.cpp đã chọn một đường dẫn chậm hơn mặc dù thiết bị hoàn toàn có thể thực thi các nhân mới hơn.

Apple ghi lại khả năng GPU thông qua các dòng GPU và bảng tính năng, đồng thời khuyến nghị truy vấn thiết bị tại thời điểm chạy (runtime). Điều đó làm cho ranh giới khả năng được báo cáo trở nên quan trọng: các ứng dụng đang thực hiện chính xác những gì nền tảng yêu cầu chúng làm.

Giải pháp: một shim khả năng Metal giới hạn trong tiến trình

Chúng tôi đã xây dựng một shim khả năng Metal nhỏ (một lớp tương thích được chèn giữa ứng dụng và API) chạy bên trong một tiến trình máy khách. Nó chặn các truy vấn khả năng Metal được chọn và thay đổi các câu trả lời trả về cho tiến trình đó. Các ứng dụng Metal sử dụng những câu trả lời đó để chọn nhân, vì vậy việc trả về các giá trị dòng Apple và bộ nhớ threadgroup đã được kiểm thử cho phép llama.cpp chọn các đường dẫn GPU mới hơn của nó. Đối với cấu hình đã kiểm thử của chúng tôi, shim này:

Điều đó là đủ để bản dựng llama.cpp đã kiểm thử chọn các đường dẫn giảm nhóm SIMD, ma trận nhóm SIMD và bfloat16 mới hơn:

Cấu hình đã kiểm thử thay đổi hai giá trị được báo cáo: câu trả lời về dòng Apple và giới hạn bộ nhớ threadgroup. Các giá trị Common, Mac, Metal và working-set-size giữ nguyên cài đặt tiêu chuẩn trong suốt quá trình benchmark. Chúng tôi đã loại bỏ hook tính năng riêng tư, sự can thiệp vào xung nhịp và thời gian, thay thế mesh, ghi đè ray-tracing, bảo vệ bố cục đối số và dự phòng biên dịch pipeline của hook nghiên cứu ban đầu. Mã nguồn của nó đủ nhỏ để kiểm toán, và cấu hình bị lỗi hoặc thiếu sẽ giữ cho tiến trình đi theo đường dẫn khả năng tiêu chuẩn.

Khối lượng công việc vẫn nằm trên đường dẫn đồ họa Virtualization.framework của Apple và thực thi trên Apple GPU của máy chủ. Các thay đổi về khả năng chỉ giới hạn trong tiến trình máy khách được tiêm (injected).

Việc gán GPU vật lý, passthrough PCI thô hoặc VFIO và các thay đổi nhân nằm ngoài cơ chế này. Một dòng được báo cáo mô tả các đường dẫn được bao phủ bởi các thử nghiệm của chúng tôi; mỗi API Metal bổ sung đều yêu cầu xác thực riêng.

Shim này mở khóa các khả năng Metal trên đường dẫn GPU ảo hiện có của Apple. Người dùng VM thường gặp phải giới hạn rộng hơn này dưới cái tên “GPU passthrough”.

Kết quả mới từ artifact tối giản

Chúng tôi đã thử nghiệm trên một Apple M1 Ultra với GPU 48 nhân và macOS 26.6.1. Máy khách là hình ảnh Tahoe Cua công khai hiện tại (macOS 26.5.2, 8 vCPU và 16 GiB) chạy trong Lume 0.5.1. Cả ba lần chạy đều sử dụng bản phát hành llama.cpp b10167 chính thức và cùng một mô hình TinyLlama 1.1B Chat Q4_K_M.

Lệnh thực hiện là:

Các giá trị dưới đây là trung vị của mười mẫu được đưa ra cho mỗi hàng benchmark:

Tốc độ xử lý câu lệnh gần đạt đến kết quả của máy chủ. Tốc độ tạo đạt 72,06% tốc độ của máy chủ, để lại một khoảng cách VM có thể đo lường được. Mức tăng phụ thuộc vào GPU máy chủ, phiên bản máy khách, ứng dụng và hình thái khối lượng công việc.

Kết quả thô và hồ sơ môi trường của TinyLlama bao gồm digest hình ảnh chính xác, mã băm mô hình và tệp nhị phân, các lệnh, đầu ra JSON, stderr và checksum. Những kết quả ứng viên phát hành này chứng nhận shim rút gọn được sử dụng trong bài viết này.

Một mô hình 12B hiện tại

TinyLlama tạo ra một bài benchmark có kiểm soát hữu ích vì nó chạy nhanh và làm lộ rõ đường dẫn Metal. Chúng tôi cũng muốn một mô hình lớn hơn mà các nhà phát triển có thể chọn ngày nay, vì vậy chúng tôi đã chạy Gemma 4 12B instruction-tuned QAT Q4_0 GGUF chính thức của Google thông qua cùng một tệp nhị phân llama.cpp.

Máy chủ, VM, shim, hình thái benchmark và phương pháp mười mẫu vẫn giữ nguyên. Chúng tôi đã vô hiệu hóa giải mã suy đoán (speculative decoding) và để bộ chiếu đa phương thức không tải, giữ cho sự so sánh trên cùng một đường dẫn suy luận Metal:

Bằng chứng Gemma 4 đính kèm phiên bản mô hình và SHA-256 của Google cùng với các mẫu thô cuối cùng. Chúng tôi đã loại bỏ và chạy lại một loạt thử nghiệm tiêu chuẩn sơ bộ sau khi phát hiện một khối lượng công việc tính toán khác trên máy chủ. Các tệp tiêu chuẩn, đã mở khóa và phần cứng thực được giữ lại đến từ cùng một cửa sổ không bị tranh chấp và cho thấy các phạm vi mẫu chặt chẽ.

Một mô hình văn bản 30B trong máy khách 64 GiB

Muse Glimmer cho phép chúng tôi kiểm tra cùng một đường dẫn khả năng với một mô hình lớn hơn. Chúng tôi đã sử dụng Q4_K-M GGUF 16,76 GB chính thức của Meta, nâng máy khách Tahoe lên 64 GiB và cập nhật llama.cpp lên b10359. Việc xử lý câu lệnh và tạo văn bản chạy như các tiến trình mới riêng biệt với tám luồng và giảm tải GPU đầy đủ:

Các giá trị này là trung vị của ba mẫu llama-bench. Quá trình khởi động cùng tiến trình tích hợp sẵn đã chạy trước mỗi hàng và bị loại trừ khỏi các mẫu. Cả bốn tiến trình đều thoát thành công. Trước và sau mỗi lần chạy, máy khách báo cáo 90% bộ nhớ trống, không có swap và không sử dụng trình nén. Stderr tiêu chuẩn báo cáo dòng Apple 5 với các đường dẫn SIMD-group và bfloat mới hơn bị vô hiệu hóa; stderr đã mở khóa báo cáo dòng Apple 9 với các đường dẫn đó được kích hoạt.

Máy chủ được chia sẻ với một VM khác có hoạt động CPU không liên tục, vì vậy bằng chứng Muse Glimmer bảo toàn ranh giới đó. Các mẫu pp512 rất chặt chẽ, và trung vị tg128 tiêu chuẩn khớp trong phạm vi 5,6% so với một lần chạy độc lập trước đó. Bằng chứng công khai bao gồm phiên bản mô hình chính thức và SHA-256, mã băm của llama.cpp và shim, JSON thô đã làm sạch đường dẫn, nhật ký khả năng, các đối số chính xác, tóm tắt đo từ xa và checksum.