LLM 成本在上线后暴涨，是因为生产流量改变了每个请求携带的 token 数，而能控制它的密钥、上限和模型限制，仍停留在试点阶段的设置。费率表很少变动。本文先测算一次真实的上线后暴涨，再逐一说明五个控制缺口的症状、修法，以及五天内补齐的计划。
上线后 LLM 成本暴涨的测算
一个客服机器人在 claude-sonnet-4-6 上用检索增强生成（RAG）回答问题；截至 2026 年 10 月，ATP 牌价为每百万 token 输入 3 美元、输出 15 美元。它每天处理 40,000 个请求，每条回答约写出 400 个输出 token。
试点期间，平均每个请求带 2,000 个输入 token。上线后，用户把合同和整串邮件粘贴进对话，检索也为了回答更长的问题加入更多片段。平均输入增加到 9,000 token。
每月差额是 25,200 美元，账单变成 2.75 倍。模型、价格和请求数都没有变化，任何价格表都不会提醒你。唯一的信号是每个请求的平均输入 token，而只有逐次记录 token，你才看得到它。
缺口 1：共用密钥，花费没有归属
症状：用量页显示当月大部分 token 都来自同一个密钥。三个服务、一个定时任务，还有一位外包人员的 notebook 都在用它。外包人员离开时，吊销这个密钥会让生产环境当天下午就中断，所以没人动手。
上线后为何更糟：试点期流量小，共用的代价不明显。上线后任何一个调用方都可能突增，而唯一的手段是给所有人关掉这个密钥。
修法：以项目作为归属单位，每个生产系统一个项目、一个自己的密钥。密钥只属于一个项目，并继承该项目的允许模型和余额；API 密钥页会列出所有工作区和项目中的每个密钥（管理 API 密钥）。被吊销的密钥立即失效，并保留在列表中供审计。
缺口 2：没有上限，账单就是警报
症状：那个跑了整个周末的 staging 任务。一个重试循环每秒发出 2 个请求，持续 48 小时：345,600 个请求，每个在 claude-sonnet-4-6 上带 3,000 个输入和 300 个输出 token。每个请求 0.009 + 0.0045 = 0.0135 美元，整个周末花了 4,665.60 美元，周一才被发现。
上线后为何更糟：批处理任务、agent 和重试都在无人看管时运行。每个工作负载没有上限，一条热路径就会动用整个组织的余额。
修法：沿着组织、工作区、项目的层级分配点数，把每个项目的分配额度当作上限。项目只能花被分配到的额度；余额用完时，请求会返回 402。如果 staging 只分配 50,000 点（500 美元），同一个循环约在 37,000 个请求、大约 5 小时后就会停下。步骤见设置有预算上限的团队。每一层的已分配与已消耗都显示在用量页（点数如何运作）。
缺口 3：没有逐请求记录，月账单无法自我解释
症状：财务看到机器人从 14,400 美元变成 39,600 美元。工程团队说什么都没变：同一个模型、同一个价格。会议结束时仍找不到原因。
上线后为何更糟：上线同时带来很多变化：更长的提示、新的检索设置、重试策略、更多用户。月度总额无法把它们区分开。
修法：每次调用都记录项目、密钥、模型、状态和输入／输出 token。ATP 的请求日志正是逐请求显示这些字段，可按时间范围、范围、模型、状态和 request ID 筛选（用量与日志）。以上面的例子来说，把请求日志筛选到机器人的项目，会看到每行约带 9,000 个输入 token。对照试点期记下的 2,000，几分钟内就能回答问题，前提是有人把试点期的数字记了下来。请把“每个项目每个请求的平均输入 token”作为每周跟踪的数字。
缺口 4：没有模型白名单，昂贵路径变成默认
症状：政策写着默认用中档模型。接着某位开发者为了处理一条语气投诉，把机器人换成更强的模型，然后就上线了。
上线后为何更糟：流量会放大模型之间的价差。同样的上线后流量（每天 40,000 个请求、输入 9,000 和输出 400 token），成本差异很大：
修法：每个项目维护一份允许模型列表。列表外的模型请求会在到达任何供应商之前被以 403 拒绝（工作原理）。GET /v1/models 会列出密钥可以调用的模型。这样一来，更换机器人的模型就成为由管理员在项目上做的变更，而不是一行代码的修改。
缺口 5：没有检查节奏，问题等到账单才出现
症状：两次账单之间没人打开用量页。为一次性迁移调高的上限一直没有调回，已结束试点的闲置密钥仍然有效。
上线后为何更糟：上线前检查过一次的控制，之后会慢慢偏移：新的密钥、更宽的白名单、更大的分配额度。
修法：建立轻量、固定的节奏：
活动日志会记录登录、邀请、额度变更和资源更新，覆盖每季度检查的大部分内容。
五个工作日补上五个缺口
第 1 天（周一）：盘点
打开 API 密钥页，它会列出所有工作区和项目中的每个密钥。逐一记下每个密钥被哪些系统使用、负责人是谁，并标出被多个系统共用的密钥。
第 2 天（周二）：拆分
为每个生产系统建立一个项目并发放新密钥。先迁移花费最高的服务，并为每个共用密钥定好吊销日期。
第 3 天（周三）：分配上限
取每个项目过去 30 天的消耗量，加上预计增长的余量，分配为每月上限。以上线后的客服机器人为例，至少是 3,960,000 点。staging 和实验项目只给小额分配。
第 4 天（周四）：收窄白名单
每个项目只启用需要的模型。从每个项目调用一次不在列表上的模型，确认会得到 403。
第 5 天（周五）：埋点与排期
把每个响应的 x-request-id 响应头，和你自己的功能或租户 ID 一起记录。把每周检查排进日历，并完整演练一次密钥吊销：吊销、查日志、重新发放。
同一个问题在每一步层面的版本，见什么是 agent tax。要建立第一个项目和密钥，请按照快速开始。
