素材：集群产能评估框架——一天最多卖多少 token，用户凭什么不退订

来源：内部仓库 ai-infra/slo-analysis（docs/capacity-assessment.md）——推理集群产能评估的对外汇报版框架。

与本演讲的关系：把第三部分”技术革命”和第二部分”财务模型”接到真实运营上——”单卡产能 / 集群日上限 / 日产值 / 支撑业务量”四数正是”利用率是第一杠杆”的量化版；Goodput（合规吞吐）回答”多少钱的 token 才卖得出去”。文中的 Token Factory agent-coding-interactive 集群实例（ch6）与素材 01/03 的财务测算可互证。

内部链接说明：文中引用的 docs/specs/goodput-capacity-metrics-spec.md 与 docs/infer-cost/infer-cost-ch6.md 位于内部仓库（gitlab.transwarp.io，非公开），仅本地可访问，外部读者以本文概念为准。

集群产能评估框架：一天最多卖多少 token，用户凭什么不退订

定位：面向任意一个推理集群的产能评估框架——用一套指标回答两个问题：”这个集群一天最多能产出多少合格 token？”、”每个用户的请求够不够快、够不够稳？”。本文是对外汇报版（指标定义可与老板、客户讲清楚）；公式与技术口径见 docs/specs/goodput-capacity-metrics-spec.md；一个完整应用实例（Token Factory agent-coding-interactive 集群的 SLO 与压测规范）见 docs/infer-cost/infer-cost-ch6.md——本文是该实例的解释性框架，也可套用到任何其他集群。 口径：文中所有指标的严格定义见文末附录「指标定义」。定义只依赖概念，与实现解耦。

原始诉求（只有两条）

  1. 产能：这个集群一天最多能产出多少 output tokens？每天过手多少 input tokens？
  2. 品质：每个用户的每次请求都要足够快、足够稳——做不到，用户就不为这个服务付钱。

第六章的全部指标体系就是把这两条量化成可签字验收的数字。

① 产能指标：回答”一天最多卖多少 token”

SLO Goodput（合规吞吐）:

每秒「成功 且 体验达标」的请求所产出的 output tokens

关键词是合规：只有满足品质承诺的 token 才有人付钱。不顾体验硬灌负载也能刷高原始吞吐，但那些 token 对应的是流失中的用户——原始吞吐是假产能，Goodput 是可售卖产能。

先声明模型，再谈产能：token 数量不是价值——不同模型的每 token 算力成本差几十倍（7B 与 70B 的 tokens/s 可以差一个量级），同一模型不同配置（TP/PP、量化、缓存策略）也不同。因此：

  • 每个产能数字都绑定模型与配置声明；同模型才可横向比较（比配置、比优化），跨模型直接比 token 数没有意义；
  • 跨模型比较只能换算成钱：$/MTok under SLO（单位合格 token 的成本，ch6 的 C_eff 框架即此口径）——集群跑多个模型时，产能评估按模型分行，并用日产值（$/MTok × 日产能）做统一比较。

换算成老板视角的四个数（按模型分行）：

口径 公式 回答什么
单卡产能 SLO Goodput / GPU 数（绑定模型与配置） 一张卡值多少 token（横向比配置，同模型）
集群日上限 单卡产能 × 卡数 × 86400（绑定模型与配置） 该模型每天最多能交付多少合格 output
日产值 日上限 × $/MTok under SLO 每天最多能卖出多少钱（跨模型统一比较）
支撑业务量 日上限 ÷ 每 agent 步平均输出（生产实测 ~247 tokens） 养得起多少次编码任务调用

Input 侧要看两个数而不是一个：每天过手的 input 总量很大（生产数据 input:output ≈ 294:1），但其中 prefix cache 命中的部分（生产实测 ~96%）不需要重新计算、近乎免费；真正消耗 GPU 算力的是未命中部分（~4%）。所以产能汇报必须拆开：”总处理 input” 规模观瞻，”真实重算 input” 决定成本与容量。

② 品质指标：回答”用户凭什么不退订”

用户感知 ↔ 技术指标的对照，全部承诺 P99（最差的那 1% 也要达标）：

用户体感 指标 承诺量级
点下发送后多久开始出字 TTFT 按请求长度分档承诺，长 prompt 另有档位
打字机流顺不顺滑 ITL token 间隔 P99 < 100ms
出字速度 TPOT 按模型与请求档位定（示例：≥25 token/s）
高峰期排不排队 Queue Time P99 < 300ms
服务能不能用 成功率 ≥ 99.95%（十万次里最多错 50 次）
整体兑现度 SLO Attainment ≥ 99%（每百个请求最多一个体验不达标）

为什么尾部要求这么狠——agent 任务把违约乘法放大：一次任务串行调模型几十次，单请求 99% 达标的任务是全程无感的概率只剩 0.99^50 ≈ 60%。用户体验看的是整条链，所以单步的尾巴必须极窄。

③ 两者的关系：品质约束决定产能上限

不加约束地加大流量，吞吐确实继续涨，但排队失控、首字延迟爆炸、成功率先崩——然后Goodput 归零。反过来，把流量压到品质承诺恰好守住的临界点：

可售卖产能 = 品质承诺刚被守住的极限工作点上的 Goodput
            （该点的到达率记作 λ_slo_max）

一句话总结：对外卖的是一个承诺——”你的每个请求都快而稳”；对内考核一个数字——”守住该承诺的前提下，每张卡每天能产出多少合格 token”。两数必须一起报告：只有前者没有后者是赔本买卖，只有后者没有前者是自欺欺人。

④ 对任意集群怎么评估（四步流程）

  1. 定承诺：确定集群服务的请求类型与 SLO 档位（延迟分档、成功率、Attainment 目标）——承诺必须可检验、可签字；
  2. 压测找极限：逐步提高到达率 λ，观测品质指标（分档 TTFT/ITL、成功率、Attainment）——找到品质承诺刚被守住的临界到达率 λ_slo_max。完整压测规范见 docs/infer-cost/infer-cost-ch6.md（Token Factory 实例）；
  3. 算产能三数：在 λ_slo_max 工作点上，取正式计量段的产出，计算单卡产能、集群日上限、支撑业务量（Input 侧报三口径）；
  4. 出评估报告：按模型分行——每行：模型与配置（规模/TP/PP/量化/缓存策略）、承诺表、λ_slo_max、SLO Goodput/GPU、日产能、$/MTok、日产值、品质对照（各档 Attainment/成功率实测 vs 承诺）——一个数一行，可签字。

附录：指标定义

口径与 docs/specs/goodput-capacity-metrics-spec.md 一致（本文为业务版，spec 为技术版），只涉及概念本身，不绑定具体工具和数据格式。

A. 度量对象

请求：用户或模拟用户的程序发给推理服务的一次补全任务。一个编码任务在底层会拆成多个请求串行发出，因此单个请求的体验直接决定整个任务的体验。

正式计量段（统计窗口）：固定压力下运行一段时间，计算指标只取中间的稳定期，开头用于暖机的流量不计入。所有指标共用同一个窗口，产能数字与品质数字之间才能直接运算对照。

有效请求：正式计量段内去掉用户主动取消的请求后剩下的集合。取消是用户的决定而非服务过错，因而不进入品质分母。

ISL / OSL（输入/输出长度）：单个请求包含多少输入 token、实际生成多少输出 token。延迟承诺按 ISL 分档给出，千字任务和十万字任务的合理等待本不相同。

B. 延迟类指标（每个请求各测出一个数）

TTFT（首字延迟）：从请求发出到收到第一个输出 token 的墙钟时间，等于排队、读入理解、首字生成三段之和。通俗地讲就是点下发送后多久看到第一个字。高峰期 TTFT 变差多半是排队变长而并非模型变慢，归因时应先查排队时间。

排队时间（Queue Time）：请求被服务接收到开始真正计算之间的等待。它是 TTFT 的组成部分，单独列出的理由是在过载场景下它最先恶化，是最廉价的预警线。

ITL（字间隔）：流式输出中相邻两个输出 token 的间隔，反映打字机输出的流畅程度，用来捕捉单次卡顿。

TPOT（平均出字速度）：单个请求内首个字之后的总时间除以输出字数减一，即这一段字间隔的平均值。ITL 与 TPOT 必须同时报告，原因是平均值会把一次长卡顿摊薄，TPOT 表现正常不代表没有卡顿；两者分管均速与抖动。

P99 口径：延迟承诺一律取 P99 而非平均值。将窗口内同档请求按快慢排序后，第 99 百分位的那个也要达标，相当于一百个请求里最差的那个不能太差。P99 描述的是集合，单个请求只有一个数值，谈不上自身是否达标。

C. 成败与达标

成功 / 失败：失败指服务端原因导致请求没拿到完整结果，包括服务端报错（5xx 类）、等待超时、连接中断、调度拒收和基础设施故障，以是否返回完整响应为准。用户主动取消不算失败。成功率承诺不低于 99.95%，对应每十万个请求最多坏五十个。

合规（Compliant）：单个请求合格需同时满足三条：该请求成功、首字延迟不超过所属 ISL 档上限、字间隔不超标，逐个请求判定。正文产能公式中的「体验达标」即后两条延迟条件；”合规”是这三条的总称。TPOT 作为独立计数单独考核，不参与单请求判定。另需澄清：”某个请求 P99 达标”的说法并不成立，P99 只属于集合。

Attainment（达标率）：有效请求中合规请求的占比，逐 ISL 档分别计算，各自承诺不低于 99%。不允许用全体请求的整体均值替代分档数字，整体表现良好可能恰好掩盖某一档的塌方。

λ_slo_max（最大守约到达率）：逐步提高每秒新到的请求数，品质承诺尚能全面守住的最高一档压力。越过这一档继续加压，换来的是吞吐，付出的是承诺。

D. 产能类指标

wall_time（观察时长）：统计窗口的实际时长，从最早一个请求发出算到最晚一个请求结束。以下各项”每秒”类指标都以它为分母。

Output Token 产出量：窗口内所有完成请求实际生成的输出 token 总数，按实测值计，不按申请值计。

Input 处理量的三个口径：

  1. 过手总量，即处理过的输入 token 合计；
  2. 缓存复用量，其中命中上下文缓存、无需重新计算的部分；

  3. 真实计算量为二者之差，是唯一真正消耗 GPU 算力的部分。

    三个数必须一起给。Coding agent 场景生产基线命中率约 96%，只报总量会把真实算力消耗高估二十倍以上。

Raw Throughput（原始吞吐）：全部有效请求的产出除以 wall_time。它与质量无关，代表机器极限，用于对账而不用于许诺。

SLO Goodput（合规吞吐）：只有合规请求的产出计入分子，再除以 wall_time。过载时原始吞吐可能仍在上涨，同时大量请求开始违约；原始吞吐上升而 Goodput 转跌，即为容量见顶的信号。绑定模型与配置声明：同一集群跑多个模型时按模型分别计量——不同模型的 token/s 不可直接比较。

$/MTok under SLO（单位合格 token 成本）：计量段的 GPU 成本除以 SLO Goodput 折算的每百万合格 token 成本（并发感知口径即 ch6 的 C_eff）。它是跨模型、跨配置唯一可比的产能度量——比较两个集群或两个模型的价值时用钱，不用 token 数。

Goodput/GPU（单卡合规产出）：SLO Goodput 除以参与服务的 GPU 卡数，得到与集群规模脱钩的单卡价值量，便于横向比较不同配置（限同模型）。

日产能：Goodput/GPU、卡数、24 小时三者相乘的外推值（绑定模型与配置），成立前提是通过长时间稳定性验证（连续半小时以上无退化）；在此之前只能作为参考数字，不得当作对外承诺。多模型集群按模型分行报告。

Goodput/Watt（能效）：SLO Goodput 除以窗口内 GPU 平均总功率。它防范的是靠堆卡换取吞吐的做法：能效偏低的配置通常意味着缓存利用率不足或调度存在浪费。