- Đã gắn eGPU RTX 5090 vào MacBook Air M4 và chạy game trong Linux VM, đồng thời phải lách qua việc thiếu driver macOS và các giới hạn của Thunderbolt
- Việc triển khai đòi hỏi thiết bị PCI ảo apple-dma-pci, vượt qua ánh xạ DART, vá driver NVIDIA dựa trên kprobes và chỉnh sửa QEMU/HVF
- Cyberpunk 2077 trên M4 Air + eGPU đạt 27fps ở 4K RT Ultra, và có thể tăng lên tới 111fps khi dùng tạo khung hình DLSS nên đã có thể chơi được
- Nếu cắm cùng RTX 5090 đó vào PC PCIe thông thường thì sẽ nhanh hơn 2–4 lần tùy game, do vẫn còn nhiều overhead từ FEX, Proton, VM và Thunderbolt
- Thành quả lớn hơn là suy luận AI: prefill của Qwen trên M4 Air giảm khoảng 100 lần và tốc độ sinh một luồng tăng từ khoảng 22 tok/s lên 155 tok/s
Giới hạn của Thunderbolt eGPU và Apple Silicon Mac
-
Cấu trúc Thunderbolt eGPU
- Đây là cách cắm GPU desktop như RTX 5090 vào dock Thunderbolt, rồi dock chuyển PCIe sang Thunderbolt để kết nối vào cổng USB-C của MacBook Air M4
- Thunderbolt tunnel PCIe qua cáp USB-C, nên từ góc nhìn của máy tính, thiết bị Thunderbolt hiện ra như một thiết bị PCIe chứ không phải USB
- Thunderbolt 4 cung cấp tối đa 4 lane PCIe ở 40Gbps, và có một mức hao hụt hiệu năng nhỏ do tunnel
- Thông thường trên Linux và Windows, eGPU được nhận diện như một thiết bị PCIe hơi chậm hơn bình thường và gần như chạy được ngay với driver sẵn có
- Rào cản đầu tiên là macOS trên Apple Silicon không đi kèm sẵn driver cho GPU NVIDIA hay AMD
-
Vượt qua bằng Linux VM
- Có thể chạy Linux trên Apple Silicon Mac, nhưng hiện tại Linux kernel chưa hỗ trợ Thunderbolt trên Apple Silicon, chỉ hỗ trợ thiết bị nội bộ và USB3
- Nếu chạy một ARM64 Linux VM trên macOS host, có thể kết hợp kiểu macOS xử lý thiết bị Thunderbolt còn Linux xử lý GPU NVIDIA
- Dùng Linux vì không có driver card NVIDIA cho Windows ARM64
- Driver eGPU cho macOS của tinygrad chỉ dùng được trong stack tinygrad, nên không phù hợp như một driver phổ dụng để suy luận AI hay chạy game
Triển khai PCI passthrough trên macOS
-
PCI BAR và DMA
- Để VM giao tiếp với PCI device, PCI BAR(Base Address Registers) và DMA phải hoạt động
- PCI BAR là vùng bộ nhớ mà PCI device dùng để đọc và ghi với máy tính; để PCI passthrough hoạt động thì vùng này phải được mirror vào bên trong VM
- DMA(Direct Memory Access) là cách device đọc ghi trực tiếp bộ nhớ máy tính mà không cần CPU sao chép
-
Hypervisor.framework và ánh xạ BAR
- Khi khởi động VM, QEMU gọi
Hypervisor.framework qua hv_vm_map() để thiết lập layout bộ nhớ guest
- Bằng cách kết nối tới driver PCIDriverKit trên host và dùng
IOConnectMapMemory64() để ánh xạ bộ nhớ PCI device vào process, có thể đọc được bộ nhớ BAR0
- Khi đọc
BAR0[0], kết quả trả về là 0x1b2000a1, một hằng số đặc thù của thiết bị chỉ tới RTX 5090
- Nếu QEMU ánh xạ trực tiếp bộ nhớ của device vào guest thì guest có thể giao tiếp trực tiếp với GPU, nhưng ban đầu cứ hễ VM chạm vào bộ nhớ PCI BAR là kernel host bị crash
- Nguyên nhân là QEMU gắn cả
HV_MEMORY_EXEC vào mapping RAM-device/MMIO; bỏ EXEC khỏi mapping device/MMIO là workaround để tránh host panic
- Cách này nhanh hơn khoảng 30 lần so với trap mọi truy cập, nhưng vì
hv_vm_map() không thể chỉ định subtype bộ nhớ thiết bị ARM nên ghi BAR chậm hơn khoảng 10 lần so với trường hợp bình thường
Vượt qua ràng buộc DMA và DART
-
Giới hạn DART trên Apple Silicon
- Apple Silicon có khối phần cứng DART tương tự IOMMU, đồng thời cũng đóng vai trò như ranh giới bảo mật để device không thể truy cập tùy ý vào bộ nhớ host
- Khi dùng thiết bị Thunderbolt qua PCIDriverKit, có ba giới hạn lớn
- Giới hạn ánh xạ khoảng 1.5GB khiến không thể giữ nguyên các ánh xạ bộ nhớ cỡ 8–16GB cần cho CUDA và game hiện đại
- Giới hạn khoảng 64k mapping khiến bảng ánh xạ nhanh đầy nếu có nhiều DMA buffer nhỏ
- Không thể tự chọn địa chỉ và alignment, nên mô hình IOMMU ảo nơi guest tự quyết định địa chỉ DMA không phù hợp
- Cách dùng
restricted-dma-pool để ép DMA vào vùng được cấp phát trước hoạt động với thiết bị đơn giản, nhưng không phù hợp với driver GPU
-
Thiết bị PCI ảo apple-dma-pci
- QEMU được bổ sung một PCI device ảo
apple-dma-pci và chèn nó vào VM cùng với GPU được passthrough
- Driver kernel trong guest chặn các lời gọi ánh xạ DMA của driver NVIDIA, tạo ánh xạ theo nhu cầu cho từng DMA request, rồi gỡ ánh xạ khi buffer được giải phóng
- Với cấu trúc này, không cần toàn bộ RAM của guest nằm trong giới hạn 1.5GB, mà chỉ cần working set của các DMA buffer đang hoạt động tại thời điểm đó nằm trong giới hạn
- Driver guest thay các DMA ops của driver NVIDIA bằng DMA ops tùy biến trước khi GPU được sử dụng, và xử lý
map_page, unmap_page, map_sg, unmap_sg, alloc, free bằng các wrapper mỏng
- Ở phía host, QEMU chuyển request sang driver PCIDriverKit; driver này thực hiện ánh xạ DART thực tế rồi ghi lại địa chỉ DMA vào bộ nhớ guest
-
Vấn đề alignment của NVIDIA và bản vá kprobes
- Khi chạy workload CUDA, kernel log xuất hiện
NV_ERR_INVALID_OFFSET cùng các thông báo liên quan đến alignment của RM_PAGE_SIZE_HUGE
- Allocation gây vấn đề là allocation 16MB kiểu
UVM_RM_MEM_TYPE_SYS, nơi driver NVIDIA dùng kích thước trang 2MB và bị xung đột với ràng buộc alignment
- Trong driver có sẵn workaround thử lại với kích thước trang mặc định khi lỗi
NV_ERR_NO_MEMORY, nhưng không xử lý NV_ERR_INVALID_OFFSET
- Dùng kprobes của Linux kernel để ép
pageSize thành UVM_PAGE_SIZE_DEFAULT tại lời gọi nvUvmInterfaceMemoryAllocSys()
- Nhờ vậy có thể buộc driver yêu cầu trang nhỏ hơn mà không phải sửa trực tiếp driver NVIDIA, giúp các workload đơn giản chạy được
-
Né giới hạn 64k bằng mapping coalescing
- Khi tăng thiết lập game, rất nhiều tiny mapping xuất hiện và vượt qua giới hạn số lượng mapping khoảng 64k
- Từ log mapping có thể thấy hơn 90% mapping là 4kB, và tuy không liên tiếp hoàn toàn nhưng xuất hiện theo cụm
- Bộ nhớ guest được chia thành các vùng kích thước cố định như 256kB; khi một buffer 4kB được ánh xạ thì toàn bộ cụm tương ứng cũng được ánh xạ để các allocation sau đó trong cùng cụm tái sử dụng ánh xạ cũ
- Cách này ánh xạ hơi nhiều bộ nhớ hơn lượng buffer đang hoạt động thực tế, nhưng trong workload thử nghiệm vẫn giữ dưới trần ánh xạ khoảng 1.5GB
- Số lượng live mapping giảm khoảng 4 lần, tạo thêm headroom để chạy các game nặng ở thiết lập cao nhất
Cải thiện hiệu năng VM
-
Lập lịch vCPU
- Có vấn đề benchmark dao động mạnh ngẫu nhiên và đôi khi chậm hơn tới 50%
- Có vẻ QEMU không đặt priority cho các luồng vCPU nên scheduler không cấp đủ thời gian chạy cho VM
- Đã vá đường khởi tạo vCPU của QEMU để gọi
pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) và pthread_setschedparam(..., SCHED_RR, ...), từ đó gán priority cao hơn
-
Total Store Ordering và FEX-Emu
- VM chạy Linux arm64, nhưng phần lớn game phát hành là binary Windows x86-64 nên dùng kết hợp Proton) và FEX-Emu
- x86 dùng Total Store Ordering(TSO), trong đó các phép store hiện ra với core khác theo đúng program order, còn ARM dùng mô hình memory ordering yếu hơn
- Apple Silicon có TSO mode phần cứng theo từng luồng, và
Hypervisor.framework trên macOS 15+ đã phơi bày tính năng này
- Đã lấy patch từ UTM để bật bit 1 của
ACTLR_EL1 trên vCPU, đồng thời tắt mô phỏng TSO bằng phần mềm của FEX-Emu
- Nếu tắt mô phỏng TSO bằng phần mềm mà không có bit phần cứng, Geekbench 6 sẽ crash giữa chừng
- Hiệu năng guest khi dùng FEX và TSO của CPU thấp hơn khoảng 50% so với host native
Hiệu năng chơi game
-
Cyberpunk 2077
- Cyberpunk 2077 được thử nghiệm trên M4 Air macOS native, M4 Air + eGPU, MacBook Pro Intel 2020 + eGPU, M5 Max macOS native, M5 Max + eGPU, và PC gaming i5-12600K + RTX 5090
+ Framegen dùng DLSS 4x ở cấu hình eGPU/PCIe native, còn trên macOS native thì dùng FSR 2x- Ở 720p Low, tải GPU nhỏ nên CPU và overhead từ mô phỏng/ảo hóa chi phối, khiến M4 Air native đạt 61fps nhanh hơn M4 Air + eGPU với 49fps
- Ở 1080p High, M5 Max macOS native đạt 131fps, nhanh hơn M5 Max + eGPU ở 68fps; khi GPU tích hợp đã đủ mạnh thì overhead trở nên đáng kể hơn
- M4 Air native trên macOS chỉ đạt 7fps ở 1080p RT Ultra, nhưng M4 Air + eGPU đạt 30fps, và 119fps khi bật tạo khung hình
- Ở 4K, nghẽn cổ chai chủ yếu nằm ở GPU; M4 Air + eGPU đạt 27fps ở RT Ultra và 111fps khi dùng tạo khung hình DLSS, nâng lên mức có thể chơi được
- PC gaming PCIe native là nhanh nhất với 100fps ở 4K RT Ultra và 282fps khi dùng tạo khung hình DLSS
- M5 Max + eGPU đạt 47fps ở 4K RT Ultra và 145fps khi bật tạo khung hình, nhanh hơn M4 Air + eGPU khoảng 30–70%
-
Các game và benchmark khác
- Trong GravityMark, chỉ riêng việc nối cùng GPU qua Thunderbolt thay vì khe PCIe đã làm hiệu năng giảm khoảng 20%, và M4 Air + eGPU chậm hơn khoảng 31% so với kết nối PCIe native
- Trong Shadow of the Tomb Raider, eGPU nâng M4 Air từ 8fps native ở 4K lên 40fps, còn 1080p cũng tăng từ 26fps native lên 42fps với eGPU
- Hiệu năng eGPU của Shadow of the Tomb Raider gần như giống nhau giữa 1080p và 4K, cho thấy nút thắt không nằm ở GPU mà ở CPU dưới lớp FEX
- Horizon Zero Dawn Remastered yêu cầu ánh xạ DMA vượt quá 1.5GB cùng lúc ngay cả ở thiết lập thấp nhất 720p, nên không thể bắt đầu benchmark
- Doom (2016) chạy được ở cấu hình eGPU, và overlay hiệu năng ghi nhận 49fps, luôn giữ trên 30fps
- Crysis Remastered chậm hơn tối đa khoảng 4 lần so với PC gaming, nhưng vẫn chạy được ở mức khung hình có thể chơi trên M4 MacBook Air
Hiệu năng suy luận AI
-
Qwen 3.6
- Mô hình Qwen 35B MoE được thử nghiệm ở dạng lượng tử hóa 4-bit, với 3B tham số hoạt động
- Trên GPU NVIDIA dùng vLLM và bản NVFP4, còn trên Apple Silicon dùng vllm-mlx và mô hình lượng tử hóa MLX 4-bit
- Benchmark được chạy bằng
llama-benchy
- Thunderbolt eGPU mất khoảng 9% hiệu năng so với PCIe, nhưng phần lớn xử lý diễn ra trên card nên vẫn khá gần với PCIe
- RTX 5090 nhanh hơn M4 Air 6.5 lần, nhanh hơn M4 Max Mac Studio 2.1 lần, và nhanh hơn M5 Max MacBook Pro 1.2 lần trong tác vụ sinh một luồng
- Với prompt 4K token, M4 MacBook Air mất 17 giây để prefill, nhưng khi gắn eGPU vào cùng chiếc M4 Air đó thì giảm còn 150ms, nhanh hơn 120 lần
- Khi tăng số request đồng thời từ 1 lên 4, tổng throughput của cấu hình RTX 5090 tăng khoảng 3 lần, trong khi Mac Apple Silicon mở rộng kém hơn
-
Gemma 4
- Gemma 4 31B là mô hình dense 31B, không phải MoE thưa, nên mọi token đều phải đi qua toàn bộ tham số
- GPU tích hợp của M4 Air không thể vượt quá 2–3 token/giây trong thử nghiệm, nên bị xem là ngoài ngưỡng hữu ích
- Các cấu hình RTX 5090 dựa trên vLLM đều gom quanh khoảng 50 t/s trong biên độ vài phần trăm, còn M4 Max Mac Studio đạt khoảng 22 t/s và M5 Max MacBook Pro đạt khoảng 27 t/s
- Ở prefill, RTX 5090 luôn dưới 400ms, nhưng M4 Max mất tới 21 giây để phân tích prompt 4K token, còn M5 Max mất khoảng 7.5 giây
- Các cấu hình vLLM đạt throughput khoảng 3.5 lần ở 4 request đồng thời, trong khi backend MLX trên Mac gần như không tăng thêm ở 4 request
Khả năng chạy trực tiếp và độ ổn định
-
Điều kiện phân phối và build
- Ở trạng thái hiện tại, đây chưa phải mức “tải về là chạy ngay”, và còn cần entitlement đặc biệt từ Apple
- Đã gửi yêu cầu entitlement nhưng vẫn chưa nhận được phản hồi, và thời gian chờ có thể kéo dài vài tháng
- Trong lúc đó vẫn có thể tự build driver, với điều kiện tài khoản chứng chỉ ký phải bao gồm chiếc Mac tương ứng
- Không cần tắt SIP hay dùng reduced security mode
- Có thể lấy mã tại qemu-vfio-apple
- Launcher đi kèm sẽ tự động tải image Ubuntu dựng sẵn đã cài driver
apple_dma đặc biệt
-
Độ ổn định
- Độ ổn định hiện vẫn chưa tốt
- FEX hiện có lỗi khiến Steam thường xuyên crash theo vòng lặp, và trong cấu hình này vấn đề dường như còn nặng hơn
- Việc khởi động một số game có thể mất vài phút
- Vì giới hạn ánh xạ DMA, theo thời gian mapping có thể bị phân mảnh và không còn đủ chỗ để chạy game mới
- Khi đó phải tắt Linux VM, rút GPU ra rồi cắm lại để xóa toàn bộ DMA mapping, sau đó thử lại
- Tác vụ ổn định nhất là AI, và cho mục đích này thì hệ thống hoạt động rất tốt
- Hiện đang tiến hành hợp nhất patch vào upstream QEMU, với mục tiêu lý tưởng là được đưa vào các bản phân phối QEMU phổ biến như UTM để có thể chạy ngay
1 bình luận
Ý kiến trên Hacker News
Tôi đã yêu cầu nhóm VM hỗ trợ VM GPU passthrough suốt nhiều năm. Tôi từng làm việc với Apple Silicon Mac Pro, và nếu có thể passthrough GPU gắn trong máy vào một Linux VM thì mọi thứ hẳn đã hợp lý hơn nhiều
Tiếc là đề xuất đó không được chấp nhận, nhưng việc người khác làm cho nó chạy được vẫn rất tuyệt
Cuối cùng có vẻ chỉ là vấn đề để một virtual machine monitor như QEMU áp dụng giao diện này bên cạnh cách kiểu Linux VFIO. Nếu đang nói tới Virtualization.framework thì bản thân nó cũng gần như là một loại virtual machine monitor, nên tôi tò mò chính xác macOS còn thiếu gì
Gần đây ngay cả QEMU mainline cũng đã nhận các bản vá dùng virtio-gpu cùng với "venus server" để hỗ trợ tính năng tương tự cho Linux guest dưới Hypervisor.framework. Thứ hai, bên trong Apple dường như có hỗ trợ PCI passthrough cho Virtualization.framework. Mã framework tự nó được phát hành cho khách hàng, nhưng có vẻ phụ thuộc vào kext hoặc thành phần kernel không có trong macOS phổ thông. Tôi không biết họ có ý định công khai cho khách hàng hay không, nhưng rõ ràng là bên trong Apple đã có người từng nghĩ tới tính năng này
Dù sao thì Mac Pro giờ cũng là sản phẩm đã chết. Chỉ bán cho giới chuyên nghiệp audio/video thì có giới hạn
Bài viết rất hay. Benchmark game thì vui thật, nhưng về mặt thực dụng thì phần cải thiện hiệu năng LLM mới thật sự đáng chú ý
Nền tảng Apple là môi trường dễ tiếp cận để chạy model cục bộ nhờ có nhiều RAM, nhưng tốc độ xử lý prompt tương đối chậm thường bị bỏ qua. Như bài viết trích dẫn, với prompt 4K token thì M4 MacBook Air mất 17 giây để parse trước khi bắt đầu sinh phản hồi, còn gắn eGPU vào thì chỉ mất 150ms, nhanh hơn 120 lần. Khi nghịch LLM bằng các đoạn chat nhỏ thì vấn đề prefill ít lộ ra, nhưng khi bắt đầu dùng cho các tác vụ lớn hơn thì giới hạn tính toán trở thành nút thắt. Biểu đồ thời gian tới token đầu tiên (TTFT) thoạt nhìn cũng không tệ, nhưng ý nghĩa thay đổi hẳn khi thấy nền tảng Mac chậm hơn tổng năng lực tính toán GPU quá nhiều đến mức phải vẽ theo thang log
Khi tác giả trình bày kết quả theo kiểu đó có thể tạo cảm giác hơi thiên lệch, nhưng tôi tin thực tế không phải vậy
Có vẻ đúng khi nói OpenGL trên macOS không còn được hỗ trợ tốt nữa nên game không thể chơi trọn vẹn kể cả qua CrossOver
Tuy vậy Doom dường như hỗ trợ Vulkan, và có lẽ chỉ cần thêm
VK_NV_glsl_shadervào MoltenVK là được. Có vẻ vẫn ít việc hơn nhiều so với chuyện gắn RTX 5090 vào M4, nhưng dù sao cũng phải vỗ tay cho Scott. Tốc độ suy luận AI cục bộ cũng khá ấn tượng, đúng là một dự án điên rồ theo nghĩa tốtKhá ấn tượng. Ấn tượng của tôi trước giờ là eGPU đơn giản là không hoạt động trên Apple Silicon
Apple cũng nói như vậy. “Để dùng eGPU, bạn cần một máy Mac dùng bộ xử lý Intel.” Hơn nữa các eGPU được hỗ trợ chính thức cũng đều là AMD chứ không phải NVIDIA. https://support.apple.com/en-us/102363
Ở đây cấu trúc là tunnel eGPU vào Linux VM
Ban đầu tôi tưởng đây sẽ là một bài chạy VM với driver tinygrad chậm chạp, nhưng thực ra cách tiếp cận tốt hơn nhiều
Giá mà Apple hỗ trợ tốt hơn và nới giới hạn cửa sổ 1.5GB thì mọi thứ đã dễ hơn nhiều. Arm nói chung có nhiều điểm kỳ quặc quanh thiết bị PCIe, nhưng ít ra trên Linux thì hầu hết driver hiện đại đã coi arm64 là công dân hạng nhất nên dễ thở hơn hẳn
Tôi đoán lý do lớn khiến tinygrad chậm là engine suy luận tinygrad vẫn chưa được tối ưu nhiều cho các model LLM công khai kiểu này. Chắc phần lớn công sức được dồn vào tối ưu stack cho công ty phần cứng xe tự lái của George. Vì không thể lấy các kernel CUDA sẵn có chạy nguyên trạng trên engine đó nên độ khó kỹ thuật tăng lên nhiều. Tôi cũng tò mò liệu dự án của tôi có thể dùng chung driver host macOS với họ không. Có lẽ sẽ cần một vài thay đổi, nhưng có vẻ phần giao nhau khá lớn
Đoạn “bước đầu tiên của hầu hết dự án ngày nay là miễn cưỡng hỏi AI” có lẽ đúng hơn nên hiểu là AI sẽ nói cho bạn biết những điều chính nó cũng không biết
Làm tôi nhớ hôm qua tôi tranh cãi với ChatGPT về việc 5070TI có phải card đồ họa thật hay không. ChatGPT cứ khăng khăng sửa tôi rằng không hề có 5070TI nào cả, chắc tôi muốn nói 4070ti
Tôi bảo Claude tạo một trang HTML về PowerShell 7 thì nó viết rằng 7.4 là bản LTS mới nhất. Tôi đưa link nói 7.6 đã phát hành từ tháng 3 và bảo làm lại theo thông tin mới, vậy mà nó gần như tạo lại đúng trang cũ và tiếp tục khẳng định 7.4 là bản phát hành mới nhất
Dù vậy, câu trả lời của ChatGPT về bài gốc lại hoàn toàn đúng. Tóm tắt kiểu “rất chuyên sâu”, “gần như không thực tế”, và “xét từ góc độ nghiên cứu” mô tả bài này một cách hoàn hảo
Cái này thật sự quá đỉnh. Tôi có một 5090 đang nhàn rỗi và đang chạy claw-like trên M4 Mini, nên nếu có thể gắn nó vào kiểu khung in 3D để đảm bảo ổn định rồi nối vào cổng TB, nó có thể trở thành công cụ khá ổn cho suy luận cục bộ
Dĩ nhiên vẫn cần một thiết bị nào đó đảm bảo phần cấp nguồn được gọn gàng. Vấn đề là
max-num-seqsvàmax-model-lenxung đột với nhau, và nếu không chạy ở chế độ thuần một client thì kiểu gì cũng cần nhiều slotNếu vượt qua được khâu phê duyệt của Apple thì có vẻ sẽ khá hữu ích cho suy luận AI. Tôi vốn muốn dùng NVIDIA GPU trên Mac Mini, và cách này sẽ cho phép chạy CUDA trực tiếp. Quá tuyệt