Capordia整理一份精简但可重建的初始材料
保留系统、应用程序及其依赖项的版本、启动流程以及一组小型代表性数据。补充预期的路径、权限以及验证输出的方法。此清单描述了一个已知的基准。对于变更，请在该基准之外创建一个候选版本；密钥仍保留在您的访问管理系统中。请指出缺失的项及其负责人，而不是用一句“环境已就绪”将其掩盖。
当您的组织有要求时，指定一人负责验收，另一人负责切换决策。他们必须在新处理成为团队其他成员所依赖的对象之前了解验收标准。下单时选择的 Ubuntu、PyTorch、Blender 或自定义偏好会指导准备工作，但不能替代对您应用程序的精确清点。
核实实际可见的资源
在交付时，请将检测到的型号、显卡数量及其显存与预期范围进行对比。同时还要记录项目所需、但仅凭 GPU 无法体现的要素：系统、工作空间、权限以及对目标位置的访问。任何差异都会成为需要处理的具体问题，不要假设规格表中未提及的 CPU、网络或磁盘能力。
在具备 nvidia-smi 的 NVIDIA 环境中，建议的命令会读取名称、该工具报告的总显存以及驱动版本。它既不能判定性能，也不能覆盖所有 CUDA 依赖。对于 AMD，请使用与所用硬件及所采用的 ROCm 组合相对应的文档；避免将 NVIDIA 的检查手段直接套用，作为 MI300X 正常运行的证明。
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv使用分项标准完成一次全流程验证
请依次检查访问、配置、数据加载、执行和导出。针对每个步骤，记录一项观察和一项决定。一个程序无错误地结束，并不一定生成了所有预期文件。反过来，显卡显示正常，也不能证明软件使用了所选的 GPU。
请在试用前设定可接受的结果。它可以是一定数量的文件夹、一张通过目视检查的图片，或一项数值标准。PyTorch 提醒，不同版本和平台之间无法保证完全可复现。因此，请与负责人一起选择适合该工作的容差；不要事后为了让测试通过而放宽它。
| 步骤 | 预期观察 | 失败时的决定 |
|---|---|---|
| 访问 | 获授权的人员能够进入正确的环境 | 在导入前修正访问权限 |
| 加载 | 测试集的所有输入均可读取 | 修正数据包或其权限 |
| 执行 | 处理过程使用预期资源并完成 | 找出依赖项或设置问题 |
| 结果 | 内容符合书面标准 | 暂停活动的扩展 |
| 导出 | 结果可从其目标位置使用 | 在切换前修正输出 |
完整示例：收到一百个文件夹，得到九十九个结果
在这个虚构案例中，一个团队将预处理版本 A 替换为版本 B。其清单标明了修改前后的代码、依赖项和输出格式；验收集仍然由相同的 100 个文件夹组成，编号从 001 到 100。版本 A 生成 100 个结果。版本 B 运行结束，但只导出 99 个不同标识：缺少文件夹 057。书面标准要求 100 个结果且无重复。因此，此时该变更被拒绝。
候选包中缺少文件夹 057 所需的一项依赖。团队在新版清单中恢复了该依赖，检查了这个文件夹，然后在修正后的候选包上重新运行全部 100 个输入。他们重新得到了 100 个不同标识，并从最终目标位置打开了该包。这次完整测试验证了该修正并不只是修复了那个孤立的个案。这一结果解决了所描述的差异；但它尚不能证明在更大规模或持续负载下的运行表现。
对比修改前后的清单，然后决定是否采用
变更说明只需几行：原因、修改的要素、保留的要素、标准和负责人。请保留一份基准配置的可用副本。如果您同时更改驱动、框架和数据格式，就会增加差异可能原因的数目。尽可能拆分；否则，请明确将这一整体视为一次范围更大的变更。
修正后，请让结果所有者确认新的基准版本。下表用于组织这一决策，并非所提供软件的清单。某个版本只有在完成约定的检查之后，才会成为基准版本。请为采纳日期和该版本适用的任务做好记录，以免两个人各自悄悄启动同一活动的两个变体。
| 要素 | 之前 | 修正后选定的候选版本 |
|---|---|---|
| 应用 | 版本 A | 版本 B，包含依赖修正 |
| 验收输入 | 100 个固定档案 | 同样的 100 个档案 |
| 要求的结果 | 100 个不同的标识符 | 100 个不同的标识符，格式符合要求 |
| 发布 | 团队使用的参考版本 | 经负责人同意后注明日期的采用 |
保留回退的可能性，且不混淆结果
在采用之前，请确认先前的参考版本仍能读取其输入并恢复其状态。区分候选版本的输出，避免重复发布，并明确谁有权决定回退。如果新软件会不可逆地修改工作文件，仅保留旧程序是不够的：还需要一个兼容的数据状态。迁移指南处理的是环境之间的切换；而这里的决定针对的是经过验证的软件变更。
付款确认和资源交付与这些技术检查相互独立。“我已付款”按钮仅表示一笔付款；它既不验证访问权限，也不验证软件变更。请在环境确实可访问时进行测试，然后将测试结果与内部档案中的订单参考号关联起来。
最终交付给一支能够运行和退出的团队
预期交付物是一份简短的档案：记录的环境、验收数据集、已通过的检查、剩余的偏差以及决定后续事项的人员。让未参与安装准备的人复查启动流程。如果此人必须询问某个关键路径或设置，请在移交运维之前补全档案。
还要规划最终的数据取回及其检查。常见的错误包括在验收前扩大负载、在诊断期间更换多个版本，以及直到截止日期才发现需要导出。无论周期是 3 天、7 天还是 30 天，都请在所选周期内为这些步骤预留时间，不要把它们当作必然瞬间完成的操作。
决策要点
检测到显卡就足以接受部署吗？
不够。检测只验证了硬件范围的一部分。还需要加载输入、运行软件、验证其结果并从其目标位置取回结果。每项检查都应有独立的判定标准。
更换 GPU 后输出必须完全一致吗？
这取决于您的处理任务。请明确哪些必须严格保持一致，哪些属于有合理依据的容差范围。记录版本和参数；不应假定任何软件和任何环境都能做到完全一致。
谁来决定某项偏差可以接受？
由相关判定标准的指定负责人决定，当偏差影响服务时，还需与切换决策人共同决定。执行测试的人负责描述观察结果；他不能自动取代业务负责人或数据负责人。