模型很会聊天，账单也会——上线前要把「每次成功任务」的成本写进产品规格
试点阶段「随便调大模型」几乎没人管账单；一旦把助手、摘要或 RAG 写进客户付费产品，token 就变成毛利的一部分。可上线在上海交付 AI 方案时，成本控制不是上线后的运维彩蛋，而是探索阶段就要定的产品约束：谁触发调用、成功一次任务允许多少钱、超额时产品怎么降级而不是静默烧钱。Weaverine 一类 B2B 工作流若每天自动处理文档与询价辅助，没有单位经济模型，季度账单会比功能列表更吓人。本文面向代理与甲方产研，讲清客户产品语境下的 LLM 成本结构、可落地的工程手段、与业务对齐的配额设计，以及如何在 discover→design→build→launch 各阶段把「可预测成本」当成验收项，而不是等财务来敲门。
先定「成功任务」单价，再选模型
客户产品里的成本单位不该是「一次 API 调用」，而应是业务可理解的成功任务：一次工单摘要通过审核、一次带引用的知识问答、一次符合 schema 的表单抽取。探索工作坊里把任务定义清楚，再估算：平均输入/输出 token、重试率、检索片段长度、工具调用次数。用「目标成本 / 次成功」反推允许的模型档位与上下文窗口。若业务愿意为决策辅助付 0.5–2 元/次，却用最贵多模态模型做分类，规格本身就错了。把这个单价写进 PRD 与 SOW，比事后争论「AI 怎么这么贵」有效一百倍。
账单从哪来：生成、嵌入、重试与隐藏乘数
可见的生成 token 只是一部分。嵌入更新、长上下文重复塞入系统提示、失败自动重试、流式中断后的二次请求、日志里完整回放做「质量抽检」——都会乘在真实成本上。代理交付时默认要求：按 feature flag 与租户打标签计量；区分「用户可见请求」与「后台批处理」；把 P50/P95 token 与费用写进看板，而不是只看调用次数。客户产品还要注意多租户串账：一个大客户疯狂试用不应拖垮共享预算池。没有标签，你无法解释账单，也无法做限流。
路由：小模型做分流，大模型做合成
多数客户产品请求不需要旗舰模型。典型分层：规则/小模型负责意图分类、安全拒答、语言检测；中等模型做草稿与结构化抽取；仅在高价值或低置信路径上升级。RAG 场景先检索，材料不足则拒答或转人工，避免「空检索仍烧长生成」。可上线在 build 阶段把路由表做成配置而不是散落 if-else，便于换价或换供应商时不改业务代码。路由策略要进评测集：确认省钱路径没有悄悄降低红线任务的忠实度。
上下文与缓存：少传重复字，多传有用字
系统提示与工具说明若每次完整上传，成本随 QPS 线性放大。优先：提示词压缩与版本化；对稳定前缀使用供应商 prompt cache；会话内只追加增量消息；检索 top-k 设硬上限并去重。客户文档场景避免把整份 PDF 当上下文，改为切片 + 引用。输出侧限制 max tokens，并在 UI 提供「继续生成」而不是默认超长。设计阶段就要定默认长度预期——体验上「够用且可展开」往往比「一次写完报告」更省且更可信。
产品层配额：让业务规则驱动限流
纯技术限流（QPS）保护的是系统，不是毛利。客户产品应映射套餐：每日任务数、每座席费用池、按工作区预算告警。超额时的体验要设计：排队、降级到模板/关键词搜索、只读历史、或引导升级套餐——禁止静默失败或无限透支。B2B 合同里写清「含多少 AI 额度、超出如何计费」，比在发票上出现一长串模型名称更好解释。探索阶段让销售与客户成功一起签字额度假设，避免交付后扯皮。
可观测性：每次调用都要能复盘
成本优化没有日志就是玄学。最小字段：租户、功能、模型、输入/输出 token、延迟、缓存命中、路由决策、是否重试、业务结果（成功/拒答/错误）。抽样保留提示与响应以便审计，但遵守隐私约定（脱敏、保留期、禁止默认用于再训练）。周报复盘：高成本功能、高失败重试对、异常租户。可上线把「成本回归」放进发版检查：改提示词或检索深度时，评测集外再跑成本基线，防止质量微升、账单翻倍。
供应商与合同：可替换比「最便宜」更重要
单一供应商锁死价格与额度风险。适配层统一：消息格式、重试、超时、流式与计费字段映射。评估时看：数据驻留、训练政策、SLA、缓存能力、中国/海外路由是否符合客户合规。价格表每季变，产品逻辑不应绑死某一 SDK。对甲方解释时，用「任务单价区间 + 降级策略」而不是模型营销名。若客户要求私有化，把硬件与运维人力计入 TCO，别只比 API 标价。
按阶段嵌入成本门禁，而不是上线后补课
discover：冻结任务单价、套餐额度假设、不可接受的成本尖刺场景。design：默认上下文长度、降级 UI、用量提示。build：路由、缓存、计量标签、评测含成本断言。launch：生产看板、告警阈值、一周成本复盘会。之后若进入 retainer，月度只优化高 ROI 杠杆（缓存命中、检索过宽、重试风暴），而不是无休调模型。需要可上线一起把 AI 写进真实产品时，把成本控制与功能范围同一张表管理——否则你交付的是演示温度，客户收到的是生产账单。
可执行清单
- 1用业务「成功任务」定义目标成本，并写入 PRD/SOW
- 2实现按租户与功能的 token/费用计量，以及缓存与路由配置化
- 3设计超额降级体验与套餐额度，禁止静默透支
- 4发版时同时跑质量评测与成本基线，防止账单回归
- 5供应商适配层 + 数据驻留/训练政策书面确认
核心要点
- 客户产品里的 LLM 成本控制，核心是「每次成功任务」的单位经济，而不是单次 API 单价表。
- 路由、缓存、上下文上限与产品配额，比盲目换更便宜的模型更能稳定毛利。
- 没有分标签计量与发版成本门禁，优化只能靠感觉，客户账单也无法解释。
常见问题
- 演示阶段要不要就做完整成本体系？
- 演示可以简化，但必须记录预估任务单价与调用量假设。进入客户预发或付费试点前，计量标签、路由与超额策略应就绪，否则试点成功会变成财务事故。
- 缓存会不会影响答案新鲜度？
- 会，所以要分层：稳定系统提示可长缓存；检索结果短 TTL 或按文档版本失效；用户个性化上下文不跨用户缓存。用版本号与业务事件触发失效，而不是二选一关掉缓存。
- 如何向非技术客户解释模型费用？
- 用「每完成一次 XX 任务大约多少钱、套餐含多少次、超出如何计费/降级」，配一周真实用量样例。避免只甩 token 单价；他们买的是任务结果，不是 token。