介面卡的線上管理：熱切換與多租戶服務

服務端的設定

# vLLM 啟用多 LoRA
python -m vllm.entrypoints.openai.api_server \
  --model base/qwen3-8b \
  --enable-lora \
  --max-loras 8 \
  --max-lora-rank 32 \
  --lora-modules \
     ticket-cls=/adapters/ticket-cls-v4 \
     summarize=/adapters/summarize-v2 \
     acme-tone=/adapters/acme-tone-v1

請求端指定介面卡

resp = client.chat.completions.create(
    model='ticket-cls',          # 用介面卡名稱作為 model
    messages=[...],
)

三個容量參數

• max-loras：同時常駐在顯示記憶體中的介面卡數。超過時會換出換入，有延遲成本。
• max-lora-rank：所有介面卡的 rank 上限，會影響預留的記憶體。
• 介面卡總數可以遠大於 max-loras，只是熱門的要盡量常駐。

熱切換的延遲

介面卡換入需要從磁碟載入並複製到顯示記憶體，通常是數十到數百毫秒。若流量在很多介面卡之間平均分散，換入換出會頻繁發生，延遲上升明顯。

# 監控換入率，過高就要提高 max-loras 或分流部署
lora_swap_rate = swaps_per_min / requests_per_min
if lora_swap_rate > 0.15:
    alert('介面卡換入過於頻繁，考慮增加常駐數或按介面卡分流')

版本更新不中斷

1. 新版介面卡用新名稱註冊（ticket-cls-v5），不覆寫舊版。
2. 在路由層調整流量比例，逐步從 v4 移到 v5。
3. 穩定後再卸載 v4。

因為介面卡是獨立檔案，這個流程不需要重啟服務，也不影響其他任務。這是相較於「合併權重後部署」的最大優勢。

多租戶的隔離考量

• 介面卡名稱要做權限檢查：不能讓 A 客戶指定 B 客戶的介面卡。
• 用量與計費要分租戶統計。
• 單一租戶的流量上限：避免一個客戶的批次任務拖垮共用服務。