在 AMD Instinct GPU 上编译 vLLMROCm 7.x 抛出一个 Segmentation fault 却连 traceback 都不给是很多人卡住的第一关。遇到这种段错误先去 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 API Key再把 Codex 接到统一通道上让它陪你逐条对照 rocminfo 输出、pip 版本清单和编译日志。TaoToken 在这里只负责提供可用的模型通道真正敲 rocminfo、跑 pip install、执行 python -c 的人始终是你自己——Codex 不会远程 SSH 到你的机器也不会替你操作生产环境它做的只有一件事把你贴过去的文本和版本号排成一张对照表指出 Triton、PyTorch ROCm 后端和架构代码这三者里谁先对不上。经验上vLLM 的段错误可以粗分成三类编译期 hipcc/clang 段错误、导入期import vllm崩在 Triton、运行期非法指令。三类现象的排查顺序完全不同混在一起看就会觉得「明明都装了还是崩」。下面按这个顺序展开先抓现场证据再让 Codex 进对话做版本对照然后落到PYTORCH_ROCM_ARCH、HIP_PATH这些具体变量上重编最后才是显存和多卡参数。原始那篇部署指南里的环境验证、源码编译、显存优化、性能监控四段在排障场景下会被拆成「证据 → 对照 → 修复 → 复现」四步来走。1. 段错误现场vLLM 在 ROCm 7.x 上到底崩在哪一层1.1 先分清编译期 segfault 和导入期 segfault很多人一看到 Segmentation fault 就怀疑显卡、怀疑驱动其实这一步最该做的是分清崩溃发生在哪个进程阶段。编译期的段错误终端通常停在Building wheel for vllm或hipcc调用的那一行前后会夹着大段 kernel 编译输出导入期的段错误则出现在你敲完python -c import vllm之后屏幕上干净得只剩一个 Segmentation fault连 Python 层的异常都没抛出来运行期的报错往往是Illegal instruction或者 HIP 返回hipErrorNoBinaryForGpu这种才是典型的架构代码不匹配。把这三类分开直接决定了后面要不要重编。编译期崩溃要动编译器和环境变量导入期崩溃优先查 Triton 与 torch 的二进制兼容运行期崩溃基本锁定PYTORCH_ROCM_ARCH写错了型号。下面几条命令在你本地终端执行把输出留着后面要整体贴进对话python -c import torch; print(torch, torch.__version__, hip, torch.version.hip) python -c import triton; print(triton, triton.__version__) python -c import vllm; print(vllm, vllm.__version__) python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))注意最后一条虽然写的是torch.cuda在 ROCm 轮子里它映射到的就是 HIP 后端返回 True 只能说明后端被识别到了并不能证明算子全部可用这个区别后面还会再提。1.2 把 rocminfo、pip freeze、编译日志三份材料抓齐Codex 拿不到你的机器状态它能推理的全部依据就是你粘过去的文本所以材料一定要抓全。第一份是硬件架构信息用rocminfo找 Agent 段落里的 gfx 编号第二份是版本清单第三份是完整编译日志。三份都建议重定向到文件方便一会整段复制rocminfo | grep -E Name:|gfx | head -40 rocm-smi pip freeze | grep -Ei torch|triton|vllm|hip|rocm pip install --no-build-isolation -v vllm 21 | tee /tmp/vllm-build.log/tmp/vllm-build.log不要只截最后十行Triton 相关的失败信息常常混在中段。如果日志超过几千行可以先用grep -n -i segmentation\|fault\|triton\|error /tmp/vllm-build.log | head -50筛一遍把命中行前后各二十行一起贴出去比重贴整份日志更有效。材料准备的同时把通道准备好打开 TaoToken 注册账号在控制台创建一把 API Key记下模型广场里当前可用的模型 ID。Key 只用于 Codex 对话本身跟你的 ROCm 编译环境没有任何耦合别把 Key 写进PYTORCH_ROCM_ARCH这类变量里两者是完全不同层面的东西。2. Codex 通过 TaoToken 读日志config.toml 的三行关键配置2.1 API Key 与模型 ID 从哪里取Key 的创建入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 进去之后按控制台提示新建复制出来的字符串形如占位符YOUR_API_KEY。模型 ID 不要凭记忆写也不要自己加日期后缀猜一个一律以模型广场当时的列表为准——每家平台命名习惯不同猜错一个字符返回的就是 404 或者「模型不存在」白白浪费一轮排查时间。拿到这两样东西之后先在网页侧的模型对话里发一条测试消息确认这把 Key 是活的、模型 ID 是能命中的。这一步几十秒就能做完却能排掉后面一大半「配了但没反应」的假故障。2.2 在 ~/.codex/config.toml 里把 base_url 指向 TaoTokenCodex 的配置放在用户目录下的~/.codex/config.toml核心是声明一个自定义 provider把base_url填成统一入口再通过环境变量把 Key 喂进去。填进工具的地址用https://taotoken.net/api末尾不要带/v1这一点和很多 OpenAI 兼容文档里的写法不同多写一层路径会出现 404model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat环境变量在同一个 shell 里导出或者写进你的 shell 配置文件注意这里只能写 Key 本身不要写任何 URLexport TAOTOKEN_API_KEYYOUR_API_KEY保存后重新开一个终端随便提一句「你能看到我这条消息吗」验证连通性。如果 Codex 报 401先检查环境变量有没有在正确的 shell 里生效报 404 则检查base_url是否被误写成了带/v1的形式或者模型 ID 写错。2.3 把三份材料贴进对话的提问模板进对话之后不要只说「vLLM 段错误怎么办」信息量太低模型只能给你一堆通用建议。有效的提问是把证据铺开让 Codex 做交叉比对模板大致长这样第一段贴rocminfo里 gfx 开头的行第二段贴pip freeze中 torch、triton、vllm 三行第三段贴编译日志里命中段错误的前后文最后明确要求三列输出——「当前版本组合」「需要执行的核对命令」「可能的修复动作」。这样提问的好处是结论可验证。Codex 给出的每一条修复动作你都能在自己机器上跑一遍看结果跑完把新输出再贴回去形成一轮闭环。TaoToken 在这个闭环里承担的只是模型通道的角色Token 消耗在每次对照与解释上编译和验证依然在你本机完成。3. Triton 与 PyTorch ROCm 后端的版本对照怎么做3.1 用 torch 的源码 pin 锁定 Triton 版本ROCm 版 PyTorch 对 Triton 的依赖比 CUDA 版更敏感因为它背后是同一套 HIP 编译链。判断该装哪个 Triton最可靠的做法不是看 PyPI 上最新版是多少而是看你当前 torch 版本对应的源码 tag 里那份 pin 文件——PyTorch 仓库的.ci/docker/ci_commit_pins/目录下就放着 Triton 的提交锁定记录。把当前torch.__version__里的版本号对上 tag翻到那个文件就能知道官方测试时用的是哪一支 Triton。拿到目标版本之后先卸干净再装避免旧编译产物残留pip uninstall -y triton vllm pip install triton目标版本 python -c import triton; print(triton.__version__)如果 Codex 在对话里判断「Triton 版本超前于 torch ROCm 后端」它会建议你降级而不是升级。这时候别硬扛段错误本身就说明二进制层面的 ABI 已经对不上了继续往上装新版本只会让崩溃点从导入期挪到运行期更难定位。3.2 PYTORCH_ROCM_ARCH 与 rocminfo 的 gfx 代码对齐第二层对照是架构代码。rocminfo输出里会有一行类似Name: gfx942或者gfx90a而PYTORCH_ROCM_ARCH必须写成不带任何特性后缀的纯编号。有些机器会打印成gfx942:sramecc:xnack-这种形式冒号后面的部分属于运行时特性标记填进环境变量时要去掉只留gfx942。如果是混插机器可以用分号并列多个架构但每个都要确认对应真实硬件export PYTORCH_ROCM_ARCHgfx942;gfx90a echo $PYTORCH_ROCM_ARCH写错架构的后果非常有辨识度编译能过一加载模型就崩报错还常常是底层的非法指令而不是 Python 异常。原始部署文章里提到这一步能规避大部分架构不匹配问题从排障角度看它同时也是段错误和非法指令两类报错的分水岭——先确认PYTORCH_ROCM_ARCH和rocminfo一致再去怀疑 Triton。3.3 HIP_PATH、MAX_JOBS 与 no-build-isolation 的重编顺序修完前两层重编要按固定顺序来先清旧包再定变量最后带日志装。HIP_PATH指向 ROCm 安装根目录MAX_JOBS用满 CPU 核数缩短构建时间--no-build-isolation让构建过程复用你当前环境里已经对齐好的 Triton而不是另起一个隔离沙箱又装一份版本不一致的依赖export HIP_PATH/opt/rocm export MAX_JOBS$(nproc) pip install --no-build-isolation -v vllm 21 | tee /tmp/vllm-build-2.logMAX_JOBS不要盲目开到核数两倍内存不够时并行编译会触发 OOM Killer 把 hipcc 杀掉现象看起来像「编译到一半进程消失」很容易被误判成段错误。机器内存偏小的话把MAX_JOBS压到核数的一半更稳。4. 重编之后的最小验证别急着上大模型4.1 确认 HIP 后端与设备名编译完第一件事不是起服务而是确认后端真的被识别。跑一次设备和后端检查把输出和之前那份对比看torch.version.hip有没有变化、设备名是否列出你预期的 Instinct 型号python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0)); print(torch.version.hip) python -c import triton; print(triton.__version__) python -c import vllm; print(vllm.__version__)三条命令都能正常打印说明导入期段错误已经被消掉。如果第二条仍然崩说明 Triton 这一层还没对齐回到 3.1 重新核对 pin 版本不要靠反复重装碰运气。4.2 用最小模型加载替代全量服务启动真正跑通加载之前不建议直接拉几十 GB 的大模型。先用参数量小的模型走一遍权重加载和一次前向确认算子路径没有问题服务入口能不能正常起来也可以用参数帮助信息快速验证python -c from vllm import LLM; llm LLM(model小模型路径, tensor_parallel_size1); print(load ok) python -m vllm.entrypoints.openai.api_server --help /dev/null echo entrypoint ok小模型能加载、入口能打印帮助这两个信号同时拿到才说明编译层面的段错误已经解决接下来遇到的任何崩溃都属于显存或并行配置范畴排查范围一下子缩小了。4.3 段错误还在把新的 traceback 再贴一轮如果重编之后导入期仍然段错误不要推翻前面的结论从头再来。正确做法是抓新的日志和上一轮做差集新日志里如果 Triton 相关的报错行消失了说明方向对了只是还有别的问题如果崩在同一处大概率是环境里同时存在两个版本的 Triton可以pip list | grep -i triton确认有没有重复安装再python -c import triton; print(triton.__file__)看实际加载的是哪一个路径。把这轮的新日志、pip freeze里相关行、以及你实际执行的修复命令一起贴回对话让 Codex 做前后对比。这一步比第一轮更有价值因为此时版本组合已经变化模型能基于差异给出更贴近的下一步建议。5. 编译通过之后再谈显存与多卡两个容易互相掩盖的参数5.1 gpu-memory-utilization 与 OOM 的边界段错误解决后最常见的下一个报错是 OOM而 OOM 和非法指令的日志长得完全不一样前者是显存申请失败后者是二进制不兼容。参数上--gpu-memory-utilization不要一上手就顶到 0.95ROCm 栈本身有驱动缓冲和运行时开销把比例留在合理区间更稳具体到你的卡型和模型可以用小模型先试出上限再往上调。显存碎片化明显时--block-size会影响管理开销短序列偏多的业务用小 block 更省长序列为主的场景把 block 调大能减少调度负担。这两个参数在编译没通过之前调是没有意义的先解决崩溃再优化利用率。5.2 tensor-parallel-size 与 NUMA 绑核多卡推理上--tensor-parallel-size会按卡数切分权重卡间通信质量直接决定吞吐。同一 PCIe 根复合体下或走高速互联的卡通信延迟差异会体现在长序列生成的首字延迟上。进程绑核这一层可以用 numactl 把推理进程固定到对应 NUMA 节点避免多张卡的计算进程挤在同一批 CPU 核心上互相抢资源现象是并发一上来吞吐不升反降。判断瓶颈时可以先用固定并发跑几组对比把--tensor-parallel-size和绑核策略当成两个自变量一次只动一个记录吞吐变化这样得到的结论才可复现。参数调优阶段的性能数据建议连同当时的版本清单一起存档下次环境变化时能直接对照。6. 把这套排查沉淀成清单并接上下一次调用6.1 一份可复用的环境清单一轮段错误排查下来真正值钱的产出是那份版本组合torch 版本、triton 版本、PYTORCH_ROCM_ARCH取值、HIP_PATH、编译器版本、rocminfo 的 gfx 行。把它们写进一个env-check.sh每次换机器或升级 ROCm 之前跑一遍比出事之后再翻聊天记录快得多。驱动侧依旧建议先跑rocm-smi看温度功耗显存是否正常再用rocminfo确认架构代码这两步是原始部署流程里最值得保留的开场动作。排查方法上也要留个心眼Codex 给的是基于你贴过去文本的推理结论编译、执行、验证这三件事必须由你在本地完成任何一步都不要指望对话窗口替你跑命令更不要把它指向生产库或线上机器。把「生成建议 → 本地执行 → 结果回贴」当成固定循环效率和安全性都能兼顾。6.2 下一步从对话验证到长期写代码配置通了之后先在 TaoToken 模型对话 里用同一把 Key 发一条消息确认这次改的config.toml和模型 ID 都生效如果你打算把这类日志排查变成日常动作可以到 Coding Plan 看套餐额度是否压得住长期使用需要再建新 Key 或轮换旧 Key在 控制台 API Keys 里操作顺手也能看到这几轮排查消耗了多少 Token。想把这套流程挪到更顺手的命令行工作流可以对照 Claude Code 接入文档 里的环境变量写法把同一套 Base URL 和 Key 换到另一个工具上。至于 ROCm 版本清单建议每隔一段时间回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场对一次当前可用模型避免照着旧记录填了一个已经下线的 ID。 vLLM 在 ROCm 7.x 上段错误，TaoToken 让 Codex 对着 Triton 版本差排查
在 AMD Instinct GPU 上编译 vLLMROCm 7.x 抛出一个 Segmentation fault 却连 traceback 都不给是很多人卡住的第一关。遇到这种段错误先去 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 API Key再把 Codex 接到统一通道上让它陪你逐条对照 rocminfo 输出、pip 版本清单和编译日志。TaoToken 在这里只负责提供可用的模型通道真正敲 rocminfo、跑 pip install、执行 python -c 的人始终是你自己——Codex 不会远程 SSH 到你的机器也不会替你操作生产环境它做的只有一件事把你贴过去的文本和版本号排成一张对照表指出 Triton、PyTorch ROCm 后端和架构代码这三者里谁先对不上。经验上vLLM 的段错误可以粗分成三类编译期 hipcc/clang 段错误、导入期import vllm崩在 Triton、运行期非法指令。三类现象的排查顺序完全不同混在一起看就会觉得「明明都装了还是崩」。下面按这个顺序展开先抓现场证据再让 Codex 进对话做版本对照然后落到PYTORCH_ROCM_ARCH、HIP_PATH这些具体变量上重编最后才是显存和多卡参数。原始那篇部署指南里的环境验证、源码编译、显存优化、性能监控四段在排障场景下会被拆成「证据 → 对照 → 修复 → 复现」四步来走。1. 段错误现场vLLM 在 ROCm 7.x 上到底崩在哪一层1.1 先分清编译期 segfault 和导入期 segfault很多人一看到 Segmentation fault 就怀疑显卡、怀疑驱动其实这一步最该做的是分清崩溃发生在哪个进程阶段。编译期的段错误终端通常停在Building wheel for vllm或hipcc调用的那一行前后会夹着大段 kernel 编译输出导入期的段错误则出现在你敲完python -c import vllm之后屏幕上干净得只剩一个 Segmentation fault连 Python 层的异常都没抛出来运行期的报错往往是Illegal instruction或者 HIP 返回hipErrorNoBinaryForGpu这种才是典型的架构代码不匹配。把这三类分开直接决定了后面要不要重编。编译期崩溃要动编译器和环境变量导入期崩溃优先查 Triton 与 torch 的二进制兼容运行期崩溃基本锁定PYTORCH_ROCM_ARCH写错了型号。下面几条命令在你本地终端执行把输出留着后面要整体贴进对话python -c import torch; print(torch, torch.__version__, hip, torch.version.hip) python -c import triton; print(triton, triton.__version__) python -c import vllm; print(vllm, vllm.__version__) python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))注意最后一条虽然写的是torch.cuda在 ROCm 轮子里它映射到的就是 HIP 后端返回 True 只能说明后端被识别到了并不能证明算子全部可用这个区别后面还会再提。1.2 把 rocminfo、pip freeze、编译日志三份材料抓齐Codex 拿不到你的机器状态它能推理的全部依据就是你粘过去的文本所以材料一定要抓全。第一份是硬件架构信息用rocminfo找 Agent 段落里的 gfx 编号第二份是版本清单第三份是完整编译日志。三份都建议重定向到文件方便一会整段复制rocminfo | grep -E Name:|gfx | head -40 rocm-smi pip freeze | grep -Ei torch|triton|vllm|hip|rocm pip install --no-build-isolation -v vllm 21 | tee /tmp/vllm-build.log/tmp/vllm-build.log不要只截最后十行Triton 相关的失败信息常常混在中段。如果日志超过几千行可以先用grep -n -i segmentation\|fault\|triton\|error /tmp/vllm-build.log | head -50筛一遍把命中行前后各二十行一起贴出去比重贴整份日志更有效。材料准备的同时把通道准备好打开 TaoToken 注册账号在控制台创建一把 API Key记下模型广场里当前可用的模型 ID。Key 只用于 Codex 对话本身跟你的 ROCm 编译环境没有任何耦合别把 Key 写进PYTORCH_ROCM_ARCH这类变量里两者是完全不同层面的东西。2. Codex 通过 TaoToken 读日志config.toml 的三行关键配置2.1 API Key 与模型 ID 从哪里取Key 的创建入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 进去之后按控制台提示新建复制出来的字符串形如占位符YOUR_API_KEY。模型 ID 不要凭记忆写也不要自己加日期后缀猜一个一律以模型广场当时的列表为准——每家平台命名习惯不同猜错一个字符返回的就是 404 或者「模型不存在」白白浪费一轮排查时间。拿到这两样东西之后先在网页侧的模型对话里发一条测试消息确认这把 Key 是活的、模型 ID 是能命中的。这一步几十秒就能做完却能排掉后面一大半「配了但没反应」的假故障。2.2 在 ~/.codex/config.toml 里把 base_url 指向 TaoTokenCodex 的配置放在用户目录下的~/.codex/config.toml核心是声明一个自定义 provider把base_url填成统一入口再通过环境变量把 Key 喂进去。填进工具的地址用https://taotoken.net/api末尾不要带/v1这一点和很多 OpenAI 兼容文档里的写法不同多写一层路径会出现 404model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat环境变量在同一个 shell 里导出或者写进你的 shell 配置文件注意这里只能写 Key 本身不要写任何 URLexport TAOTOKEN_API_KEYYOUR_API_KEY保存后重新开一个终端随便提一句「你能看到我这条消息吗」验证连通性。如果 Codex 报 401先检查环境变量有没有在正确的 shell 里生效报 404 则检查base_url是否被误写成了带/v1的形式或者模型 ID 写错。2.3 把三份材料贴进对话的提问模板进对话之后不要只说「vLLM 段错误怎么办」信息量太低模型只能给你一堆通用建议。有效的提问是把证据铺开让 Codex 做交叉比对模板大致长这样第一段贴rocminfo里 gfx 开头的行第二段贴pip freeze中 torch、triton、vllm 三行第三段贴编译日志里命中段错误的前后文最后明确要求三列输出——「当前版本组合」「需要执行的核对命令」「可能的修复动作」。这样提问的好处是结论可验证。Codex 给出的每一条修复动作你都能在自己机器上跑一遍看结果跑完把新输出再贴回去形成一轮闭环。TaoToken 在这个闭环里承担的只是模型通道的角色Token 消耗在每次对照与解释上编译和验证依然在你本机完成。3. Triton 与 PyTorch ROCm 后端的版本对照怎么做3.1 用 torch 的源码 pin 锁定 Triton 版本ROCm 版 PyTorch 对 Triton 的依赖比 CUDA 版更敏感因为它背后是同一套 HIP 编译链。判断该装哪个 Triton最可靠的做法不是看 PyPI 上最新版是多少而是看你当前 torch 版本对应的源码 tag 里那份 pin 文件——PyTorch 仓库的.ci/docker/ci_commit_pins/目录下就放着 Triton 的提交锁定记录。把当前torch.__version__里的版本号对上 tag翻到那个文件就能知道官方测试时用的是哪一支 Triton。拿到目标版本之后先卸干净再装避免旧编译产物残留pip uninstall -y triton vllm pip install triton目标版本 python -c import triton; print(triton.__version__)如果 Codex 在对话里判断「Triton 版本超前于 torch ROCm 后端」它会建议你降级而不是升级。这时候别硬扛段错误本身就说明二进制层面的 ABI 已经对不上了继续往上装新版本只会让崩溃点从导入期挪到运行期更难定位。3.2 PYTORCH_ROCM_ARCH 与 rocminfo 的 gfx 代码对齐第二层对照是架构代码。rocminfo输出里会有一行类似Name: gfx942或者gfx90a而PYTORCH_ROCM_ARCH必须写成不带任何特性后缀的纯编号。有些机器会打印成gfx942:sramecc:xnack-这种形式冒号后面的部分属于运行时特性标记填进环境变量时要去掉只留gfx942。如果是混插机器可以用分号并列多个架构但每个都要确认对应真实硬件export PYTORCH_ROCM_ARCHgfx942;gfx90a echo $PYTORCH_ROCM_ARCH写错架构的后果非常有辨识度编译能过一加载模型就崩报错还常常是底层的非法指令而不是 Python 异常。原始部署文章里提到这一步能规避大部分架构不匹配问题从排障角度看它同时也是段错误和非法指令两类报错的分水岭——先确认PYTORCH_ROCM_ARCH和rocminfo一致再去怀疑 Triton。3.3 HIP_PATH、MAX_JOBS 与 no-build-isolation 的重编顺序修完前两层重编要按固定顺序来先清旧包再定变量最后带日志装。HIP_PATH指向 ROCm 安装根目录MAX_JOBS用满 CPU 核数缩短构建时间--no-build-isolation让构建过程复用你当前环境里已经对齐好的 Triton而不是另起一个隔离沙箱又装一份版本不一致的依赖export HIP_PATH/opt/rocm export MAX_JOBS$(nproc) pip install --no-build-isolation -v vllm 21 | tee /tmp/vllm-build-2.logMAX_JOBS不要盲目开到核数两倍内存不够时并行编译会触发 OOM Killer 把 hipcc 杀掉现象看起来像「编译到一半进程消失」很容易被误判成段错误。机器内存偏小的话把MAX_JOBS压到核数的一半更稳。4. 重编之后的最小验证别急着上大模型4.1 确认 HIP 后端与设备名编译完第一件事不是起服务而是确认后端真的被识别。跑一次设备和后端检查把输出和之前那份对比看torch.version.hip有没有变化、设备名是否列出你预期的 Instinct 型号python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0)); print(torch.version.hip) python -c import triton; print(triton.__version__) python -c import vllm; print(vllm.__version__)三条命令都能正常打印说明导入期段错误已经被消掉。如果第二条仍然崩说明 Triton 这一层还没对齐回到 3.1 重新核对 pin 版本不要靠反复重装碰运气。4.2 用最小模型加载替代全量服务启动真正跑通加载之前不建议直接拉几十 GB 的大模型。先用参数量小的模型走一遍权重加载和一次前向确认算子路径没有问题服务入口能不能正常起来也可以用参数帮助信息快速验证python -c from vllm import LLM; llm LLM(model小模型路径, tensor_parallel_size1); print(load ok) python -m vllm.entrypoints.openai.api_server --help /dev/null echo entrypoint ok小模型能加载、入口能打印帮助这两个信号同时拿到才说明编译层面的段错误已经解决接下来遇到的任何崩溃都属于显存或并行配置范畴排查范围一下子缩小了。4.3 段错误还在把新的 traceback 再贴一轮如果重编之后导入期仍然段错误不要推翻前面的结论从头再来。正确做法是抓新的日志和上一轮做差集新日志里如果 Triton 相关的报错行消失了说明方向对了只是还有别的问题如果崩在同一处大概率是环境里同时存在两个版本的 Triton可以pip list | grep -i triton确认有没有重复安装再python -c import triton; print(triton.__file__)看实际加载的是哪一个路径。把这轮的新日志、pip freeze里相关行、以及你实际执行的修复命令一起贴回对话让 Codex 做前后对比。这一步比第一轮更有价值因为此时版本组合已经变化模型能基于差异给出更贴近的下一步建议。5. 编译通过之后再谈显存与多卡两个容易互相掩盖的参数5.1 gpu-memory-utilization 与 OOM 的边界段错误解决后最常见的下一个报错是 OOM而 OOM 和非法指令的日志长得完全不一样前者是显存申请失败后者是二进制不兼容。参数上--gpu-memory-utilization不要一上手就顶到 0.95ROCm 栈本身有驱动缓冲和运行时开销把比例留在合理区间更稳具体到你的卡型和模型可以用小模型先试出上限再往上调。显存碎片化明显时--block-size会影响管理开销短序列偏多的业务用小 block 更省长序列为主的场景把 block 调大能减少调度负担。这两个参数在编译没通过之前调是没有意义的先解决崩溃再优化利用率。5.2 tensor-parallel-size 与 NUMA 绑核多卡推理上--tensor-parallel-size会按卡数切分权重卡间通信质量直接决定吞吐。同一 PCIe 根复合体下或走高速互联的卡通信延迟差异会体现在长序列生成的首字延迟上。进程绑核这一层可以用 numactl 把推理进程固定到对应 NUMA 节点避免多张卡的计算进程挤在同一批 CPU 核心上互相抢资源现象是并发一上来吞吐不升反降。判断瓶颈时可以先用固定并发跑几组对比把--tensor-parallel-size和绑核策略当成两个自变量一次只动一个记录吞吐变化这样得到的结论才可复现。参数调优阶段的性能数据建议连同当时的版本清单一起存档下次环境变化时能直接对照。6. 把这套排查沉淀成清单并接上下一次调用6.1 一份可复用的环境清单一轮段错误排查下来真正值钱的产出是那份版本组合torch 版本、triton 版本、PYTORCH_ROCM_ARCH取值、HIP_PATH、编译器版本、rocminfo 的 gfx 行。把它们写进一个env-check.sh每次换机器或升级 ROCm 之前跑一遍比出事之后再翻聊天记录快得多。驱动侧依旧建议先跑rocm-smi看温度功耗显存是否正常再用rocminfo确认架构代码这两步是原始部署流程里最值得保留的开场动作。排查方法上也要留个心眼Codex 给的是基于你贴过去文本的推理结论编译、执行、验证这三件事必须由你在本地完成任何一步都不要指望对话窗口替你跑命令更不要把它指向生产库或线上机器。把「生成建议 → 本地执行 → 结果回贴」当成固定循环效率和安全性都能兼顾。6.2 下一步从对话验证到长期写代码配置通了之后先在 TaoToken 模型对话 里用同一把 Key 发一条消息确认这次改的config.toml和模型 ID 都生效如果你打算把这类日志排查变成日常动作可以到 Coding Plan 看套餐额度是否压得住长期使用需要再建新 Key 或轮换旧 Key在 控制台 API Keys 里操作顺手也能看到这几轮排查消耗了多少 Token。想把这套流程挪到更顺手的命令行工作流可以对照 Claude Code 接入文档 里的环境变量写法把同一套 Base URL 和 Key 换到另一个工具上。至于 ROCm 版本清单建议每隔一段时间回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场对一次当前可用模型避免照着旧记录填了一个已经下线的 ID。