vLLM 多 LoRA 服务用于 MoE 模型

vLLM 引入了一种高效的多低秩适配（Multi-LoRA）服务解决方案，使组织能够在单个 GPU 上托管数十个微调模型。这消除了为每个自定义模型设置专用计算端点的需求，因为当单个模型的流量不足以饱和其硬件时，往往会导致 GPU 空闲。

多 LoRA 服务用于 MoE 模型

Multi-LoRA 通过保持原始基础模型权重冻结，并在每个请求中切换小型可训练适配器，实现多个自定义模型共享同一 GPU。这对混合专家（MoE）模型尤为有利，因为路由器会将输入 token 引导至专门的神经网络（专家）。

在 MoE 架构中，每个专家采用“先扩展后压缩”的模式：gate_up 投影将隐藏状态扩展到更大的中间空间，down 投影再将其压缩回来。当应用 LoRA 时，每个专家需要四个额外的 kernel 操作：对 gate_up 和 down 投影分别进行收缩和扩展操作。

为了解决此问题，vLLM 实现了 fused_moe_lora kernel。该 kernel 将 LoRA 操作直接集成到 fused_moe kernel 中，管理由专家路由（token 被分配到不同专家）和适配器选择（请求使用不同 LoRA 适配器）共同产生的稀疏性。

性能技术优化

最初的多 LoRA 在 MoE 模型上的实现存在高延迟。vLLM 与 AWS 使用 NVIDIA Nsys 和 NCU 识别并通过三大优化层解决瓶颈：

执行优化

分析发现 Triton 编译器将与输入长度相关的变量视为编译时常量，导致 fused_moe_lora kernel 在每个新上下文长度时都重新编译。这使得相较于基础模型的首 token 时间（TTFT）出现了 10 倍的回退。通过添加 do_not_specialize 编译器提示，确保 kernel 只编译一次并在所有上下文长度中复用，从而解决了该问题。

Kernel 级别优化

由于 LoRA 矩阵是“瘦矩阵”（秩 r 远小于隐藏状态维度），标准 GEMM kernel 表现不佳。实现了以下优化：

• Split‑K 工作分解： 该策略将内部维度 K 的求和拆分到多个线程组中，并行计算部分和，以提升瘦矩阵的负载均衡。原子加操作使用 Triton 编译器中的 sem="relaxed" 进行优化。
• CTA 交错（Swizzling）： Cooperative Thread Array（CTA）交错重新安排 GPU 调度，使得处理相邻列的线程组同时运行，提升 L2 缓存复用。
• 掩码化简（Masking Reduction）： 引入 EVEN_K 参数，以在矩阵维度能整除块大小时跳过条件掩码检查，从而降低每次加载操作的开销。
• Kernel 融合： 将 LoRA 权重与基础模型权重的相加融合到 LoRA 扩展 kernel 中，以减少 kernel 启动开销。

亚马逊特定调优

针对标准融合 MoE 优化的默认 Triton kernel 配置未考虑多 LoRA 的复合稀疏性。AWS 为四个 fused_moe_lora 操作（gate_up_shrink、gate_up_expand、down_shrink、down_expand）开发了自定义调优配置。这些配置会在使用 Amazon SageMaker AI 和 Amazon Bedrock 的客户中自动加载。

性能基准与可用性

这些优化显著提升了 GPT-OSS 20B、Qwen3-MoE、DeepSeek、Llama MoE 等 MoE 模型以及 Llama 3.3 70B、Qwen3 32B 等密集模型的性能。

对于 GPT-OSS 20B，从 vLLM 0.11.1rc3 升级到 vLLM 0.15.0，使每秒输出 token 数（OTPS）提升了 454%，首 token 时间（TTFT）降低了 87%。在 Amazon SageMaker AI 和 Amazon Bedrock 上可用的进一步优化相比 vLLM 0.15.0 额外提升 OTPS 19%，并将 TTFT 再降低 8%。

GPT-OSS 20B 结果摘要：

版本/平台	OTPS	TTFT
vLLM 0.11.1rc3	32 (初始)	~1.2s (估计)
vLLM 0.15.0	144	135 ms
Amazon SageMaker/Bedrock	171	124 ms

这些改进在 vLLM 0.15.0 及以上版本可用。