验收这件事，在很多算力项目里被当成”到货签收”：设备上架、通电开机、清单对得上，就签了字。可国产化目标真正被检验的时刻，恰恰是验收——立项文件里写的技术路线、可行性研究里承诺的自主可控程度，都要在这里被逐项对照。等到审计或上级检查来要材料，才发现当时的验收报告只写了设备型号和数量。中间缺的不是设备，是证据链。
验收为什么是合规关口，而不只是签收
三个常被混在一起的说法，对应三套完全不同的证据：设备是国产的，看产品资质与厂商文件；方案是信创的，看全栈适配与互认清单；项目是合规的，看采购程序、验收结论与归档是否闭环。只做到第一条，后两项在检查时都无法自证。
对采购方来说，验收报告是会被长期引用的文件——后续绩效评价、资产审计、等保与关基检查，都会回到这份结论。所以验收的写法应当可复核：测了什么、在什么条件下测、判定标准是什么，都要写清。
采购文件阶段就要把话说准
不少验收争议的根子其实埋在采购文件里。有三条经验。
其一，技术指标描述能力，不描述品牌。把”必须采用某厂商架构”改为”需支持某类并行计算编程模型与既有算子库”，既满足业务需求，也避免指向性条款。
其二，把资格性要求与评分项分开。产品认证、目录准入、兼容性互认属于能不能参与的门槛，不宜当成加分项反复加权，否则容易出现”资质齐全但跑不动业务”的结果。
其三，明确验收测试由谁提供负载与工具、按什么口径判定。这一条写进采购文件，后期能省下一轮扯皮。
合同里要落下的六类材料
设备清单之外，建议在合同中逐项约定交付物：产品资质与国产化相关证明文件；与操作系统、数据库、中间件、AI 框架的互认清单并注明适用版本区间；驱动、编译器、算子库与集群管理平台的授权范围及升级承诺，避免硬件买了软件另计；备件备卡比例、停产替代方案与供货周期；漏洞公告渠道、修复时限与固件来源签名要求；原有代码迁移、算子补齐与性能调优的责任方和验收口径。
这六类里，软件授权与迁移责任这两类常被忽略，也常在上线后被追加预算。
到货核验与性能验收的实操口径
到货环节做四件事：序列号与合同清单逐台对应、固件与驱动版本登记为基线、板卡与整机配置逐项核对、随机文档与授权文件归档。上架前再核一遍供电与散热余量、机柜承重与网络端口配套，避免到现场才发现缺光模块。
性能验收不要拿厂商标称峰值做判定。以真实业务负载跑：训练看集群扩展效率与断点续训表现，推理看长尾延迟与并发下的稳定性，混合负载看资源隔离。测试报告必须写明模型规模、并发数、精度设置与数据集来源，否则结论不可复现，等于没测。建议再加一轮故障注入，观察单卡或单节点退出后的降级与恢复表现。
归档清单与后续审计衔接
归档五类材料：采购文件与合同、产品与互认证明、到货与安装记录、测试报告与验收结论、资产台账与变更记录。台账要能回答四个问题：设备在哪、跑什么业务、固件什么版本、属哪次采购批次。
这套材料与等保、密评、关基检查的底稿高度重叠——资产清单、供应链信息、日志留存本来就要备，一次整理可以多处复用。
自查五条：采购文件有无指向性条款；合同是否约定互认清单与软件授权范围；固件版本是否登记为基线；性能报告是否写明测试条件；台账能否追溯到具体采购批次。
需要评估某类算力项目的验收材料准备，可先看国产 GPU 显卡的产品定位，或在询价页说明项目背景与验收要求；同类文章见方案与洞察。