最近不少做 AI 应用的同学都在聊同一个趋势Tokenmaxxing开始退场了。早先大家拿到大模型接口后习惯性地把“多塞上下文、多给提示、多让模型生成长文”当成提高效果的法宝甚至为了一个很小的判断会把几十页资料、整段日志、全部会话历史都拼进 prompt 里。这种“用 token 数量换效果”的做法在 demo 阶段确实很爽但一旦进入生产环境、面对真实流量和成本账单问题就会集中暴露。本文将围绕Tokenmaxxing这个概念展开讲清楚它为什么曾经流行、为什么现在开始失效以及 AI 应用进入“紧缩期”后我们应该如何从 token 预算、上下文管理、模型选型、缓存策略、RAG 提示词工程等维度做精打细算。文章会提供大量可复用的 Python 代码示例和工程建议适合正在做 LLM 应用开发、准备把 AI 功能落地的后端工程师和技术负责人阅读。1. 背景Tokenmaxxing 是什么它为什么曾经流行1.1 Tokenmaxxing 的典型行为先给一个通俗解释。Tokenmaxxing可以理解为“token 极限堆叠式用法”核心思路是既然模型的能力和上下文窗口都在增长那我就不做太多取舍把所有可能相关的信息都塞给模型让模型自己从里面找答案。这种玩法在真实项目中非常常见典型表现包括把整份产品文档、知识库文档、原始日志全部塞进系统提示词不做检索、不做裁剪。每次对话都把全部历史消息原样发给模型从不做摘要和截断。prompt 里反复强调同一个目标写一大段冗长的指令鼓励模型“详细思考、逐步分析”。不设置max_tokens上限让模型自由发挥生成很长的回复。对同一问题多次让模型重新生成然后人工或代码选择最佳结果宁愿多耗 token 也要“试出好答案”。从短期效果看Tokenmaxxing 确实能带来一些收益。大模型对上下文的利用能力在提升某些时候你给它更多信息它确实能给出更符合预期的答案。尤其在做概念验证、内部工具、一次性分析任务时这种“暴力投喂”的方式简单直接不需要做复杂的工程优化也不需要考虑成本分摊。1.2 Tokenmaxxing 流行的时代背景Tokenmaxxing 的流行和大模型 API 的早期生态有关。最初各家大模型厂商为了吸引开发者推出了大量免费额度和低价体验包很多开发者在试用阶段对 token 单价不敏感也没有完整的计量系统于是形成了“先堆量、再优化”的习惯。另外早期 LLM 应用的技术栈比较粗糙无论是 RAG检索增强生成还是 Agent 应用大家对如何构建 prompt、如何管理上下文都还在摸索阶段。与其费尽心思做检索排序、上下文压缩不如直接把数据全塞进去——这几乎是当时最稳妥的方案。在一些榜单评测和内部业务验证中Tokenmaxxing 也确实能刷出不错的成绩。1.3 什么是“Belt Tightening”标题里的Belt Tightening直译是“勒紧腰带”放在 AI 应用语境下就是“token 紧缩期”。它的含义不再是控制输出长度这么简单而是强调每一块 token 都要花得有价值。打个比方Tokenmaxxing 就像家里条件好时为了找一把钥匙可以把整个房子翻个底朝天而 Belt Tightening 则是要求你按房间、按区域、按概率逐步查找先找最可能放钥匙的地方找不到再扩大搜索范围。放在 LLM 应用里就是要在请求前想清楚这条 prompt 里的每一段文字是否必要这个上下文是否可以用更短的方式表达这个问题是不是一定需要最强最贵的模型2. Tokenmaxxing 为什么会“死”四个致命信号2.1 成本账单最先报警Tokenmaxxing 在 demo 阶段往往只有几个内部用户每个月消耗几百万 token换算成费用可能并不显眼。但应用一旦上线用户量增长十倍、百倍之后token 费用会呈线性甚至超线性增长。举个例子一个 RAG 问答应用如果每个请求都把 10 万字的知识库内容拼进 prompt那么一次请求可能就要消耗两三万 token。假设每天有一万次请求一天就是两三亿 token。这种消耗量即使单价很低月账单也会变成一笔不可忽视的固定支出。而且很多应用团队会发现消耗了这么多 token用户其实只关注其中一段几百字的答案。更麻烦的是token 成本很难通过简单的并发优化来降低因为它直接和业务调用量绑定。业务增长越快成本压力越大如果不提前做预算控制很可能出现“越成功越亏钱”的尴尬局面。2.2 延迟和体验下降Tokenmaxxing 不只是费钱还会让接口变慢。大模型的推理速度和输入长度强相关输入 token 越多计算量越大首字返回延迟也会明显增加。如果用户问一个简单问题服务端却要先把几万 token 的上下文发给模型再等模型处理完整体体验会非常差。移动端用户尤其敏感一个接口如果超过三五秒才有首字返回很可能直接在客户端被中断或超时重试。重试又会产生新的 token 消耗形成恶性循环。2.3 模型“迷失在上下文中”很多人以为上下文越长模型就越聪明但实际情况并非如此。研究发现大模型对超长上下文的利用并不均衡模型更容易注意到开头和结尾的信息而对中间部分的内容容易忽视这就是常说的“迷失在中间”Lost in the Middle现象。当 prompt 里塞入大量无关内容时模型可能会被噪声干扰反而漏掉真正关键的信息。你给了模型 10 万字最后模型告诉你“找不到相关内容”而实际上答案就藏在其中一段。这种质量下降不是模型变笨了而是信息过载导致注意力被稀释。裁剪 prompt、聚焦关键信息往往比无限堆料更能提升准确率。2.4 配额和稳定性压力大模型 API 通常有每分钟请求数RPM和每分钟 token 数TPM限制。Tokenmaxxing 会让单个请求消耗大量 token导致 TPM 配额很容易被打满。请求一旦触发限流就需要重试重试又加剧消耗还会影响线上稳定性。对于企业级应用来说稳定性要求远高于个人项目。如果因为个别大请求挤占了大量 TPM 配额导致其他核心接口无法调用这个系统就谈不上高可用。进入生产环境后开发者必须开始为每个请求做 token 预算评估而不是让模型“想吃多少吃多少”。3. “紧缩期”的核心思路预算、路由、优化既然 Tokenmaxxing 不可持续那新的阶段应该怎么做我把它归纳为三个关键词Token Budget预算、Token Routing路由、Token Optimization优化。3.1 Token Budget给每一次请求定预算预算思维要求开发者在构建 prompt 之前就清楚这次调用可以花多少 token。例如一个客服问答接口可以设定系统提示词不超过 500 token。用户问题携带的上下文不超过 1500 token。模型回答不超过 500 token。单次请求总 token 不超过 3000。这个预算可以基于业务重要性动态调整但必须有一个明确的阈值。超过阈值的请求要么裁剪上下文要么降级到更简单的模型要么直接拒绝并给出提示。预算思维是 Tokenmaxxing 的反面不是先想怎么把效果堆到最好而是先规定资源上限再在上限内做效果优化。3.2 Token Routing按场景选模型不同模型的定价和能力差异很大。最强模型虽然效果最好但可能是普通模型价格的几倍甚至更多。Tokenmaxxing 时代大家喜欢“无脑用最强模型”紧缩期则建议按任务难度做模型路由。简单任务可以这样分意图识别、关键词提取、格式化输出使用轻量模型速度快、成本低。普通文档问答、总结使用中等规模模型。复杂推理、代码生成、长文本分析才使用最强模型。模型路由可以放到业务代码里做也可以借助网关层实现。先判断任务类型再决定调用哪个模型这样整体成本可以下降 30%-60%而用户体验几乎不受影响。3.3 Token Optimization从各个环节压缩消耗Token 优化是本文的重点它不只是一两个技巧而是从 prompt 设计、上下文管理、缓存、数据预处理到输出控制的一整套工程实践。接下来我们会用几个代码示例把这套实践拆开来看。4. 实战在 API 调用层做 token 控制4.1 公共基础模块我们先用 Python 写一个简单的模型调用封装把 token 控制的几个关键点max_tokens、temperature、top_p、流式输出都纳入一个统一接口。# 文件路径llm_client.py import os import time from typing import Optional # 假设这里使用的是 openai 兼容接口 # 实际项目请替换为服务商对应的 SDK 和配置 from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) def chat( messages: list, model: str gpt-4o-mini, max_tokens: int 512, temperature: float 0.3, stream: bool True, ) - str: 统一的对话封装所有请求必须经过此函数。 通过 max_tokens 限制输出长度通过 messages 控制输入内容。 response client.chat.completions.create( modelmodel, messagesmessages, max_tokensmax_tokens, temperaturetemperature, streamstream, ) if not stream: return response.choices[0].message.content collected_chunks [] for chunk in response: if chunk.choices and chunk.choices[0].delta.content: collected_chunks.append(chunk.choices[0].delta.content) return .join(collected_chunks)这个封装有几个地方值得注意max_tokens是必填参数不允许缺省避免模型无限生成。stream默认开启这样用户能尽快看到输出也能在客户端中止时及时释放资源。model参数保留方便后续做模型路由。所有环境变量从外部读取不硬编码在代码里。4.2 每次请求都统计 token做成本控制的第一步是记录每一笔 token 消耗。修改上面的chat函数返回 token 使用情况。def chat_with_usage( messages: list, model: str gpt-4o-mini, max_tokens: int 512, temperature: float 0.3, ) - dict: 返回内容包括生成文本和 token 统计信息。 response client.chat.completions.create( modelmodel, messagesmessages, max_tokensmax_tokens, temperaturetemperature, ) message response.choices[0].message.content usage { prompt_tokens: response.usage.prompt_tokens, completion_tokens: response.usage.completion_tokens, total_tokens: response.usage.total_tokens, } # 记录到日志或监控系统用于后续成本核算 print( f[TOKEN_USAGE] model{model} fprompt{usage[prompt_tokens]} fcompletion{usage[completion_tokens]} ftotal{usage[total_tokens]} ) return {content: message, usage: usage}日志中的[TOKEN_USAGE]是方便监控系统采集的关键字。实际生产环境可以接入 Prometheus、SkyWalking 等监控体系也可以直接写 JSON 日志由 ELK 收集。记录 token 只是第一步没有这些数据后面任何优化都无法量化。4.3 设置请求前预算校验除了事后记录还可以在请求前做预算校验。这里用简单的估算函数判断当前 prompt 预计消耗多少 token。def estimate_tokens(text: str) - int: 粗略估算 token 数量。 不同模型的 tokenizer 不同这里只用于预警。 如果有服务商提供的 tokenizer 库应优先使用官方库。 if not text: return 0 # 一个常见近似英文约 4 字符/token中文约 1.5~2 字/token char_count len(text) # 简单处理按字符数除以 2 再向上取整 return max(1, int(char_count / 2)) def check_budget(messages: list, budget: int 3000): 如果估算出的 prompt token 超过预算提前预警或裁剪。 total_est 0 for msg in messages: total_est estimate_tokens(msg.get(content, )) if total_est budget: raise ValueError( fEstimated prompt tokens {total_est} exceeds budget {budget}. Please reduce context or use a simpler model. ) return total_est这里使用的估算函数只是近似值实际项目中如果服务商提供了官方 tokenizer例如tiktoken建议直接使用官方库。5. 实战上下文窗口管理与压缩5.1 用消息列表代替无脑拼接很多 Tokenmaxxing 的代码会把历史对话拼接成一段很长的字符串再塞进 system prompt。这种做法不仅浪费 token还会让模型分不清“历史对话”和“当前指令”的边界。正确做法是使用结构化的消息列表messages [ {role: system, content: 你是一个客服助手回答要简洁。}, {role: user, content: 我的订单一直显示配送中怎么办}, {role: assistant, content: 好的请提供你的订单号我来查询。}, {role: user, content: 订单号是 20250101001已经等了两天了。}, ] # 后续可以继续追加但需要控制总长度 messages.append({role: user, content: 请问还要等多久})角色字段让模型能理解每一段消息的来源。继续使用上一节的chat_with_usage调用即可。5.2 基于最近 N 轮对话的滑动窗口当对话历史很长时一个经典的策略是只保留最近 N 轮更早的内容直接丢弃或转成摘要。下面是一个简单的滑动窗口实现。def build_conversation_context( history: list, max_rounds: int 5, ): 从完整历史中提取最近 max_rounds 轮对话。 history 中的每个元素是一个 dict包含 role 和 content。 # 保留最近的 max_rounds * 2 条消息一问一答算 2 条 recent_items history[-max_rounds * 2:] if len(history) max_rounds * 2 else history return list(recent_items)使用示例full_history [ {role: user, content: f第 {i} 个问题} if i % 2 0 else {role: assistant, content: f第 {i} 个回答} for i in range(1, 21) ] context build_conversation_context(full_history, max_rounds5) print(len(context)) # 输出 10只保留最后 5 轮对话滑动窗口看似简单但在很多场景下非常有效。用户当前的问题通常只依赖最近的几轮对话更早的信息往往不影响回答质量。5.3 超出阈值时的历史摘要压缩如果最近几轮对话仍然太长例如每一轮都包含大段代码或长文档那么就需要在滑动窗口的基础上加入“历史摘要”机制。思路是保留完整的最近 1-2 轮对话。更早的对话由模型生成一段 200 字以内的摘要。每次请求时把摘要 最近对话 当前问题组合成最终的 messages。def summarize_history(history: list) - str: 对较旧的历史对话生成摘要。 summary_prompt [ {role: system, content: 你的任务是把用户和客服的对话历史压缩成一段不超过200字的摘要保留关键信息用户诉求、已经确认的事实、待办事项。}, {role: user, content: 以下是历史对话\n \n.join( f{item[role]}: {item[content]} for item in history )}, ] result chat(summary_prompt, max_tokens260, streamFalse) return result def build_compressed_context( history: list, max_rounds: int 2, ) - list: if len(history) max_rounds * 2: return list(history) recent history[-max_rounds * 2:] older history[:-max_rounds * 2] summary summarize_history(older) return [ {role: system, content: f以下是对更早对话的摘要请结合摘要回答用户问题{summary}}, *recent, ]这个方案虽然会额外消耗一次摘要生成的 token但对长期对话场景却能节省大量上下文费用。需要注意摘要本身也要控制长度不能让摘要越长越大最后失去压缩意义。5.4 显式传递关键结构化字段当请求中包含的是订单号、商品 ID、金额等结构化信息时与其把一大段数据塞进 prompt不如只提取关键字段。例如原始接口返回如下{ order_id: 20250101001, status: delivering, items: [ {name: 手机壳, quantity: 1, price: 29.9}, {name: 钢化膜, quantity: 2, price: 19.9} ], address: 北京市海淀区中关村大街1号, remark: 用户希望尽快送达有隐私保护需求 }不要直接把整个 JSON 塞进模型而是先提取模型需要用到的字段order_info { order_id: 20250101001, status: delivering, item_count: len(items), total_price: sum(item[price] * item[quantity] for item in items), }这样既减少了 token又避免了模型被无关字段误导。6. 实战RAG 场景中的 token 优化6.1 限制检索数量是最直接的削减方式RAG检索增强生成场景是 token 大户。很多实现会检索 Top K 条片段后把全部内容塞进 prompt导致一次问答消耗几千甚至上万 token。一个简单的优化方式是控制 K 值def search_documents(query: str, top_k: int 3) - list: 模拟向量检索实际项目中会调用向量数据库或搜索引擎。 # 这里只是示例实际返回的是与 query 语义最相关的文档片段 return [ {content: 文档片段一, score: 0.91}, {content: 文档片段二, score: 0.87}, {content: 文档片段三, score: 0.82}, ] results search_documents(订单配送超时怎么办, top_k3)把top_k从 10 降到 3prompt 的 token 消耗直接减少 70%。当然K 值不是越低越好需要根据你的文档切分粒度和业务场景进行测试。6.2 对检索片段做前置过滤在把检索片段拼进 prompt 之前先做一个规则层过滤。例如去掉空白字符过多、内容过短的片段。去掉明显重复或高度相似的片段。如果问题中包含订单号、手机号等实体优先保留包含这些实体的片段。def filter_and_deduplicate(chunks: list, min_len: int 20, max_len: int 500) - list: seen set() result [] for chunk in chunks: content chunk[content].strip() # 去掉过短和无内容片段 if len(content) min_len: continue # 去重 key content[:50] if key in seen: continue seen.add(key) # 截断超长片段只保留前后关键部分 if len(content) max_len: chunk[content] content[:max_len] result.append(chunk) return result6.3 把 RAG 提示词模板化把 RAG 提示词固定成模板避免开发者或用户随意注入无关内容。模板中只预留可变位置检索片段列表和用户问题。RAG_PROMPT_TEMPLATE 你是企业知识库助手。请仅根据下面提供的资料回答用户问题。 如果资料中没有答案请直接说明“资料中未找到相关信息”不要编造。 资料 {context} 用户问题{question} 回答要求 1. 简明扼要不超过300字。 2. 如果引用了资料中的内容请说明出处编号。 .strip() def build_rag_prompt(question: str, docs: list) - str: context_lines [] for idx, doc in enumerate(docs, start1): context_lines.append(f[{idx}] {doc[content]}) return RAG_PROMPT_TEMPLATE.format( context\n.join(context_lines), questionquestion, )模板有几点好处prompt 逻辑统一、token 消耗可预期、方便 A/B 测试。上线后如果某个请求消耗 token 异常对比模板一查就知道是哪个环节出了问题。6.4 为 RAG 增加语义缓存对于高频重复问题可以增加语义缓存。模型答案与用户问题并不是严格一一对应的因此简单用question做 key 不够准确可以使用 embedding 相似度来命中缓存。import hashlib def get_cache_key(text: str) - str: return hashlib.md5(text.encode(utf-8)).hexdigest() # 简化版缓存示例在真实项目中可以使用 Redis 并设置过期时间 cache {} def cached_answer(question: str, docs: list) - str | None: key get_cache_key(question | |.join(d[content] for d in docs)) return cache.get(key) def set_cached_answer(question: str, docs: list, answer: str): key get_cache_key(question | |.join(d[content] for d in docs)) cache[key] answer上面的实现非常简单实际系统中建议配合向量检索做语义缓存先算用户问题的 embedding再在缓存表中查找相似度超过阈值的历史问题直接复用答案。对于客服、FAQ 类业务缓存命中率可以做到 30% 以上是一个值得投入的方向。7. 常见问题与排查思路7.1 常见报错和现象问题现象常见原因解决思路账单费用突然暴涨某个请求的 prompt 太长或用户量突增按 interface / 用户维度拆分统计 token 消耗定位消耗大户设置了max_tokens但还是觉得费用高max_tokens只限制输出没有限制输入重点检查 messages 中 system prompt 和历史上下文的长度模型回答质量变差上下文过长模型忽略关键信息缩小上下文范围直接用检索保留关键片段接口响应时间变长输入 token 太多导致预填充时间增加对输入做裁剪优先使用流式输出明明给了知识库资料模型却说找不到资料被截断或关键信息位于超长上下文中部优化检索 Top K将关键片段前移减少总上下文长度Token 统计和账单不一致tokenizer 估算方式和服务商不同以服务商返回的 usage 字段为准不要用自己的估算值做费用对账7.2 排查 token 消耗异常的操作步骤如果线上 token 消耗异常建议按下面顺序排查先看监控从日志里找出单次请求 token 消耗最高的 Top 10观察它们有什么共同点。查 prompt 组成是 system prompt 太长还是历史消息没有裁剪还是检索片段数量过多查重试逻辑请求失败后是否会自动重试重试时是否因为消息列表没清理而叠加了更多历史查用户输入用户是否上传了超长文本是否有批量调用查流式中断流式输出时客户端中断是否会导致服务端继续生成7.3 如何避免常见坑不要把max_tokens当成唯一的 token 管控手段输入长度往往比输出更费 token。不要只存 messages 的字符串形式要保留消息数量和角色信息方便后续做裁剪。不要把所有逻辑放在一个 prompt 里拆成多个小任务往往更便宜、更稳定。不要盲目使用 Agent 自动规划Agent 每多一次调用就多一次 token 消耗简单问题用规则判断就够了。8. 最佳实践与工程建议8.1 预算先行量化一切在进入 AI 应用开发前先确定一个“单次请求成本上限”和“月度 token 预算”。这个预算应当由业务方和技术负责人共同确认并且在开发环境、测试环境、生产环境分别设置不同的阈值。上线前最好给每个接口做一个成本实测记录一个典型的二维表格业务场景、平均输入 token、平均输出 token、单次成本、预计日调用量、月成本估算。这样可以避免上线后才发现成本失控。8.2 在网关层统一管控如果团队内有多个应用都在调用大模型 API建议在网关层统一封装以下能力按应用维度做 token 配额控制。按接口维度做模型路由。统一记录日志和用量。支持一键降级到备用模型。对异常调用进行熔断。这样做的好处是业务代码不需要重复实现 token 管控逻辑只需要关心自己的业务参数。网关层的数据也可以用于后续成本分摊到各个业务线。8.3 充分利用缓存和离线批处理很多 AI 应用的 token 消耗集中在重复劳动上。例如同一份文档被多个用户反复提问每次都要重新检索和生成。热门问题每天都在被不同用户用不同的话术询问。定时任务不断调用模型做内容总结但原始内容并没有变化。这些场景都应该优先考虑缓存或离线预计算。离线预计算适合周期性任务例如每天晚上把当天的日志生成摘要而不是每次请求都让模型重新读一遍原始日志。8.4 用规则和传统算法分担模型压力不要把所有判断逻辑都交给大模型。例如手机号、邮箱、日期格式校验用正则表达式。简单的分类逻辑用 if-else 或决策树。关键词提取、敏感词过滤用词典法。大规模数据去重、排序用传统算法。大模型适合处理语义理解、内容生成、复杂推理等任务而规则和传统算法在这些场景中更快、更便宜。两者结合才能在成本和效果之间取得平衡。8.5 注意数据安全和最小必要原则在 token 紧缩的同时也要从安全角度审视 prompt 中的数据。不要把超出业务需要的用户隐私、密钥、内部系统信息发送给模型。遵循最小必要原则只发送当前任务必需的数据字段。对涉及生产环境的变更先在小流量上验证确认效果和成本符合预期后再逐步扩大范围。涉及数据导出的场景先做脱敏处理。9. 从 Tokenmaxxing 到精细化运营的转变Tokenmaxxing 的退场并不意味着大模型应用变弱了恰恰相反它意味着这个领域正在变得更成熟。刚开始接触大模型时大家被它的能力震撼愿意用大量 token 去试探模型的边界但当应用进入真实生产环境成本、延迟、稳定性和合规都成为必须考虑的因素精打细算就变成了核心竞争力。整个转变可以这样理解Tokenmaxxing 时代的核心问题是“模型能不能做到”而 token 紧缩时代的核心问题是“业务流程是否值得这样做”。如果一条业务逻辑可以用几行规则代码解决就没必要让模型读几万字上下文如果一段历史对话已经可以压缩成摘要就没必要每次都原样发送。对于正在开发 LLM 应用的团队建议从今天开始做三件事第一给所有模型调用加上统一的日志记录统计每天的 token 消耗和成本。数据是一切优化和决策的基础没有数据就谈不上成本控制。第二梳理出高消耗调用场景逐个优化 prompt 和上下文策略。优先处理调用量最大、token 消耗最高的几个接口性价比最明显。第三建立模型路由和预算告警机制。只对所有请求使用最强模型既是对效果的不尊重也是对成本的浪费。从长远看token 会随着技术发展越来越便宜但这并不意味着可以回到 Tokenmaxxing 的老路。模型能力越强我们越应该把宝贵的上下文窗口用在真正关键的信息上。如果你正在做的 AI 应用还在无脑堆 token不妨趁这次调整把预算、路由、缓存、上下文压缩这套体系建立起来。省下的不只是账单上的数字还有系统更稳定的运行状态和更可预期的用户体验。