华南金牌X99-TF 2696V3 PVE直通7900XTX成功
-
1,我特么从来没推荐华南金牌,我只是说性价比不错,不叫推荐,推荐是大家闭眼买就对了。
2,你单卡开启rebar有个毛用啊,主要是看能否两张XTX,这个很显然不行。
3,你发这个帖子不上图?1推荐的7900xtx
2……内存便宜忍了
3没拍……回头补上 -
1推荐的7900xtx
2……内存便宜忍了
3没拍……回头补上@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 的价差也要算进去。
-
X99 平台 Proxmox VE 直通 AMD RX 7900 XTX 完整实战指南
适用平台:华南金牌 X99-TF + Intel Xeon E5 v3/v4(40 通道 CPU 最佳)
目标显卡:Sapphire NITRO+ RX 7900 XTX Vapor-X(设备 ID1002:744c,音频 ID1002: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,ID1002:744c - 7900 XTX 音频:
05:00.1,ID1002:ab30 - GT 620:
01:00.0,ID10de: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 reboot3.5 验证 vfio-pci 接管成功
lspci -nnk | grep -A 3 "VGA compatible controller"7900 XTX(
05:00.0)下面应显示:Kernel driver in use: vfio-pciGT 620(
01:00.0)下面应显示:Kernel driver in use: nvidiafb3.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,ID1002: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 wireplumber9.4 若 HDMI 音频始终异常
换用 DisplayPort 线。
-22infoframe 报错是 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.backup10.4 关于鼠标键盘
不需要专门直通键鼠。QEMU 默认提供虚拟 USB 控制器和模拟键鼠,物理键鼠在切换显示窗口时通常能直接使用。只有在追求极低延迟(如游戏)或虚拟机需要完全独占输入时,才考虑单设备 USB 直通(不要直通整个 USB 控制器,X99 上有风险)。
十一、完整配置清单速查
PVE 宿主机:
文件 内容 /etc/default/grubGRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pci=noaer video=efifb:off initcall_blacklist=sysfb_init"/etc/modprobe.d/vfio.confoptions vfio-pci ids=1002:744c,1002:ab30/etc/modprobe.d/pve-blacklist.confblacklist amdgpu/blacklist radeon/etc/modulesvfio/vfio_iommu_type1/vfio_pci/vfio_virqfd/usr/share/kvm/7900xtx.rom从本卡导出的 vBIOS Guest 虚拟机(101.conf)关键行:
hostpci0: 0000:05:00,pcie=1,romfile=7900xtx.romGuest 内关键配置:
文件 内容 /etc/X11/xorg.conf强制 amdgpu 作为 PrimaryGPU,BusID PCI:1:0:0/etc/gdm3/custom.confWaylandEnable=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 上已实际验证可用。
- 7900 XTX 显卡:
-
1,我特么从来没推荐华南金牌,我只是说性价比不错,不叫推荐,推荐是大家闭眼买就对了。
2,你单卡开启rebar有个毛用啊,主要是看能否两张XTX,这个很显然不行。
3,你发这个帖子不上图?@terry
版主帖子超时无法编辑了 -
@terry
版主帖子超时无法编辑了 -
单张 RX 7900 XTX + PVE 直通:Qwen3.8-27B 本地大模型部署实录
补图,自己动手翻新了旧机箱,上岁数了吧,非常喜欢这种老情人回到18个感觉……

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




另外发现一个很迷的问题……见图。
一、最终成果
在 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 \ --jinjachmod +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 9830498K 上下文 --cache-type-k q8_0 --cache-type-v q4_1K 精度优先,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 32768prompt 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-headersCMake 报 Could not find SPIRV-Headerssudo apt install spirv-headers2 用户不在 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-mtp5 256M BAR 导致 ctx 断崖 16K 以上 decode 掉到 14 export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=16 短 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
所有数据均为同一台机器实测,含失败组合。 - PVE 直通下 ReBAR 通常不生效,BAR 只有 256M。
-
o对了,我这个显卡目前还是节能模式,没切到oc的bios,因为还得折腾vbios就先这样了
-
单张 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 9830498K 上下文 --cache-type-k q8_0 --cache-type-v q4_1K 精度优先,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 32768prompt 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-headersCMake 报 Could not find SPIRV-Headerssudo apt install spirv-headers2 用户不在 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-mtp5 256M BAR 导致 ctx 断崖 16K 以上 decode 掉到 14 export GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=16 短 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
所有数据均为同一台机器实测,含失败组合。 - PVE 直通下 ReBAR 通常不生效,BAR 只有 256M。
-

更新一下最新的使用速度情况,用的是Hermes agent
-
不错。直通独立显卡。在一些人的知识面还是盲区。
感谢为他们科普了。 -
,
T terry 固定了此主题
-
不错。直通独立显卡。在一些人的知识面还是盲区。
感谢为他们科普了。@williamlouis
其实直通之后没有太多性能损失的前提下,这玩意具有非常大的实用价值:一、目前我们大部分人的算例底座都是性能过剩的,即使是X99这种老东西切了一半的cpu资源也没有任何影响,切几个核心几个G的内存百十来G的硬盘几乎没啥感觉,所以在虚拟机和直通的基础上,我们可以分裂出若干个虚拟机,用来跑agent,即避免了资源浪费噪音污染,也减少了资金投入,不然还要再找一台电脑去架设个agent。
二、对提高系统的稳定性和可用性帮助也很大,pve虚拟机可以提供非常方便的冷热备份,只要有个大硬盘或者nas,对于喜欢折腾的人来说,只要及时备份虚拟机,一个系统可以在几分钟之内迅速的完全恢复。
三、虚拟机是可以迁移的,如同备份。
-
,系统 取消固定了此主题