本文介绍了一种在显存受限环境下部署多个 LoRA 微调模型的技术方案。通过 vLLM 框架，可以在加载单个基础模型的同时动态切换多个 LoRA 适配器，从而避免为每个任务单独部署完整模型带来的显存浪费。文章提供了具体的 Python 代码示例，展示了如何初始化模型、配置采样参数以及调用不同 LoRA 进行推理，并对比了基座模型与不同 LoRA 模型的输出效果。该方法适用于需要同时运行多个垂直领域模型但硬件资源有限的场景，详细分析了显存优化原理及生产环境中的最佳实践。
在人工智能应用开发中，经常面临需要同时支持多个垂直领域任务的情况。例如，一个客服系统可能需要同时处理售前咨询、售后技术支持和订单查询等不同场景。针对这些场景，通常的做法是为每个任务训练独立的 LoRA（Low-Rank Adaptation）微调模型。
然而，如果将每个 LoRA 模型都 Merge（合并）回基座模型并单独部署，会导致资源浪费。假设有一个 7B 参数的基座模型，部署一份需要占用约 14GB 显存（FP16）。如果有 10 个不同的 LoRA 任务，分别部署意味着需要 10 份基座权重，总计消耗 140GB 显存，这对大多数单卡或双卡环境来说是不可接受的。
此外，模型文件的复制、上传以及加载时间也会随着部署数量的增加而线性增长，影响业务上线效率。
为了解决上述问题，vLLM 等推理框架支持在同一基座模型上动态加载多个 LoRA 适配器。其核心原理是：
这种方案的显存占用约为：显存 = 基座模型显存 + (N * LoRA 模型显容)。相比全量部署，显存节省效果显著，但代价是每次推理都需要进行额外的矩阵乘法运算，因此推理速度会比 Merge 后的模型稍慢。
确保安装了支持 LoRA 的 vLLM 版本以及相应的依赖库。
pip install vllm transformers accelerate
以下代码展示了如何使用 vLLM 加载基座模型并动态调用两个不同的 LoRA 适配器。
from vllm import LLM, SamplingParams
from vllm.lora.request import LoRARequest
from transformers import AutoTokenizer
# 定义提示词
prompts = ["你是谁？", "你由谁训练？"]
# 设置生成参数
sampling_params = SamplingParams(
temperature=0.7,
top_p=0.8,
top_k=50,
max_tokens=2048
)
# 定义 LoRA 请求对象
# lora_name: 适配器名称标识
# lora_int_id: 整数 ID，用于内部索引
# lora_local_path: 本地 LoRA 权重路径
lora_request_1 = LoRARequest("adapter_v1", 1, lora_local_path="output_dir_qwen2.5_lora_v1/")
lora_request_2 = LoRARequest("adapter_v2", 2, lora_local_path="output_dir_qwen2.5_lora_v2/")
# 初始化 LLM 实例
# enable_lora=True 开启 LoRA 支持
# max_loras 限制最大并发加载的 LoRA 数量
llm = LLM(
model="Qwen2.5-7B-Instruct",
enable_lora=True,
max_model_len=2048,
dtype="float16"
)
# 加载分词器
tokenizer = AutoTokenizer.from_pretrained("Qwen2.5-7B-Instruct")
# 预处理 Prompt
temp_prompts = [
tokenizer.apply_chat_template(
[{"role": "user", "content": prompt}],
tokenize=False
) for prompt in prompts
]
prompt_token_ids = tokenizer(temp_prompts).input_ids
# 推理 1：使用第一个 LoRA
print("=== 加载 Adapter V1 ===")
outputs = llm.generate(
sampling_params=sampling_params,
prompt_token_ids=prompt_token_ids,
lora_request=lora_request_1
)
for i, output in enumerate(outputs):
print(f"Prompt: {prompts[i]} -> Output: {output.outputs[0].text}")
# 推理 2：使用第二个 LoRA
print("\n=== 加载 Adapter V2 ===")
outputs = llm.generate(
sampling_params=sampling_params,
prompt_token_ids=prompt_token_ids,
lora_request=lora_request_2
)
for i, output in enumerate(outputs):
print(f"Prompt: {prompts[i]} -> Output: {output.outputs[0].text}")
# 推理 3：不使用 LoRA（基座模型）
print("\n=== 基座模型推理 ===")
outputs = llm.generate(
sampling_params=sampling_params,
prompt_token_ids=prompt_token_ids
)
for i, output in enumerate(outputs):
print(f"Prompt: {prompts[i]} -> Output: {output.outputs[0].text}")
通过上述代码，我们可以观察到不同配置下的输出差异：
这证明了在同一个进程内，通过切换 lora_request 参数，即可实现不同模型行为的无缝切换，而无需重启服务或重新加载基座权重。
为了更清晰地理解显存节省机制，我们需要对比两种部署模式的显存分布。
在此模式下，每个任务都有完整的模型权重副本。
在此模式下，基座权重常驻显存，LoRA 权重按需加载。
在实际生产环境中部署多 LoRA 服务时，建议遵循以下规范：
max_num_batched_tokens 和 max_num_seqs 以防止 OOM。利用 vLLM 的多 LoRA 部署能力，开发者可以在有限的硬件资源下，以极高的性价比支撑多个垂直领域的 AI 应用。这种方案特别适用于 SaaS 平台、智能助手聚合系统等场景。尽管存在微小的性能损耗，但相比于显存成本的降低和业务灵活性的提升，这一权衡通常是值得的。通过合理的架构设计和资源管理，可以实现大规模模型服务的低成本落地。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online