加速卡验收不应只看设备能否点亮或跑完一次基准测试。要让加速卡采购验收标准与渠道选择真正服务于业务，应先确认卡要承担什么任务，再把任务转成可复现的测试项和合同指标。推理服务、模型训练、视频编解码及科学计算的负载特征不同，验收不能用一套分数代替所有场景。
先把业务负载拆成可测条件
验收前整理实际软件栈、输入规模、并发量和运行时长。优先使用脱敏后的真实样本；无法提供样本时，制作能代表数据尺寸、精度和批量的合成数据，并记录生成方式。避免只测设备厂商提供的演示程序，因为它未必覆盖部署时的框架、驱动和数据处理流程。
- 推理：记录模型、输入尺寸、精度模式、并发请求数，观察推理吞吐、平均时延和尾延迟。
- 训练或批量计算：固定数据规模、批量大小和计算精度，记录每步耗时、显存占用及任务是否中断。
- 视频处理：若业务依赖硬件编解码，使用目标编码格式、分辨率和并行任务数验证；仅支持计算的卡不能据此推定具备编解码能力。
把版本也纳入记录：操作系统、驱动、运行库、框架及应用程序版本均应固定。验收过程中更改其中一项，就要标记为新的测试条件，避免把软件变化误判成硬件差异。
按风险安排测试顺序
先验证功能与兼容
收货后核对设备型号、数量和外观，再安装到目标主机，确认系统能识别设备、驱动正常加载，并能调用业务所需的计算或编解码能力。随后运行框架级小任务，检查结果是否正确。建议留存命令、日志、软件版本和错误信息，便于双方复核。
再测性能与持续运行
性能测试至少设置空闲基线、典型负载和预期高峰负载。每种条件重复运行，记录吞吐、时延、错误率、显存占用及温度等监控数据。先短测排除配置错误，再做持续负载观察；可把数小时作为初步稳定性窗口，关键生产用途则按业务连续运行时长延长至一夜或更久。时长不是统一合格线，应在合同或测试方案中预先约定。
- 固定主机、软件版本、输入样本和测试脚本，保存初始配置。
- 执行功能正确性测试，再逐级增加并发或数据规模。
- 按约定时长连续运行，记录降频、报错、任务退出和性能波动。
- 将结果与合同阈值及同条件基线比较；异常时重复测试并排查软件、散热、供电或主机配置因素。
合格阈值要对应业务目标，例如峰值请求下允许的最大时延、最低吞吐和可接受错误率。没有可靠基线时，先用小规模试运行建立参考，再确定采购批次的验收值，不宜套用脱离应用的统一分数。
渠道差异要反映在验收责任里
授权经销渠道通常便于确认货源、保修和原厂支持路径，但具体权益仍以合同为准；系统集成商可负责整机适配与联调，适合缺少部署能力的采购方，需写清软硬件故障的责任边界；二手或非授权渠道可能有成本优势，但设备历史、剩余保修及维修来源更难核实，应提高到货检测和退换约定的优先级。加速卡采购验收标准与渠道选择应一起评估，不能只比较报价。
合同应明确准确型号、交付状态、测试环境、性能口径、验收期限、故障处理方式及未达标的补测或退换安排。渠道承诺若没有落实到书面条款，不能替代验收依据。测试报告由双方确认并保存原始日志，避免只留一张汇总分数表。
常见问题
必须使用生产数据验收吗？
不一定。可使用脱敏样本或合成数据，但要覆盖真实任务的尺寸、精度和并发特征。
一次跑分通过就算验收合格吗？
不够。跑分只能说明特定条件下的性能，还应验证业务功能、软件兼容及持续运行稳定性。
如何处理测试结果不稳定？
固定环境后重复测试，保存日志，并检查软件版本、散热、供电和主机配置；确认原因后再按约定复测。
小批采购也需要测试方案吗？
需要。可缩减测试规模，但至少应书面约定样本、指标、运行时长和异常处理办法。
最终应以业务可接受的吞吐、时延和稳定性定义合格条件，并把条件写进合同及测试记录。这样制定加速卡采购验收标准与渠道选择，才能让测试结果既可复现，也能用于交付争议的判断。
