上下文工程中的Token预算管理

可视化演示

\u5c55\u793a\u8bed\u8a00\u6a21\u578b\u6839\u636e\u4e0a\u4e0b\u6587\u9884\u6d4b\u4e0b\u4e00\u4e2a\u8bcd\u5143\u7684\u6982\u7387\u5206\u5e03\uff0c\u901a\u8fc7\u6982\u7387\u6761\u5f62\u56fe\u76f4\u89c2\u5448\u73b0\u6a21\u578b\u5bf9\u5404\u5019\u9009\u8bcd\u7684\u7f6e\u4fe1\u5ea6\u3002

预算本质认识

出门前要过秤。航空公司给的免费额度是 23 公斤，你站上行李秤，心里一沉——超了。于是你明白，旅行的第一课不是“能装多少”，而是“允许装多少”。调用大模型之前，第一课同样不是模型的上下文窗口有多大，而是你愿意为一次请求花多少个 Token。Token 是大模型世界里的计价单位，就像衡量行李重量的“克”；而 Token 预算，就是航空公司给你的重量限额，既是物理上限，也是心理上限。

先纠正一个直觉：大模型声称的上下文窗口（Context Window，模型单次能“看到”的所有文本总量），比如 128K Token，并不等于每次都能塞进 128K。模型要给回答预留输出空间，输入和输出共享同一个窗口。这就像行李箱里你总要留一层放当天换洗的衣物，不能全塞满纪念品。

上下文工程的第一步，是明确输入侧的可用预算。从窗口总量中扣除输出预留，剩下的才是所有提示内容能分到的蛋糕。输出预留通常按窗口的 15%～30% 估算，取决于任务要生成多长的回答。预算同时受两重约束：窗口大小是硬约束，超了直接报错；成本是软约束，超了账单吃不消。

$$\displaystyle B_{\text{in}} = W_{\text{window}} - T_{\text{out}}$$

1. W_{window}（窗口总量）：模型上下文窗口的总容量，例如 128K 或 32K Token，可理解为行李箱的核定容积。

$$W_{\text{window}}$$

2. T_{out}（输出预留）：为模型生成回答预留的 Token 空间，通常占窗口的 15%～30%。

$$T_{\text{out}}$$

3. B_{in}（输入预算）：本次请求可用于系统提示、检索结果、历史对话等所有输入的总预算。

$$B_{\text{in}}$$

就像托运前先拿出尺子量一量，搞清楚“允许装多少”，后面的取舍才有依据。预算本质认识，就是给自己上一把行李秤。

上下文优先级

行李放不下时，老旅行者心里有一张清单：证件和内衣放最底层，永远在场；当季衣物按行程放第二层；相机、电脑这些“电子玩具”看剩余空间；到了当地才买的特产，从来不在计划内。大模型的上下文也有同样一张清单，只是排序依据换成了“对回答的贡献”。

上下文工程里，信息源一般分四层：系统提示词是核心层，相当于内衣证件，定义角色的行为基线，必须常驻；用户当前问题是必要层，决定这趟“旅程”的目的地，权重最高；RAG（检索增强生成，即先从外部知识库检索相关段落再让模型回答）结果和工具定义是可选层，按需裁剪；历史对话是易弃层，最该被压缩。

如何自动排序？给每条信息源算一个优先级评分：必要性打分越高越靠前；与用户问题的相关性越强越值得装；但冗余度是负项——和已装信息重复得越多越要扣分，因为重复的句子既浪费 Token，又稀释模型注意力。

$$\displaystyle S_i = w_1 \times N_i + w_2 \times C_i - w_3 \times R_i$$

1. N_i（必要性）：第 i 条信息源的必要性得分，想象成“不带它，这趟旅程根本走不了”的物品。

$$N_i$$

2. C_i（相关性）：与当前用户问题的相关程度，对应“跟行程单的匹配度”，越高越优先。

$$C_i$$

3. R_i（冗余度）：与其他已装信息的重复程度，重复越多扣分越狠，因为它在抢别人的份额。

$$R_i$$

4. w_1、w_2、w_3（权重）：三个可调权重，表示你对不同维度的信任程度，通过实验调参确定。

$$w_1,\ w_2,\ w_3$$

打包时给每件物品贴“必带、按需、可弃”的标签，上下文优先级就是给每条信息贴同样的标签。装不下的时候，最先被撕掉的永远是“可弃”的那一张。

动态组装策略

旅行达人从不把整个衣柜塞进行李箱，而是出发前一晚查好天气预报，再决定带不带冲锋衣；第二天早晨要是下雨，雨伞就出现在包里了。上下文工程也讲“看天装箱”：不是把知识库全塞进每次请求，而是为当前请求现做一盒便当。

动态上下文组装（Dynamic Context Assembly）的意思是：每次调用时，从候选信息池里按需加载最相关片段，而不是全量注入。工程上通常配合三条管线：路由分流——先用意图识别决定这趟请求走 RAG 还是走工具调用；增量注入——多轮对话中只追加新增内容，不重复推送旧内容；过期淘汰——超过 N 轮或与当前话题无关的历史，自动移出窗口。

组装是有成本的。单次请求的 Token 开销可以拆成三部分：基础层是系统提示加用户问题，固定且必须；检索层是 RAG 拉取片段产生的开销，按需产生；装配层是序列化、拼接、格式化带来的额外开销，虽小但积累起来可观。

$$\displaystyle C_{\text{req}} = C_{\text{base}} + C_{\text{ret}} + C_{\text{asm}}$$

1. C_{base}（基础开销）：系统提示词与用户问题的固定 Token 数，相当于行李箱的常驻层，每次必花。

$$C_{\text{base}}$$

2. C_{ret}（检索开销）：RAG 或工具调用把外部信息拉进上下文带来的 Token 数，只在需要时产生。

$$C_{\text{ret}}$$

3. C_{asm}（装配开销）：拼接、换行、JSON 格式化等结构性 Token，属于“打包用的胶带”。

$$C_{\text{asm}}$$

动态组装像“当天现炒的便当”，而不是把整个冰箱背在身上。你只带今天要吃的，路再远也不怕超重。

预算分配方法

23 公斤怎么分？常穿的衣服多给几公斤，只拍照用的相机给两公斤，书能不带的就电子化。分完，每个隔层都有自己的配额，超了就互相借。上下文预算的分配，本质是把输入预算这块蛋糕按优先级切成几份，分给不同信息源。

每个信息源在预算里的“理想份额”，应该与它的优先级权重成正比。系统提示词权重高，分得多；历史摘要权重低，只分到很小一块。这样保证最重要信息永远是最大块，可弃信息永远是最小块。

实际工程里两种做法配合：一是硬分配，给每个信息源设上限（例如 RAG 片段最多 2000 Token）；二是自适应缩减，当检索结果超长时，从低优先级信息源（通常是历史）扣预算，而不是削系统提示。再用滑动窗口管理多轮历史：最近 K 轮保留原文保证连贯，更早的压成一句话摘要放进窗口一角。

$$\displaystyle T_i = B_{\text{in}} \times \frac{r_i}{\sum_{j=1}^{n} r_j}$$

1. T_i（份额）：第 i 个信息源分到的输入 Token 数，即它在行李箱里的隔层大小。

$$T_i$$

2. r_i（权重）：第 i 个信息源的优先级权重，由上一节的评分归一化得到。

$$r_i$$

3. Σ r_j（权重总和）：所有信息源权重之和，把 100% 的预算按比例切分。

$$\sum_{j=1}^{n} r_j$$

就像给行李箱的每个隔层贴一张“配额”小纸条，预算分配方法保证任何信息源都不会偷偷霸占整个箱子，也保证最低优先级的信息源永远第一个被牺牲。

密度优化技巧

同样的行李箱，有人塞进五套衣服，有人塞进十套——差别在打包方式：卷，不叠。Token 世界的“卷衣服”叫信息密度优化：让每个 Token 装载更多对回答有用的信息。

一篇 5000 字的文档和一段 200 字的摘要，对回答同一个问题的贡献可能相差无几，成本却差 25 倍。信息密度高的上下文，等于把羽绒服塞进真空压缩袋，体积缩小一半，保暖效果不变。

三个常用手段：压缩改写——让模型或规则把检索片段压成要点式摘要，而不是原样粘贴；去重合并——多个片段互相重叠时先合并再裁剪，去掉重复句；结构化——用 JSON、表格、要点符号代替散文，同样的 Token 能装更多结构化信息。每一条都指向同一个数学直觉：密度等于有效信息量除以消耗 Token 数。

$$\displaystyle D = \frac{I_{\text{eff}}}{T_{\text{in}}}$$

1. I_{eff}（有效信息量）：对生成正确回答有直接帮助的信息单位，是行李里真正保暖的部分。

$$I_{\text{eff}}$$

2. T_{in}（输入令牌数）：这条信息占用的输入 Token 数，等于它的“行李重量”。

$$T_{\text{in}}$$

3. D（信息密度）：单位 Token 装载的有效信息量，密度越高，预算利用得越充分。

$$D$$

卷起来的 T 恤、压扁的羽绒服、结构清晰的清单——密度优化让你在同一个箱子里带走更多真正有用的东西。它不改变窗口大小，却改变了窗口里装的是什么。

成本估算控制

超重一公斤，柜台收费二百。旅行者最心疼的往往是返程过秤那一刻。大模型应用也分“去程”和“返程”：输入 Token 和输出 Token 的单价可能不同，而输出往往更贵——它们都被记在账单上，只是单价不一样。

Token 预算不只是技术指标，更是财务指标。一个 100K 上下文的请求，哪怕只在输入侧，也会让单次调用成本肉眼可见地上升。上生产前必须回答一个问题：一次典型请求到底花多少钱？答案来自一个简单的乘法。

计费公式拆开看：输入 Token 数乘以输入单价，输出 Token 数乘以输出单价，两者相加再乘以调用次数。控制账单的三板斧：缓存复用——高频固定片段（系统提示、常用知识）命中 KV 缓存后省去重复计费，相当于同一件外套多穿几次不另收费；监控预警——记录每次调用的 Token 消耗，超阈值报警；多级降级——预算紧张时先用摘要回答，再降级为短答案，保住最核心体验。

$$\displaystyle \text{Cost} = \left( \frac{T_{\text{in}}}{1000} \times p_{\text{in}} + \frac{T_{\text{out}}}{1000} \times p_{\text{out}} \right) \times N_{\text{calls}}$$

1. T_in / T_out（输入与输出令牌数）：一次请求实际消耗的上下文输入量和模型生成的输出量。

$$T_{\text{in}},\ T_{\text{out}}$$

2. p_in / p_out（单价）：每 1000 Token 的输入与输出价格，通常 p_out 高于 p_in。

$$p_{\text{in}},\ p_{\text{out}}$$

3. N_calls（调用次数）：请求总次数。次数一多成本线性放大，Agent 多轮场景尤其明显。

$$N_{\text{calls}}$$

像记账本一样给每趟“航班”记下行李费，成本估算让 Token 预算从工程师的直觉，变成产品经理和财务都能看懂的预算表。记好这笔账，你的 Agent 才不会在月底被账单吓一跳。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Token预算管理器:按优先级分配,超限裁剪,估算成本"""  def estimate_tokens(text):    """粗略估算:中文约一字一令牌,英文约四字符一令牌"""    if not text:        return 0    cn = sum(1 for ch in text if '\u4e00' <= ch <= '\u9fff')    en = len(text) - cn    return int(cn + en / 4.0)  class BudgetManager:    def __init__(self, window=4096, reserve=0.25, prices=(0.03, 0.06)):        self.window = window        self.reserve = reserve        self.prices = prices        self.sources = {}     def add_source(self, name, text, priority, tokens=None):        if tokens is None:            tokens = estimate_tokens(text)        self.sources[name] = {'tokens': tokens, 'priority': priority}     def input_budget(self):        return int(self.window * (1 - self.reserve))     def ideal_split(self):        """按优先级权重将输入预算划分为各信息源份额"""        budget = self.input_budget()        total_pri = sum(s['priority'] for s in self.sources.values())        shares = {name: int(budget * s['priority'] / total_pri)                  for name, s in self.sources.items()}        return shares     def requested(self):        """每个信息源实际想要的令牌数(未裁剪)"""        return {name: s['tokens'] for name, s in self.sources.items()}     def trim_to_budget(self, plan):        """超预算时从优先级最低的信息源开始裁剪"""        budget = self.input_budget()        used = sum(plan.values())        if used <= budget:            return plan, used        order = sorted(self.sources, key=lambda n: self.sources[n]['priority'])        for name in order:            if used <= budget:                break            cut = min(plan[name], used - budget)            plan[name] -= cut            used -= cut        return plan, used     def estimate_cost(self, input_tokens, output_tokens, calls=1):        pin, pout = self.prices        return (input_tokens / 1000 * pin + output_tokens / 1000 * pout) * calls  def main():    mgr = BudgetManager(window=4096, reserve=0.25, prices=(0.03, 0.06))    mgr.add_source('system', '你是一个专业的客服助手,负责回答售后问题.', priority=5)    mgr.add_source('user', '我的订单一直显示运输中,已经三天了,怎么办?', priority=4)    mgr.add_source('rag', '物流常见问题:超48小时未更新请提交工单,可申请退款.', priority=3, tokens=1500)    mgr.add_source('history', '(最近十轮对话摘要:用户上周询问优惠券使用条件.)', priority=1, tokens=2400)     print('理想划分(按优先级):', mgr.ideal_split())     plan = mgr.requested()    trimmed, used = mgr.trim_to_budget(plan)    print('裁剪后分配:', trimmed)    print('实际使用:', used, '预算上限:', mgr.input_budget())     cost = mgr.estimate_cost(used, 300)    print('单次调用成本: $%.3f' % cost)  if __name__ == '__main__':    main()

1. cn = sum(1 for ch in text if '\u4e00' <= ch <= '\u9fff')用 Unicode 范围数出中文字符个数，英文按四字符一令牌折算。
2. tokens = estimate_tokens(text)字符估算只是兜底，上线前要换成真实 tokenizer 的输出。
3. self.sources[name] = {'tokens': tokens, 'priority': priority}把每个信息源注册进预算表，记录它“想要多少”和“该排多前”。
4. budget = self.input_budget()先算输入预算：窗口总量乘以 1 减输出预留比例，对应文章第一个公式。
5. shares = {name: int(budget * s['priority'] / total_pri) for name, s in self.sources.items()}按优先级权重把预算切成份额，权重越高隔层越大。
6. order = sorted(self.sources, key=lambda n: self.sources[n]['priority'])超预算时按优先级从低到高排序，最先牺牲的永远是历史层。
7. cut = min(plan[name], used - budget)每个源最多被裁到 0，不会出现负额度。
8. return (input_tokens / 1000 * pin + output_tokens / 1000 * pout) * calls账单公式：输入与输出分别计价，再乘以调用次数。

常见误区

面试题