团队的大模型 API 预算怎么排？从功能清单到季度数字
团队预算和个人试用最大的区别，是你要为「还没上线的功能」和「不受控的增长」留出余量，还要能在月中就发现跑偏，而不是月底看账单才知道。
这篇给一套能直接填进表格的编制方法。单个功能的算法见大模型 API 月成本怎么算，这里讲怎么把多个功能汇总成团队预算。
第一步：按功能拆，不要按人拆
常见错误是按人头分配额度（每人每月多少）。这个口径在开发阶段还行，一旦有功能上线就完全失真——生产流量和开发者人数没有关系。
正确的拆法是按功能 / 接口列清单，每行包括：
- 功能名（客服问答、文档摘要、代码补全……）
- 状态（实验 / 灰度 / 生产）
- 单次输入输出 token（实测，不是估的）
- 日调用量（生产按真实流量，灰度按放量比例）
- 选用模型与单价
- 月成本
这张表的好处是：任何一行超支，你都能立刻定位到具体功能，而不是笼统地说「这个月 AI 花超了」。
第二步：把实验预算和生产预算分开
两者性质完全不同，混在一起会互相掩盖问题。
实验预算是固定池子，用来做选型对比、prompt 调优、效果评估。它波动大、不可预测，但有上限——给一个固定数字，用完再申请。
生产预算按流量推算，波动应该和业务量成正比。如果生产成本涨了但流量没涨，那就是出了问题（prompt 变长了、重试变多了、有人误用了旗舰模型），要查。
分开之后，你才能回答「这个月涨了三成是正常的吗」这类问题。
第三步：留三种余量
重试余量。 限流、超时、格式不合规导致的重跑都照常计费。按历史重试率加系数，没有历史数据就先给一个保守值，上线后按实测调整。
增长余量。 业务自然增长、灰度放量、季节波动。建议按季度做三档：保守 / 基准 / 乐观，向上汇报时给区间而不是单点。
变更余量。 模型升级、prompt 改版、新功能上线，都会改变用量结构。这部分不好预测，但至少要在预算里留一行，而不是等它来了再打补丁。
第四步：设置告警，而不是月底对账
预算的价值在于能提前发现偏离。最小可用的三条告警：
- 日消耗超过日均预算的某个倍数（比如 1.5 倍）时告警——抓突发。
- 单接口周消耗环比涨幅超过阈值时告警——抓慢性泄漏，比如 prompt 悄悄变长。
- 重试率超过阈值时告警——抓限流和格式问题，这两个都是纯浪费。
要能告警，前提是有埋点：每次调用记录模型、输入输出 token、是否命中缓存、是否重试、耗时、调用方。参考 API 成本监控和 API 配额规划。
第五步：定分摊口径
多团队共用一个账号时，账单怎么分是个绕不开的问题。三种常见口径：
- 按调用方标签分摊：请求里带上业务标识，按 token 数分摊。最准，但要求埋点到位。
- 按功能归属分摊：一个功能归一个团队，整条接口的成本归它。简单，适合边界清晰的组织。
- 平台统一承担，只对超额部分追责：鼓励尝试，但要有上限。适合还在推广期的团队。
没有最优解，关键是提前说清楚，别等账单出来再讨论口径。
季度评审该看哪几个数
预算不是排完就完事，每个周期要回头看。建议固定看这五个数，其余都是噪声。
一、单位业务量成本。 不是总花了多少钱，而是「每次会话 / 每份文档 / 每个用户」花了多少。总成本随业务增长是健康的，单位成本上升才是问题。这个指标能把「业务涨了」和「效率降了」区分开。
二、缓存命中率。 它直接决定实际输入均价。命中率突然下降，通常是有人往请求前缀里加了动态内容，是最常见也最容易修的一类成本泄漏。
三、重试率与失败率。 纯浪费，且往往意味着限流配置或格式约束出了问题。这个数字上升时，先查是不是并发调高了或者厂商限流政策变了。
四、输入长度分位数（P50 / P90）。 中位数上升说明 prompt 或历史在悄悄变长；P90 跨进更高计费档说明相当一部分请求在按贵档计费。
五、模型使用分布。 有多少比例的请求走了旗舰模型？这个比例经常在无人注意的情况下上升——某个开发为了解决一个个案把默认模型改了，然后忘了改回来。
三个常见的预算失真来源
一是拿开发环境的样本估生产。 开发时用的短样例和线上真实数据长度差很远，估出来的单次 token 系统性偏低。修正办法是上线后两周用真实数据重估一次，把预算做一次校准。
二是忽略了「隐性调用」。 一次用户可见的操作，背后可能有多次模型调用：意图识别一次、检索改写一次、生成一次、安全检查一次。按用户操作数估会漏掉大部分。正确做法是按实际 API 调用数统计。
三是把实验期的低消耗当常态。 灰度阶段流量小、缓存命中率高、用户行为温和，全量之后这三项都会变差。给增长余量时，别只考虑流量倍数，还要考虑这些结构性变化。
超支时先动哪一刀
按这个顺序，痛感从小到大：
- 砍实验池——先停不紧急的对比测试。
- 压输入——system prompt 瘦身、历史裁剪、检索替代整份文档。见降本十招。
- 开缓存——固定前缀交给提示缓存，命中价通常极低。
- 分流——简单任务降到轻量档模型。
- 降 max_tokens——输出更简洁，用户能感知但影响可控。
- 换模型——迁移成本最高，放最后。
前三刀通常就够了，而且用户几乎无感。
怎么向不懂技术的人解释这笔预算
预算最终要过非技术评审，几条经验可以少走弯路。
别用 token 当汇报单位。 决策层对「五亿 token」没有概念。换成他们熟悉的口径：每次客服会话多少钱、每处理一份合同多少钱、每个活跃用户每月多少钱。单位业务量成本是最容易被理解也最容易被追问的指标，提前准备好。
给区间，并说明区间是怎么来的。 「基准 X，上界 Y，差异主要来自缓存命中率和重试率」比一个精确数字更可信，也给了你后续调整的空间。
把优化路线一起给。 说明如果超预算，你会按什么顺序动刀（先砍实验池、再压输入、最后才动用户可感知的部分）。有预案的预算比只有数字的预算好通过得多。
把不确定性写明白。 厂商调价、模型下线、政策变化都不在你的控制内。提前说清楚这些是外部变量，比事后解释强。
一个可以直接用的排法
- 用月成本估算器给每个功能算基准月成本
- 汇总后 ×（1 + 重试系数）×（1 + 增长系数）
- 加上固定的实验池
- 得到基准值，再按保守 / 乐观各给一个区间
- 把告警阈值设成基准值的某个倍数
数字给区间、口径写清楚、告警设起来——预算这件事就从「月底解释」变成了「月中可控」。想比一遍各家单价，去价格对比表。