把一类云单独叫成一个新词，统计口径要先说清它包含什么
一、新词立起来之前，先问它划了三条什么线
据公开报道，一家研究机构发布了 AI 云服务方向的年度报告，把一类面向 AI 的新型云单独划成一个统计类别，并给出某厂商在该类别中占据接近一半份额的结论。本篇不把这个份额当作任何判断的依据，也不讨论它属于谁。要讨论的是这份东西的结构：先定义一个类别，再在类别里排出第一名。
新类别加份额这种组合，对采购方几乎不提供决策信息。原因是类别的名字是营销产物，可它一旦进了统计表，就隐含三条边界：卖的是什么、卖给谁、收入怎么算。这三条会真实落到你收到的报价单与 SLA 文本里——含不含调度层、出事时找谁、按什么单位扣费。同一个新词，在不同厂商与不同机构的嘴里常常指三种范围。
我们的方法只有一句：不要问这一类云好不好，要问它的三条边界画在哪里，我的负载落在哪一侧。
二、与传统云的三条真实差异，和三条能当场问出口的判据
差异一，卖的是算力时长还是应用可用能力。传统云的商品单位是实例、卷、带宽，客户买回去自己搭平台、自己管队列；这一类新云的商品单位往往是一次训练任务或一路推理服务，卖的东西带着“下面那层你不必管”的暗示，也可能带着“下面那层你管不了”的限制。这两句在合同上完全是两回事。
差异二，交付对象是算法团队还是 IT 运维。这一条决定控制台的层次、文档的写法和工单里默认的责任切分。给算法团队的界面，通常把队列、并行策略、失败重跑摆在首页；给 IT 运维的界面，通常把主机、网络、存储摆在首页。看一眼首页就知道对方把谁当用户，也就知道日常配合要派什么人去。
差异三，计费与 SLA 是否围绕训练与推理作业，而不是主机可用性。这一条最硬，因为它直接决定一次事故的成本落在谁头上、以什么方式落。
对应三条差异，各给一个可以在电话里直接问出口的问句：
- 能不能按作业计费，并给出作业级的成功率？答不出成功率的，计费单位其实仍是资源。
- 加速卡的驱动、通信库与固件由谁负责？异常时升级链路走谁、多久到谁？
- 一次故障之后，恢复动作是把实例重开，还是把作业接回原来的步数？
第三问是分水岭。作业续跑要求平台把检查点、并行拓扑与数据游标当成一等对象保存和恢复；实例重开只要求虚拟化层还活着。两者的运维成本差很多，对客户业务连续性的影响也差很多，但报价单上这两者可能长得分毫不差。
三、份额这个词，问清四件事之前它只是一个数字
第一问，分子分母是什么。是这一类的收入除以整个云市场的收入，还是除以这一类自身的收入？分母不同的两个“接近一半”之间毫无可比性，而报告正文常常不把分母写出来。
第二问，按什么计量。按收入、按算力规模、按交付卡数、按客户数量，还是按公开可查的项目信息？这是几种完全不同的东西，下一节展开。
第三问，统计期是否覆盖一次性大单。一个集中交付的项目就能把整年的比例推动很大，而这类项目的收入在下一个周期往往不重复。看到某一家忽然靠前，先问有没有一次性交付。
第四问，自建自用部分算不算。不少供应商的资源由自己集团内部消化，把它计入份额，衡量的就不再是对外提供服务的能力。对采购方来说，这一项尤其要剥离，因为它把“拥有多少”和“能卖多少”混成了一格。
四问里第二问最容易被忽略，也最容易导致误判；第四问最容易被有意无意地跳过。
四、同一份数据，四种口径会排出四个不同的第一名
| 计量口径 | 结果偏向哪类供应商 | 采购方能读出什么 | 读不出什么 |
|---|---|---|---|
| 按收入 | 客户数少但单客金额大的那家 | 大客户渠道的成交能力 | 中小客户是否被同样认真地服务 |
| 按算力规模或交付卡数 | 自建比例高、资产重的那家 | 供给的物理上限 | 对外出租的比例与真实负载率 |
| 按客户数量 | 单价低、中小客户多而杂的那家 | 接入面与标准化程度 | 高要求客户的服务深度 |
| 按公开可查的成交信息 | 渠道结构偏向集中采购项目的那家 | 面向集采类要求的响应经验 | 长周期运营与技术支持水平 |
四行看完，结论就出来了：份额排名的信息量取决于口径，而口径通常藏在报告注释里且往往不完整。再叠加另外两件事——类别由被统计的厂商与定义它的机构共同商定，样本与明细不公开——同一家厂商在不同报告里落在不同类别并不奇怪。这不是矛盾，这是分类的自由度。所以这类报告对选型的帮助有限，不是因为它假，而是因为它不是为选型编制的。
五、把它用对的三个动作
动作一，只看趋势与分类逻辑。一份报告里最值得读的是“为什么把这几家放在一起”，它反映市场正在把哪些能力打包成一件商品卖。这个信息对我们排期有用，对排名无用。
动作二，不看排名。排名对选型的唯一正当用途，是提醒你这家公司值得再查一下；它从来不是“可以签”的理由。
动作三，把类别定义拿去问供应商。把报告里那一类的特征原样发给对方，问一句：你接受这个定义吗？如果接受，请指出自家产品里哪一项对应哪一条。对方接不接受一个外部定义、接受到什么程度，比它自己怎么写宣传页更有信息量。不接受，也要问清它为什么不接受——那通常能问出行业的真实分界线在哪里。
六、我们替换掉的交付物：一张四列矩阵
给客户做云选型时，我们不再交排名，改交一张能力矩阵。矩阵按“卖什么／谁运维／故障恢复单位／计费粒度”四列建立，把候选供应商逐行填进去，然后让客户拿自己的负载去对，而不是拿分数去比。
| 列 | 填写要求 | 应当拒收的写法 |
|---|---|---|
| 卖什么 | 写订单里真正交付的对象：资源、平台还是作业 | 一站式 AI 云 |
| 谁运维 | 驱动、通信库、调度器三层各自写明责任方 | 厂商提供支撑 |
| 故障恢复单位 | 写明恢复动作的确切对象与耗时口径 | 支持自动恢复 |
| 计费粒度 | 按小时、按作业、按 Token 还是按调用次 | 弹性计费 |
最容易被填错的一格是“故障恢复单位”。很多供应商在这一格写“支持自动恢复”，实际指的是实例重启而不是作业续跑。这一格必须问出具体动作才算填完：检查点由谁保存、写到什么存储、恢复后是从末次检查点继续还是从头开始、由平台自动触发还是要客户提工单、恢复一次的时间上限是多少。四问答完才允许落笔，答不出就在该格写“不可判定”，不要留空白也不要写好话。
新词写进合同与招标文件还有一个具体风险：把一个未定义的名词写成技术要求，评审时无从判定对方响应与否，最后它变成一条谁都能解释的条款。我们的处理办法固定成一句话——凡新词一律在本项目范围内自定义，并在同一条款里附上三条可判定要求。例如把“智算云服务”在本项目内定义成“按训练作业计费、提供作业级成功率统计、支持从检查点续跑，三项全部满足”，缺一项即判为未响应。自定义不需要学术上正确，只需要在评审时能判定。
洹拓在整理这类评审材料时还有一条纪律：报告可以引用，但引用时把口径写进脚注，注明口径来自报告原文还是我方事后询问。同一份报告被两家供应商各自摘取不同页使用是常事，页码与口径一起留在文档里，后面争论才有得可查。选型的讨论会上，我们更希望客户带着那张四列矩阵去提问，而不是带着名次去相信——名次会随下一份报告改变，矩阵的四列定义不会。