把"高质量 Token 产能"当指标：先说清什么算有效输出
一、产能这个词要能用，先动分子
据公开报道，国内某基础设施团队的负责人在行业峰会上表示，应用从对话式问答走向多智能体协作与长任务执行之后，Token 需求量级显著上升，基础设施的竞争点正在从算力规模转向”高质量 Token 产能”。这里的量级判断只是背景，它不进本文的推导；我们要接住的是后半句：一旦把”产能”当指标，就必须回答”产的是哪一种量”。
生成量是最容易报的数：设备跑满、每秒钟输出多少个字。它的问题不在不准，而在于分子里什么都能算进去——重试算一次、被下游丢弃的中间步骤算一次、没人消费的解释性文字也算一次。同一个集群，用生成量看是满负荷，用有效量看可能有一半以上是在原地消耗。
所以顺序不能反：先定义什么算有效输出，再谈吞吐、并发与显存。定义不同，同一次测量的结论可以完全相反，而多数争论其实是两个人在用不同的分子。
二、四种”有效”定义：分子、采集点和被造假的姿势
我们把可用的口径固定为四种，按”从技术到业务”排开。它们不是替代关系，是层层收窄的关系：第①条过了才有第②条，第②条过了第③条才有意义。
| 口径 | 分子 | 分母 | 采集点 | 最容易被做漂亮的地方 |
|---|---|---|---|---|
| 结构合格 | 可被下游解析且必填字段齐全的输出量 | 同期总生成量 | 网关出口与校验层，解析结果与字段齐全标记 | 把输出长度上限调小，合格率立刻上升；把”解析不报错”当成”字段齐全” |
| 任务被采纳 | 进入人工或系统确认状态的那部分输出量 | 同期总生成量 | 业务系统的状态位，而不是模型侧的返回码 | 把默认状态设成通过；把超时未审的算作采纳 |
| 无浪费重做 | 首次生成即被接受、不含因截断、超时、拒答引发重试的输出量 | 有效交付量所要求的总生成量 | 父子请求链路上的重试标记与终止原因 | 把重试记成新请求，父子链一断，浪费就从统计里消失 |
| 单位成本 | 每一元或每单位能耗对应的有效输出量 | 账单成本与机房侧计量 | 财务口径的成本分摊、机房电表与业务分账 | 只计电力不计折旧与闲置；共享池成本只往某一条业务线身上摊 |
表里右列不是修辞。这四个口径有两个已经在我们内部被验证过”可被无意做漂亮”：一是把最大输出长度压低后再报”结构合格率提升”，二是某条链路的重试由客户端自己发起、绕过了服务端埋点，导致重试率凭空下降。这两条不需要任何人主观作假就会发生，所以口径定义里必须写清楚”谁负责把重试记回父链”。
还有一点值得写明：第四个口径里的成本项，电只是其中一小块。折旧、散热、闲置时长、以及为保证峰值而预留但不能被别的业务使用的容量，都要在同一张分摊表里出现，否则每单位能耗的有效产出会随负载率波动得无法解读。
三、多智能体长任务为什么把第三项吃掉一大块
对话式问答的浪费主要在重答一次。长任务的浪费结构完全不同，有三个稳定的来源。
第一个是上下文的重复携带。多个子角色各自需要同一份背景材料，每个请求都把这份材料重新送进去。从生成量的角度它只算输出端，但从成本角度输入端的重复搬运是真实开销；更糟的是这些子角色往往只有一个的产出会进入下一步，其余的输出注定是分母。
第二个是中间步骤被丢弃。规划、检索、格式化这类步骤的输出没有被任何下游消费，它们的唯一用途是给下一次推理当输入。这类步骤的字数在生成量里占比很高，而在采纳口径里应该等于零。
第三个是串行等待把吞吐变成空转。链路上有一段必须等人确认，设备利用率看板仍然是”有任务在跑”，但有效产出在这段时间内是零。这就是为什么单看设备占用率无法判断产能：占用率和产出量在长任务场景下不再是正相关关系。
对应三个可查证的量：父子请求关系是否完整、跨请求的上下文重复度、以及被丢弃步骤的输出量占总生成量的比例。第三个量最诚实，它直接把”产能”两个字打掉一半。
四、容量规划要从有效交付量反推
传统的排法是：预估请求量，折算 Token 量，配并发，算显存。这个排法在长任务下会系统性低估资源需求，也可能高估——取决于浪费在哪一段。正确的排法从业务侧要的数开始往回推，四步。
- 先定有效交付量：单位时间内业务实际消费的输出量，用第二种口径的分子，取自业务状态位。这个数由客户或产品负责人给，不由平台组估。
- 按历史的采纳率与重试率反推需要的生成量：把有效量除以首次采纳率，再按终止原因把截断、超时、拒答引发的重复生成加回去。关键是这两个比率必须来自自己的链路，不是别人的公开数。
- 折算并发与显存时要带上下文重复度：同一份背景被重复送进多少个请求，直接决定输入侧的吞吐需求，这一步的错会导致显存预算整段偏小。
- 给串行等待与人工确认留空转预算：按链路上等待环节的时长占比，把”设备被占用但无产出”的那部分单独列一行，不要靠调高利用率假设来掩盖它。
三个常见陷阱：把比率当成常数（不同业务线的采纳率差很多，混在一起算会掩盖最差的那条）；把重试率下降当成改善（先看埋点有没有断）；把有效量与生成量放在同一个面板上比较（分母不同，曲线会误导决策）。
五、要测出来，最少要埋哪些事件
这套指标不能靠日志文本推，必须把链路每一步变成事件。我们用的最小事件集如下，字段名可以换，但每一项都得有落点。
- 请求标识与父链路标识：让一次任务下的所有子请求能被还原成一棵树，重试必须挂在同一棵树上。
- 调用方标识：按业务线、按外部租户拆分，这是后面所有分摊的基础，缺它就只能报全局均值。
- 阶段标记：生成、校验、重试、采纳四步各自成事件，一步一记，不要合并成”完成”。
- 终止原因：正常结束、长度截断、超时、内容策略拦截、拒答。这五项决定了第二项与第三项口径能不能算。
- 输入输出量与所用模型标识：与版本治理那条线共用同一份配对关系。
- 采纳状态与改判：人工最终是否使用，用了多少，改动原因是什么。改判信息要能回灌到提示与评测里。
分账纪律三条：按调用方出账，不按集群出账；有效量与生成量永远同时呈现，只报前者会被拿去压预算，只报后者会被拿去邀功；空转与等待单列，不要摊进利用率。埋点的验收方式很粗暴——随机抽一条链路，能在十分钟内还原出它生成过多少次、被重试过几次、最终哪一次被采纳。还原不出，指标就先不要上线。
六、把吞吐当对外承诺时的风险
这一层是立场问题，不是技术问题。只报每秒钟输出量会给出一个非常清晰的激励：把上下文塞满、把输出写长，因为分子是产出字数。长上下文对准确率未必有帮助，但对报表一定有帮助。所以任何把吞吐当承诺的场合，承诺对象都要换成有效量，并把口径写进书面材料。
对客户与供应商，我们的读法收敛成四个问题：报的是四种口径里的哪一种；重试是否计入分子；采纳率与终止原因能不能自己查；能不能按调用方出一份分账。四个问题都有书面回答，”产能”这个词才值得进入讨论；只要有一个答不上，它就是个营销词。
洹拓科技这边把这件事固定成两页交付物：一页是口径定义表，写明本文四种有效定义的分子、分母与采集点；一页是反推过程，从业务要求的有效交付量出发，把采纳率、重试率、上下文重复度和空转预算逐行列出。做容量评审时先确认这两页的数是不是同源，不同源就不进入采购讨论。
至于”竞争从算力规模转向产能”这句话本身，它是行业口径的变化，不是某一家厂商的排名结论。我们关心的是它落到自己链路上的那一层：分子定义清楚了，同样的设备能多交出多少有效量，才是可以算、可以验、可以负责的数。