做過傳統 MLOps 的團隊，對模型發布的基本責任並不陌生

• 資料、模型與執行環境要能重建
• 候選版本先通過離線驗證，再以少量流量觀察
• 上線後持續監控服務等級目標與資料分布，異常時能回到上一個穩定版本。

LLM/Agent的發布沒有讓這些原則失效，卻把發布的對象變大了。

模型行為不只由權重決定，還受到 Tokenizer、對話模板、提示詞、RAG 索引、工具規格、解析器與推論引擎影響；Agent 更可能跨多輪保存狀態，甚至真的退款、寄信或寫入資料。

因此，LLMOps 不是替 MLOps 換一個名字，而是把同一套發布紀律套用到更大的「AI 系統發布版本」。它必須能重建、能驗證、能漸進導入流量，也知道如何整組回退。

現在回到我們一路從 SFT、LoRA、DPO 走到 Online RL 後得到的候選模型。
離線測試顯示，它更符合品牌語氣，退款說明也更完整；但原本 99% 的 Tool Calling 成功率掉到了 94%。平均分數仍然高於基礎模型，該不該上線？我的答案是：先不要。

品牌語氣的進步，不能抵銷退款工具的錯誤呼叫。我們面對的已經不是「哪個 Checkpoint 分數比較高」，而是「哪一整組系統元件有資格接手正式流量」。

這就是模型客製化最後一個容易被忽略的環節：
訓練只能產生候選模型；發布流程才有權決定它能不能取代現行版本。

從 Checkpoint 到 Stable，中間少了什麼？

我們可以先用四個狀態理解模型如何走進正式環境。這不是跨平台標準，而是一個用來釐清責任的心智模型。

這四個狀態代表的不是檔名，而是逐步增加的證據。訓練曲線可以協助挑選 Checkpoint，卻不能授權正式流量；Model Registry 可以保存 Candidate，卻不能證明它已經安全。只有離線驗收、Canary 觀察與回退能力都成立，候選版本才有資格成為 Stable。

Checkpoint 是模型產物；發布版本則是鎖定相依關係、通過驗收，而且知道如何回退的系統版本。

發布版本不是權重，而是一份相容性契約

一個微調後模型真正開始服務請求時，行為並不只由權重決定。

Tokenizer 會把輸入轉成 Token；對話模板會加入角色與控制符號；提示詞會補上產品規則；工具規格與解析器會把模型輸出轉成工具呼叫；量化格式、推論引擎與硬體則共同影響輸出、延遲與容量。

Hugging Face 的 PEFT 格式就是很直接的例子：Adapter Checkpoint 只保存 Adapter 參數，還需要正確的基礎模型與設定才能還原。Transformers 的對話模板文件也提醒，即使模型來自同一個基礎模型，不同微調版本仍可能使用不同的控制 Token；套錯模板，表現可能明顯下降。

目前並沒有跨平台公認的 LLM 發布清單標準。不過，只要某個元件會影響正式請求的輸入、輸出、安全或資源占用，它就應該被綁進同一個發布版本：

1. 模型產物： 基礎模型、完整權重或 Adapter、模型設定，以及精確的 Revision 或 Digest。
2. 互動契約： Tokenizer、對話模板、系統提示詞、取樣設定、工具與結構化輸出規格、解析器。
3. 資料與狀態： RAG 語料、索引與檢索器版本，以及 Session／狀態資料格式。
4. 服務契約： 安全政策、工具權限與決策邊界、量化產物、推論引擎、容器、硬體、容量與租戶路由。
5. 發布證據： 評估資料與關鍵切片、評估流程、各項發布門檻、停止條件、上一個 Stable 版本與負責人。

AWS 在 2025 年發布的生成式 AI 生命週期實務，已把提示詞、模型設定、應用程式與評估資料視為同一份不可變的完整快照。這不是跨平台標準，卻反映出近年的共同方向：發布紀錄要能重建當時真正服務使用者的整套系統。

MLflow Model Registry 可以保存版本、來源執行紀錄、介面簽章、別名與標籤；SageMaker Model Registry 也能管理模型套件與批准狀態。但模型登錄庫只提供版本與升級控制的基礎，不會自動知道提示詞、工具規格、安全規則與成本門檻是否合格。

另一個常見陷阱，是直接以 latest、champion 或 stable 這類別名啟動服務。別名可以移動，適合表示「目前推薦版本」，卻不能作為事故重建的唯一依據。部署紀錄仍要把別名解析成不可變的 Revision 或 Digest，否則同一份設定在不同時間可能載入不同內容。

這是本文第一個重要觀念：真正需要發布與回退的，不是權重，而是這一整組相容性契約。

平均分數不能決定發布

到了發布階段，最危險的做法是把所有指標加權成一個總分。

假設品牌語氣進步 8 分，Tool Calling 退步 5 分，總分仍然增加 3 分。數學沒有錯，但這個加法隱藏了一個重要事實：語氣與退款工具的風險不能交換。

更實用的心智模型，是把發布條件分成三種門檻：

1. 必須改善：這次微調本來想改善什麼？ 例如品牌語氣、政策說明與特定客服意圖。如果目標能力沒有明顯改善，這次發布就失去理由。
2. 不得退步：哪些既有能力不能退步？ 包含安全、拒答、關鍵 Tool Calling、結構化輸出、重要語言與核心任務。這些條件不能被其他分數抵銷。
3. 資源預算：為了這些改善，系統付出多少代價？ 包含尾端延遲、吞吐、GPU 記憶體、逾時、容量與每次成功任務成本。

生成結果具有非決定性，關鍵案例也不能只測一次。實務上應固定取樣設定，對安全與高風險工具案例重複執行，保存成功率分布與失敗樣本。需要多少次取樣取決於風險與事件發生率，沒有一個適用所有系統的魔法數字。

這裡不是要重講 Evaluation，而是把評估結果改寫成真的可以阻止發布的條件。

ICLR 2024 的研究顯示，即使使用者沒有刻意進行惡意訓練，一般微調仍可能讓既有安全行為退化。這不代表每次微調都一定發生同樣程度的問題，但足以支持一項發布原則：基礎模型通過的安全驗收，不能直接繼承給微調後模型。

Tool Calling 也不該只看 JSON 能不能解析。Berkeley Function Calling Leaderboard 會分別檢查函式選擇、參數、沒有適合工具時的判斷、多工具與多輪任務。企業自己的發布門檻還要加入 Sandbox 執行結果與最終狀態，因為格式正確不等於退款真的正確。

所以開頭案例的答案很清楚：品牌語氣確實改善，卻在關鍵 Tool Calling 上違反「不得退步」的門檻。這不是 8 分能不能抵銷 5 分的問題，而是候選版本尚未取得發布資格。

有些模型回歸，其實是整合回歸

Tool Calling 從 99% 掉到 94%，第一個反應不應該是立刻重新訓練。先確認比較的是否真的是「只換模型」的實驗。

新版可能搭配不同的對話模板，讓工具定義被放到錯誤位置；解析器可能不認得新的輸出格式；工具規格也可能同時更改必填欄位、列舉值或函式名稱。這些都會讓結果下降，但問題實際上發生在發布版本的整合邊界，不一定是權重本身。

vLLM 的 Tool Calling 文件要求依模型選擇對應的解析器與對話模板，並列出部分模型在工具呼叫 ID、平行呼叫與參數型別上的限制。結構化輸出文件也顯示，API 欄位與後端能力會隨版本改變。

Qwen 的官方 vLLM 部署說明同樣要求搭配正確的推理／工具解析器與版本。這些例子共同說明了一件事：API 看起來相容，不代表模型行為真的相容。

因此，比較現行版本與候選版本時，要先固定實驗邊界：

• 若只想量測微調的效果，其他相依元件應保持一致。
• 若對話模板、工具規格或推論引擎必須一起改，就把它視為一次聯合發布，不能把差異全部歸功或歸咎於模型。
• 除了最終答案，也要保存實際送入模型的提示詞、Token ID、解析結果與隔離環境中的工具終態，才能知道差異從哪裡開始。

這是第二個重要觀念：模型回歸與整合回歸需要不同修法。沒有先固定發布邊界，重新訓練可能只是修錯地方。

五種發布機制，解決的是五個問題

候選版本通過離線門檻後，仍不應一次接手全部流量。Shadow、Canary、A/B、Fallback 與 Rollback 經常被混成「先放一點流量看看」，實際責任卻完全不同。

AWS 的部署指引明確區分 Shadow、A/B 與 Canary；Seldon Core 2 也把分流給候選版本的流量，與只做 Mirror 的流量分開。名稱相似，不代表可以互換。

對 Agent 而言，Shadow 特別容易被誤用。若我們把正式退款請求複製給新模型，又讓它真的呼叫寫入工具，就可能造成雙重退款。實務上應改用既有工具回應、空操作、Sandbox 或專門的影子環境；但也必須承認，這些結果仍不等於真實副作用已被驗證。

Canary 則需要固定分流。同一段多輪客服對話若前一輪走舊模型、下一輪切到新模型，不只會污染比較，還可能讓工具狀態與對話假設不一致。因此應依 Session、租戶或其他穩定識別，把整段任務固定在同一個發布版本。

先證明退得回去，再讓新版接觸流量

很多團隊是在出事後才第一次測試 Rollback。真正安全的順序應該相反：候選版本尚未接觸正式流量前，先證明上一個 Stable 版本可以重新載入。

有效的回退演練至少要確認：

• 模型登錄庫中的上一版能解析到不可變的發布版本 ID，而不是只剩可移動的別名。
• 在乾淨環境能載入基礎模型、Adapter、Tokenizer、對話模板、提示詞、工具規格、解析器、安全政策、量化產物與推論環境。
• 資料格式、快取、對話狀態與工具狀態能向後相容，或已有明確轉換方式。
• 基本功能、工具契約與健康檢查可以通過，舊版本也有足夠容量接回流量。
• 高風險寫入使用冪等鍵，避免重試造成重複退款或寄信；已發生的副作用另以對帳與補償流程處理，必要時交由人工確認。

這也是 2026 年 AWS Agentic AI Lens 的冪等執行實務所強調的方向：Agent 重試時，不能把同一個動作再做一次；工具使用的安全實務也把權限檢查放在執行層，而不是只依賴提示詞約束模型。

SageMaker Deployment Guardrails 可以在 Canary 觀察期間依 CloudWatch Alarm 自動回退；Argo Rollouts 也能根據 AnalysisRun 的成功或失敗條件繼續或中止。但工具只會執行團隊定義的規則，不會替我們決定什麼風險值得停止。

目前也沒有一組通用的 Canary 百分比、觀察時間或 Rollback 門檻。流量比例必須配合事件風險、樣本量、租戶與地區分布設定。樣本不足代表結果仍不確定，不是通過；等待時間到了，也不應自動升版。

可以參考這五步完成模型發布

把前面的概念收斂成實際流程，順序如下：

1. 固定發布單位。 鎖定模型、輸入輸出契約、服務契約與發布證據；部署時記錄不可變的發布版本 ID。
2. 建立不可抵銷的門檻。 目標能力必須改善，安全與關鍵工具不得退步，延遲、容量與成本不得超出預算。
3. 先演練 Rollback。 在乾淨環境重建上一個 Stable 版本，驗證路由、容量與狀態相容性，並準備副作用補償流程。
4. 先 Shadow，再 Canary。 Shadow 找出真實輸入下的整合與成本差異；Canary 以固定分流限制故障範圍。任一強制門檻失敗都要立即停止。
5. 最後才更新 stable 別名。 只有樣本量、關鍵切片、觀察時間與停止條件都通過，才讓 stable 指向新的不可變版本 ID。

發布期間還有一條底線：所有評估、指標與 Trace 都必須能對應到確切的發布版本 ID、流量分組與 Adapter Digest。2026 年的 OpenTelemetry 生成式 AI 語意慣例已開始涵蓋推論、Agent、Tool 與 MCP，但部分規格仍在演進，還不能當成完整且穩定的標準。團隊至少要先固定自己的版本 ID，讓系統知道哪一版出錯，並能自動停止或回退。

NVIDIA GenAI-Perf 會分開量測首個 Token 延遲、Token 間延遲、請求延遲與吞吐。2026 年發布的 MLPerf Endpoints v0.7 更把模型、軟體與硬體視為同一個受測系統，並同時觀察吞吐、互動速度、p95 首個 Token 延遲與併發量。

因此，服務門檻應使用真實的輸入與輸出長度分布，分開測試冷快取與暖快取，觀察不同併發量下的效能曲線，而不是拿單一平均延遲或最高 Tokens/s 宣布新版更快、更便宜。

模型從訓練走向正式環境，真正的演化不是檔名從 checkpoint 改成 final，而是證據逐步增加：Checkpoint 證明模型曾被保存；Candidate 證明相依元件已被鎖定；Canary 代表它正在接受受控流量驗證；Stable 才表示它已通過漸進發布。

所以 Day29 最值得記住的不是某一套模型登錄庫或 Canary 工具，而是這個發布順序：先固定發布單位，再建立不可抵銷的門檻；先證明退得回去，再讓新版接觸真實流量。

AI 你怎麼看？

明天終於到了系列的最後一天啦！好期待！

延伸閱讀

• Hugging Face PEFT Checkpoint Format
• Hugging Face Chat Templates
• MLflow Model Registry Workflows
• AWS SageMaker Deployment Guardrails
• AWS：Shadow、A/B 與 Canary Deployment
• Seldon Core 2 Experiments
• vLLM Tool Calling
• Qwen：使用 vLLM 部署
• NVIDIA GenAI-Perf
• AWS Generative AI Lifecycle Operational Excellence
• OpenTelemetry Generative AI Semantic Conventions
• MLPerf Endpoints
• AWS Agentic AI Lens：Idempotent Execution