最近在 LLM 工程圈有一段话被反复转发“Microsoft Tells Engineers Tokenmaxxing Is Not What We Are Optimizing For”。微软明确告诉工程师“Token 拉满Tokenmaxxing”并不是他们优化的方向。这句话为什么会引发讨论因为过去一年多里很多团队在做 LLM 应用时确实把“Token 消耗”当成了最核心的技术指标。上下文塞得越满越好输出长度越长越好单次请求不把模型的上下文窗口用掉一大半就总觉得亏。但从微软这句表态来看这种思路可能从一开始就跑偏了。这篇文章不聊模型也不聊部署就专门拆解一句话Tokenmaxxing 到底指什么为什么它不是优化目标以及我们自己在做 LLM 应用时应该怎么设计 Token 相关的指标体系、日志记录和批量任务成本控制。如果你正在做 LLM 应用、接大模型 API、维护批量任务或者团队内部正把“Token 用量”当作技术 KPI这篇建议直接收藏。1. Tokenmaxxing 是什么先把这个合成词拆开1.1 Token 是 LLM 的基本度量单位大语言模型处理文本时会把输入内容切成小块这些小块的通用叫法就是 Token。中文场景下一个字大概对应 1 到 2 个 Token英文一个常见单词也差不多是 1 到 2 个 Token。Token 同时决定了三件事你能不能把内容塞进上下文窗口、一次请求要花多少钱、以及生成结果需要等多久。所以 Token 本身没有问题它是 LLM 应用里绕不开的基本单位。问题出在“怎么用 Token”这个层面。1.2 Tokenmaxxing 在工程里的三种典型表现Tokenmaxxing 是 Token 和 Maxing 组合出来的词可以理解为“把 Token 用到极致”。在工程实践里我见过比较典型的表现有三种第一种上下文塞满。不管业务需不需要把全部历史记录、所有参考资料、各种示例对话一次性全塞进上下文。系统提示词越写越长用户每发一句话模型都要重新处理几千甚至几万个 Token。看起来是把大模型能力用满了实际很多内容都是冗余的。第二种输出拉满。把 max_tokens 直接设置成模型允许的上限认为“输出越长效果越好”。用户问一个简单问题模型硬生生给你生成一两千字的回复里面有效信息可能就两句话。Token 花了体验反而变差了。第三种Token 变成考核指标。团队内部用“单次请求消耗了多少 Token”“上下文窗口占用率多高”来评估技术方案好坏。这个指标一挂上去开发者的行为就会变形所有人都在想办法把 Token 数字做得“好看”而不是把产品功能做得“好用”。1.3 为什么“把 Token 用满”不等于“把事做好”Token 是过程度量不是结果度量。用户使用一个 AI 产品真正关心的是任务有没有完成、结果准不准、响应快不快、成本可不可控。至于这次请求消耗了多少 Token那是实现层面的细节。Token 用得多和产品质量没有线性关系甚至经常是反的。上下文里塞了太多无关内容模型容易抓不住重点回答质量会下降输出拉满会导致响应变慢用户等得不耐烦上下文窗口占用率越高并发场景下显存和计算压力也越大。微软说“Tokenmaxxing 不是我们在优化的方向”本质上就是在纠正这种指标错位。2. Microsoft 这句表态的工程含义2.1 这不是一句产品公告而是一次工程评估视角的纠偏这句话从传播形式看更像是微软内部对工程师团队的一句提醒而不是对外发布的规则文档。我们不去考据它具体出自哪个部门、哪次会议只讨论这句话本身传递的工程信号。很多 LLM 团队在初期探索时都容易陷入同一个误区把模型能力当产品价值。模型能处理长文本就把所有文本都喂进去模型能生成超长回复就让输出拉到最长模型上下文窗口大到 200K就希望每次请求都用满 200K。这种思路看起来很“充分利用模型能力”实际上是在用模型边界代替产品需求。微软这句表态是站在工程效率角度做了一次纠偏优化的方向应该是产品目标而不是模型能力的使用率。2.2 优化目标要从 Token 指标上移到业务结果如果说 Tokenmaxxing 是“指标导向”的错误示范那它的反方向就是“结果导向”。一个功能上线前我们应该先定义清楚用户完成一项任务的成功率是多少单次任务的平均成本是多少端到端响应延迟是多少。这些指标稳定了再去反推合理的 Token 使用区间。举个例子。同样是做一个客服问答机器人用 2000 个 Token 就能把用户问题处理清楚就完全没必要为了“充分利用上下文窗口”把知识库几千字的资料全部塞进去。前者单次成本低、响应快、维护简单后者看着更“聪明”实际只是在为无效 Token 买单。2.3 如果我们自己做项目该怎么理解这句话对我们自己来说这句话最大的价值是调整评估视角。以后在技术评审或方案设计时不要再问“这次请求用掉了多少个 Token”而应该问“这次请求有没有用最少的资源完成业务目标”。Token 消耗当然要看它是成本控制的重要信号。但看的方式是记录、分析和优化而不是作为团队 KPI 来考核。微软这句表态给了一个很好的判断标准任何一个指标如果跟业务结果没有直接关联就不应该成为优化的终点。3. LLM 工程真正要盯的四个指标既然 Token 数量不是核心优化目标那应该盯什么这里给出四个经过大量工程实践验证的指标比单独看 Token 更有价值。指标定义为什么比 Token 更重要任务完成率用户请求被成功处理的比例直接反映产品价值Token 数量与任务完成率无线性关系有效输出密度输出结果中有效信息占比衡量生成质量避免“注水回复”单位任务成本完成一个任务消耗的总成本关联 Token 与业务是成本控制的关键端到端延迟用户发起请求到拿到结果的时间决定用户体验上下文越长延迟越高3.1 任务完成率这是最核心的指标。用户问了一个问题模型给出的答案是否满足需求这是评价 LLM 应用价值的第一标准。Token 消耗多不代表任务完成率更高反而可能因为上下文干扰导致成功率下降。3.2 有效输出密度同样一个任务有些模型回复 2000 字但有效信息就 100 字有些模型回复 300 字但每句都有用。有效输出密度就是用来刻画这个差异的。评估方法可以人工打分也可以用小模型做信息抽取看输出中真正被用户使用的内容占比。3.3 单位任务成本单位任务成本 总成本 / 完成任务数。这个指标把 Token 消耗、API 调用价格、重试次数和人工干预成本都折算进去。Token 少不等于成本低因为如果任务失败需要重试失败的那次请求同样要花钱。单位任务成本是 Token 成本控制的正确打开方式。3.4 端到端延迟端到端延迟受上下文长度、输出长度、模型推理速度和网络环境影响。上下文越长模型首 Token 延迟越高输出越长整体生成时间越长。优化延迟往往和优化 Token 用量是一致的更精简的上下文、更克制的输出长度通常带来更快的响应。这四个指标是联动的不要只盯其中一个。理想的优化方式是在任务完成率不下降、有效输出密度不降低的前提下把单位任务成本和端到端延迟压到最低。4. 开发中如何观测和评估 Token 消耗前面说了 Token 不是优化目标但 Token 消耗必须被观测。不观测就谈不上成本控制。这一节给出具体的观测方法以常见的 OpenAI 兼容接口为例。4.1 从 API 返回里读取 Token 用量大多数大模型 API 的返回结果里都带有 usage 字段里面包含 prompt_tokens、completion_tokens 和 total_tokens。即使部分自建服务不返回这个字段也可以通过请求日志辅助统计。import requests import json url https://api-provider.example.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { model: your-model-name, messages: [ {role: system, content: 你是一个技术助手回答尽量简洁。}, {role: user, content: 帮我解释一下 Token 成本控制的基本思路。} ], max_tokens: 1024 } resp requests.post(url, headersheaders, jsonpayload, timeout60) data resp.json() print(json.dumps(data.get(usage, {}), ensure_asciiFalse, indent2))如果接口正常返回你会看到类似下面的输出{ prompt_tokens: 48, completion_tokens: 256, total_tokens: 304 }每次请求完成之后都应该把这三项数据记录下来而不是用完就丢。4.2 把 Token 消耗写进请求日志一个完整的 Token 审计日志至少应该包含请求 ID、模型名称、输入 Token、输出 Token、总 Token、耗时和请求状态。这样后续才能按模型、按时间段、按任务类型拆分成本。import json import datetime def log_request(request_id, model, usage, elapsed_ms, status): log_entry { timestamp: datetime.datetime.now().isoformat(), request_id: request_id, model: model, prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), total_tokens: usage.get(total_tokens, 0), elapsed_ms: elapsed_ms, status: status } with open(token_audit.jsonl, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n)建议把日志写入 JSONL 格式一行一条记录方便后续用 pandas 或 jq 做统计分析。日志目录要轮转避免单个文件无限增长。4.3 用配置表做单位任务成本估算Token 单价经常会变不建议把价格写死在代码里。正确做法是把模型价格放在配置表里单独维护。# cost_config.yaml models: your-model-name: input_price_per_1k_tokens: 0.001 output_price_per_1k_tokens: 0.002 your-other-model: input_price_per_1k_tokens: 0.0005 output_price_per_1k_tokens: 0.0015计算单次请求成本的公式是cost (prompt_tokens / 1000 * input_price_per_1k_tokens) (completion_tokens / 1000 * output_price_per_1k_tokens)然后根据日志里的任务 ID 做聚合就能得到单位任务成本。这个数据比单纯看 Token 数量有用得多。5. 避免 Tokenmaxxing 的落地手段知道了要看什么指标接下来就是具体怎么控制 Token 浪费。这里给出三个可直接落地的优化手段。5.1 上下文裁剪摘要 最近轮次长对话场景最容易出现 Tokenmaxxing。简单粗暴地把所有历史消息全部传给模型既不经济也会让模型忽略当前真正重要的指令。推荐做法是维护一份对话摘要再保留最近几轮完整消息。def build_messages(system_prompt, history, max_turns6): # 只保留最近 max_turns 轮完整对话 recent history[-max_turns:] messages [{role: system, content: system_prompt}] for item in recent: messages.append({ role: item[role], content: item[content] }) return messages如果对话特别长可以先调用一次模型对旧对话做摘要把摘要作为 system prompt 的一部分再接最近几轮消息。代码逻辑上多了一个分支但能大幅压低每次请求的输入 Token。5.2 输出长度约束max_tokens 和结构化输出输出端最容易浪费 Token。一个能用 200 Token 解决的问题不要给模型 2000 Token 的生成空间。max_tokens 要按任务类型做区分而不是所有接口统一拉满。payload { model: your-model-name, messages: messages, max_tokens: 512, # 先限制输出长度 temperature: 0.3, response_format: {type: json_object} # 如果接口支持 }需要结构化输出时优先让模型返回 JSON而不是自由文本。这样既方便下游解析也能从格式上约束输出长度避免模型把答案写成小作文。5.3 系统提示词瘦身很多项目的 system prompt 是不断累加出来的。早期版本写了一段后续需求再加一段几个月下来 system prompt 可能已经上千 Token。定期做一次系统提示词清理把过时规则、重复表述和冗余示例删掉。瘦身后的 system prompt 不仅省 Token模型遵循指令的效果往往也更好。一个可执行的建议每次修改 system prompt 前先对当前版本做一次“最小化测试”看看删掉哪些内容后结果质量不受影响。这样逐步把不必要的 Token 挤出去。6. 接口 API 与批量任务里的 Token 成本控制6.1 批量任务先做小样本成本测试批量任务场景下Token 成本会线性放大。同样一段提示词跑 1000 条数据和跑 100 条数据成本差 10 倍。所以在全量执行之前一定要先做小样本测试。第一步先抽 50 条有代表性的样本。第二步用完整配置跑一遍记录总 Token 消耗、耗时和成功率。第三步根据这 50 条的均值估算全量成本。如果超出预算就先优化提示词或调整模型不要直接全量跑。{ model: your-model-name, input_dir: ./inputs, output_dir: ./outputs, log_dir: ./logs, max_tokens_per_task: 1024, temperature: 0.2, batch_limit: 50, retry_limit: 2, concurrency: 4, estimate_before_full_run: true }6.2 失败重试会导致 Token 重复消耗批量任务里最容易忽略的成本陷阱是重试。一次请求失败后重试输入 Token 会重新计费。如果失败率高重试消耗的 Token 可能比有效请求还多。缓解办法是加缓存。同一个输入内容如果之前已经成功生成过结果就直接读取缓存不再重复调用模型。对需要重试的任务也要设最大重试次数避免死循环式重试。# 先查缓存再请求 cache_key hash((model, prompt_text)) if cache_key in result_cache: return result_cache[cache_key] result call_api(payload) result_cache[cache_key] result save(result, foutputs/{task_id}.json)6.3 批量任务目录规划批量任务的输入、输出、日志建议分开管理结构固定下来。这样出了问题能快速定位是哪个任务、哪次请求、消耗了多少 Token。project/ ├── inputs/ │ └── batch_001.jsonl ├── outputs/ │ ├── batch_001_result.jsonl │ └── batch_001_failed.jsonl ├── logs/ │ └── token_audit.jsonl └── config/ └── batch_config.json7. 常见误区与排查方法问题现象可能原因排查方式解决思路每次请求都很慢上下文过长输入 Token 太多查看日志中 prompt_tokens 数量和耗时裁剪上下文保留摘要和最近几轮账单上涨明显输出 Token 过多或重试次数太频繁按日期统计 total_tokens查看重试率限制 max_tokens增加缓存和失败重试限制回答质量不稳定上下文里无关内容太多干扰模型判断对比精简上下文前后的任务完成率精简 system prompt按需注入参考资料响应内容注水严重max_tokens 设置过大模型生成过多冗余内容查看单次输出的 completion_tokens 分布按任务类型设置不同的最大输出长度批量任务成本超预算没有做小样本成本测试就全量执行检查批次日志中的总 Token 消耗每次批量任务先跑 50 条样本估算API 调用频繁报错并发过高触发限流查看服务端返回的状态码和限流信息降低并发数加入退避重试策略上下文窗口超限历史消息和参考资料累积过多查看报错信息和请求前的 Token 估算使用摘要压缩长对话按需加载参考资料排查 Token 相关问题时最重要的就是日志。如果每次请求都记录了 prompt_tokens、completion_tokens、耗时和状态大部分问题都可以在几分钟内定位。没有日志的情况下只能凭感觉猜效率和准确率都会差很多。8. 最佳实践把 Token 当作成本信号而不是 KPI8.1 先定业务指标再定技术指标做任何 LLM 功能之前先写清楚业务指标任务成功率要到多少、单次响应时间上限是多少、单位任务成本不超过多少。业务指标定了再反推需要怎么控制 Token。不要把“Token 用得少”本身当作目标它的价值要体现在成本和延迟上。8.2 每次变更做小样本对比无论是改 system prompt、换模型、调整上下文策略都不要直接全量上线。保留一个对比集先跑 50 到 100 条样本对比任务完成率、有效输出密度和 Token 消耗。用数据决定保留还是回滚。8.3 为输入和输出做结构化记录不仅要在日志里记录 Token 数据还要记录输入内容和输出内容。这样后续复盘质量问题时能把 Token 消耗和实际效果关联起来。涉及敏感业务数据时日志要做脱敏处理避免把用户隐私数据直接写进文本日志。8.4 保留一套最小可用配置一个项目里至少保留一套“最少 Token 也能跑通”的配置精简的 system prompt、较短的上下文策略、适中的 max_tokens。这套配置用做性能基准。任何优化如果比这套配置效果更差就说明优化方向不对。8.5 注意数据合规和隐私边界调用云端大模型 API 时输入内容会离开本地环境。涉及用户隐私、商业机密、未公开数据时要提前确认是否允许发送到第三方服务。对敏感字段做脱敏、加密或者改用本地部署模型。合规不是上线后补救的事而是在设计阶段就要考虑的约束条件。8.6 定期清理和复盘LLM 项目迭代很快提示词、上下文策略、模型配置都会不断变化。建议每月做一次 Token 使用复盘哪些请求的 Token 消耗明显偏高、哪些任务的单次成本在上涨、有没有已经不需要的冗余配置。这种复盘不需要花太多时间但对控制成本很有帮助。回到微软那句“Tokenmaxxing Is Not What We Are Optimizing For”。它真正提醒我们的是在大模型应用开发里技术指标永远要服务于业务结果。Token 是成本信号是性能信号是排查问题的抓手但它不是产品价值本身。建议你从今天开始做一件事把自己项目里的请求日志翻出来看看 total_tokens、任务完成率和单位任务成本这三组数据。如果只有 Token 数据没有业务结果数据那这个观测体系本身就是偏的。先从日志补起再逐步把指标对齐到业务目标上。这条路走通之后你会发现很多成本问题和体验问题其实在根源上是一样的。