给业务线发 token 额度：三种配额模式的坑和适用边界

LLM 网关计费系列的第三篇。前两篇讲了漏记和对账，今天讲治理：当公司内部多条业务线共用大模型资源，怎么发额度。这事的方案看着都差不多，坑全在细节里——三种主流模式逐一过。

模式一：月度固定配额（最常见，坑最多）

每月给每条业务线一个固定 token 数，用完停或申请追加。

坑：业务波动让固定额度两头挨骂——忙月不够用（加急审批流程比宕机还慢）、闲月全浪费（月底突击烧 token 的「配额焦虑式消费」是真实存在的组织行为学现象）。

适用：用量稳定的基础服务。波动型业务慎用，或至少配「按周滚动」而不是按月一刀切。

模式二：预算制（配额换成钱）

不限制 token 数，限制金额：每条业务线每月 X 元等值的模型消耗。

坑：token 单价变动（上游调价、缓存折扣、分时价）会让同等业务量的「花费」漂移——业务方什么都没多做，预算却提前烧完，来问你的第一个人一定是财务口径的质疑。预算制必须配「单价锁定」或「消耗指数化」（按调用次数/处理文档数等业务单位折算），否则沟通成本巨大。

适用：管理层更关心钱而非用量的组织——但记得把折算规则写进文档。

模式三：令牌桶（实时流控式）

不设周期上限，设速率：每秒/每分钟最多 N token，超了排队或降级。

坑：它是稳定性工具不是成本工具——限得住突刺，限不住总量。只上令牌桶的团队，月底账单照样爆炸，只是爆炸得很平稳。另一个细节：突发桶的容量要按「最大单请求」留（长文档一次 10 万 token），否则合法大请求被误杀。

适用：保护共享资源不被单业务打挂，必须和前两种之一组合使用。

组合拳（我们的落地方案）

三层各管一件事：令牌桶管稳定（速率）→ 月度配额管总量（预算折算成业务单位）→ 超额看板管沟通（哪个业务快超了，提前 3 天提醒而不是当天断粮）。治理工具的本质不是「卡住」，是让用量可见、可预期、可商量——卡得越死，旁路（业务自己偷偷直连 API）越多，那才是治理的真崩盘。