AI网关Token成本激增4.2倍？从底层归因到上下文瘦身的完整治理方案

先说结论：Openlaw 网关某一周 Token 消耗环比涨了 4.2 倍，账单金额直逼当月预算的 87%。我盯着监控面板看了十分钟，第一反应不是模型变贵了，而是网关层某个开关失效了。做过 AI 应用的人应该都懂，网关一旦开始无脑转发请求，Token 就像漏水的龙头，关不住也堵不上，最后只能看着成本曲线在报表里画出一条垂直向上的线。

这里先解释一下背景。Openlaw 是一个面向法律场景的 AI 平台，主要做合同审查、法规问答、裁判文书结构化这类事情。法律文本本来就长，一份合同动辄两三万字，监管规定又常带着几十个条款，所以在 Openlaw 的调用链路上，Token 天然就是敏感指标。我负责的是 AI 网关层，所有业务方请求大模型都必须经过这一层，也是在这里统一做鉴权、限流、计量和计费。因此当成本超标这件事发生的时候，第一现场不在模型服务商，也不在某个业务代码，而就在网关的访问日志和用量明细里。

这篇文章算是我对这个问题的完整复盘，包括 Token 激增的根因分析、成本归因方法、优化方向和落地细节。如果你也在做 AI 网关、模型代理层或聚合 API 平台，或者你只是被大模型账单吓到过，我相信这里面的方法和踩坑记录都能直接用上。

1. 问题背景：先从一次“Token 成本超标”说起

1.1 Openlaw 网关在这条链路里到底做了什么

Openlaw 的架构并不复杂，核心链路是：客户端请求进入业务服务，业务服务拼装 Prompt，然后通过内部网关统一转发到多个大模型接口。网关在这里承担的不只是反向代理，它还会做三件重要的事：第一，把不同模型提供商的接口格式统一成内部标准；第二，把每个请求的模型名、业务线、用户维度、Token 用量记录下来；第三，控制并发、超时和重试策略。

听起来很常规，但问题恰好出在“统一”和“控制”上。一旦业务方认为网关会自动处理重试、会自动裁剪上下文、会自动切换模型，他们就会在代码里少写很多防御逻辑。法律业务的需求千奇百怪，有的业务方会把整部法规塞进 Prompt，有的会一口气发起 20 个审查子任务，还有的在模型返回超时后立刻再来一次相同请求。这些做法在业务侧很难直观感受到成本压力，因为对业务方来说只是“多调用了一次接口”，但在网关侧，每一次转发都是在燃烧 Token。

而且法律场景有它的特殊性：文本必须精读，问题通常需要很长的上下文。同一个用户在多轮问答中，既往对话可能积累几万 Token；同一个合同审查请求，可能需要把合同全部输入之外，还要追加法条、公司风险偏好、行业规范。这种“大上下文 + 长会话 + 多子任务”的组合，是 Token 激增的天然温床。

1.2 Token 激增的现场数据

本次问题是在一个周三下午被成本告警触发发现的。告警规则是“当日 Token 消耗超过 7 日均值 2 倍”时发送通知，而实际上，周五当日消耗已经飙到 7 日均值的 4.6 倍。

从网关日志里抽几组典型数据看会更直观：

• 单次对话类请求的平均 Token 消耗从优化前的 1.2 万涨到 3.8 万；
• 某个合同审查入口，一次请求最高消耗 12.7 万 Token；
• 重试请求占总请求量的比例，从 2% 升到了 9%；
• 同一用户的并发会话数没有明显增加，说明不存在“真实用户暴涨”的合理性；
• 4 个模型接口中有 3 个的输入 Token 占比超过 95%，输出 Token 几乎没有异常。

最后一组数据非常关键。输出 Token 正常，说明不是模型在“长篇大论”，而是我们送进模型的上下文被无限放大了。结合业务时间线，发现最近上线了一个“法规知识库增强”功能，用户提问后会把检索到的法条片段、司法解释、相似裁判文书全部拼装到 Prompt 里。出发点是好的，但没有任何上限控制，最极端的请求拼装了 6 万字材料。再加上多轮历史对话本身已经很长，最终一个普通问题也可能触发几万 Token 的输入成本。

1.3 为什么说网关是排查成本问题的最佳观测点

刚开始业务团队觉得是不是模型服务商计费出错了，我直接把网关里的 JSON 日志翻出来，按 request_id 还原了每一次完整请求。相比直接在模型服务商后台看账单，网关日志有不可替代的优势：它记录了业务请求的原文、路由信息、Token 用量、响应码和耗时。只要网关在设计之初就把 usage 字段原样记录，你就能回答“哪些业务线烧钱”“哪种请求烧钱”“是输入贵还是输出贵”这三个核心问题。

所以遇到 Token 成本激增，永远不要急着去调模型参数，先把网关日志当作第一手数据库来查。数据不会骗人，具体怎么查，下一个章节详细讲。

2. 核心归因：Token 激增背后的五个“吃钱黑洞”

2.1 先把 Token 到账单的换算规则说清楚

大模型计费的传统是按 Token 单价乘以用量，输入和输出往往价格不同。以一个常见模型举例：假设输入每百万 Token 5 美元，输出每百万 Token 15 美元。那么一次消耗 1 万输入 Token 的请求，成本是 0.05 美元；但如果这次请求因为超时被自动重试了 3 次，成本就直接变成 0.2 美元，而业务侧看到的“失败返回”数量可能只有一条。

如果再把这种重复放大到整个网关，一个 6 万输入 Token 的重型请求，每次成本可能在 0.3 美元以上。重试三次就是 0.9 美元，1000 个用户同时触发，就是 900 美元。换算成人民币之后，这就是一笔完全不该花的钱。

所以在做成本优化时，我习惯把 Token 账拆成四块：真实业务消耗、重试导致的重叠消耗、上下文无增长带来的无效消耗、以及模型选择不当造成的高单价消耗。这四块分别对应四种不同的优化手段，不能混在一起谈。

2.2 现场拆解：五个最可能的激增源

第一个黑洞是没有设置历史对话上限。Openlaw 的法规问答场景里，用户经常会连续追问，比如先问“合同违约金上限多少”，再问“那定金呢”，最后问“两个能并用吗”。这些单轮问题看似很轻，但如果网关在拼装 Prompt 时把用户进来之后的所有历史消息都带上了，三轮、十轮之后上下文就会不断膨胀。法律用户在真实场景中甚至能连续问几十轮，最夸张的一个会话历史超过了 50 万 Token，模型光读上下文就要花掉十几秒，费用当然压不住。

第二个黑洞是失败重试没有退避策略。网关里配置了重试，但很多团队第一次做的时候只会配一个简单的“失败就重试”。尤其是遇到上游模型接口返回 429（限流）或 503（服务暂不可用）时，重试如果立即执行，不仅会继续被限流，还会把每次失败请求的上下文重复发送出去。Openlaw 曾经发生过一次上游服务抖动，10 分钟内网关自动重试了 6400 次，而这 6400 次里面超过 70% 请求的输入内容完全相同，Token 消耗直接翻倍。

第三个黑洞是系统提示词和指令模板越来越长。为了优化输出质量，团队会不断往 System Prompt 里加规则，比如“你是一名资深法律顾问”“回答必须引用具体条文”“禁止编造法条”“如果信息不足要明确说明”。单条规则不贵，但累计起来很容易超过 2000 Token。这个值乘以每天几十万次请求，就是每月的固定浪费。更隐蔽的是有些模板会包含大量示例，Few-shot 示例一多，系统提示词甚至能到 5000 Token。

第四个黑洞是 RAG 召回结果不做去重和裁剪。知识库增强功能上线后，网关每次会把检索到的所有片段全部拼进 Prompt。问题是检索算法基本不会只返回 3 条，为了追求召回率，通常返回 10 条甚至 20 条，而这些片段之间存在大量重叠和重复。更夸张的是有些片段是整页裁判文书，明明有效信息只有“法院认为合同有效”这一句话，却把前后三页都带了进来。

第五个黑洞是批处理类任务没有流控。Openlaw 有一个老合同批量审查功能，用户上传一个 Excel 表格，系统会对每一份合同调用一次模型。这个功能本意是好的，但业务方会在同一个请求里并发 50 份合同，每份合同 8000 Token，一次性产生 40 万 Token 的用量。如果这种批量任务密集出现，网关又没做排队，就会在几分钟内烧掉平时一天的成本。

2.3 实际排查方法：从 Trace 到 SQL 的完整链路

排查 Token 激增不能靠猜，要做一次数据还原。我在这次问题中使用了如下方法，你完全可以直接复制。

首先确认总趋势。从网关在 MongoDB 里的调用日志表查出按小时聚合的 Token 消耗：

SELECT date_trunc('hour', request_time) AS hour, model_name, COUNT(*) AS request_count, SUM(input_tokens) AS total_input_tokens, SUM(output_tokens) AS total_output_tokens, SUM(input_tokens) + SUM(output_tokens) AS total_tokens FROM gateway_request_log WHERE request_time >= now() - interval '7 day' GROUP BY 1, 2 ORDER BY total_tokens DESC

通常这条 SQL 就能看出成本大头集中在哪个模型、哪个小时段。

第二步按业务线下钻。保证每个请求都带有 business_line 和 user_id 标签是网关设计的底线。然后继续查业务线占比：

SELECT business_line, COUNT(*) AS cnt, SUM(input_tokens) AS input_tokens, SUM(output_tokens) AS output_tokens, AVG(input_tokens) AS avg_input_tokens FROM gateway_request_log WHERE request_time >= now() - interval '7 day' GROUP BY business_line ORDER BY input_tokens DESC

第三步查重试比例。这一步最关键。我先找到所有 retry_count > 0 的请求，再关联到原始请求的 prompt_hash。prompt_hash 是网关在转发前对完整 Prompt 内容做的哈希值，它让我能用 SQL 找出“完全相同的请求被发送了多少次”。

查出来的结果触目惊心：某个 2 万 Token 的重型请求，在 3 分钟内被原样重试了 18 次，原因是下游服务偶发超时，而网关的重试指数退避配置没有生效。

为了长期监控这个指标，建议建一张“Token 异常波动”的汇总表，保留每日数据。以后再做优化时，直接盯这张表的趋势就够了。

3. 优化方向设计：怎么把成本重新装回笼子里

3.1 上下文瘦身：从源头控制输入 Token

成本超标问题爆发后，我们立刻开始设计上下文治理方案，原则只有一个：能用得越少，就绝不多送一个 Token 给模型。

第一步给多轮会话加硬上限。网关不再无条件拼接所有历史消息，而是采用滑动窗口。比如普通问答最多保留最近 6 轮对话，如果整体上下文超过 12000 Token，就把更早的历史消息改写成摘要。这个摘要可以由一次轻量模型调用生成，也可以直接用简单的截断策略。对很多法律咨询场景，“把前几轮问题压缩成一句主题”完全够用，不需要保留原文逐字信息。

第二步对上下文做分段定位。合同审查类任务并不需要一次把整份合同全部塞进模型。可以先把合同按条款切块，每块配合特定问题独立请求模型。比如“审查违约责任条款”，只传入违约相关的 3 个条款，而不是整个合同全文。这样即使合同有 5 万字，单次请求的 Token 也能控制在 5000 以内。

第三步在 RAG 侧增加召回结果裁剪。这里推荐“先粗排后精排再拼接”的做法：检索器先召回 20 条，重排器取 top5，最后按内容去重，并限制每个片段最大加入 800 Token。如果超过总量上限，按相关度从高到低截断。另外，要对检索片段做冗余检测，两段文本若相似度超过阈值，只保留更完整的那个。

实现上，上下文管理不应该散落在业务代码里，而应该在网关层做统一。网关收到业务方的请求时，检查请求里的 messages 结构，如果超出限额，就自动调用摘要模型或直接执行裁剪策略。这样业务方不需要关心底层细节，模型服务的质量也更容易稳定。

3.2 Prompt 工程和输出层的成本治理

上下文瘦身解决的是“历史消息太长”和“原始材料太多”的问题，但还有一类浪费来自我们自己的指令。

系统提示词需要做一次“减脂”。我在优化时建了一个提示词资产库，把每条指令拆成“必要性标签”，分成核心规则、安全规则、示例、格式要求四类。核心规则和安全规则必须保留，但示例尽量精简到 1 个，格式要求能用一句话说清的就不写五句话。删完后模型响应质量没有变化，但固定成本下降了约 25%。

另一个很值得做的优化是要求模型只输出增量信息。过去业务方会要求“把修改后的完整合同返回”，这会带来大量输出 Token，而输出 Token 往往比输入贵 3 倍。改成返回结构化修改建议，比如只输出“修改位置、原文引用、修改后内容、修改理由”，输出量能缩减到原来的五分之一。同时打开模型的 JSON 输出模式，网关在拿到结果后再转换成业务需要的格式。

还要注意 Stop Token 和最大输出长度限制。有些模型默认最大输出 4096 Token，如果业务逻辑只需要 200 Token 的结论，就应该在请求参数里把 max_tokens 拉低。Openlaw 问答场景里，我们统一将绝大多数接口的 max_tokens 设为 800，把超长输出能力留给少数确实需要生成完整文书的接口。

3.3 网关侧能做的事：限流、缓存和模型路由

网关不仅可以做被动转发，还可以主动承担成本治理职责。

限流是防止突发批处理用量的最重要手段。我们不能阻止业务方上传批量任务，但可以在网关层给每个用户或每个业务线配置 QPS 上限和 Token 每分钟消耗上限。一个很实用的做法是 Token Bucket 算法：每个用户每分钟允许消耗的总 Token 数固定，超过后排队等待。这样即使有用户一次上传 100 份合同，系统也会匀速处理，不会在 5 分钟内把成本烧穿。

缓存是本文成本优化里性价比最高的手段。语义相同或接近的请求不需要每次都去调用大模型。比如法律问答里用户经常问“合同违约金的上限是多少”，换成问题“民法典关于违约金的规定”，本质查询目标相同。网关层可以对用户输入做 embedding，然后存到向量数据库，当相似度超过 0.95 时直接返回缓存结果。更简单的场景是相同 prompt_hash 的请求，只要有滚动窗口缓存，就直接命中，不需要再消耗任何 Token。

模型路由则是“把不同类型的任务送到不同价格的模型”。Openlaw 内部将任务分成三类：复杂合同分析、标准法规问答、简单格式抽取。第一类使用最强的大模型，第二类使用中等性能且便宜的模型，第三类直接用轻量模型。网关在路由时根据业务方声明的任务等级，或根据 Prompt 预算自动选择模型。测试结果显示，在不牺牲关键业务质量的前提下，整体成本下降了约 40%。

3.4 建立成本基线和自动熔断机制

优化只做一次是不够的，业务迭代随时可能让 Token 用量再次失控。所以必须建立一套成本控制机制。

首先是成本预警。网关层每天统计每个模型接口的输入/输出 Token 用量，并与最近 14 天基线做对比。若单日消耗超过基线 1.5 倍，触发黄色告警；超过 2 倍时触发红色告警，自动发送到值班群。

其次是自动熔断。网关在转发请求前，会先计算当前时间窗口内已经消耗的成本和单次请求的预估成本。如果单次请求的预估成本超过 2 美元，并且用户没有申请特殊权限，则直接拒绝请求并返回“上下文过长，请精简后重试”。这个阈值一开始可以设高一点，运营一段时间后再调低。

最后是成本归因报表。每个月初，我会从网关导出一张按业务线聚合的成本表，发给各业务负责人。这其实就是把成本意识下放到每个团队。事实证明，业务方看到自己的请求量不过几百，成本却有几千美元，就会主动去优化 Prompt。比我们在后台反复推动有效得多。

4. 核心实现：网关层的关键代码与配置思路

4.1 标准化 Token 打点逻辑

网关层实现成本优化的前提是日志里有足够完整的数据。以常见的 Python/FastAPI 网关为例，在调用大模型接口后，必须把响应的 usage 对象保存下来，并给请求补上 request_id、business_line、user_id、prompt_hash 等维度。

下面是我实现的接入层核心片段：

import hashlib import time import json from datetime import datetime def build_request_meta(request_body: dict, business_line: str, user_id: str): messages = request_body.get("messages", []) prompt_text = json.dumps(messages, ensure_ascii=False) prompt_hash = hashlib.md5(prompt_text.encode("utf-8")).hexdigest() return { "request_id": f"{int(time.time()*1000)}-{user_id}", "business_line": business_line, "user_id": user_id, "prompt_hash": prompt_hash, "request_time": datetime.utcnow().isoformat(), "model_name": request_body.get("model", ""), "input_estimation": estimate_tokens(prompt_text) } def log_usage(record: dict, usage: dict, elapsed_ms: int): record["input_tokens"] = usage.get("prompt_tokens", 0) record["output_tokens"] = usage.get("completion_tokens", 0) record["total_tokens"] = usage.get("total_tokens", 0) record["elapsed_ms"] = elapsed_ms save_to_mongo(record)

在写入日志之前做一次 prompt_hash，比后续离线分析时再去对全文做哈希高效太多。另外，每次写入日志时记录预估输入 Token 的好处是，即使上游没有返回 usage，也能通过离线公式估算成本。Openlaw 很多模型接口在异常返回时不会带 usage，但请求内容已经发送出去了，这部分成本如果不记录，会变成“隐形 Token”。

4.2 成本预估公式与多模型定价表

成本预估这件事，很多人想复杂了。本质上就是 Token 量乘以对应模型的单价，公式如下：

请求成本 = (输入 Token / 1_000_000) × 输入单价 + (输出 Token / 1_000_000) × 输出单价

但实际应用里，输出 Token 往往不会在请求前就知道。所以网关层需要在转发前先用规则做“最坏情况”预估：假设输出会达到 max_tokens 上限。这样算出来的成本虽然偏保守，但用于限额控制是安全的。

我用下面的方法维护动态价格表：

MODEL_PRICE = { "claude-sonnet": {"input": 5.0, "output": 15.0}, # 美元/百万 Token "gpt-4o-mini": {"input": 1.5, "output": 6.0}, "local-small": {"input": 0.3, "output": 1.2}, } def predict_cost(model: str, input_tokens: int, max_output_tokens: int): if model not in MODEL_PRICE: # 如果遇到未知模型，按最高价拦截，宁可多拦，不能漏拦 return (input_tokens / 1e6) * 10 + (max_output_tokens / 1e6) * 30 price = MODEL_PRICE[model] input_cost = (input_tokens / 1e6) * price["input"] output_cost = (max_output_tokens / 1e6) * price["output"] return input_cost + output_cost

在网关的拦截逻辑中，先执行 predict_cost，再根据当前时间窗口内的剩余预算决定是放行还是排队：

def check_budget(record: dict, cost_limit_per_req: float = 2.0): predicted = predict_cost( record["model_name"], record["input_estimation"], 2048 # 统一按最大输出预期计算 ) if predicted > cost_limit_per_req: raise RequestTooExpensive( f"predicted cost {predicted:.3f} USD exceeds limit {cost_limit_per_req}" )

这套逻辑上线后，无数“把整部法规塞进 Prompt”的请求被拦截在了网关之前。业务方只需要看一眼系统提示，就能明白自己写的请求为什么被拒。

4.3 优化前与优化后的效果对比

把上下文截断、提示词精简、缓存和模型路由全部落地后，我统计了完整两周的数据。第一周是所有优化上线前的基线，第二周是优化上线后的稳定期。结果如下：

请求量上涨但成本下降的事实证明，之前烧掉的钱大部分都是工程浪费。缓存命中率在开通后稳定在 31% 左右，这部分请求完全没有调用模型。RAG 裁剪策略上线后，长尾请求的平均输入 Token 从 1.5 万降到 6000，业务答复准确率还小幅度提升了，因为多余的噪声文本被清理后，模型更聚焦于核心问题。

这里要特别说明，63.7% 的成本下降不能只归功于某一项优化。缓存节省的是重复请求成本，上下文裁剪节省的是长上下文成本，模型路由节省的是“过度使用贵模型”的成本。如果只做其中一项，效果都会大打折扣。

5. 常见问题与排查技巧实录

5.1 “改了上下文策略后，模型回答变差了怎么办”

这是做得最多的争议。业务方可能会反馈说，之前能记住 20 轮前的信息，现在只保留 6 轮，连续追问时上下文就不连贯了。

我的建议是把“上下文窗口”和“长期记忆”分开。不要指望把全部历史都塞进 Prompt，而是定期把重要信息抽取成摘要，作为系统提示词的一部分注入。Openlaw 里，我会在每 10 轮对话后调用一次轻量模型，生成一个包含“用户核心诉求、关键事实、待确认事项”的会话摘要，后续请求都携带这个摘要。这样一来，模型还是能回答“前面提到的那个合同”，但不用携带全部原文。

另外一个回退手段是支持业务方显式标记“这条请求必须全量上下文”。如果业务侧确实需要完整阅读一份长合同，就不做截断，而是把该请求路由到支持较长上下文的模型。网关的价值正是把这种例外控制在一个可控范围内，而不是全面放开。

5.2 “缓存命中率很低，为什么会这样”

工程同学经常提出缓存命中率不到 10%，怀疑缓存没用。我讲一个真实案例：Openlaw 最初做缓存时，用完整的 messages 数组做 key，结果完全相同的问题带上不同的历史背景，哈希值就变了，缓存几乎永远不命中。

后来我给缓存 key 增加了一层抽象：只对“当前用户问题 + 当前系统提示词版本 + 知识库检索结果的文档 ID 列表”做哈希，而不是把完整 prompt 所有字段都纳进去。这样只要用户问题相同、引用材料相同，哪怕历史上下文有细微差异，也能命中缓存。

如果连这个命中率都低，那说明业务场景本身重复请求较少。这种情况下可以考虑语义缓存，通过 embedding 计算相似度，但要注意延迟和误判风险。语义缓存更适合“不同问法、相似意图”的咨询场景，对合同审查这类强精确匹配场景帮助不大。

5.3 “重试逻辑为什么会让成本翻倍”

很多团队的网关配置了重试，但没有区分错误类型。如果上游返回 400（客户端参数错误），重试永远不会成功，只会重复消耗无效 Token；如果上游返回 429，重试必须带退避，否则会加剧限流；如果上游返回 5xx，可以重试，但次数上限一般在 2 到 3 次内。

我的排查技巧是在网关日志里记录每次重试是第几次尝试，并将重试请求关联同一个 trace_id。只要 trace_id 相同，离线分析时就可以把重试请求合并成一组。问题发生时，能立刻算出“这组请求因为重试额外消耗了多少 Token”。

5.4 “模型返回内容开始重复或走样”

有些团队优化过头，把上下文裁到 3000 Token，导致模型缺少必要的背景信息。针对这个问题，我建议守住两条底线：一是必须保留系统提示词中与安全相关的内容，即使它会占掉一些 Token；二是关键定义和术语不能砍，比如用户已经明确了合同标的、价款、管辖法院，这类信息绝不因为“超长”而丢弃。

如果上下文真的不够，不要硬裁，而是拆成多个子任务，分别调用模型，最后再汇总。这样每轮请求都只带和该子任务相关的内容，准确率和成本往往都能优化。

6. 写在最后：如果再来一次，我会先做什么

这次成本超标问题的完整处理过程，让我对“模型调用网关成本治理”有了很深刻的体会。如果时间倒流，让我回到最初做 Openlaw 网关的设计阶段，我会把下面三件事放在最高优先级：

第一，从第一天就在网关层强制统计 Token，而不是等账单出来再倒推。早期只记录了请求数和延迟，导致成本异常发生时，无法快速定位是哪些业务线烧钱。这个教训很贵。

第二，把“上下文上限”做成默认参数，而不是让每个业务方自己处理。用户不会主动控制 Prompt 长度，业务方也不会为成本负责。只有网关兜底限制，才是真正的防线。

第三，优化成本时不要只盯着“便宜”。法律场景对准确率要求极高，如果为了省 Token 把关键上下文砍掉，最后模型回答出错，带来的业务损失可能远超省下的一点模型成本。正确的思路是在保证质量的前提下，减少无用 Token、合理路由模型。

最后再分享一个可以直接落地的小技巧：给网关的每个请求加上 estimated_cost 字段，然后再配一个“当日成本 Top50 请求列表”的定时任务。每天看一眼这个列表，你不需要依靠任何复杂报表，就能第一时间发现异常调用模式。这比在模型服务商后台看账单直观得多，也是这次优化过程中我认为投入产出比最高的一件事。