01、引言

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

1. 靜態LoRA:在模型加載時將LoRA權重疊加到底層模型中，適用于單LoRA的場景，可以提高模型的運行效率和降低計算開銷。
2. 動態LoRA:共享基座模型，根據不同的業務場景動態選擇適當的LoRA參數。這種方式在保證模型性能的同時，顯著節省了顯存，提高了模型的適應性和靈活性，使同一種模型服務可以滿足多種業務場景的需求。

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

02

靜態LoRA：效率之選

  圖1

在線部署的時候我們可以將BA加到原參數上，從而在推理時不會產生額外的推理時延。在LLM場景我們可以將LoRA應用于Transformer模型結構中的任何權重矩陣子集，以減少可訓練參數的數量。在Transformer模型結構中，Multi-Head Self-Attention模塊 (Wq，Wk，Wu，Wo) 中有四個權重矩陣，FFN模塊中通常有兩到三個,下面以Multi-Head Self-Attention以及 FFN模塊的計算邏輯為例，說明LoRA 在Transformer模型預測階段的計算過程。

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

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

經過LoRA finetune之后模型的attention計算公式為：

經過LoRA finetune模型的FFN層計算公式為：

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

03、動態LoRA：靈活性考量

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

圖2

基于以上背景，我們參考S-LORA提出了動態LoRA的方案。如圖3所示。動態LoRA采取分離base model權重和LoRA adapter的策略。推理時根據請求的adapter name，選擇對應的LoRA adapter和base model結構加和完成推理。這種設計因其允許adapter之間的秩(rank)不同，具有較強的通用性。

圖3

batching策略：針對共享base model的特點，我們對χ AB和χ ω分別采用不同的批處理策略來優化計算效率。對χω的批處理可以直接應用RTP-LLM的原生批處理優化技術:continuous batching。而對于χ AB，盡管其計算成本相對較低且參數少，但處理起來卻相對復雜。這是因為輸入的序列長度和adapter 的rank都是動態變化的，例如可能同時收到兩個不同長度的查詢和兩個不同rank的adapter請求。為了處理這種情況，如果采用傳統的批量GEMM內核，我們需要對某一個維度進行padding，且隨著continuous batching rank也會動態變化，還需要動態地進行填充。因此計算χ AB的時候我們不padding，而通過GroupGEMM來實現χ AB batch計算，如圖4所示，該方案可以更加高效地適應動態變化的LoRA rank。

圖4

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

圖5

性能評估：

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

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

動態LoRA通過分離base model 和 LoRA adapter 實現了多LoRA 任務base model顯存共享，同一種模型服務可以滿足多種業務場景的需求。云服務團隊基于動態LoRA實現的LLM大模型的檢索增強生成（Retrieval Agumented Generation，RAG）SAAS產品已發布，大家可以參考OpenSearch-LLM智能問答版使用指南進行試用。

04、動態LoRA的管理

LoRA動態上下線：在云服務場景中，出于成本和資源效率的考慮，業務通常僅部署一個實例來運行多LoRA任務，而不采用多實例部署。這種策略雖然節約了成本，但在LoRA更新時卻可能會面臨服務連續性和穩定性的挑戰。

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

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

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

該方案基于LoRA任務的需求來調配LoRA任務的部署。后續我們會做進一步的優化比如根據實時的流量，實現LoRA部署的動態調整，優化資源分布，從而在負載均衡和資源利用率之間找到最佳平衡。提高整體的資源效率。

05、后續規劃

RTP-LLM通過預加載LoRA Adapter到顯存中，有效降低了處理延遲，但顯存大小也限制了單實例能支持的LoRA Adapter 的數量與大小。后續我們計劃通過優化顯存分配策略按需動態管理LoRA的顯存占用，來擴大單實例支持的LoRA Adapter 數量。

參考鏈接

[01] S-LORA

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

本文轉載自 ??阿里技術??，作者： 阿里技術