我的主板是
处理器 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+rocm723 wheel，干净替换，这一步没出幺蛾子。
二、编译阶段：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 崩像编译失败。诊断顺序永远是：看进程是不是真的活着（端口+显存）→ 看日志里第一条真实报错 → 再动手。
️ 别被工具自己的输出骗了：它报的