跳转至

SuperPod Pareto Index（SPI）筹备说明书

SuperPod Pareto Index (SPI) 当前不是一个已经定型的正式评估机制，也不是一个准正式打分平台。它在本白皮书中的定位，是一份筹备说明书：把未来如果要做产品条目、证据整理、跨路线比较与协同治理，今天必须先讲清楚的问题、边界和接口提前摊开。

SPI 之所以被单列出来，不是因为它已经成熟，而是因为如果这些问题不被提前说明，后续任何产品名录、比较页面、试点提交流程都很容易滑向三种风险：一是把复杂系统问题压缩成营销参数表，二是过早固化并不稳妥的评价口径，三是让企业误以为需要在规则未清前先交付完整敏感信息。

当前定位

在当前阶段，SPI 只承担三件事：

  1. 把白皮书七维分析框架延伸为一个可讨论的产品整理入口。
  2. 把证据、保密、治理、版本等关键问题先显性化，而不是默认它们已经解决。
  3. 为企业、研究机构、测试机构和编写委员会之间的后续共建预留接口。

换句话说，白皮书回答的是“怎么看超节点”，SPI 当前回答的是：如果未来要持续标注“产业今天走到哪里”，现在有哪些事情必须先筹备。

当前不是什么

为避免误读，SPI 在当前阶段明确不是：

  • 不是 TOP500 式单榜单；
  • 不是已经生效的统一评分制度；
  • 不是已经完成治理设计的行业标准；
  • 不是要求企业立即公开全部产品细节的提交流程；
  • 不是可以直接拿来做采购结论的最终评价结果。

现阶段更合适的理解是：SPI 是把“以后也许要怎么做”先写成一份可讨论、可修订、可共建的说明。

为什么仍然保留 SPI

超节点竞争本质上是多维权衡问题。只比较理论算力、峰值带宽或卡数，都会掩盖真正影响 Goodput 的关键因素。即便 SPI 当前不进入正式机制状态，这类筹备工作仍然有必要保留，因为产业协同迟早会遇到几个现实问题：

  • 不同路线的产品如何放到同一分析坐标下讨论；
  • 哪些公开数字可采信，哪些只能附条件解释；
  • 哪些材料适合公开，哪些更适合闭门校准；
  • 样例条目、正式条目和委员会结论之间如何区分；
  • 争议出现时，版本、修订和保留意见如何处理。

因此，SPI 不是为了提前“发牌”，而是为了避免未来真正进入协同时从零开始。

SPI 依托的分析基础

SPI 不另起一套评价哲学，而是继续依托本白皮书已经建立的七维分析框架：

  1. 单跳 / 访存延迟
  2. 规模上限
  3. 拓扑弹性
  4. 生态成熟度
  5. 功耗与 TCO
  6. 软件复杂度
  7. 适用负载

这里更重要的不是今天就给出一套固定分数，而是先确认：未来无论采用条目说明、雷达图、标签还是阶段性评语，都应建立在这套多维框架上，而不是退回到单一指标排序。

当前需要先筹备清楚的问题

SPI 当前最重要的任务，不是扩充条目数量，而是把以下问题先准备清楚。

1. 产品条目的边界

需要先明确：什么算一个可提交的“产品条目”。

  • 是单芯片、单节点、整机柜，还是一整套超节点方案；
  • 同一家公司不同配置的产品应如何拆分；
  • 方案级能力与器件级能力应如何区分；
  • 参考设计、实验系统、商用系统和概念样机是否应进入同一入口。

如果边界不清，后续任何比较都容易失真。

2. 证据等级与引用口径

需要先明确：哪些数字属于可公开采信证据，哪些只能作为说明性材料。

  • 公开论文、公开白皮书、标准文档、第三方测试、厂商自述各自算什么等级；
  • benchmark、实测数据、部署反馈、推理 / 训练案例能否并列呈现；
  • 缺少复现实验时，数字应如何附条件展示；
  • 同一指标来自不同测试条件时，如何避免误导性横向比较。

这也是为什么 SPI 当前更适合作为说明书，而不是直接进入评分页。

3. 保密边界与开放边界

企业参与需要明确知道什么可以交、什么不必交。

  • 哪些内容适合公开进入站点；
  • 哪些内容只适合闭门讨论或定向评审；
  • 哪些属于核心机密、客户敏感信息或未发布路线图，原则上不要求提交；
  • 样例条目是否允许只提交结构化事实而不附完整实测。

如果这条边界不清，企业参与意愿会被明显压低。

4. 治理分工与角色边界

需要先明确各角色分别做什么，而不是默认“编写委员会统包一切”。

  • 厂商负责提交什么；
  • 编写委员会负责审核什么；
  • 是否需要独立测试机构或研究机构参与证据校准；
  • 当厂商说明、公开材料与第三方观察不一致时，谁来给出保留意见。

5. 版本演进与争议处理

如果未来条目持续增加，争议一定会出现，因此必须提前设计：

  • 条目更新与撤回如何记录；
  • 历史版本如何保留；
  • 对同一产品的不同证据是否允许并列；
  • 对存在争议的结论，是否允许“暂不定论”而不是强行落分。

6. 展示形式与成熟度分层

即便未来做展示，也不应默认只有一种形态。至少需要区分：

  • 样例条目；
  • 试运行条目；
  • 证据较完整的公开条目；
  • 经进一步讨论后形成的阶段性委员会意见。

这几层如果混在一起，外界会误把“样例积累”当成“正式结论”。

当前如何参与

SPI 当前欢迎参与，但参与重点不是“争取一个结论”，而是“帮助把问题定义清楚”。现阶段更适合围绕三类内容共建：

  • 结构化事实：产品形态、互联方式、规模、功耗、软件栈、适用场景。
  • 证据化材料：公开论文、公开白皮书、实测数据、部署反馈、基准结果及其测试条件。
  • 边界性意见：对条目拆分、证据等级、保密处理、展示形式和版本机制的建议。

当前默认参与方式仍以 GitHub Pull Request 为主，但更适合作为样例积累、条目试填和问题收集入口，而不应被理解为“提交后即可进入正式评审”。

当前最适合参与的角色

SPI 的筹备不只需要厂商，也需要多类角色共同补齐：

  • 芯片与加速器厂商：提供产品结构和系统约束事实；
  • 互联、交换与光模块厂商：补齐链路、拓扑和器件成熟度证据；
  • 系统整机、云厂商与模型公司：补齐真实负载、部署反馈与 Goodput 视角；
  • 测试机构与研究机构：补齐 benchmark、仿真、证据分级与方法校准；
  • 编写委员会：负责维护问题清单、版本记录与公开表述边界。

仓库中当前已经预留的结构

当前仓库中已预留 SPI 基础结构：

  • spi/README.md
  • spi/templates/product-template.yaml
  • spi/schema/spi-product.schema.json
  • spi/products/

这些结构说明 SPI 已具备“可以开始试填、试挂、试讨论”的基础条件，但并不意味着治理、证据和采信逻辑已经完成。

已收录产品入口的当前含义

当前已收录产品通过独立导航页展示：

该页面在构建时自动扫描 spi/products/ 目录生成，因此会随着仓库中新增产品条目而更新。现阶段这些条目更适合作为样例积累、模板验证和结构演示，而不应被理解为成熟评估体系下的完整结果。

后续如果继续推进，建议先走的顺序

SPI 如果后续继续推进，建议按以下顺序演进，而不是直接进入评分发布：

  1. 先收敛产品条目边界和证据等级。
  2. 再明确公开材料与闭门材料的分界。
  3. 再补治理分工、争议处理和版本机制。
  4. 最后才讨论是否需要阶段性标签、评语、雷达图或其他展示形式。

只有前面三步足够清楚，第四步才不会把 SPI 推成一个“看起来像正式机制、实际上证据和治理都没跟上”的半成品。