我們已經決定用 SFT，讓退款 Agent 從正確示範中學會如何查詢證據、選擇工具，以及在什麼時候停止。資料也不再只是完整保存一段成功紀錄，而是要呈現模型當下看見什麼、應該做出什麼決策。

資料準備好之後，下一個問題才是：
為了讓模型學會這些行為，我們要更新整個模型，還是只訓練這次任務需要的差異？

有哪些關鍵呢?

如果更新全部權重，走的是全參數微調；如果希望保留底座模型，只訓練少量新增參數，就會進入參數高效微調，而 LoRA 是其中最常見的方法。QLoRA 則是在 LoRA 之上，進一步降低訓練時底座模型占用的顯存。

要繼續往下選方法，必須先把 SFT 與 LoRA 家族放回正確的層級：

• SFT 決定模型從什麼訓練訊號學習。
• 全參數微調與參數高效微調，決定要更新多少模型參數。
• LoRA 是參數高效微調的一種實作。
• QLoRA 是 LoRA 的延伸，重點是把訓練時凍結的底座量化，降低顯存需求。

把這個層級分清楚，後面的問題才不會混在一起：LoRA 能不能達到全參數微調的效果？QLoRA 到底省下什麼？當十個品牌各有一個 Adapter 時，線上成本是否也會跟著下降？

第一個分岔：更新整個模型，還是只保存任務差異？

SFT 的核心是一組輸入與理想輸出。模型根據示範計算損失，再調整參數，讓理想答案更容易出現。至於要調整全部權重，還是只調整少量新增參數，並不是 SFT 本身規定的。

全參數微調可以讓模型每一層都配合任務改變，適合任務與底座能力差距很大、資料充足，而且團隊能負擔訓練與版本成本的情境。代價是每次實驗都要維護完整權重的梯度與優化器狀態，最後產生的模型版本也接近底座本身的大小。

但退款 Agent 想學的通常不是一套全新的語言能力，而是較明確的行為差異，例如證據不足時不要退款、查詢失敗時改走人工流程，或完成操作後不要繼續呼叫工具。這類需求讓參數高效微調變得有吸引力：保留既有底座，只保存任務帶來的改變。

這不是說任務看起來簡單就一定該用 LoRA，而是先建立一個成本較低的基準。若 LoRA 達不到品質要求，再提高容量或加入全參數微調比較，而不是一開始就支付最昂貴的訓練與版本成本。

LoRA 家族究竟改了什麼？

LoRA（Low-Rank Adaptation，低秩調適）凍結原本的底座權重，另外訓練一組低秩矩陣，用來表示任務需要的權重差異：

W = W0 + BA

W0 是凍結的底座權重，BA 是訓練後得到的差異。rank 決定這個差異空間的容量；提高 rank 通常會增加可訓練參數、Adapter 大小與運算量，但不保證品質會持續上升。

因此，LoRA 省下的不是「模型本體」，而是每次任務需要訓練和保存的差異。部署時仍然要有相符的底座模型、分詞器與對話模板，Adapter 無法單獨回答問題。

原始 LoRA 論文在 GPT-3 175B 的案例中，把 Adam 訓練顯存從 1.2TB 降到 350GB。只調整注意力機制中的 query 與 value 投影矩陣，且 r=4 時，模型檢查點由 350GB 降到 35MB；同一設定的訓練吞吐量則由每張 V100 每秒 32.5 tokens 提升到 43.1 tokens。

這組數字最值得注意的地方，不是 35MB 看起來有多小，而是不同成本下降的幅度完全不同。版本大小可以縮小數千倍，訓練速度卻不會提高數千倍，因為資料仍要通過底座模型完成前向與反向計算。

QLoRA 是 LoRA 的延伸，不是另一個訓練目標

LoRA 雖然只更新少量參數，訓練時仍要把凍結的底座放進 GPU。模型愈大，光是保存這份底座就可能超出單張顯示卡的容量。

QLoRA解的是這個問題。它保留 LoRA 的低秩差異訓練，但把凍結的底座以 4-bit 形式放入記憶體，並搭配 NF4、雙重量化與分頁優化器，進一步降低訓練顯存。

論文把 65B 模型的一般 16-bit 微調顯存需求，從超過 780GB 降到低於 48GB；雙重量化平均再替每個參數省下約 0.37 bit，換算約 3GB。

不過，這裡不能直接得到「QLoRA 沒有品質代價」的結論。該研究八組 MMLU 實驗的平均分數，是 BF16 LoRA 53.0、FP4 52.2、NF4 加雙重量化 53.1；平均值相近，個別組合仍有差距。例如 33B 模型搭配 FLAN v2 時，NF4 為 59.2，BF16 為 60.5。

更容易被忽略的是：QLoRA 處理的是訓練階段如何保存凍結底座，不代表線上模型已完成推論量化。 最後使用什麼權重格式、推論引擎與 KV cache 精度，仍然要分別決定並驗收。

到這裡，三者的關係可以濃縮成一句話：SFT 定義模型要模仿的答案，LoRA 定義如何只保存任務差異，QLoRA 再降低訓練時保存底座的顯存成本。

LoRA 能不能取代全參數微調？

LoRA 的成本優勢很明確，但真正的工程問題仍是：少量差異參數，是否足以學會目標行為？

2026 年 9 月公開的 Post-Training Science 研究，比較九個 Qwen 與 Llama 模型、四種正式環境任務，共規劃 1,008 組實驗，其中 970 組通過有效性條件。每組使用 5,000 筆資料並訓練一個週期。

在模型、資料與批次大小對齊的 72 組比較中，全參數微調的驗證損失全部等於或優於 LoRA；但 LoRA 只訓練 3.1% 到 12.6% 的參數，就保留了全參數微調相對底座改善幅度的中位數 98%。

這個結果同時否定兩個過度簡化的說法：LoRA 並非只能做表面調整，但也不是全參數微調的無條件替代品。

研究還發現，LoRA 與全參數微調適合的學習率不同；rank 從 32 增加到 64 的差距已經很小，增加到 128 也沒有穩定改善。由於這是使用匿名資料、尚未同儕審查的預印本，不能把特定 rank 或學習率當成通用答案。更可靠的做法，是讓 LoRA 擁有自己的實驗設定，不要直接沿用全參數微調的參數後，只比較誰比較省顯存。

對退款 Agent 而言，可以先以 LoRA 或 QLoRA 建立基準，檢查關鍵行為是否真的改善；若失敗集中在模型無法吸收的新能力，再把全參數微調加入比較。方法的選擇應該由能力差距與實驗結果決定，而不是由模型大小單獨決定。

從一個 Adapter 到多個 Adapter，問題開始改變

單一任務完成後，團隊通常會很快遇到下一個需求：不同品牌、地區或產品線，能不能各自擁有一份 Adapter，又繼續共用同一個底座？

這時常會看到「Multi-QLoRA」這類說法，但它不是一個足以描述架構的固定方法。實際上，至少有三種不同問題：

1. 多種任務是否要共同訓練一個 Adapter？
2. 多個已經訓練好的 Adapter，能不能在推論時組合？
3. 多個租戶的 Adapter，能不能在線上共用底座與 GPU？

多任務共同訓練

2026 年的多任務 QLoRA 研究，讓同一個模型共同學習程式生成、程式翻譯與程式摘要，並比較單任務 QLoRA、多任務 QLoRA 與多任務全參數微調。實驗涵蓋 1.5B、3B 與 7B 模型。

研究顯示，多任務 QLoRA 可以透過任務間轉移，在多個設定中達到相當或更好的結果；較小模型雖能維持功能正確性，程式品質問題卻較常出現。這是尚未同儕審查的預印本，而且研究的是程式任務，不能直接推論十個客服品牌一定適合共同訓練。

它回答的是：多種任務是否應該共同改變同一組參數？

多個 Adapter 在推論時組合

另一篇 2026 年研究分別訓練控制情緒、主題與多重屬性的 QLoRA 模組組合，再比較共同訓練、合併權重，以及推論時加總不同模組輸出。實驗使用三種模型與三組文字控制資料。

其中，直接加總多個模組輸出的方式，整體表現相當或優於其他方案；在情緒控制的單任務測試中，三個模組組合平均增加約 2 個百分點。

它回答的是：分開訓練的能力能否臨時組合，而不必為每種組合重新訓練？這同樣是預印本，而且場景是受控文字生成，距離 Agent 的工具決策仍有一段距離。

多個租戶共用底座

Multi-LoRA 服務處理的是另一個層級：每個品牌保有自己的 Adapter，但線上請求共用底座模型、GPU 與批次。

2025 年 NeurIPS 的 Loquetier 把 LoRA 訓練與推論整合在同一套執行環境，讓不同 Adapter 共用底座並共同批次。論文在三種任務設定中，最高達到既有共同服務系統三倍的純推論吞吐量；在訓練與推論並行的設定中，SLO 達成率最高提高 46.4 倍。

2025 年正式發表於 ICML 的 Compress then Serve，則把一批 LoRA 壓縮成共享基底與各自的小矩陣。實驗涵蓋最多 1,000 個 LoRA；在超過一千個 Adapter 的服務情境中，仍能維持單一 LoRA 服務約 80% 的吞吐量。

這些數字都依賴論文中的硬體、流量與比較基線，不能直接當成正式環境的容量預估。它們揭示的重點是：當 Adapter 數量增加，問題不再只是單一檔案多小，而是底座、Adapter 記憶體與請求批次能否共同設計。

訓練省下來的成本，為什麼不一定延伸到線上？

假設十個客服品牌共用相同的底座版本、分詞器、對話模板與模型架構；政策知識仍由 RAG 或工具提供，交易權限仍由執行環境限制。

線上大致有三種部署方式 :

• 第一種是每個品牌各自部署完整模型。隔離最強，也能使用不同底座，但訓練、預熱、儲存與閒置 GPU 的成本最高。

• 第二種是把每個 Adapter 分別合併回底座。線上仍然是十套完整模型，推論路徑較單純，延遲也容易預測；代價是跨品牌無法共同批次，GPU 成本仍接近十套模型。

• 第三種是共享底座，依照請求動態載入 Adapter。低、中流量的品牌可以共同批次，才有機會把訓練階段的版本優勢延伸到線上；相對地，團隊必須處理 Adapter 路由、快取、冷載入、租戶互相干擾與共同故障。

實務上不必三選一。
高流量或延遲要求嚴格的品牌，可以部署合併後的獨立模型；長尾品牌則共用底座，並讓常用 Adapter 留在 GPU。選擇依據不是 Adapter 檔案大小，而是真實流量能否形成有效批次。

小型 Adapter 沒有讓版本責任消失

Adapter 不能只保存一個 .safetensors 檔。每個可發布版本至少要綁定：

• 底座模型、分詞器與對話模板版本。
• 目標模組、rank、alpha 與訓練精度。
• QLoRA 的量化格式與計算精度。
• 訓練資料、程式版本與評估結果。
• 合併狀態、推論引擎、硬體與線上量化產物。

單一 Adapter 出錯時，可以只回滾一個品牌；底座升級卻會成為所有品牌的共同遷移。只要分詞器、對話模板或目標模組改變，所有 Adapter 都要重新驗收。

因此，方法選擇可以按照以下順序進行：

1. 先確認要解的是 SFT 的實作成本，而不是資料或評估問題。
2. 用固定資料與評估集建立 LoRA 或 QLoRA 基準，必要時再加入全參數微調，確認品質差距。
3. 記錄最高顯存、訓練吞吐量、達到目標所需的 GPU 時數與版本大小。
4. 用真實流量比較合併部署與 Multi-LoRA 的首個 token 延遲、P95／P99、整體吞吐量與每百萬 token 成本。
5. 演練單一 Adapter 回滾、底座升級、快取未命中與錯誤路由。

LoRA／QLoRA 首先降低的是訓練與版本成本。它們能否降低線上成本，還要看底座是否真的共享、流量能否共同批次，以及版本責任是否可控。

AI 你怎麼看？

工程師：「所以決定做 SFT 之後，還沒決定要更新多少參數？」

AI：「對。LoRA 家族解的是怎麼更新；QLoRA 再處理訓練時的底座顯存。」

當模型已經能透過 SFT 模仿正確示範，而且我們也找到了可負擔的訓練方式，下一個問題才會出現：如果兩個答案都能完成任務，模型要如何知道哪一個更好？接下來會進入偏好學習與 DPO。

延伸閱讀

• LoRA: Low-Rank Adaptation of Large Language Models
• QLoRA: Efficient Finetuning of Quantized LLMs
• Post-Training Science for Supervised Fine-Tuning
• Parameter-Efficient Multi-Task Fine-Tuning in Code-Related Tasks
• Output Composability of QLoRA PEFT Modules
• Loquetier: A Virtualized Multi-LoRA Framework
• Compress then Serve