AI应用省钱攻略--降低模型成本的七大策略

产品二姐

读完需要

13分钟速读仅需 5 分钟

1

引言

最近 AI 大模型上演的“上下文长度”之战确实有点热闹，我给大家整理了一个时间轴，并用图形化的方式展示出各个模型支持的上下文长度以及价格(图中黄色方块表示)。

不难看出，上下文越长，相应的成本也成倍增加。所以，对于应用开发者，与其讨论模型是否应该在长度上卷来卷去，不如今天重点讨论一下 如何压缩模型调用成本 的问题。其中的经验和方法都是几个真实案例驱动下的探索总结，囊括了目前我所知道的降低模型调用成本的方法，希望对大家有所帮助，文章较长，适合收藏。

这也是之前之前一篇文章《做大模型AI应用一定要了解的成本计算公式》的续写，新同学也推荐阅读这篇比较受欢迎的老文章。

2

概述

按照文章《一文讲清大模型AI应用架构》里定义的 AI 应用四层架构(算法算力数据层，模型层，应用层，用户层），我们能做的降本方法主要集中在模型层、应用层里。 你将收获以下内容：

1.应用层降低 LLM 调用成本方法：

• 通过问答对向量库降低模型调用次数，从而实现降本，我会通过案例讲解。

• 借用昂贵模型生成问答对，将问答对作为 RAG 知识库，将优质问答对发给便宜模型以降低成本。

• 通过压缩 prompt， 降低 token 量实现降本，我会提供相应的开源代码。

• 优化 RAG 分块以降低 token 量实现降本。

2.模型层降低 LLM 调用成本方法：

• 借用昂贵大模型微调便宜小模型。

• 做好模型分发，好钢用在刀刃上，我会分享比较成熟的模型分发工具。

• 优先调用便宜模型，逐步升级调用不同等级的模型。

最后介绍一下大模型的成本监控工具：Langchain 的 LangSimith 的监控日志。

3

应用层降低 LLM 调用成本方法

3.1

问答对向量库辅助问答，降低模型调用次数

用一张图来说明什么叫问答对向量库辅助问答，下图中红色部分就是问答对向量库的作用。

可以看出，在满足条件的情况下，系统完全可以脱离大模型完整执行一次问答。这个方法非常简单，事实上，它在大模型出来之前就很常见了。比如某个 SAAS 产品网站的帮助文档，可能用户 50%的问题都是相似的，那么产品运营人员把这些 FAQ 总结出来，存入向量数据库。下次当有用户问问题的时候，按照向量语义检索就可以找到对应答案，而无需调用大模型。

我对向量库语义检索的理解就是相当于原有 SQL 里运行了一条“

Select * from vectorDB where query like …

” ，尽管实际上向量库语义检索是通过下述方式来运行的。

在这种场景下，个人觉得 LLM 更多的作用 是大大加快了 FAQ 的生成速度，而非问答本身 。我们试着对比在有、无大模型的情况下，完善 FAQ 的流程。

不难发现，FAQ 维护的速度在 LLM 的协助下有近十倍速的提升，更重要的是这背后也意味着迭代速度，服务效率和满意度的十倍速增长。在成本方面，在每次新知识产生的时候，会有一次模型调用的峰值，之后逐步下降。我概念性地绘制这样一幅图来说明大模型成本的曲线。

不过既然问答要依赖 FAQ，那么 FAQ 自身的更新也需要注意，FAQ 的维护方式分为两种：

1.由用户反馈驱动的被动更新：比如收到用户对某个答案的负面反馈（用户对回答点踩），运营人员需要核实问答库的答案是否准确、完备。

2.有 LLM 巡检驱动的主动更新：定期将 LLM + RAG 的答案和 FAQ 的答案进行对比，相当于“巡检”，来保证 FAQ 的准确性。

当然上述方法仅在有限场景中可以达到明显降本的效果， 即：用户的问题比较集中，知识库的内容更新不会特别频繁或者更新前后差异不大 。我们目前所接触的客户中，有两个都属于这种情况。其实，只要满足客户诉求，是不是大模型真的不重要。

此外，我也有看到类似方法也被升级使用：借用昂贵模型生成问答对，将问答对作为 RAG 检索出优质内容发给便宜小模型降低成本。原作者可以借助这种方法来优化 Agent 能力，这个方法我们没有实践，不过也可以拿出来和大家分享。

3.2

借用优质问答对+RAG 的方式来优化 Agent 能力

在论文

https://arxiv.org/abs/2310.03046

中，作者使用了一个多 Agent方案进行问答的。

方案中设计了一个代码 agent 专门负责撰写调用外部 API 的代码，比如根据给定某个 API 的接口文档，让这个 agent 写出调用 API 接口的代码。下面这种图是来自原文的架构图，紫色图标是我加上去用来说明过程的标注。

接下来我按照紫色序号来讲述 agent 的具体执行过程：

1. 首先系统将用户诉求和大模型分发系统进行交互；

2. 在大模型分发时，系统首先调用便宜模型 GPT 3.5 进行撰写，写好之后执行代码，如果成功，则接口返回成功，如果不成功，接口返回错误；

3. 如果通过 GPT3.5 经过几轮还是不能返回成功，才开始调用 GPT4；

4. 一旦有返回接口成功的记录；

5. 系统就会将这次接口调用代码以及对应的用户诉求自动存入向量数据库；

6. 当下次其他用户有诉求的时候，首先从向量数据库中检索是否有类似问题；

7. 如果有类似问题，则提取出所有正确答案；

8. 然后将答案加上本次用户的 query，一并合成 prompt；

9. 将该 prompt 再发给大模型分发系统，首先调用低成本 LLM 模型，如果不能返回结果再调用高成本模型；

如此反复迭代反馈，最终可以得到一个比较能够自我进化的 code executor agent，且能迭代降低大模型使用成本。

这种场景与刚刚提到的单纯使用问答对辅助问答有两个不同的地方：

• 作者把“API 接口是否返回成功”作为一个高效的反馈，这相当于我们在 FAQ 的人工标注，达到了无人工介入即可达成目标的效果。

• 其次，作者把问答库作为一个 RAG 知识库在使用，但个人认为如果 FAQ 足够准确，问题相关度足够高，其实可以不用再发给大模型。

上述两种方法本质上是使用迭代方式构建优质问答对来降低大模型的成本，接下来就是通过压缩提示词的方式来实现降本了。

3.3

压缩提示词

首先说说这种方法的效果，以下是我自己日常使用提示词，经过压缩后文本长度压缩到原来的 70%(由 175 字压缩到 123 字) ，但模型返回答案非常相似。

这里用到的压缩神器就是微软LLM Lingua，他们开源了代码(

https://github.com/microsoft/LLMLingua

)，大家也可以直接在他们的playground 上( https://huggingface.co/spaces/microsoft/LLMLingua )将自己平时使用的提示词模板去压缩，绝对有肉眼可见的效果。

注：Lingua 有一点要吐槽的就是，当我的提示词中含有某个链接作为参考文章时，这个链接也会被压缩，导致链接无法使用，这里需要大家手动再把链接恢复一下 。

压缩提示词的方式有很多种，相关论文链接我贴在文末，但整体使用下来 Lingua 更加完善(Github 3.3K star)，而且他们的更新也比较及时，大家可以直接用在自己的应用中。

实际上所有压缩提示词的方法都是基于一个现象：自然语言中存在着大量冗余信息。Lingua 和其他压缩方法的优势在于：

1. Lingua 针对提示词中的不同部分进行了分类处理，比如提示词中的指令和提问部分信息含量高，压缩率就会低；而提示词中的 few shot 等信息含量低，压缩率就会高。

2. 压缩是采用迭代的压缩方式，而非一次性的压缩来进行的。

有兴趣的同学可以阅读原论文(

https://arxiv.org/abs/2310.05736

)，我还没有完全看懂，你可以带着我一起看。接下来看一下我们常说的 RAG 流水线中对成本影响最重要的模块：分块。

3.4

优化 RAG 分块以降低 token 量实现降本。

RAG 的方法之前有讲到，我放一张有 RAG 和无 RAG 时调用大模型的对比来简单阐述 RAG （想进一步了解 RAG 的同学推荐阅读《RAG组合拳：AGI应用走向落地的40%（上篇）》） 。

上图可以看出，RAG 本质上是将外挂知识库里检索到的资料作为上下文发给 LLM，自然而然会增长上下文的长度，同时含有部分冗余信息。而 RAG 检索到的内容是以”块”为单位的，分块可以是按照句子，也可能按照段落，也可能按照固定长度来分。那么“块”的长度很大程度上会影响上下文的长度(即 token 的长度)。

举个例子，当用户提问：xxxAPI 接口怎么写。

• 如果块按照“句子”分，RAG 检索到一个块，发给大模型的就是：句子+用户的 query。

• 如果按照“段落”分，RAG检索后发给大模型的就是：段落 + 用户的 query。

此时你就需要合理分块，从而把最合适大小的参考资料发给大模型，当然这个过程你也可以结合 Prompt 压缩来进一步降低成本。不过，需要注意的是，分块除了对成本有影响外，更多的是对准确率也会有影响，切不可仅仅为了满足成本需求而降低了准确性。

谈完应用层，接下来看看模型层可以做的降低成本方式。

4

模型层降低 LLM 调用成本方法

4.1

借用昂贵大模型微调便宜小模型

这种方法可能更适用于企业想要训练自己私有化模型的场景，但在短期内又无法准备足够数据的情况。具体实现步骤是：

1. 在产品初期，使用昂贵模型生成的优质问答对；

2. 当优质问答对积累到一定程度，用这些问答对来微调便宜模型。

3. 当便宜模型的生成质量和昂贵模型类似时，底层切换为便宜模型。

很容易看出，这种方式需要产品本身就有较多的用户使用，才能够积累非常广，或者非常垂直的数据用于微调。我甚至觉得 Coze 的海外版之所以舍得老本让大家白嫖 GPT4 和 GPT 4-Turbo，就是在采用这种策略来达到长期降低成本的目标，当然这只是猜测( Coze 的同学不要骂我，我还是经常在用 Coze )。

而在实际企业的应用场景中，更多的诉求不是像 Coze 一样训练一个通用模型，而是能得到一个便宜的垂直模型。如果企业能够发现 GPT4(昂贵)在某个领域的能力远超出小(便宜)模型，且场景比较单一，就可以采用这种方式来可达到是长期降低成本的目标( 短期内微调成本要高一些 )。

至于如何实施这个步骤，后面的文章我们展开来讲讲微调。那么既然大模型与小模型的能力不齐，自然而然有另外一个方法，就是做好不同难度的问题，交给不同模型解决，这就是模型层降本的第二类方法。

4.2

做好模型分发，好钢用在刀刃上

目前我们已经看到商业化的产品来专门做模型分发了，比较有名的是：

1. Martian:

https://withmartian.com

， 大家可以在它的 playground 上去玩一下。

2. Neutrino AI:

https://www.neutrinoapp.com

3. Aurelio AI :

https://www.aurelio.ai/semantic-router

, 开源代码: https://github.com/aurelio-labs/semantic-router

这些工具背后的原理大多是对用户问题进行语义分析，进行归类，然后按照不同模型擅长的领域来使用对应模型。听起来这种方式更多适用于不确定性较高的 to C 场景中。而在 to B 场景确定性比较高，可能混合使用三种模型就够了，那么你可以使用这些工具进行实验，为你选择模型提供一定的参考。

最后一个方法本质上也是模型分发，只是分发的方法是不断升级的过程。

4.3

优先调用便宜模型，逐步升级调用不同等级的模型

这个方法的原论文在这里：

https://huggingface.co/papers/2310.03094

。理解起来也比较简单，我借用论文中的一张图来描述。

这种方法首先会调用便宜模型(weaker LLM), 对模型的答案进行评估(论文中使用 answer consistency 指标), 如果评估通过，则使用便宜模型的答案，如果不通过，则调用昂贵模型(Stronger LLM)来回答。

不过这种方式的风险就是假使 weaker LLM 的能力特别弱，或者多少情况下问题比较复杂，那么每次都要一次调用便宜模型，昂贵模型(Stronger LLM)，那么其实成本没有降低反而升高了。

到这里，大概涵盖了目前我已知的大模型 AI 应用的降本方法，相信未来还有很多，这些方法都可以组合使用，当组合使用的时候，需要提供一个有效的工具来监控成本。

5

成本监控

主要讲讲比较完善的 Langchain 的 LangSmith 吧。成本监控包括：

1. 每次调用 LLM 的 token 数

2. 所花成本

3. 响应速度

在 LangSmith 就提供了这些功能，你可以在这里看到每次调用所花费的 token 数，响应时长，花费。当然还有基于这些基本数据的分析、图表等。

只是 LangSmith 的免费版仅允许每个月 Trace 3000 条记录，平均每天 100 条，如果纯开发可能够用了。超过这个就要付费使用了（$39/月/人），确实不便宜，如果大家有好的开源工具欢迎和我交流。

6

总结

好了，以上就是今天的内容，总结起来也很简单：

• 应用层能用向量数据库查询能解决的问题，就可以不用 LLM。

• 提示词压缩方法多，选择最合适的压缩程度，降低 token 成本。

• 模型层微调小模型自力更生或者做好模型分发。

希望大家能有所收获。最后各位老铁点赞的同时，如果有业务诉求也可以联系我们，目前的业务包含：

• 企业 AI 应用的定制开发。

• AI 应用落地加速服务(咨询，培训，方案设计，答疑，代码 review，代码交付等)。

需要商务合作公众号直接点击联系我。

---

我是关注 AI 产品的产品二姐，致力于带来丰富的 AI 学习分享、体会，欢迎你和我一起学习，如果你觉得文章有用，欢迎关注、点赞、转发。

附录 ：

压缩提示词方法相关论文

1.《Soaring from 4K to 400K: Extending LLM’s Context with Activation Beacon》

2.《EXTENDING CONTEXT WINDOW OF LARGE LANGUAGE MODELS VIA SEMANTIC COMPRESSION》

3.《Adapting Language Models to Compress Long Contexts》

4.《LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression》

5.《LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models》

6.《Unlocking Context Constraints of LLMs: Enhancing Context Efficiency of LLMs with Self-Information-Based Content Filtering》