平台：Dell Precision T7910（双路 Xeon E5-2683 v4 / 128G DDR4 ECC / 1300W 电源）
显卡：盈通 R9700 32G（RDNA4 / gfx1201 / Navi48）×2
系统：Ubuntu 24.04.5 LTS + HWE 内核 7.0.0 + ROCm 7.2 + llama.cpp（HIP 后端 + FastMTP 补丁）
模型：Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q6_K_P（24.1G）

TL;DR（赶时间看这张表）

项目	结果
单卡 32G	27B Q6 + MTP + 128K 上下文 → decode 39.7 t/s / prefill 395 t/s
双卡 64G	一满载就整机断电重启，连发一句"你好"都能重启
把功率限到 250W	照样断
限到硬件下限 210W	还是断（且已确认崩溃瞬间功率确实是 210W）
最终结论	不是总功率不够 —— 双卡稳态才 ~690W，1300W 电源只用了 53% → 怀疑是单路 12V 瞬态过流触发电源保护
现状	单卡先跑着，等解决供电再上双卡

一句话教训：power1_cap 限的是平均功耗，限不住微秒级瞬态尖峰。靠降功率，救不了供电不足的机器。

一、平台配置与采购价

️ 内存插法要留意：每路 CPU 只插了 DIMM1+DIMM2，每路双通道、全平台 4/8 通道，实测带宽 76.8 GB/s。插满 8 条可到 153.6 GB/s（跑 CPU 推理才有意义，见第六节）。

二、装机踩坑（按踩到的顺序，每条都能省你半天）

坑 1：Ubuntu 24.04 默认内核 6.8 完全不认识 RDNA4

• 症状：amdgpu: Fatal error during GPU init、probe of 0000:05:00.0 failed with error -22，/dev/dri/renderD128 压根不出现
• 原因：RDNA4（Navi48）需要 6.12+ 内核，24.04 GA 的 6.8 太老
• 解法：装 HWE 内核

sudo apt install -y linux-generic-hwe-24.04     # 实测拿到 7.0.0-31

坑 2：老平台必须开 BIOS「Above 4G Decoding」

RDNA4 这种 32G 大显存卡需要 GB 级 BAR 空间，老平台默认不开时：

lspci -vvs 05:00.0 | grep -A3 'Resizable BAR'   # BAR 0 只有 256MB
dmesg | grep 'root bus resource \[mem'           # PCIe MMIO 窗口仅 ~320MB

开完 BIOS 后窗口变成 mem 0x30000000000-0x33fffffffff、BAR 升到 33fe0000000，这一步是硬前提。

坑 3：换新内核后 amdgpu 一初始化就挂 → boot loop

现象：内核 7.0 下 amdgpu 走到 DMUB hardware initialized 之后就整机重启，日志无 panic 落盘。旧内核 6.8 看不到这症状（它连初始化都进不去）。

三步定位法：

1. 内核参数加 modprobe.blacklist=amdgpu 启动 → 系统能稳 ⇒ 确认是 amdgpu，同时拿到一个能抓日志的窗口
2. 黑名单模式下：一个连接 sudo dmesg -w 流式读，另一个连接手动 sudo modprobe amdgpu → 抓到最后几行
3. 逐项加参数复测（每次用 grub-reboot '1>N' 一次性试启动，失败自动回默认内核，不会把自己锁在门外）

最后解决它的不是参数，是硬件：用户换了一个 GPU 供电接口后，连 runpm=0 都可以去掉，彻底稳定。

教训：软件层对不上时先看硬件。[drm] Initialized amdgpu 3.64.0 都打出来了还挂 → 不是驱动 bug，优先查供电/接线。

坑 4：ROCm 7.2 装到怀疑人生

• 国内没有任何 ROCm 镜像（中科大/阿里/腾讯/清华全 404），只能直连 repo.radeon.com，实测 ~2.7 MB/s
• 下载 5~7 GB / 600+ 包，装完占 8~15 GB，全程约 80 分钟，别少留时间

curl -s https://repo.radeon.com/amdgpu-install/7.2/ubuntu/noble/ | grep -oE 'amdgpu-install_[0-9._-]+_all.deb'
sudo apt-get install -y /tmp/amdgpu-install_*_all.deb
sudo amdgpu-install --usecase=rocm --no-dkms -y

• apt 走清华源时若命中 IPv6 会 403：403 Forbidden [IP: 2402:...] → 写 /etc/apt/apt.conf.d/99force-ipv4 内容 Acquire::ForceIPv4 "true"; 永久解决
• ROCm 7.2 原生就认 gfx1201，HSA_OVERRIDE_GFX_VERSION 单卡 llama.cpp 不需要（那个变量是留给 SGLang/vLLM 这类还在旧支持列表里的框架的）

坑 5：装完 ROCm 第一件事 —— 用户要进 render 组 ★

这是最阴的一个坑：

rocminfo          # 普通用户跑 → 空的
sudo rocminfo     # 正常显示 gfx1201

根因：/dev/kfd 和 /dev/dri/renderD128 的权限是 root:render 660，用户不在 render 组里。而 llama.cpp 只会报 no ROCm-capable device is detected，极易误判成"架构不支持/驱动坏了"，白查半天。

sudo usermod -aG render,video <user>     # 必须重新登录才生效

同类报错还有第二个来源：systemd 服务抢在 amdgpu 初始化完成前启动（/dev/kfd 刚出现但还不可用），症状一模一样（is-active=active、/health=ok、实际在跑 CPU）。修法不同：ExecStartPre=/bin/sleep 20 + Wants=dev-kfd.device + 单元文件里必须显式写 SupplementaryGroups=render video（systemd 只继承主组，shell 里的补充组带不进去）。

一秒判定在不在 GPU 上：cat /sys/class/drm/card*/device/mem_info_vram_used 只有 ~50MiB ⇒ 跑在 CPU 上；正常加载 20G+ 模型应显示几十 GiB。

坑 6：btop 1.3.0 在 RDNA4 上必崩（段错误）

1.3.0 新增了 ROCm SMI GPU 监控，会 dlopen 系统的 librocm_smi64，在 gfx1201 上读温度/PCIe 吞吐失败后直接 Segfault。日志线索在 ~/.config/btop/btop.log（先 WARNING: ROCm SMI: Failed to get maximum GPU temperature 再崩）。没有任何配置项/环境变量/命令行参数能关掉它。

解法：降级到 btop 1.2.13（GPU 模块是 1.3.0 才加的），并且必须覆盖 /usr/bin/btop 本体——只装到 /usr/local/bin 时调用路径没命中，跑的还是那个必崩的版本。

坑 7：llama.cpp 新版参数改名，照抄教程直接崩

• --no-mmap → --load-mode {auto|none|mmap|mlock|dio}
• --draft-n → --spec-draft-n-max
• 投机解码统一到 --spec-type

照抄模型卡里的示例命令 → systemd 陷入 Failed with result 'exit-code' 的 5 秒重启循环，而显存看着是空的，容易误判"模型没加载上"。

抄完必须 llama-server --help | grep <参数> 验证一遍。

三、单卡成绩单（真香的部分）

配置

llama-server \
  --model  Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q6_K_P.gguf \
  --spec-type draft-mtp \
  --spec-draft-model Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-FastMTP-32K.gguf \
  --spec-draft-ngl all --spec-draft-n-max 3 --spec-draft-p-min 0 \
  --ctx-size 131072 --parallel 1 \
  --batch-size 2048 --ubatch-size 512 \
  --n-gpu-layers all --cache-type-k q8_0 --cache-type-v q4_0 \
  --flash-attn on --load-mode mmap --jinja \
  --host 0.0.0.0 --port 8080 --metrics

实测（27B Q6_K_P + MTP，128K 上下文，280W）

• 显存占用 29.8G / 32.6G（模型 + 128K KV + draft 全驻显存）
• 272 秒连续输出 10000 tokens，稳定 36.7 t/s 不掉速
• 跑完 GPU 立刻回落 17W —— 完全空闲

对 Agent 工作流的意义：16K 的 prompt 40 秒内消化完，之后 decode 稳在 37~40 t/s。"大 prompt 快速吞吐 + 投机解码加速长输出"正是 coding agent 最吃重的两段。

四、双卡翻车全过程（本文重点）

时间线

步骤	动作	结果
1	双卡上机，llama.cpp 直接认出 ROCm0 + ROCm1（各 32G）	识别正常
2	两卡各限 250W，跑双卡单实例（--split-mode layer）	跑到"生成"阶段"啪"一声整机断电重启
3	怀疑限功不够，降到 210W（GPU 总功耗仅 420W）	还是断电
4	重启后确认崩溃瞬间的功率确实 = 210W	彻底排除"功率上限太高"
5	换供电接口再试	依旧断电
6	最后发现：连发一句"你好"都会重启	关键线索

转折点：一句"你好"就重启

这一条把整个排查方向掰过来了。

如果光是满载跑长任务才断，那还能怀疑"持续功耗过高"。但发一句"你好"（输出不到 10 个 token）也断，说明问题不在持续负载上：

GPU 从空闲 12W 被唤醒到满载 300W+，这个瞬间跳变才是凶手。

判据链总结

降功率 → 仍然断电            ⇒ 不是"功率上限设太高"
崩溃时功率确实等于设定值      ⇒ 不是"限功没生效"
单卡同功率长期稳定            ⇒ 卡本身没问题
发一句"你好"就重启            ⇒ 不是持续负载，是瞬态跳变 ← 关键

断电后的后遗症

反复跳闸几次后，只有一块卡被 amdgpu 接管了（dmesg | grep 'Initialized amdgpu' 只有一条、/dev/dri 里缺 card0），需要重启系统才能恢复。此时另一张卡物理上等于不存在（不耗电，对供电反而"安全"）。

五、为什么 1300W 电源也不够？（分析）

先算总账：根本不是"瓦数不够"

单卡：276W(GPU) + 170W(双路CPU) + ~100W(平台) ≈ 546W
双卡：420W(GPU) + 170W(CPU)   + ~100W(平台) ≈ 690W
                                  1300W 电源 → 利用率仅 53%

总功率余量巨大，所以"1300W 不够"这个方向一开始就是错的。

真相方向：瞬态尖峰 + 单路 12V

证据一：power1_cap 根本拦不住尖峰

单卡实测（0.15 秒采样，120 个点）：

平均 278 W     ← 贴着 cap 280W，说明 cap 在生效
最大 335 W     ← 但尖峰冲高 20%！
最小 181 W

cap 是平均值控制，控制回路有延迟。GPU 在微秒级尺度上可以瞬间抽走远超 cap 的电流。

证据二：现代显卡的瞬态特性

• 现代 GPU 的瞬态峰值可达稳态的 1.5~2 倍（ATX 3.0 规范正是为此要求电源支撑 200% 峰值）
• AMD 卡在这块尤其出名（RDNA3 的 7900XTX 就因尖峰太猛有过不少翻车案例）
• 两张卡同时从空闲跳到满载，尖峰叠加 → 单路 12V 电流跳变极猛

推论（待验证）：

1300W 是总功率，但电源的 12V 是多路分配的。显卡走的那一（几）路 12V，在瞬态瞬间电流超出该路 OCP（过流保护）阈值 → 电源直接保护性关断。
这也解释了为什么降 cap 完全没用：cap 管的是平均功耗，管不了 dI/dt。

下一步打算（等验证）

1. 查电源铭牌的分路规格（各 12V 路的额定电流）
2. 换独立 PCIe 供电线（排除一分二/转接线瓶颈 —— 转接线是最常见的元凶）
3. 必要时换更大/单路 12V 更强的电源
4. 或者干脆双电源（显卡单独供电，用同步启动线）

六、附带实测：CPU 和内存能参与推理吗？

能，但在这台机器上等于自残。

配置	prefill	decode
GPU 全卸载（-ngl all）	~395 t/s	39.7 t/s
CPU 单路 16 线程（numactl --cpunodebind=0 --membind=0）	30 t/s	1.09 t/s
CPU 跨双路 32 线程（默认）	26 t/s	0.15 t/s ️

三个反直觉发现

① 跨双路比单路还慢 7 倍

16 线程（单路，内存本地）  = 1.09 t/s
32 线程（跨两路）          = 0.15 t/s   ← 慢 7 倍！

llama.cpp 的 CPU 后端用自旋屏障做线程同步，双路 Xeon 之间的 QPI 延迟远高于片内；32 个线程跨 socket 同步时，屏障开销直接吃光带宽，叠加远端内存访存惩罚 → 比只用一路还惨。线程多 ≠ 快。

② llama.cpp 的 --numa 三种模式全部无效

别指望参数绕过，只能靠 numactl 钉死单路。

③ 单路 1.09 t/s 是完全自洽的

单路 2 通道 DDR4-2400 = 38.4 GB/s
38.4 GB/s ÷ 24GB 模型 ≈ 1.6 t/s 理论上限
实测 1.09 t/s = 68% 效率 ✓

结论：decode 是纯带宽活（每 token 把权重读一遍）。模型能全装进显存时，让 CPU 参与纯属拖后腿；只有模型大于显存（如 70B Q4 = 39G 塞不进 32G）时，混合推理才有意义 —— 且那时必须钉单路。

七、MTP（FastMTP）实测数据

HauhauCS 的 FastMTP 补丁（改 src/models/qwen35.cpp，+27 行，实现 d2t draft 词表映射）+ 862MB 的 draft 模型。

关键指标是 mean len（平均接受长度），不是 acceptance % —— mean len 就是提速倍数：

8 段真实 agent 请求实测：mean len 在 1.73 ~ 3.27 之间，平均 2.46 → 约 2.5 倍提速。

规律：

• 代码生成 / 工具调用 JSON / 结构化输出 / 长文续写 → mean len 高（2.5~3.3），收益大
• 随机文本 / 开放式创作 → mean len 掉到 1.7 附近，收益有限

别把官方"3× 提速"当承诺 —— 收益完全取决于你生成内容的可预测性。

八、给后来人的建议清单

买之前

• 先算供电账，别只算显存账：加卡的收益可能被"必须换电源"的代价吃掉
• 老工作站平台（T7910/R7910 这类）标配电源是按
  当年 250W 级卡设计的，上现代 300W 卡要重算
• 查清电源是
  单路 12V 还是多路，以及显卡走哪一路

装机时

• 大显存卡（24G/32G）
  必须开 BIOS Above 4G Decoding
• RDNA4 需要
  6.12+ 内核（Ubuntu 24.04 要装 HWE）
• 装完 ROCm
  第一件事：usermod -aG render,video <user> 并重新登录
• systemd 跑服务要显式写
  SupplementaryGroups=render video + ExecStartPre=/bin/sleep 20

调优时

• power1_cap 只能限平均值，限不住瞬态尖峰 —— 这是本文最大的一个认知
• 显卡功率限制
  不是 llama.cpp 的参数，在驱动层 sysfs（/sys/class/drm/card*/device/hwmon/hwmon*/power1_cap）
• 抄启动命令前先
  --help | grep 验证参数名（新版改了一堆）
• btop 在 RDNA4 上用
  1.2.13，并覆盖 /usr/bin/btop 本体

排障时

• 降功率后仍然断电 ⇒ 不是功率上限问题，别再往下调了（硬件下限是 210W）
• 低频小请求也重启 ⇒ 是瞬态问题，不是持续负载
• 软件层所有证据都对得上还挂 →
  回头查硬件（供电/接线）
• 排查"明明修好了又崩"时，先
  diff 本地与远端脚本（本次踩过：本地旧副本覆盖了远端已修好的版本）

九、当前状态

✅ 单卡 R9700 32G + Qwen3.8-27B Q6_K_P + FastMTP + 128K 上下文
   decode 39.7 t/s / prefill 395 t/s / 280W / 显存 29.8G
   已服务化（systemd 开机自启 + 崩溃自愈）

❌ 双卡 64G：暂不可用，等解决供电问题

下一步：查电源分路规格 → 换独立 PCIe 线 → 必要时换电源 → 再战双卡。

本文数据均为实机实测，硬件为自购。有踩过同款坑或者对单路 12V 有经验的朋友，欢迎在评论区指教。