Token 摆上货架：套餐化零售要重算的计量、退订与对账
一、货架化改变的不是价格，是计费系统要同时对三方负责
据公开报道，有大模型厂商在电商平台上开了品牌官方旗舰店，把 Token 订阅套餐当成标准商品来卖。销量、价格带和平台怎么分成，我们一概不知道，这些也不影响下面的判断。
值得单独拎出来的是结构变化。直销时，计费系统只对一类对象负责：签约客户，口径谈妥、账单发过去、有争议翻日志。商品上了货架，责任对象一下变成三方——渠道（成交、券、退款、发票都要跟它对账）、用户（没签过合同，只看过商品详情页，就默认你的口径和他理解的一致）、内部财务（收入确认的时点和金额要能从订单推到用量）。算力这种商品还有一层特殊之处：交付在卖出之后才发生，而且消耗速度由买家决定。于是争议的来源不再只是”用量对不对”，更多是”卖的到底是什么、卖出去的东西有没有按时开通、退的时候怎么折算”。这三件事分别对应计量口径、异步开通补偿和退订设计，缺一个都会被零售的规模放大。
二、计量口径要在购买前可见，而且与后端同源
详情页写一套、计费引擎跑另一套，是所有口径争议的根因。正确做法是单一口径定义：一份配置同时生成商品页文案、后端计费规则和账单说明，谁也不许手写第二份。
| 口径项 | 必须写清的内容 | 后端对应的配置字段 |
|---|---|---|
| 输入与输出 | 是否分别计价、系统提示与历史上下文算不算输入 | 输入单价、输出单价、上下文计入规则 |
| 缓存 | 命中与写入分别怎么计、TTL 多久、谁付写入的钱 | 缓存读价、缓存写价、过期策略 |
| 多模态 | 图像与音频按帧、按时长还是折算成 Token，折算表在哪 | 折算规则版本、单位换算表 |
| 工具调用与检索 | 是否另计、按次数还是按实际消耗 | 附加计项开关与计价方式 |
| 交付等级 | 批量、优先、实时三档的差别与排队承诺 | 队列类别、并发与速率限额 |
| 超额行为 | 停止服务、转按量、还是降优先级，三选一写死 | 超阈值动作、按量价目 |
| 口径版本 | 这套规则从哪个版本开始生效、改过几次 | 规则版本号，写入每条计量流水 |
最后一行是关键：口径版本号要落到每一条计量流水上，而不只写在页面里。口径改过一次而账单没标版本，用户就没法核对，客服也没法解释。至于”多模态到底折成多少 Token””工具调用是不是另计”，这些不是商业机密，写不出来只会让成交变慢——零售客户没有谈判环节，页面就是他唯一的信息源。
三、超卖治理：套餐是承诺，算力是共享池
套餐一旦被大量售出，卖出去的是并发承诺，而算力是同一池子。治理要提前定，不能等容量紧张时临时决定牺牲谁。
先定限额维度：速率类限额（每分钟请求数、每分钟 Token 数）按套餐档位分池，而不是共用一个全局上限；档位差异要写在商品页上，写成”你的请求在拥挤时会被排队还是被拒”这种可验证的话，不要写”弹性扩容”。
再定降级顺序。拥挤时系统的动作顺序必须是确定的，而且付费档位之间有区分：
- 先削自由额度与试用账户的并发（这部分本来就不该被当成承诺）；
- 再把按量计费部分降到批量队列，明确告知延迟上升；
- 然后对套餐内请求排队并返回位次与预计等待；
- 最后才是拒绝，并返回可重试时间与原因码。
优先级消耗顺序同样要显式：免费额度和套餐额度并存时，先扣哪个、谁先过期，必须写在页面上。常见的两种体验断裂都来自这里——额度还剩但不能用（被速率限额卡住），以及限额明明宽松却被扣完了（多模态折算没算清）。前者要在响应里返回”当前被限的是速率而非余额”，后者要在明细里把折算过程展开，让客户能自己算一遍。
四、退订与退款要能被系统执行，而不是客服话术
零售的退款量级远超直销，规则必须能自动跑。要定死四件事：
- 折算规则：按已消耗额度、按未使用的整期，还是两者取高，说清有没有开通成本；折算公式必须在协议里能查到，且与系统实现同源。
- 已开票部分怎么处理：冲红还是换开、由谁发起、多久完成，这条流程要在退款申请页可见，否则财务和客服会在同一个工单上互相踢。
- 跨期结转：升档、降档、中途改名时，剩余额度是否顺延、顺延后按哪个口径计。
- 争议凭据：证据是计量日志，不是客服说法。日志要能导出原始明细，带时间戳、请求标识、口径版本与折算过程，让人能重算。
实现上，退款动作要冻结一个快照：申请时刻的余额、消耗流水区间、适用的口径版本、折算结果与计算步骤，一并落到退款单上。事后规则改了也不影响这张单子——没有快照的退款系统，永远在跟”当时到底按哪个规则算”纠缠。
五、渠道对账：差价、券的归属与异步开通的补偿
渠道订单系统和自己的开通系统是两套账，中间靠消息串起来，于是必然出现”渠道说卖掉了、我们这边没开出来”。这类差异不能靠人工捞，要三本账互相勾稽：
| 账 | 记录什么 | 与上一本的勾稽关系 | 异常处置 |
|---|---|---|---|
| 渠道成交账 | 平台侧订单号、成交金额、券、退款状态 | 每日拉取成交单与前一日的开通请求比对 | 缺失订单进异常池并触发补偿 |
| 开通履约账 | 账户初始化、套餐生效时间、生效失败原因 | 每笔成交必须落到一条开通记录，一对一 | 未成对的多出与缺少都要单独报表 |
| 计量消耗账 | 每个账户的流水与口径版本 | 生效期内允许为零，但要有”为何为零”的标记 | 长期零消耗进待核实清单，不自动判定为未开通 |
补偿任务要有幂等性与人工闸门：能自动重开的（纯粹消息丢失）自动重开；涉及账号已存在、权益冲突的必须转人工，并在渠道侧回写处理进度，别让买家在两个平台之间来回问。
券和差价要提前记账归属。促销价与标价之间的差额，是渠道承担还是厂商承担，落在订单上就是一个字段；平台券与厂商券必须在券模板上带出资方标识，否则月底对账时只能靠猜。这部分规则要写在上线之前，写在商品配置里，事后补记一定记不全。
六、合规交付物，以及给采购方的一句话
经由第三方渠道卖云服务，最容易含糊的是合同关系。要在页面与协议里写清：谁是服务提供方与协议主体（品牌方还是平台）、发票由谁开、开票主体与协议主体是否一致、个人信息在下单与开通之间传给了谁、用于什么。渠道方拿到手机号或账号标识来完成开通，这本身就是一次个人信息流转，服务范围与保存期限要写进相应条款，而不是藏在勾选框里。这些不是法务单方面的事：计量口径、开通动作和发票主体三者在系统里对不对得上，决定了条款能不能兑现。
站在买方一侧，洹拓给客户的一句话很短：采购模型能力时，把计量口径写进验收文档，并要求供应商提供可导出的原始计量明细。验收文档里至少包含上面那张口径表的每一行怎么理解、超额行为是哪一种、速率限额的具体值；验收动作则很简单——挑一笔真实请求，从发起到账单出现，把明细里的每个数字算回去，能对上才算通过。对不上的项目要在采购阶段解决，而不是等到第一次账单争议时才发现双方从未对齐过口径。零售化把算力的购买门槛降得很低，但计费的可解释性并没有因此变好，这是渠道化之后仍然要重算的那部分成本。