01、引言

LoRA(Low-rank Adapter)在大模型（如GPT-3，LLama, Qwen等）中，是一種重要的微調(diào)技術(shù)。該技術(shù)通過在不改變預(yù)訓(xùn)練模型參數(shù)的同時(shí)，添加低階矩陣，學(xué)習(xí)新的、特定于任務(wù)的參數(shù)。這種微調(diào)方式不僅維持了模型的高效性能，也顯著提升了模型訓(xùn)練和部署的效率。然而當(dāng)對base model進(jìn)行規(guī)模化多任務(wù)微調(diào)時(shí)，相關(guān)部署成本可能會(huì)顯著增加?；趯?shí)際應(yīng)用場景，成本和效率考慮，我們在RTP-LLM框架上實(shí)現(xiàn)了兩種LoRA方法：靜態(tài)LoRA和動(dòng)態(tài)LoRA。

1. 靜態(tài)LoRA:在模型加載時(shí)將LoRA權(quán)重疊加到底層模型中，適用于單LoRA的場景，可以提高模型的運(yùn)行效率和降低計(jì)算開銷。
2. 動(dòng)態(tài)LoRA:共享基座模型，根據(jù)不同的業(yè)務(wù)場景動(dòng)態(tài)選擇適當(dāng)?shù)腖oRA參數(shù)。這種方式在保證模型性能的同時(shí)，顯著節(jié)省了顯存，提高了模型的適應(yīng)性和靈活性，使同一種模型服務(wù)可以滿足多種業(yè)務(wù)場景的需求。

目前，在阿里集團(tuán)內(nèi)部的推理平臺-whale已經(jīng)集成了靜態(tài)和動(dòng)態(tài)LoRA解決方案，該平臺基于RTP-LLM框架，用于部署大型語言模型（LLM）。業(yè)務(wù)團(tuán)隊(duì)可以在whale平臺通過一鍵部署快速將訓(xùn)練好的模型應(yīng)用到生產(chǎn)環(huán)境，從而加速推動(dòng)創(chuàng)新應(yīng)用的實(shí)施。接下來的內(nèi)容中深入探討靜態(tài)和動(dòng)態(tài)LoRA的工作原理以及它們在現(xiàn)實(shí)業(yè)務(wù)場景中的性能表現(xiàn)，幫助您更好地理解這些技術(shù)，并根據(jù)實(shí)際業(yè)務(wù)場景選擇合適的LoRA方案。

02

靜態(tài)LoRA：效率之選

  圖1

在線部署的時(shí)候我們可以將BA加到原參數(shù)上，從而在推理時(shí)不會(huì)產(chǎn)生額外的推理時(shí)延。在LLM場景我們可以將LoRA應(yīng)用于Transformer模型結(jié)構(gòu)中的任何權(quán)重矩陣子集，以減少可訓(xùn)練參數(shù)的數(shù)量。在Transformer模型結(jié)構(gòu)中，Multi-Head Self-Attention模塊 (Wq，Wk，Wu，Wo) 中有四個(gè)權(quán)重矩陣，F(xiàn)FN模塊中通常有兩到三個(gè),下面以Multi-Head Self-Attention以及 FFN模塊的計(jì)算邏輯為例，說明LoRA 在Transformer模型預(yù)測階段的計(jì)算過程。

基座模型的多頭自注意力機(jī)制(Multi-Head Self-Attention)計(jì)算公式為：

基座模型的(Feed Forward Network, FFN)計(jì)算公式為：

經(jīng)過LoRA finetune之后模型的attention計(jì)算公式為：

經(jīng)過LoRA finetune模型的FFN層計(jì)算公式為：

在只有單一LoRA任務(wù)的場景中，可以借鑒LoRA finetune之后的計(jì)算公式，并在模型加載時(shí)將LoRA權(quán)重疊加到base model的權(quán)重中，這種實(shí)現(xiàn)方式被稱為靜態(tài)LoRA。靜態(tài)LoRA的主要優(yōu)點(diǎn)是可以顯著減少計(jì)算量，提高模型的運(yùn)行效率。目前whale(大模型管控平臺)已經(jīng)支持了靜態(tài)LoRA的部署，大家可以體驗(yàn)。

03、動(dòng)態(tài)LoRA：靈活性考量

在whale平臺部署多個(gè)基于相同base model微調(diào)的LoRA adapter任務(wù)時(shí)需每個(gè)adapter都作為獨(dú)立模型實(shí)例運(yùn)行，那么每個(gè)實(shí)例都需獨(dú)立分配顯存資源(如圖2所示)。尤其在LoRA adapter請求比較稀疏的情況下，這種部署方式阻礙了對base model顯存的集中管理和優(yōu)化復(fù)用，顯存資源以及GPU算力都得不到充分利用，造成了整體GPU的浪費(fèi)。這種情況下，雖然確保了性能的穩(wěn)定性，但在資源效率方面存在改進(jìn)空間。

圖2

基于以上背景，我們參考S-LORA提出了動(dòng)態(tài)LoRA的方案。如圖3所示。動(dòng)態(tài)LoRA采取分離base model權(quán)重和LoRA adapter的策略。推理時(shí)根據(jù)請求的adapter name，選擇對應(yīng)的LoRA adapter和base model結(jié)構(gòu)加和完成推理。這種設(shè)計(jì)因其允許adapter之間的秩(rank)不同，具有較強(qiáng)的通用性。

圖3

batching策略：針對共享base model的特點(diǎn)，我們對χ AB和χ ω分別采用不同的批處理策略來優(yōu)化計(jì)算效率。對χω的批處理可以直接應(yīng)用RTP-LLM的原生批處理優(yōu)化技術(shù):continuous batching。而對于χ AB，盡管其計(jì)算成本相對較低且參數(shù)少，但處理起來卻相對復(fù)雜。這是因?yàn)檩斎氲男蛄虚L度和adapter 的rank都是動(dòng)態(tài)變化的，例如可能同時(shí)收到兩個(gè)不同長度的查詢和兩個(gè)不同rank的adapter請求。為了處理這種情況，如果采用傳統(tǒng)的批量GEMM內(nèi)核，我們需要對某一個(gè)維度進(jìn)行padding，且隨著continuous batching rank也會(huì)動(dòng)態(tài)變化，還需要?jiǎng)討B(tài)地進(jìn)行填充。因此計(jì)算χ AB的時(shí)候我們不padding，而通過GroupGEMM來實(shí)現(xiàn)χ AB batch計(jì)算，如圖4所示，該方案可以更加高效地適應(yīng)動(dòng)態(tài)變化的LoRA rank。

圖4

tensor-para: 如果把多adapter單base model部署在多卡環(huán)境，那就需要tensor-para。RTP-LLM的tensor-para 方案為：根據(jù)base model 的tensor-para切分策略，對tensor A或者B其中一個(gè)tensor進(jìn)行冗余存儲(chǔ)，這樣不會(huì)因?yàn)橛?jì)算x AB增加額外計(jì)算的通信需求。如圖5所示，展示了一個(gè)兩層MLP的切分方法，W1和W2兩個(gè)tensor 分別對應(yīng)的LoRA tensorA和B的切分策略，MLP的切分策略可以拓展到self-attention層。

圖5

性能評估：

A10單卡機(jī)器上測試了qwen_7b lora_rank=8與base model的性能對比結(jié)果：

v100-16GB*4卡機(jī)器測試 llama2-13B lora_rank=8, 64，tensor-para=4與base model的性能對比結(jié)果：

動(dòng)態(tài)LoRA通過分離base model 和 LoRA adapter 實(shí)現(xiàn)了多LoRA 任務(wù)base model顯存共享，同一種模型服務(wù)可以滿足多種業(yè)務(wù)場景的需求。云服務(wù)團(tuán)隊(duì)基于動(dòng)態(tài)LoRA實(shí)現(xiàn)的LLM大模型的檢索增強(qiáng)生成（Retrieval Agumented Generation，RAG）SAAS產(chǎn)品已發(fā)布，大家可以參考OpenSearch-LLM智能問答版使用指南進(jìn)行試用。

04、動(dòng)態(tài)LoRA的管理

LoRA動(dòng)態(tài)上下線：在云服務(wù)場景中，出于成本和資源效率的考慮，業(yè)務(wù)通常僅部署一個(gè)實(shí)例來運(yùn)行多LoRA任務(wù)，而不采用多實(shí)例部署。這種策略雖然節(jié)約了成本，但在LoRA更新時(shí)卻可能會(huì)面臨服務(wù)連續(xù)性和穩(wěn)定性的挑戰(zhàn)。

當(dāng)需要對LoRA進(jìn)行變更時(shí)，傳統(tǒng)流程需要將整個(gè)實(shí)例下線，然后重啟進(jìn)程，重新加載base_model 以及多份LoRA adapter。這一過程可能導(dǎo)致至少5分鐘以上的服務(wù)中斷，從而降低了單實(shí)例的有效服務(wù)時(shí)間，并影響用戶體驗(yàn)。為了緩解這種情況，RTP-LLM引入了LoRA adapter的熱更新機(jī)制，這使得在實(shí)例提供服務(wù)的同時(shí)，可以快速更新LoRA adapter，顯著減少了變更所需的時(shí)間并最小化了服務(wù)中斷時(shí)間。

LoRA topo 管理：在云服務(wù)環(huán)境中，不同LoRA 任務(wù)所需的GPU顯存大小不一致， 且不同LoRA任務(wù)的流量也呈現(xiàn)出不同的特點(diǎn)：一些LoRA為流量密集型任務(wù)，而一些LoRA任務(wù)則是流量稀疏的任務(wù)。不同的LoRA對GPU的顯存和算力的要求不一致，單實(shí)例的GPU 資源有限，如何從整體資源效率出發(fā)，盡可能的讓單實(shí)例的GPU資源利用率達(dá)到最優(yōu)是我們在云服務(wù)場景面臨的一個(gè)很重要的難題。目前我們采用智能管理方案來優(yōu)化大語言模型（LLM）任務(wù)的執(zhí)行流程，該方案包括幾個(gè)關(guān)鍵步驟：

1. 任務(wù)注冊與模型性能評估：LoRA任務(wù)以及流量需求注冊至quota server，同步評估LoRA任務(wù)的顯存需求和算力需求
2. 選擇集群：quota server 綜合考量當(dāng)前集群性能和負(fù)載，以及LoRA任務(wù)的需求，選取最合適的集群或者新建集群。
3. 資源調(diào)度與分配：系統(tǒng)將用戶LoRA任務(wù)部署通過LoRA熱更新機(jī)制部署到目標(biāo)集群，確保資源的高效利用和任務(wù)的快速啟動(dòng)。
4. 提供服務(wù)：LoRA  任務(wù)生效后，提供推理服務(wù)

該方案基于LoRA任務(wù)的需求來調(diào)配LoRA任務(wù)的部署。后續(xù)我們會(huì)做進(jìn)一步的優(yōu)化比如根據(jù)實(shí)時(shí)的流量，實(shí)現(xiàn)LoRA部署的動(dòng)態(tài)調(diào)整，優(yōu)化資源分布，從而在負(fù)載均衡和資源利用率之間找到最佳平衡。提高整體的資源效率。

05、后續(xù)規(guī)劃

RTP-LLM通過預(yù)加載LoRA Adapter到顯存中，有效降低了處理延遲，但顯存大小也限制了單實(shí)例能支持的LoRA Adapter 的數(shù)量與大小。后續(xù)我們計(jì)劃通過優(yōu)化顯存分配策略按需動(dòng)態(tài)管理LoRA的顯存占用，來擴(kuò)大單實(shí)例支持的LoRA Adapter 數(shù)量。

參考鏈接

[01] S-LORA

????https://arxiv.org/pdf/2311.03285.pdf??

本文轉(zhuǎn)載自 ??阿里技術(shù)??，作者： 阿里技術(shù)