在大模型落地应用中，Token 消耗往往是最直接的运营成本。以下是经过实际验证的优化方法，按实施难度排序：
1. Prompt 压缩
删除冗余的修饰词、重复示例和礼貌性用语。将系统提示词从 500 字精简到 100 字，通常不会降低效果。使用符号替代自然语言指令（如用 JSON 格式代替长段落描述）。
2. 上下文窗口管理
不要无限累积对话历史。采用滑动窗口保留最近 3-4 轮对话，或让模型每 10 轮生成一次摘要，用 200 字的摘要替代 2000 字的历史记录。长文档务必使用 RAG 分段检索，而非全量输入。
3. 大小模型路由
简单任务（格式转换、关键词提取、是非判断）使用轻量级模型（如 GPT-3.5、Llama-3-8B），仅复杂推理调用大模型。通过轻量级分类器自动分流，通常可节省 50%-70% 成本。
4. 严格限制输出长度
在请求参数中设置 max_tokens，并在 Prompt 中明确要求字数（如"回复不超过 50 字"）。模型生成 100 字和生成 1000 字的成本相差 10 倍，事后截断无法节省已产生的费用。
5. 语义缓存
对高频重复查询（如客服 FAQ、代码规范解释），在应用层建立向量缓存。新请求先与缓存比对，相似度 >0.95 直接返回历史结果，无需调用 API。适用于 30% 以上的重复性咨询场景。
6. 批量处理（Batching）
将多条独立请求合并为一次调用，让单条 Prompt 处理多条数据（如"请分析以下 5 条用户评论的情绪"），平摊 System Prompt 的开销。或使用厂商提供的 Batch API，通常有 50% 价格折扣。
7. 工具定义精简
使用 Function Calling 时，仅携带当前轮次可能使用的工具，删除冗余的枚举值和参数描述。工具定义也会计入 Token，过多无用工具可能浪费 20% 以上的输入 Token。
8. 预过滤机制
在请求发送前进行规则过滤：拦截空输入、超长文本（>8K 先切分）、测试用的重复字符。避免为明显的无效请求付费。
实战参考：某电商客服系统通过"小模型意图识别 + 大模型精准生成 + 语义缓存"三层架构，将月均 Token 消耗从 2.3 亿降至 4000 万，响应延迟从 2.1s 降至 0.8s。
优化原则：先用 Token 计数工具分析消耗分布，优先优化占比最高的环节（通常是输入上下文过长），避免过早优化带来的复杂度。