大模型应用中的性能瓶颈问题——批量数据处理的优化方案

最近在处理一个RAG的知识库导入功能，功能逻辑也很简单；为了提升数据的召回率，对内容进行提炼以及标签提取，之后再对原数据和总结提炼的数据进行嵌入(embedding)并插入到向量数据库中。

但还是自己太年轻把问题想的太简单了，本来以为不是什么麻烦的东西，随便搞搞就行了；结果也是这样，代码几个小时就搞定了，但等到真正去导入的时候才发现一个问题，那就是效率问题，导入速度实在是太慢了；原因是因为这次导入数据的量有点大，上百万条。

虽然百万条数据对传统的系统开发来说，并不是很大的数据量，但对大模型应用来说却并没那么简单，因为大模型的处理效率本身就低，再加上资源限制问题(就一个模型服务 并发量也就十来个)，导致并发量上不去。

所以怎么解决这个问题，就需要一个性能优化方案，特别是针对这种大数据量处理。

首先我们先来考虑一下在当前业务场景下的性能瓶颈有哪些？ 

首先在大模型应用中第一个瓶颈在大模型，特别是本地部署的大模型企业，由于资源有限因此模型的并发量是一个很大的问题；但这玩意只能靠钞能力没有别的办法。

大模型本身是一个算力密集性系统，因此对模型来说最重要的就是提升其算力，也就是CPU和GPU；通过增加硬件资源来提升大模型的响应速度；其次，就是增加模型的集群数量，来进行负载均衡实现高并发，还有一个就是让大模型支持批量数据，但目前来看市面上的大模型大都不支持批处理的功能。

但对大部分企业来说，大模型的资源是有限的，因此只能在调用方来优化我们的系统；那么调用方应该怎么优化呢？

在右侧，也就是大模型的主要性能瓶颈是算力问题；但在左侧调用端，大模型的主要瓶颈却是IO问题，因为大模型响应时间较长，再加上数据量巨大，因此会导致大量的网络IO占用，因此我们需要想办法降低IO的次数；比如说把循环调用改成批量传参；这样能够大量减少网络IO的消耗，提升效率。

其次，使用多线程/多进程/异步消息等等实现串行调用到并行调用；但这里需要注意线程安全问题以及可能存在的数据顺序问题。

关于性能问题，主要就是找到我们的性能瓶颈的那段代码，然后尝试使用多线程，异步，批量传参，等多种方式来优化我们的代码，减少不必要的网络请求和数据传输；最后再利用计算机的并行处理能力，多线程执行。

以目前作者为例，目前的主要性能瓶颈就是embedding嵌入以及文档内容总结等需要频繁调用大模型的任务；其会消耗大量的时间，因此作者采用多线程的方式并行执行任务，处理速度至少提升了十倍以上。之前需要几个小时才能跑完的数据，现在二十分钟就可以搞定。

另外，使用第三方模型API如魔塔(modelscope)，硅基流动等；其会限制访问速度和次数(免费版，付费版可能不会限制)，因此在大数据量处理时最好找一下支持高频访问的模型厂商。