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（CTA 交錯）： 合作執行緒陣列（CTA）交錯會重新排程 GPU，使得處理相鄰列的執行緒群組同時執行，提升 L2 快取的重用率。
• Masking 簡化： 引入 EVEN_K 參數，以在矩陣維度能整除區塊大小時跳過條件遮罩檢查，減少每次載入操作的開銷。
• Kernel 融合： 將 LoRA 權重加到基礎模型權重的操作融合進 LoRA 擴張 kernel，以降低 kernel 啟動開銷。

針對 Amazon 的調校

針對標準 fused 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 再提升 19% OTPS，並將 TTFT 再降低 8%。

GPT-OSS 20B 結果摘要：

版本/平台	OTPS	TTFT
vLLM 0.11.1rc3	32（初始）	約 1.2 秒（估計）
vLLM 0.15.0	144	135 毫秒
Amazon SageMaker/Bedrock	171	124 毫秒

這些改進在 vLLM 0.15.0 版或更新版本中可用。