我是按照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）。

对照：加 MTP 之前同模型同双卡是 ~58 tok/s，加了自带 MTP 之后到 77.8+，提速约 34%。这个提速是接口口径的均速（completion_tokens ÷ 总耗时，含思考 token），不是峰值——自回归生成是稳态过程，均速就等于实际速度。

回答"体感慢"的常见疑问：这个模型思考很长，而思考部分和正文是同一个解码速度，所以体感慢的锅不在引擎，在思考长度。想快只能压思考（--reasoning-parser qwen3 已配，把思考抽到 reasoning 字段不污染正文），再往上提只能换模型。

五、一张表总结所有坑

一句话血泪总结：编译阶段 6 个坑里只有 GLIBCXX 是真坑（其余是虚惊或镜像问题），运行阶段 3 个坑个个"差一个参数就崩"。坑不可怕，可怕的是每个坑的报错都像别的事——NCCL 崩像驱动问题、OOM 像显存不够、import 崩像编译失败。诊断顺序永远是：看进程是不是真的活着（端口+显存）→ 看日志里第一条真实报错 → 再动手。