这是整套标准的“总尺子”。它会明确：
评测对象必须精确到具体产品线 + 具体软件栈组合；
评测覆盖哪些层：基础支撑层、核心工具层、框架适配层、管理监控层、支持闭环能力；
什么叫“最小等价适配”，什么属于不允许的换题、绕题、静默 fallback；
总分、首轮通过率、最终闭环率、原则性不兼容数如何统一口径；
哪些证据必须提交，哪些结论不能只靠截图或口头说明。
也就是说，这份文件负责回答：到底测什么，哪些算通过，哪些不算。
《AI 加速器软件生态公开评测打分表》
这不是普通表格，而是公开结论的统一出口。它会把：
每个技术子项的首轮状态 / 最终状态 / 过程扣分 / 最终得分；
问题级别、问题编码、核心证据路径；
厂商支持档位与闭环方式；
首轮通过率、最终闭环率、P1 / P2 / P3 问题数；
时间成本、文档与接口质量评级
统一收敛在同一张表里。
这份文件负责回答：最后怎么形成一份可横向比较、可公开引用的结果。
《AI加速器软件生态评测过程数据提交规范/模板》
这是这次新增的关键文件，也是过去最容易缺位的一块。
它会统一规定：
结果目录怎么建；
元数据、日志、脚本、运行产物、问题台账、支持记录怎么组织；
时间成本怎么记；
文档质量怎么记；
PR 提交时最少要带哪些材料；
哪些内容属于公共标准文件，哪些内容应该只提交到自己的结果目录。
这份文件负责回答：评测过程数据怎么交，交上来之后别人怎样复核、复现、复用。
为这套标准和常见“兼容性测试“最大的不同是什么？
最大的不同，是我们不再只看“最后过没过”，而是把过程成本也摆到台面上。一个任务最终跑通，不代表它就适合采购，也不代表迁移成本可接受。对企业来说，3天跑通和3周跑通，是完全不同的决策信号。
因此，这一版标准会把时间成本单独量化，至少记录三类指标：
首轮通过耗时：从裸机接管到首轮达到预定验收目标的总工时；
问题闭环耗时：从发现问题到完成修复并验证通过的总时长；
文档阅读耗时 / 文档阅读工作量：完成评测所需阅读的关键文档数量、页数 / 字数及投入工时。
我们希望公开结果不只告诉大家“能不能跑”，更告诉大家：跑通这件事到底花了多少人天，靠的是什么路径，值不值得在真实项目里承担。
不仅针对国产卡，TPU\AMD等国外AI加速芯片都可以按照这个评测。
这次为什么还要把”文档质量“和API稳定性”单独拉出来？
因为软件生态的真实体验，往往不是坏在“完全不能用”，而是坏在：
文档分散，关键版本矩阵找不到；
已知问题没有清单，踩坑只能靠反复试；
故障排查没有路径，问题只能远程问人；
关键文档需要登录甚至 NDA，公开用户拿不到；
API 或插件频繁发生破坏性变更，但没有迁移说明。
所以这次我们会把文档与接口质量单列展示，至少覆盖三项：
文档完备性：是否提供版本矩阵、已知问题列表、故障排查指南；
文档可访问性：关键文档是否公开可获取，是否需要登录或 NDA；
API 稳定性：是否存在频繁破坏性变更，是否提供清晰迁移说明。
这部分暂不简单并进“跑分”，但会和总分一起公开。因为对采购、迁移和长期维护来说，这些信息和性能数字同样重要。
为什么我们坚持把“自定义算子/自定义模型”继续纳入主评项
因为真实业务从来不只有官方 Demo。
如果一张卡只能在标准样例上表现不错，一旦遇到用户自己的算子、自己的服务模型、自己的训练脚本就开始报错，那么这更像“样板间生态”，而不是真正可用的工程生态。
所以这套评测仍会继续重点看：
自定义扩展能不能编译；热点算子有没有 fallback；图编译路径是否可用；真实业务模型迁移时，到底只是改个 device，还是要大面积改脚本、改导出、改构建链路。
推荐的提交方式
进入统一提交仓库：
https:
点击Fork，先复制到自己的 Gitee 账号下；
按评测规范和目录要求，在自己仓库中新增本次测试结果目录，并放入打分表、报告、日志、脚本和必要说明；
提交完成后，向主仓库发起Pull Request；
由维护团队审核目录结构、材料完整性、证据有效性和口径一致性，审核通过后再合并进入主仓库。
PS: 点击文末阅读原文可以进入仓库
过程数据将怎么提交？
这一轮我们把仓库中的结果目录结构统一为：
submission/<厂商>/<产品型号>/<stack_tag>_<yyyymmdd>_<submitter_id>/
仓库会把公共标准文件和具体测试结果明确分开：
公共标准文件：由维护团队统一维护；
测试结果与过程数据：由参与方按统一目录提交到自己的结果目录；
对标准本身的修改建议：优先通过 Issue 讨论，再由维护团队合并进正式版。
我们会怎么公开结果？
最终公开结果，不会只给一个总分。至少会同时给出：
总分；
首轮通过率；
最终闭环率；
原则性不兼容数；
时间成本指标；
文档与接口质量评级；
厂商支持闭环结论；
对应的日志、脚本、问题台账和支持记录路径。
也就是说，结果不再只是“结论”，而是一套可审计的证据索引。
欢迎谁来参与？
如果你是厂商，这会是一张更接近真实用户感受的答卷。跑得快很重要，但“第一次能不能顺利跑起来”“问题能不能以公开方式闭环”“用户要为迁移多付出多少时间成本”同样重要。
如果你是开发者或平台团队，这会是一份更接近真实落地的问题地图。你看到的不只是宣传口径，而是日志、问题台账、支持方式、时间投入和最终结论。
如果你是最终用户，这套标准想回答的核心问题其实只有一个：这套软件生态，究竟是“看起来支持”，还是“真的值得迁移进去”。
我们希望最终沉淀下来的是什么？
不是更热闹的口号，也不是更多“已经适配”的截图。而是三类真正能被行业复用的东西：
一把公开、稳定、可复核的尺子；
一套可以横向比较的打分结果；
一批带有完整过程证据的真实案例。
这也是为什么，这次我们不是只发一篇文章，而是一次性把以下三份文件一起公开：
《AI 加速器软件生态公开评测规范》
《AI 加速器软件生态公开评测打分表》
《AI加速器软件生态评测过程数据提交规范/模板》
评测不是为了制造噪音，而是为了让“软件生态可用性”这件事，被更真实、更具体地看见。
编写团队： 陈泽宇 陈禹澎 谢先衍 陈果
编写单位：湖南大学
本项工作受国家超级计算长沙中心和湖南省计算产业生态创新中心支持
