Token 工厂的产能怎么算？ — 从”一天最多卖多少 token”到”用户凭什么不退订”
面向推理集群运营者、Token 工厂从业者与 AI 基础设施买家。本文给出一个可落地的产能度量框架：用什么指标回答”一天最多卖多少”、”用户凭什么不退订”，以及如何用开源工具 AIPerf 把框架变成可签字验收的数字。所有指标只依赖概念，与具体引擎、具体部署解耦。
一、为什么 Token 工厂要谈”产能”
Token 工厂是把「资本 → 电力 → Token」的转化机器。对这座工厂的经营者，有两个问题比”模型多聪明”更接近账本：这台机器一天最多能产出多少”卖得出去”的 token，以及每个用户凭什么不退订。
注意”卖得出去”四个字。一台推理集群的吞吐指标很多（首字延迟、出字速度、每秒请求数、每卡 token 数），但它们回答的是”机器跑多快”，不是”生意赚多少”。产能要回答的是后者：在用户愿意持续付费的前提下，一天最多能交付多少合格产出。本文用一套指标框架 + 一个开源工具（NVIDIA AIPerf）把这个问题量化。
框架本身与实现解耦：概念部分适用于任何推理集群（vLLM、SGLang、TensorRT-LLM、托管 API 均可），工具部分负责把概念变成数字。
AIPerf（NVIDIA，Apache 2.0）：https://github.com/ai-dynamo/aiperf
二、产能度量的三个误区
先拆掉三个想当然，因为它们恰好是产能数字不可信的原因。
误区一：原始吞吐是假产能。 不顾体验硬灌负载，吞吐确实还能涨（排队失控、首字延迟爆炸、成功率先崩，然后用户流失）。那些”刷出来”的 token 对应的是流失中的用户。原始吞吐是机器极限，用于对账；可售卖产能必须与品质承诺绑定。
误区二：token 数量不是价值。 不同模型的每 token 成本差几十倍（7B 与 70B 模型的 tokens/s 可以差一个量级），同一模型不同配置（TP/PP、量化、缓存策略、部署拓扑）也不同。跨模型直接比 token 数没有意义，每个产能数字必须绑定模型与配置声明。
误区三：品质与产能脱节。 只报产能、不报品质承诺，是赔本买卖（卖出去的 token 没有承诺保障）；只报承诺、不报产能，是自欺欺人（承诺了也兑现不了）。两个数必须一起报告，而且必须出自同一统计窗口，才能直接运算对照。
三、先定义”卖得出去”：SLO Goodput
产能的核心指标只有一个：
SLO Goodput = 每秒「成功 且 体验达标」的请求所产出的 output tokens
关键词是合规。一个请求要计入产能，必须同时满足：请求成功、首字延迟不超过所属档位上限、字间隔不超标。只有这类 token 才有人付钱，它们对应的用户还留在产品里。
Goodput 与原始吞吐的区别在过载时最明显：原始吞吐可能继续上涨，同时大量请求开始违约。原始吞吐上升而 Goodput 转跌，就是容量见顶的信号。
在 Goodput 之上还有两条纪律：
- 先声明模型，再谈产能。产能数字必须绑定”模型 + 配置”（规模、TP/PP、量化、缓存策略、部署拓扑），换任何一个变量，数字都不可比；
- 跨模型只能换算成钱。比较两个模型或两个集群的价值时，用
$/MTok under SLO（单位合格 token 成本），不用 token 数。
四、品质承诺：用户凭什么不退订
产能的”合规”部分需要一套可检验的品质指标。用户体感与技术指标一一对应，全部承诺 P99（尾部 1% 边界：最差的请求也基本达标，而不是平均达标）：
| 用户体感 | 指标 | 承诺量级（示例，按业务调整） |
|---|---|---|
| 点下发送后多久开始出字 | TTFT（首字延迟） | 按请求长度分档承诺（排队已含在内） |
| 打字机流顺不顺滑 | ITL（字间隔） | P99 < 100ms |
| 出字速度 | TPOT（平均出字速度） | 跟踪项，不参与合规判定（合规集与达标率同源，维持 TTFT+ITL） |
| 服务能不能用 | 成功率 | ≥ 99.95% |
| 整体兑现度 | 达标率（Attainment） | ≥ 99%，逐档分别承诺 |
为什么尾部要求这么狠：Agent 任务把违约乘法放大。一个 Agent 任务串行调用模型几十次，单请求 99% 达标，整条任务全程无感的概率只剩 0.99^50 ≈ 60%。用户体验看的是整条链，所以单步的尾巴必须极窄。
两个口径提醒：延迟承诺取 P99 而非平均值（平均值会把一次长卡顿摊薄）；达标率按请求长度档位分别承诺（千字任务和十万字任务的合理等待本不相同，整体均值会掩盖某一档的塌方）。
五、两者关系：品质约束决定产能上限
产能与品质不是两个独立指标，是同一个问题的两面：品质承诺划定了产能的边界。
不加约束地加压，吞吐继续涨，但排队失控、首字延迟爆炸、成功率先崩，Goodput 归零。反过来，把流量压到品质承诺恰好守住的临界点：
可售卖产能 = 品质承诺刚被守住的极限工作点上的 Goodput
（该点的请求到达率记作 λ_slo_max）
λ_slo_max 是这套框架里最重要的一个数：它把”用户凭什么不退订”（一组品质承诺）翻译成”一天最多卖多少”（一个产能数字）。越过这个到达率，产出的都是违约 token。
一句话总结：对外卖的是一个承诺（”你的每个请求都快而稳”）；对内考核一个数字（守住承诺的前提下，每天能产出多少合格 token）。
六、老板视角：换算成四个数
λ_slo_max 是工程师语言。给老板或客户看的，是把它换算成的四个数（按模型分行）：
| 口径 | 公式 | 回答什么 |
|---|---|---|
| 单卡产能 | SLO Goodput ÷ GPU 数 | 一张卡值多少 token（同模型横向比配置） |
| 集群日上限 | 单卡产能 × 卡数 × 86400 | 一天最多交付多少合格输出 |
| 日产值 | 日上限 × $/MTok under SLO | 一天最多卖出多少钱（跨模型唯一可比） |
| 支撑业务量 | 日上限 ÷ 每任务步平均输出 | 养得起多少次任务调用 |
Input 侧要拆两个数而不是一个：每天过手的 input 总量很大，但其中命中上下文缓存（prefix cache）的部分近乎免费、不需要重新计算；真正消耗 GPU 算力的是未命中部分。产能汇报必须拆开：”总处理 input”是规模观瞻，”真实重算 input”决定成本与容量。只报总量，会把真实算力消耗高估一个数量级以上。
七、落地：用 AIPerf 把框架变成数字
工具用 NVIDIA 开源的推理基准测试工具 AIPerf（Apache 2.0，https://github.com/ai-dynamo/aiperf）。它对 OpenAI 兼容端点做压测，per-request 记录 TTFT、ITL、TPOT、输入/输出长度等全套指标，支持 vLLM、SGLang、TensorRT-LLM、Ollama、TGI 等引擎。它恰好覆盖框架需要的每一项：P99 统计、并发/到达率控制、暖机与正式计量两阶段、自定义数据集、生产 trace 回放。
指标映射：一条命令拿到全套 P99
aiperf profile --model <model> --endpoint-type chat \
--url <endpoint> --concurrency 5 --request-count 100 --streaming
（--streaming 必开：TTFT/ITL 依赖流式逐字计时，不开则这两项指标缺失。）
输出即框架所需的全部指标，且自带 avg/min/max/p99/p90/p50：TTFT（首字延迟）、Time to Second Token、Inter Token Latency（字间隔）、Output Token Throughput Per User（出字速度）、Output Token Throughput（吞吐）、Request Throughput（每秒请求数）、输入/输出序列长度。映射关系零成本：AIPerf 的指标字典就是框架的指标字典。
负载怎么来：合成与回放
产能数字对负载形状极其敏感（短对话与长上下文 Agent 任务的产能差几倍），所以负载必须贴近真实。两条路，共用同一判定口径：
- 合成负载：按负载 profile 采样生成。profile 描述链长（一个会话几轮对话）、think time（工具执行/人工阅读间隔）、输入/输出长度分布（用 p50/p99 两点拟合长尾：多数请求短、长尾很重）。适合任意强度、任意形态的探索；
- 生产 trace 回放：用真实流量的 trace 文件（到达节奏、长度分布、前缀复用结构全部真实）。AIPerf 支持 ShareGPT、BurstGPT、Agentic coding traces 等公开数据集。对 trace 的时间戳等比缩放即可提升到达率，同一份真实负载，按不同倍数压测。
三阶段自适应压测：λ_slo_max 的工程方法
逐档加压找 λ_slo_max 是手工活，实践中行之有效的做法是三阶段自适应：
- Phase A 粗扫：到达率几何递增（×2 起步：0.5 → 1 → 2 → 4 → 8），每档跑完逐档判定 PASS/FAIL。为什么用几何递增而不是等差：容量-延迟关系在临界点附近高度非线性，几何 4–5 档即可覆盖 16 倍负载范围；
- Phase B 二分细化：在最后一个 PASS 与第一个 FAIL 之间二分逼近，细化临界点；
- Phase C 长稳确认：临界档连续跑 30–60 分钟，确认无退化。对外承诺的数字必须是长稳验证过的档位，短跑 PASS 只是候选。
逐档 PASS 判定三项，阈值按集群承诺表配置：TTFT（按 ISL 分档）P99、ITL P99、成功率，另有样本量门槛（有效请求不足时 P99 是噪声，该档判无效）。请求延迟 P99 只作体验预算跟踪（推理模型的端到端延迟大头是模型自己的生成时长，属负载行为而非容量信号，超预算标注但不改判定）。三个判定指标的恶化顺序有诊断价值：TTFT 最先恶化（过载时排队最先变长，是最早的预警线），ITL 反映 batch 过大与 decode 抢占，成功率最后崩，但崩了就是事故。
λ_slo_max 怎么读：从低到高逐档加压，最后一个 PASS 的档位就是 λ_slo_max。注意取”已验证守约的档位”而非区间中点，对外数字必须是验证过的。AIPerf 还内置 Adaptive Scale 模式，可以在单次运行中自动发现并维持 SLO 边界，把这个过程自动化。
产出：报告按模型分行
最终报告按模型分行，每行：模型与配置声明、承诺表、λ_slo_max、单卡产能、集群日上限、$/MTok、日产值、品质对照（各档实测 vs 承诺）。一个数一行，可签字。
八、四步流程：一次完整的产能评估
整套方法可以收敛成四步流程：
- 定承诺：确定集群服务的请求类型与 SLO 档位（延迟分档、成功率、达标率目标），承诺必须可检验、可签字；
- 压测找极限：用 AIPerf 生成/回放负载，三阶段自适应加压（粗扫 → 二分 → 长稳），观测品质指标，找到承诺刚被守住的临界到达率 λ_slo_max；
- 算产能：在 λ_slo_max 工作点上，取正式计量段的产出，计算单卡产能、集群日上限、支撑业务量（Input 侧按”过手总量 / 缓存复用 / 真实重算”三口径报告）；
- 出报告：按模型分行，一个数一行，可签字验收。
九、取舍与边界
框架是清楚的，但三个边界必须诚实标注：
1. 品质与吞吐的此消彼长。 P99 承诺越狠，产能上限越低，产能数字永远是一组承诺的函数。承诺档位不是拍脑袋，是业务决策：延迟敏感的应用（交互式 Agent）比异步批处理（离线生成）付更高的单位成本。这正是 $/MTok under SLO 存在的意义：把”承诺多狠”和”成本多高”放在同一个数里比较。
2. 产能绑定模型与配置，拓扑是其中一环。 前面说产能数字绑定”模型 + 配置”，这里的配置包括部署拓扑。大模型必须切卡部署，切卡就有通信开销：单节点 NVLink 可以大部分隐藏通信（接近理论产能），跨节点部署通信无法隐藏，产能可能断崖式下跌。同模型的产能数字，换一个拓扑就不可比，产能报告必须写清楚拓扑。
3. 压测是近似。 合成负载再贴近，也不是生产流量；生产 trace 回放缩小了差距，但 trace 快照本身会过时。另外：统计窗口要取稳定期（暖机流量不计入）；短跑 PASS 不等于长稳（30–60 分钟无退化才可对外承诺）。产能数字应该标上”评估时点 + 负载 profile 版本 + 长稳状态”，让它可追溯、可复核。
最后回到开头的问题。Token 工厂的产能不是一张卡的峰值吞吐，也不是一个模型的 benchmark 分数，它是”承诺能守住的质量下，一天最多能卖多少合格 token”这个具体的数。度量它的框架只有三条：先声明模型，再谈产能；先承诺品质，再谈上限；先长稳验证，再对外报告。 工具（AIPerf 这样的开源基准）负责把这三条变成可签字的数字，剩下的，是运营者自己的判断。