把成本表建起来

我自己的表会按「一次请求」和「一个付费用户」两层记。一次请求看技术细节，一个付费用户看生意是否成立。只看总 token 很容易被骗：一个重度用户可能吃掉 20 个轻度用户的毛利。

字段为什么要记
user_id / plan看不同套餐是否亏钱
model找出高价模型滥用
input / output token输出通常更贵
cache read / write判断缓存是否真省钱
retry count失败重试会偷成本
latency降本不能把体验打烂

表不用一开始就完美，把日志落到 Postgres 或 ClickHouse，每晚汇总到 spreadsheet。独立开发者最怕的是账单来了才知道某个功能一直在烧钱。

prompt cache 怎么用？

prompt cache 适合固定长上下文：system prompt、工具说明、品牌语气、长文档摘要前缀。把这些内容放在请求前半段，保持顺序稳定，后面再拼用户输入。频繁变化的字段不要塞进缓存块，否则命中率会很难看。

我会给缓存设三条规则：一是缓存块超过一定长度才启用；二是缓存命中率低于 30% 就回滚；三是缓存写入成本单独记。缓存不是免费魔法，它只是把重复输入变便宜。

batch、路由、模型分层怎么排？

任务推荐策略原因
用户即时对话streaming + 中档模型体验优先
夜间报表Batch API便宜，不急
分类和标签小模型容错高
复杂代码或推理高档模型错一次更贵
失败重试换模型或降温度别原样烧第二遍

模型分层不要写死在前端。放到服务端路由层，用任务类型、用户套餐、预算和失败次数决定。这样你以后换供应商，只改一层。

毛利 spreadsheet 怎么算？

每个套餐至少算这几列：月收入、支付手续费、平均 API 成本、服务器成本、退款率、客服时间。比如 $19/月套餐，如果 API 成本已经到 $8，再扣 Stripe 手续费和服务器，剩下的钱不够你买流量。

我会给每个功能设成本上限：一次长文生成最多花多少，一次代码分析最多花多少，一个用户每天最多跑几次高档模型。超过就提示排队、降级或让用户升级套餐。

接入层怎么留后路？

早期可以先接一家多模型统一计费的 API 中转，快速拿到 Claude、OpenAI 和其他模型的统一账单。等月用量上来，再把官方 key、备用网关和自建统计接进去。重点是业务代码只调用你自己的 llmRouter()，不要到处散落供应商 SDK。

关联文章