一、目前我们大部分人的算例底座都是性能过剩的，即使是X99这种老东西切了一半的cpu资源也没有任何影响，切几个核心几个G的内存百十来G的硬盘几乎没啥感觉，所以在虚拟机和直通的基础上，我们可以分裂出若干个虚拟机，用来跑agent，即避免了资源浪费噪音污染，也减少了资金投入，不然还要再找一台电脑去架设个agent。

二、对提高系统的稳定性和可用性帮助也很大，pve虚拟机可以提供非常方便的冷热备份，只要有个大硬盘或者nas，对于喜欢折腾的人来说，只要及时备份虚拟机，一个系统可以在几分钟之内迅速的完全恢复。

三、虚拟机是可以迁移的，如同备份。

更新一下最新的使用速度情况,用的是Hermes agent

一、最终成果

在 PVE 虚拟机中直通单张 RX 7900 XTX，跑 Qwen3.8-27B Q4_K_M：

去审查版的 MTP 头是完整的第 65 层（含 attention + FFN），比 unsloth UD 版（只有 4 个 nextn.* 投影张量）猜得更准，decode 快约 16%。

二、硬件与软件环境

三、编译 llama.cpp

sudo apt update
sudo apt install -y git build-essential cmake libvulkan-dev glslc spirv-headers

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release -j$(nproc)

注意：spirv-headers 是较新版本新增的强制依赖，旧教程不会提到。缺它会在 CMake 配置阶段报 Could not find SPIRV-Headers。

验证 Vulkan 设备：

./build/bin/llama-cli --list-devices
# 应输出：Vulkan0: AMD Radeon RX 7900 XTX (RADV NAVI31) (24576 MiB, 23624 MiB free)

四、权限配置（PVE 直通必做）

/dev/dri/renderD128 属于 root:render，普通用户默认无权限访问。这会导致 Vulkan 报 Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)。

sudo usermod -aG render,video $USER

关键：加组后必须完全退出 SSH 会话重新登录，组权限才生效。验证：

groups
# 应包含 render 和 video
vulkaninfo --summary | grep -A5 "GPU0"
# 应显示 AMD Radeon RX 7900 XTX (RADV NAVI31)

五、下载模型

pipx install "huggingface_hub[cli]"
# 新版命令是 hf，不是 huggingface-cli

# unsloth UD 版
hf download unsloth/Qwen3.8-27B-GGUF \
  --include "*Q4_K_M*" \
  --local-dir ~/llama.cpp

# 去审查版（推荐）
# 从社区仓库下载 Qwen3.8-27B-Uncensored-Q4_K_M.gguf + mmproj

下载不稳定时可用 hfd.sh（基于 aria2c，支持断点续传）。

六、核心调参过程与实测数据

6.1 初始配置（失败）

--ctx-size 65536 --cache-type-k q8_0 --cache-type-v q8_0 \
--spec-type draft-mtp,ngram-map-k4v --spec-draft-n-max 3

结果：decode 13.12 t/s，接受率 0.490。

问题：--spec-ngram-map-k4v 在 Vulkan 后端产生巨大开销，反而拖慢。

6.2 去掉 n-gram（改善但仍有断崖）

--ctx-size 8192 --cache-type-k q8_0 --cache-type-v q8_0 \
--spec-type draft-mtp --spec-draft-n-max 3

结果：decode 51.67 t/s，接受率 0.449。

但 ctx 提到 16384/32768/65536/98304 后，全部掉到 9–14 t/s。

6.3 定位断崖

断崖在 8192 和 16384 之间。

6.4 第一次修复尝试：改 KV 量化

--ctx-size 16384 --cache-type-k q8_0 --cache-type-v q4_1 \
--ctx-checkpoints 2 --spec-draft-n-max 5

结果：decode 46.08 t/s，接受率 0.439。

V 从 q8_0 降到 q4_1 后，16384 的断崖消失。但 ctx 提到 65536/98304 后仍掉回 10–13 t/s。

6.5 根因定位：256M BAR

lspci -v -s 01:00.0 | grep -i "size="
# Memory at 380000000000 (64-bit, prefetchable) [size=256M]

PVE 直通环境下 BAR 只有 256M，ReBAR 未生效。

llama.cpp 的 Vulkan 后端默认尝试使用这 256MB 的主机可见窗口。ctx 增大后，KV cache 和计算 buffer 装不下，被迫走碎片化的低效路径，decode 断崖。

6.6 最终修复：禁用 host visible VRAM

export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1

让 Vulkan 后端完全放弃 256MB 窗口，所有 buffer 直接分配到设备本地 VRAM。

结果：98304 ctx 下 decode 41.25 t/s，prefill 199.38 t/s，断崖彻底解决。

6.7 换用去审查版（进一步提升）

去审查版的 blk.64 是一个完整的 Transformer 层（含 attn_q/k/v/output + ffn_gate/down/up + nextn 投影头），而 unsloth UD 版只有 4 个 nextn.* 张量。

MTP 头的完整程度直接影响投机解码的收益，这是论坛里很少有人提到的一点。

七、最终可用配置

脚本一：unsloth UD 版（+ mmproj）

#!/bin/bash
# ~/start-llama-unsloth.sh

export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1

cd /home/kby/llama.cpp
exec ./build/bin/llama-server \
  -m /home/kby/llama.cpp/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf \
  --mmproj /home/kby/llama.cpp/Qwen3.8/mmproj-Qwen3.8-27B-Uncensored-F16.gguf \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \
  -ngl 99 \
  --parallel 1 \
  --ctx-size 98304 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q4_1 \
  --ctx-checkpoints 2 \
  --spec-type draft-mtp \
  --spec-draft-n-max 5 \
  --cache-ram 32768 \
  --jinja

脚本二：去审查版（+ mmproj，推荐）

#!/bin/bash
# ~/start-llama-uncensored.sh

export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1

cd /home/kby/llama.cpp
exec ./build/bin/llama-server \
  -m /home/kby/llama.cpp/Qwen3.8/Qwen3.8-27B-Uncensored-Q4_K_M.gguf \
  --mmproj /home/kby/llama.cpp/Qwen3.8/mmproj-Qwen3.8-27B-Uncensored-F16.gguf \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \
  -ngl 99 \
  --parallel 1 \
  --ctx-size 98304 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q4_1 \
  --ctx-checkpoints 2 \
  --spec-type draft-mtp \
  --spec-draft-n-max 5 \
  --cache-ram 32768 \
  --jinja

创建命令

# unsloth UD 版
cat > ~/start-llama-unsloth.sh << 'EOF'
#!/bin/bash
export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1
cd /home/kby/llama.cpp
exec ./build/bin/llama-server \
  -m /home/kby/llama.cpp/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf \
  --mmproj /home/kby/llama.cpp/Qwen3.8/mmproj-Qwen3.8-27B-Uncensored-F16.gguf \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \
  -ngl 99 \
  --parallel 1 \
  --ctx-size 98304 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q4_1 \
  --ctx-checkpoints 2 \
  --spec-type draft-mtp \
  --spec-draft-n-max 5 \
  --cache-ram 32768 \
  --jinja
EOF

# 去审查版
cat > ~/start-llama-uncensored.sh << 'EOF'
#!/bin/bash
export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1
cd /home/kby/llama.cpp
exec ./build/bin/llama-server \
  -m /home/kby/llama.cpp/Qwen3.8/Qwen3.8-27B-Uncensored-Q4_K_M.gguf \
  --mmproj /home/kby/llama.cpp/Qwen3.8/mmproj-Qwen3.8-27B-Uncensored-F16.gguf \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \
  -ngl 99 \
  --parallel 1 \
  --ctx-size 98304 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q4_1 \
  --ctx-checkpoints 2 \
  --spec-type draft-mtp \
  --spec-draft-n-max 5 \
  --cache-ram 32768 \
  --jinja
EOF

chmod +x ~/start-llama-unsloth.sh ~/start-llama-uncensored.sh

使用

~/start-llama-uncensored.sh    # 推荐
# 或
~/start-llama-unsloth.sh

后台运行：

nohup ~/start-llama-uncensored.sh > ~/llama-server.log 2>&1 &

八、参数说明

九、性能对比总表

配置	ctx	KV	n_max	decode	接受率	判定
MTP+ngram	65536	q8_0/q8_0	3	13.12	0.490	ngram 拖慢
纯 MTP	8192	q8_0/q8_0	3	51.67	0.449
纯 MTP	16384	q8_0/q8_0	3	14.18	0.551	断崖
纯 MTP	32768	q8_0/q8_0	3	14.47	0.570	断崖
纯 MTP	98304	q8_0/q8_0	3	11–15	—	断崖
纯 MTP	16384	q8_0/q4_1	5	46.08	0.439	断崖消失
纯 MTP	98304	q8_0/q4_1	5	11.04	0.377	仍断崖
最终（unsloth）	98304	q8_0/q4_1	5	41.25	0.345	禁用 host VRAM
最终（去审查）	98304	q8_0/q4_1	5	47.95	0.420	推荐

十、踩坑清单

十一、关键经验

1. PVE 直通下 ReBAR 通常不生效，BAR 只有 256M。GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 是必加项，不是可选项。
2. Vulkan 后端的 ngram-map-k4v 在 RDNA3 上表现异常，社区在 ROCm/HIP 下的收益无法复现，建议只用 draft-mtp。
3. KV 量化不对称是正解：K q8_0 / V q4_1。K 决定注意力方向，敏感；V 是加权平均，容忍度高。
4. 断崖是确定性的，不是脏状态。冷启动、子分配修复都无效，只有禁用 host visible VRAM 才解决。
5. 测速必须固定内容类型。代码生成接受率高（0.4–0.6），散文接受率低（0.3），同一配置速度可差 2–3 倍。
6. MTP 头的完整程度直接影响投机解码收益。去审查版的 blk.64 是完整 Transformer 层，接受率 0.420；unsloth UD 版只有 4 个投影张量，接受率 0.345。
7. mmproj 会额外占约 900MB 显存。加载后如果 98K 上下文触发 OOM，降到 64K。

十二、附录：验证命令

# 确认 Vulkan 设备可见
vulkaninfo --summary | grep -A10 "GPU0"

# 确认 BAR 大小
lspci -v -s 01:00.0 | grep -i "size="

# 确认用户组
groups

# 确认 llama.cpp 链接了 Vulkan
ldd build/bin/llama-server | grep -i vulkan

# 确认 GGUF 有 MTP 层
./build/bin/llama-gguf Qwen3.8/Qwen3.8-27B-Uncensored-Q4_K_M.gguf r 2>&1 | grep -iE "blk\.64|nextn" | head -20

测试日期：2026-09-18 ～ 2026-09-19
环境：PVE + Ubuntu 24.04 + RX 7900 XTX 直通 + llama.cpp build 11037 + Mesa 25.2.8
所有数据均为同一台机器实测，含失败组合。

补图，自己动手翻新了旧机箱，上岁数了吧，非常喜欢这种老情人回到18个感觉……

先说结论，PVE下X99加7900xtx基本可用，40tokens加98k上下文。与物理安装差距不大。另外大模型与基础平台的性能关系也没有预想那么大，物理配置切一半的情况下效果没有太大弱化。算是达到了购买目标。
配置如下：

另外发现一个很迷的问题……见图。

一、最终成果

在 PVE 虚拟机中直通单张 RX 7900 XTX，跑 Qwen3.8-27B Q4_K_M：

二、硬件与软件环境

三、编译 llama.cpp

sudo apt update
sudo apt install -y git build-essential cmake libvulkan-dev glslc spirv-headers

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release -j$(nproc)

注意：spirv-headers 是较新版本新增的强制依赖，旧教程不会提到。缺它会在 CMake 配置阶段报 Could not find SPIRV-Headers。

验证 Vulkan 设备：

./build/bin/llama-cli --list-devices
# 应输出：Vulkan0: AMD Radeon RX 7900 XTX (RADV NAVI31) (24576 MiB, 23624 MiB free)

四、权限配置（PVE 直通必做）

/dev/dri/renderD128 属于 root:render，普通用户默认无权限访问。这会导致 Vulkan 报 Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)。

sudo usermod -aG render,video $USER

关键：加组后必须完全退出 SSH 会话重新登录，组权限才生效。验证：

groups
# 应包含 render 和 video
vulkaninfo --summary | grep -A5 "GPU0"
# 应显示 AMD Radeon RX 7900 XTX (RADV NAVI31)

五、下载模型

pipx install "huggingface_hub[cli]"
# 新版命令是 hf，不是 huggingface-cli

hf download unsloth/Qwen3.8-27B-GGUF \
  --include "*Q4_K_M*" \
  --local-dir ~/models

下载不稳定时可用 hfd.sh（基于 aria2c，支持断点续传）。

六、核心调参过程与实测数据

6.1 初始配置（失败）

--ctx-size 65536 --cache-type-k q8_0 --cache-type-v q8_0 \
--spec-type draft-mtp,ngram-map-k4v --spec-draft-n-max 3

结果：decode 13.12 t/s，接受率 0.490。

问题：--spec-ngram-map-k4v 在 Vulkan 后端产生巨大开销，反而拖慢。

6.2 去掉 n-gram（改善但仍有断崖）

--ctx-size 8192 --cache-type-k q8_0 --cache-type-v q8_0 \
--spec-type draft-mtp --spec-draft-n-max 3

结果：decode 51.67 t/s，接受率 0.449。

但 ctx 提到 16384/32768/65536/98304 后，全部掉到 9–14 t/s。

6.3 定位断崖

断崖在 8192 和 16384 之间。

6.4 第一次修复尝试：改 KV 量化

--ctx-size 16384 --cache-type-k q8_0 --cache-type-v q4_1 \
--ctx-checkpoints 2 --spec-draft-n-max 5

结果：decode 46.08 t/s，接受率 0.439。

V 从 q8_0 降到 q4_1 后，16384 的断崖消失。但 ctx 提到 65536/98304 后仍掉回 10–13 t/s。

6.5 根因定位：256M BAR

lspci -v -s 01:00.0 | grep -i "size="
# Memory at 380000000000 (64-bit, prefetchable) [size=256M]

PVE 直通环境下 BAR 只有 256M，ReBAR 未生效。

llama.cpp 的 Vulkan 后端默认尝试使用这 256MB 的主机可见窗口。ctx 增大后，KV cache 和计算 buffer 装不下，被迫走碎片化的低效路径，decode 断崖。

6.6 最终修复：禁用 host visible VRAM

export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1

让 Vulkan 后端完全放弃 256MB 窗口，所有 buffer 直接分配到设备本地 VRAM。

结果：98304 ctx 下 decode 41.25 t/s，prefill 199.38 t/s，断崖彻底解决。

七、最终可用配置

#!/bin/bash
# ~/start-llama.sh

export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1

cd /home/kby/llama.cpp
exec ./build/bin/llama-server \
  -m /home/kby/llama.cpp/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \
  -ngl 99 \
  --parallel 1 \
  --ctx-size 98304 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q4_1 \
  --ctx-checkpoints 2 \
  --spec-type draft-mtp \
  --spec-draft-n-max 5 \
  --cache-ram 32768 \
  --jinja

chmod +x ~/start-llama.sh

后台运行：

nohup ~/start-llama.sh > ~/llama-server.log 2>&1 &

八、参数说明

九、性能对比总表

配置	ctx	KV	n_max	decode	接受率	判定
MTP+ngram	65536	q8_0/q8_0	3	13.12	0.490	ngram 拖慢
纯 MTP	8192	q8_0/q8_0	3	51.67	0.449
纯 MTP	16384	q8_0/q8_0	3	14.18	0.551	断崖
纯 MTP	32768	q8_0/q8_0	3	14.47	0.570	断崖
纯 MTP	98304	q8_0/q8_0	3	11–15	—	断崖
纯 MTP	16384	q8_0/q4_1	5	46.08	0.439	断崖消失
纯 MTP	98304	q8_0/q4_1	5	11.04	0.377	仍断崖
最终	98304	q8_0/q4_1	5	41.25	0.345	禁用 host VRAM 后

十、踩坑清单

十一、关键经验

1. PVE 直通下 ReBAR 通常不生效，BAR 只有 256M。GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 是必加项，不是可选项。
2. Vulkan 后端的 ngram-map-k4v 在 RDNA3 上表现异常，社区在 ROCm/HIP 下的收益无法复现，建议只用 draft-mtp。
3. KV 量化不对称是正解：K q8_0 / V q4_1。K 决定注意力方向，敏感；V 是加权平均，容忍度高。
4. 断崖是确定性的，不是脏状态。冷启动、子分配修复都无效，只有禁用 host visible VRAM 才解决。
5. 测速必须固定内容类型。代码生成接受率高（0.4–0.6），散文接受率低（0.3），同一配置速度可差 2–3 倍。

十二、附录：Vulkan 设备识别验证

# 确认 Vulkan 设备可见
vulkaninfo --summary | grep -A10 "GPU0"

# 确认 BAR 大小
lspci -v -s 01:00.0 | grep -i "size="

# 确认用户组
groups

# 确认 llama.cpp 链接了 Vulkan
ldd build/bin/llama-server | grep -i vulkan

测试日期：2026-09-18
环境：PVE + Ubuntu 24.04 + RX 7900 XTX 直通 + llama.cpp build 11037 + Mesa 25.2.8
所有数据均为同一台机器实测，含失败组合。

适用平台：华南金牌 X99-TF + Intel Xeon E5 v3/v4（40 通道 CPU 最佳）
目标显卡：Sapphire NITRO+ RX 7900 XTX Vapor-X（设备 ID 1002:744c，音频 ID 1002:ab30）
PVE 版本：Proxmox VE 8.x / 9.x，内核 7.0.2-6-pve
亮机卡：NVIDIA GeForce GT 620（10de:1049，用于宿主机显示输出）
目标 Guest：Ubuntu 24.04 LTS

写在前面：AMD 官方明确声明 RX 7900 XTX 的 PCI Passthrough 不在支持范围内，所有可用的方案均属于社区实践。本指南记录的是在 X99 平台上实际跑通的完整配置，但不保证在其他主板上完全复现。X99 平台存在 PCIe 根端口 AER 报错这一硬件级限制，需要在软件层面尽量规避。

一、硬件准备

关键原则：7900 XTX 必须插在直连 CPU 的插槽，保证 IOMMU 分组独立且 PCIe 带宽为 x16。GT 620 负责宿主机显示，两张卡在不同的 IOMMU 组（本例中 GT 620 在 Group 31，7900 XTX 在 Group 35）。

二、BIOS 设置（华南金牌 X99-TF）

进入 BIOS（Aptio Setup Utility），完成以下配置：

2.1 IntelRCSetup 标签页

进入 IIO Configuration，设置：

进入 IIO0 Configuration，确认两个全长插槽都是 x16：

注意：X99-TF 的 BIOS 中没有独立的 Link Speed 选项（子菜单中也没有），速率由硬件自动协商为 Gen3。

2.2 Advanced 标签页

进入 PCI Subsystem Settings：

进入 CSM Configuration：

关于 Re-Size BAR 的取舍：如果直通后出现频繁 AER 报错或虚拟机启动不稳定，将 Re-Size BAR Support 改为 [Disabled] 再测试。这会牺牲少量性能，但能显著提升兼容性。

2.3 关于板载显卡选项

华南金牌 X99-TF 没有物理板载显卡，BIOS 中也没有 Onboard VGA Control 或 Primary Display 相关选项。直接使用 GT 620 作为宿主机显示输出即可，无需额外设置。

保存退出：按 F10。

三、PVE 宿主机配置

3.1 安装 PVE

用 U 盘安装 PVE 8.x 或 9.x。安装时显示器接在 GT 620 上。

3.2 开启 IOMMU

编辑 GRUB 配置：

nano /etc/default/grub

将 GRUB_CMDLINE_LINUX_DEFAULT 这一行完整替换为（注意：必须是一整行，不能有换行）：

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pci=noaer video=efifb:off initcall_blacklist=sysfb_init"

保存退出后执行：

update-grub
update-initramfs -u
reboot

重启后验证 IOMMU：

dmesg | grep -e DMAR -e IOMMU

应看到 DMAR: IOMMU enabled。

3.3 获取显卡设备 ID

lspci -nn | grep -i vga
lspci -nn | grep -i audio

本例输出：

• 7900 XTX 显卡：05:00.0，ID 1002:744c
• 7900 XTX 音频：05:00.1，ID 1002:ab30
• GT 620：01:00.0，ID 10de:1049（不需要屏蔽）

3.4 绑定 vfio-pci

创建 VFIO 配置（不要加入 disable_vga=1，该参数会导致 X99 平台启动死锁）：

cat << EOF > /etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:744c,1002:ab30
EOF

拉黑宿主机 AMD 驱动：

cat << EOF > /etc/modprobe.d/pve-blacklist.conf
blacklist amdgpu
blacklist radeon
EOF

让 PVE 开机自动加载 VFIO 模块：

echo -e "vfio\nvfio_iommu_type1\nvfio_pci\nvfio_virqfd" >> /etc/modules

更新 initramfs 并重启：

update-initramfs -u
reboot

3.5 验证 vfio-pci 接管成功

lspci -nnk | grep -A 3 "VGA compatible controller"

7900 XTX（05:00.0）下面应显示：

Kernel driver in use: vfio-pci

GT 620（01:00.0）下面应显示：

Kernel driver in use: nvidiafb

3.6 验证 IOMMU 分组独立

for d in /sys/kernel/iommu_groups/*/devices/*; do n="${d#*/iommu_groups/*}"; n="${n%%/*}"; printf 'IOMMU group %s ' "$n"; lspci -nns "${d##*/}"; done | grep -E "1002:744c|10de:1049"

本例输出：

IOMMU group 31 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [GeForce GT 620 OEM] [10de:1049] (rev a1)
IOMMU group 35 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900 GRE/7900M] [1002:744c] (rev c8)

两张卡在不同 Group，说明分组干净，可以单独隔离。

四、vBIOS 文件准备

必须从自己这张显卡上提取，不要从网上下载第三方 vBIOS。

1. 将 7900 XTX 装到一台 Windows 机器上。
2. 用 GPU-Z 软件导出 vBIOS，保存为 7900xtx.rom。
3. 上传到 PVE 宿主机 /usr/share/kvm/ 目录。
4. 验证文件：

ls -lh /usr/share/kvm/7900xtx.rom

应显示约 2.0M 大小。

五、创建 Ubuntu 虚拟机

5.1 创建 VM

在 PVE Web UI 中创建虚拟机，关键参数：

5.2 编辑虚拟机配置文件

nano /etc/pve/qemu-server/101.conf

当前跑通的配置内容：

balloon: 0
bios: ovmf
boot: order=sata0;net0
cores: 16
cpu: host
efidisk0: local-lvm:vm-101-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=4M
hostpci0: 0000:05:00,pcie=1,romfile=7900xtx.rom
ide2: none,media=cdrom
machine: q35
memory: 61440
meta: creation-qemu=11.0.0,ctime=1789626016
name: Ubuntu24.04
net0: virtio=BC:24:11:7B:0F:27,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
sata0: local-lvm:vm-101-disk-1,size=388G
scsihw: virtio-scsi-single
smbios1: uuid=e144b18b-b6fb-4350-bc4c-b1c9659bfe59
sockets: 1
vmgenid: afd026f7-60b3-4c56-a1ca-5d67d88245b7

关键说明：

• hostpci0: 0000:05:00,pcie=1,romfile=7900xtx.rom — 使用 pcie=1 启用 PCIe 直通，加载 vBIOS
• 不要加 args: -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536，X99 平台会因此触发 AER 报错
• 不要加 disable_vga=1，会导致启动死锁
• x-vga=1 可以视 Guest 内输出情况决定是否添加，本例最终未使用

5.3 给虚拟机添加串口（调试用）

qm set 101 -serial0 socket

之后可以用 qm terminal 101 通过串口查看引导输出。

六、安装 Ubuntu 24.04

6.1 先不加直通，用虚拟显卡装完系统

重要：先用最简配置完成 Ubuntu 安装，避免直通干扰安装流程。

# 临时去掉直通
qm set 101 -delete hostpci0

挂载 Ubuntu ISO：

ls /var/lib/vz/template/iso/
qm set 101 -ide2 local:iso/你的ubuntu镜像.iso,media=cdrom
qm set 101 -boot order=ide2;sata0;net0

启动 VM：

qm start 101

通过 PVE Web UI → VM 101 → Console → noVNC 完成 Ubuntu 安装。

6.2 安装时确认

• 设置用户名（本例为 kby）和密码
• 配置网络（DHCP 或静态 IP）
• 安装过程中勾选 Install OpenSSH server

安装完成后，记录 Guest 的 IP 地址（本例为 192.168.0.58）。

6.3 在 Guest 内配置 SSH

SSH 进 Guest：

ssh kby@192.168.0.58

安装并启用 SSH：

sudo apt update
sudo apt install openssh-server -y
sudo systemctl enable --now ssh
sudo systemctl status ssh

看到 active (running) 即可。

七、加回直通并配置 Guest 显示

7.1 在 PVE 宿主机加回直通

qm set 101 -hostpci0 0000:05:00,pcie=1,romfile=7900xtx.rom

重启 VM：

qm stop 101
qm start 101

启动时可能出现以下警告：

error writing '1' to '/sys/bus/pci/devices/0000:05:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:05:00.0', but trying to continue as not all devices need a reset

这是正常警告，不会阻断启动，QEMU 会继续执行。

7.2 Guest 内验证显卡识别

SSH 进 Guest：

ssh kby@192.168.0.58
lspci -nnk | grep -i vga -A3

应看到：

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M] [1002:744c] (rev c8)
        Subsystem: Sapphire Technology Limited NITRO+ RX 7900 XTX Vapor-X [1da2:e471]
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

以及 00:01.0 的 QEMU 虚拟显卡（bochs-drm）。

7.3 检查 amdgpu 驱动加载日志

sudo dmesg | grep -i amdgpu | tail -n 80

关键成功标志：

amdgpu: 24560M of VRAM memory ready
[drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1

可能出现的非致命报错：

amdgpu: PCIe atomic ops is not supported
amdgpu: [drm] Failed to setup vendor infoframe on connector HDMI-A-2: -22

-22 是 HDMI infoframe 格式不合法，会影响 HDMI 音频通道建立，但不影响显示输出的核心功能。

7.4 确认 /dev/dri 设备节点

ls -l /dev/dri/

应看到：

card0（bochs 虚拟显卡）
card1（7900 XTX）
renderD128（7900 XTX 渲染节点）

八、强制 Xorg 使用 7900 XTX 作为主 GPU

这一步是关键：Ubuntu 默认把 card0（bochs 虚拟显卡）当作主显示输出，导致 7900 XTX 虽然驱动加载成功，但拿不到 GDM 的显示绑定。

8.1 创建 Xorg 配置文件

在 Guest 内：

sudo nano /etc/X11/xorg.conf

填入：

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
EndSection

Section "Device"
    Identifier     "AMD0"
    Driver         "amdgpu"
    BusID          "PCI:1:0:0"
    Option         "PrimaryGPU" "yes"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "AMD0"
    DefaultDepth   24
EndSection

保存：Ctrl+O → Enter → Ctrl+X。

8.2 强制 GDM 使用 Xorg（禁用 Wayland）

sudo nano /etc/gdm3/custom.conf

找到 #WaylandEnable=false，去掉前面的 #，变成：

WaylandEnable=false

保存退出。

8.3 更新并重启

sudo update-initramfs -u
sudo reboot

重启后，7900 XTX 屏幕应出现 GDM 登录界面。

九、HDMI 音频配置

如果 HDMI 音频未自动生效，按以下顺序排查：

9.1 检查系统声音设置

打开 Ubuntu 的 设置 → 声音，在“输出设备”中查找 HDMI / DisplayPort Output 或 Navi 31 HDMI Audio，选中它。

9.2 检查音频设备直通状态

确保 7900 XTX 的音频设备（05:00.1，ID 1002:ab30）也一同直通给 Guest。本例中 hostpci0: 0000:05:00 写的是 05:00.0，由于 05:00.0 和 05:00.1 在同一 IOMMU 组，QEMU 会自动带上音频设备。

在 Guest 内验证：

lspci -nnk | grep -i audio

应看到：

01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 HDMI/DP Audio [1002:ab30]

9.3 若声音断断续续，禁用 WirePlumber 自动挂起

mkdir -p ~/.config/wireplumber/wireplumber.conf.d/
nano ~/.config/wireplumber/wireplumber.conf.d/disable-suspend.conf

填入：

wireplumber.profiles = {
  main = {
    hooks.node.suspend = disabled
  }
}

然后重启音频服务：

systemctl --user restart pipewire
systemctl --user restart wireplumber

9.4 若 HDMI 音频始终异常

换用 DisplayPort 线。-22 infoframe 报错是 HDMI 通道特有的兼容性问题，DP 通道通常能直接绕过。这是最省心的解决方案。

十、X99 平台长期使用注意事项

10.1 failed to reset PCI device 警告

每次 qm start 都可能出现，不是致命错误，QEMU 会继续启动。如果遇到 VM 启动后 7900 XTX 不亮：

qm stop 101
# 若 stop 失败
qm stop 101 --skiplock
qm start 101

若仍失败，冷启动 PVE 主机（长按电源键关机再开机）恢复 PCIe 状态。

10.2 AER 错误

X99 平台 PCIe 根端口会持续报 AER: Uncorrectable (Non-Fatal)。这是硬件级限制，已通过 pci=noaer 和 initcall_blacklist=sysfb_init 在内核层面尽量抑制。高负载下若链路崩溃，需冷启动主机。

10.3 备份关键配置

跑通后立刻备份：

cp /etc/pve/qemu-server/101.conf ~/101.conf.backup
cp /etc/default/grub ~/grub.backup
cp /etc/modprobe.d/vfio.conf ~/vfio.conf.backup
cp /etc/modprobe.d/pve-blacklist.conf ~/pve-blacklist.conf.backup
cp /usr/share/kvm/7900xtx.rom ~/7900xtx.rom.backup

10.4 关于鼠标键盘

不需要专门直通键鼠。QEMU 默认提供虚拟 USB 控制器和模拟键鼠，物理键鼠在切换显示窗口时通常能直接使用。只有在追求极低延迟（如游戏）或虚拟机需要完全独占输入时，才考虑单设备 USB 直通（不要直通整个 USB 控制器，X99 上有风险）。

十一、完整配置清单速查

PVE 宿主机：

Guest 虚拟机（101.conf）关键行：

hostpci0: 0000:05:00,pcie=1,romfile=7900xtx.rom

Guest 内关键配置：

十二、最终验证

在 Guest 内执行：

glxinfo | grep "OpenGL renderer"

应显示：

OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, ...)

看到这一行，说明整个直通链路——BIOS → vfio-pci → QEMU → amdgpu → Xorg → GDM → 显示输出 → HDMI 音频——全部打通。

这套配置在华南金牌 X99-TF + RX 7900 XTX 上已实际验证可用。

• 7900XTX 不支持 SR-IOV，只能整卡直通；两卡要分别落在独立 IOMMU group 里。X99 上如果分组不干净，要么换插槽，要么用 ACS override（有安全代价，内网可接受）。
• BIOS 里 Above 4G Decoding、Resizable BAR、IOMMU 都要开；7900 系有经典的 reset bug，直通 VM 重启前先确认宿主机用 vendor-reset 或内核参数兜住，不然第二次启动会挂。
• PVE 里把 /dev/kfd 和 /dev/dri 正确映射给 guest；ROCm 6.x 在 VM 里能跑 llama.cpp/vLLM，但性能比裸机差一截，能用 LXC 就别用 KVM（ROCm 在 LXC 需要手动映射设备）。
• 单卡 ReBAR 对推理收益有限，主要看显存映射；你以后切 NV 是对的，但 5090/4090 的价差也要算进去。

1推荐的7900xtx
2……内存便宜忍了
3没拍……回头补上