省钱又提效大模型Token优化与减少使用技巧全指南系统整理 Token 优化的技巧、策略与工程实践帮助你在保证输出质量的前提下最大化降低 Token 消耗与成本。一、为什么 Token 优化如此重要在大规模 AI 应用中60-80% 的 LLM 调用成本来自重复的系统提示词。每次调用 API 时相同的上下文被反复处理、相同的 Token 被反复计费。随着 Agentic AI智能体的普及单次任务可能涉及多轮工具调用Token 消耗呈指数级增长。Token 优化的核心目标不是省钱这么简单而是实现成本、质量与性能的三方平衡。图Token 优化的三层架构——从 Prompt 到 Context 再到 Harness二、Prompt 层面优化Prompt Engineering2.1 精简系统提示词原理系统提示词System Prompt在每次请求中都会被发送是最大的固定开销。技巧去除冗余描述用简洁的指令替代啰嗦的解释。例如回答简洁不超过3句话比请你用尽可能简短的语言来回答我的问题每句话都要精炼总体不要超过三句话节省约 60% 的 Token使用结构化格式用编号列表、缩写代替长段落描述避免重复约束不要在系统提示和用户消息中重复相同的规则定期审计使用tiktoken等工具测量系统提示的 Token 数定期精简# 示例精简前后对比# 精简前 (~150 tokens)system_prompt 你是一个非常专业的代码审查助手。你需要仔细阅读用户提供的代码 从代码质量、安全性、性能等多个维度进行全面的审查。 对于每个发现的问题你需要给出具体的改进建议。 请用中文回答并且保持专业和友好的语气。 # 精简后 (~40 tokens)system_prompt 你是代码审查助手。审查维度质量/安全/性能。 输出格式问题 改进建议。中文回答。 2.2 使用 Few-Shot 示例替代长指令原理与其用 200 个 Token 描述期望的输出格式不如用 1-2 个精炼的示例。技巧示例要短小精悍覆盖核心格式要求优先使用输出格式示例而非输入处理示例示例中的 Token 数应远少于被替代的指令 Token 数2.3 控制输出长度原理输出的每一个 Token 都要付费控制输出长度是直接的省钱手段。技巧在提示词中明确限制输出长度不超过200字/列出3个要点设置 API 的max_tokens参数防止模型过度生成使用 JSON mode / Structured Output 强制结构化输出避免冗余文本对于分类/提取任务要求输出标签而非完整句子2.4 选择高效的语言表达原理不同语言的 Token 效率差异巨大。技巧英文通常比中文更省 Token大多数模型的分词器对英文优化更好同样的语义内容英文通常只需中文 50-70% 的 Token如果业务允许考虑使用英文作为系统提示语言避免使用特殊符号、Emoji每个 Emoji 可能消耗 1-3 个 Token使用常见词汇而非生僻词分词器对高频词有更好的压缩三、上下文管理优化Context Engineering3.1 上下文压缩原理不传输完整的对话历史只提炼关键信息。技巧滑动窗口只保留最近 N 轮对话丢弃更早的内容摘要压缩用 LLM 将早期对话压缩为摘要只保留摘要 最近几轮完整对话关键信息提取从对话中提取用户偏好、核心需求、关键结论以结构化形式传递# 传统方式每次发送完整历史 (~5000 tokens) messages [msg1, msg2, msg3, msg4, msg5, msg6, msg7, msg8, ...] # 压缩后摘要 最近2轮 (~800 tokens) messages [ {role: system, content: 对话摘要用户需要一款7000元以内的编程笔记本偏好轻薄长续航...}, {role: user, content: 最近两轮对话...}, {role: assistant, content: ...} ]效果MemoryLake 等技术通过智能记忆压缩在生产场景中Token 成本降低高达 91%。图上下文压缩效果对比——从 5000 tokens 到 800 tokens3.2 懒加载上下文Lazy Loading原理只加载当前任务需要的工具定义和上下文无关内容一律不加载。技巧工具按需加载用户问笔记本推荐时只加载产品搜索、价格对比工具不加载天气、日历等无关工具文档按需检索使用 RAG 检索最相关的文档片段而非将整个知识库塞入上下文分层上下文将上下文分为必要和可选优先发送必要部分# 传统方式加载所有工具定义 (~3000 tokens)tools[search_tool,price_tool,review_tool,weather_tool,calendar_tool,...]# 懒加载只加载相关工具 (~500 tokens)toolsselect_relevant_tools(user_query推荐笔记本,all_toolstools)# → [search_tool, price_tool, review_tool]3.3 RAG 检索优化原理RAG检索增强生成是减少上下文 Token 的利器但检索质量直接影响效果。技巧控制检索片段数量通常 3-5 个高质量片段优于 20 个低质量片段设置片段长度上限每个检索片段控制在 200-500 Token重排序Reranking先用向量检索召回候选再用精排模型筛选最相关的 Top-K元数据过滤利用文档元数据时间、类别、来源预过滤减少无效检索3.4 智能记忆系统原理用外部存储替代上下文中的历史信息按需召回。技巧短期记忆当前会话的关键信息存储在内存中长期记忆用户偏好、历史结论存储在向量数据库中共享记忆多 Agent 实例共用记忆池如联想龙虾湖方案避免重复调用四、模型路由与选择优化4.1 模型路由Model Routing原理不同任务复杂度需要不同能力的模型用高端模型处理简单任务是极大的浪费。技巧简单任务信息查询、格式转换、简单分类→ 小模型GPT-4o-mini / Claude Haiku中等任务摘要、翻译、对比分析→ 中等模型GPT-4o / Claude Sonnet复杂任务多步推理、代码生成、创意写作→ 大模型GPT-4.1 / Claude Opus / o3任务类型示例推荐模型Token 成本比简单分类垃圾邮件检测Mini/Haiku1x信息提取从文本中提取关键信息Medium/Sonnet3-5x复杂推理多步数学推理Large/Opus15-30x图模型路由策略——根据任务复杂度选择合适模型4.2 级联策略Cascade原理先用廉价模型尝试信心不足时再升级到更强模型。技巧第一轮小模型处理评估输出质量/置信度第二轮如果质量不达标自动升级到中等模型第三轮如果仍不达标使用大模型兜底可结合logprobs或独立评分模型判断输出质量defcascade_call(query,complexityauto):ifcomplexitysimpleor(complexityautoandis_simple(query)):resultcall_model(query,modelmini)ifquality_check(result):# 质量达标则返回returnresult# 降级到更强模型resultcall_model(query,modelsonnet)ifquality_check(result):returnresult# 最终兜底returncall_model(query,modelopus)4.3 模型微调替代长提示原理将系统提示中的规则、格式要求通过微调烧录到模型中减少每次请求的输入 Token。技巧适用于固定格式的任务JSON 输出、特定领域问答微调后系统提示可从 2000 Token 缩减到 200 Token权衡微调有训练成本适合高频调用的场景五、缓存策略Caching5.1 Prompt Caching提示词缓存原理缓存 Transformer 注意力机制中的 KV 矩阵避免重复计算。相同前缀的请求可以复用已计算的 KV Cache。效果Anthropic Claude缓存命中的 Token 价格是普通价格的10%降低 90%OpenAI GPT-4o缓存命中 Token 按50%价格计费首字节延迟减少高达85%图Prompt Caching 原理——首次请求生成 KV Cache后续请求复用缓存Anthropic 实践importanthropic clientanthropic.Anthropic()responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens1024,system[{type:text,text:LARGE_SYSTEM_PROMPT,cache_control:{type:ephemeral}# 标记为可缓存}],messages[{role:user,content:user_message}])# 查看缓存使用情况usageresponse.usageprint(f缓存读取:{usage.cache_read_input_tokens}tokens)print(f缓存创建:{usage.cache_creation_input_tokens}tokens)OpenAI 实践# OpenAI 自动缓存无需特殊标记# 条件前缀完全一致 至少 1024 tokens# 有效期约 5-10 分钟空闲后过期responseclient.chat.completions.create(modelgpt-4o,messages[{role:system,content:SYSTEM_PROMPT},# 保持不变{role:user,content:user_message}# 动态部分])关键规则前缀必须完全一致任何修改都会导致缓存失效动态内容放后面将静态系统提示放前面动态用户消息放后面分层缓存静态内容 → 会话级内容 → 动态内容确保最大前缀复用Anthropic 缓存有效期 5 分钟注意批处理任务的节奏5.2 语义缓存Semantic Cache原理识别语义相似的问题直接复用之前的回答完全跳过 LLM 调用。技巧使用向量数据库存储历史 QA 对新问题先做向量检索相似度超过阈值则直接返回缓存答案适合高频重复问题的场景客服 FAQ、产品推荐defsemantic_cached_call(query,threshold0.92):# 1. 向量化查询query_embeddingembed(query)# 2. 在缓存中搜索相似问题cachedvector_db.search(query_embedding,top_k1)# 3. 相似度达标则直接返回ifcachedandcached.similaritythreshold:returncached.answer# 0 Token 消耗# 4. 未命中调用 LLM 并缓存结果answercall_llm(query)vector_db.insert(query_embedding,answer)returnanswer注意语义缓存的相似度阈值需要根据场景调试——太高无法复用太低会返回不准确答案。5.3 缓存友好的提示词设计策略将动态内容日期、用户 ID、计数器移到消息末尾而非嵌入系统提示中对 JSON 字段排序sort_keysTrue确保相同数据生成相同字符串监控缓存命中率持续优化提示词结构六、工程架构优化6.1 输出格式控制技巧JSON Mode / Structured Output强制结构化输出避免冗余的自然语言包装Tool Calling / Function Calling用工具调用的方式获取结构化数据而非让模型生成自由文本限制输出 Token始终设置合理的max_tokens上限# 使用 Structured Output 替代自由文本responseclient.beta.chat.completions.parse(modelgpt-4o,messages[{role:user,content:分析这段文本的情感}],response_formatSentimentAnalysis,# Pydantic 模型)# 输出{sentiment: positive, confidence: 0.92, keywords: [好, 优秀]}# 而非经过仔细分析我认为这段文本的情感倾向是积极的...6.2 并发与批处理优化技巧并行调用独立的 LLM 调用并发执行减少总等待时间批量处理将多个小任务合并为一次大调用注意上下文窗口限制流式输出使用 streaming 模式减少用户感知延迟6.3 中间件与代理层技巧Token 计数中间件在调用 LLM 之前先计算预估 Token 数超过阈值则触发压缩请求拦截器自动检测并移除重复的上下文内容成本监控面板实时追踪每次调用的 Token 消耗和成本classTokenAwareMiddleware:defbefore_call(self,messages,max_budget100000):total_tokenscount_tokens(messages)iftotal_tokensmax_budget:messagescompress_context(messages,targetmax_budget)logger.warning(f上下文压缩:{total_tokens}→{count_tokens(messages)}tokens)returnmessages6.4 本地部署替代方案原理对于高频、敏感或大规模场景本地部署可消除按 Token 计费的成本。技巧开源模型使用 Llama、Qwen、DeepSeek 等开源模型本地部署量化压缩使用 4-bit/8-bit 量化降低显存需求GGUF、AWQ、GPTQ轻量推理框架Ollama、vLLM、llama.cpp 等支持在消费级硬件运行混合部署简单任务用本地模型复杂任务用云端大模型方案适用场景成本特点纯云端 API低频、多变任务按量付费灵活但单价高本地部署高频、固定任务一次性投入长期边际成本趋近于零混合部署多样化任务兼顾灵活性和成本控制七、Agent 场景专项优化7.1 工具调用优化精简工具描述工具的 name 和 description 也会消耗 Token保持简洁工具结果截断工具返回的冗长结果应截断或摘要后再传给模型避免无效调用在调用工具前先用规则引擎或小模型判断是否真的需要调用7.2 多 Agent 协作优化Agent 间传递摘要而非全文Agent A 的输出经摘要后传给 Agent B共享记忆层多个 Agent 实例共用外部记忆避免重复加载上下文任务分解粒度控制过细的子任务会导致过多的 Agent 间通信开销7.3 推理链Chain of Thought优化只在必要时使用 CoT简单任务不需要推理链直接输出答案使用轻量级 CoT想一下比请一步一步详细思考每个步骤省很多 Token模型内置推理使用 o1/o3 等内置推理模型无需在提示词中写推理指令八、成本监控与持续优化8.1 建立监控体系dataclassclassTokenMetrics:total_input_tokens:int0total_output_tokens:int0cached_tokens:int0total_cost_usd:float0.0request_count:int0propertydefcache_hit_rate(self):returnself.cached_tokens/max(self.total_input_tokens,1)propertydefavg_cost_per_request(self):returnself.total_cost_usd/max(self.request_count,1)8.2 持续优化清单每月审计系统提示词精简冗余内容监控缓存命中率低于 50% 时排查原因分析高成本调用识别可路由到小模型的请求检查上下文窗口利用率是否存在大量浪费评估语义缓存的覆盖率和准确率对比不同模型在相同任务上的 Token 消耗差异九、优化效果速查表优化手段预期节省实施难度适用场景Prompt 精简20-40%⭐ 低所有场景上下文压缩40-90%⭐⭐ 中长对话、多轮 AgentPrompt Caching50-90%⭐ 低大系统提示、高频调用语义缓存30-80%⭐⭐⭐ 高高重复问题场景模型路由40-70%⭐⭐ 中多样化任务级联策略30-60%⭐⭐⭐ 高任务复杂度差异大懒加载30-50%⭐⭐ 中多工具 Agent本地部署80-100%⭐⭐⭐⭐ 很高高频固定任务结构化输出20-40%⭐ 低提取/分类任务RAG 检索优化30-60%⭐⭐ 中知识库问答十、总结三层优化体系┌─────────────────────────────────────────────────┐ │ Harness Engineering运行结构 │ │ 模型路由 · 级联策略 · 缓存中间件 · 成本监控 │ ├─────────────────────────────────────────────────┤ │ Context Engineering信息组织 │ │ 上下文压缩 · 懒加载 · RAG优化 · 智能记忆 │ ├─────────────────────────────────────────────────┤ │ Prompt Engineering任务表达 │ │ 提示精简 · Few-Shot · 输出控制 · 语言选择 │ └─────────────────────────────────────────────────┘Token 优化不是单一手段而是Prompt → Context → Harness 三层协同的系统工程。从输入控制到上下文组织再到运行时治理每一层都有对应的优化空间。关键是根据自身业务场景选择投入产出比最高的优化组合并在成本与质量之间找到最佳平衡点。参考来源Prompt Caching: 让LLM Token成本降低10倍Agentic AI 4个设计技巧告别Token浪费优化Agent上下文管理降Token消耗Prompt缓存技术深度解析让LLM调用成本降低90%的工程实践从 LLM 的角度聊 Prompt、Context 和 HarnessKotaemon优化Token消耗降低成本40%Langchain-Chatchat如何降低大模型Token消耗
省钱又提效！大模型Token优化与减少使用技巧全指南
省钱又提效大模型Token优化与减少使用技巧全指南系统整理 Token 优化的技巧、策略与工程实践帮助你在保证输出质量的前提下最大化降低 Token 消耗与成本。一、为什么 Token 优化如此重要在大规模 AI 应用中60-80% 的 LLM 调用成本来自重复的系统提示词。每次调用 API 时相同的上下文被反复处理、相同的 Token 被反复计费。随着 Agentic AI智能体的普及单次任务可能涉及多轮工具调用Token 消耗呈指数级增长。Token 优化的核心目标不是省钱这么简单而是实现成本、质量与性能的三方平衡。图Token 优化的三层架构——从 Prompt 到 Context 再到 Harness二、Prompt 层面优化Prompt Engineering2.1 精简系统提示词原理系统提示词System Prompt在每次请求中都会被发送是最大的固定开销。技巧去除冗余描述用简洁的指令替代啰嗦的解释。例如回答简洁不超过3句话比请你用尽可能简短的语言来回答我的问题每句话都要精炼总体不要超过三句话节省约 60% 的 Token使用结构化格式用编号列表、缩写代替长段落描述避免重复约束不要在系统提示和用户消息中重复相同的规则定期审计使用tiktoken等工具测量系统提示的 Token 数定期精简# 示例精简前后对比# 精简前 (~150 tokens)system_prompt 你是一个非常专业的代码审查助手。你需要仔细阅读用户提供的代码 从代码质量、安全性、性能等多个维度进行全面的审查。 对于每个发现的问题你需要给出具体的改进建议。 请用中文回答并且保持专业和友好的语气。 # 精简后 (~40 tokens)system_prompt 你是代码审查助手。审查维度质量/安全/性能。 输出格式问题 改进建议。中文回答。 2.2 使用 Few-Shot 示例替代长指令原理与其用 200 个 Token 描述期望的输出格式不如用 1-2 个精炼的示例。技巧示例要短小精悍覆盖核心格式要求优先使用输出格式示例而非输入处理示例示例中的 Token 数应远少于被替代的指令 Token 数2.3 控制输出长度原理输出的每一个 Token 都要付费控制输出长度是直接的省钱手段。技巧在提示词中明确限制输出长度不超过200字/列出3个要点设置 API 的max_tokens参数防止模型过度生成使用 JSON mode / Structured Output 强制结构化输出避免冗余文本对于分类/提取任务要求输出标签而非完整句子2.4 选择高效的语言表达原理不同语言的 Token 效率差异巨大。技巧英文通常比中文更省 Token大多数模型的分词器对英文优化更好同样的语义内容英文通常只需中文 50-70% 的 Token如果业务允许考虑使用英文作为系统提示语言避免使用特殊符号、Emoji每个 Emoji 可能消耗 1-3 个 Token使用常见词汇而非生僻词分词器对高频词有更好的压缩三、上下文管理优化Context Engineering3.1 上下文压缩原理不传输完整的对话历史只提炼关键信息。技巧滑动窗口只保留最近 N 轮对话丢弃更早的内容摘要压缩用 LLM 将早期对话压缩为摘要只保留摘要 最近几轮完整对话关键信息提取从对话中提取用户偏好、核心需求、关键结论以结构化形式传递# 传统方式每次发送完整历史 (~5000 tokens) messages [msg1, msg2, msg3, msg4, msg5, msg6, msg7, msg8, ...] # 压缩后摘要 最近2轮 (~800 tokens) messages [ {role: system, content: 对话摘要用户需要一款7000元以内的编程笔记本偏好轻薄长续航...}, {role: user, content: 最近两轮对话...}, {role: assistant, content: ...} ]效果MemoryLake 等技术通过智能记忆压缩在生产场景中Token 成本降低高达 91%。图上下文压缩效果对比——从 5000 tokens 到 800 tokens3.2 懒加载上下文Lazy Loading原理只加载当前任务需要的工具定义和上下文无关内容一律不加载。技巧工具按需加载用户问笔记本推荐时只加载产品搜索、价格对比工具不加载天气、日历等无关工具文档按需检索使用 RAG 检索最相关的文档片段而非将整个知识库塞入上下文分层上下文将上下文分为必要和可选优先发送必要部分# 传统方式加载所有工具定义 (~3000 tokens)tools[search_tool,price_tool,review_tool,weather_tool,calendar_tool,...]# 懒加载只加载相关工具 (~500 tokens)toolsselect_relevant_tools(user_query推荐笔记本,all_toolstools)# → [search_tool, price_tool, review_tool]3.3 RAG 检索优化原理RAG检索增强生成是减少上下文 Token 的利器但检索质量直接影响效果。技巧控制检索片段数量通常 3-5 个高质量片段优于 20 个低质量片段设置片段长度上限每个检索片段控制在 200-500 Token重排序Reranking先用向量检索召回候选再用精排模型筛选最相关的 Top-K元数据过滤利用文档元数据时间、类别、来源预过滤减少无效检索3.4 智能记忆系统原理用外部存储替代上下文中的历史信息按需召回。技巧短期记忆当前会话的关键信息存储在内存中长期记忆用户偏好、历史结论存储在向量数据库中共享记忆多 Agent 实例共用记忆池如联想龙虾湖方案避免重复调用四、模型路由与选择优化4.1 模型路由Model Routing原理不同任务复杂度需要不同能力的模型用高端模型处理简单任务是极大的浪费。技巧简单任务信息查询、格式转换、简单分类→ 小模型GPT-4o-mini / Claude Haiku中等任务摘要、翻译、对比分析→ 中等模型GPT-4o / Claude Sonnet复杂任务多步推理、代码生成、创意写作→ 大模型GPT-4.1 / Claude Opus / o3任务类型示例推荐模型Token 成本比简单分类垃圾邮件检测Mini/Haiku1x信息提取从文本中提取关键信息Medium/Sonnet3-5x复杂推理多步数学推理Large/Opus15-30x图模型路由策略——根据任务复杂度选择合适模型4.2 级联策略Cascade原理先用廉价模型尝试信心不足时再升级到更强模型。技巧第一轮小模型处理评估输出质量/置信度第二轮如果质量不达标自动升级到中等模型第三轮如果仍不达标使用大模型兜底可结合logprobs或独立评分模型判断输出质量defcascade_call(query,complexityauto):ifcomplexitysimpleor(complexityautoandis_simple(query)):resultcall_model(query,modelmini)ifquality_check(result):# 质量达标则返回returnresult# 降级到更强模型resultcall_model(query,modelsonnet)ifquality_check(result):returnresult# 最终兜底returncall_model(query,modelopus)4.3 模型微调替代长提示原理将系统提示中的规则、格式要求通过微调烧录到模型中减少每次请求的输入 Token。技巧适用于固定格式的任务JSON 输出、特定领域问答微调后系统提示可从 2000 Token 缩减到 200 Token权衡微调有训练成本适合高频调用的场景五、缓存策略Caching5.1 Prompt Caching提示词缓存原理缓存 Transformer 注意力机制中的 KV 矩阵避免重复计算。相同前缀的请求可以复用已计算的 KV Cache。效果Anthropic Claude缓存命中的 Token 价格是普通价格的10%降低 90%OpenAI GPT-4o缓存命中 Token 按50%价格计费首字节延迟减少高达85%图Prompt Caching 原理——首次请求生成 KV Cache后续请求复用缓存Anthropic 实践importanthropic clientanthropic.Anthropic()responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens1024,system[{type:text,text:LARGE_SYSTEM_PROMPT,cache_control:{type:ephemeral}# 标记为可缓存}],messages[{role:user,content:user_message}])# 查看缓存使用情况usageresponse.usageprint(f缓存读取:{usage.cache_read_input_tokens}tokens)print(f缓存创建:{usage.cache_creation_input_tokens}tokens)OpenAI 实践# OpenAI 自动缓存无需特殊标记# 条件前缀完全一致 至少 1024 tokens# 有效期约 5-10 分钟空闲后过期responseclient.chat.completions.create(modelgpt-4o,messages[{role:system,content:SYSTEM_PROMPT},# 保持不变{role:user,content:user_message}# 动态部分])关键规则前缀必须完全一致任何修改都会导致缓存失效动态内容放后面将静态系统提示放前面动态用户消息放后面分层缓存静态内容 → 会话级内容 → 动态内容确保最大前缀复用Anthropic 缓存有效期 5 分钟注意批处理任务的节奏5.2 语义缓存Semantic Cache原理识别语义相似的问题直接复用之前的回答完全跳过 LLM 调用。技巧使用向量数据库存储历史 QA 对新问题先做向量检索相似度超过阈值则直接返回缓存答案适合高频重复问题的场景客服 FAQ、产品推荐defsemantic_cached_call(query,threshold0.92):# 1. 向量化查询query_embeddingembed(query)# 2. 在缓存中搜索相似问题cachedvector_db.search(query_embedding,top_k1)# 3. 相似度达标则直接返回ifcachedandcached.similaritythreshold:returncached.answer# 0 Token 消耗# 4. 未命中调用 LLM 并缓存结果answercall_llm(query)vector_db.insert(query_embedding,answer)returnanswer注意语义缓存的相似度阈值需要根据场景调试——太高无法复用太低会返回不准确答案。5.3 缓存友好的提示词设计策略将动态内容日期、用户 ID、计数器移到消息末尾而非嵌入系统提示中对 JSON 字段排序sort_keysTrue确保相同数据生成相同字符串监控缓存命中率持续优化提示词结构六、工程架构优化6.1 输出格式控制技巧JSON Mode / Structured Output强制结构化输出避免冗余的自然语言包装Tool Calling / Function Calling用工具调用的方式获取结构化数据而非让模型生成自由文本限制输出 Token始终设置合理的max_tokens上限# 使用 Structured Output 替代自由文本responseclient.beta.chat.completions.parse(modelgpt-4o,messages[{role:user,content:分析这段文本的情感}],response_formatSentimentAnalysis,# Pydantic 模型)# 输出{sentiment: positive, confidence: 0.92, keywords: [好, 优秀]}# 而非经过仔细分析我认为这段文本的情感倾向是积极的...6.2 并发与批处理优化技巧并行调用独立的 LLM 调用并发执行减少总等待时间批量处理将多个小任务合并为一次大调用注意上下文窗口限制流式输出使用 streaming 模式减少用户感知延迟6.3 中间件与代理层技巧Token 计数中间件在调用 LLM 之前先计算预估 Token 数超过阈值则触发压缩请求拦截器自动检测并移除重复的上下文内容成本监控面板实时追踪每次调用的 Token 消耗和成本classTokenAwareMiddleware:defbefore_call(self,messages,max_budget100000):total_tokenscount_tokens(messages)iftotal_tokensmax_budget:messagescompress_context(messages,targetmax_budget)logger.warning(f上下文压缩:{total_tokens}→{count_tokens(messages)}tokens)returnmessages6.4 本地部署替代方案原理对于高频、敏感或大规模场景本地部署可消除按 Token 计费的成本。技巧开源模型使用 Llama、Qwen、DeepSeek 等开源模型本地部署量化压缩使用 4-bit/8-bit 量化降低显存需求GGUF、AWQ、GPTQ轻量推理框架Ollama、vLLM、llama.cpp 等支持在消费级硬件运行混合部署简单任务用本地模型复杂任务用云端大模型方案适用场景成本特点纯云端 API低频、多变任务按量付费灵活但单价高本地部署高频、固定任务一次性投入长期边际成本趋近于零混合部署多样化任务兼顾灵活性和成本控制七、Agent 场景专项优化7.1 工具调用优化精简工具描述工具的 name 和 description 也会消耗 Token保持简洁工具结果截断工具返回的冗长结果应截断或摘要后再传给模型避免无效调用在调用工具前先用规则引擎或小模型判断是否真的需要调用7.2 多 Agent 协作优化Agent 间传递摘要而非全文Agent A 的输出经摘要后传给 Agent B共享记忆层多个 Agent 实例共用外部记忆避免重复加载上下文任务分解粒度控制过细的子任务会导致过多的 Agent 间通信开销7.3 推理链Chain of Thought优化只在必要时使用 CoT简单任务不需要推理链直接输出答案使用轻量级 CoT想一下比请一步一步详细思考每个步骤省很多 Token模型内置推理使用 o1/o3 等内置推理模型无需在提示词中写推理指令八、成本监控与持续优化8.1 建立监控体系dataclassclassTokenMetrics:total_input_tokens:int0total_output_tokens:int0cached_tokens:int0total_cost_usd:float0.0request_count:int0propertydefcache_hit_rate(self):returnself.cached_tokens/max(self.total_input_tokens,1)propertydefavg_cost_per_request(self):returnself.total_cost_usd/max(self.request_count,1)8.2 持续优化清单每月审计系统提示词精简冗余内容监控缓存命中率低于 50% 时排查原因分析高成本调用识别可路由到小模型的请求检查上下文窗口利用率是否存在大量浪费评估语义缓存的覆盖率和准确率对比不同模型在相同任务上的 Token 消耗差异九、优化效果速查表优化手段预期节省实施难度适用场景Prompt 精简20-40%⭐ 低所有场景上下文压缩40-90%⭐⭐ 中长对话、多轮 AgentPrompt Caching50-90%⭐ 低大系统提示、高频调用语义缓存30-80%⭐⭐⭐ 高高重复问题场景模型路由40-70%⭐⭐ 中多样化任务级联策略30-60%⭐⭐⭐ 高任务复杂度差异大懒加载30-50%⭐⭐ 中多工具 Agent本地部署80-100%⭐⭐⭐⭐ 很高高频固定任务结构化输出20-40%⭐ 低提取/分类任务RAG 检索优化30-60%⭐⭐ 中知识库问答十、总结三层优化体系┌─────────────────────────────────────────────────┐ │ Harness Engineering运行结构 │ │ 模型路由 · 级联策略 · 缓存中间件 · 成本监控 │ ├─────────────────────────────────────────────────┤ │ Context Engineering信息组织 │ │ 上下文压缩 · 懒加载 · RAG优化 · 智能记忆 │ ├─────────────────────────────────────────────────┤ │ Prompt Engineering任务表达 │ │ 提示精简 · Few-Shot · 输出控制 · 语言选择 │ └─────────────────────────────────────────────────┘Token 优化不是单一手段而是Prompt → Context → Harness 三层协同的系统工程。从输入控制到上下文组织再到运行时治理每一层都有对应的优化空间。关键是根据自身业务场景选择投入产出比最高的优化组合并在成本与质量之间找到最佳平衡点。参考来源Prompt Caching: 让LLM Token成本降低10倍Agentic AI 4个设计技巧告别Token浪费优化Agent上下文管理降Token消耗Prompt缓存技术深度解析让LLM调用成本降低90%的工程实践从 LLM 的角度聊 Prompt、Context 和 HarnessKotaemon优化Token消耗降低成本40%Langchain-Chatchat如何降低大模型Token消耗
