AI 服务定价：当计价单位变成商品，成本导向为什么会失灵

AI 服务的定价难点不在”按什么计费”，而在”容量稀缺时谁先用”。前者是会计问题，后者是机制设计问题——绝大多数定价翻车，是把后者当成了前者。

导语

先摆一个矛盾。

云厂商卖虚拟机，成本导向定价很好用：CPU 小时、内存 GB 小时、存储 GB 月，每一项都能追到硬件折旧 + 电费 + 机房成本，加个目标毛利就是价格。

但同一个云厂商卖大模型推理 API，这套算法立刻失效：

同一张 GPU，成本随利用率剧烈变化。空闲时跑一个请求的增量成本接近 0（电费而已），满载时跑一个请求要挤掉另一个请求——**边际成本从 0 跳到”一个完整请求的收入”**。
成本导向会给出自杀式价格。按”平均利用率下的平均成本”定价，高峰期你亏（要扩容），低谷期你贵（客户跑去用批处理）。
计价单位本身在产品化。客户不是买”token”，是买”一次能拿到满意答案的调用”——而这两者的成本结构完全不同（长上下文、重试、缓存命中、思考链长度）。

所以本文的主张是：

AI 服务的定价问题，本质是”容量稀缺下的分配问题”，定价只是它的对外接口。

围绕这个主张，本文按三层拆解（计价单位 / 价格结构 / 分配机制），用经济学解释”为什么”，用工程给出”怎么算”，最后落到三类场景的选型。

面向做算法产品、AI 平台、推理服务的读者。经济学部分不要求背景，工程部分会给出可复算的成本公式。

0. 一个必须先建立的分解：三层定价

大多数关于 AI 定价的讨论在混淆三件不同的事。分开看，问题会清晰一半。

层	回答什么	典型选项	谁决定
L1 计价单位（Metering）	数什么	token / 请求 / 小时 / 并发 / 任务 / 席位	产品 + 财务
L2 价格结构（Structure）	价格怎么随用量变	线性 / 阶梯 / 两部制 / 订阅 / 打包	定价策略
L3 分配机制（Allocation）	稀缺时谁先用	先到先得 / 优先级 / 拍卖 / 配额	系统设计

关键判断：AI 服务的难点几乎全在 L3，但绝大多数讨论停在 L1。

举一个具体的例子说明为什么：

两个客户都买”100 万 token / 月”。A 客户在凌晨批量跑，B 客户在上午 10 点做实时客服。
同样的计价单位（token）、同样的价格结构（线性），但成本完全不同——B 的高峰请求挤占了本该给其他客户的 GPU 时间。

如果你的定价只覆盖 L1 和 L2，B 就在系统性补贴 A 的反面：A 的低谷用量本来便宜，却按统一单价付费；B 的高峰占用很贵，也按统一单价付费。这不是”定价”，这是”平均”。

0.1 三层之间的耦合关系

这三层不是独立的，改动任何一层都会牵动其他两层：

L1 计价单位  ──决定──>  成本可归因性（能不能算清单个请求的成本）
                            ↓
L2 价格结构  ──决定──>  客户的自选择（谁会被吸引来、谁会被赶走）
                            ↓
L3 分配机制  ──决定──>  实际成本（拥塞、排队、闲置）
                            ↑
                            └── 反过来影响 L1（真实的成本分布）

这张图最重要的信息是那条向上的箭头：L3 的分配效率决定了 L1 的成本基数。如果你的集群利用率只有 30%，那么”按 token 分摊成本”算出来的单价会高得离谱——而这不是定价问题，是利用率问题。

我见过的最常见的定价翻车就是这一类：用一个低效系统算出的单位成本，去定一个高效率竞品的价格。

1. 三种经典定价导向，以及它们各自在哪一步失灵

1.1 成本导向（Cost-Plus）

公式：

1	价格 = 单位成本 / (1 − 目标毛利率)

它的前提：单位成本可稳定测算，且不随销量剧烈变化。

在 AI 服务上，这个前提有两个硬伤：

硬伤一：单位成本不是常数，是利用率的函数

1	单位成本 = 固定成本 / 有效吞吐量

而 有效吞吐量 取决于 batch size、序列长度分布、KV cache 占用、调度策略。同一个模型、同一批 GPU，吞吐可以差 3–5 倍（取决于这些工程细节）。

后果：**”算出单位成本”这件事本身就是一个系统测量问题，不是一个会计问题。** 详见第 6 节。

硬伤二：成本导向在产能受限时会导致分配失效

如果按”平均成本 + 毛利”定价，价格是固定的。当需求超过产能时：

价格不会涨（不反映稀缺）；
于是只能靠排队或限流分配；
结果是”先到先得”——而这个分配结果和”谁最需要/谁付得起”毫无关系。

这正是云厂商在 GPU 紧张时期出现的现象：价格不变，但拿不到卡。经济学上这叫”非价格配给”，代价是效率损失（有些高价值需求拿不到资源）和寻租（要托关系）。

成本导向的正确用法：它是下限约束（不能低于成本卖），不是定价公式。

1.2 价值导向（Value-Based）

公式：

1	价格 = 客户获得的价值 × 分成比例

它的难点在”价值”怎么度量。AI 服务的价值度量有三个层次：

层次	度量方式	问题
替代成本	客户自己做这件事要花多少钱（雇人、买传统软件）	最稳，但需要客户侧的基线数据
增量收益	带来的收入增长 / 成本节省	最有说服力，但归因极难（效果和其他系统耦合）
支付意愿	调研 / 实验 / A/B	直接，但 AI 产品的支付意愿高度依赖”是否真的解决了问题”

一个实务上的可操作做法：用”替代成本”定锚，用”增量收益”做溢价论证。

例（面向客服场景的 AI 服务）：
  替代成本：一个客服席位月成本 8k，AI 能承接 40% 的工单
  → 价值锚点 ≈ 3.2k / 月 / 万次工单
  定价 = 锚点 × 分成比例（如 30–50%）
  → 约 1k–1.6k / 月

价值导向的根本困难：AI 服务的价值高度依赖客户的使用方式。同一个模型，A 客户做得好（prompt 精心设计、有 RAG、有验证），B 客户做得差（直接裸调用）。**你卖的是”能力”，客户买的是”结果”**——中间的落差谁来承担？

这直接引出 AI 定价里最尖锐的一个问题：要不要为结果负责（outcome-based pricing）？

模式	收费依据	优点	缺点
按用量	token / 调用次数	简单、成本可覆盖	客户承担”效果不确定”的风险
按结果	解决率 / 转化率	客户风险低、易卖	归因争议、可被操纵、现金流不稳
按席位	用户数	可预测	与用量脱钩，重度用户亏

我的判断：纯 outcome-based 在基础设施层不可行（因为结果不由你单独决定），但在应用层可行（因为你可以控制完整链路）。混合模式（底价 + 结果分成）是更稳的形态。

1.3 竞争导向（Competition-Based）

逻辑：看竞品定价，跟随或差异化。

AI 服务在这一导向下有一个独特现象：价格战的传导速度极快，因为能力差异难以感知。

1
2
3

模型能力差距 10% → 客户感知不到
价格差距 10% → 客户立刻感知
→ 竞争很快退化为纯价格竞争

这解释了为什么 2024–2026 年大模型 API 的价格下降速度远超成本下降速度——不是成本驱动，是竞争驱动。

但竞争导向有一个陷阱：如果你的成本结构比对手差（比如自研推理优化不如对方），跟着降价就是加速亏损。降价的前提是自己有成本优势，否则是自杀。

1.4 三种导向的适用位置

导向	适用位置	不适用
成本导向	定价下限、内部结算、容量规划	对外定价公式
价值导向	定价上限、高价值垂直场景、企业合同	同质化 API
竞争导向	定价区间校准、市场进入策略	长期唯一依据

实操上，三者是”三段式”关系：

1	价格 ∈ [成本下限, 价值上限]，在区间内按竞争位置落点

先算清下限（否则越卖越亏），再论证上限（否则卖不出溢价），最后看竞争定落点。

2. AI 服务的六个经济学特征

这一节是全文的理论核心。六个特征里，第 2 条和第 6 条是关键。

2.1 特征一：固定成本极高，边际成本趋近 0（但只在非饱和时）

成本结构：

成本项	性质	说明
GPU 采购/租用	固定（按时间）	主要成本项，60–80%
电力与制冷	半固定	与负载相关但非线性
网络与存储	变动但小	权重加载、日志
人力（研发/运维）	固定	分摊到单位成本上是会计选择
单次推理的增量成本	≈ 0（空闲时）	只有电费

关键推论：AI 服务是”高经营杠杆”生意——成本几乎固定，收入随用量增长。所以：

利用率 30% 时，单位成本是 90% 时的 3 倍；
利润率对利用率极度敏感，远超过对定价的敏感度。

这意味着一个反直觉的结论：

很多 AI 服务的”定价问题”，本质是”利用率问题”。

如果你的集群利用率只有 25%，你应该优化调度和批处理（把利用率提到 60%），而不是降价抢量——因为降价带来的量未必能把利用率补回来，而成本下降是确定的。

2.2 特征二：容量硬约束下，边际成本 = 影子价格

这是最重要的一条，也是成本导向失效的根源。

利用率 < 阈值（约 70%）：
    边际成本 ≈ 电费 + 极小的调度开销 ≈ 0
    此时"多服务一个请求"几乎免费

利用率 > 阈值（约 85%）：
    边际成本 = 被挤掉的那个请求的价值（机会成本）
    此时"多服务一个请求"要牺牲别人

经济学的表述：产能约束的影子价格（shadow price / dual price）。

把它写成优化问题就很清楚：

1
2
3

max  Σ_i p_i · x_i
s.t. Σ_i c_i · x_i ≤ C        （容量约束，c_i 是请求 i 消耗的资源）
     x_i ≥ 0

拉格朗日乘子 λ（容量约束的对偶变量）就是单位容量的影子价格：

λ = 0 → 容量有余，不该涨价（此时定价 = 边际成本 ≈ 0）；
λ > 0 → 容量紧张，最优价格 = 边际成本 + λ。

这个结论直接给出了”动态定价”的理论依据：不是因为”需求大所以要涨价”（那是经验），而是因为容量约束的对偶变量在告诉你，每单位资源此刻的机会成本是多少。

工程含义（很重要）：

你不需要真的去解这个 LP。你只需要监控 λ 的代理指标——例如队列等待时间、GPU 显存占用率、KV cache 命中率、调度拒绝率。

这些运维指标，就是影子价格的观测量。 当排队时间变长时，λ 在上升，说明当前价格偏低（相对于稀缺度）。

这解释了一个现象：为什么云厂商在 GPU 紧张时最先动的不是价格，而是配额和优先级——因为直接涨价会引发客户反弹（见 5.1），但调整配额是”技术调整”，阻力小得多。从经济学上说，两者都是在给 λ 定价，只是前者显性、后者隐性。

2.3 特征三：成本随序列长度非线性变化（计价单位的技术根源）

这一条直接决定 L1（计价单位）怎么设计。三类计算的成本结构完全不同：

阶段	计算特性	成本与什么成正比	能否批处理
Prefill（处理输入）	计算密集（矩阵乘）	输入 token 数（线性）	✅ 好（并行）
Decode（逐 token 生成）	访存密集（每 token 要读一遍权重）	输出 token 数 × 1/batch	✅ 好（batch 共享权重读取）
KV cache（存历史）	显存占用	上下文长度（线性）× 并发数	❌ 是占位，不是计算

这解释了两件事：

① 为什么 output token 比 input token 贵（通常 3–5 倍）

1 2	Prefill：一次矩阵乘处理 N 个输入 token → 摊薄，单位成本低 Decode：每个 token 要完整跑一次前向 → 串行，单位成本高

用一个粗略的公式看（量级示意，非精确）：

1	decode 的 token 吞吐 ≈ batch_size × HBM_带宽 / 模型字节数

70B 模型 fp16 ≈ 140 GB；H100 的 HBM 带宽约 3.35 TB/s。batch=64 时：

1	tokens/s ≈ 64 × 3350 / 140 ≈ 1530 tok/s

而 prefill 是算力密集，同样硬件下单位 token 的成本可以低一个数量级。这个 3–5 倍的价差不是”营销策略”，是物理。

② 为什么长上下文有”隐性成本”（这是最被低估的）

KV cache 占用显存 → 挤占 batch size → 降低所有请求的吞吐 → 抬高全局单位成本。

1	KV cache per token ≈ 2 × 层数 × kv_head数 × head_dim × 精度字节

对一个 70B 级模型（80 层、GQA、fp16），每 token 的 KV cache 约 0.3–0.6 MB。32K 上下文 = 10–20 GB。而一张 H100 才 80 GB。

所以：一个 32K 上下文的请求，占用的显存相当于几十个 1K 上下文的请求，但如果你”按 token 统一计价”，它只付了 32 倍的输入 token 钱——这是严重的交叉补贴。

这就是 prompt caching 折扣、以及按上下文长度分段定价的技术根源。它不是让利，是纠正错误的分摊。

2.4 特征四：资源可弹性，但弹性有延迟与不可逆性

资源	弹性	延迟	不可逆性
无状态推理（serverless）	高	秒级（冷启动）	低
有状态会话（KV cache 驻留）	中	分钟级（迁移/重建）	中
独占 GPU（预留实例）	低	小时–天	高（合同期）
自建集群	极低	月–季度	极高

定价含义：

弹性越高，越适合按量计费（成本随用量走）；
不可逆性越高，越适合预留/承诺折扣（客户用承诺换低价，你换现金流和可预测性）；
中间的”有状态会话”是最难定价的——它占用资源但你不知道它什么时候释放。这就是为什么”会话超时”要收费（或至少要有闲置回收）。

2.5 特征五：QoS 可以分层，且分层成本很低

这是 AI 服务相对传统云的一个巨大优势。

可以分层的维度：

维度	分层方式	实现成本
延迟（TTFT）	优先级队列 / 抢占	低（调度器改几行）
吞吐（tok/s）	batch 优先级、更大 GPU	低–中
可用性（SLA）	冗余部署、隔离池	中
上下文长度	不同模型/分块策略	中
模型档位	大/中/小模型路由	低（路由层）

为什么这条重要：QoS 分层是”价格歧视”最优雅的实现方式——它不伤害任何人的自尊（你买”更快的”而不是”更贵的”），且技术上真实存在成本差异（优先级队列确实占用了更多资源）。

这就是第二度价格歧视（self-selection）：不用问客户”你愿意付多少”，而是给一个菜单，让客户自己选。

关键设计原则：菜单要让”高支付意愿客户”自愿选择高价档，而不是被迫。

失败的菜单：标准版限速 5 tok/s，专业版不限速
  → 高支付意愿客户觉得"被故意卡脖子"，反感

成功的菜单：标准版 20 tok/s + 99% 可用性，专业版 80 tok/s + 99.9% 可用性 + 优先支持
  → 差别在"你有多急"，客户理解并接受

2.6 特征六：成本快速下降，但价格有粘性

观察到的现象（2024–2026）：单位 token 的推理成本下降了一个数量级以上（模型量化、更好的 kernel、投机解码、更便宜的硬件）。

**这带来一个定价上的”棘轮效应”**：

情况	后果
成本降了，价格不降	短期毛利暴涨 → 竞品降价抢量 → 被迫跟进，但客户已流失
成本降了，主动降价	客户预期”还会更便宜” → 推迟采购 → 现金流受损
成本降了，价格不变但提升配额	最稳的路径：客户感知”更划算”，你的名义价格没变

第三条是关键策略：**用”加量”代替”降价”**。原因有二：

避免价格锚定被打破（一旦降到某个数，客户会认为那是新基线）；
避免触发已有客户的重新谈判（价格没变，合同不用重签）。

但这条有边界：如果竞品降价 50% 而你只是”加量 20%”，客户会算清楚。加量策略适用于”成本温和下降”，不适用于”成本腰斩”。

3. 五种定价范式：它们的本质是三度价格歧视

把常见的定价方式映射到经济学框架，会看得更清楚。

范式	收什么钱	经济学本质	解决什么问题
按量计费（pay-as-you-go）	用量 × 单价	一度价格歧视的近似（不完全）	成本可覆盖、门槛低
订阅（flat rate）	固定月费	打包 / 期权	收入可预测、客户决策简单
阶梯定价（tiered）	分段单价	二度价格歧视（数量折扣）	大客户留存、鼓励用量
两部制（two-part tariff）	固定费 + 用量费	二度价格歧视的经典形式	覆盖固定成本 + 按边际定价
动态定价（dynamic）	随供需变价	三级（完全）价格歧视的近似	削峰填谷、容量变现
拍卖（auction）	竞价	机制设计 / 显性价格发现	稀缺资源的有效分配

3.1 按量计费：最”公平”也最不可预测

优点：成本可覆盖、无逆向选择、客户觉得公平（用多少付多少）。

缺点：

收入不可预测（客户自己也不知道会用多少）；
客户有”计量焦虑”**——每次调用都在花钱，导致使用保守，这会压制产品价值实现**；
计价单位成为争议焦点（为什么这次调用扣了 1,200 token？）。

第三条是 AI 服务特有的痛点。传统云计费（CPU 小时）客户能理解，但”token”对客户是黑箱：

输入 token 怎么算的？（不同 tokenizer 切法不同）
为什么一次”你好”扣了 80 token？（system prompt + 历史）
重试算不算钱？

实践建议：把”计费明细”做成产品功能（每次调用返回 usage 明细、可查历史、可设预算告警）。计量透明度直接决定客户的使用深度——不透明的计费会让客户用得更保守，你的收入反而更低。

3.2 订阅：把波动风险从客户转给你

本质：你卖的是一个”看涨期权”——客户付固定费，换取不限量（或高额度）使用。

这带来一个经典的逆向选择问题：

重度用户会优先选择 flat rate，轻度用户会选按量。
如果定价按”平均用户”算，你会被重度用户吃掉利润。

这就是 **”自助餐悖论”**（all-you-can-eat pricing）：定价必须按”重度用户的成本”来定，否则必亏；但按重度用户定价，轻度用户会觉得贵而不买。

三种解法：

解法	机制	代价
公平使用条款 + 限流	名义不限量，实际超过阈值就降速/排队	客户体验受损（”说好的不限量呢”）
分段订阅（额度 + 超额按量）	订阅含 N 次，超出按量	计量焦虑回来了
按席位/按结果	与用量解耦，与人数/结果挂钩	需要客户规模可度量

AI 服务的特殊困难：用量差异极大。同一个订阅，有人一天 10 次，有人一天 10,000 次，成本差 1,000 倍。这在传统 SaaS 里很少见（Seat 的用量差异通常 10 倍以内）。

所以纯 flat rate 在 AI 服务上很难长期成立，除非：

客单价足够高（能覆盖 P95 用户的成本）；
或产品本身限制了用量（如”每月生成 500 张图”）。

3.3 阶梯定价：鼓励用量的同时保护毛利

两种阶梯形态，方向相反：

形态	单位价格随用量	目的	适用
递减阶梯（volume discount）	用越多单价越低	激励增长、留住大客户	大多数 B2B
递增阶梯（tiered / progressive）	用越多单价越高（边际）	抑制过度消耗、保护资源	资源紧张时

递减阶梯的经济学：本质是数量折扣，让大客户的价格接近你的边际成本（而非平均成本）。这是有效的，因为你的边际成本确实低。

递增阶梯的适用场景（很少被讨论但很重要）：

免费额度 + 超出后提价（防滥用）；
高并发/高峰期的用量提价（削峰）；
超长上下文的边际提价（反映 KV cache 成本）。

一个混合设计（实践中效果好的）：

第 1 段：0–100 万 token     单价 A（基准）
第 2 段：100 万–10 亿        单价 0.85A（数量折扣）
第 3 段：> 10 亿             单价 0.7A（大客户）
另加：单请求上下文 > 32K 时，该请求按 2× 计费（反映显存成本）

最后一条是关键：阶梯折扣 + 长度附加费，两者方向相反但服务于不同目标（激励量 vs 纠正分摊）。

3.4 两部制：AI 服务最被低估的形态

结构：

1	总价 = 固定费（capacity reservation）+ 用量 × 单价（usage）

为什么它适合 AI 服务：

优势	机制
覆盖固定成本	固定费直接对应”我给你留了这么多卡”
让边际定价回归效率	用量部分可以定得接近边际成本（因为固定成本已被覆盖）
客户自选择	需要稳定性的客户买高固定费、低单价；波动型客户买低固定费、高单价
可预测性	固定部分给出收入底盘

这就是云厂商”按需 vs 预留实例/承诺用量折扣（CUD）”的本质，也是”BigQuery on-demand vs flat-rate”的本质。

对 AI 服务特别有价值的原因：AI 的固定成本占比极高（60–80%），纯按量计费意味着”所有的固定成本风险都由你承担”。两部制把这个风险部分转移给愿意承担（换取折扣）的客户。

设计要点：

1 2	固定费应 ≈ 客户承诺占用容量的成本 × (1 - 折扣率) 用量单价应 ≈ 边际成本 × (1 + 小毛利)

如果用量单价定得太高（想多赚），客户会算出来”我不如自己建”。

3.5 动态定价：理论最优，实践要极度小心

理论依据（见 2.2）：价格 = 边际成本 + λ，λ 是容量约束的影子价格。

三种实现强度：

强度	做法	客户感知	适用
L1 内部（推荐）	对外价格不变，内部用 `λ` 做调度/配额决策	无感知	几乎所有场景
L2 分时（谨慎）	高峰期价格上浮（如 1.5×）	弱（可预告）	批量计算、非实时任务
L3 实时（几乎不可行）	价格随实时供需波动	强（反感）	现货市场、竞价实例

为什么 L3 在 AI API 上几乎不可行：

客户无法做价格响应。一个客服系统的调用量由业务量决定，不会因为”现在贵 30%”而少调用——需求是刚性的；
公平性感知极差。Kahneman 的经典结论：**涨价被认为不公平，尤其是”同样的东西在不同时间不同价”**；
客户无法预算。企业客户的采购和财务要求成本可预测。

所以动态定价在 AI 服务上的正确形态是”隐性”的：

1 2	对外：固定价格表 + 明确的优先级档位对内：用影子价格调度（高峰期优先保障高优先级客户）

这在经济学上等价于动态定价（高价值客户在高峰期获得资源），但客户看到的是”我买了高优先级”，而不是”我被动态加价了”。

这是本文最重要的一个实务结论：

AI 服务的动态定价，应该实现为”优先级 + 配额”，而不是”价格波动”。

3.6 拍卖：什么时候真的需要

拍卖适用条件（三条同时满足）：

资源同质且稀缺（大家抢同一种东西）；
价值异质（不同买家对它的估值差异大）；
需求可延迟（抢不到可以等）。

AI 服务里符合的场景：

场景	是否符合	说明
现货 GPU（抢占式实例）	✅	经典场景，AWS Spot 就是拍卖
批量推理的错峰调度	✅	任务可延迟，用低价换延迟
预留容量的分配（大客户）	⚠️	通常用谈判而非拍卖
在线 API 的每次调用	❌	需求刚性、延迟敏感、拍卖开销不划算

一个正在出现的新场景：Agent 之间的服务采购。当 AI Agent 需要调用其他服务（工具、数据、其他模型）时，”谁出价高谁先被服务”可能成为自然机制。但这个领域目前是概念多于实践，不建议作为近期设计目标。

4. 与推荐/分配算法的结合：定价作为优化目标

这一节讲工程与算法的交叉。核心观点：定价不应该是一个”业务拍板”的静态数字，而应该是系统中一个可优化的决策变量。

4.1 定价与分配的联合优化（对偶视角）

先把问题写清楚。假设有 n 个请求、m 类资源（GPU 类型/显存/带宽）：

max_{x, p}  Σ_i p_i · x_i                     ← 收入
s.t.        Σ_i a_{ij} · x_i ≤ C_j   ∀j        ← 容量约束
            x_i ∈ {0,1}                        ← 是否服务（或 x_i 为用量）
            p_i ≥ 0

如果 p_i 是外生给定的（价格已定），这就退化成”带权重的装箱/分配问题”——定价不参与优化。

如果 p_i 是决策变量，就变成定价-分配联合优化。这时最优定价有闭式结构：

1	p_i* = 边际成本_i + Σ_j λ_j · a_{ij}

其中 λ_j 是第 j 类资源容量约束的对偶变量。

这个式子的三个含义：

含义	解释
价格 = 边际成本 + 资源占用加权影子价	资源密集型的请求应该更贵，不是因为”我们想多赚”，而是因为它挤占更多稀缺资源
`λ_j = 0` 时价格 = 边际成本	资源不稀缺就不该有溢价
`λ_j` 随时间变	这就是”动态定价”的严格来源

工程落地的正确姿势（不要真去解 LP）：

1. 选定"影子价格的代理指标"：
   λ_gpu   ← GPU 利用率 / 队列长度 / 拒绝率
   λ_mem   ← KV cache 占用率
   λ_net   ← 出口带宽利用率

2. 把这些指标聚合成"拥塞分数" c(t)（0–1）

3. 用 c(t) 驱动三类决策（按激进程度）：
   a) 调度：c 高时优先服务高优先级（不改价格）  ← 默认
   b) 配额：c 持续高时降低低优先级客户的速率上限
   c) 价格：只在批量/非实时产品上做分时定价

关键洞察：调度、配额、价格，是同一件事的三种实现。 选哪个取决于”客户能接受哪种形式的不公平”。

4.2 收益管理：把航空业的方法搬过来

收益管理（Revenue Management / Yield Management） 是航空、酒店的经典方法，它解决的问题与 AI 服务高度同构：

航空	AI 推理服务
同样的座位，卖给不同乘客价格不同	同样的 GPU 时间，卖给不同客户价格不同
座位是易腐库存（起飞就浪费）	GPU 时间是易腐库存（空闲就浪费）
提前购票便宜、临时购票贵	批量/可延迟任务便宜、实时任务贵
超售（overbooking）对冲 no-show	超卖配额（oversubscription）对冲低使用率

三个可直接借用的工具：

① Littlewood 规则（两舱位容量分配）

1	接受低价客户的条件：p_low ≥ p_high × P(需求_high > 剩余容量)

搬到 AI 上：是否接受一个低优先级（低毛利）的批量任务，占用了本可能留给实时高价值客户的容量？

1	接受条件：p_batch ≥ p_realtime × P(高峰期实时需求 > 剩余容量)

这个规则的价值：它给出了”什么时候该拒绝生意”的量化标准。很多团队不敢拒绝低毛利订单，结果高峰期被低价值任务占满。

② EMSR-b（多舱位保护水平）

多档优先级（如 3 档 QoS）时，如何给每档预留容量。核心是”保护水平”（protection level）：

1	保护水平_k = 满足 k 档及以上需求的容量

搬到 AI 上：为高优先级客户预留多少 GPU。预留太多 → 低峰期浪费；预留太少 → 高峰期高价值客户排队。

③ 动态规划/随机规划求最优策略

当需求分布已知（可从历史数据估计）时，可以用 DP 求”每个时间点该接受什么价格的需求”。这在批量推理产品上有实用价值（因为延迟容忍度高，可以真正做”接单/拒单”决策）。

4.3 拥塞定价与优先级定价

拥塞定价（congestion pricing）：当系统接近饱和时，提高价格以抑制需求。

它的理论最优形式（Mendelson-Whang 型模型）：

1 2	总福利 = 用户价值 − 拥塞成本（延迟）最优价格 = 边际拥塞外部性

关键点：价格 应该等于”你的请求给别人造成的延迟成本”。这是庇古税（Pigouvian tax）的思路。

但在 AI 服务上，直接做拥塞定价有三个问题：

需求刚性（客户不能因为贵就不调用）；
公平性感知差；
价格波动破坏预算。

**所以更实用的形态是”优先级定价”**：

客户从菜单中选择优先级（而不是被动态定价）：
  标准档：$X / 百万 token，P95 延迟 2s，可能排队
  优先档：$2X / 百万 token，P95 延迟 500ms，优先调度
  
机制：优先档的请求在调度器里有更高的权重

这个设计的三个优点：

优点	机制
自选择	急的客户自愿付溢价，不急的客户省钱
效率	高价值请求优先获得资源（社会总福利更高）
公平感	客户买的是”更快的服务”，不是”被加价”

这正是 2.5 节说的”QoS 分层是价格歧视最优雅的实现”。

4.4 Bandit 做价格实验

定价实验的困难：不能像推荐那样大规模 A/B（价格变动会被客户看到，且不能对不同客户显示不同价——法律与公平性问题）。

可行的做法：

方法	应用	注意
地理/账户分层 A/B	不同区域/新客户用不同价格表	避免”同客户看到不同价”
Contextual Bandit	对新客户动态选”首购折扣”	只用于促销，不用于基础定价
需求曲线估计	从历史数据拟合”价格-用量”弹性	需要价格变动历史（自然实验）
联合测价（conjoint）	调研”你愿意为 X 付多少”	偏差大，只做方向参考

一个现实提示：基础价格几乎不能做 bandit 实验（因为价格是公开的、客户会交流），但折扣/优惠券/首购激励可以。所以 bandit 的正确用法是”促销优化”，不是”定价优化”。

4.5 机制设计的边界：什么是”好”的定价机制

一个”好”的定价机制（在机制设计意义上）应该满足：

性质	含义	在 AI 定价里是否容易满足
激励相容（IC）	客户说真话最优	⚠️ 难（客户会低报用量以获折扣）
个体理性（IR）	参与不亏	✅ 易（价格低于价值即可）
预算平衡	平台不补贴	✅ 易
无嫉妒（envy-free）	没人想换别人的套餐	⚠️ 难（大客户折扣会引发小客户不满）
可计算	能实时定价	✅ 易（影子价格可用近似）

实践上最需要关注的是”无嫉妒”**：大客户折扣是必给的，但必须”可解释”**（”因为承诺量，所以单价低”），否则小客户会觉得被不公平对待。

设计建议：把折扣绑定到义务（承诺量、预付、长约），而不是绑定到”客户规模”。这样折扣就是”用确定性换价格”，逻辑上站得住。

5. 成本测算：这一节决定你的定价有没有地基

前面讲了很多经济学，但如果单位成本算错，所有定价都是错的。而 AI 服务的单位成本极其难算——这是我认为最被低估的工程问题。

5.1 完整成本模型

月总成本 = 
    GPU 成本（自有：折旧 + 电费 + 机房；租用：租金）
  + 网络成本（出口带宽、跨区传输）
  + 存储成本（模型权重、日志、缓存）
  + 平台成本（调度、监控、网关的服务器）
  + 人力成本（研发、运维、支持）
  + 分摊的研发摊销

分层归因：

层级	内容	归因方式
直接成本	该请求消耗的 GPU 时间	可精确计量
半直接成本	该请求占用的 KV cache（影响别人）	需建模
间接成本	平台、人力、研发	按用量或收入分摊

关键：不要在间接成本上纠结精确性。 分摊方法的差异（按 GPU 秒、按 token、按收入）会导致单位成本差 20–30%，但这部分不是定价的主要矛盾——主要矛盾在直接成本和半直接成本。

5.2 单位成本的核心公式

这是本文最”可执行”的部分。给出可复算的框架：

Step 1：算 GPU 小时成本

1	C_gpu_hour = (卡价 / 折旧年限 / 8760) + 功耗 × 电价 + 机房分摊

示例（单卡，数量级示意）：

卡价 25 万元，折旧 3 年 → 25万 / 3 / 8760 ≈ 9.5 元/小时
功耗 0.7 kW × 电价 0.6 元/kWh ≈ 0.42 元/小时
机房 + 网络分摊 ≈ 0.5 元/小时
→ C_gpu_hour ≈ 10.4 元/小时

租用等价：如果是租云，单卡 H100 级实例的公开价格在几十元/小时量级（具体价格波动大，务必自行核实）。

Step 2：算有效吞吐

这是最容易出错的一步。**不要用”峰值吞吐”，要用”生产环境实测吞吐”**：

1 2	有效吞吐(tokens/s) = 单卡批次吞吐 × 卡数 × 并行效率 × 有效利用率

其中：

单卡批次吞吐：在目标 batch size 和序列长度分布下实测（不是理论峰值）；
并行效率：张量并行的通信开销，通常 0.7–0.9；
有效利用率：请求间隔、扩缩容、故障、测试流量——这是最被高估的一项，生产环境常只有 40–70%。

Step 3：算单位成本

1	成本 / 百万 token = (C_gpu_hour / 3600) / 有效吞吐 × 1e6

示例（假设）：

1
2
3

C_gpu_hour = 10.4 元
有效吞吐 = 1500 tokens/s（单卡，70B 级模型，含批处理）
→ 成本 = (10.4/3600) / 1500 × 1e6 ≈ 1.93 元 / 百万 token

注意这个数字的含义：它是纯推理成本，不含研发、平台、销售、毛利。加上这些后，实际成本可能是它的 2–3 倍。

5.3 三个必须单独建模的成本项

① Prefill 与 Decode 的成本比

两者成本结构不同（见 2.3），所以：

1	成本 = a × input_tokens + b × output_tokens

a/b 的比值取决于：

模型大小（越大差距越明显）；
batch 能力（prefill 更容易批处理）；
硬件（算力/带宽比）。

经验上 b/a ≈ 3–5**（这是量级，需自测）。这就是”output token 比 input 贵 3–5 倍”的技术依据**——如果你定成 1:1，你就在补贴 output 密集型的客户（长文生成、代码生成）。

② KV cache 的”占位成本”

1	KV_cache_bytes = 2 × layers × kv_heads × head_dim × dtype_bytes × seq_len

它对成本的影响是间接的：占用显存 → 降低可用 batch → 降低吞吐。

量化方式：算”每 GB 显存小时的成本”，然后按请求占用的 KV cache GB 数 × 时长计费。

1	C_kv = C_gpu_hour / 显存容量(GB) × KV_cache_GB × 时长(小时)

**这就是为什么需要”上下文长度附加费”或”prompt caching 折扣”**——不是营销，是纠正分摊。

③ 重试与失败的成本

一个失败重试的请求，成本是双份的（第一次也消耗了算力）。如果失败率 5%，实际成本比”成功请求成本”高 5%。

如果按”成功请求”计费，你就在承担失败的成本。这是定价时必须计入的隐性成本项。

5.4 一个自查清单

在定价上线前，逐条确认：

检查项	不做的后果
单位成本是否基于生产实测吞吐而非理论峰值？	严重低估成本（常见 2–3 倍偏差）
是否单独测了 prefill / decode / KV cache 三项？	输入输出定同价 → 结构性补贴
是否计入了有效利用率（不是 100%）？	同上
是否计入了重试成本和空闲资源？	同上
是否用峰值负载验证过容量规划？	高峰期雪崩
是否算了P95/P99 用户的成本（不是平均）？	flat rate 被重度用户吃穿
是否算过毛利敏感性（利用率 ±20% 时毛利变化）？	利用率一波动就亏损

最后一条最重要：做一次敏感性分析。

利用率  40% → 单位成本 2.4×基准
利用率  60% → 1.6×
利用率  80% → 1.2×
利用率 100% → 1.0×

如果你的价格在利用率 60% 时毛利 50%，那么在利用率 40% 时毛利就是负的。 这个信息比”定价多少”重要得多。

6. 落地难点：五个真实的坑

6.1 坑一：用户感知——“为什么这次扣了 1,200 token？”

问题本质：AI 的计量单位对客户不透明，且不可直观验证。

传统云计费，客户能理解”我开了一台 4 核 8G 的机器，跑了一小时”。但 token 计费：

客户不知道 tokenizer 怎么切（”你好”是 1 个还是 2 个 token？）；
客户不知道 system prompt 和对话历史也算钱；
客户无法预估”我这个需求大概要多少 token”。

后果：计量焦虑 → 使用保守 → 产品价值无法实现 → 续约率低。

解法（按有效性排序）：

解法	效果
实时 usage 回显（每次响应带 usage 明细）	高（透明度直接降低焦虑）
预算与告警（设月度上限、80% 提醒）	高（把”不可控”变”可控”）
费用预估器（输入 prompt 就估出成本）	中高（降低试错成本）
包月额度 + 超额提示	中（把波动变成可预期）
成本解释文档（为什么 output 比 input 贵）	中（教育客户）

一个反直觉的结论：计费越透明，客户用得越多。 很多团队怕”透明会让客户觉得贵”，实际相反——不透明才让客户保守。

6.2 坑二：算力成本波动——成本基准在漂移

三个波动源：

源	影响
硬件价格波动（GPU 供需）	自有集群的折旧假设失效；租用的价格随行就市
电价波动（分时电价、区域差异）	训练/批量推理可以迁移，在线服务不行
技术迭代（量化、新 kernel、新硬件）	单位成本可能一年降 2–5 倍

后果：定价的”成本地基”每季度都在变。

应对：

成本基准定期重算（建议每季度），并记录历史（用于解释”为什么降价”）；
价格与成本解耦：定价基于”目标毛利率”而非”绝对成本”，这样成本降了毛利自动上升（可选择性让利）；
不要用”最新最优成本”定价。如果你按”最好情况（90% 利用率 + 最优 batch）”定价，一旦实际利用率掉到 50%，就亏损。用”可持续达到的成本”定价。

6.3 坑三：逆向选择与”用量异常”

AI 服务有一个传统 SaaS 没有的问题：单个客户可以消耗任意多的资源。

现象	机制	后果
重度用户聚集	flat rate 吸引高频用户	毛利被吃穿
批量任务混入在线	在线 API 被用来跑离线批处理	高峰期资源被占
滥用与转售	一个 API key 被多人共享/转卖	用量失控、无法归因
长上下文滥用	每请求塞满 128K 上下文	KV cache 被占满

应对（组合拳）：

1. 速率限制（RPM / TPM）+ 并发上限
2. 分级配额（不同套餐不同上限）
3. 异常检测（用量突增告警、行为模式识别）
4. 上下文长度附加费（让滥用者付费）
5. 公平使用条款（法律兜底）

第 4 条最关键：不要用”禁止”来解决滥用，用”定价”来解决。 长上下文是合理需求，只是成本高——收费即可，不要封禁。

6.4 坑四：客户预算流程与价格变动

企业客户的现实：

1	年度预算 → 采购审批 → 合同 → 执行

这意味着：

价格变动需要重新走审批（半年周期）；
不可预测的账单会被财务拒绝（这比”贵”更致命）；
价格上调几乎不可能（要走新一轮谈判）。

所以对企业客户，”价格稳定”比”价格低”更重要。

应对：

做法	效果
年度价格锁定（合同期内不涨价）	高（符合采购流程）
用量上限保护（超过上限需另行审批，不自动扣费）	高（避免账单失控）
价格调整提前 90 天通知	中（给客户留预算调整时间）
老客户价格保护	高（避免”新人便宜老人贵”的反弹）

最后一条特别重要：涨价时给老客户豁免期（如”老客户 12 个月内按原价”）。这不是慈善，是避免口碑崩塌——AI 服务的客户获取成本很高，流失一个老客户的代价远超短期涨价收益。

6.5 坑五：定价与产品的耦合——定价会塑造产品

这是最容易被忽视的：你按什么收费，产品就会朝那个方向优化。

计价单位	产品会优化什么	副作用
按 token	输出更短、更简洁	可能牺牲完整性（该解释的不解释）
按请求次数	一次请求做更多事（合并）	响应变慢、单次失败率上升
按席位	鼓励更多人使用	资源消耗不受控
按结果	优化”可被计量的结果”	忽视不可计量的价值（如用户满意度）
按时间（订阅）	提高留存	不关心用量效率

举例说明：如果按 token 计费，模型会倾向于输出简短答案（因为客户会抱怨”这么点内容扣这么多”）；如果按请求计费，模型会倾向于”一次给全部信息”（哪怕冗长）。

这意味着：定价决策同时是产品决策。 在定计价单位时，要问：”这个单位会让我们优化什么？那个优化方向是我们想要的吗？”

6.6 补充：一个”法律与合规”的坑

问题	说明
价格歧视的边界	同产品对不同客户不同价，在 B2B 通常合法（量大优惠），但要避免”无正当理由的差别待遇”
自动续费	多地有强制规定（提前提醒、便捷取消）
用量计量的争议	合同里要定义”计量口径”（tokenizer 版本变化会影响计数）
SLA 与赔偿	承诺可用性就要定义赔偿（通常是服务抵扣，不是现金）
数据用于训练	如果合同允许用客户数据训练，”免费额度换数据”要显式约定

最后一条在 AI 服务里特别常见（”免费版”换数据），必须显式写清，否则一旦客户发现会引发严重信任危机。

7. 场景选型：三类典型场景的定价骨架

7.1 场景一：大模型 API 服务（MaaS）

特征：客户是开发者、用量波动大、竞品多、价格透明、切换成本低。

要素	建议
计价单位	input token / output token 分开计（比值 3–5×），加缓存命中折扣
价格结构	按量为主 + 承诺用量折扣（两部制）
QoS 分层	标准 / 优先（用队列优先级实现，不用价格波动）
免费层	有（获取开发者），但严格限速（限速比限量更能筛出真实用户）
长上下文	分段计价或附加费（反映 KV cache 成本）
定价逻辑	竞争导向为主（市场透明），成本导向做下限

关键设计：

基础表：
  输入 $A / 百万 token（缓存命中 $0.1A）
  输出 $3.5A / 百万 token
  > 32K 上下文：该请求 2× 计费

企业档：
  年承诺 $X → 单价 0.7×，含 SLA 99.9% + 优先队列

为什么”缓存命中折扣”是必须的：不做折扣，等于对”重复的 system prompt”重复收费，客户会觉得被坑；做了折扣，客户会主动优化 prompt 结构（对你也是好事——降低你的 KV cache 压力）。

7.2 场景二：推理云服务（GPU 即服务）

特征：客户是 AI 公司、需求可预测性中等、资源同质、竞争基于价格+可用性。

要素	建议
计价单位	GPU 小时（按卡型分档）
价格结构	两部制是主流：按需（高价、随时停）+ 预留（低价、长约）+ 抢占（最低价、可被回收）
QoS 分层	本质就是”可用性分层”：抢占式 < 按需 < 预留
动态定价	抢占式实例可以做（客户接受”可能被回收”隐含的价格波动）
定价逻辑	成本导向为主（资源同质，价值差异小）

这是五种范式里”拍卖/动态定价”唯一真正适用的场景，因为它满足第 3.6 节的三条：资源同质、价值异质（训练 vs 推理对价格敏感度不同）、需求可延迟（训练任务可以等）。

关键指标：利用率。推理云的毛利几乎完全由利用率决定（见 2.1）。

1 2	毛利 = 1 − (实际成本 / 收入) = 1 − (C_gpu_hour × 卡数 × 8760) / (单价 × 售出卡小时)

如果利用率 60%，单价必须 ≈ 成本 / 0.6 / (1−目标毛利)。 这就是为什么推理云的单价看起来”比自建贵不少”——差价里很大一部分是闲置成本。

7.3 场景三：企业 SaaS（AI 应用层）

特征：客户是企业、需求相对稳定、价值可度量（业务指标）、切换成本高、销售驱动。

要素	建议
计价单位	席位 + 用量混合（席位覆盖基础价值，用量覆盖边际成本）
价格结构	订阅（含额度）+ 超额按量；年付折扣
QoS 分层	按套餐分（功能 + 额度 + 支持等级）
定价逻辑	价值导向为主（用替代成本定锚）
结果分成	可选，但只用于”能明确定义结果”的场景

为什么企业 SaaS 不适合纯按量：

企业要可预测预算（见 6.4）；
企业采购流程**不接受”用量不确定”**的合同；
纯按量会让客户用得保守（不敢试），反而抑制价值实现。

推荐的混合结构：

基础订阅：$X/月，含 N 个席位 + M 次 AI 调用
  超出席位：$Y/席位/月
  超出调用：$Z/千次（阶梯递减）
  年付：8.5 折

这个结构的好处：

部分	作用
席位费	覆盖固定成本、可预测、符合企业采购习惯
含额度	让客户敢用（”已经付了”）
超额按量	覆盖重度用户的边际成本，防止逆向选择

7.4 三类场景对照

维度	MaaS（API）	推理云	企业 SaaS
主要计价单位	token	GPU 小时	席位 + 调用
主导定价逻辑	竞争	成本	价值
价格透明度	极高	高	低（一客一价）
动态定价可行性	低	高（抢占式）	极低
主要风险	价格战	利用率	逆向选择 + 预算流程
最关键的动作	计量透明度	容量规划	套餐设计

8. 小结

定价要分三层看：计价单位（L1）、价格结构（L2）、分配机制（L3）。AI 服务的难点在 L3，但大多数讨论停在 L1。
L3 决定 L1 的成本基数。 如果你的集群利用率只有 30%，按 token 分摊成本算出的单价会高得离谱——这不是定价问题，是利用率问题。
成本导向在 AI 服务上只能当”下限”，不能当”公式”。 因为单位成本是利用率的函数（同一批卡，吞吐可差 3–5 倍），且成本导向在产能受限时不提供分配机制。
容量约束下，边际成本 = 影子价格。 利用率低时 ≈ 0，利用率高时 = 被挤掉请求的价值。这是”动态定价”的严格理论依据，也是为什么”高峰期拿不到卡”是价格失灵的表现。
运维指标就是影子价格的观测量。 队列长度、显存占用、拒绝率——当它们上升，说明价格相对稀缺度偏低。你不需要解 LP，只需要监控这些指标。
output token 比 input 贵 3–5 倍不是营销，是物理。 Prefill 是计算密集（可批处理），Decode 是访存密集（串行）。定成 1:1 就是补贴长文生成客户。
长上下文有隐性成本，且被严重低估。 32K 上下文占用的显存相当于几十个 1K 请求，但按 token 统一计价只付 32 倍的钱。分段计价/prompt caching 折扣不是让利，是纠正分摊。
QoS 分层是价格歧视最优雅的实现。 客户买的是”更快的”，不是”更贵的”，且技术上真实存在成本差异。这比直接涨价好得多。
动态定价在 AI API 上应实现为”优先级 + 配额”，而不是”价格波动”。 因为需求刚性、公平性感知差、客户无法做预算。对外固定价格表，对内用影子价格调度——经济学上等价，客户感知完全不同。
两部制（固定费 + 用量）被严重低估。 它同时解决三个问题：覆盖高固定成本、让边际定价回归效率、让客户自选择。云厂商的”按需 vs 预留”就是这个。
拍卖只适用于资源同质、价值异质、需求可延迟的场景（抢占式 GPU、批量任务）。在线 API 的每次调用不适合拍卖。
成本测算最容易错在”用理论峰值吞吐”而非”生产实测”。 加上有效利用率（常只有 40–70%）、重试成本、KV cache 占位后，真实成本可能是”简单估算”的 2–3 倍。
一定要做敏感性分析。 “利用率 60% 时毛利 50%”和”利用率 40% 时毛利为负”是同一套价格 ——这个信息比”定价多少”重要。
计费越透明，客户用得越多。 不透明不保护毛利，只会抑制使用、降低续约。
定价会塑造产品。 按 token 收费会让产品优化”简洁”，按请求收费会让产品优化”一次给全”。定计价单位时，要问”这会让我们优化什么”。
对企业客户，”价格稳定”比”价格低”更重要。 因为预算流程和采购审批。年度锁价、用量上限保护、涨价提前通知、老客户豁免——这四条能避免大部分客户关系事故。
涨价别用涨价，用”加量”。 成本温和下降时，”价格不变但配额提升”最稳；只有成本腰斩时才必须降价。

如果只留一句：AI 服务的定价，是把”容量稀缺的影子价格”翻译成客户能接受的形式——翻译得好是”优先级套餐”，翻译得差是”动态涨价”，不翻译就是”排队和拿不到卡”。

参考来源

定价与收益管理理论

Pigou, The Economics of Welfare, 1920（价格歧视的三种类型）
Varian, Price Discrimination, Handbook of Industrial Organization, 1989
Shapiro & Varian, Information Rules: A Strategic Guide to the Network Economy, 1999（版本划分 versioning、捆绑、锁定）
Phillips, Pricing and Revenue Optimization, 2005（收益管理教科书：Littlewood 规则、EMSR、容量分配）
Talluri & van Ryzin, The Theory and Practice of Revenue Management, 2004
Wilson, Nonlinear Pricing, 1993（两部制、数量折扣的理论基础）
Mendelson & Whang, Optimal Incentive-Compatible Priority Pricing for the M/M/1 Queue, Operations Research 1990（优先级定价的经典）
Naor, The Regulation of Queue Size by Levying Tolls, Econometrica 1969（拥塞定价的起点）
Maskin & Riley, Monopoly with Incomplete Information, RAND 1984（机制设计与菜单设计）
Myerson, Optimal Auction Design, Mathematics of Operations Research 1981
Kahneman, Knetsch, Thaler, Fairness as a Constraint on Profit Seeking, AER 1986（涨价的不公平感知，解释了为什么动态定价在 to-B 场景受阻）

云与 AI 服务定价

Xu & Li, A Survey of Revenue Management for Cloud Computing, 2013
Mihailescu & Teo, Dynamic Resource Pricing on Federated Clouds, 2010
Ben-Yehuda et al., Deconstructing Amazon EC2 Spot Instance Pricing, 2013（Spot 市场的实证：价格与中断率的真实行为）
Abhishek, Kash, Key, Fixed and Market Pricing for Cloud Services, 2012（固定价 vs 市场价的比较，与本文 3.5 的结论一致）
Karp, Pricing in the Cloud: Spot Instances and Beyond, 2023 相关实践总结（厂商视角，非同行评议）
各厂商公开定价页与用量计费文档（具体单价请自行核实，本文刻意不引用具体价格数字）

推理成本与系统

Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention（vLLM）, SOSP 2023（KV cache 管理与吞吐的关系）
Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI 2022（continuous batching，解释 prefill/decode 的成本结构差异）
Agrawal et al., Sarathi: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills, 2023（chunked prefill，长上下文对吞吐的影响）
Zhong et al., Distserve: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving, ICLR 2024（prefill/decode 分离，是本文 2.3 与 5.3 的技术依据）
Anthropic / OpenAI 关于 prompt caching 的工程说明（缓存定价的技术背景）

说明：文中所有金额、倍数（如 output/input 的 3–5 倍、有效利用率 40–70%、C_gpu_hour ≈ 10 元）均为量级示意与经验区间，随模型规模、硬件型号、批处理策略、地区电价、采购方式差异极大，不构成对任何厂商实际定价的陈述。用于实际决策前，请按 5.2 的公式在自有环境实测。本文刻意不引用具体厂商的单位价格，因为该数据月度变化且易误导。