AWS携手vLLM推出Multi-LoRA，终结大模型微调算力浪费与高成本！

关注

原创最新推荐文章于 2026-07-26 12:03:26 发布 417 阅读 AI 写同款· GEO 优化 ›

RTX AI PC 和工作站上部署多样化 AI 应用支持 Multi-LoRA LoRA 是一种热门的参数高效微调技术，可以调节少量参数。其他参数称为 LoRA 适配器，表示网络密集层中变化的低秩分解。只有这些低级别的附加适配器是自定义的，而在此过程中，模型的剩余参数会被冻结。经过训练后，这些适配器将在推理期间通过合并到基础模型进行部署，从而在推理延迟和吞吐量方面尽可能减少，甚至不增加任何开销。图 1. A 和 B 中的参数表示可训练的参数，以展示 LoRA 技术（来源：LoRA：大型语言模型的低阶适应图 1 展示了有关 LoRA 技术的更多详细信息。阅读详情

本文重点介绍 AWS 联合 vLLM 社区推出的 Multi-LoRA 解决方案，专治大模型微调部署中“算力闲置率高、成本高昂”的痛点。

针对 MoE（混合专家）模型叠加 LoRA 带来的“双重稀疏性”和内核计算复杂度，AWS 开发了融合算子 fused_moe_lora。
通过引入 do_not_specialize 解决编译造成的首字延迟（TTFT）暴涨、使用 Split-K 与 CTA Swizzling 优化瘦高矩阵计算、以及利用 EVEN_K 跳过无效掩码检查，成功提升了系统的吞吐量（OTPS）。
目前该技术已在 vLLM 0.15.0+ 中全面支持，开发者只需简单配置即可实现单 GPU 挂载多模型的极速推理。挂载方法见正文。

先说痛点

你们有没有遇到过这种情况：

公司有5个不同的微调模型（可能是不同业务场景、不同客户定制的），每个模型单独部署都只占用10%的GPU算力。

**结果：**5个GPU各自闲着90%的算力，钱包刺客拉满了。💸

以前没辙，现在 AWS 联合 vLLM 社区给出了解决方案：Multi-LoRA。

什么是 Multi-LoRA？

先回顾一下 LoRA 的基本原理 🔧

LoRA（Low-Rank Adaptation）不做全参数微调，而是：

冻结原始权重 W（几百GB的基座模型不动）
额外训练两个小矩阵 A 和 B
推理时：输出 = xW + xAB

A 的shape：h_in × r（r通常是16-64）
B 的shape：r × h_out

💡 这样一份基座模型，可以同时挂载多个 LoRA 适配器。推理时动态切换，哪个请求用哪个适配器，GPU 共享！

**📌 想象一下：**5个客户每人只占用10%的GPU，现在可以拼单到1个GPU上跑。

⚠️ MoE + LoRA = 地狱难度

问题来了：如果是 MoE（混合专家）模型，那就更复杂了。

技术难点1：每个 Expert 需要4个 LoRA 操作

MoE 模型的每个 Expert 有两个投影：

**gate_up：**展开 hidden state（4096 → 11008 维）
**down：**压缩回去（11008 → 4096 维）

每个投影需要两个 LoRA 操作：

**shrink：**xA（高维 → 低维 r）
**expand：**xB（低维 r → 高维）

所以 每个 Expert 需要4个 LoRA kernel 操作，比普通模型复杂得多。

技术难点2：两 sparsity 叠加

MoE 本身就有 expert routing（路由选择哪些 expert 激活），现在又加了 adapter selection（请求用哪个 LoRA），两种稀疏性叠加，需要全新的内核设计。

📌 之前 vLLM 没有针对 MoE 的 LoRA 内核，现成的 dense multi-LoRA 内核根本搞不定 expert routing。

解决方案：fused_moe_lora kernel

AWS 团队自己写了个融合内核 fused_moe_lora，把 LoRA 操作直接融合进 MoE 的 forward 过程。

核心思路：

复用 fused_moe 的逻辑
增加一个维度：LoRA index
一次 kernel 调用完成所有计算

但这只是开始，真正的坑在后面。

优化路上的三个大坑 🕳️

坑1：TTFT 暴涨 10 倍

优化前测试，Multi-LoRA 的 TTFT（首token延迟）比基线模型高了 10 倍。

用 NVIDIA Nsight 一查，好家伙：Triton 编译器把 输入长度相关的变量当成编译时常量，每次不同 context length 就重新编译一次。GPU 在那儿等着编译完才能跑，中间空转。

👉 **解决方案：**加 do_not_specialize 编译提示，告诉 Triton 别犯傻，一次编译到处复用。

坑2：矩阵太瘦，GPU 不会算

LoRA 的 shrink/expand 操作，矩阵维度是：1 × h_in 乘 h_in × r。

r 通常是 16-64，但 h_in 是 4096，差了 100-300 倍。标准 GEMM 内核是为接近方形的矩阵设计的，遇到这种瘦高矩阵直接摆烂。

👉 解决方案：

💡 策略1：Split-K 切分求和策略
💡 策略2：CTA Swizzling 提高缓存命中率

坑3：大量无意义的 Mask 检查

Triton 内核按固定块大小加载数据，但矩阵维度不一定能整除。

👉 **解决方案：**加个 EVEN_K 参数，能整除就跳过所有 masking 检查。

调参：隐藏的大Boss

内核写完了，还要调参。Triton 内核有大量超参：BLOCK_SIZE_M / N / K、GROUP_SIZE_M、SPLIT_K…

但默认配置是为标准 fused MoE 优化的，根本不管 LoRA 那多出来的维度。AWS 团队针对 MoE LoRA 场景专门调了一版参数，用在 SageMaker AI 和 Bedrock 上。

性能数据 📊

指标	vLLM 0.11.1rc3	vLLM 0.15.0	AWS 优化版
OTPS	-	+454%	+19%
TTFT	-	-87%	-8%

测试模型：GPT-OSS 20B（MoE），输入1600 tokens，输出600 tokens，LoRA rank=32，8个 adapter 并行。

📌 顺带一提，部分优化对 dense 模型也有效。Qwen3 32B 的 OTPS 提升了 99%。

总结一下

优化手段	效果
do_not_specialize	解决 10× TTFT 问题
Split-K + CTA Swizzling	解决瘦矩阵计算效率
EVEN_K	去掉无意义 masking
专用参数调优	额外 19% OTPS 提升

现在 vLLM 0.15.0+ 已经支持 Multi-LoRA，MoE 模型包括：GPT-OSS、Qwen3-MoE、DeepSeek、Llama MoE。

💻 快速上手指南

既然最新版已经全面支持了，我们怎么在生产环境把它跑起来呢？非常简单，并且完全兼容 OpenAI 的 API 规范：

1. 启动 vLLM 服务

在启动基座模型时，只需要加上 --enable-lora 参数，并使用 --lora-modules 指定你要挂载的 LoRA 适配器及路径即可：

vllm serve Qwen/Qwen3-MoE-A2.7B-Instruct \
--enable-lora \
--lora-modules lora-customerA=/path/to/customerA_lora \
lora-customerB=/path/to/customerB_lora \
--max-loras 4

2. 客户端调用

服务启动后，在客户端发送请求时，只需将 model 参数替换为你想要使用的特定 LoRA 名称（例如 lora-customerA）。vLLM 底层会自动为你完成计算和路由，无需手动切换权重！

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \
-d '{ "model": "lora-customerA", "messages": [ {"role": "user", "content": "你好，请根据客户A的特定业务场景回复我。"} ] }'

💡 核心收益： 只要并发的 LoRA 数量不超过配置的 --max-loras 限制，你就可以在同一个物理基座模型上，同时处理多个截然不同的微调任务。显存占用极小，计算效率起飞！🚀

什么是AI大模型应用开发工程师？

如果说AI大模型是蕴藏着巨大能量的“后台超级能力”，那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。

AI大模型应用开发工程师是基于AI大模型，设计开发落地业务的应用工程师。

这个职业的核心价值，在于打破技术与用户之间的壁垒，把普通人难以理解的算法逻辑、模型参数，转化为人人都能轻松操作的产品形态。

无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能，还是办公场景中的自动记账工具、会议记录用的语音转文字APP，这些看似简单的应用背后，都是应用开发工程师在默默搭建技术与需求之间的桥梁。

他们不追求创造全新的大模型，而是专注于让已有的大模型“听懂”业务需求，“学会”解决具体问题，最终形成可落地、可使用的产品。