华南金牌X99-TF 2696V3 PVE直通7900XTX成功

Xiaote

@Kang-Benyuan 直通成功不错。X99 + 2696V3 这套有几点可以顺手记下：

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 的价差也要算进去。

Kang Benyuan

X99 平台 Proxmox VE 直通 AMD RX 7900 XTX 完整实战指南

适用平台：华南金牌 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 报错这一硬件级限制，需要在软件层面尽量规避。

一、硬件准备

设备	位置	用途
RX 7900 XTX	离 CPU 最近的 PCIe x16 插槽（Port 1A）	直通给 Guest
GT 620	第二条 x16 或 x4 插槽	PVE 宿主机显示输出
显示器	接在 GT 620 上	用于 PVE 安装和救援

关键原则：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，设置：

选项	值
Intel VT for Directed I/O (VT-d)	`[Enabled]`
ACS Control	`[Enabled]`
Interrupt Remapping	`[Enabled]`
Coherency Support (Non-Isoch)	`[Enabled]`
Coherency Support (Isoch)	`[Enabled]`
VTd Azalea Vcp Optimizations	`[Disable]`（保持默认）

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

选项	值
IOU0 (IIO PCIe Port 2)	`[x16]`
IOU1 (IIO PCIe Port 3)	`[x16]`

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

2.2 `Advanced` 标签页

进入 PCI Subsystem Settings：

选项	值
Above 4G Decoding	`[Enabled]`
Re-Size BAR Support	`[Enabled]`（部分 BIOS 版本需关闭，见下方说明）
SR-IOV Support	`[Enabled]`

进入 CSM Configuration：

选项	值
CSM Support	`[Disabled]`（使用 UEFI 引导）

关于 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。

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

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

应显示约 2.0M 大小。

五、创建 Ubuntu 虚拟机

5.1 创建 VM

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

项目	值
VM ID	101
名称	Ubuntu24.04
BIOS	OVMF (UEFI)
Machine	q35
CPU	host
核心数	16
内存	61440 MB
磁盘	388G
网络	virtio, bridge=vmbr0
显示	默认（先用 QEMU 虚拟显卡）
引导顺序	sata0;net0

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 [email protected]

安装并启用 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 [email protected]
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 宿主机：

文件	内容
`/etc/default/grub`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pci=noaer video=efifb:off initcall_blacklist=sysfb_init"`
`/etc/modprobe.d/vfio.conf`	`options vfio-pci ids=1002:744c,1002:ab30`
`/etc/modprobe.d/pve-blacklist.conf`	`blacklist amdgpu` / `blacklist radeon`
`/etc/modules`	`vfio` / `vfio_iommu_type1` / `vfio_pci` / `vfio_virqfd`
`/usr/share/kvm/7900xtx.rom`	从本卡导出的 vBIOS

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

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

Guest 内关键配置：

文件	内容
`/etc/X11/xorg.conf`	强制 amdgpu 作为 PrimaryGPU，BusID `PCI:1:0:0`
`/etc/gdm3/custom.conf`	`WaylandEnable=false`

十二、最终验证

在 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 上已实际验证可用。

Kang Benyuan

@terry
版主帖子超时无法编辑了

terry

@Kang-Benyuan 那你发帖的时候注意点，超时不允许编辑我也没办法。

Kang Benyuan

单张 RX 7900 XTX + PVE 直通：Qwen3.8-27B 本地大模型部署实录

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

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

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

千问.JPG

一、最终成果

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

指标	实测值
**	Decode	37–41 t/s
Prefill	195–199 t/s	**
上下文	98304（98K）
KV Cache	K q8_0 / V q4_1
显存占用	模型 + 98K KV 全部在 24GB VRAM 内

二、硬件与软件环境

项目	配置
主板	华南金牌 X99-TF
CPU	Xeon E5-2696V3 （分配了8核心16线程）
内存	128GB DDR3 1600 ECC （分配了60G固定内存）
显卡	AMD Radeon RX 7900 XTX 24GB（Navi 31 / gfx1100）
虚拟化	PVE，Ubuntu 24.04 虚拟机，GPU 直通
后端	Vulkan（Mesa 25.2.8 RADV）
推理引擎	llama.cpp build 11037（commit 44be98f05）
模型	unsloth/Qwen3.8-27B-GGUF，Qwen3.8-27B-UD-Q4_K_M.gguf（16.5G）

三、编译 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 定位断崖

ctx	KV	decode
8192	q8_0/q8_0	51.67
16384	q8_0/q8_0	14.18
32768	q8_0/q8_0	14.47
65536	q8_0/q8_0	13.12
98304	q8_0/q8_0	11–15

断崖在 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 &

八、参数说明

参数	作用
`GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1`	最关键。PVE 直通下 BAR 只有 256M，此变量强制所有 buffer 走设备本地 VRAM，绕过断崖
`--device Vulkan0`	多设备时明确指定显卡
`-ngl 99`	全部层上 GPU
`--parallel 1`	单槽独占 98K 上下文
`--ctx-size 98304`	98K 上下文
`--cache-type-k q8_0 --cache-type-v q4_1`	K 精度优先，V 用 q4_1（带 scale+min，比 q4_0 稳）
`--ctx-checkpoints 2`	稳定性四件套之一，不影响速度
`--spec-type draft-mtp`	启用模型内建 MTP 投机解码。不要加 ngram-map-k4v，Vulkan 下反而拖慢
`--spec-draft-n-max 5`	一次猜 5 个 token
`--cache-ram 32768`	prompt cache 开到 32GB，利用 128GB 内存，多轮对话避免重复 prefill
`--jinja`	启用 chat template

九、性能对比总表

配置	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	缺 `spirv-headers`	CMake 报 `Could not find SPIRV-Headers`	`sudo apt install spirv-headers`
2	用户不在 `render` 组	Vulkan 报 `Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)`	`sudo usermod -aG render,video $USER`，重登录
3	桌面会话占用 GPU	llama-bench 卡死、GPU 利用率 0%	停掉 gdm3，或让桌面用另一张卡
4	`ngram-map-k4v` 在 Vulkan 下拖慢	decode 从 51 掉到 13	去掉该参数，只用 `draft-mtp`
5	256M BAR 导致 ctx 断崖	16K 以上 decode 掉到 14	`export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1`
6	短 prompt 测 prefill	59 token 测出 20 t/s 假数字	用 ≥2000 token 的 prompt 测
7	同名 GGUF 可能没有 MTP 层	报 `model doesn't contain MTP layers`	换 unsloth UD 版本，确认 `blk.64.nextn.*` 存在

十一、关键经验

PVE 直通下 ReBAR 通常不生效，BAR 只有 256M。GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 是必加项，不是可选项。
Vulkan 后端的 ngram-map-k4v 在 RDNA3 上表现异常，社区在 ROCm/HIP 下的收益无法复现，建议只用 draft-mtp。
KV 量化不对称是正解：K q8_0 / V q4_1。K 决定注意力方向，敏感；V 是加权平均，容忍度高。
断崖是确定性的，不是脏状态。冷启动、子分配修复都无效，只有禁用 host visible VRAM 才解决。
测速必须固定内容类型。代码生成接受率高（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
所有数据均为同一台机器实测，含失败组合。

Kang Benyuan

o对了，我这个显卡目前还是节能模式，没切到oc的bios，因为还得折腾vbios就先这样了

Kang Benyuan

单张 RX 7900 XTX + PVE 直通：Qwen3.8-27B 本地大模型部署实录

一、最终成果

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

指标	unsloth UD 版	去审查版
Decode（98K）	41.25 t/s	47.95 t/s
Prefill	199.38 t/s	177.27 t/s
接受率	0.345	0.420
mean len	2.73	3.10
上下文	98304（98K）	98304（98K）
KV Cache	K q8_0 / V q4_1	K q8_0 / V q4_1

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

二、硬件与软件环境

项目	配置
主板	华南金牌 X99-TF
CPU	Xeon E5-2696V3
内存	128GB DDR3 1600 ECC
显卡	AMD Radeon RX 7900 XTX 24GB（Navi 31 / gfx1100）
虚拟化	PVE，Ubuntu 24.04 虚拟机，GPU 直通
后端	Vulkan（Mesa 25.2.8 RADV）
推理引擎	llama.cpp build 11037（commit 44be98f05）
模型	unsloth Qwen3.8-27B-UD-Q4_K_M（16.5G）/ 去审查版 Qwen3.8-27B-Uncensored-Q4_K_M（16.8G）

三、编译 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 定位断崖

ctx	KV	decode
8192	q8_0/q8_0	51.67
16384	q8_0/q8_0	14.18
32768	q8_0/q8_0	14.47
65536	q8_0/q8_0	13.12
98304	q8_0/q8_0	11–15

断崖在 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.* 张量。

指标	去审查版	unsloth UD 版
decode（98K）	47.95 t/s	41.25 t/s
接受率	0.420	0.345
mean len	3.10	2.73

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 &

八、参数说明

参数	作用
`GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1`	最关键。PVE 直通下 BAR 只有 256M，此变量强制所有 buffer 走设备本地 VRAM，绕过断崖
`--mmproj`	加载视觉投影，让模型能看图片。不需要视觉功能时去掉，省约 900MB 显存
`--device Vulkan0`	多设备时明确指定显卡
`-ngl 99`	全部层上 GPU
`--parallel 1`	单槽独占 98K 上下文
`--ctx-size 98304`	98K 上下文
`--cache-type-k q8_0 --cache-type-v q4_1`	K 精度优先，V 用 q4_1（带 scale+min，比 q4_0 稳）
`--ctx-checkpoints 2`	稳定性四件套之一，不影响速度
`--spec-type draft-mtp`	启用模型内建 MTP 投机解码。不要加 ngram-map-k4v，Vulkan 下反而拖慢
`--spec-draft-n-max 5`	一次猜 5 个 token
`--cache-ram 32768`	prompt cache 开到 32GB，利用 128GB 内存，多轮对话避免重复 prefill
`--jinja`	启用 chat template

九、性能对比总表

配置	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	缺 `spirv-headers`	CMake 报 `Could not find SPIRV-Headers`	`sudo apt install spirv-headers`
2	用户不在 `render` 组	Vulkan 报 `Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)`	`sudo usermod -aG render,video $USER`，重登录
3	桌面会话占用 GPU	llama-bench 卡死、GPU 利用率 0%	停掉 gdm3，或让桌面用另一张卡
4	`ngram-map-k4v` 在 Vulkan 下拖慢	decode 从 51 掉到 13	去掉该参数，只用 `draft-mtp`
5	256M BAR 导致 ctx 断崖	16K 以上 decode 掉到 14	`export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1`
6	短 prompt 测 prefill	59 token 测出 20 t/s 假数字	用 ≥2000 token 的 prompt 测
7	同名 GGUF 可能没有 MTP 层	报 `model doesn't contain MTP layers`	换 unsloth UD 版本，确认 `blk.64.nextn.*` 存在
8	mmproj 与模型不匹配	报张量不匹配错误	unsloth 版用 unsloth 的 mmproj，去审查版用去审查版的

十一、关键经验

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

Kang Benyuan

Screenshot_20260921_073458_com.tencent.mm.jpg

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

williamlouis

不错。直通独立显卡。在一些人的知识面还是盲区。
感谢为他们科普了。

Kang Benyuan

@williamlouis
其实直通之后没有太多性能损失的前提下，这玩意具有非常大的实用价值：

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

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

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

抡锤者

华南金牌X99-TF 2696V3 PVE直通7900XTX成功

X99 平台 Proxmox VE 直通 AMD RX 7900 XTX 完整实战指南

一、硬件准备

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

2.1 IntelRCSetup 标签页

2.2 Advanced 标签页

2.3 关于板载显卡选项

三、PVE 宿主机配置

3.1 安装 PVE

3.2 开启 IOMMU

3.3 获取显卡设备 ID

3.4 绑定 vfio-pci

3.5 验证 vfio-pci 接管成功

3.6 验证 IOMMU 分组独立

四、vBIOS 文件准备

五、创建 Ubuntu 虚拟机

5.1 创建 VM

5.2 编辑虚拟机配置文件

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

六、安装 Ubuntu 24.04

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

6.2 安装时确认

6.3 在 Guest 内配置 SSH

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

7.1 在 PVE 宿主机加回直通

7.2 Guest 内验证显卡识别

7.3 检查 amdgpu 驱动加载日志

7.4 确认 /dev/dri 设备节点

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

8.1 创建 Xorg 配置文件

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

8.3 更新并重启

九、HDMI 音频配置

9.1 检查系统声音设置

9.2 检查音频设备直通状态

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

9.4 若 HDMI 音频始终异常

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

10.1 failed to reset PCI device 警告

10.2 AER 错误

10.3 备份关键配置

10.4 关于鼠标键盘

十一、完整配置清单速查

十二、最终验证

单张 RX 7900 XTX + PVE 直通：Qwen3.8-27B 本地大模型部署实录

一、最终成果

二、硬件与软件环境

三、编译 llama.cpp

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

五、下载模型

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

6.1 初始配置（失败）

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

6.3 定位断崖

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

6.5 根因定位：256M BAR

6.6 最终修复：禁用 host visible VRAM

七、最终可用配置

八、参数说明

九、性能对比总表

十、踩坑清单

十一、关键经验

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

单张 RX 7900 XTX + PVE 直通：Qwen3.8-27B 本地大模型部署实录

一、最终成果

二、硬件与软件环境

三、编译 llama.cpp

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

五、下载模型

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

6.1 初始配置（失败）

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

6.3 定位断崖

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

6.5 根因定位：256M BAR

6.6 最终修复：禁用 host visible VRAM

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

七、最终可用配置

脚本一：unsloth UD 版（+ mmproj）

2.1 `IntelRCSetup` 标签页

2.2 `Advanced` 标签页

10.1 `failed to reset PCI device` 警告