企业官网建设流程全解析

如果你想让一台普通 X86 服务器或工作站跑起 macOS，又希望显卡真正参与渲染和计算，OSX-KVM 加 GPU 硬件加速是目前社区里被验证过最多的一条路径。简单说，OSX-KVM 是一个开源项目，它把 QEMU/KVM、OpenCore 引导器和 macOS 安装脚本组合起来，让非苹果硬件上有机会启动 macOS；而 GPU 硬件加速则通过 VFIO 把一张物理显卡直接交给虚拟机，让 macOS 不再依赖虚拟显示设备。这里解决的问题很具体：之前虚拟机里的 macOS 基本靠 CPU 软渲染，界面卡顿、视频播放不流畅、Metal 程序根本跑不动。有了 GPU 直通之后，Final Cut Pro 渲染、Blender 的 Metal 后端、PyTorch 的 MPS 计算、Ollama 的大模型推理，都可以在虚拟化环境里接近原生速度运行。

这篇文章适合两类人：一类是做虚拟化、CI、自动化测试的工程师，需要一台低成本的 macOS 构建机；另一类是玩 KVM、QEMU 的技术爱好者，想搞清楚 GPU 直通到底是怎么配置的。下面按我实际踩坑的顺序拆开讲，不绕圈子。

1. 先搞清楚 OSX-KVM 的 GPU 硬件加速到底解决了什么

1.1 虚拟机里为什么需要 GPU 硬件加速

KVM 虚拟机默认会给 guest 提供一个虚拟显卡，QEMU 通常用 VGA 或 virtio-gpu 来模拟显示输出。对 Linux、Windows 来说，这种虚拟显卡配合 virtio 驱动已经能应付桌面和普通 2D 任务。但 macOS 不一样，它对图形栈要求更高，系统界面本身的窗口合成、滚动、缩放都依赖 Metal 或 OpenGL。单纯用虚拟显卡跑 macOS，哪怕分配了十几个 CPU 核心和大内存，操作起来也像远程桌面在高延迟网络里工作，窗口拖动会掉帧，播放 4K 视频更是灾难。

更麻烦的是计算类任务。PyTorch 在 macOS 上有一个 MPS 后端，Ollama、llama.cpp 也能走 Metal 加速。这些能力都要求系统能访问到真实的 GPU 设备。虚拟显卡没有对应的 Metal 驱动，应用层只能退回 CPU 计算，大模型推理速度和 GPU 差距可以拉到十倍以上。GPU 硬件加速要解决的就是这个核心矛盾：让 macOS 直接看到一张物理显卡，而不是一个经 QEMU 转发的模拟设备。

1.2 OSX-KVM 项目在中间扮演什么角色

OSX-KVM 不是一个单独的工具，更像一套组合脚本和配置文件。它解决的是“在 KVM 里把 macOS 引导起来”这个基础问题，包括 OpenCore 引导器配置、QEMU 启动参数、Clover 兼容层、macOS 安装镜像下载脚本等。GPU 直通只是这套链路里的一步，但它是最容易出问题的一步。

我的经验是：先把 OSX-KVM 跑起来，用虚拟显卡看到 macOS 桌面，再考虑 GPU 直通。很多人跳过基础环境，一上来就摸显卡，结果连启动日志都看不清，问题排查会非常痛苦。基础环境验证通过之后，GPU 直通的价值才能真正体现出来，否则一张显卡插上去，启动界面黑屏、OpenCore 循环、登录后紫屏，这些现象会让你分不清是引导问题还是显卡问题。

1.3 GPU 直通后的实际表现

我自己在 AMD Ryzen 9 5900X 的机器上，直通过一张 Radeon RX 580 和一张 Radeon RX 6600 XT。效果比较明显的有三点：

• 系统桌面的流畅度和原生 Mac mini 几乎无差别，窗口动画、缩放、Mission Control 都不掉帧。
• Metal 相关测试能跑起来，Geekbench Metal 分数和同型号显卡在物理 Mac 上的差距不大，通常损耗在 5% 到 10% 以内。
• PyTorch 的 MPS 后端能正常识别到 GPU，跑小型扩散模型或文本生成模型时，算力和物理 Mac 接近，核心瓶颈往往在内存带宽和虚拟 CPU 分配上。

但也要说明，这不等于所有场景都顺滑。如果显卡型号太新或太老，驱动匹配不上，系统可能只能显示 7MB 显存，等于没有加速。这一点在后面的兼容性部分再展开。

2. 硬件和 BIOS 准备，决定 GPU 直通能不能成

2.1 CPU、主板和内存的基本门槛

GPU 直通依赖 IOMMU，也就是 Intel 的 VT-d 或 AMD 的 VT-d 对应的 AMD-Vi。所以第一道门槛不是显卡，而是 CPU 和主板：

如果 CPU 是 Intel 带核显的型号，可以把核显留给宿主机，独显直通给 macOS，这样不需要插两张独显。AMD 不带核显的 CPU 就要准备两张独显，或者用主板自带的显示输出加一张独显，宿主机用板载显卡，独显专门直通过去。

2.2 BIOS 里必须开的几个选项

不管用 Intel 还是 AMD，BIOS 设置高度相似。我建议按这个顺序检查：

1. 开启虚拟化相关选项：Intel 叫 VT-x / Virtualization Technology，AMD 叫 SVM Mode。
2. 开启 VT-d 或 AMD-Vi，这是 IOMMU 的总开关。
3. 开启 Above 4G Decoding，也叫 Above 4G MMIO BIOS Assignment。GPU 的大块显存地址需要映射到高位内存空间，不开这个选项，直通常常失败。
4. 开启 UEFI 启动，关闭 CSM。macOS 在纯 UEFI 模式下更容易被 OpenCore 引导。
5. 如果主板支持 Resizable BAR，建议先关闭。部分主板开了之后会在 GPU 直通时出现地址冲突。

这里最容易被忽略的是 Above 4G Decoding。很多人配置了半天，IOMMU 分组也正常，但虚拟机一启动显卡就报 could not get resource 之类的问题，最后发现就是 BIOS 里少开这一项。

2.3 显卡选择为什么比 CPU 还关键

macOS 对显卡的驱动支持是由 Apple 决定的，不是所有显卡都开箱即用。OSX-KVM 场景下，社区验证过的顺序大致是：

• AMD Radeon RX 500 系列、RX 5000 系列、RX 6000 系列，原生支持较好，是首推。
• AMD Radeon RX 7000 系列部分型号在新系统上有支持，但早期容易出现睡眠唤醒黑屏。
• NVIDIA 显卡在较新 macOS 上基本没有官方驱动，老型号 Kepler 架构在特定版本能用，但体验不完整。
• Intel 核显直通到 macOS 的案例很少，不建议新手尝试。

换句话说，OSX-KVM 的 GPU 直通，基本就是 AMD 显卡的主场。如果你手头只有 NVIDIA 显卡，先把期望调低，别指望一键跑满 Metal。

3. 先搭好 OSX-KVM 基础环境，再谈 GPU 直通

3.1 下载项目并准备 macOS 安装介质

OSX-KVM 的常规流程是从 GitHub 克隆项目仓库，然后运行脚本下载 macOS 恢复镜像或完整安装器。原项目会维护一个 OpenCore 配置目录，脚本会自动匹配不同版本系统。基础步骤如下：

git clone https://github.com/kholia/OSX-KVM.git cd OSX-KVM ./fetch-macOS.py

这个脚本会列出可以下载的 macOS 版本，选择你需要的版本后，它会自动下载到当前目录。较新的脚本还会生成一个可启动的恢复镜像或完整安装器，具体取决于所选版本。

下载完成之后，先不要急着加显卡。用项目里的 qemu 启动脚本或手动创建的 virt-manager 虚拟机，把 macOS 安装到虚拟磁盘里。这个阶段用虚拟显卡，显示方式用 VNC 或 SPICE 都能接受。安装过程可能比较慢，特别是下载安装器和系统初始化阶段，需要耐心等。

3.2 virt-manager 创建虚拟机的配置建议

我一般用手动创建虚拟机的方式，而不是直接跑官方的 boot-macOS.sh，因为 virt-manager 的图形界面更容易调整 XML。创建虚拟机的时候，有几个配置要点：

• 操作系统类型不要选 macOS，手动选择 QEMU TCG 或默认类型即可，因为 virt-manager 内置的 macOS 支持并不符合 OSX-KVM 的配置。
• 固件选择 UEFI，也就是 OVMF。OpenCore 需要 UEFI 环境，不能用 SeaBIOS。
• 磁盘建议使用 VirtIO 或 SATA。macOS 对 VirtIO 磁盘有社区驱动支持，但安装阶段可能找不到磁盘，如果遇到识别问题，先用 SATA 默认接口把系统装上再说。
• 网络优先使用 e1000-82545em 或 virtio-net，前者兼容性更好，后者性能更高。安装阶段用 e1000 更稳。

创建好虚拟机后，把 OSX-KVM 项目里的 OpenCore 镜像附加为启动盘。启动顺序要确认一下：OpenCore 镜像第一，macOS 系统盘第二。如果 OpenCore 没有出现在启动设备里，手动指定启动设备也可以。

3.3 这一步为什么要先跑通

很多人不理解为啥要先装一遍不带 GPU 的 macOS。原因很简单：OSX-KVM 的 GPU 直通配置是在已有可启动 macOS 的基础上叠加的，不是一开始就把显卡直通过去。先跑通基础系统意味着你排除了 CPU、内存、磁盘、网络、引导镜像这些因素。等出现问题时，你就能定位到是显卡直通的配置问题，而不是整个虚拟机的搭建问题。

基础系统跑通后，我建议先做一个虚拟机快照。快照可以在 virt-manager 里做，也可以在命令行里做：

virsh snapshot-create-as macos-snapshot --name "base-installed" --description "macOS installed without GPU passthrough"

快照的意义不是让你偷懒，而是给后续 GPU 直通实验一个安全的回滚点。直通配置改错了，几分钟就能恢复原状，不用重装 macOS。

4. GPU 直通配置：把物理显卡彻底交给 macOS

4.1 先检查 IOMMU 分组和显卡所在位置

GPU 直通的第一步，是确认显卡在独立的 IOMMU 组里，并且宿主机没有正在使用它。用下面命令查看 IOMMU 分组：

#!/bin/bash for d in /sys/kernel/iommu_groups/*/devices/*; do group=$(basename $(dirname $(dirname $d))) device=$(basename $d) echo "IOMMU group $group: $device $(lspci -nns $device)" done

重点看目标显卡的 IOMMU 组里，除了显卡本体和它的音频设备之外，有没有网卡、NVMe 控制器之类的功能设备。如果整张显卡和它的 HDMI/DP 音频在一个组里，那还好。如果和宿主机其他设备混在一个组里，直通时会遇到麻烦，因为整个组都必须从宿主机解绑。

还需要确认宿主机没有加载 Nvidia 或 AMDGPU 驱动去占用这张显卡。最好的办法是启动时把它绑定到 vfio-pci 驱动，让宿主机一开机就不碰它。

4.2 用 vfio-pci 隔离显卡

在 Linux 内核启动参数里加上下面内容，可以把显卡直接隔离出来：

intel_iommu=on iommu=pt vfio-pci.ids=1002:67df,1002:aaf0

AMD 平台通常这样加：

amd_iommu=on iommu=pt vfio-pci.ids=1002:67df,1002:aaf0

这里的 1002:67df 是一张 RX 580 的 PCI ID，1002:aaf0 是它的音频设备 ID。具体 ID 用 lspci -nn 查看。配置好之后，重启宿主机，然后用 lspci -k 确认显卡已经挂在 vfio-pci 驱动下。

如果不想改内核启动参数，也可以用一个 modprobe 配置文件。两种方式选一种就行。这里我更推荐内核参数，因为它的时序更早，不容易出现显卡先被 AMDGPU 驱动占用、再解绑失败的竞态。

4.3 修改虚拟机 XML 添加 PCI 设备

用 virsh edit 或 virt-manager 打开虚拟机 XML，在 devices 部分添加 PCI 设备：

<hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </hostdev>

address 的 domain、bus、slot、function 要根据宿主机 lspci 输出填。添加完显卡本体，如果还想让 HDMI/DP 音频设备一起工作，可以把音频设备也加进去。managed='yes' 表示 libvirt 会自动做 vfio-pci 绑定和解绑，省去手动脚本。

4.4 常见启动参数和 OpenCore 兼容注意事项

macOS 对 QEMU/KVM 环境有一个额外的硬件检测机制，OSX-KVM 项目通常会在 QEMU 参数或 libvirt XML 里加入一些伪造 SMBIOS 和引导参数。不同 CPU 平台需要的参数也不完全一样：

• Intel 平台可能要加 -cpu host,vmware-cpuid-freq=false 或类似的 CPU 掩码参数。
• AMD 平台在安装时需要在 OpenCore config 里设置 Kernel 相关的 Quirk，特别是 ProvideCurrentCpuInfo。
• 如果启动后 macOS 一直卡在苹果标志或进度条，先检查 CPU 相关的 Quirk，不要急着怀疑显卡。

这里容易被忽略的是：GPU 直通后，VNC/SPICE 显示就不再有画面输出了，虚拟机窗口一片黑是正常现象。你要把显示器接到直通显卡上，或者让显卡的 HDMI/DP 输出接一个采集卡、显示器、或者支持 HDMI 输入的便携屏。很多人直通后在 virt-manager 窗口里看到黑屏，误以为失败，实际上 macOS 的画面已经走物理显卡输出了。

5. 进入系统后，如何确认 GPU 加速真的生效

5.1 system_profiler 是第一个判断依据

macOS 启动完成后，打开终端，运行：

system_profiler SPDisplaysDataType

重点看两行：

• Chipset Model 是否是直通显卡的型号，比如 AMD Radeon RX 580。
• Metal 是否显示 Supported。如果显示 “Metal: Supported”，说明图形加速正常。如果显示 7MB 或者只有 Display 输出、没有 Metal 支持，说明驱动没有正确加载。

还有一种情况是显示型号正确，但显存只有 7MB。这个经典问题通常意味着 macOS 没有加载 AMD 显卡驱动，或者 ACPI 表没有正确描述显卡的电源和 PCI 信息。解决办法多数在 OpenCore 的 DeviceProperties 和 ACPI patches 里，需要对照项目文档调整。

5.2 用 Metal 和 MPS 做真实负载验证

system_profiler 只是静态判断。真正要验证性能，我会用三类负载：

第一类是 Metal 基准测试。Geekbench 的 Metal 测试最直观，分数接近同型号物理 Mac 上的表现，代表加速链路正常。没有付费软件的话，也可以用 Unigine Valley，它带 Metal 后端，启动后能看到 GPU 名称和帧率。

第二类是 PyTorch 的 MPS 计算。如果系统里装了 PyTorch，用下面这段代码验证：

import torch if torch.backends.mps.is_available(): device = torch.device("mps") a = torch.randn(1024, 1024, device=device) b = torch.randn(1024, 1024, device=device) c = a @ b print("MPS calculation OK:", c.shape) else: print("MPS not available")

如果输出 MPS calculation OK，说明 PyTorch 能调用 GPU 做矩阵乘法。这不代表所有模型都能顺畅跑，但已经说明计算链路是通的。

第三类是 Ollama 或 llama.cpp 的 Metal 推理。安装 Ollama 后，在终端里执行：

ollama run qwen2.5:7b

然后随便提问，观察日志里是否出现 llama_model_load 相关字段和 Metal layers。Ollama 的 macOS 版本默认会尝试用 Metal 加速。如果日志里显示 GPU 显存被占用，说明推理走了显卡，而不是 CPU。

5.3 性能损耗的合理范围

GPU 直通后的性能损耗通常很小，但不等于零。影响最大的不是 QEMU 转发，而是 CPU 核心分配、内存带宽和 PCIe 通道布局。我观察到的情况是：

• 同型号 RX 580，在直通 macOS 里的 Metal 分数大约是物理 Mac 的 90% 到 95%。
• 同型号 RX 6600 XT，PCIe 4.0 x8 通道下，性能损耗在 5% 左右。
• 如果 CPU 核心分配不足，比如只给 4 核跑渲染任务，GPU 可能吃不满，因为 CPU 提交指令的能力不够。

所以判断性能时不要只看 GPU 型号，还要看整体资源分配。虚拟机给 8 核以上，内存 16GB 以上，直通显卡跑在 PCIe 3.0 x16 或 PCIe 4.0 x8 以上，通常体验最好。

6. 显卡不亮、系统重启、崩溃日志的排查顺序

6.1 先看启动阶段，再进系统看日志

GPU 直通出问题，最怕一上来改一堆参数。我的经验是先分阶段定位：

1. 宿主机启动后，目标显卡是否被 vfio-pci 绑定。如果没有绑定，虚拟机无法启动直通设备。
2. 虚拟机启动时，OpenCore 是否正常出现。如果 OpenCore 都没出现，说明引导配置或固件有问题，和显卡关系不大。
3. OpenCore 加载完，macOS 内核是否开始打印日志。如果卡在黑屏，考虑显卡 ROM 和 ACPI 兼容问题。
4. 系统能否登录到桌面。如果能登录，但显示 7MB 显存，再看驱动和 DeviceProperties。
5. 如果跑负载时死机或重启，再看电源管理和 PCIe 电源状态。

不要跳过第一步。很多人改了 XML，结果宿主机显卡还被 AMDGPU 驱动占着，虚拟机的 PCI 设备根本加不进去，连启动都会报错。这种情况属于资源冲突，不是 macOS 配置问题。

6.2 黑屏和循环重启的常见原因

黑屏基本可以分成两类：一类是 OpenCore 阶段黑屏，另一类是 macOS 内核加载后黑屏。

OpenCore 阶段黑屏，通常是显卡输出没有被 UEFI GOP 初始化。解决办法是给虚拟机加一个虚拟显示设备，例如 QXL 或 VGA，让 OpenCore 走虚拟显示输出，macOS 内核启动后再切换到物理显卡。这种折中能让引导阶段可见，虽然不是最完美的方案，但调试很方便。

macOS 内核加载后黑屏，更多是显卡驱动、电源管理、或者 framebuffer 配置的问题。比如部分 AMD 显卡需要注入特定接口的通道顺序，否则系统认为显示器没插好，就不输出画面。这个修改要在 OpenCore 的 DeviceProperties 里加显卡属性，具体值依赖显卡型号和接口类型。

循环重启则常见于 CPU Quirk 配置不对。OSX-KVM 在 AMD 平台多为明显，虚拟机重启到一半，然后再次重启，循环几次后进入恢复模式。这种情况先回退 GPU 直通，只保留虚拟显卡，确认系统还能正常启动，然后再把 Quirk 调对。

6.3 “gpu crash dump triggered”这类日志怎么看

如果你在 macOS 日志或崩溃报告里看到类似 gpu crash dump triggered 的表述，先别当成显卡物理损坏。这通常是显卡驱动遇到无法恢复的错误后生成的转储信息。可能原因有：

• 显卡被直通后，ACPI 电源状态切换失败。
• OpenCore 注入的设备属性不正确。
• 显卡固件版本和 macOS 驱动不兼容。

正确的处理顺序是：先查看完整崩溃日志，找到是哪个用户进程触发的；再在 OpenCore 里调整 GPU 相关属性，比如去掉部分注入项；最后考虑换一张社区配合度更高的显卡。绝大多数情况下，gpu crash dump triggered 都是软件配置的锅，而不是硬件坏了。

7. 不同显卡在 OSX-KVM 下的兼容边界

7.1 AMD 显卡是主力，但不是每张都完美

根据社区反馈和我的测试，AMD 显卡的兼容度明显高于 NVIDIA，但也不是所有 AMD 显卡都无脑可用：

这里说的兼容性，不是说不能显示，而是“能不能在 macOS 下完整发挥 GPU 能力”。NVIDIA 显卡即使能显示，往往也拿不到 Metal 加速，这和没有 GPU 直通区别不大。

7.2 显卡直通和显存的关系

macOS 的显存识别逻辑和 Windows 不一样。AMD 显卡在原生 Mac 上通过驱动读取显存容量，直通后也应该如此。但如果看到 7MB，基本是驱动没有加载成功。需要注意的另一个点是显存虚拟地址映射：

• 显卡显存越大，占用的物理地址空间也越大，Above 4G Decoding 和 PCIe ACS 设置就越重要。
• 8GB 显存级别的显卡通常没问题，16GB 显卡需要确认主板 PWM 和内存映射能力，否则启动阶段可能直接崩溃。
• 如果直通后 macOS 显示显卡型号，但应用里报显存不足，先看宿主机是不是没有开启大页内存或 vfio 的 allow_unsafe_interrupts 选项。

这个场景下，给虚拟机预留的内存不要太小。8GB 显存的显卡，最好给虚拟机分配 16GB 以上内存，否则显卡和系统应用争内存，性能会明显下降。

7.3 低配置机器能不能跑

很多人在普通台式机上尝试 OSX-KVM，CPU 只有 4 核 8 线程，内存 16GB。这种配置能跑，但有两个明显瓶颈：

• 启动安装阶段很慢，可能需要半小时以上才能进到装系统界面。
• 直通后如果同时跑 macOS 和宿主机 Linux，内存会非常紧张，建议把 macOS 虚拟机设置为 8GB 内存，宿主机再留 6GB 左右。
• CPU 核心分配建议 4 核起步，少于 4 核会让 GPU 提交引擎吃不满，Metal 性能打折。

低配置环境下，建议先关掉宿主机的桌面环境，用命令行 + libvirt 管理虚拟机，把资源尽量留给 macOS。这样虽然牺牲了宿主机图形，但 macOS 的可用性会明显提升。

8. 从单机测试到长期使用的几个现实建议

8.1 单任务跑稳定之后，再考虑批量任务和接口化

OSX-KVM 的 GPU 直通搭建起来之后，很多人的下一步是批量跑任务。比如用 Jenkins 或 GitLab CI 自动创建 macOS 虚拟机，跑 iOS 编译；或者用 Python 定时调用 PyTorch MPS 做推理。

批量使用前要先处理几件事：

• 定义清晰的虚拟机命名和快照机制，每次任务后回滚到初始状态。
• 输出目录要独立，避免多个任务写同一个路径。
• 失败重试要有日志可查，不能只靠 GUI 截图。
• 如果多个虚拟机共享同一张物理显卡，这基本不可行。GPU 直通是独占设备，一个 macOS 虚拟机用了，其他虚拟机就不能再用。批量任务要么用多张显卡，要么排队执行。

8.2 长期使用时，最该盯住的是备份和系统更新

macOS 系统更新对 OSX-KVM 用户来说，风险和收益并存。更新可能带来新特性，也可能让 OpenCore 配置失效，甚至让显卡驱动崩溃。我的习惯是：

• 系统更新前，先看 OSX-KVM 项目仓库的 issue，确认社区有没有报出破坏性问题。
• 更新前做一次虚拟机快照或整盘备份。
• 更新后如果发现 GPU 直通失效，优先回退快照，而不是花几小时调 OpenCore。

备份方案上，建议用 virt-manager 的快照配合磁盘镜像文件复制。快照适合短时间内调试回滚，镜像复制适合长期存档。磁盘镜像放在 SSD 上，复制几百 GB 的文件也就十几分钟，但能省掉重装系统的大把时间。

8.3 什么情况下不应该用 OSX-KVM

虽然 OSX-KVM 很强大，但要诚实说：它不适合所有场景。如果你的目标只是偶尔跑一个 macOS 小程序，对图形性能没有要求，那么普通 QEMU 虚拟显卡就够了，不需要承受 GPU 直通的复杂度。

如果你需要稳定的生产环境，且有预算，直接买一台 Mac mini 或 Mac Studio 更省心。OSX-KVM 的宿主机更新、内核参数调整、OpenCore 维护都需要持续投入，不是装完就一劳永逸的。

如果你手头只有 NVIDIA 显卡，又必须要跑 Metal 计算，那 OSX-KVM 大概率帮不了你。这种情况下，绕开虚拟化，直接用支持 CUDA 的 Linux 虚拟机配合 GPU 直通，反而更符合需求。

8.4 我最终建议的执行顺序

回到开头那句话：OSX-KVM 加 GPU 直通，价值在于让虚拟机里的 macOS 拥有接近原生显卡的能力。但想稳定落地，不要跳步。我给你一个可以直接照做的顺序：

1. 先确认硬件支持 IOMMU，BIOS 开启 VT-d / AMD-Vi 和 Above 4G Decoding。
2. 用虚拟显卡把 macOS 装好，跑一遍基础功能。
3. 用快照保存初始状态。
4. 隔离物理显卡到 vfio-pci，修改虚拟机 XML，添加 PCI 设备。
5. 把显示器接到直通显卡上，确认 macOS 启动到桌面。
6. 用 system_profiler 和 Metal 测试确认加速生效。
7. 实测 PyTorch MPS 或 Ollama，验证真实负载。
8. 一切稳定后，再做快照、备份、批量任务规划。

这条路每一步都有明确的判断标准，而且每多走一步，都是在前一步没有问题的基础上推进的。这样踩坑会少很多，即使出了问题，也知道该回退到哪一步，而不是抓着一堆参数乱试。