在前面几篇里,我们把企业大模型应用从 0 搭到了「能跑生产」:
- 有 DeepSeek + RAG 的企业知识库;
- 接入了 钉钉 / 企业微信 的企业助手;
- 有 多轮对话 + 工具调用 的企业智能助理;
- 用 LangChain / LlamaIndex 做了工作流编排;
- 甚至已经搭好了 多智能体中台 + 能力市场 + 监控告警。
但只要一上线,技术团队和老板都很快会问两个问题:
- 为什么越来越慢?
- 为什么这么贵?
本篇就聚焦一件事:
在不明显牺牲效果的前提下,系统性地优化 大模型推理性能 ,并把 成本控制 在一个可接受、可预测的范围内。
文章会从「监控 → 请求级优化 → 架构级优化 → 模型级优化 → 预算治理」几个层次展开,给出可直接落地的策略和代码骨架。
一、先算清楚:你的大模型钱都花在了哪里?
在企业场景里,大模型推理成本主要由三个维度构成:
-
Token 维度成本
- 输入 Prompt 长度(历史对话 + 上下文 + 系统提示词)
- 输出内容长度(回答字数、格式化程度)
- 不同模型的单价($/1k tokens)
-
调用次数维度成本
- 日均调用次数(用户规模 × 使用频次)
- 是否有重复问题 / 重复场景
- 是否存在「可以不用大模型却用上了」的情况
-
架构与模型维度成本
- 是否使用了合适大小的模型(大材小用 vs. 能力不足)
- 是否有缓存、批处理、多模型路由
- 是否利用了量化、本地部署等手段
一个典型企业的「惊吓时刻」通常是这样的:
- 只做了简单 FAQ + RAG;
- 没做任何监控与优化;
- 月底一看账单,几万块钱就没了。
所以,在谈如何省钱之前,先把钱烧到哪里搞清楚。
二、可观测是降本第一步:必须先有一套"成本仪表盘"
在你已有的 Orchestrator / 工作流入口层,建议统一打这几类指标:
-
Token 指标
- 输入 tokens(prompt_tokens)
- 输出 tokens(completion_tokens)
- 总 tokens(total_tokens)
- 按:模型 / 场景 / Agent / 部门 分维度统计
-
性能指标
- P50 / P95 延迟(毫秒)
- 各关键节点(RAG 检索、LLM 推理、工具调用)的耗时
-
质量 / 稳定性指标
- 错误率(网络错误、超时、限流)
- 重试率(retry)
- 缓存命中率(response 缓存 / 检索缓存 / 工具缓存)
-
费用估算
- 按模型估算 /小时、/天、$/月
- 按场景估算成本占比(HR / 客服 / 采购等)
有了这些,你才能:
- 找出 top N 高成本场景;
- 识别「最耗时节点」;
- 定期做「节流项目」评估。
如果前几篇你已经用 Prometheus + Grafana 建了监控,这一层只是在原有基础上多加几条指标和告警规则而已。
三、请求级优化:先砍掉"不必要的 token"
这一层是最立竿见影、工程量也最小的一层。
3.1 精简 Prompt:从「小说式」变成「指令式」
常见问题:
- 系统提示词里写了大段场景描述、人格设定;
- 用非常冗长的自然语言约束输出格式;
- 不同场景复用一个"万能 Prompt",导致每次都在传一大堆无关内容。
优化思路:
-
按场景拆模板
HR、客服、采购分别有自己的 Prompt 模板,不要一个模板打天下。
-
尽量结构化而不是散文式
例如,用「角色 + 规则 + 输入字段」三段式,而不是"你现在是一个 XX 助手......"写一大堆。
-
能用系统层约束的就别在用户 Prompt 里啰嗦
如要求「不要编造」「少于 200 字」,集中写在系统消息中。
实践中,精简 Prompt 往往可以把输入 Token 减少 30%~60%,而回答质量并不会明显下降,甚至因为更明确反而更稳定。
3.2 管理历史对话:摘要压缩,而不是"全量回放"
多轮对话场景里,最常见的 token 黑洞是:
把整段 N 轮对话原样加在 messages 里发给模型。
问题在于,大部分早期对话在当前轮的作用非常有限,却一直占着 Token 预算。
可行的做法:
- 只保留最近 N 轮原文(例如 3~5 轮);
- 更早的对话用「概要摘要」形式存在:
- 在后台按需调用一次 LLM,将早期对话压缩成不超过 100~200 字的要点;
- 后续对话只带这段摘要 + 最近几轮原文。
这样可以让多轮对话的输入 Token 始终控制在一个可预期的范围内(例如 300~600 tokens),避免线性膨胀。
3.3 裁剪无关字段:传给 LLM 的越少越好
大模型并不需要知道所有上下文字段:
- 用户档案:几十个字段中,真正跟当前问题相关的可能只有部门、岗位、工龄;
- 订单信息:真正关心的可能只有状态、金额、时间,而不是一整条 JSON。
在进入 LLM 前,可以用一个「字段白名单」做一次裁剪:
- HR 场景:只保留
department / level / hire_date; - 采购场景:只保留
amount / currency / supplier / category。
这一步很容易被忽视,但在大量调用场景下,累积节省的 token 和序列长度会非常可观。
四、架构级优化:缓存 + 批处理,直接砍掉大头浪费
当你已经有了多个场景、多个 Agent、多个工作流之后,最能直接省钱的,往往是「重复调用」与「碎片化请求」。
4.1 三类缓存,优先级从高到低
-
响应缓存(LLM Response Cache)
- 适用:FAQ 问答、制度条款解释、固定政策说明。
- 策略:对「问题归一化」后做缓存键,例如:
- 去除空格、标点变体;
- 做意图归类 / 关键词提取;
- 注意:带强时效性、强个性化的数据(如余额、订单状态)不要直接缓存完整答案。
-
检索缓存(RAG Retrieval Cache)
- 适用:相同问题命中的文档片段通常相同的场景。
- 策略:对查询文本做 embedding 前的归一化,把向量检索结果缓存起来:
- 节省 embedding 开销;
- 避免重复向量召回。
-
工具调用缓存(Tool Result Cache)
- 适用:短时间内重复查询的系统,如订单状态、工单状态。
- 策略:TTL 型缓存(例如 30~300 秒),在容忍的数据延迟范围内大幅减少下游系统调用以及随后的 LLM 推理。
按照经验,在 FAQ / 制度问答类场景,开启合理的缓存后,可以做到:
- 调用次数下降 30~70%;
- 整体 LLM Token 消耗下降 30~50%。
4.2 批处理:把 N 次调用变成 1 次
一些业务场景不是「人机对话」,而是批量任务:
- 批量发票识别与报销规则校验;
- 批量简历筛选;
- 批量政策条款检查。
这类场景如果用「逐条请求 LLM」的方式来做,非常浪费:
- 每条任务都要支付 Prompt 成本;
- 每条任务都要承受一次网络往返延迟。
解决方式:
- 把同类任务合在一条 Prompt 中,用「列表 + 标号」形式输入;
- 输出时要求模型用结构化格式(比如 JSON 数组)返回。
例如:
你是报销审核助手,请依次判断下列发票是否符合《出差报销制度》第 X 版规定。
【制度摘要】
...
【待审核发票列表】
1. 发票金额:500 元;类型:餐饮;日期:2025-01-01;备注:晚餐
2. 发票金额:3000 元;类型:住宿;日期:2025-01-02;备注:酒店
...
请按如下 JSON 数组返回结果:
[
{"id": 1, "pass": true/false, "reason": "..."},
...
]
一个 10 条的批次,token 成本往往只略高于单条的 2~3 倍,但单位任务成本直接下降 70~90%。
五、模型级优化:选对模型,比一味"上大模型"更重要
5.1 多模型路由:简单任务不要用"核弹"
现实中,大量问题并不需要最强模型:
- FAQ 问答、简单流程说明;
- 内容润色、短文摘要;
- 简单分类、标签推荐。
可以设计一套简单的「多模型路由」规则:
- 通过关键字、意图识别、历史表现来判断任务复杂度;
- 简单任务路由到 小模型 / 便宜模型;
- 复杂任务(涉及严肃合规、复杂推理)再用 大模型 / 更强推理模型。
如果你之前一直只用一个大模型,把其中 30~50% 的简单请求迁移到小模型上,往往能立刻节约 30~60% 的总体费用,而体感质量变化不大。
5.2 本地部署与量化:算力够,就换"自用电表"
对于调用量大、对延迟敏感、对数据安全要求高的企业,使用自建/专有模型是一个必然趋势:
- 选择合适大小的开源模型(7B/14B 等)做私有部署;
- 结合 4-bit/8-bit 量化、推理引擎(TensorRT、vLLM 等);
- 通过规模效应摊薄 GPU 成本。
注意:
- 本地部署不是为了"追求极致性能",而是为了「在稳定吞吐量下,用更低边际成本支撑业务」;
- 在调用量较小、算力资源紧张时,盲目自建反而成本更高。
5.3 专项微调 vs. RAG:别急着全场景微调大模型
很多团队一上来就想「微调一个属于自己的大模型」,但实践中往往是:
- 数据不够干净,标注不足;
- 评估体系不完善,很难客观判断「微调前后到底有没有提升」;
- 成本和风险远高于即时收益。
一个务实的策略是:
- 尽可能用 RAG + 精细 Prompt 解决 80% 的问题;
- 只有在以下场景才考虑微调:
- 高度结构化、模式稳定的输出(如合同条款分类、模板化文本生成);
- 高频、刚需、对效果极其敏感的核心业务。
六、预算与治理:从"无限刷卡"到"按部门记账"
最后,所有优化手段如果没有被纳入一个清晰的「预算与治理」框架,很容易在后期失控。
6.1 部门、场景、能力三个维度的"账单视图"
建议每个月产出一份类似这样的报表:
| 维度 | Token 消耗 | 估算费用 ($) | 调用次数 | 缓存命中率 | 说明 |
|---|---|---|---|---|---|
| HR 场景 | 100 万 | 140 | 2,000 | 45% | 请假/报销问答 |
| 客服场景 | 300 万 | 420 | 5,000 | 55% | 订单/物流咨询 |
| 采购工作流 | 80 万 | 112 | 800 | 35% | 审批+合同 |
| 通用写作助手 | 50 万 | 70 | 500 | 10% | 邮件/汇报 |
配合:
- 每部门的预算上限;
- 每个场景的优化计划;
- 每个能力(Agent/工具)的成本评估。
6.2 动态预算与自动化"刹车"
在监控系统中设置:
-
当某个场景的小时花费超过某个阈值(比如 2× 过去 7 日平均),触发:
- 告警通知到 AI 运维群;
- 自动将该场景降级为"低成本模式"(如强制使用小模型、关闭部分上下文)。
-
当某个部门的月度预算即将耗尽(比如超过 80%):
- 通知部门负责人;
- 提示是否需要优化场景 / 追加预算;
- 或对非关键任务暂时限流。
七、总结:把「大模型账单」从不可控变成可设计
这篇文章从实战出发,把「大模型推理性能与成本优化」拆成了几个互相配合的层次:
- 可观测层:先把 Token / 延迟 / 错误 / 成本变成看得见的指标;
- 请求级层:精简 Prompt、管理对话历史、裁剪上下文字段,立刻节省 30~60% Token;
- 架构级层:缓存、批处理、多场景共用结果,砍掉大部分重复与碎片化调用;
- 模型级层:多模型路由、本地量化、慎重微调,让"用好模型"而不是"用最大模型";
- 治理层:预算、告警、配额、账单,把技术手段纳入企业管理体系。
如果你已经有了前几篇搭好的那套 DeepSeek + RAG + 工作流 + 多智能体中台,那么本篇的内容完全可以在 不大改架构的前提下逐步落地:
- 先做监控与简单预算;
- 再做 Prompt 和上下文优化;
- 然后引入缓存与路由策略;
- 最后根据调用量和算力条件,决策本地部署与模型微调。
这样一步步下来,你会发现:
大模型从一个「不敢多用的高端玩具」,变成了「可以算账、能控成本、敢放心规模化上生产」的基础设施。