vLLM AMD GPU 90%功能对等：ROCm原生兼容与生产就绪实践

1. 项目概述：AMD 在 vLLM 上游测试组达成 90%+ 功能对等，意味着什么？

最近在 vLLM 的 CI（持续集成）流水线里，一个被反复提及的指标悄然跃升至 90% 以上——“AMD GPU 对等测试通过率”。这不是某个内部分支的临时数据，而是直接跑在 vLLM 官方上游 main 分支的自动化测试组结果。简单说，当你从 GitHub 拉下最新版 vLLM 代码、用 AMD GPU（如 MI250X、MI300 系列）编译部署后，它能通过官方 CI 中 90% 以上的功能验证用例，包括推理吞吐、PagedAttention 内存管理、连续批处理（Continuous Batching）、量化加载（AWQ/GPTQ）、LoRA 微调支持等核心能力。这个数字背后，不是“勉强可用”，而是 AMD GPU 在主流大模型服务框架中，正从“能跑通”迈向“可生产”的关键拐点。

我去年初第一次在 MI250X 上跑 vLLM 时，连 basic inference test 都要 patch 三处 CUDA kernel 才能过；到年中，社区补丁合入后，通过率卡在 62%；而今年 Q2 的 CI 报告里，这个数字稳定在 91.3%～94.7% 区间浮动。这意味着什么？对终端用户而言，你不再需要为 AMD 卡单独维护一个 fork 分支，也不必在部署文档里加一句“仅限 NVIDIA”。对开发者而言，vLLM 的--device cuda参数现在真正在语义上兼容 AMD —— 它调用的不是模拟层，而是直通 ROCm 运行时的原生路径。对基础设施团队而言，GPU 资源池可以真正混合调度：NVIDIA A100 和 AMD MI300X 在同一套 vLLM Serving API 下，共享相同的请求路由、监控埋点和扩缩容策略。这不是技术公关稿里的“支持”，而是 CI 测试用例这一硬性标尺下的实打实达标。尤其值得注意的是，这 90%+ 的对等率，是在不依赖任何闭源驱动魔改、不绕过 ROCm 标准接口的前提下达成的。它反映的是 ROCm 6.x 与 PyTorch 2.3+、vLLM 0.6.x 三者之间协同演进的真实水位线。

2. 核心设计思路拆解：为什么是“上游测试组”而非“下游适配”？

2.1 “上游测试组”不是口号，而是工程决策的分水岭

很多人看到“AMD 达成 90% 对等”，第一反应是“是不是又搞了个定制版 vLLM？”——恰恰相反，这个成果的根基，正是拒绝定制，拥抱上游。vLLM 官方 CI 流水线包含两套并行测试组：一套是nvidia-cuda，运行在 A100/H100 上，覆盖全部 287 个功能测试用例；另一套是amd-rocm，运行在 MI300A 上，同样执行这 287 个用例。关键在于，amd-rocm组的代码基线，完全同步于nvidia-cuda组所用的同一 commit hash。没有分支、没有条件编译宏、没有#ifdef ROCM的胶水代码。所有适配工作，都以 PR 形式提交到 vLLM 主仓库，并经过 NVIDIA 卡 CI 的反向验证——即：一个修复 AMD 问题的 PR，必须同时确保 NVIDIA 卡测试不退化。这种“双向门禁”机制，彻底堵死了“为 AMD 特供而牺牲通用性”的捷径。

我参与过早期 ROCm 移植时的代码审查，当时有个 PR 想用hipMemcpyAsync替代cudaMemcpyAsync，但只改了推理路径，没动 LoRA 加载逻辑。CI 直接挂掉，因为 NVIDIA 卡上的cudaMemcpyAsync在某些场景下行为略有差异，导致 LoRA 权重加载错位。最终方案是：把内存拷贝抽象成DeviceMemoryManager接口，NVIDIA 实现CudaMemoryManager，AMD 实现RocmMemoryManager，两者都遵循同一套内存生命周期契约。这种设计看似多写 200 行代码，却让后续新增的 FlashInfer 支持、FP8 推理等特性，都能自动继承 AMD 兼容性，无需二次适配。这就是“上游测试组”的真实代价与红利：前期投入翻倍，后期维护成本趋近于零。

2.2 90% 的阈值选择：聚焦“影响交付”的关键用例

为什么是 90% 而非 100%？这并非妥协，而是基于生产环境真实权重的理性取舍。vLLM 的 287 个测试用例中，我们按“对线上服务 SLA 的影响程度”做了三级分类：

• S 级（必须 100%）：基础推理正确性（输出 token 序列与 reference 一致）、OOM 保护机制（显存超限时优雅降级）、PagedAttention 内存碎片率 <5%。这部分共 43 个用例，AMD 当前通过率 100%。
• A 级（强推荐 ≥90%）：连续批处理吞吐稳定性（p95 延迟波动 <15%）、量化模型加载时间偏差 <20%、多实例并发隔离性（GPU 利用率互不影响）。这部分共 156 个用例，AMD 通过 142 个，占比 91%。
• B 级（可选 ≥70%）：冷门硬件特性支持（如 NVLink 多卡拓扑探测）、实验性算子（FlashAttention-3）、特定编译器链支持（HIP-Clang vs GCC）。这部分共 88 个用例，AMD 通过 52 个，占比 59%。

所谓“90% 对等”，指的就是 A 级用例的通过率。这些用例直接对应着客户最常抱怨的问题：为什么我的 Qwen2-7B 模型在 AMD 卡上 batch_size=32 时延迟抖动剧烈？为什么 AWQ 量化模型加载比 NVIDIA 慢 40%？为什么 4 卡 MI300X 并发时，第三张卡利用率总卡在 60%？解决这些问题，比让一个冷门的--enable-nvlink-topology参数跑通，对实际业务价值大得多。vLLM 团队甚至为此重构了 CI 的失败归因系统：当amd-rocm测试失败时，自动标注该用例所属等级，并关联到对应的 SLA 指标（如 p95 延迟、OOM 次数），让工程师一眼看出“这个失败会让客户 API 超时率上升多少”。

2.3 ROCm 与 CUDA 的“语义对齐”：不只是 API 替换

很多开发者以为 AMD 兼容就是把cudaMalloc换成hipMalloc，把__syncthreads()换成__syncthreads()（HIP 里名字一样，但实现不同）。这是巨大误区。真正的对等，是让 ROCm 运行时在行为语义上逼近 CUDA，而非字面替换。举三个典型例子：

• 内存分配器一致性：CUDA 的cudaMalloc默认使用 Unified Memory（UM），而 HIP 的hipMalloc默认是 Device Memory。如果直接替换，会导致 vLLM 的 PagedAttention 内存池无法跨 CPU/GPU 共享页表。解决方案是：在 ROCm 初始化时强制启用HIP_VISIBLE_DEVICES=0+ROCM_VISIBLE_DEVICES=0，并调用hipExtMallocWithFlags分配 UM 内存，且设置hipExtMallocWithFlags的 flag 为hipExtMallocFlagCoherent，确保缓存一致性行为与 CUDA 的cudaMallocManaged一致。

• Stream 同步语义：CUDA 中cudaStreamSynchronize(stream)会阻塞当前 CPU 线程，直到 stream 上所有任务完成；而早期 ROCm 的hipStreamSynchronize在某些驱动版本下存在“假同步”——返回时 kernel 实际未结束。vLLM 的 Continuous Batching 严重依赖 stream 同步精度。最终 fix 是：在 ROCm 6.1.1+ 中，强制使用hipEventRecord+hipEventSynchronize组合替代hipStreamSynchronize，因为 event 语义在 ROCm 中更严格对标 CUDA event。

• Kernel Launch 参数校验：CUDA 的cudaLaunchKernel对 block 数量无硬性上限，而 HIP 的hipModuleLaunchKernel在 MI300 上对gridSize.x * gridSize.y * gridSize.z有 2^31-1 的隐式限制。vLLM 的 dynamic batch size 逻辑曾在此踩坑：当用户请求 batch_size=1024 时，kernel launch grid size 计算溢出。解决方案不是改 batch size，而是将大 grid 拆分为多个小 kernel launch，用hipLaunchKernel的sharedMemBytes参数传递中间状态，复现 CUDA 的原子性语义。

这些细节没有写在任何官方文档里，全靠在 CI 失败日志里逐行比对cuda-gdb和roc-gdb的 stack trace，再结合 ROCm 源码注释反推。所谓“90% 对等”，本质上是对这些幽灵般差异的系统性填坑。

3. 核心技术实现与实操要点：从 CI 报告到本地部署

3.1 解读 CI 测试报告：如何定位你的 AMD 兼容性瓶颈

vLLM 的 CI 报告不是简单的“PASS/FAIL”列表，而是一份可深度钻取的诊断地图。以最近一次amd-rocm测试为例（commit:vllm-0.6.3-rc1），报告结构如下：

提示：不要只看通过率数字。重点关注 A 级模块中的失败用例名，它们直接对应你生产环境可能遇到的问题。例如test_batch_size_256_latency_stability失败，说明你的高并发场景必然存在抖动；test_awq_loading_time失败，则量化模型冷启动慢是已知问题。

进入具体失败用例详情页，你会看到：

• Failure Stack Trace：精确到第几行代码、哪个 HIP API 返回hipErrorLaunchOutOfResources
• ROCm Runtime Log：rocm-smi --showhw输出的 GPU 状态快照（显存占用、温度、PCIe link width）
• CUDA Equivalent Log：同一 commit 下 NVIDIA 卡的对应日志（用于行为对比）
• Reproduce Command：一键复现命令，如pytest tests/test_continuous_batching.py::test_batch_size_256_latency_stability -xvs --rocm-device=mi300a

我通常的做法是：先运行reproduce command，再用rocprof --timestamp on -o profile.csv python ...抓取性能火焰图。发现test_batch_size_256_latency_stability失败的根本原因是hipMemcpyAsync在大 buffer（>2GB）传输时，ROCm 驱动的 DMA 引擎调度策略与 CUDA 不同，导致部分 batch 的 memory copy 与 compute kernel 争抢 PCIe 带宽。解决方案不是降低 batch size，而是修改 vLLM 的Scheduler类，在schedule()方法中插入hipStreamWaitEvent显式同步，强制 memory copy 完成后再 dispatch compute kernel。

3.2 本地部署 AMD vLLM 的最小可行配置

想立刻验证 90% 对等是否对你有效？别急着拉 master 分支，先用经过 CI 验证的稳定组合：

# 环境前提：ROCm 6.1.1 + Ubuntu 22.04 + Python 3.10 # 1. 安装 ROCm 驱动（必须用官方 deb 包，禁用 snap 或第三方 repo） wget https://repo.radeon.com/rocm/apt/6.1.1/amdgpu-install_6.1.103001-1_amd64.deb sudo apt install ./amdgpu-install_6.1.103001-1_amd64.deb sudo amdgpu-install --usecase=dkms,rocm,opencl,mllib --no-opengl # 2. 安装 PyTorch for ROCm（vLLM 0.6.3 严格要求 torch==2.3.0+rocm6.1） pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1 # 3. 安装 vLLM（必须指定 --rocm 标志，否则默认编译 CUDA） pip3 install vllm --no-cache-dir --force-reinstall --no-deps # 然后手动编译：cd /path/to/vllm && python setup.py build_ext --inplace --rocm # 4. 验证安装（关键检查项） python3 -c "import torch; print(torch.cuda.is_available())" # 必须输出 True python3 -c "import vllm; print(vllm.__version__)" # 必须输出 0.6.3 python3 -c "from vllm import LLM; llm = LLM(model='facebook/opt-125m', device='cuda'); print('OK')" # 必须无报错

注意：--rocm编译标志是核心。vLLM 的setup.py会根据此标志启用hipcc编译器，并链接libamdhip64.so而非libcudart.so。漏掉此步，即使 ROCm 驱动正常，vLLM 也会 fallback 到 CPU 模式。

部署时最关键的参数是--device和--enforce-eager：

• --device cuda：强制使用 ROCm 后端（不是--device rocm，vLLM 统一用cuda字符串标识 GPU 设备）
• --enforce-eager：禁用 CUDA Graph（ROCm Graph 支持尚不成熟），避免hipGraphCreate相关 crash

实测下来，一个标准的 Qwen2-7B 模型在 MI300A 上，开启--enforce-eager后，吞吐量比关闭时仅下降 3.2%，但稳定性提升 100%（CI 中test_continuous_batching通过率从 72% → 91%）。

3.3 性能调优三板斧：让 AMD 卡跑出接近 NVIDIA 的效率

达到 90% 功能对等后，下一步是性能对等。我在 MI300A 上实测，通过以下三步调优，Qwen2-7B 的 tokens/sec 从 128 提升到 215（NVIDIA A100 为 232）：

第一板斧：显存带宽榨干术
MI300A 的 HBM3 带宽高达 5.2TB/s，但默认配置下常闲置。关键在于HSA_OVERRIDE_GFX_VERSION环境变量：

export HSA_OVERRIDE_GFX_VERSION=1100 # 强制启用 GFX1100 架构优化 export HIP_LAUNCH_BLOCKING=0 # 禁用 HIP 同步模式（默认为1，严重拖慢）

HSA_OVERRIDE_GFX_VERSION告诉 ROCm 运行时：这张卡是 MI300A（GFX1100），而非旧款 MI250（GFX90A），从而启用 HBM3 特有的 burst transfer 模式。实测开启后，vLLM的PagedAttention内存拷贝带宽从 1.8TB/s 提升至 4.3TB/s。

第二板斧：Kernel Fusion 激活
vLLM 的flash_attn内核在 ROCm 下默认未 fusion。需手动 patchvllm/model_executor/layers/attention.py：

# 在 _make_alibi_bias 函数末尾添加： if hasattr(torch, 'hip') and torch.hip.is_available(): # 强制启用 ROCm 的 fused flash attn from vllm.model_executor.layers.attention.ops.rocm_flash_attn import roc_flash_attn_varlen_func return roc_flash_attn_varlen_func(...)

此 patch 调用 ROCm 专属的roc_flash_attn_varlen_func，它将 attention 的 QKV projection、softmax、output projection 三步融合为单个 kernel，减少 HBM 访问次数。MI300A 上实测，单 token 推理延迟从 18.7ms 降至 12.3ms。

第三板斧：PCIe 通道锁频
MI300A 通过 x16 PCIe 5.0 连接主机，但 BIOS 默认启用 ASPM（Active State Power Management），导致链路在空闲时降速。必须在 BIOS 中关闭 ASPM，并在 Linux 启动参数中锁定：

# /etc/default/grub 中添加 GRUB_CMDLINE_LINUX="pcie_aspm=off" # 然后更新 grub 并重启 sudo update-grub && sudo reboot

验证命令：sudo lspci -vv -s $(lspci | grep "AMD" | head -1 | awk '{print $1}') | grep "LnkSta:"，确认Speed字段始终为16GT/s（PCIe 5.0），而非跳变的8GT/s或2.5GT/s。此项调优对 multi-GPU 场景影响最大，4 卡 MI300A 的 aggregate throughput 提升 22%。

4. 实操过程详解：从零部署 Qwen2-7B 到 AMD GPU

4.1 模型准备：为什么 AWQ 量化是 AMD 用户的首选？

在 AMD GPU 上部署大模型，量化不是“锦上添花”，而是“雪中送炭”。原因很现实：ROCm 的 FP16 tensor core 利用率目前约 65%，而 NVIDIA 的 Tensor Core 可达 92%。这意味着同型号显卡，AMD 的 raw compute throughput 天然吃亏。AWQ 量化（Activation-aware Weight Quantization）通过牺牲极小精度（<0.3% perplexity 上升），换取显存带宽和计算密度的双重提升。

Qwen2-7B 的 AWQ 版本（4-bit）在 MI300A 上表现：

• 显存占用：从 FP16 的 14.2GB → 4.1GB（下降 71%）
• 推理速度：tokens/sec 从 89（FP16）→ 215（AWQ）（提升 141%）
• 首 token 延迟：从 124ms → 87ms（下降 29.8%）

操作步骤：

# 1. 下载 AWQ 量化模型（HuggingFace Hub） # 注意：必须选择明确标注 "awq" 且 "rocm" 兼容的版本 # 推荐：Qwen/Qwen2-7B-Instruct-AWQ （由 vLLM 团队官方验证） # 2. 使用 vLLM 加载（关键参数） python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-7B-Instruct-AWQ \ --tokenizer Qwen/Qwen2-7B-Instruct \ --dtype auto \ --quantization awq \ --gpu-memory-utilization 0.95 \ --max-model-len 32768 \ --tensor-parallel-size 2 \ --enforce-eager \ --host 0.0.0.0 \ --port 8000 # 3. 验证 API（curl 测试） curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen/Qwen2-7B-Instruct-AWQ", "prompt": "Explain quantum computing in simple terms.", "max_tokens": 100 }'

注意：--quantization awq参数必须显式声明，vLLM 不会自动检测 AWQ 模型。--gpu-memory-utilization 0.95是 AMD 专用调优——ROCm 的显存碎片率比 CUDA 高，设为 0.95 可避免 OOM，而 NVIDIA 通常用 0.9。

4.2 连续批处理（Continuous Batching）实战：如何压测出真实吞吐？

vLLM 的核心优势是 Continuous Batching，但在 AMD 上需特殊配置才能发挥。标准压测命令：

# 使用官方 benchmark 工具（vLLM 自带） python -m vllm.benchmarks.benchmark_serving \ --backend vllm \ --dataset-name sharegpt \ --dataset-path ./sharegpt/sharegpt_html.json \ --tokenizer Qwen/Qwen2-7B-Instruct \ --request-rate 100 \ --num-prompts 1000 \ --output-file results_amd.json \ --trust-remote-code

但直接运行会失败，因为sharegpt数据集的 prompt 长度分布不均，导致 AMD 的PagedAttention内存池频繁 realloc。解决方案是预处理数据集：

# preprocess_sharegpt.py import json from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-7B-Instruct") with open("./sharegpt/sharegpt_html.json") as f: data = json.load(f) # 过滤掉长度 > 2048 的 prompt（AMD 的 PagedAttention 最佳窗口是 2048） filtered = [item for item in data if len(tokenizer.encode(item["conversations"][0]["value"])) <= 2048] # 截断到统一长度 1024，保证 batch 内 token 数稳定 for item in filtered: item["conversations"][0]["value"] = tokenizer.decode( tokenizer.encode(item["conversations"][0]["value"])[:1024] ) with open("./sharegpt/sharegpt_1024.json", "w") as f: json.dump(filtered, f)

压测结果解读重点看三项：

• Throughput (req/s)：请求吞吐，MI300A 实测 82.3 req/s（A100 为 89.1）
• Output Token Throughput (tok/s)：输出 token 吞吐，MI300A 实测 215 tok/s（A100 为 232）
• p95 Latency (ms)：95% 请求的首 token 延迟，MI300A 实测 112ms（A100 为 98ms）

差距最大的是 p95 延迟，根源在于 ROCm 的hipEventRecord在高并发下存在微秒级抖动。临时缓解方案：在 vLLM 的engine.py中，将event_record调用从stream改为default_stream，牺牲一点并行度，换取延迟稳定性。

4.3 多卡扩展：MI300A 的 4 卡部署避坑指南

MI300A 支持 4 卡互联（Infinity Fabric），但 vLLM 的 tensor parallelism 在 ROCm 下需额外配置：

# 启动命令（4 卡 MI300A） CUDA_VISIBLE_DEVICES=0,1,2,3 \ HIP_VISIBLE_DEVICES=0,1,2,3 \ ROCM_VISIBLE_DEVICES=0,1,2,3 \ python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-7B-Instruct-AWQ \ --tensor-parallel-size 4 \ --pipeline-parallel-size 1 \ --distributed-executor-backend ray \ --ray-address auto \ --host 0.0.0.0 \ --port 8000 \ --enforce-eager

关键环境变量解释：

• CUDA_VISIBLE_DEVICES：vLLM 代码中仍用 CUDA 字符串，必须设置
• HIP_VISIBLE_DEVICES：ROCm 运行时识别设备
• ROCM_VISIBLE_DEVICES：AMD 驱动层设备映射

常见问题及解决：

• 问题：4 卡启动后，只有卡 0 有负载，其余为 0%
  原因：ROCm 的hipSetDevice在多进程下未正确绑定。解决方案：在vllm/engine/llm_engine.py的_init_worker方法中，添加：

  import os hip_device_id = int(os.environ.get("HIP_VISIBLE_DEVICES", "").split(",")[rank]) hip.hipSetDevice(hip_device_id)

• 问题：raybackend 启动失败，报Failed to initialize Ray
  原因：ROCm 的libamdhip64.so与 Ray 的libarrow存在 symbol 冲突。解决方案：升级 Ray 至 2.9.3+，并在启动前设置：

  export LD_PRELOAD="/opt/rocm/lib/libamdhip64.so"

• 问题：4 卡吞吐未线性提升，仅达单卡的 3.2x
  根源：Infinity Fabric 带宽未满。需在 BIOS 中启用Infinity Fabric Link Width为x16，并确认rocm-smi --showhw中IF Bandwidth显示32GB/s（理论值）。实测开启后，4 卡吞吐从 682 tok/s 提升至 852 tok/s。

5. 常见问题与排查技巧实录：来自 CI 和生产环境的血泪经验

5.1 典型问题速查表

5.2 独家避坑技巧：那些文档不会写的细节

技巧一：ROCm 驱动版本与 PyTorch 的“婚姻匹配表”
ROCm 6.1.1 只与 PyTorch 2.3.0+rocm6.1 完全兼容。用 PyTorch 2.2.2 会导致torch.compile在 AMD 上静默失效（无报错，但 kernel 不 fusion）。验证方法：

python3 -c " import torch x = torch.randn(1024, 1024, device='cuda') y = torch.randn(1024, 1024, device='cuda') z = torch.compile(lambda a,b: a @ b)(x, y) # 如果 z 仍是 eager mode，说明 compile 失效 print(z.device) # 应输出 'cuda:0'，若为 'cpu' 则失败 "

技巧二：MI300A 的“温度墙”陷阱
MI300A 的 TDP 为 760W，但 BIOS 默认温度墙设为 85°C。当连续运行 30 分钟后，GPU 频率会从 1.8GHz 降至 1.2GHz，吞吐暴跌 35%。解决方案不是降温，而是主动降频：

# 在 /etc/rc.local 中添加（需 root） echo "performance" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "0 1500" > /sys/class/drm/card0/device/pp_od_clk_voltage # 锁定 GPU 频率 1.5GHz

实测 1.5GHz 持续运行 2 小时，温度稳定在 72°C，吞吐波动 <2%，比动态频率更可靠。

技巧三：vLLM 日志里的“ROCm 黑话”
vLLM 的 debug 日志中，[INFO] Using ROCm backend是假消息——它只表示编译时启用了 ROCm，不代表运行时真的用上了。真正在用 ROCm 的标志是：

• 日志出现hipMalloc、hipMemcpyAsync字样
• nvidia-smi命令无输出（正确），但rocm-smi有输出
• cat /proc/driver/rocm/version返回非空

如果看到cudaMalloc字样，说明 vLLM fallback 到了 CUDA 模拟层（通常因libamdhip64.so加载失败）。

5.3 CI 失败的黄金排查流程

当你的本地部署遇到 CI 中的同类失败，按此顺序排查（已验证 92% 的问题可定位）：

1. 第一步：确认 ROCm 基础健康

   rocm-smi --showhw # 检查 GPU 状态、温度、PCIe link width rocminfo # 检查 HIP 运行时版本、设备数量 hipconfig # 检查 HIP 编译器路径

2. 第二步：复现 CI 的 exact command
   从 CI 报告中复制Reproduce Command，不要修改任何参数。哪怕你觉得--rocm-device=mi300a多余，也必须带上。

3. 第三步：抓取 HIP 级别 trace

   rocprof --timestamp on -o trace.csv --hsa-trace python reproduce_cmd.py # 分析 trace.csv，查找第一个 `hipError` 或 `hipEvent` 超时

4. 第四步：对比 CUDA 等价日志
   在同一台机器（如有 NVIDIA 卡）或 CI 的nvidia-cuda报告中，找到相同用例的日志，逐行比对：

   • kernel launch 参数（grid/block size）
   • memory allocation size
   • stream synchronization 点

5. 第五步：最小化复现
   将失败用例提取为独立脚本，逐步注释掉非核心代码，直到找到触发点。例如test_lora_merge_during_inference失败，最终定位到torch.nn.functional.linear在 ROCm 下对bfloat16输入的 bias 加法有精度误差，解决方案是强制 cast bias 为float32。

我在 MI300A 上部署 Qwen2-7B 的第 7 次失败，就是卡在test_lora_merge，按此流程，从rocproftrace 发现hipMemcpyAsync传输 bias 时，hipMemcpyKindDefault被误判为hipMemcpyHostToDevice，导致数据错位。补丁只有一行：hipMemcpyAsync(dst, src, size, hipMemcpyDeviceToDevice, stream)。这种细节，只有在 trace 里才能看见。

6. 生产环境落地建议：从 CI 通过到业务稳定

6.1 监控体系必须增加的 3 个 AMD 专属指标

NVIDIA 环境的监控（如nvidia-smi、DCGM）对 AMD 不适用。生产环境必须部署 ROCm 原生监控：

• rocm-smi --showuse的GPU use (%)：注意这不是利用率，而是“active cycles / total cycles”，需结合--showmemuse的VRAM use (%)判断是否瓶颈在显存。
• rocm-smi --showfwinfo的Firmware version：MI300A 的固件 bug 会导致