最近一年，"记忆系统"成了降低大模型调用成本的主流叙事：历史对话压缩成摘要、稳定内容进缓存、长期信息按需检索，官方口径普遍是能省下 50% 到 90% 的 Token。手段本身没有问题，但不少团队落地后出现了一个反直觉的现象：上下文输入确实降下来了，月度账单却没有跟着降，甚至还在涨。
本文尝试复盘这个现象：先拆清楚记忆系统到底省了哪部分钱，再列出账单里真正失控的几类开销，最后给出一个偏向工程落地的治理思路和示意代码。全程不讨论具体某家厂商，只看调用链路上可以做的控制。
一、记忆系统省的是什么
拆开一次大模型调用，成本主要由两部分构成：输入 Token（Prompt）和输出 Token（Completion）。记忆系统主要作用在输入侧：
- 历史压缩：多轮对话每轮都要携带之前的内容，轮次越多，单次输入越长。行业实测是对话超过 5 轮后，单次输入 Token 量能比单轮场景高 4 倍。把历史压成摘要，只保留最近几轮原文，能显著降低输入量。
- 缓存复用：系统提示词、工具定义、参考文档这些每轮不变的内容，平台普遍提供缓存折扣，命中部分按原价一到两折计费。静态内容前置、动态内容后置，能提高命中率。
- 按需检索：长期信息放向量库，需要时再拉回上下文，而不是每轮全量携带。
这三招叠加，"输入侧省 50% 到 90%"是能实现的。问题在于：输入侧只是账单的一块，而且往往不是最大的一块。
二、账单真正失控的三类开销
把一个月的大模型账单摊开，通常会看到三类与记忆系统无关的开销：
散落的 Key，拆不开账。 每个人、每个项目各有一把 Key，直接对接模型平台。业务方只关心"能用"，没人关心"花了多少"。月底财务拿账单来问时，哪个项目烧的、哪个环境烧的、测试环境混在生产里的无效调用，全都说不清。
Agent 循环，跑起来停不住。 Agent 任务的单任务计算资源是传统问答的几十倍，复合任务里工具调用环节可占整体 Token 消耗的 85% 到 90%。一旦出现死循环——几十个 Agent 一夜烧掉价值数百万元的 Token，这类案例并不罕见——没有硬性退出条件和预算上限，就是灾难。
没有预算、告警和熔断。 能说清"下个月 AI 大概花多少"的团队十不存一。预算阈值、异常增长告警、超支熔断在云成本治理里是常规手段，放到模型调用上大多一件没做。钱不是一天烧完的，是每天多烧一点，直到季度账单出来才被看见。
三、治理思路：让每次调用可归属
这三类问题的共同点，是调用缺少归属。谁在什么时间、用了哪把 Key、调了哪个模型、花了多少钱，如果全部能查到，预算、告警、熔断、降级才有意义。
建议从三层入手：
- 凭证层：用可撤销的派生凭证替代散落的真实 Key，每把 Key 绑定项目、环境和负责人，泄露可秒级吊销，轮换不用改代码。
- 预算层：每把 Key、每个项目设日/月额度，接近阈值预警，超支限流或降级到低成本模型。
- 审计层：从凭证签发到每次调用全链路留痕，让"这笔钱花得值不值"变成可讨论的问题。
四、工程落地示意
落地时通常需要两条链路：一条是用量归集，把每次调用的归属信息沉淀成明细；一条是预算闸门，在请求路径上实时校验额度。
用量归集可以先把调用明细落地成结构化数据，示意表结构如下：
CREATE TABLE call_log (
call_id VARCHAR(64) PRIMARY KEY,
key_alias VARCHAR(64), -- 凭证别名，关联项目/环境/负责人
model_name VARCHAR(64),
input_tokens BIGINT,
output_tokens BIGINT,
cost_amount DECIMAL(12,4),
status VARCHAR(16),
created_at TIMESTAMP
);
CREATE INDEX idx_call_log_key_time ON call_log(key_alias, created_at);
预算闸门适合放在请求经过的网关或代理层，逻辑可以用伪代码表达：
def check_budget(key, project, estimated_cost):
used = get_period_usage(key, project, window="day")
if used + estimated_cost >= daily_quota * 0.8:
notify(project, "approaching_daily_quota")
if used + estimated_cost >= daily_quota:
reject("daily_quota_exceeded") # 或降级到低成本模型
return
charge(key, project, estimated_cost)
这两段只是示意：真实系统还需要考虑速率限制、模型白名单、失败重试的退避策略，以及把调用明细与现有监控体系打通。比如在云上落地时，可以把调用明细写入日志服务做留存分析，用轻量函数计算承载预算校验逻辑，用托管数据库保存配额与审计数据——核心原则是一致的：先让每一次调用可归属，再谈优化。
五、小结
记忆系统解决的是"怎么让每一次调用更便宜"，治理层解决的是"怎么让每一笔钱都花得明白"。前者决定单次成本的下限，后者决定月度账单的上限。如果你的项目已经做了记忆优化、账单却还在涨，不妨先检查三件事：凭证是否集中管理、预算是否有硬上限、月底能否说清钱花在哪。这三件事，才是账单不失控的真正底线。
