一家公司上了 AI 之后，最常出现的失控场景是这样的

起初只有一两个人在用，申请一个 Key，跑得挺好。三个月后，五个业务线都在调，用的模型各不相同，谁也说不清这个月花了多少、花在哪个项目上。等到财务拿着账单来问，才发现根本拆不出来，所有调用共用一个 Key，日志里只有一串流水，没有归属。

这不是个例。大模型 API 的成本治理，难点从来不是「单价贵不贵」，而是**「钱花在哪了」这件事能不能被回答出来**。本文讲一套可落地的隔离方法。

一、为什么会失控

四个原因，按发生频率排序

1. 共用 Key。多个业务共用一个凭证，日志里无法区分调用方，事后无法分摊
2. 没有额度上限。任何一个脚本写错循环，都能在几小时内烧掉整月预算
3. 没有分层告警。只有「钱花完了」这一个信号，等到发现时为时已晚
4. 没有调用日志或粒度不够。只有总量没有明细，出问题时定位不到具体请求

这四条里，共用 Key 是根因，它导致后面三条都无法补救。所以治理的第一刀应该切在这里。

二、隔离的四层设计

层级	做什么	解决什么问题
账号层	主账号统一管理，各业务线下设子凭证	权限归属清晰
凭证层	每个项目/团队/环境分配独立 Key	调用可区分、可追溯
额度层	每个 Key 单独设定消费上限与有效期	单点失控不影响全局
日志层	记录时间、模型、输入输出 Token、费用	可分摊、可定位

这四层是递进的 没有凭证隔离，额度就设不了；没有额度，告警就没意义；没有日志，分摊就做不了。

三、落地步骤

第一步：按「项目 × 环境」拆分凭证，而不是按人。

按人分会导致人员变动后凭证混乱。建议的命名规则

{业务线}-{项目}-{环境}
示例：mkt-copywriter-prod、cs-kb-test、rd-agent-dev

一条原则 生产环境必须用独立 Key，且不与测试环境共用。测试Key可以宽松，生产Key必须收紧。

第二步：给每个 Key 设定额度与有效期。

Key 类型	额度建议	有效期	说明
生产 Key	按月度预算的 80% 设硬上限	长期	超限即熔断，需人工解除
测试 Key	小额固定额度	30 天自动过期	用完自动失效，避免遗留
临时/个人 Key	极小额	7-14 天	用完即弃，降低泄露影响

第三步：设定分层告警阈值。

def budget_alert(used: float, limit: float) -> tuple:
    """返回 (等级, 处理建议)"""
    ratio = used / limit
    if ratio < 0.5:
        return "正常", "无需处理"
    if ratio < 0.8:
        return "关注", "通知项目负责人，检查调用量异常增长原因"
    if ratio < 1.0:
        return "预警", "暂停新功能放量，排查是否存在循环调用或重试风暴"
    return "熔断", "停止该 Key 调用，人工确认后恢复或提额"

阈值设三层（50% 关注 / 80% 预警 / 100% 熔断）比只设一层有效得多，它给了团队反应时间，而不是等到账单出来才处理。

第四步：把日志粒度定死。

最小可用粒度：每次调用记录时间、所属 Key、模型名、输入 Token 数、输出 Token 数、费用。缺任何一项，后续分摊都做不下去。

这一项在不同平台上的实现差异比较明显。有的只给到「按天、按模型的总量」，有的能下钻到每一次调用。以快快AI Hub 为例，它的用量日志可查看各 Key 的时间、模型、Token 消耗与费用明细；但能细到什么程度，仍建议按自己的场景实测确认，因为「有日志」和「日志够用」是两回事。

第五步：按月出一张分摊表。

这是让成本治理闭环的最后一步，格式可以很简单

业务线	Key	调用次数	输入 Token	输出 Token	费用	环比
客服	cs-kb-prod	62,000	148M	31M	¥XXX	+18%
内容	mkt-copywriter-prod	8,400	12M	26M	¥XXX	-5%

有了这张表，财务问「钱花在哪」就有了答案，业务线之间也不必再互相猜疑。

四、成本怎么分摊到项目

如果日志已经按 Key 记录了 Token 与费用，分摊就是简单的汇总

from collections import defaultdict

def allocate_cost(logs: list, price_table: dict) -> dict:
    """
    logs: [{"key": "cs-kb-prod", "model": "deepseek-v3.2",
            "input_tokens": 800, "output_tokens": 400, "cached_tokens": 0}, ...]
    price_table: {"deepseek-v3.2": {"input": 0.7, "output": 1.05, "cache_read": None}}
    返回按 key 聚合的费用
    """
    result = defaultdict(float)
    for log in logs:
        price = price_table[log["model"]]
        cache_price = price.get("cache_read") or price["input"]
        fresh = log["input_tokens"] - log.get("cached_tokens", 0)
        cost = (fresh * price["input"]
                + log.get("cached_tokens", 0) * cache_price
                + log["output_tokens"] * price["output"]) / 1_000_000
        result[log["key"]] += cost
    # 单次成本极小，保留 6 位小数；累计到月度后再四舍五入到分
    return {k: round(v, 6) for k, v in result.items()}


# 示例（3 条调用，实际环境为百万级）
logs = [
    {"key": "cs-kb-prod", "model": "deepseek-v3.2", "input_tokens": 800, "output_tokens": 400, "cached_tokens": 0},
    {"key": "cs-kb-prod", "model": "deepseek-v3.2", "input_tokens": 1200, "output_tokens": 600, "cached_tokens": 0},
    {"key": "mkt-copywriter-prod", "model": "deepseek-v3.2", "input_tokens": 2000, "output_tokens": 1500, "cached_tokens": 0},
]
price = {"deepseek-v3.2": {"input": 0.7, "output": 1.05, "cache_read": None}}
print(allocate_cost(logs, price))
# {'cs-kb-prod': 0.00245, 'mkt-copywriter-prod': 0.002975}

真实环境下调用量是百万级的，把日志全量喂进去，汇总后四舍五入到分就是可直接交付财务的分摊表。脚本本身不复杂，难的是前面四步，如果 Key 没拆分，这段代码拿不到有意义的数据。

五、几个容易忽略的点

按环境隔离比按团队隔离更重要。

测试脚本的调用量往往远大于生产，一个跑偏的压测能在几小时内超过生产全月的量。测试 Key 务必独立设额且短期有效。

凭证泄露的影响半径取决于隔离粒度。

如果全公司共用一个 Key，一次泄露等于全部暴露。如果已经按项目拆开，泄露的影响就限制在单个项目内，且能快速定位是哪个 Key 出的问题、及时吊销。

权限与审计要一起做。

额度管的是钱，权限管的是谁能调用哪些模型、从哪些 IP 调用。审计日志记录的是谁在什么时候做了什么。这三件事分开看都是管理手段，合起来才是完整的治理，尤其当公司需要向客户或监管说明数据使用边界时，有没有审计日志是能不能回答的关键。

不同平台对这类能力的支持程度差异较大。

以快快AI Hub 为例，它支持在主账号下为每个 Key 单独设定有效期与消费额度，用量日志可下钻到每次调用的时间、模型与 Token 明细。不过具体到什么粒度、能否满足你的场景，仍建议按自己的业务实测确认，各家实现差异不小，不宜只看宣传口径。

六、边界说明

• 本文讨论的是企业内部的管理方法，不涉及具体平台的选型推荐；
• 配额与告警阈值的数值均为示例，需按自身业务量级调整；
• 分摊脚本依赖日志粒度，若平台未提供按 Key 的 Token 明细，则无法实现精确分摊，这一点应在选型阶段提前确认；
• 大模型 API 价格随上游调整而变动，分摊表中的单价应定期更新。

如果你们在成本治理上有别的做法，欢迎评论区交流，这类经验散在各家公司内部，公开讨论的价值很高。

---

关键词：大模型 API 成本治理、API Key 管理、预算隔离、Token 分摊、多团队核算、成本控制