R

A02 成本对象层级辨析·per-token per-query per-task per-user per-seat

创建 2026-06-07 更新 2026-06-11 13 条双链 成本工程 专题 AI 整理

A02 成本对象层级辨析·per-token per-query per-task per-user per-seat

本节点要解决的问题是：当一个 AI 产品的人在说”成本”时，他到底在说哪一层的成本？ per-token、per-query、per-task、per-user、per-seat 是五个不同的成本对象（cost object）层级，单位不同、口径不同、对应的决策不同。绝大多数关于 AI 产品盈利的争论之所以鸡同鸭讲，是因为吵架双方根本站在不同的计量层级上——工程拿 per-token 单价说”很便宜了”，财务拿 per-user 月成本说”要亏死了”，两个人都对，但他们说的不是同一笔账。本节点提供一张五层换算矩阵，以及一条贯穿全节点的判断主轴：层级错配是 AI 产品成本判断里最高发的事故——拿低层级的便宜，去回答高层级的盈利问题。

这是管理会计里”成本对象”概念在 AI 产品上的落地。成本对象是”你想单独度量成本的那个东西”——它可以是一个 token、一次请求、一个任务、一个用户、一个席位。换个成本对象，同一笔钱的”单位成本”数字可以差几个数量级，而只有最高那层（per-user / per-seat）才直接决定毛利。

§0 为什么是”五层成本对象”这个框架，而不是”单价 vs 总成本”

读者脑子里默认的框架往往是二分的：“单位成本”和”总成本”——单价乘以量等于总账。这个框架在 SaaS 里够用，因为 SaaS 的边际成本≈0，单价这一层几乎可以忽略，关注点直接跳到 per-seat 订阅价。但在 AI 产品里这个二分框架是有害的简化，因为它把中间三层（query / task / user）压没了，而真正的成本错配恰恰发生在这三层的换算缝隙里。

为什么必须是五层而不是两层？因为这五层之间的换算系数全都不是常数，且每一跳都引入一个新的、产品侧才知道的变量：

flowchart LR
    T["per-token<br/>(工程/计费原子)"] -->|×单次token数| Q["per-query<br/>(一次请求)"]
    Q -->|×单任务请求数<br/>(Agent步数/重试/检索)| K["per-task<br/>(一个完成的任务)"]
    K -->|×人均任务数<br/>(使用强度/留存)| U["per-user<br/>(一个用户的月成本)"]
    U -->|×席位活跃率<br/>(买了但不用)| S["per-seat<br/>(一个付费席位)"]
    style T fill:#e3f2fd
    style U fill:#fff3cd
    style S fill:#ffe0e0

每往上跳一层，乘的都不是一个工程常数，而是一个产品-行为变量：token 数取决于上下文设计，请求数取决于 Agent 架构和重试策略，人均任务数取决于使用强度和留存，席位活跃率取决于销售模式（企业批量采购 vs 个人订阅）。五层框架的价值就在于：它把”为什么 per-token 很便宜但 per-user 在亏钱”这个谜，拆成了四个可以分别诊断、分别归因的换算跳跃。 二分框架做不到这一点——它只会让你在”单价明明很低”和”账单明明很高”之间反复困惑。

§1 五层成本对象逐层定义与单位

层级成本对象典型单位谁在用这个口径主要决策
per-token一个 token（输入/输出分开）美元 / 百万 token（MTok）工程、API 计费、模型选型选哪个模型、要不要量化/缓存
per-query一次 API 请求 / 一轮对话美元 / 次工程、容量规划单次请求贵不贵、要不要限制上下文长度
per-task一个对用户有意义的完成任务（可能含多次请求、检索、重试、Agent 多步）美元 / 任务产品、Agent 设计这个功能值不值得做成 Agent、深度推理划不划算
per-user一个活跃用户一个计费周期（月）的总推理成本美元 / 用户·月（COGS 的核心）产品、定价、财务免费额度怎么定、订阅价能不能覆盖、毛利多少
per-seat一个已售出的席位（B2B：买了的人不等于用的人）美元 / 席位·月商业、定价、销售企业版定价、毛利率、能不能规模化

[!note] per-user 与 per-seat 的关键区别（B2B 的隐藏红利） 在 C 端订阅里 per-user ≈ per-seat（买的人就是用的人）。但在 B2B 里两者可以差几倍：企业批量买 500 个席位，月活可能只有 30%。未激活席位的边际推理成本≈0，但订阅费照收——这是 B2B AI 产品比 C 端订阅”看起来”毛利更健康的结构性原因，也是为什么同一个产品 C 端可能亏、企业版却赚。把 C 端的 per-user 直觉套到 B2B 定价上，会严重低估企业版的真实毛利空间。

§2 五层换算矩阵（核心交付物）

下表是本节点的核心工具：从任意一层换算到相邻层，要乘哪个系数、这个系数由什么决定、为什么它不是常数。把这张表打印出来贴在定价会的墙上——每次有人报一个成本数字，先问”这是哪一层、要换到 per-user 还得乘哪几个我们其实没量过的系数”。

换算跳跃乘以的系数系数由什么决定（产品侧变量）为什么不是常数 / 高发陷阱
token → query单次请求的 token 数（input + output，含 KV/缓存折扣）上下文设计：system prompt 长度、历史轮数、RAG 注入的检索块数、output 长度RAG/长上下文让单次 token 数膨胀 10–100×；output token 通常比 input 贵数倍（见 A03 Token Economics 精算），按 input 估会严重低估
query → task完成一个任务的请求数Agent 步数、工具调用轮数、重试次数、检索召回轮数、reasoning/thinking token单轮对话 ≈1 query；一个多步 Agent 任务可能 5–50 query（每步一次推理 + 失败重试）。这是 per-token 直觉死得最惨的一跳（见 E03 一个 RAG Agent 产品的 unit economics 拆解）
task → user人均月任务数使用强度、留存曲线、重度用户长尾（power-law 分布）不是平均数能代表的——10% 的重度用户可能消耗 70%+ 的 token；用算术平均估 per-user 会被长尾彻底带偏
user → seat1 / 席位活跃率销售模式（个人订阅 vs 企业批量）、激活率、座位闲置C 端 ≈1；B2B 可能 0.2–0.5（买了不用）。未激活席位是利润，不是成本

[!warning] 这张矩阵的边界 矩阵给的是换算的结构和方向，不是可照搬的数值。每个系数都是产品特异的、会随时间漂移的、且很多在产品上线前是默会估计（留存、人均强度、激活率都是猜的）。所以从 per-token 推 per-user 永远要做敏感性分析而非单点估计——这是 Polanyi 默会知识与提示工程的认识论张力 在成本上的回响：盈亏平衡点算到小数点后两位是认识论幻觉。

§3 一个贯穿示例：同一笔钱在五层各是多少

为了让换算具象，做一次示意计算（first-order，数值标〔示意〕，结构真实、绝对值仅用于说明层级差）。假设一个 RAG 问答产品：

  • per-token：用某中端模型（如现役 Claude Sonnet 一档），input 约 $3/MTok、output 约 $15/MTok〔截至 2026-06 已核实，现役 Claude Sonnet 档 $3/$15 per MTok，来源 platform.claude.com pricing；单价 volatile 需定期复查〕——单看这一层，“便宜得不像话”。
  • per-query：一次问答塞进 8K input（system + 检索块 + 历史）+ 1K output ≈ 8×$3/1000 + 1×$15/1000 ≈ $0.039/次〔示意〕。仍然很便宜。
  • per-task：一个”研究型”任务触发 1 次 query 分解 + 3 轮检索重排 + 1 次综合 + 偶发 1 次重试 ≈ 5 query ≈ $0.20/任务〔示意〕。开始有感觉了。
  • per-user：一个活跃用户每月做 200 个任务 ≈ $40/用户·月〔示意〕。如果订阅价是 $20/月，毛利已经是负的——而 per-token 那层还在喊”便宜”。
  • per-seat：若是 B2B，企业买 100 席、活跃率 40%，分摊到席位的成本 = $40 × 0.4 = $16/席位·月〔示意〕，订阅 $30/席位则毛利转正。

[!note] 这个示例要说明的不是数字，是落差 从 per-token 的”便宜得不像话”到 per-user 的”在亏钱”，中间只隔了四次乘法，每次都乘了一个产品侧才知道的变量。任何只在 per-token 层成立的”我们很便宜”的结论，都还没有回答”我们赚不赚钱”。 volatile 的具体单价以 A03 Token Economics 精算 和 R01 最小可运行·Token 成本计算器 为准，本节点只负责换算结构。

§4 判断主轴：层级错配——五个最高发的成本事故

这是本节点的命门。下面五个错配每一个都在面试、评审会、定价会上真实高发，每个配齐 症状 → 为什么会错 → 正确做法 → 真实反例 四件套。

错配一：拿 per-token 单价谈 per-user 盈利（本节点的核心病）

  • 症状：评审会上工程说”GPT-4o mini 才几毛钱一百万 token，成本完全不是问题”，于是 PM 把免费额度定得很慷慨。
  • 为什么会错：per-token 跳到 per-user 要连乘四个系数（单次 token 数 × 单任务请求数 × 人均任务数 × 1/活跃率），每个都 >1 且产品特异。只看最底层等于把后面四次放大全忽略了。
  • 正确做法：任何盈利/定价结论必须在 per-user（C 端）或 per-seat（B2B） 层做，per-token 只能用来回答”选哪个模型”。报价前先沿换算矩阵把四个系数填上（哪怕是带区间的估计）。
  • 真实反例：2023 年多家 AI 创业公司用”token 很便宜”的直觉定了不限量或大额度的订阅，重度用户的人均调用量把 per-user 成本拉到远超订阅价，被迫事后加 rate limit / 改用量计费。OpenAI、Anthropic 的对话产品都设了消息频率上限和 context 上限——这些限制正是 per-user 成本倒逼的产品决策（见 E01 ChatGPT 与 Claude 的 context rate-limit 产品成本耦合剖解 与判断主轴 A07 成本约束反向塑造产品）。

错配二：拿 per-query 估 per-task（无视 Agent 的请求放大）

  • 症状：“一次请求才 4 分钱”被直接用来估一个多步 Agent 功能的成本。
  • 为什么会错：单轮对话 query ≈ task，但 Agent 任务的 query/task 系数是 5–50：每个工具调用、每轮检索、每次失败重试都是一次独立计费的推理。
  • 正确做法：对 Agent/RAG 类功能，成本对象必须是 per-task，并显式数清”一个任务平均触发几次推理”。
  • 真实反例：一个多步 Agent 的 per-query 成本是单次对话的数倍到数十倍——这正是 0413 总览指出”0411 Agent 专题没算的那笔账”。用 per-query 估 Agent 成本会低估一个数量级（详见 E03 一个 RAG Agent 产品的 unit economics 拆解）。

错配三：用算术平均的 per-user 做定价（无视长尾）

  • 症状：“平均每个用户每月才花我们 $3，订阅 $10 稳赚。”
  • 为什么会错：AI 产品的用量是重尾分布（power-law），10% 的重度用户可能消耗 70%+ 的 token。算术平均被长尾拉低或拉高都失真，且重度用户恰恰是最不愿流失的付费意愿者。
  • 正确做法：per-user 成本要看分布而非均值——至少看 P50 / P90 / P99，用 P90+ 用户的成本去校验”会不会被一小撮人吃穷”。定价/额度按分位数设计（如超过某用量转用量计费）。
  • 真实反例：Anthropic、OpenAI 对重度用户设的速率与额度限制，本质是在切重尾——不切的话，少数 power user 的成本能把整个用户群的毛利吃光。

错配四：C 端把 per-user 当 per-seat（B2B 错配，反向）

  • 症状：拿 C 端”每个活跃用户成本 $40”的数字，去推断企业版”每席位成本也是 $40”，于是把企业版定价定得过高、丢单。
  • 为什么会错：B2B 席位有激活率，未激活席位的边际推理成本≈0。per-seat = per-user × 活跃率，活跃率常在 0.2–0.5。
  • 正确做法：B2B 定价的成本对象是 per-seat，必须乘上激活率折扣；同时警惕”激活率会随产品粘性上升”这个动态变量。
  • 真实反例：企业协作类 AI 工具普遍按席位订阅，靠未激活席位摊薄成本——这是 B2B SaaS 把”买了不用”变成结构性利润的老套路，在 AI 产品上同样成立。

错配五：把固定成本(per-deployment)硬摊成 per-token（自建/端侧的错配）

  • 症状：自建推理或端侧部署后，把 GPU 月租/折旧除以当月 token 数，得到一个”per-token 成本”，再拿去跟 API 单价比。
  • 为什么会错：自建成本主体是固定成本（GPU 折旧/常驻显存/运维/闲置），不随 token 量线性变化。低利用率时算出的 per-token 高得吓人，高利用率时又低得诱人——这个”per-token”是利用率的函数，不是稳定单价。
  • 正确做法：固定成本主导的部署要用 per-deployment + 利用率 来核算，盈亏看”打满到什么 QPS 才比 API 便宜”，而非比单价（见 A06 端侧与云端成本重构 与 c05 - 算力物理定律与 KV Cache 的并发上限）。
  • 真实反例：自建 GPU 集群在低利用率时单位成本远高于 API（闲置烧钱），只有打满才省——许多”自建省钱”的论断只算了满载理想态，忽略了闲置（TCO 视角）。

§5 产品 PM 视角补盲：计量层级不只是会计，是产品语言

工程 PM 容易把这五层当纯财务换算。但成本对象的选择直接塑造产品形态与用户心智：

  • 计费单位即用户心智模型。按 token 计费（API 产品）逼用户去理解”为什么我的长对话更贵”，按 seat 计费（企业版）让用户感觉”买断了不心疼地用”——后者鼓励重度使用，反而推高你的真实 per-user 成本。你选的计费单位，会反过来改变用户的用量行为，进而改变你要承担的成本层级。
  • 额度的呈现层级要和用户能感知的层级对齐。给 C 端用户展示”你还剩 X 个 token”是糟糕的产品（用户无法换算成”还能聊几次”）；展示”今天还能问 X 次”（per-query/per-task 层）才符合心智。计量内部可以是 per-token，呈现必须翻译到用户能感知的层级。
  • 合规边界藏在 per-task 层。一个任务若跨了端侧（免费、隐私安全）与云端（计费、数据出境）两段，per-task 成本和合规风险是耦合的——把任务整体当一个成本对象时，别忘了它内部可能横跨两套数据治理边界（见 A06 端侧与云端成本重构）。

§6 对手框架回应：单一成本对象论 vs 五层论

业界反方立场（FinOps 简化派 / 部分财务）：“别搞这么复杂，AI 成本归根到底就是一个 COGS 数字除以用户数，盯住 per-user gross margin 就够了，中间那几层是工程细节，不该进财务模型。”

接受的部分：他们是对的——最终决策层确实只有 per-user / per-seat 那一层，毛利就是在那层算的，下面四层不直接进损益表。如果只是要回答”这个月毛利多少”，确实一个 per-user 数字就够。盯住毛利、拒绝过度工程化的成本拆解，这个纪律本身是对的。

坚持的边界：但当你要预测毛利、诊断毛利为什么恶化、或在产品上线前估一个还没有真实用量的功能的成本时，单一 per-user 数字是个黑箱——它会变、却说不清为什么变。这时必须打开五层换算，因为毛利恶化的原因总是发生在某一个具体的换算跳跃里（是上下文变长了？Agent 步数变多了？重度用户占比上升了？激活率变了？）。单层论适合事后记账，五层论适合事前预测和事中归因。 这正好对应 S03 FinOps for AI·成本可观测与归因全景 里”成本归因维度的选择不是中立的”——你按哪个成本对象归因，决定了你能看见哪类成本失控。Strathern 的审计社会学在此提醒：选择 per-user 还是 per-task 作为归因主单位，本身就在决定”哪个团队为账单负责”。

§7 跨域呼应：成本对象选择即权力分配（Strathern 审计社会学）

[!note] 跨域调度：Marilyn Strathern《Audit Cultures》——度量单位的选择不是中立的 人类学家 Strathern 指出，审计与度量从来不是对既存现实的中立测量，度量单位的选择本身在重构被度量的对象、并重新分配责任。把这把尺架到成本对象上：你选 per-token 作为主计量单位，成本失控的”责任”就落在工程（选错模型）；你选 per-task，责任落在产品（功能设计太重）；你选 per-user，责任落在增长（拉来了不付费的重度白嫖用户）。没有一个”客观正确”的成本对象——每种选择都在悄悄回答”这是谁的锅”。

这个框架具体改变了什么判断？它让我对”我们应该用哪个成本指标”这个看似纯技术的问题产生警觉：当一个组织默认用 per-user COGS 作为唯一成本 KPI 时，它结构性地看不见 per-task 层的浪费（Agent 步数冗余、重试过多），因为这些被平均进了 per-user 黑箱。反过来，一个只盯 per-token 单价的工程团队，会结构性地看不见 per-user 的亏损。所以成本治理的第一步不是”算出成本”，而是有意识地同时维护多个成本对象的视图，并意识到每个视图都在替某个团队开脱或定罪。这也是为什么 S03 FinOps for AI·成本可观测与归因全景 主张按功能/用户/租户多维归因，而不是认定某一维是”真实成本”。

§8 PM 决策启示：面试 / 选型 / 复现三类落地

  • 面试桌：被问”你怎么算一个 AI 产品的成本”，不要张口就报 per-token 单价（这是初级信号）。正确回法：“要看在哪个成本对象层——per-token 决定选型，per-user 决定毛利，中间隔着四次换算。“然后能口述换算矩阵的四个系数。这一句话立刻把你和”只会查 API 价格表”的人区分开。
  • 选型/评审会：每当有人报成本数字，先做”层级归位”——问清这是哪一层、要换到决策需要的层（通常是 per-user/per-seat）还得乘哪几个系数、这些系数我们量过没有。这能当场拆穿”per-token 很便宜所以成本不是问题”这类最常见的评审会话术。
  • 复现台：用 R01 最小可运行·Token 成本计算器 把 per-token 算到 per-query，用 R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡 把 per-query 一路推到 per-user/per-seat 并做敏感性分析。亲手跑一遍五层换算，比记住任何单价都重要。

§9 与已有节点的关系

  • 对照 A01 成本概念史与口径辨析：A01 辨的是”成本”这个词的口径（token 计费 / 推理成本 / TCO / unit economics 四种语义）；A02 辨的是同一笔成本的计量层级（成本对象）。口径回答”算的是哪种成本”，层级回答”以什么为单位算”——两者正交，是概念辨析模块的一横一纵。纠偏：A01 指出 COGS/CAC/LTV 在 AI 与 SaaS 的语义差异，A02 补上”为什么这个差异在层级换算时会被放大”（SaaS 边际成本≈0 让中间三层坍缩，AI 不行）。
  • 对照 A03 Token Economics 精算：A03 深耕 per-token 这一层的内部结构（input/output 价差、缓存折扣、thinking token）；A02 不复述这些，只把 A03 当作 token→query 那一跳的系数来源。分工：A03 管”一个 token 到底多少钱”，A02 管”这个 token 价怎么换算成毛利”。
  • 对照 m209 - 推理成本控制手册：m209 §2.6 给的成本估算停在 per-query/per-request 层（如 $1,620/百万请求这类口径）；A02 升高抽象层，指出 m209 的”百万请求”成本还要再乘人均请求数和活跃率才到毛利，把 m209 的工程估算接进商业账。不复述 m209 的具体降本数字。
  • 支撑 E03 一个 RAG Agent 产品的 unit economics 拆解 与 A07 成本约束反向塑造产品：A02 是这两个节点的方法论前置——E03 是五层换算的一次完整真实演算，A07 的”产品限制是成本影子”则建立在”per-user 成本倒逼 rate limit”这条具体换算链上。

§10 关联节点

核心（必读）

延伸（可选）

§11 修订日志

  • R0（2026-06-07，初稿）：按宪章 §4 十一段骨架与总览 §3/§4 蓝图写成 comparison 型节点。核心交付物为 §2 五层换算矩阵（token→query→task→user→seat 四跳，每跳标系数、产品侧变量、不是常数的原因与陷阱）；§3 一次贯穿五层的示意计算（数值标〔示意〕，结构真实）；§4 判断主轴给五个高发层级错配，每个配齐症状/为什么错/正确做法/真实反例四件套（核心错配一 = per-token 谈 per-user 盈利）；§6 对手回应（FinOps 单层论”接受+边界”）；§7 跨域呼应 Strathern 审计社会学（成本对象选择即权力分配，非装饰、具体改变”该用哪个成本 KPI”的判断）；§9 与 A01/A03/m209/E03/A07 显式升级对照（不复述）。已核实（2026-06-07 WebSearch）：§3 示意所用中端模型单价 input $3 / output $15 per MTok 已核实为 Claude Sonnet 4.6 当前定价（来源 platform.claude.com/docs pricing、tldl.io、pricepertoken.com，多源一致），标日期口径〔以2026-06定价为准〕；GPT-4o mini $0.15/$0.60 per MTok 亦核实（openai.com/api/pricing、devtk.ai），用于错配一的”很便宜”直觉佐证。具体最终单价一律指向 A03 Token Economics 精算/R01 最小可运行·Token 成本计算器，本节点不硬编最终单价，§3 绝对值仍标〔示意〕（用于说明层级落差，非精算）。双链：均取总览已核验的真实 basename；专题内 A0x/E0x/R0x/S0x 待落稿随专题 resolve。
  • 2026-06-11 P3.1 接地修复：§2 per-token 行的”Claude Sonnet 4.6 $3/$15·以2026-06定价为准”改为版本无关的”现役 Claude Sonnet 档 $3/$15”，并标〔截至 2026-06 已核实，volatile 需定期复查〕——经 claude-api 权威定价表复核 $3/$15 仍为现役 Sonnet 真值（4.6 版本号已被更新版取代但价格未变，去版本号抗过时）。§3 per-query/task/user/seat 的 $0.039/$0.20/$40/$16 等下游推算均已标〔示意〕、依赖此单价，单价确证后示意链成立。GPT-4o mini $0.15/$0.60 复核仍准。