AI 模型功能越來越強大，結(jié)構(gòu)也越來越復雜，它們的速度也成為了衡量先進程度的標準之一。

如果 AI 是一輛豪華跑車，那么 LoRA 微調(diào)技術(shù)就是讓它加速的渦輪增壓器。LoRA 強大到什么地步？它可以讓模型的處理速度提升 300%。還記得 LCM-LoRA 的驚艷表現(xiàn)嗎？其他模型的十步，它只需要一步就能達到相媲美的效果。

這是怎么做到的？Raphael G 的博客詳細說明了 LoRA 如何在提高模型推理效率和速度方面取得顯著成效，并介紹了這一技術(shù)實現(xiàn)的改進及其對 AI 模型性能的重大影響。以下為機器之心對本篇博客不改變原意的編譯和整理。

原博客鏈接：https://huggingface.co/raphael-gl

我們已經(jīng)能夠大大加快基于公共擴散模型的公共 LoRA 在 Hub 中的推理速度，這能夠節(jié)省大量的計算資源，并帶給用戶更快更好的使用體驗。

要對給定模型進行推理，有兩個步驟：

1. 預熱階段，包括下載模型和設置服務 ——25 秒。

2. 然后是推理工作本身 ——10 秒。

經(jīng)過改進，預熱時間能夠從 25 秒縮短到 3 秒。現(xiàn)在，我們只需不到 5 個 A10G GPU 就能為數(shù)百個不同的 LoRA 提供推理服務，而對用戶請求的響應時間則從 35 秒減少到 13 秒。

下面讓我們進一步討論如何利用 Diffusers 庫中最近開發(fā)的一些功能，通過單個服務以動態(tài)方式為許多不同的 LoRA 提供服務。

什么是 LoRA

LoRA 是一種微調(diào)技術(shù)，屬于「參數(shù)高效微調(diào)」（parameter-efficient fine-tuning，PEFT）方法系列，該方法致力于在微調(diào)過程減少受影響可訓練參數(shù)的數(shù)量。它在提高微調(diào)速度的同時，還能減少微調(diào)檢查點的大小。

LoRA 的方法并不是通過對模型的所有權(quán)重進行微小改動來微調(diào)模型，而是凍結(jié)大部分層，只在注意力模塊中訓練少數(shù)特定層。此外，我們通過在原始權(quán)重上添加兩個較小矩陣的乘積來避免觸及這些層的參數(shù)。這些小矩陣的權(quán)重會在微調(diào)過程中更新，然后保存到磁盤中。這意味著所有模型的原始參數(shù)都被保留下來，使用者可以用自適應方法在其上加載 LoRA 權(quán)重。

LoRA（Low-Rank Adaptation，低秩自適應）的名稱來源于上文提到的小矩陣。有關該方法的更多信息，可以參閱下方博客或原論文。

• 相關博客鏈接：https://huggingface.co/blog/lora
• 論文鏈接 https://arxiv.org/abs/2106.09685

下圖顯示了兩個較小的橙色矩陣，它們被保存為 LoRA 適配器的一部分。接下來，我們可以加載 LoRA 適配器，并將其與藍色基礎模型合并，得到黃色微調(diào)模型。最重要的是，我們還可以卸載適配器，這樣就可以在任何時候返回到原始基礎模型。

換句話說，LoRA 適配器就像是基礎模型的附加組件，可以按需添加和卸載。由于 A 級和 B 級較小，與模型尺寸相比，它非常輕便。因此，加載速度要比加載整個基礎模型快得多。

例如，被廣泛用作許多 LoRA 適配器基礎模型的 Stable Diffusion XL Base 1.0 模型 repo，我們會發(fā)現(xiàn)它的大小約為 7 GB。然而，像這樣的典型 LoRA 適配器僅占用 24 MB 空間。

在 Hub 上，藍色基本模型的數(shù)量遠遠少于黃色模型。如果能從藍色快速切換到黃色，反之亦然，那么我們就有辦法為許多不同的黃色模型提供服務，并且只需少數(shù)不同的藍色部署。

LoRA 的優(yōu)勢

Hub 上擁有約 2500 個不同的公共 LoRA，其中絕大多數(shù)（約 92%）基于 Stable Diffusion XL Base 1.0 模型。

在這種共享機制之前，要為所有這些模型（例如上文圖中所有黃色合并矩陣）部署專用服務，并至少占用一個新的 GPU。啟動服務并準備好為特定模型的請求提供服務的時間約為 25 秒，此外還有推理時間，在 A10G 上以 25 個推理步驟進行 1024x1024 SDXL 推理擴散的時間約為 10 秒。如果一個適配器只是偶爾被請求，它的服務就會被停止，以釋放被其他適配器搶占的資源。

如果你請求的 LoRA 不那么受歡迎，即使它是基于 SDXL 模型的，就像迄今為止在 Hub 上發(fā)現(xiàn)的絕大多數(shù)適配器一樣，也需要 35 秒來預熱并在第一次請求時獲得響應。

不過，以上已成為過去時，現(xiàn)在請求時間從 35 秒縮短到 13 秒，因為適配器將只使用幾個不同的「藍色」基礎模型（如 Diffusion 的兩個重要模型）。即使你的適配器不那么火熱，其「藍色」服務也很有可能已經(jīng)預熱。換句話說，即使你不經(jīng)常請求你的模型，也很有可能避免了 25 秒的預熱時間。藍色模型已經(jīng)下載并準備就緒，我們要做的就是卸載之前的適配器并加載新的適配器，只需要 3 秒鐘。

總的來說，盡管我們已經(jīng)有辦法在各個部署之間共享 GPU 以充分利用它們的計算能力，但相比之下仍然需要更少的 GPU 來支持所有不同的模型。在 2 分鐘內(nèi)，大約有 10 個不同的 LoRA 權(quán)重被請求。我們只需使用 1 到 2 個 GPU（如果有請求突發(fā)，可能會更多）就能為所有這些模型提供服務，而無需啟動 10 個部署并讓它們保持運行。

實現(xiàn)

我們在推理 API 中實現(xiàn)了 LoRA 共享。當在平臺上對一個模型發(fā)起請求時，我們首先判斷這是否是一個 LoRA，然后確定 LoRA 的基礎模型，并將請求路由到一個能夠服務該模型的共同的后端服務器群。

推理請求通過保持基礎模型運行狀態(tài)，并即時加載 / 卸載 LoRA 來服務。這樣，你就可以重復使用相同的計算資源來同時服務多個不同的模型。

LoRA 的結(jié)構(gòu)

在 Hub 中，LoRA 可通過兩個屬性來識別：

LoRA 會有一個 base_model 屬性，這是 LoRA 建立的基礎模型，用于執(zhí)行推理過程中使用。由于不僅 LoRA 擁有這樣的屬性（任何復制的模型都會有一個），所以它還需要一個 lora 標簽來正確識別。

數(shù)據(jù)展示

每次推理多花 2 到 4 秒鐘，我們就能為很多不同的 LoRA 提供服務。不過在 A10G GPU 上，推理時間大大縮短，而適配器加載時間變化不大，因此 LoRA 的加載 / 卸載成本相對更高。

所有數(shù)字的單位為秒。

批處理如何？

最近有一篇非常有趣的論文，介紹了如何通過在 LoRA 模型上執(zhí)行批量推理來提高吞吐量。簡而言之，所有推理請求都將被批量收集，與通用基礎模型相關的計算將一次性完成，然后再計算剩余的特定適配器產(chǎn)品。

論文鏈接 https://arxiv.org/pdf/2311.03285.pdf

我們沒有采用這種技術(shù)。相反，我們堅持單個順序推理請求。因為我們觀察到對于擴散器來說，吞吐量不會隨著批處理規(guī)模的增加而顯著提高。在我們執(zhí)行的簡單圖像生成基準測試中，當批量大小為 8 時，吞吐量只增加了 25%，而延遲卻增加了 6 倍。

關于加載 / 卸載 LoRA 的內(nèi)容，請閱讀博客原文。