教程目标与适用范围
面向受支持AMD GPU，在Linux中安装或使用官方容器验证PyTorch ROCm环境。
本文依据对应项目的官方文档和官方仓库整理。命令用于建立可重复的基线环境，不承诺未经目标硬件实测的速度、显存或并发数字。
部署前检查
- GPU位于ROCm支持列表
- 操作系统和内核符合兼容矩阵
- 主机设备节点和权限正常
执行前请记录操作系统、驱动、容器、Python、框架和模型版本。生产机器不要直接使用无法追溯的第三方镜像或模型文件。
安装与启动
rocminfo
rocm-smi
# 从ROCm官方PyTorch安装页选择与当前ROCm版本一致的容器或wheel
python -c "import torch; print(torch.__version__); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'CPU')"关键参数说明
- PyTorch仍通过torch.cuda命名空间访问ROCm设备
- torch.version.hip用于确认ROCm构建
- 内核、ROCm和框架必须按矩阵组合
第一次启动应使用较短上下文、单并发和保守资源参数。基础请求稳定后，每次只改变一个变量，并保存修改前后的日志和指标。
验证步骤
1. rocminfo确认设备 2. 创建张量并执行矩阵计算 3. 运行目标模型最小前向 4. 保存完整版本和容器摘要
验收不能只看“是否返回文本”。至少记录首个响应时间、完整耗时、输入输出规模、CPU/GPU利用率、显存峰值和失败原因，并验证服务重启后仍能恢复。
常见问题与处理
- 设备不可见：检查支持矩阵和权限
- wheel安装失败：核对Python和ROCm版本
- 算子缺失：确认模型依赖是否支持ROCm
生产环境补充
服务对外开放前应增加认证、TLS、限流、超时、请求大小限制、日志脱敏、健康检查和监控告警。模型缓存与配置必须持久化，并保留能够回退的镜像和启动参数。
性能基线怎么记录
不要用一次手工对话判断部署质量。准备固定请求集，分别覆盖短输入短输出、长输入短输出和短输入长输出。先预热模型，再以1、2、4、8并发逐级测试；每一级记录首Token延迟、端到端耗时、输入输出Token、GPU显存峰值、GPU利用率、CPU和内存占用以及失败请求。测试客户端必须有足够性能，否则测到的可能是客户端瓶颈。
不同模型、精度、上下文和输出长度的吞吐数字不能直接横向比较。发布测试结果时必须同时附带GPU型号与数量、驱动、框架版本、模型提交或文件哈希、启动命令和请求分布。出现性能提升时还应复查输出质量，避免量化、截断或错误模板造成“速度更快但结果不可用”。
日志、监控和故障恢复
至少保留服务启动日志、请求状态码、请求耗时、模型加载事件和GPU错误。提示词和输出可能包含敏感信息，默认不应全文写入日志；确需留样时要脱敏并设置保存期限。GPU监控不能只看利用率，还要关注显存、温度、功耗、降频、Xid错误和进程退出。
主动执行一次恢复演练：停止进程或容器，确认服务能够按配置重新启动；模拟模型目录不可访问，确认健康检查不会误报正常；恢复上一份配置，确认客户端无需修改即可继续请求。只有完成恢复验证，重启策略才算真正有效。
升级与回退
升级驱动、镜像、推理框架或模型时不要覆盖唯一运行版本。新旧版本应使用不同目录或镜像标签，先在独立端口完成接口、质量和性能回归，再切换流量。保存上一版模型哈希、镜像摘要、依赖锁定文件、完整启动参数和环境变量；发生输出异常、性能回退或显存增长时，可以在同一硬件上恢复旧版本复核。
升级完成后检查客户端依赖的模型名、返回字段、流式结束方式、工具调用和错误码。所谓“兼容接口”并不保证所有可选参数在不同框架之间完全一致。
适用边界
NVIDIA CUDA教程不能直接替代ROCm流程，消费级和数据中心GPU支持范围也可能不同。官方文档可能随版本更新，实际执行前应打开原文核对当前命令和支持范围。
