“ 在大模型應用中，處理大量數據會很容易遇到瓶頸問題，因此我們需要從各個環節進行優化。”

最近在處理一個RAG的知識庫導入功能，功能邏輯也很簡單；為了提升數據的召回率，對內容進行提煉以及標簽提取，之后再對原數據和總結提煉的數據進行嵌入(embedding)并插入到向量數據庫中。

但還是自己太年輕把問題想的太簡單了，本來以為不是什么麻煩的東西，隨便搞搞就行了；結果也是這樣，代碼幾個小時就搞定了，但等到真正去導入的時候才發現一個問題，那就是效率問題，導入速度實在是太慢了；原因是因為這次導入數據的量有點大，上百萬條。

雖然百萬條數據對傳統的系統開發來說，并不是很大的數據量，但對大模型應用來說卻并沒那么簡單，因為大模型的處理效率本身就低，再加上資源限制問題(就一個模型服務 并發量也就十來個)，導致并發量上不去。

所以怎么解決這個問題，就需要一個性能優化方案，特別是針對這種大數據量處理。

在大模型領域中——批量數據處理的優化方案

首先我們先來考慮一下在當前業務場景下的性能瓶頸有哪些？ 

首先在大模型應用中第一個瓶頸在大模型，特別是本地部署的大模型企業，由于資源有限因此模型的并發量是一個很大的問題；但這玩意只能靠鈔能力沒有別的辦法。

大模型本身是一個算力密集性系統，因此對模型來說最重要的就是提升其算力，也就是CPU和GPU；通過增加硬件資源來提升大模型的響應速度；其次，就是增加模型的集群數量，來進行負載均衡實現高并發，還有一個就是讓大模型支持批量數據，但目前來看市面上的大模型大都不支持批處理的功能。

但對大部分企業來說，大模型的資源是有限的，因此只能在調用方來優化我們的系統；那么調用方應該怎么優化呢？

在右側，也就是大模型的主要性能瓶頸是算力問題；但在左側調用端，大模型的主要瓶頸卻是IO問題，因為大模型響應時間較長，再加上數據量巨大，因此會導致大量的網絡IO占用，因此我們需要想辦法降低IO的次數；比如說把循環調用改成批量傳參；這樣能夠大量減少網絡IO的消耗，提升效率。

其次，使用多線程/多進程/異步消息等等實現串行調用到并行調用；但這里需要注意線程安全問題以及可能存在的數據順序問題。

關于性能問題，主要就是找到我們的性能瓶頸的那段代碼，然后嘗試使用多線程，異步，批量傳參，等多種方式來優化我們的代碼，減少不必要的網絡請求和數據傳輸；最后再利用計算機的并行處理能力，多線程執行。

以目前作者為例，目前的主要性能瓶頸就是embedding嵌入以及文檔內容總結等需要頻繁調用大模型的任務；其會消耗大量的時間，因此作者采用多線程的方式并行執行任務，處理速度至少提升了十倍以上。之前需要幾個小時才能跑完的數據，現在二十分鐘就可以搞定。

另外，使用第三方模型API如魔塔(modelscope)，硅基流動等；其會限制訪問速度和次數(免費版，付費版可能不會限制)，因此在大數據量處理時最好找一下支持高頻訪問的模型廠商。

本文轉載自???AI探索時代??? 作者：DFires