AI SaaS 定价：用量账本、单位经济与迁移

核心摘要

AI SaaS 定价不是价格页设计，而是一套计量和风险分配系统。可靠方案必须分开：

1. 价值指标：客户认为自己获得了什么。
2. 计费指标：账单计算使用的确定性单位。
3. 成本指标：产品实际消耗的资源。
4. 权益：套餐在请求前、执行中和执行后允许什么。

Token 可以是成本指标，但不必成为价值指标或计费指标。订阅可以让访问权可预测，却无法自动消除无限可变成本。长期可用的底座，是只追加的用量账本、明确的结算语义，以及按 Cohort 和长尾而不是“平均用户”衡量的单位经济。

核心要点

• 先定义客户价值，再设计可结算单位。 不能只因为供应商内部指标容易采集，就直接把它暴露给客户。
• 尝试记录与用户扣费必须分开。 重试、超时、退款和 Credit 都需要独立会计事件。
• 依据分布定价。 平均成本会掩盖 P95/P99 工作流、重度用户集中度和负毛利 Cohort。
• 把 Price Book 当成版本化生产配置。 模型费率或套餐变化不能静默改写客户经济。
• 混合套餐只是常见模式，不是标准答案。 只有当套餐内用量能降低购买摩擦，超量计费能约束长尾风险时，它才成立。

不能混为一谈的四类指标

价值指标

价值指标应映射客户能够理解的结果，并随感知收益增长。Stripe 关于 AI 产品定价的研究也指出，AI 成本与客户价值并非同步变化，因此团队正在订阅、用量和结果指标之间持续试验。

常见例子：

• 已解决的客服工单；
• 转写分钟数；
• 已审阅文档；
• 成功完成的编码任务；
• 活跃席位及其自动化额度。

结果并不自动等于可计费单位。“成功任务”必须有稳定定义、争议流程，而且不能由产品在事后单方面宣布成功。

计费指标

计费指标必须满足：

• 在明确边界上可观测；
• 重试和重放后仍确定；
• 能在账单上解释；
• 足够稳定，便于客户预测；
• 定义变化时有新版本。

“一次 AI 请求”通常过于模糊。失败请求是否计费？工具调用、重新生成、部分流式输出、供应商重试如何处理？这些问题应在上线前写进结算状态机。

成本指标

内部成本遥测可以比用户计费更细：

• 模型快照与输入/输出 Token；
• Cache 命中与未命中 Token；
• 图片、音频和视频单位；
• 搜索、浏览器、数据库和代码执行调用；
• 专用加速器或 Sandbox 时间；
• 第三方数据增强；
• 可直接归属的存储和交付。

同时保留请求时估算成本和供应商账单对账成本。两者用途不同，也会因四舍五入、折扣、Batch Rate、失败调用和延迟调整而不一致。

用工作负载证据选择定价形态

不要只看竞品价格页就选模型。应使用自己的工作负载分布、销售方式、客户对账单波动的接受度和合同义务。

用量账本才是计费事实源

分析事件不是计费账本。分析系统常会抽样、聚合、延迟到达，甚至重新解释 Schema；计费需要不可变身份、只追加记录和显式修正。

必要事件标识

每个可计费操作至少需要：

event_id                 全局唯一账本事件
operation_id             跨重试稳定的业务操作
tenant_id                账单归属方
feature_id               产品能力
meter_id + meter_version 计费单位定义
price_book_version       生效的价格规则
occurred_at              产品事件时间
received_at              账本接收时间
quantity                 最小单位整数
cost_estimate_micros     内部估算，不是账单金额
source_attempt_id        供应商或工具尝试
event_type               usage、adjustment、refund、void
related_event_id         关联原事件

金额和数量都应用整数表示。浮点运算无法保证账单可复算。

追加修正，不改写历史

如果某条用量事件错误：

1. 追加冲销或调整事件；
2. 关联原事件；
3. 记录原因和操作方；
4. 重新计算受影响账单；
5. 保留新旧事件供审计。

这与会计中的不可变事件日志一致，也让价格迁移和客户争议可解释。

Go 示例：幂等用量结算

下面的标准库示例按 operation_id 去重，独立记录供应商每次尝试，并只追加一次用户结算。真实服务必须在数据库事务中强制唯一约束。

package main

import (
	"errors"
	"fmt"
	"sync"
	"time"
)

type Attempt struct {
	ID         string
	Operation  string
	Provider   string
	Model      string
	CostMicros int64
	Succeeded  bool
	OccurredAt time.Time
}

type LedgerEvent struct {
	ID           string
	Operation    string
	Tenant       string
	Meter        string
	MeterVersion int
	PriceBook    string
	Quantity     int64
	Type         string
	RelatedEvent string
	Reason       string
	OccurredAt   time.Time
}

type Ledger struct {
	mu       sync.Mutex
	settled  map[string]string
	attempts []Attempt
	events   []LedgerEvent
}

func NewLedger() *Ledger {
	return &Ledger{settled: make(map[string]string)}
}

func (l *Ledger) RecordAttempt(attempt Attempt) {
	l.mu.Lock()
	defer l.mu.Unlock()
	l.attempts = append(l.attempts, attempt)
}

func (l *Ledger) Settle(event LedgerEvent) error {
	l.mu.Lock()
	defer l.mu.Unlock()
	if event.Operation == "" || event.Quantity <= 0 {
		return errors.New("invalid settlement")
	}
	if existing, ok := l.settled[event.Operation]; ok {
		return fmt.Errorf("operation already settled by %s", existing)
	}
	event.Type = "usage"
	l.events = append(l.events, event)
	l.settled[event.Operation] = event.ID
	return nil
}

func (l *Ledger) Adjust(event LedgerEvent) error {
	l.mu.Lock()
	defer l.mu.Unlock()
	if event.RelatedEvent == "" || event.Quantity == 0 {
		return errors.New("adjustment requires a related event and non-zero quantity")
	}
	event.Type = "adjustment"
	l.events = append(l.events, event)
	return nil
}

func main() {
	ledger := NewLedger()
	now := time.Now().UTC()
	ledger.RecordAttempt(Attempt{
		ID: "attempt-1", Operation: "op-42", Provider: "provider-a",
		Model: "snapshot-7", CostMicros: 18420, Succeeded: true, OccurredAt: now,
	})
	err := ledger.Settle(LedgerEvent{
		ID: "usage-1", Operation: "op-42", Tenant: "tenant-9",
		Meter: "completed_document", MeterVersion: 2,
		PriceBook: "global-2026-10", Quantity: 1, OccurredAt: now,
	})
	fmt.Println(err == nil)
}

这可以防止用户被重复扣费，但不会抹掉重试成本。所有 Attempt 仍可用于内部成本分析。

明确定义结算状态机

Agent 或多模态工作流可能执行数分钟，并扇出多个供应商调用。必须定义权益和金额在哪个阶段变化：

accepted -> reserved -> executing -> succeeded -> settled
                       -> failed ----> released
settled -> adjusted/refunded

产品契约必须回答：

• 执行前是否预占额度？
• 估算成本高于剩余额度时如何处理？
• 部分输出是否计费？
• 用户主动重新生成是否构成新价值？
• 供应商重试或产品 Bug 由谁承担？
• 客户能否争议“任务成功”？
• Credit 何时过期？
• 赠送 Credit 与购买 Credit 的消耗顺序是否明确？

同一策略必须在 UI、API、Worker、客服工具和账单生成器中一致执行。

不被平均用户误导的单位经济

某个 Cohort 和周期内：

贡献毛利
= 已确认收入
- 模型与工具成本
- 可直接归属的计算和交付成本
- 与用量相关的支持或人工复核成本
- Credit 与退款

具体会计归类会因公司和司法辖区而异，最终毛利定义应与财务统一。但工程仍需要用于路由与套餐设计的运营贡献视图。

最小分析维度

• 功能和工作流版本；
• 租户与套餐；
• 注册与续费 Cohort；
• 地区与币种；
• 模型路由；
• 用户计费单位；
• 单操作成本 P50、P90、P95、P99；
• 头部用量分位的成本集中度；
• 重试、失败、退款和补偿率；
• 扣除促销用量后的毛利；
• 估算成本与对账成本偏差。

FinOps Framework 的 Unit Economics 能力强调，要用有意义的单位指标把技术成本连接到业务价值。对 AI 产品而言，关键是“每个成功业务结果的成本”，而不只是“每百万 Token 成本”。

长尾与 Cohort 问题

设定额度前，需要回答：

• 最重度租户贡献了套餐成本的多少比例？
• 高用量与留存、扩张相关，还是与滥用相关？
• 哪些工作流存在长输出或工具调用长尾？
• 新模型是否降低均值却提高重试率？
• 年付老客户是否在补贴新上线的昂贵功能？
• 供应商折扣到期后，毛利如何变化？

不能仅因为用户活跃且有价值就限制其使用。应先判断价格、路由或工作流是否与交付价值错位。

套餐与权益

一个套餐应分别回答：

“公平使用”不能替代未定义限制。任何能够中断服务或改变账单的约束，都应可计量、可见且可解释。

安全迁移 Price Book

价格变化是一种具有用户财务影响的数据迁移。

生效前

1. 创建新的不可变 price_book_version。
2. 用新旧规则重放历史用量。
3. 在实时事件上同时影子计算两套价格。
4. 按 Cohort、套餐和长尾租户检查账单差异。
5. 明确合同、老用户、税务和币种规则。
6. 公布生效日期与客户解释。
7. 准备补偿、回滚和争议流程。

迁移中

• 购买前明确展示准确版本；
• 每次结算绑定该版本；
• 展示剩余额度与预计超量；
• 除非明确设计，否则不在一张账单混用版本；
• 对异常差异和对账漂移告警。

迁移后

• 比较预测与实际用量、收入；
• 检查流失、降级、客服和争议信号；
• 对账供应商账单；
• 保留旧账单和原账本事件；
• 后续变更创建新版本，绝不修改历史。

发布检查清单

1. 客户无需理解供应商 Tokenization 就能说清价值单位。
2. 计费指标只有一个版本化定义。
3. 重复投递和重试测试不会重复扣费。
4. 失败、取消和部分完成有明确结算规则。
5. 成本估算与供应商账单在可调查容差内一致。
6. P95/P99 与租户成本集中度可见。
7. 每个账单行都能追溯到不可变账本事件。
8. 支出上限、告警和硬停止行为已测试。
9. 税务、币种、Credit 过期和退款规则已评审。
10. 价格迁移可以影子运行、解释和回滚。

常见问题

AI 产品是否应该展示 Token？

当买家是技术用户且 Token 有助于预测时可以展示；否则应向用户展示结果单位，同时内部保留 Token 遥测。如果 Token 会影响账单，就不能隐藏换算规则。

Credit 是货币吗？

即使它不是法定货币，也表现为合同余额。必须定义购买价值、有效期、退款、转让、消耗顺序，以及换算率变化后的处理，并接受财务和法律评审。

供应商重试应消耗用户 Credit 吗？

通常，为完成同一个承诺操作而发生的重试应由产品承担。内部要记录成本，用户用量则按公开的业务操作契约结算。

合理毛利目标是多少？

不存在通用目标。它取决于销售方式、支持成本、基础设施、增长阶段和会计政策。应使用当前 Cohort 证据和经过批准的财务定义，而不是复制行业数字。

应多久调整一次价格？

内部路由和成本控制可以频繁变化；面向客户的 Price Book 应谨慎变化，并具备版本、通知、合同处理和账单差异测试。

一手资料

• Stripe，Pricing AI Products: Lessons from Leading AI Companies：AI 定价形态，以及客户价值与可变 AI 成本的分离。
• FinOps Foundation，Unit Economics：使用单位指标连接技术成本与业务价值。
• FinOps Foundation，FinOps Terminology：成本分摊和单位经济的通用术语。
• AI 产品隐私工程：用量遥测的数据目的、保留和删除要求。

关联学习路径

• LLM Gateway 架构：路由级用量、成本与模型策略。
• AI 应用国际化：币种、市场、税务和产品可用性边界。
• Token：不能与客户价值混为一谈的模型侧计算单位。
• 大语言模型：可变推理成本背后的模型服务概念。

总结

可持续的 AI 定价，来自客户能够预测的契约，以及工程和财务能够复算的内部账本。应分离价值、计费、成本和权益；围绕同一个业务操作只结算一次；保留每次尝试和修正；并依据 Cohort 与长尾证据设计价格。

价格页只是可见输出，真正的产品是其下方的计量、结算、对账与迁移系统。