Stable Diffusion 3.5 NIM部署与验收清单

先列出部署边界

这类服务的验收对象不是“容器能运行”这一项，而是模型、运行环境、请求方式和输出结果能否被再次复现。资料包确认该微服务面向 Stable Diffusion 3.5 图像生成，并强调性能改进与企业部署简化，但没有给出可直接照抄的版本号、命令参数或硬件门槛。因此，下面涉及具体镜像、端口和字段的位置都应以当前官方文档为准。

准备 NVIDIA 环境

1. 确认主机使用 NVIDIA GPU，并记录 GPU 型号、显存容量、驱动版本、容器运行时版本和可见设备编号。不要把“有 NVIDIA 显卡”直接等同于“满足当前微服务条件”。
2. 打开当前的 Stability AI 或 NVIDIA 官方说明，核对目标模型、容器镜像、授权方式、支持的硬件架构、输入输出格式和网络端口。
3. 建立一个独立配置目录，至少保存环境变量模板、镜像版本、模型标识、端口、挂载目录和启动时间。密钥只通过环境变量或密钥管理工具注入，不写入公开配置。
4. 为测试准备一组固定样本。每条样本记录提示词、负面提示词、宽高、步数、随机种子、批量数量和输出格式；若某字段不被当前服务支持，就明确记为“未使用”。

启动图像服务

1. 先使用官方示例中的容器启动方式，不自行替换镜像标签或接口路径。启动前检查 GPU 是否被其他任务占用，并确认挂载目录有足够空间。
2. 启动后先看初始化日志，重点确认镜像拉取、模型加载、GPU识别、端口监听和错误退出状态。模型还未加载完成时，不要立即进行性能测试。
3. 使用服务文档提供的健康检查方式确认服务已就绪。若文档没有单独的健康接口，就通过一条最小请求验证响应状态，并把请求时间和响应摘要保存下来。
4. 只在单请求、单图片、固定尺寸的条件下完成第一次冒烟测试。成功后再进入多样本测试，避免把并发、分辨率和模型加载问题混在一起。

固定样本怎么测

固定样本的价值在于让不同配置之间可以比较。不要一边测试一边修改提示词、种子和尺寸，否则即使图片变化，也无法判断原因。

1. 建立样本表，每行对应一次请求，记录样本编号、提交时间、提示词摘要、模型标识、请求参数、响应状态和输出文件名。
2. 先顺序执行全部样本，记录首张图的等待时间、后续请求耗时和失败原因。首次请求可能包含模型初始化开销，应单独标注。
3. 使用系统监控工具记录测试期间的 GPU 利用率、显存占用、温度和功耗。不要把某一次瞬时读数当成稳定结论。
4. 在配置不变的情况下重复同一组样本，至少保留两轮结果。若随机种子或服务实现无法保证完全一致，就比较主体、构图、细节和缺陷，而不是只比较文件哈希。

性能记录模板

一个最小测试示例

可以把样本设计成容易人工判断的室内静物场景，例如：一只蓝色陶瓷杯放在浅木桌面上，窗边自然光，正面视角，主体居中，背景简洁，不包含可读文字。测试时固定尺寸、步数和随机种子，只改变服务配置。验收时检查杯子的颜色和形状是否稳定，桌面透视是否异常，边缘是否出现明显破碎，以及输出文件是否能正常保存和打开。

这个示例不是质量承诺，也不代表某个固定参数适用于所有部署。它的作用是提供一个低歧义、易对照的样本。正式业务还应加入人物、产品细节、复杂背景或批量请求等真实场景。

常见故障与修正

• 容器启动后立即退出：常见原因是镜像版本、授权变量、挂载目录或启动参数不匹配。先查看完整日志，再逐项对照当前官方说明，不要只重复重启。
• 找不到 GPU：可能是驱动、容器运行时、设备映射或权限配置不完整。先在宿主机确认 GPU，再检查容器内的设备可见性，最后核对运行时兼容性。
• 模型加载失败或显存不足：可能是模型版本不对应、其他进程占用显存或请求尺寸过大。先停止无关任务并使用最小测试条件，再确认官方支持的模型和硬件组合。
• 请求返回字段异常：可能是客户端仍使用旧接口格式，或请求路径与当前镜像不匹配。以当前容器文档为准更新字段，并保存一份原始响应用于比对。
• 速度波动明显：可能混入了首次加载、后台任务、不同尺寸或不同批量数。拆分冷启动与热运行数据，固定测试条件后再比较。
• 图片能生成但质量不稳定：可能是提示词过于复杂、参数没有固定或模型版本发生变化。先锁定提示词、种子和尺寸，再逐项改变一个变量。

发布前验收

• 模型标识、镜像摘要、驱动版本和 GPU 信息已经归档。
• 授权信息没有写入代码、日志公开目录或提交记录。
• 服务能正常启动，健康检查或最小请求可以得到预期响应。
• 固定样本已完成顺序测试和重复测试，首请求耗时已单独标注。
• 性能记录包含耗时、显存、GPU状态、请求条件和失败样本。
• 输出图片能够打开，尺寸、格式、文件命名和保存路径符合业务要求。
• 人工检查了提示词遵循、主体完整、构图、细节缺陷和异常内容。
• 已保存可回退的镜像、配置、模型标识和上一轮测试结果。
• 正式开放服务前已明确并发限制、超时策略、日志保留方式和失败重试规则。

验收通过的标准不是某个未经资料确认的固定速度，而是同一套条件下能稳定启动、稳定请求、完整记录并在出现变化时快速定位。这样部署后的服务才具备可维护性。