跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(LCZ-Blue)
  • 不使用皮肤
  • LCZ-Green
  • LCZ-Blue
  • LCZ-Black
折叠
品牌标识

抡锤者

首页 版块 标签
硬件
装备秀
AI 广场 App
Kang BenyuanK

Kang Benyuan

@Kang Benyuan
取消关注 关注
关于
帖子
16
主题
1
分享
0
群组
0
粉丝
0
关注
0

帖子

最新 最佳 有争议的

  • 双R9700 P2P+双卡TP 方案总结
    Kang BenyuanK Kang Benyuan
    AI硬件 r9700 x99 多卡部署

    @q1726092075
    兄弟客气,我这刚上手玩了一个礼拜,就一张7900xtx😧


  • 双R9700 P2P+双卡TP 方案总结
    Kang BenyuanK Kang Benyuan
    AI硬件 r9700 x99 多卡部署

    X99-tf应该也支持,但是好像要刷鸡血的BIOS


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

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

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

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

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

    Screenshot_20260921_073458_com.tencent.mm.jpg

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

    单张 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,去审查版用去审查版的

    十一、关键经验

    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
    所有数据均为同一台机器实测,含失败组合。


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

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

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

    72d9deeca311b3893403fa601370519.jpg

    先说结论,PVE下X99加7900xtx基本可用,40tokens加98k上下文。与物理安装差距不大。另外大模型与基础平台的性能关系也没有预想那么大,物理配置切一半的情况下效果没有太大弱化。算是达到了购买目标。
    配置如下:
    千问2.JPG
    fc5fb08e1e9183dc89cf7bafbe73ea1.jpg
    0b7f5b580d8266705e754f009b94406.jpg
    8a5e00134a4798f073ddf29a47e564b.jpg
    a32090db5289a449bb9ae92acd47f15.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.* 存在

    十一、关键经验

    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 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

    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。

    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 中创建虚拟机,关键参数:

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

    @terry

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


  • 华南金牌X99-TF 2696V3 PVE直通7900XTX成功
    Kang BenyuanK Kang Benyuan
    AI硬件 x99 7900xtx 服务器

    首先感谢一下版主推荐了7900xtx,建议也很好都是个渐进的过程,小投入先玩玩看,有必要再砸钱。

    目标配置如下,显卡目前是7900xtx。
    序号 配件名称 型号 规格 备注 数量 价格
    1 cpu 2696V3 LGA2011-3 鸡血刷bios降压 1 0
    2 主板 华南金牌TF ATX 板U套装 1 958
    3 内存 DDR3服务器ecc 1600MHz 4 980
    4 机箱 旧机箱 nzxt p410 只有240水冷 0
    5 硬盘 1Tssd sata接口 0
    6 cpu水冷 240规格 1 295
    7 显卡 7900xtx蓝宝石超白金 咸鱼 6500
    8 电源 酷冷至尊(CoolerMaster)X Mighty 2000W 白金牌静音电源 2000w模组 1 2799
    e9a943af-3d77-4b15-912c-a843563ce403-image.jpeg

    分别在三块硬盘上安装了三个系统
    第一块1个256g的nvme安装了ubuntu24.04LTS, Qwen2.5的7B和Qwen3.8的27B,没有做深度测试仅仅是跑通。十几个token上下,没有做优化,显卡用的节能模式。
    第二块是个sata的120Gssd硬盘,安装了Win10
    第三块是sata的960G的ssd,安装了PVE。一个server2022虚拟机,一个ubuntu24.04加7900xtx直通。

    听了版主很多视频,一再强调x99够用,最好物理安装,虚拟机很麻烦会有各种问题,但是需求也很客观,我确实需要两个机器跑数据运算,切成两个虚拟机并直通一个是最合理的分配。一个跑数据库一个跑前端运算,核心和线程可以完全匹配全部利用起来,而且比网络传输数据可靠速度也更靠谱。

    PVE里面server2022虚拟机和ubuntu24.04各分配了60G内存8个核心,留给pve2个核心8G内存。折腾了一天,还没安装本地大模型,但是pve的显卡直通已经搞定了。先说重点后续补充其他信息。

    7900xtx 是可以pve直通的。我有另外一张geforce620的亮机卡,所以可能少走了很多弯路。
    一、x99 BIOS准备 ,用的官方鸡血bios,版本4.04 (注意bios版本,我并没有出现后关闭导致7900xtxCSM黑屏可能与bios版本有关)
    二、IOMMU和VT-D开启
    三、CSM关闭 关闭前确认显卡选项是EFI
    四、开启Above 4G
    五、Resize Bar 开启
    六、SR-IOV开启
    重点虚拟机先不要加上7900xtx,先把虚拟机安装好,之后用命令行去直通显卡。
    七、之后pve会面对多次开机锁死,解决方法是在pve开始菜单按e编辑grub,之后ctrl+x启动。 后续我会补充grub代码。PVE。一个server2022虚拟机,一个ubuntu24.04加7900xtx直通。
    八、进入pve之后会发现虚拟机无法启动,主要问题是x99太老,导致pcie的分配混乱导致冲突引起。需要写脚本固定。后续补充代码。
    九、重点这是重点中的重点,x99必须要作的,提取显卡的bios并存到pve的/usr/share/kvm目录,使用gpu-z提取

    十、这个年代肯定都是在AI的指导下复制粘贴,总共动用了三个,Deepseek网页版,gemini网页版,Qwen网页版。最靠谱的是Deepseek在他的指导下完成。不提vbios的都是刷流氓。Qwen幻觉有点严重。

    十一、很晚了先占个坑,回头测一下直通的大模型情况再来更新。初步验证了直通的可行性,实际大模型表现待确认


  • [求助] 想在ITX机箱里塞双卡7900 XTX,组成AI小钢炮带出国,可行吗?
    Kang BenyuanK Kang Benyuan
    AI硬件 7900xtx x99 多卡部署

    我劝你直接放弃这个想法,我用的是标准atx机箱和atx大板,我一开始也是想上两张;7900xtx买了一张二手的先试试,本来打算后续靠谱靠配一下版主的4090。这个蓝宝石的超白金,号称是3.5宽而实际上插进之后,这哥们要占5个以上的插槽,临近他的两个插槽儿基本上除了那种特别特别薄的卡什么也用不了,就是那种特别特别老的网卡才有可能。我这还是atx机箱……然而完全装不下第二张xtx。除非像班主那样第二张搞个涡轮的把这个挪到第二个16x插槽去去。放弃吧兄弟都出去了还搞什么amd


  • 7900xtx 蓝宝石 白金款抖音领券6000-780 ,券后价格5220。低价啊,兄弟们!
    Kang BenyuanK Kang Benyuan
    AI硬件 7900xtx

    @terry 就是看你的油管频道才决定买的,感谢推荐,二手真香,省下了电源钱。看看过几天也搞个4090 48G,抄作业就要彻底,连名字都抄上。


  • 7900xtx 蓝宝石 白金款抖音领券6000-780 ,券后价格5220。低价啊,兄弟们!
    Kang BenyuanK Kang Benyuan
    AI硬件 7900xtx

    刚买了个二手的7900xtx超白金,还有一年多保修,6500

  • 登录

  • 登录或注册以进行搜索。
  • 第一个帖子
    最后一个帖子
0
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组