TGI 推出 Multi-LoRA 服务：一次部署，服务 30 个模型

您是否厌倦了管理多个 AI 模型的复杂性和高昂成本？如果您能一次部署，就能服务 30 个模型呢？在当今的机器学习领域，希望利用其数据价值的组织很可能会步入一个微调世界，构建众多高度专业化的模型，每个模型专门针对特定任务。但如何才能应对为每个用例部署模型的麻烦和成本？答案就是 Multi-LoRA 服务。

动机

作为一个组织，通过微调构建众多模型在多个方面都是合理的。

性能 -有令人信服的证据表明，更小的专用模型在其训练过的任务上优于更大的通用模型。Predibase [5] 展示了使用特定任务的 LoRA 搭配如 mistralai/Mistral-7B-v0.1 的基础模型，可以获得比 GPT-4 更好的性能。
适应性 -像 Mistral 或 Llama 这样的模型极其通用。您可以选择其中一个作为基础模型，并构建许多专用模型，即使下游任务差异很大。另外，注意您不会被锁定，因为您可以轻松切换基础模型，并在另一个基础上用您的数据对其进行微调（稍后详述）。
独立性 -对于贵组织关心的每个任务，不同的团队可以处理不同的微调，从而在数据准备、配置、评估标准和模型更新节奏上实现独立。
隐私 -专用模型为训练数据隔离和根据数据隐私要求对不同用户进行访问限制提供了灵活性。此外，在需要在本地运行模型的情况下，小型模型可以在保持足够小以在设备上运行的同时，针对特定任务变得非常强大。

总之，微调使组织能够释放其数据的价值，当组织使用其独有的高度专用数据时，这一优势尤为显著，甚至具有颠覆性。

那么，问题在哪里？部署和服务大型语言模型（LLM）在许多方面都具有挑战性。成本和运营复杂性是部署单个模型时的关键考虑因素，更不用说n 个模型了。这意味着，尽管微调有其辉煌之处，但它进一步复杂化了 LLM 的部署和服务。

这就是为什么今天我们非常激动地推出 TGI 的最新功能——Multi-LoRA 服务。

LoRA 背景

LoRA，全称为低秩适应，是一种高效微调大型预训练模型的技术。其核心思想是将大型预训练模型适应于特定任务，而无需重新训练整个模型，只需少量称为适配器的参数。这些适配器通常只增加约 1% 的存储和内存开销，相比于预训练 LLM 的大小，同时保持与完全微调模型相当的质量。

LoRA 的明显好处是通过减少内存需求，大幅降低微调成本。它还减少了灾难性遗忘，并更好地适用于小型数据集。


图 1：LoRA 解释

在训练过程中，LoRA 冻结原始权重 W 并微调两个小矩阵，A 和 B，从而使微调更加高效。考虑到这一点，我们可以在图 1中看到 LoRA 在推理时的工作原理。我们取预训练模型 Wx 的输出，并添加低秩适配项 BAx [6]。

多 LoRA 服务

现在我们理解了 LoRA 引入的模型适配基本概念，接下来可以深入探讨多 LoRA 服务。这个概念很简单：给定一个基础预训练模型和许多不同的任务，你为这些任务微调了特定的 LoRA，多 LoRA 服务是一种机制，根据传入的请求动态选择所需的 LoRA。


图 2：多 LoRA 详解

图 2 展示了这种动态适配的工作方式。每个用户请求包含输入 x 以及该请求对应 LoRA 的 id（我们称之为异构用户请求批次）。任务信息使 TGI 能够选择正确的 LoRA 适配器来使用。

多 LoRA 服务使你只需部署一次基础模型。由于 LoRA 适配器很小，你可以加载许多适配器。注意确切数量将取决于你可用的 GPU 资源和所部署的模型。你最终得到的效果相当于在一个单一部署中拥有多个微调模型。

LoRA（适配器权重）可能因秩和量化而异，但通常非常小。让我们快速直观地了解这些适配器有多小：predibase/magicoder 为 13.6MB，不到 mistralai/Mistral-7B-v0.1 的 1/1000，后者为 14.48GB。相对而言，将 30 个适配器加载到 RAM 中仅导致 VRAM 增加 3%。最终，这对大多数部署来说不是问题。因此，我们可以用一个部署服务多个模型。

如何使用

收集 LoRA

首先，你需要训练你的 LoRA 模型并导出适配器。你可以在这里找到关于微调 LoRA 适配器的指南。请注意，当你将微调后的模型推送到 Hub 时，只需推送适配器，而不是完整的合并模型。从 Hub 加载 LoRA 适配器时，基础模型会从适配器模型卡中推断出来，并再次单独加载。如需更深入的支持，请查看我们的专家支持计划。真正的价值将体现在你为特定用例创建自己的 LoRA 时。

低代码团队

对于一些组织来说，为每个用例训练一个 LoRA 可能很困难，因为他们可能缺乏专业知识或其他资源。即使你选择了基础并准备好了数据，你还需要跟上最新技术、探索超参数、寻找最佳硬件资源、编写代码，然后进行评估。即使对于经验丰富的团队来说，这也可能是一项艰巨的任务。

AutoTrain 可以显著降低这一门槛。AutoTrain 是一个无代码解决方案，允许你只需点击几下即可训练机器学习模型。使用 AutoTrain 有多种方式。除了本地/本地部署之外，我们还有：

AutoTrain 环境	硬件详情	代码要求	备注
HF Mirror Space	多种 GPU 和硬件	无需代码	灵活且易于分享
DGX cloud	最多 8xH100 GPU	无需代码	更适合大型模型
Google Colab	可使用 T4 GPU	低代码	适合小负载和量化模型

部署

在我们的示例中，我们将使用 Predibase 的 LoRA Land 中的一些优秀适配器：

predibase/customer_support 基于 Gridspace-Stanford Harper Valley 语音数据集训练，这增强了其准确理解和响应客户服务交互的能力。这提高了模型在语音识别、情感检测和对话管理等任务中的性能，从而实现更高效、更具同理心的客户支持。
predibase/magicoder 基于 ise-uiuc/Magicoder-OSS-Instruct-75K 训练，这是一个合成生成的代码指令数据集。

TGI

关于如何部署 TGI，已有大量优质资料。按照常规方式进行部署，但请确保：

使用版本不低于 v2.1.1 的 TGI
部署你的基础模型：mistralai/Mistral-7B-v0.1
Add the LORA_ADAPTERS env var during deployment
- 示例：LORA_ADAPTERS=predibase/customer_support,predibase/magicoder

model=mistralai/Mistral-7B-v0.1
# share a volume with the Docker container to avoid downloading weights every run
volume=$PWD/data

docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data \
    ghcr.io/huggingface/text-generation-inference:2.1.1 \
    --model-id $model \
    --lora-adapters=predibase/customer_support,predibase/magicoder

推理端点 GUI

推理端点让你只需点击几下，就能在 AWS、GCP 和 Azure 上的多种 GPU 及其他硬件类型上部署任何 HF Mirror 模型！在 GUI 中，部署非常简单。在底层，我们默认使用 TGI 进行文本生成（不过你也有选项使用任何你选择的镜像）。

要在推理端点上使用 Multi-LoRA 服务，你只需前往你的仪表板，然后：

选择你的基础模型：mistralai/Mistral-7B-v0.1
Choose your Cloud | Region | HW
- 我将使用 AWS | us-east-1 | Nvidia L4
Select Advanced Configuration
- 你应该会看到 text generation 已被选中
- 你可以根据自己的需求进行配置
在环境变量中添加 LORA_ADAPTERS=predibase/customer_support,predibase/magicoder
最后 Create Endpoint！

请注意这只是最低配置，你应该按需配置其他设置。


图 3：Multi-LoRA 推理端点


图 4：Multi-LoRA 推理端点 2

推理端点代码

也许你们中有些人害怕鼠标，不想用鼠标，我们不会评判。用代码自动化这一点并只用键盘是很容易的。

from huggingface_hub import create_inference_endpoint

# Custom Docker image details
custom_image = {
    "health_route": "/health",
    "url": "ghcr.io/huggingface/text-generation-inference:2.1.1",  # This is the min version
    "env": {
        "LORA_ADAPTERS": "predibase/customer_support,predibase/magicoder",  # Add adapters here
        "MAX_BATCH_PREFILL_TOKENS": "2048",  # Set according to your needs
        "MAX_INPUT_LENGTH": "1024", # Set according to your needs
        "MAX_TOTAL_TOKENS": "1512", # Set according to your needs
        "MODEL_ID": "/repository"
    }
}

# Creating the inference endpoint
endpoint = create_inference_endpoint(
    name="mistral-7b-multi-lora",
    repository="mistralai/Mistral-7B-v0.1",
    framework="pytorch",
    accelerator="gpu",
    instance_size="x1",
    instance_type="nvidia-l4",
    region="us-east-1",
    vendor="aws",
    min_replica=1,
    max_replica=1,
    task="text-generation",
    custom_image=custom_image,
)
endpoint.wait()

print("Your model is ready to use!")

此配置部署耗时约 3 分 40 秒。注意，模型更多时耗时会更长。如果你遇到加载时间方面的问题，请务必提交 github issue！

消费

当你消费你的端点时，你需要指定你的 adapter_id。这是一个 cURL 示例：

curl 127.0.0.1:3000/generate \
    -X POST \
    -H 'Content-Type: application/json' \
    -d '{
  "inputs": "Hello who are you?",
  "parameters": {
    "max_new_tokens": 40,
    "adapter_id": "predibase/customer_support"
  }
}'

或者，这里有一个使用来自出色的 HF Mirror Hub Python 库的 InferenceClient 的示例。请务必确保你使用的是 huggingface-hub>=0.24.0，并且如有必要，你已登录。

from huggingface_hub import InferenceClient

tgi_deployment = "127.0.0.1:3000"
client = InferenceClient(tgi_deployment)
response = client.text_generation(
    prompt="Hello who are you?",
    max_new_tokens=40,
    adapter_id='predibase/customer_support',
)

实际考虑

成本

我们并不是第一批攀登这座高峰的人，正如下文所讨论的。LoRAX 背后的团队 Predibase 有一篇出色的文章。请务必查看，因为本节内容基于他们的工作。


图 5：Multi-LoRA 成本对于 TGI，我在 nvidia-l4 上部署了 mistralai/Mistral-7B-v0.1 作为基础模型，其在推理端点上的成本为 $0.8/小时。我能够获得 75 请求/秒，平均 450 个输入 token 和 234 个输出 token，并据此针对 GPT3.5 Turbo 进行了调整。

Multi-LoRA 服务的一大优势在于，你不需要为多个模型进行多次部署，最终这会便宜得多。这应该符合你的直觉，因为多个模型需要所有的权重，而不仅仅是小的适配器层。如图 5所示，即使我们添加更多模型，使用 TGI Multi-LoRA 时每个 token 的成本也是相同的。而 TGI 专用部署的成本会随着每个微调模型需要新部署而增加。

使用模式


图 6：Multi-LoRA 服务模式

部署多个模型时一个现实挑战是，你的使用模式会有很大差异。有些模型可能使用率低；有些可能是突发性的；还有一些可能是高频的。这使得扩展变得非常困难，尤其是当每个模型都是独立的时候。当你不得不增加另一块 GPU 时，会产生很多“取整”误差，而且这些误差会迅速累积。在理想情况下，你会最大化每块 GPU 的利用率，而不使用任何额外的 GPU。你需要确保能够访问足够多的 GPU，同时知道有些会处于空闲状态，这可能相当繁琐。

当我们通过 Multi-LoRA 进行整合时，使用情况会稳定得多。我们可以在图 6中看到这一结果，其中 Multi-LoRA 服务模式相当稳定，尽管它由更易波动的模式组成。通过整合模型，你可以实现更平滑的使用和更易管理的扩展。请注意，这些只是说明性的模式，但请思考你自己的模式以及 Multi-LoRA 如何提供帮助。扩展 1 个模型，而不是 30 个！

更换基础模型

在 AI 以惊人速度发展的现实世界中会发生什么？如果你想选择不同/更新的模型作为基础模型呢？虽然我们的示例使用 mistralai/Mistral-7B-v0.1 作为基础模型，但还有其他基础模型，比如 Mistral 的 v0.3，它支持函数调用，以及完全不同的模型系列，比如 Llama 3。总的来说，我们预计更高效、性能更强的新基础模型会不断涌现。

但不用担心！如果你有令人信服的理由要更新基础模型，重新训练 LoRA 是很容易的。训练相对便宜；事实上，Predibase 发现训练每个 LoRA 只需约 8.00 美元。借助现代框架和常见工程实践，代码变更量很小：

保留用于训练模型的 notebook/代码
对数据集进行版本控制
跟踪所使用的配置
使用新模型/设置进行更新

结论

Multi-LoRA 服务代表了 AI 模型部署的一种变革性方法，为管理多个专用模型相关的成本和复杂性障碍提供了解决方案。通过利用单个基础模型并动态应用微调适配器，组织可以显著降低运营开销，同时在各种任务中保持甚至增强性能。AI 主管们，我们请你们大胆一些，选择一个基础模型并拥抱 Multi-LoRA 范式，其简便性和成本节约将带来丰厚回报。让 Multi-LoRA 成为你 AI 战略的基石，确保你的组织在快速发展的技术格局中保持领先。

致谢

实现 Multi-LoRA 服务可能非常棘手，但由于 punica-ai 和 lorax 团队的出色工作，已经开发出优化的内核和框架，使这一过程更加高效。TGI 利用这些优化，为多个 LoRA 模型提供快速高效的推理。

特别感谢 Punica、LoRAX 和 S-LoRA 团队在多 LoRA 服务方面所做的出色且开放的工作。

参考文献

[1] ：Dan Biderman, Jose Gonzalez Ortiz, Jacob Portes, Mansheej Paul, Philip Greengard, Connor Jennings, Daniel King, Sam Havens, Vitaliy Chiley, Jonathan Frankle, Cody Blakeney, John P. Cunningham, LoRA Learns Less and Forgets Less, 2024
[2] ：Edward J. Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen, LoRA: Low-Rank Adaptation of Large Language Models, 2021
[3] ：Sourab Mangrulkar, Sayak Paul, PEFT: Parameter-Efficient Fine-Tuning of Billion-Scale Models on Low-Resource Hardware, 2023
[4] ：Travis Addair, Geoffrey Angus, Magdy Saleh, Wael Abid, LoRAX: The Open Source Framework for Serving 100s of Fine-Tuned LLMs in Production, 2023
[5] ：Timothy Wang, Justin Zhao, Will Van Eaton, LoRA Land: Fine-Tuned Open-Source LLMs that Outperform GPT-4, 2024
[6] ：Punica: Serving multiple LoRA finetuned LLM as one: https://github.com/punica-ai/punica