1. 为什么要在AMD ROCm上折腾SenseNova U1.5 Lite先把结论摆在前面SenseNova U1.5 Lite这个量级的模型放在单卡192G显存的AMD Instinct加速卡上跑推理是一件性价比相当高的事情。显存够大意味着你可以把模型权重、KV Cache、中间激活值全部塞进显存不用做频繁的CPU-GPU数据搬运推理延迟能压得很低。而ROCm这套软件栈经过这几年的迭代在主流推理框架上的兼容性已经今非昔比不再是那个装完驱动就掉半条命的状态了。这篇文章面向的是手里有AMD加速卡、想跑大模型推理、但被ROCm环境配置和性能调优卡住的工程师。如果你之前只在NVIDIA CUDA生态里打转第一次接触ROCm那这篇内容基本能帮你把从驱动安装到推理服务上线的整条链路走通。我会把每一步背后的逻辑讲清楚包括为什么这么选、参数怎么算、坑在哪里。SenseNova U1.5 Lite本身是一个偏轻量的对话与生成模型参数量控制得比较克制但它对显存带宽和KV Cache管理有一定要求。192G显存这个配置说实话有点杀鸡用牛刀的意思但正因为显存充裕我们可以把batch size开大、把context length拉长在实际业务场景里获得更高的吞吐。这也是我选择在这个配置上做部署的核心原因——不是为了跑通而是为了跑好。ROCm的全称是Radeon Open Compute是AMD对标CUDA的一套开源异构计算平台。它包含驱动、运行时、编译器、数学库等一整套组件。很多人对ROCm的印象还停留在文档少、报错多的阶段但实际用下来只要版本对齐、依赖装对稳定性是完全够用的。关键是要理解它的组件分层知道出问题该去哪个层面找原因。2. 环境准备与ROCm软件栈选型2.1 硬件与系统基线确认动手之前先把硬件和系统基线确认清楚这一步偷懒后面会加倍还回来。你需要确认加速卡型号是否在ROCm官方支持列表里这一点直接决定了你后面能不能用上完整的数学库加速。我这次用的是AMD Instinct系列加速卡192G显存版本系统是Ubuntu 22.04 LTS。系统版本的选择有讲究。ROCm对内核版本有要求太新的内核可能驱动编译不过太旧的又缺少必要的特性支持。Ubuntu 22.04搭配5.15系列内核是比较稳的组合社区验证充分。如果你用的是其他发行版建议先查一下官方兼容性矩阵别凭感觉上。确认命令很简单先看卡认没认出来lspci | grep -i amd rocminfo | grep -i gfxrocminfo能输出说明驱动层已经工作了。如果这条命令报找不到那说明ROCm还没装或者驱动没加载先别往下走。2.2 ROCm版本选择的核心逻辑ROCm版本不是越新越好。我的经验是跟着推理框架的官方推荐版本走而不是跟着ROCm最新版走。因为框架对ROCm的适配是滞后的你装了最新的ROCm框架可能还没适配编译直接失败。这次我选的是ROCm 6.2这个版本线。原因有三点第一主流推理框架对这个版本的支持已经成熟社区issue里踩过的坑基本都有解第二PyTorch的ROCm构建版本和它对齐第三这个版本的显存管理相比早期版本有优化长上下文场景下碎片问题改善明显。安装方式我推荐用官方apt源不要用源码编译。源码编译ROCm是个体力活动辄几个小时而且容易因为依赖版本问题失败。apt源安装虽然版本固定但胜在稳定可复现。# 添加ROCm官方源以6.2为例 wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | \ gpg --dearmor | sudo tee /etc/apt/keyrings/rocm.gpg /dev/null echo deb [archamd64 signed-by/etc/apt/keyrings/rocm.gpg] \ https://repo.radeon.com/rocm/apt/6.2 jammy main | \ sudo tee /etc/apt/sources.list.d/rocm.list sudo apt update sudo apt install rocm-hip-sdk rocm-libraries装完之后把当前用户加入render和video组否则访问设备会权限不足sudo usermod -aG render,video $USER这一步做完必须重新登录组权限才会生效。我见过太多人卡在这里以为是驱动问题其实是权限没刷新。2.3 Python环境与推理框架依赖Python环境我强烈建议用conda或者venv隔离别在系统Python里直接装。ROCm版的PyTorch和CUDA版是两套不同的wheel包混装必出问题。conda create -n sensenova python3.10 -y conda activate sensenova # 安装ROCm版PyTorch pip install torch torchvision --index-url \ https://download.pytorch.org/whl/rocm6.2装完验证一下GPU能不能被PyTorch识别import torch print(torch.cuda.is_available()) # ROCm下也返回True print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_properties(0).total_memory / 1024**3)最后一行应该输出接近192的数字。如果输出的是0或者报错说明PyTorch没链接到ROCm运行时检查一下LD_LIBRARY_PATH里有没有/opt/rocm/lib。注意ROCm环境下PyTorch仍然使用torch.cuda这个命名空间这是历史遗留不要以为是装错了CUDA版。判断依据是torch.version.hip有没有值。3. 模型加载与显存分配策略3.1 模型权重的精度选择SenseNova U1.5 Lite的原始权重通常是FP16或者BF16格式。在192G显存这个配置下其实你有很大的精度选择空间。我实测下来BF16在AMD加速卡上的表现比FP16更稳因为BF16的数值范围更大不容易在长序列推理时出现溢出。如果你追求极致吞吐可以考虑INT8量化。但量化会带来精度损失对话场景下可能表现为回答质量下降或者逻辑不连贯。我的建议是先用BF16跑通基线确认业务效果达标后再考虑量化压榨性能。不要一上来就量化否则出了问题你分不清是量化导致的还是部署本身有问题。模型加载的核心代码大概是这样from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path /path/to/sensenova-u1.5-lite tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) model.eval()device_mapauto会让框架自动分配显存。但在单卡192G的场景下其实不需要分片直接model.to(cuda)更直接避免框架做多余的显存规划。3.2 KV Cache显存占用估算这是很多人忽略的一环。KV Cache的显存占用和batch size、序列长度、层数、注意力头数都相关。粗算公式是KV Cache显存 ≈ 2 × batch_size × seq_len × num_layers × num_kv_heads × head_dim × dtype_bytes以SenseNova U1.5 Lite为例假设num_layers32num_kv_heads8head_dim128dtype是BF162字节那么单个token的KV Cache占用是2 × 1 × 1 × 32 × 8 × 128 × 2 131072 字节 ≈ 128 KB/token如果你要支持8192的上下文单个请求就是1GB左右。batch size开到16就是16GB。192G显存减去模型权重假设30G左右剩下的空间足够你开很大的batch和很长的上下文。这个估算的意义在于你要提前知道显存预算怎么分而不是跑起来之后OOM了再猜。我一般会预留20%的显存作为缓冲防止推理过程中的临时激活值把显存打满。3.3 显存碎片与分配器调优ROCm的显存分配器在长时间运行后可能产生碎片表现为明明显存够但就是分配失败。这个问题在长上下文、大batch场景下尤其明显。缓解手段有两个。一是设置环境变量让PyTorch使用更激进的缓存策略export PYTORCH_HIP_ALLOC_CONFexpandable_segments:True这个配置允许分配器扩展已分配的段而不是频繁申请新段能显著降低碎片率。二是控制请求的序列长度分布避免长短请求混杂导致显存块大小不一。如果你的业务允许把长请求和短请求分开处理效果会好很多。提示expandable_segments在ROCm 6.2上已经比较稳定但如果你用的是更早的版本建议先在小规模场景验证避免引入新的不稳定因素。4. 推理服务部署与性能调优实操4.1 推理框架选型对比跑推理不一定非要用原生transformers那个吞吐上不去。生产环境我一般会在vLLM和TGI之间选。这两个框架对ROCm的支持都在持续完善但成熟度有差异。框架ROCm支持成熟度吞吐表现部署复杂度适用场景vLLM较好社区活跃高PagedAttention加持中等高并发在线服务TGI一般适配滞后中高中等标准化API服务原生transformers好低低调试、验证我这次选的是vLLM。核心原因是它的PagedAttention机制对KV Cache的管理更高效在长上下文场景下显存利用率明显优于其他方案。而且vLLM的ROCm分支更新比较勤遇到问题容易找到参考。安装vLLM的ROCm版本pip install vllm --extra-index-url \ https://download.pytorch.org/whl/rocm6.24.2 启动参数的计算与配置vLLM的启动参数直接决定性能表现不能照抄别人的配置。关键参数有这么几个--gpu-memory-utilization显存利用率上限。192G显存我一般设0.9留10%缓冲。设太高容易OOM设太低浪费显存。--max-model-len最大序列长度。这个要根据你的业务需求定。设太大浪费KV Cache空间设太小长请求会被截断。我这次设的是16384覆盖绝大多数对话场景。--max-num-seqs最大并发序列数。这个和batch size相关直接影响吞吐。192G显存下我设到64实测还有余量。--tensor-parallel-size张量并行度。单卡场景设为1。启动命令python -m vllm.entrypoints.openai.api_server \ --model /path/to/sensenova-u1.5-lite \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --max-model-len 16384 \ --max-num-seqs 64 \ --tensor-parallel-size 1 \ --port 8000启动过程中会打印显存分配日志重点看KV Cache分配了多少块。如果块数太少说明max-model-len或者max-num-seqs设大了需要回调。4.3 性能压测与瓶颈定位服务起来之后别急着上线先压测。我用的是vLLM自带的benchmark脚本模拟不同并发下的吞吐和延迟。python benchmarks/benchmark_serving.py \ --backend openai \ --model /path/to/sensenova-u1.5-lite \ --dataset-name sharegpt \ --num-prompts 500 \ --request-rate 10重点看三个指标吞吐tokens/s、首token延迟TTFT、单token延迟TPOT。吞吐反映整体处理能力TTFT反映用户感知的响应速度TPOT反映生成流畅度。我实测下来192G显存配置下SenseNova U1.5 Lite在并发32时吞吐能到比较理想的水平TTFT控制在几百毫秒内。并发继续往上加吞吐增长放缓说明计算单元成了瓶颈这时候加显存也没用得考虑多卡或者模型量化。如果发现吞吐上不去排查顺序是先看GPU利用率rocm-smi利用率低说明是调度或IO瓶颈再看显存带宽占用带宽打满说明是内存墙最后看CPU占用CPU打满说明是数据预处理拖后腿。4.4 ROCm特有的调优手段ROCm有一些CUDA没有的调优开关用好了能再榨出一点性能。第一个是HIP_VISIBLE_DEVICES控制哪些卡对进程可见。多卡场景下用来隔离任务。第二个是HSA_ENABLE_SDMA控制是否启用SDMA引擎做数据搬运。默认是开的但在某些拓扑下关掉反而更快需要实测。第三个是MIOpen的算法选择。MIOpen是ROCm的深度学习算子库它会为每个卷积/矩阵运算选择算法。可以通过环境变量强制使用特定算法export MIOPEN_FIND_MODEFASTFAST模式会跳过耗时的算法搜索直接用启发式选择启动快但可能不是最优。NORMAL模式会做搜索启动慢但性能好。生产环境建议用NORMAL把搜索结果缓存下来。注意MIOpen的算法缓存默认存在~/.config/miopen容器化部署时要记得把这个目录挂出来否则每次重启都要重新搜索。5. 常见问题与排查技巧实录5.1 部署阶段高频问题速查问题现象可能原因排查方向解决方法rocminfo找不到设备驱动未加载/权限不足检查dmesg、用户组重装驱动、加render组PyTorch识别不到GPUROCm运行时未链接检查LD_LIBRARY_PATH添加/opt/rocm/lib模型加载OOM显存预算不足看权重KV Cache估算降精度、减batch推理结果乱码精度溢出检查dtype换BF16吞吐远低于预期调度瓶颈rocm-smi看利用率调并发、查CPU5.2 几个我踩过的坑坑一驱动版本和ROCm版本不匹配。这个是最隐蔽的。ROCm 6.2要求驱动版本在某个区间内太新太旧都会出问题。我遇到过驱动太新导致HIP运行时崩溃的情况回退驱动版本就好了。装之前一定查官方兼容性矩阵。坑二容器里跑ROCm忘记映射设备。用Docker部署时需要把/dev/kfd和/dev/dri映射进去还要加--group-add video和--group-add render。少一个都跑不起来。坑三长上下文场景下显存缓慢泄漏。这个不是真泄漏是KV Cache没及时释放。vLLM的PagedAttention理论上会回收但如果请求异常中断块可能没归还。解决办法是设置请求超时让框架主动清理。坑四MIOpen首次运行极慢。因为它在做算法搜索。第一次启动可能要几分钟别以为是卡死了。把缓存目录持久化之后后续启动就快了。5.3 稳定性监控建议生产环境一定要上监控。ROCm提供了rocm-smi工具可以输出GPU利用率、显存占用、温度、功耗等指标。把它接入Prometheus配合Grafana做面板能提前发现异常。# 持续监控每2秒刷新 rocm-smi --showuse --showmemuse --showtemp --loop 2重点盯两个指标显存占用是否持续上涨泄漏信号GPU利用率是否忽高忽低调度问题。显存占用在稳定负载下应该是平稳的如果一直涨说明有请求没被正确回收。6. 关于这套方案的一些个人体会跑完这一整套下来我最大的感受是ROCm生态的成熟度确实到了可以用于生产的阶段但它的坑和CUDA不一样。CUDA的坑大多是版本兼容和API使用ROCm的坑更多在环境配置和组件对齐上。只要把驱动、运行时、框架这三层的版本关系理顺后面的调优逻辑和CUDA是相通的。192G显存这个配置说实话对SenseNova U1.5 Lite来说是相当宽裕的。我建议不要把显存全用来堆batch留一部分给长上下文和突发流量实际体验会更好。显存这东西宁可平时空着也别在高峰期OOM。最后分享一个我常用的排查思路遇到问题先分层。驱动层用rocminfo和rocm-smi验证运行时层用PyTorch的torch.cuda接口验证框架层用最小复现脚本验证。一层一层往下剥比盲目改配置高效得多。这套方法帮我在很多次深夜排查里快速定位了问题希望对你有用。