教程目标与适用范围
面向采购和机房交付，把GPU、CPU、内存、存储和风扇功耗转换为可验收供电条件。
本文依据对应项目的官方文档和官方仓库整理。命令用于建立可重复的基线环境，不承诺未经目标硬件实测的速度、显存或并发数字。
部署前检查
- 取得整机额定与最大功率
- 核对机柜PDU和插座制式
- 确认机房制冷能力
执行前请记录操作系统、驱动、容器、Python、框架和模型版本。生产机器不要直接使用无法追溯的第三方镜像或模型文件。
安装与启动
# Linux记录实时功率参考
nvidia-smi --query-gpu=power.draw,power.limit,temperature.gpu --format=csv -l 1
# 满载验收应同时采集PDU、服务器BMC和GPU指标关键参数说明
- 电源额定值不是日常功耗
- 设计应考虑峰值和冗余
- 供电、线缆和散热必须联合验收
第一次启动应使用较短上下文、单并发和保守资源参数。基础请求稳定后，每次只改变一个变量，并保存修改前后的日志和指标。
验证步骤
1. 空载记录基线 2. 逐卡增加计算负载 3. 执行整机持续满载 4. 检查温度、降频和PDU告警
验收不能只看“是否返回文本”。至少记录首个响应时间、完整耗时、输入输出规模、CPU/GPU利用率、显存峰值和失败原因，并验证服务重启后仍能恢复。
常见问题与处理
- 负载时重启：检查瞬时功率和电源
- 温度升高后降频：检查风道
- PDU过载：重新分配机柜负载
生产环境补充
服务对外开放前应增加认证、TLS、限流、超时、请求大小限制、日志脱敏、健康检查和监控告警。模型缓存与配置必须持久化，并保留能够回退的镜像和启动参数。
性能基线怎么记录
不要用一次手工对话判断部署质量。准备固定请求集，分别覆盖短输入短输出、长输入短输出和短输入长输出。先预热模型，再以1、2、4、8并发逐级测试；每一级记录首Token延迟、端到端耗时、输入输出Token、GPU显存峰值、GPU利用率、CPU和内存占用以及失败请求。测试客户端必须有足够性能，否则测到的可能是客户端瓶颈。
不同模型、精度、上下文和输出长度的吞吐数字不能直接横向比较。发布测试结果时必须同时附带GPU型号与数量、驱动、框架版本、模型提交或文件哈希、启动命令和请求分布。出现性能提升时还应复查输出质量，避免量化、截断或错误模板造成“速度更快但结果不可用”。
日志、监控和故障恢复
至少保留服务启动日志、请求状态码、请求耗时、模型加载事件和GPU错误。提示词和输出可能包含敏感信息，默认不应全文写入日志；确需留样时要脱敏并设置保存期限。GPU监控不能只看利用率，还要关注显存、温度、功耗、降频、Xid错误和进程退出。
主动执行一次恢复演练：停止进程或容器，确认服务能够按配置重新启动；模拟模型目录不可访问，确认健康检查不会误报正常；恢复上一份配置，确认客户端无需修改即可继续请求。只有完成恢复验证，重启策略才算真正有效。
升级与回退
升级驱动、镜像、推理框架或模型时不要覆盖唯一运行版本。新旧版本应使用不同目录或镜像标签，先在独立端口完成接口、质量和性能回归，再切换流量。保存上一版模型哈希、镜像摘要、依赖锁定文件、完整启动参数和环境变量；发生输出异常、性能回退或显存增长时，可以在同一硬件上恢复旧版本复核。
升级完成后检查客户端依赖的模型名、返回字段、流式结束方式、工具调用和错误码。所谓“兼容接口”并不保证所有可选参数在不同框架之间完全一致。
适用边界
设备规格不能代替现场测试，机柜、海拔、进风温度和相邻设备都会影响结果。官方文档可能随版本更新，实际执行前应打开原文核对当前命令和支持范围。
