团队验收 GPU 配置

在资源交付前准备好决策

先从一个已完成的工作单元入手：一个已充实并导出的文件夹、一批已由接收方打开的渲染结果，或一次附带其输出的评估。把业务标准写在技术标准旁边。程序可以无报错地结束，却产出无法使用的结果。反过来，仅一次得到正确结果，也还不能证明团队懂得重跑工作并取回文件。

保留影响负载的参数：输入量、精度、批次大小、并发度和依赖项。区分独立作业队列、将计算分摊到多张卡的单个任务，以及持续接收请求的服务。这三种组织形式有不同的验收标准。仅凭一行“GPU 强大”无法让任何人做出判断。

项目负责人应在测试前确定标准。运维方准备访问权限，应用负责人提供已知的启动方式，接收方验证输出。同一人可以承担多个角色；但每个角色都必须有责任人和替补。在选定的时间段内，除有效计算外，还要预留安装、测试、可能的修正和最终导出的时间。

区分厂商、分配资源和实际任务

GPU 的参数表描述的是参考硬件。实际分配的机器还带来其他属性：可见设备数量、授予的访问权限、软件版本、可用存储卷和路径。基准任务则带来第三个层面：使用您的数据和设置所获得的结果。在表格中，请将每一行只归入一个层面，以免将厂商的特性当作对您服务的衡量。

不要仅凭显卡型号就推断 NVLink、特定拓扑或磁盘吞吐量。如果您的应用依赖这些属性，请将其转为明确的要求，让对方说明范围，然后在实际目标上验证。如果您的负载不需要它们，就不要将其作为人为的验收条件。

每 GPU 显存和显卡数量仍是两个不同的列。Capordia 的 B200 整机包含两块 GPU；这不足以让一个为单卡设计的程序获得统一显存。在期待收益之前，请先记录软件的分配机制。

在不修改设置的情况下建立清单

在 NVIDIA 上，以下命令会以 CSV 格式列出工具版本、GPU 列表及若干属性。请先查阅已安装的帮助：可用字段和功能取决于版本。NVIDIA 文档建议使用 UUID 等标识符来跟踪设备，因为索引顺序可能会变化。请保留工具输出的单位。这些采集不会启动 GPU 任务，也不能说明其性能。

对于 AMD，用“amd-smi version”获取版本，再用“amd-smi list --json”和“amd-smi static --json”获取清单和静态属性。请通过您所安装环境的帮助核对选项。AMD SMI 假定存在 AMD GPU 及其驱动；所查阅的文档为 AMD SMI 27.0.0。不可用的字段应保持“未确立”并注明原因，而不是填入猜测的值。

随后归档应用及其各库的版本。NVIDIA SMI 的 CUDA 横幅本身并不能证明已安装工具包的版本。对于 ROCm，请将 GPU、系统与版本的组合与相应的兼容矩阵进行核对。无论哪种情况，决定性的测试仍是在实际预期的环境中启动您的应用。

该文件提供需在您的机器上执行的 NVIDIA 和 AMD 命令，随后应附入验收记录。它们依据官方文档；本示例中未测量任何 CUDA 或 ROCm 结果。可下载的命令文件涵盖两个分支以及需附入验收记录的字段。

nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csv

将每项要求转化为可观察的检查

一条良好的验收标准将准则、方法与证明材料联系起来。例如，“足够的存储空间”可转化为：已明确工作位置、启动前已记录可用空间，并已从目标位置打开导出文件。所需容量取决于您的工作，包括中间文件；本指南不假定每块 GPU 都附带固定的磁盘容量。

在比较两组数据之前，先确定单位。十进制 1 GB 等于十亿字节；1 GiB 等于 2 的 30 次方字节。工具可能显示英文的 GB 和 GiB 表示法，或更小单位 MiB。请保留原始数值及其单位，再注明可能的换算。不要仅因规格表与实测数据之间的表示法差异而排除某种配置。

对于网络，请测试项目的实际数据流：相同目标、相同权限，并使用有代表性的文件类型。一次孤立的下载测试不足以验证数千个小结果的导出。如果项目会使用双向传输，请测量并记录两个方向的传输，然后写入您的时间计划所要求的阈值。若未在测试前确定阈值，观察到的耗时始终只是一次观察。

“未执行”状态胜过没有证明材料的一次成功。CSV 表格将观察、日期和证据这几列留空。只有当您解释了原因并保留决策者的同意后，才能删除超出范围的一项检查。

让基准任务成为一次可用的交接

选择一个经过授权、能体现实际工作约束的样本。极小规模的演示有助于验证启动；但它无法替代能暴露内存峰值、中间文件或最终导出的案例。请记录测试数据集的标识符、各版本和参数设置。共享文件夹引用密钥的提供方法，但不记录其具体值。

应用负责人从已知的启动状态执行一次完整循环，直至打开输出结果。随后，运维人员依据流程文件重新走一遍，而不依赖第一位操作员终端中隐藏的状态。目标是验证一次可用的交接：路径、权限、启动、日志位置与恢复。

还要明确可控失败之后会发生什么。临时输出必须能与被接受的结果区分开。验收档案不得虚构应用程序本身并不具备的恢复机制：它只记录现有机制，并指向迁移流程以组织被中断的批次。如果是数值计算，容差属于业务协议；逐位一致并非普遍要求。

比较多种配置时，请保持此协议不变。同时记录错误和需要重做的测试。最终决定可能因为某个选项简化了工作队列、验收或时间计划而更倾向它；但不必把单次记录转化为 GPU 的总体排名。

阅读填写示例，而不要把它当作一次测量

可下载示例「计划工作坊」完全为虚构内容。某团队希望处理一个由十二份技术文档组成的测试语料，然后获得一份可供审阅者查询的索引。这十二份文档只是组织方式上的假定；未给出任何速度、内存占用或 GPU 测量数据。H100 是框定范围的候选方案，需在审查软件和负载后确认。

应用负责人准备启动工作和所需凭证。运维团队检查访问权限与文件回收情况。负责结果的人员须确认每份文档都有可读的输出结果，并在索引中有对应引用。在该场景中，此人还无法从其目标位置打开导出文件。硬件和应用层面的条目仍处于未执行状态；因此该模拟决策为“投产受阻”。

此示例展示了如何落实责任并作出可解释的决定，而非编造成功。缺少导出证据并非简单的旁注：它恰恰阻碍了要求结果可回收的使用场景。再次尝试时必须重回该项检查、附上其凭证并为决定标注日期。仅在表格中删除该评论是不够的。

拒绝、附保留意见接受或推迟决定

一项未满足的阻断性标准将终止相关范围的验收。无法完成的检查不会默认变为通过：它会产生「受阻」或「未执行」状态、一项行动和一个责任人。避免用「保留」来掩盖工作的前提条件。如果输出无法回收，仅接受计算并不等于允许整条链路。

如果获准的使用范围有明确限制、临时方案经过验证且有人接受该范围，则次要事项可以适用保留意见。请写明复检期限以及未按期完成时的后果。仅限于一次测试的验收不等于生产验收。

验收记录保留决定、支持该决定的各项检查以及仍未完成的检查。技术验收既不确认付款，也不确认合同日期：这些跟踪事项各自保留其参照。一旦标准达成，团队向运维方移交启动方式、版本、数据位置和退出流程。

下载并使用第 1 版验收档案

Markdown 模板用作封面和验收记录。CSV 检查表提供需自定义的检查项，其列包括证据级别、责任人、测试前确定的标准、方法、观察、凭证和状态。以 UTF-8 打开 CSV，使用逗号作为分隔符；结果字段有意留空。处理前请保留一份空白副本。

用文本编辑器打开模板，用电子表格打开检查表。将虚构示例调整为您的要求，然后在您自己的机器上记录观察结果。所提供的许可证允许在保留声明的前提下使用和改编；产品名称和外部文档各自保留其权利。

请使用这份验收记录来授权一个明确的范围，然后在版本、数据或运行模式发生变更时予以补充。它既不构成通用基准，也不保证不会出现中断。当需要迁移工作状态并说明每个批次的去向时，则由迁移指南接续处理。