一台 AI MAX+ 395，如果只用来运行大模型，往往还会留下不少 CPU 余量。我的使用方式是：把 Radeon 8060S 直通给专门运行大模型的 Fedora 44 虚拟机，同时开 Windows 处理日常工作，再开 Ubuntu 做开发和后台任务。

这样，GPU 负责主要的推理计算，CPU 可以承担其他系统的任务，整台机器的利用率也更高。AI 环境独立放在虚拟机里，驱动、推理引擎和依赖可以单独维护，减少不同工作环境之间的干扰。

当然，“跑大模型时 CPU 基本没怎么用”有适用条件。在主要计算交给 GPU、并发不高的情况下，CPU 通常还有余量；模型加载、分词、数据准备、CPU offload 和高并发请求仍会消耗 CPU。CPU 和 GPU 还共享物理内存、带宽和整机功耗，因此目标是合理利用资源，而不是不加限制地开启更多任务。

Fedora 独占 8060S 运行大模型，Windows 和 Ubuntu 使用各自分配的 CPU 与内存。三套系统并行运行，但不会同时共享这张直通显卡。

下面按实际操作顺序，说明每一步的目的、检查方法，以及怎样从命令行输出判断结果。

第一步：从官网下载并安装 PVE 9.2，验证版本

先安装 PVE，作为管理 Fedora、Windows 和 Ubuntu 虚拟机的宿主系统。本方案使用 PVE 9.2，显卡驱动和大模型运行在后续创建的 Fedora 44 虚拟机中。

从 PVE 官方下载页面 获取 Proxmox VE 9.2 ISO Installer，制作启动盘后安装。安装时确认目标磁盘，完成管理网络配置，再进入 PVE 管理界面。

**这里建议直接使用 PVE 9.2。**我此前使用 PVE 9.1 时，其较旧的内核在这台机器上存在网卡兼容性问题，使用过程中经常出现网卡掉线。换用 PVE 9.2 和较新的内核后，目前网络运行正常，没有再遇到此前频繁掉网卡的情况。这个问题与具体网卡、驱动和内核组合有关，是本机选择新版本的实际原因，并不意味着所有运行 PVE 9.1 的机器都会掉网卡。

安装完成后，在 PVE 终端验证系统版本和当前运行的内核：

pveversion
uname -r

本方案的版本检查结果为：

pve-manager/9.2.2/… (running kernel: 7.0.2-6-pve)

内核检查结果为：

7.0.2-6-pve

pve-manager/9.2.2 表明系统处于 PVE 9.2 系列，uname -r 则确认当前实际运行的内核。后续更新可能带来不同的补丁版本和内核版本，不要求与这里的完整版本号逐字一致。更新内核后需要重启宿主，才能运行新内核；仅安装更新包，不代表新内核已经生效。

网络方面，除了确认管理界面可访问，还应在日常使用和持续传输过程中观察连接是否稳定。出现异常时，可以检查网卡驱动和当前启动周期的内核日志：

lspci -nnk | rg -A 3 -i 'Ethernet controller|Network controller'
journalctl -k -b | rg -i 'link.*down|link.*up|NETDEV WATCHDOG|tx timeout|reset'

重点关注是否反复出现链路断开、发送超时或设备重置。一次插拔网线也可能产生链路变化日志，应结合实际掉线时间判断，不能仅凭单条日志认定驱动故障。

确认 PVE 版本和网络正常后，再准备设备直通。在 BIOS 中开启 CPU 虚拟化和 IOMMU，两者的作用分别是：

• CPU 虚拟化：让虚拟机高效运行操作系统和应用程序。
• IOMMU：约束设备直接访问内存的范围，为设备直通提供必要的隔离基础。

启动 PVE 后检查相关日志：

journalctl -k -b | rg -i 'AMD-Vi|IOMMU'

这些日志需要与下一步的 IOMMU 分组一起检查，确认设备具备直通所需的隔离条件，再继续配置显卡。

第二步：识别显卡与 IOMMU 分组，确定交出哪些设备

显卡直通交出的是具体 PCI 设备。先在 PVE 中枚举设备，识别 Radeon 8060S 和相关音频功能：

lspci -nn

找到目标设备后，再按地址查看详细信息。以下变量中的地址应来自自己的枚举结果：

GPU_BDF='替换为宿主上的目标显卡地址'
lspci -nnk -s "$GPU_BDF"

设备信息中的关键字段为：

Strix Halo [Radeon Graphics / Radeon 8050S Graphics / Radeon 8060S Graphics]
[1002:1586]

1002:1586 是设备的厂商与型号标识，可用来核对目标 GPU。较长的系列名称来自 PCI 设备数据库，后面还要结合客体驱动和 Vulkan 输出确认实际设备。

接着在 PVE 的 PCI 设备界面检查 IOMMU 分组。IOMMU 组是设备隔离的重要边界：如果目标设备与宿主管理网卡、系统盘等必要设备处在同一组，就不能只凭“界面允许勾选”直接认定适合直通。

这套配置将 GPU、显示音频及另一相关音频功能交给客体。相关功能是否需要一并处理，要看目标机器的分组、复位依赖和实际验证结果，不能把别人的地址整套照搬。

完成这一步后，应明确目标 GPU、相关功能及其隔离边界，确认宿主需要的设备仍由宿主管理。

第三步：配置 VFIO，让宿主把显卡交给虚拟机

**VFIO 是 Linux 提供的设备直通框架。**它让 QEMU 等用户态虚拟化程序在设备隔离机制的配合下使用真实硬件，再将设备呈现给客体系统。

其中，vfio-pci 是负责接管 PCI 设备的驱动。它的任务不是替 Fedora 运行图形计算，而是让设备处于可交给虚拟机的状态。真正的 AMD 图形和计算驱动仍运行在 Fedora 内。

检查时要分别看宿主和客体：宿主由 vfio-pci 接管，客体由 amdgpu 使用硬件，这两个结果共同说明设备交接与驱动绑定已经到位。

本方案的配置思路是：

1. 确保 IOMMU 可用。
2. 让目标设备在启动时由 vfio-pci 接管。
3. 避免宿主 AMD 图形驱动或启动帧缓冲先占用设备。
4. 更新对应的启动配置和初始内存文件系统，在正常关闭虚拟机后重启宿主。

本方案涉及的两个启动参数为：

iommu=pt
initcall_blacklist=sysfb_init

iommu=pt 调整 IOMMU 的默认映射策略，不是显存容量参数，也不能替代对 IOMMU 是否启用的检查。initcall_blacklist=sysfb_init 阻止特定启动帧缓冲初始化，目的是减少宿主早期显示对设备的占用；是否采用，应结合宿主的显示和管理方式判断。

配置时只应处理目标设备。全局屏蔽 AMD 或音频驱动可能影响宿主上的其他同类硬件，不能无差别复制配置。

宿主重启后再次检查：

lspci -nnk -s "$GPU_BDF"

检查结果：

Kernel driver in use: vfio-pci
Kernel modules: amdgpu

如何判读：Kernel driver in use 表示当前真正绑定的驱动，这里是 vfio-pci，说明宿主已将显卡交给 VFIO。Kernel modules: amdgpu 只是在列出可支持该设备的模块，不代表显卡仍由 amdgpu 占用。

这一步的预期组合是：**宿主绑定 vfio-pci，后续 Fedora 客体绑定 amdgpu。**两边驱动名称不同，正是各自分工的体现。

第四步：创建 Fedora 44 虚拟机，选对虚拟硬件

在 PVE 中创建 Fedora 虚拟机时，本方案采用 UEFI、Q35 和 host CPU 类型。它们各有作用，不是单纯照着勾选的三个选项。

设置	作用及选择原因
UEFI / OVMF	OVMF 为虚拟机提供 UEFI 固件，负责启动操作系统，也为本方案的 UEFI 图形初始化提供运行环境。
Q35	提供较现代的虚拟芯片组及 PCIe 拓扑，适合组织本方案的 PCIe 直通设备。它不会自动解决所有驱动兼容问题。
CPU 类型 host	尽量向客体暴露宿主 CPU 的指令集和特性，有利于使用本机能力；相应地，跨不同 CPU 主机迁移时的兼容性需要另行考虑。
关闭 Ballooning	避免动态内存回收机制改变客体的可用内存，便于为模型及 GPU 相关内存分配建立稳定预算。
保留虚拟显示设备	方便通过 PVE 控制台安装、维护和排错；它与直通的 8060S 是两套显示设备。
启用 Guest Agent	方便宿主获取客体状态并进行正常关机等管理操作。它不负责显卡加速。

EFI 变量盘用于保存 UEFI 启动项等状态，不等于 Fedora 的系统盘。系统仍需要正常安装到虚拟磁盘上。

CPU、内存和磁盘先按安装及验证所需分配，完成基本验收后再按模型需求扩大。不要一开始就把宿主内存分完，也不要把虚拟磁盘的薄置备容量当成存储池的真实可写余量。

在 PVE 中检查关键配置：

VMID='替换为目标虚拟机编号'
qm config "$VMID" | rg '^(bios|machine|cpu|balloon|vga|agent):'

检查结果：

agent: enabled=1
balloon: 0
bios: ovmf
cpu: host
machine: pc-q35-11.0
vga: std

**如何判读：**这段输出确认实际配置已经采用上述组合。具体 Q35 版本受 PVE/QEMU 版本影响，不要求其他主机必须使用相同版本号；这些字段也只能证明配置到位，不能代替客体内的 GPU 功能验证。

第五步：挂载显卡，准备两份初始化文件并安装系统

正常关闭目标虚拟机，同时确认没有其他运行中的虚拟机占用同一张显卡，再添加目标 GPU 及本方案需要的相关功能。

这套方案还需要两份核心初始化文件：

• vbios_8060s.bin：为本方案提供 GPU 初始化所需的 VBIOS 内容。
• AMDGopDriver.rom：为本方案提供 UEFI 图形初始化支持。

两者配合使用，但作用并不相同。它们由虚拟化层提供给客体，不等于刷写主板 BIOS；也不能仅凭文件已准备好，就认定物理显示接口一定能出画面。

可以检查直通配置是否存在：

qm config "$VMID" | rg '^hostpci'

检查时，确认 GPU 和所需音频功能均有对应的 hostpci 条目，并核对 PCIe 接入选项与两份初始化文件的引用。

pcie=1 表示以 PCIe 方式接入；rombar=1 与 romfile 配合，为客体提供设备 ROM。具体分配方式属于这套方案的配置，不应理解成所有 AMD 设备的通用模板。

配置好后安装 Fedora 44，完成安装后移除安装介质，并从系统盘启动。在 Fedora 内检查：

findmnt -n -o FSTYPE /

检查结果：

btrfs

**如何判读：**这确认当前根文件系统类型；还要结合实际挂载来源、启动参数和安装介质状态，确认没有停留在 Live 环境。只看到 btrfs 不能独立证明已经从指定系统盘启动。

第六步：在 Fedora 内逐层验证显卡

先确认设备归属，再检查客体驱动、硬件接口和实际任务。前一层通过后，继续验证下一层，避免把“设备能识别”直接等同于“模型正在使用 GPU”。

Fedora 使用发行版提供的内核 amdgpu、AMD 固件和 Mesa 图形组件。Mesa 中的 RADV 提供 AMD Vulkan 驱动，内核驱动则负责底层设备与内存管理。

诊断工具可从发行版仓库安装：

sudo dnf install pciutils qemu-guest-agent nvtop vulkan-tools
sudo systemctl enable --now qemu-guest-agent

这里不需要安装 Windows 显卡驱动，也不能把面向其他 Linux 发行版的安装器直接套用到 Fedora。

先确认驱动已经接管设备

先通过 lspci -nn 找到客体中的显卡地址，再检查：

GUEST_GPU_BDF='替换为Fedora内的显卡地址'
lspci -nnk -s "$GUEST_GPU_BDF"

重点检查设备 ID 和驱动绑定：

[1002:1586]
Kernel driver in use: amdgpu
Kernel modules: amdgpu

**结论：**目标 AMD 设备已经呈现在 Fedora 内，并由 amdgpu 接管。宿主地址与客体地址不同属于正常现象，不能拿宿主地址直接在客体中查询后就认定设备丢失。

再确认硬件接口可用

vulkaninfo --summary

输出中的 AMD 硬件设备信息如下：

GPU0:
    apiVersion    = 1.4.335
    vendorID      = 0x1002
    deviceID      = 0x1586
    deviceType    = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
    deviceName    = Radeon 8060S Graphics (RADV STRIX_HALO)
    driverName    = radv
    driverInfo    = Mesa 26.0.3

**结论：**Vulkan 已枚举到 Radeon 8060S 硬件设备，RADV 用户态驱动也正常工作。这里显示集成 GPU，符合 8060S 的硬件形态；直通不会让它变成拥有独立物理显存的独立显卡。

如果还列出了 llvmpipe，不必立即判断失败。它是软件渲染设备，关键是实际应用选择了哪一个设备。Vulkan 枚举成功也不等于 ROCm、HIP 或 PyTorch 的所有版本都已兼容。

最后观察实际任务，而不只看设备列表

在 Fedora 中运行：

nvtop

让选定的图形或计算任务运行，观察进程、GPU 利用率及内存变化，并检查任务日志中的设备选择。若程序支持后端选择，应明确选择 AMD GPU。

空闲时 GPU 利用率为零正常；反过来，只看到设备名称也不能证明某个应用在使用 GPU。驱动绑定、硬件接口、实际负载是三个层次，应分别确认。短时间验证通过后，还应进一步观察持续运行和重启后的表现。

第七步：运行大模型，用健康检查和真实回答验收

选择支持该 GPU 的推理环境，再按模型需求规划内存。至少要考虑权重、上下文缓存、工作区和系统本身的开销；模型文件大小不等于完整运行峰值。

如果采用容器部署，可以先检查容器状态：

podman ps --format '{{.Status}}'

容器状态显示：

Up 3 days

**结论：**容器进程在核验时仍在运行。但容器没有退出，不代表模型已经加载完成，更不能独立证明推理可用。

下一步读取服务健康接口。MODEL_HEALTH_ENDPOINT 使用所部署服务的健康检查地址：

curl --fail --silent --show-error "$MODEL_HEALTH_ENDPOINT" | jq '{status, engine: {responds: .engine.responds}, busy, slots}'

提取健康状态和引擎响应字段，结果如下：

{
  "status": "ok",
  "engine": {
    "responds": true
  },
  "busy": false,
  "slots": 2
}

**结论：**核验时 API 返回正常状态，引擎能够响应；busy: false 表示当时没有忙碌请求，不是服务未启动。

最后再提交一条实际推理请求。对于兼容聊天补全接口的服务，可以使用下面的请求结构；接口、模型名称和鉴权方式按所用引擎配置：

curl --fail --silent --show-error "$MODEL_CHAT_ENDPOINT" \
  -H 'Content-Type: application/json' \
  --data "$(jq -n --arg model "$MODEL_NAME" '{
    model: $model,
    messages: [{role: "user", content: "请用一句中文确认你可以正常回答。"}],
    max_tokens: 64
  }')"

该示例需要 jq，用于可靠构造 JSON。请求中的模型名称是可配置项，实际回答也不应预设为某个固定文本。

此前一次短请求测试返回了以下结果：

{
  "choices": [
    {
      "finish_reason": "stop",
      "message": {
        "role": "assistant",
        "content": "你好，部署成功。"
      }
    }
  ],
  "usage": {
    "prompt_tokens": 21,
    "completion_tokens": 6,
    "total_tokens": 27
  }
}

**结论：**模型已经完成过实际请求并返回正常回答。确认 GPU 推理时，还应同时核对引擎后端、设备分配和运行时负载，因为回答 JSON 本身不会说明计算发生在 CPU 还是 GPU。

每次调整模型、驱动或资源配额后，都应重新检查服务健康、实际回答和 GPU 后端，确认新的配置仍然可用。

第八步：同时运行 Windows 和 Ubuntu，按瓶颈分配资源

显卡归 Fedora 独占后，Windows 和 Ubuntu 仍可使用分配到的 CPU、内存、虚拟磁盘和虚拟显示设备。它们可以通过控制台或远程桌面使用，但不会自动获得同一张 8060S 的加速能力。

在 PVE 中检查虚拟机状态：

qm list

检查列表中的 STATUS 列，三套系统均处于 running 状态：

系统	运行状态
Fedora / AI	running
Windows	running
Ubuntu	running

**结论：**这套配置能够同时运行 Fedora、Windows 和 Ubuntu。接下来需要结合实际任务，观察多系统并行工作时的性能与稳定性。

接着观察宿主与客体的内存、CPU 和交换活动：

free -m
vmstat 1 5

free 中优先结合 available 理解可用内存，不要只看 free。vmstat 第一行通常是自启动以来的平均值，后续行更适合观察当前变化；持续的换入换出、较高 I/O 等待或调度竞争，都可能影响推理延迟。

统一内存最容易算错的地方

8060S 与 CPU 共享物理内存，下面三个概念要分清：

名称	含义
UMA / 驱动报告的 VRAM	固件和驱动呈现给 GPU 的一部分内存资源，大小取决于具体配置。
虚拟机普通内存	PVE 分配给 Fedora 的系统内存配额，操作系统和模型运行时都要使用。
GTT	GPU 使用普通系统内存的一个内存域；它不代表机器多出了一份物理容量。

因此不能把“虚拟机内存 + GTT”直接作为两份独立容量相加，也不能只看某个 VRAM 数字判断直通是否成功。提高预算不一定能解决实际分配失败，还要看驱动、引擎使用的内存方式和整机余量。

对于锁定或 GPU 注册的内存，普通可回收缓存指标也可能不足以反映真实余量，应结合引擎日志和实际分配情况判断。

CPU 有余量，也要给推理留出空间

分配 vCPU 不等于为虚拟机永久独占同等数量的物理核心。多个系统的任务会竞争调度时间；后台编译即使不使用 GPU，也可能通过内存带宽和整机功耗影响推理。

比较稳妥的调整方式是：先只运行 Fedora 完成推理验收，再依次开启 Windows、Ubuntu，逐步增加实际任务，比较同类请求的延迟和生成速度。

如果模型响应明显变慢，优先检查内存压力、交换活动和 CPU 竞争，再决定减少其他任务、调整模型上下文或修改虚拟机资源。宿主始终需要保留余量，避免把全部资源分给客体。

完成后的检查清单

检查项	输出能说明什么
宿主显示 vfio-pci	目标设备已交给直通框架。
Fedora 显示 amdgpu	客体已识别目标设备并绑定驱动。
Vulkan 显示 Radeon 8060S / RADV	客体图形接口能够枚举真实 AMD GPU。
服务健康检查正常	对应接口及引擎在检查时能够响应。
实际请求返回回答	模型完成了一次推理，还需结合后端信息确认执行设备。
多台虚拟机显示 running	多系统能够同时运行，性能表现需要按实际任务测量。

物理 HDMI/DP 输出、客体关机再启动、宿主重启以及长期负载稳定性，分别属于额外验收项目。把每一层检查清楚，才能在独立运行 AI 服务的同时，放心把剩余资源用于 Windows 和 Ubuntu 的其他工作。