关于双AMD RX7900XTX的使用感受
-
我的主板是
处理器 Intel Core i7-10700K @ 3.80GHz（8核16线程）
显卡 2张 AMD Radeon RX 7900 XTX（gfx1100）——XFX 一块 + Sapphire 一块
内存 62GiB（约64GB）ddr4
磁盘 1块 NVMe 1.9TB：系统盘 /（190G ext4，已用93%）+ 新加卷（1.7T ntfs，挂载到 /media/qiankun/新加卷）
系统 Ubuntu 22.04.5 LTS（内核 6.8.0-138-generic，GNOME Wayland）
主板是 华硕 z590 吹雪
部署到模型：Qwen3.8-27B-Uncensored-GPTQ-Int4-sym-G128-MTP-BF16我是按照https://github.com/StevenChenSE/vllm/tree/feat/dflash-perf-opt 这个项目去编译本地vllm的
关于速度的话其实我已经满意了，聚合测试下，2并发达到85t/s，4并发达到40t/s
长上下文的话接近200k是基本在50t/s左右
这个速度是我连接codex调用模型和hermes还有DSH调用模型观察出来的，不是机器短测试
模型运行起来，第一句话会久一点，大概1分钟半，第二句话的就基本在5秒左右就能看懂响应
用起来给我的体感特别好，就像用在线模型一样，然后我是驾校文员嘛，本地处理学员资料的话
调用Qwen3.8-27b的这个模型都能完成我的任务
用codex目前也在按照我的想法制作《我的世界》，看看多久才能做出来
Hermes作为主智能体就是工作干活
DSH基本作为玩具，经常就是调用模型来写插件
总体来说，已经非常棒了，两张卡二手，一张去年4000收的，一张今年4700收的，加上主板其他总价值在1w5左右的机器
耗电来说我正常使用下来白天干活，我睡觉就关机，耗电是4.5度电，运行时间早上9点到晚上12点
因为处理器是10代的原因，主板走的是PCIE3.08的通道 速度才这么些，如果我换了cpu支持PCIE4.0的话，速度将会更快，如果换了主板，支持原生Pcle4.016或者pcie5.0点话，我估计无论是输入速度或者输出速度，会更快
还有就是我用的双电源，另外一张电源是给一张显卡独立供电的
下面是我让我的hermes总结编译踩的坑，如果有什么其他问题可以给我留言，我会让我的小马获取数据发出来从 GitHub 源码编译 vLLM（ROCm 版）踩坑全记录
环境：Ubuntu 22.04 裸机 + 双 AMD Radeon RX 7900 XTX（gfx1100）+ ROCm 7.2
源码：GitHub fork（含 DFlash2 / MTP 投机解码魔改，feat/dflash-perf-opt 分支，1282 个提交）
安装方式：venv（Python 3.12）+pip install -e .可编辑安装
成品版本：0.1.dev1159+gd9d13a27b.rocm721（rocm 后缀 = ROCm 构建，这是正常的）先说结论：整条路走通了。编译阶段 6 个坑，运行阶段 3 个坑，全部踩平。最终测试结果：单请求实测 73.2 ~ 82.6 tok/s（Qwen3.8-27B GPTQ Int4 + 自带 MTP 投机解码，双卡 TP2，草稿接受率 84%）。下面按时间顺序讲每个坑怎么踩的、怎么解决的。
一、源码阶段：3 个坑
坑 1：GitHub 国内直连不通，大仓库拉不下来
症状：
git clone https://github.com/...直接超时，连网页都打不开。解决：换
ghfast.top镜像代理：git clone https://ghfast.top/https://github.com/StevenChenSE/vllm.git小仓库直连有时能过，但 vLLM 这种仓库体积大，必须走镜像。
ghproxy.net和mirror.ghproxy.com实测不通，别浪费时间试。坑 2：浅克隆让版本管理器报警（虚惊）
症状：编译一开始就刷警告：
UserWarning: "/home/qiankun/vllm-dflash" is shallow and may cause errors还顺带导致版本号算出来是
0.1.dev1159+g...这种丑样子，看起来像编译出问题了。解决：不用解决。
git clone --depth 1浅克隆会让 setuptools_scm 没法从 tag 推算正式版本号，于是退化成 dev 版本号。它自己说了"may cause errors"——实测没造成影响，功能完好。为了一个好看的版本号去git fetch --unshallow重拉几个 G，不值。坑 3：PyPI 的默认 wheel 是 CUDA 版，装了也白装
症状：之前图省事
pip install vllm装的是 PyPI 默认包，结果在 AMD 卡上直接失败——因为 PyPI 上的 wheel 是给 NVIDIA CUDA 编的。解决：AMD 卡必须走 ROCm 构建。先装了官方 ROCm wheel（
vllm 0.28.0+rocm723）顶着用，后来要跑魔改分支的投机解码功能，只能回退到源码编译：/home/qiankun/vllm-venv/bin/pip install -e /home/qiankun/vllm-dflash-e（editable）的好处：改一行源码，重启就生效，不用反复重新打包。安装时 pip 自动发现并卸载了旧的0.28.0+rocm723wheel，干净替换，这一步没出幺蛾子。
二、编译阶段：3 个坑
坑 4：C++ 扩展编译时满屏 deprecated 警告
症状：编译 csrc 阶段（C++/HIP 代码编译成
.so）刷出一堆：csrc/cumem_allocator_compat.h:45:26: warning: 'hipError_t hipCtxGetCurrent(ihipCtx_t**)' is deprecated: This API is marked as deprecated and might not be supported in future releases看着很吓人，像要挂。
解决：不用管，全是警告不是错误。ROCm 在标一批旧 HIP API 弃用，vLLM 的兼容层还在用。只要最后看到
Successfully installed ... vllm-0.1.dev1159+...rocm721就是成功。判别标准只有一条：error 才是事故，warning 是噪音。坑 5：GLIBCXX_3.4.31 not found（最隐蔽的一个）
症状：编译明明成功了，一跑
import vllm直接崩：ImportError: /lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.31' not found (required by .../torch/lib/libtorch_python.so)torch 的 ROCm 版是按较新的系统 C++ 运行时编的，Ubuntu 22.04 自带的 libstdc++ 只有 GLIBCXX 3.4.28，差一个版本都不行。这个坑最隐蔽——它不在编译期暴露，编译全绿、安装成功，直到第一次 import 才炸。
解决：从 ROCm/torch 包里拿一个新版 libstdc++ 放到独立目录，启动时用
LD_LIBRARY_PATH指过去：# /home/qiankun/libs/libstdc++.so.6 携带 GLIBCXX_3.4.32 export LD_LIBRARY_PATH=/home/qiankun/libs:/opt/rocm/lib:/opt/rocm/lib64这个 export 必须写进启动脚本（
start-kernelogic.sh第一行），漏掉它 torch 就起不来。注意：这条只影响 vllm 自己的环境——我后来用系统 python 查 GPU 风扇的时候就因为没带这个路径，"GPU 负载测试"白跑了两分钟，GPU 根本没收到负载，还以为风扇有问题。教训：测 GPU 之前先确认 python 进程真的活着在吃卡。坑 6：编译日志没有时间戳，耗时算不清
症状：想知道编译到底花了多久，翻
vllm-build.log发现里面除了 pip 的输出什么都没有时间戳，948 行里全是 "Running command xxx: started / finished"。解决：用日志文件修改时间 + 启动日志里的时间戳交叉推算：编译完成时间（build log mtime 22:30 前后）到 serve 日志里第一条 worker 时间戳（23:05）的间隔，再加上引擎自报的 "compilation: 54.87 s"，基本能对上是十几分钟的量级。以后想精确计时，编译命令套一层
time pip install -e . 2>&1 | tee build.log就一劳永逸——这次是事后补的，没留干净数据，不装懂。
三、运行阶段：3 个坑
坑 7：双卡 TP=2 一启动就 NCCL 崩
症状：
--tensor-parallel-size 2启动直接崩，NCCL 通信初始化失败。解决：ROCm 双卡 IPC 的祖传问题，两行环境变量钉死：
export HSA_ENABLE_IPC_MODE_LEGACY=0 # 关旧 IPC 模式 export HSA_FORCE_FINE_GRAIN_AMDGPU=1 # 强制细粒度内存一个都不能少。TP=1 能跑但模型塞不下，TP=2 又必崩——卡就这两张，没得选，只能修。
坑 8：首次启动"卡死"3 分钟，其实是在编译
症状：启动后日志停在 CUDA graph 捕获进度条上，几分钟没动静，人已经准备 ctrl+c 了。
解决：等。真实数据在这台机器上的日志里写得明明白白：
init engine (profile, create kv cache, warmup model) took 174.56 s (compilation: 54.87 s) Capturing CUDA graphs (PIECEWISE): 27/27 [00:11] Capturing CUDA graphs (FULL): 15/15 [00:05]首次启动总耗时约 3 分钟：torch.compile 编译 55 秒 + Triton 按 shape JIT 编译 kernel + 两轮 CUDA graph 捕获（分段图 11 秒 + 完整图 5 秒）。这是正常流程不是死锁。之后缓存落盘，重启只要约 2 分钟。唯一的例外：清掉
~/.triton/cache会重新计时。坑 9：进程杀不干净，重启必 OOM
症状：APIServer 崩了（exit 1，日志里没 traceback），端口空了、
curl /health不通，感觉服务没了——但下次一重启就报：ValueError: Free memory on device cuda:0 (1.29/23.98 GiB) on startup is less than desired GPU memory utilization (0.95, 22.79 GiB)根因：vLLM 是多进程架构，主 API 进程崩了，Worker/EngineCore 会变成孤儿进程残留继续霸占显存。更坑的是
rocm-smi --showpids | grep python查不到它们——孤儿进程名是VLLM::Worker_TP/VLLM::EngineCor，不带 "python" 字样。解决：
rocm-smi --showpids # 找 VLLM:: 开头、显存占用非 0 的进程 kill -9 <PID1> <PID2> ... # Worker_TP0/TP1 + EngineCore 全杀 rocm-smi --showpids | grep VLLM # 确认清空再重启另外别用
pkill -9 -f vllm——会把自己 shell 命令里带 "vllm" 字样的部分一起杀掉，进程看起来"杀了又复活"，其实是 pgrep 匹配到了自己。判真伪只认两条：端口（ss -ltn）和显存（rocm-smi）。
四、最终测试结果（真实数据）
服务起在 8655 端口，模型为 kernelogic Qwen3.8-27B（GPTQ Int4 + 自带 MTP 投机解码，双卡 TP2）。
项目 结果 健康检查 /health返回 200单请求速度（400 token，实时实测） 400 tok / 5.5s = 73.2 tok/s 单请求速度（800 token，复测） 82.6 tok/s 稳定区间 77.8 ~ 82.6 tok/s MTP 草稿接受率 84%（接受 1 次出 2 个 token） 引擎初始化（首次） 174.56 秒（其中编译 54.87 秒） CUDA graph 捕获 PIECEWISE 27 档 11 秒 + FULL 15 档 5 秒 KV cache 10.99 GiB，max-model-len 200000 撑得住 对照：加 MTP 之前同模型同双卡是 ~58 tok/s，加了自带 MTP 之后到 77.8+，提速约 34%。这个提速是接口口径的均速（completion_tokens ÷ 总耗时，含思考 token），不是峰值——自回归生成是稳态过程，均速就等于实际速度。
回答"体感慢"的常见疑问：这个模型思考很长，而思考部分和正文是同一个解码速度，所以体感慢的锅不在引擎，在思考长度。想快只能压思考（
--reasoning-parser qwen3已配，把思考抽到 reasoning 字段不污染正文），再往上提只能换模型。
五、一张表总结所有坑
# 坑 阶段 症状 解法 1 GitHub 直连不通 拉源码 clone 超时 走 ghfast.top 镜像 2 浅克隆版本报警 编译 "shallow may cause errors" 虚惊，忽略 3 PyPI wheel 是 CUDA 版 安装 AMD 卡上直接失败 用 ROCm 构建（rocm 后缀） 4 HIP API deprecated 警告 编译 满屏 warning 是 warning 不是 error，忽略 5 GLIBCXX_3.4.31 缺失 运行 import 崩，最隐蔽 LD_LIBRARY_PATH 指新版 libstdc++ 6 日志无时间戳 计时 算不清编译耗时 以后 tee + 交叉验证 7 TP=2 NCCL 崩 运行 双卡通信失败 两行 HSA 环境变量 8 首启"卡死"3 分钟 运行 像死锁 等，实际在 JIT 编译 + 捕图 9 孤儿进程霸显存 运行 重启必 OOM rocm-smi 按 VLLM::精确杀一句话血泪总结：编译阶段 6 个坑里只有 GLIBCXX 是真坑（其余是虚惊或镜像问题），运行阶段 3 个坑个个"差一个参数就崩"。坑不可怕，可怕的是每个坑的报错都像别的事——NCCL 崩像驱动问题、OOM 像显存不够、import 崩像编译失败。诊断顺序永远是：看进程是不是真的活着（端口+显存）→ 看日志里第一条真实报错 → 再动手。
-
我也是这个版本，但是用的时候，容易死循环，单流速度确实挺快的，但是2流或是3流就直接卡死了，你这边有这些问题吗？
-
我也是这个版本，但是用的时候，容易死循环，单流速度确实挺快的，但是2流或是3流就直接卡死了，你这边有这些问题吗？
@farmer-node 没有诶，可能你不是死循环，而是思考内容太多太多了，思考开中就行，就是，medium
-
，
T terry 固定了此主题
-
，系统 取消固定了此主题
