ML 部署策略——A/B 測試、Shadow、Canary 與 Blue/Green

ML 部署策略是 MLA-C01 最直接測試 MLOps 成熟度的地方。替換生產中的模型並不等同於替換一個 Lambda 函數——模型行為可能在生產環境中因在離線評估中從未出現的原因而偏移（訓練-服務偏差、分布偏移、測試集從未涵蓋的邊界輸入），而錯誤的切換策略可能在任何人注意到之前就讓業務指標降級數小時。考試用以下短語設置題幹：「部署新模型時最小化風險」、「以真實流量比較新模型與當前生產模型」、「漸進式流量轉移並自動回滾」，以及「以零客戶影響驗證新模型」——每個短語都對應到恰好一種策略：A/B 測試、shadow、canary 或線性、blue/green。混淆這些是 MLA-C01 最常被引用的錯誤。

本指南介紹五種部署策略（生產 variant 的 A/B 測試、blue/green、canary、線性、shadow），然後介紹自動化回滾的 SageMaker 部署護欄功能，接著是與 Model Registry 和 SageMaker Pipelines 整合的端到端 CI/CD。本文以 ML Engineer 的角度撰寫——配置什麼、哪些 CloudWatch 指標對回滾觸發器重要，以及考試測試的精確區別。

為何部署策略對 ML 特別重要

軟體部署以眾所周知的方式失敗：5xx 錯誤率激增、記憶體洩漏、資料庫遷移出錯。ML 部署還以額外、更微妙的方式失敗：一個離線評分良好但因訓練-服務偏差而線上表現不佳的新模型、一個 99% 的輸入處理得更好但在關鍵的 1% 邊界案例上嚴重降級的模型，或者一個平均延遲特性可接受但有嚴重 P99 尾部違反 SLA 的模型。部署策略是在所有流量暴露之前捕捉這些失敗的工程控制機制。

錯誤切換的成本

直接的就地模型替換（刪除舊的 endpoint 配置，附加新模型）意味著 100% 的流量立即命中新模型。如果新模型有問題，每個使用者從第一秒起就看到問題行為，直到團隊偵測到、決定回滾並執行回滾——通常需要幾分鐘到幾小時。對於高風險模型（詐欺偵測、推薦、定價），即使幾分鐘的問題行為也會轉化為收入損失、客戶流失或監管風險。部署策略是限制爆炸半徑的緩衝器。

MLOps 成熟度曲線

成熟度第一層：替換 endpoint 配置，交叉手指。第二層：blue/green 配合手動回滾。第三層：canary 配合 CloudWatch 警報的自動回滾。第四層：shadow 部署，在任何切換前以零客戶暴露的方式在真實流量上驗證新模型。MLA-C01 考試期望你瞭解全部四層，並能為給定的風險級別選擇正確的一層。

白話文解釋 ML 部署策略

五種策略在抽象層面感覺相似，直到你把它們對應到大多數人親身經歷過的實體部署模式。

類比一：連鎖便當店更換菜單

想像一家連鎖便當店在 100 個據點推出新版招牌菜。直接切換是週一早上 9 點在所有地方同時換菜——每家店的每位客人從第一分鐘就吃到新菜。如果菜不對，所有客人同時不滿意。Blue/green 是同時開兩個廚房——現有廚房（藍）繼續供應舊菜，新廚房（綠）完全準備就緒，然後在選定時刻一次性把所有訂單從藍切到綠。如果綠出問題，切回藍（還是熱的在運行）。Canary 是先在兩個據點推出新菜，觀察一週的客訴和食安問題，再擴展到十個，再到全部 100 個——初始爆炸半徑小，漸進擴展。線性是同樣的想法但以固定的排程步驟：週一 10%、週二 20%，一路到週五 100%，不管反饋如何。Shadow 部署是最謹慎的——每個客人的訂單都送到現有的菜（藍）並提供服務，但平行廚房也做了新菜（綠）後丟棄，僅供試吃比較；沒有客人真的吃到新菜，直到 shadow 驗證完成。A/B 測試是讓兩種菜在同一家店同時供應，隨機一半客人吃新菜一半吃舊菜，然後統計比較滿意度——保留贏的那道菜。每種模式對應不同的風險容忍度和要問的不同問題。MLA-C01 題幹用問題的措辭告訴你哪種策略是答案。

類比二：醫院的藥物試驗流程

想像一家製藥公司將新藥從研發推向廣泛使用。直接切換是第一天就把藥放進所有藥局——最快、最冒險，在受監管的行業絕不這樣做。Blue/green 是在切換日期保持舊藥完全備貨並同時向所有藥局分發新藥——如果新藥出現副作用，召回恢復舊藥（還在庫存中）。Canary 是 FDA 的一期/二期/三期試驗結構——給 100 位患者、然後 1,000 位、然後 10,000 位，在每個階段觀察不良事件，如果任何閾值被突破就停止。線性是批准後的排程推廣——第一週 10% 的藥局、第二週 30%，按固定排程在第四週全面覆蓋。Shadow 部署是 FDA 的平行追蹤研究，對照組繼續使用現有藥物，試驗組使用新藥，兩組的結果不影響另一組的治療決策。A/B 測試是隨機對照試驗——一半按現有護理標準，一半按新藥，統計比較結果，採用贏家。醫療行業的風險厭惡心態正是 MLA-C01 考試用於高風險 ML 的思維模型——詐欺模型、醫學影像模型、金融定價模型——其中 shadow 和 canary 比 blue/green 或直接切換更受青睞。

類比三：跨河橋樑重建

想像替換一座繁忙橋樑。直接切換是週六早上關閉舊橋、下午開放新橋——最快，但如果新橋有結構問題，河流通道就被阻斷了。Blue/green 是在舊橋旁邊平行建造新橋，在過渡週末保持兩座橋都開放，然後一旦新橋交通順暢就關閉舊橋——如果需要可以立即回滾重新開放舊橋。Canary 是只開放新橋的一條車道，觀察一週的問題，然後隨著信心增長開放更多車道。線性是排程的一車道一車道開放——週一一條、週三兩條、週五全部開放。Shadow 部署是工程師的平行測試——新橋在結構上完整且承受模擬的交通負載（用沙袋和水車測試），但在驗證通過前沒有公眾交通通行。A/B 測試是同時開放兩座橋，南向的一半交通走舊橋、一半走新橋，工程師測量每座橋的行駛時間、事故率和結構指標。土木工程的類比對應到 ML 部署，因為兩者都是高風險的不可逆決策，失敗恢復成本高昂——這正是 MLA-C01 考試深度測試這些模式的原因。

生產 Variant——A/B 測試的基礎

SageMaker 實時 endpoint 支援生產 variant——同一 endpoint 上 hosting 多個模型版本，流量按可配置的權重分配。

Variant 配置

Endpoint 配置聲明一個或多個 ProductionVariant 條目，每個條目有 VariantName、ModelName、InstanceType、InitialInstanceCount 和 InitialVariantWeight。進入 endpoint 的流量按權重比例分配到各 variant——variant A 權重 9、variant B 權重 1，意味著 90% 的流量到 A、10% 到 B。

A/B 測試工作流程

1. 用當前生產模型作為 variant A（權重 1.0）建立 endpoint 配置
2. 部署 endpoint
3. 更新 endpoint 配置，添加 variant B（新模型）權重 0.1，保留 variant A 權重 0.9
4. 隨著信心增長使用 UpdateEndpointWeightsAndCapacities 漸進轉移流量
5. 比較每個 variant 的指標（延遲、業務指標如 CTR 或轉換率）以達統計顯著性
6. 如果 variant B 獲勝，提升到 1.0 權重；如果輸了則移除

統計顯著性

生產 variant 的流量分配不是每個請求隨機的——它是基於雜湊的每次呼叫確定性分配。要進行統計上有效的 A/B 測試，確保每個 variant 的流量量足夠大，使比較指標超過噪聲底線，並運行足夠長的時間以捕捉每日/每週的季節性。典型的 A/B 測試在有意義的流量分配下運行一到四週。

每個 Variant 的自動擴展

每個 variant 有自己的自動擴展配置。90% 的 variant A 和 10% 的 variant B 會基於每個 variant 的 InvocationsPerInstance 獨立擴展——小 variant 縮減至其 MinCapacity，而大 variant 隨著負載增長向外擴展。

Blue/Green 部署——平行堆疊加即時切換

Blue/green 是經典的「兩個平行堆疊，切換流量」模式。

SageMaker 上的機制

「藍」環境是當前服務生產的 endpoint 配置。「綠」環境是一個新的 endpoint 配置，新模型已完全佈建。SageMaker UpdateEndpoint 配合新的 endpoint 配置觸發 blue/green 切換——綠上線、流量 100% 轉移到綠、然後藍的執行個體被拆除。這是帶有 BlueGreenUpdatePolicy 的 SageMaker UpdateEndpoint 的預設行為。

流量轉移模式

在 blue/green 中，流量轉移可以是：

• All-At-Once——立即 100% 從藍切換到綠（許多配置的預設）
• Canary——先把小比例流量到綠，驗證，然後全面切換
• Linear——隨時間以相等步驟切換

儘管名稱相同，AWS 把 canary 和線性視為 blue/green 部署內的流量轉移模式——而非獨立的部署策略。這是一個頻繁測試的詞彙區別。

回滾機制

如果綠在部署後驗證期間失敗（可配置，以 CloudWatch 警報為觸發器），SageMaker 將流量切回藍並拆除綠。藍在驗證期間保持熱狀態，正是為了讓回滾是即時的。

何時使用 Blue/Green

• 需要快速切換並具備即時回滾能力
• 可以在部署窗口期間承擔雙倍基礎設施成本
• 對預生產測試的信心高到漸進轉移不必要
• 有自動護欄支持的時間壓力部署

Canary 部署——小比例初始流量

在 SageMaker blue/green 情境中，Canary 表示綠環境首先接收一小部分流量（「金絲雀」），在全面切換前烤制一段時間。

配置

BlueGreenUpdatePolicy.TrafficRoutingConfiguration.Type = "CANARY" 配合指定百分比或執行個體數量的 CanarySize。Canary 階段運行配置的持續時間；如果沒有 CloudWatch 警報觸發且等待期過後，流量轉移到 100% 綠。

自動回滾的 CloudWatch 警報

Canary 的目的是在所有使用者受影響之前，先在一小部分使用者上暴露問題。配合以下 CloudWatch 警報：

• Endpoint 錯誤率（Invocation5XXErrors）
• Endpoint 延遲（ModelLatency P90 或 P99）
• 自訂業務指標（模型特定的精確度、公平性）

如果在 canary 期間任何警報觸發，SageMaker 自動回滾。這是 SageMaker 部署護欄功能。

何時使用 Canary

• 風險厭惡的部署，1-5 分鐘在 5-10% 使用者上的暴露可以接受但 100% 不行
• 有有意義的實時 CloudWatch 警報可以觸發回滾
• 生產流量足夠大，使 canary 期間的 5-10% 能產生信號

線性部署——排程的等步長轉移

線性部署按排程以等步長轉移流量。

配置

BlueGreenUpdatePolicy.TrafficRoutingConfiguration.Type = "LINEAR" 配合 LinearStepSize（百分比）和 WaitIntervalInSeconds。SageMaker 每個等待間隔從藍到綠轉移固定比例的流量，直到 100%。

何時使用線性

• 需要可預測的排程推廣速度
• 每個步驟配合 CloudWatch 警報進行增量驗證
• 時間有限的部署窗口（例如在工作日結束前完成）

線性 vs Canary

Canary 是「先切小片段，然後跳到 100%」。線性是「以等步長漸進轉移」。兩者都可以整合自動回滾。Canary 更快但粒度較少；線性較慢但每個步驟獨立驗證。MLA-C01 考試透過題幹語言測試這個區別：「先是小比例」→ canary；「漸進的等步長」→ 線性。

Shadow 部署——零風險模型驗證

Shadow 部署是最保守的模式：新模型接收真實流量的副本，但其預測永遠不會返回給客戶。

架構

Shadow variant 與生產 variant 一起配置在 endpoint 上。每個傳入請求都發送到兩個 variant。生產 variant 的回應返回給客戶端；shadow variant 的回應被擷取（記錄到 S3 以供分析）後丟棄。客戶沒有任何影響；工程師將 shadow 預測與生產預測以及最終的真實結果進行比較。

SageMaker Shadow 測試

CreateShadowTestSchedule 配置一個有定義持續時間、要映射的流量百分比和測試後分析報告的結構化 shadow 測試。報告比較 shadow 模型的預測與生產模型的預測的差異，以及與真實結果的精確度比較。

何時使用 Shadow 部署

• 任何客戶暴露於問題模型都不可接受的最高風險容忍度場景
• 在任何切換前在真實生產流量上驗證新模型
• 在提交之前測試真實負載下的模型延遲
• 在提升之前驗證重新訓練的模型與當前生產模型在大多數預測上一致
• 每個生產影響變更都需要安全證據的受監管行業

Shadow vs A/B 測試

A/B 測試向真實客戶提供兩個模型的服務，統計比較業務結果。Shadow 只向客戶提供生產模型的服務，並離線驗證新模型。A/B 測試是「哪個模型在生產中表現更好」；shadow 是「新模型是否安全地可以放在客戶面前」。

部署護欄——自動回滾配置

SageMaker 部署護欄為 blue/green 部署添加了自動 CloudWatch 警報驅動的回滾機制。

配置

呼叫 UpdateEndpoint 時，附加一個包含以下內容的 DeploymentConfig：

• BlueGreenUpdatePolicy——流量轉移模式（全量、canary、線性）
• AutoRollbackConfiguration——要監控的 CloudWatch 警報列表

如果在 blue/green 部署期間任何受監控的警報觸發，SageMaker 將：

1. 停止向綠轉移流量
2. 將所有流量轉移回藍
3. 將部署標記為失敗
4. 保留藍和綠兩個配置以供鑑識分析

警報選擇

典型的警報：

• Invocation5XXErrors 超過閾值
• ModelLatency P95 超過延遲 SLA
• CPUUtilization 飽和，表明綠的執行個體規格不足
• 自訂業務指標警報（例如 CTR 低於基準 N%）

手動回滾

即使在部署護欄窗口之外，手動回滾也只是一個指向前一個 endpoint 配置（保存在你的 EndpointConfig 歷史記錄中）的 UpdateEndpoint 呼叫。始終用模型版本元數據標記 endpoint 配置，以便前一個版本可以立即識別用於回滾。

與 Model Registry 整合——端到端 MLOps 流程

部署策略在通過 SageMaker Model Registry 連接時變得操作上清晰。

由 Registry 驅動的部署

流程：

1. SageMaker Pipeline 訓練新模型
2. ConditionStep 根據閾值評估新模型的指標
3. 如果通過，RegisterModel 步驟以 PendingManualApproval 狀態將模型添加到 Model Package Group
4. ML Engineer 審核並批准模型套件，狀態變為 Approved
5. 批准事件觸發 EventBridge 規則
6. EventBridge 呼叫 Lambda 或 CodePipeline，以部署護欄配置呼叫 UpdateEndpoint
7. Blue/green canary 部署在 CloudWatch 警報上自動回滾繼續進行
8. 部署成功將新模型版本記錄為活躍生產版本

為何由 Registry 驅動勝出

Model Registry 提供稽核軌跡（誰批准的、何時、基於哪些指標）和部署觸發（批准事件）。與部署護欄結合，每次模型部署都是可審核的、可回滾的且有記錄的。

部署策略決策矩陣

如何將題幹對應到策略

• 「部署期間最小化風險」→ canary 或 shadow
• 「比較新模型與當前模型」→ 用生產 variant 的 A/B 測試
• 「無客戶暴露地驗證新模型」→ shadow
• 「快速切換加即時回滾」→ blue/green
• 「排程的漸進流量轉移」→ 線性
• 「先是小比例然後全量」→ canary

MLA-C01 常見部署策略陷阱

陷阱一：Blue/Green 意味著全量切換

錯誤。Blue/green 是包含全量切換、canary 和線性流量轉移模式的類別。考試設置的題幹中「blue/green」單獨使用時是模糊的，答案取決於指定的流量轉移模式。

陷阱二：Canary 和線性獨立於 Blue/Green

在 SageMaker 上是錯誤的。Canary 和線性是 blue/green 部署內的流量轉移模式。在 SageMaker 之外，如 CodeDeploy 和其他 AWS 服務，canary 和線性是獨立的概念。

陷阱三：A/B 測試和 Canary 是一樣的

錯誤。A/B 測試是兩個模型以統計顯著性為目標、平行服務真實客戶流量的長期穩態配置，通常運行數天或數週。Canary 是 blue/green 部署中持續幾分鐘到幾小時的短暫階段。意圖不同：A/B 測試衡量業務結果；canary 捕捉部署失敗。

陷阱四：Shadow 部署向某些使用者提供預測

錯誤。Shadow 從不向客戶提供預測服務。生產模型服務所有客戶；shadow 並行運行並將其預測丟棄到 S3 日誌。

陷阱五：回滾需要重新訓練

錯誤。回滾是將 endpoint 配置更新為指向前一個模型套件。模型已在 registry 中；部署只是一個指針變更。

陷阱六：部署護欄對任何警報自動回滾

錯誤。自動回滾只對 AutoRollbackConfiguration 中列出的警報觸發。其他 CloudWatch 警報存在但不影響部署。

陷阱七：生產 Variant 需要獨立的 Endpoint

錯誤。生產 variant 共享單一 endpoint，流量按權重分配。獨立的 endpoint 是不同的部署拓撲。

陷阱八：Shadow 測試是免費的

錯誤。Shadow variant 在自己的執行個體上運行（映射生產流量使推論算力成本加倍）。相應地規劃容量和預算。

FAQ——ML 部署策略

Q1：為新模型發布選擇 canary 還是線性部署？

當你想先將新模型暴露給一小部分流量、觀察相對較短的驗證窗口、觀察 CloudWatch 警報、然後如果沒有警報觸發就跳到 100% 時，Canary 是對的。當你想要更長、更漸進的等步長轉移，每個步驟在進行下一步之前獨立地根據警報進行驗證時，線性是對的。Canary 端到端更快（一個短 canary 窗口然後 100%）；線性更慢但每個步驟都被獨立觀察。對於有強大 CloudWatch 覆蓋的大多數生產發布，canary 是預設的——canary 窗口捕捉了大部分部署時問題，速度優勢很重要。對於只有在規模或隨時間才顯現的微妙降級模型，線性更長的轉移期提供了更多的驗證面。

Q2：SageMaker 生產 variant A/B 測試和 canary 部署有什麼區別？

用生產 variant 進行 A/B 測試是一個長期穩態配置，兩個模型為真實客戶流量並行服務，用於統計比較業務指標——運行幾天或幾週，目的是測量哪個模型勝出。Canary 部署是 blue/green 部署中持續幾分鐘到幾小時的短暫階段，目的是在所有流量暴露前捕捉部署失敗。它們不可互換。如果問題問的是「哪個模型在一個月的流量中有更高的轉換率」，答案是 A/B 測試。如果問題問的是「以降低風險的方式部署新模型」，答案是 canary。MLA-C01 題幹的詞彙提示：「比較兩個模型」或「衡量業務指標」→ A/B；「最小化部署風險」或「先是小比例然後全面推廣」→ canary。

Q3：如何為 SageMaker blue/green 部署實作自動回滾？

在 UpdateEndpoint 呼叫上配置一個 DeploymentConfig，包含 BlueGreenUpdatePolicy（指定流量轉移模式——全量、canary 或線性）和列出要在部署期間監控的 CloudWatch 警報的 AutoRollbackConfiguration。典型警報：endpoint 5xx 錯誤率超過閾值、P95 或 P99 模型延遲超過 SLA，以及 Model Monitor 或應用程式發出的衡量預測品質的自訂 CloudWatch 指標。如果任何受監控的警報在部署窗口期間進入 ALARM 狀態，SageMaker 自動停止流量轉移、將流量恢復到藍（前一個配置）並將部署標記為失敗。藍和綠兩個配置都保留以供事後分析。部署計時器加上警報監控期可以配置；典型的 canary 窗口是 30 分鐘到兩小時，警報評估期 1-3 分鐘。

Q4：為何應該用 shadow 部署而不是 A/B 測試來驗證新模型？

當客戶暴露於潛在問題模型是不可接受時使用 shadow——在醫療保健、詐欺偵測、金融定價或受監管行業等高風險領域很常見。Shadow 在複製的真實流量上運行新模型，但從不將其預測返回給客戶；生產模型服務所有真實預測。你將 shadow 預測與生產預測和真實結果進行比較以驗證安全性。A/B 測試相反，將新模型暴露給真實客戶——一半使用者獲得新模型的預測並按其行動。如果新模型有關鍵失效模式（例如錯誤批准詐欺、錯誤拒絕貸款、錯誤推薦藥物），A/B 測試的客戶會經歷失敗。Shadow 是在 A/B 之前的安全驗證步驟；A/B 是在全面推廣之前的業務影響衡量步驟。MLA-C01 考試將 shadow 測試為「以真實流量測試新模型，對客戶沒有影響」的答案。

Q5：模型部署期間應監控哪些 CloudWatch 指標？

最少：Invocation5XXErrors（部署破壞的錯誤）、ModelLatency P95 或 P99（延遲回退捕捉），以及 Invocations（確認流量到達新 variant 的健全性檢查）。對於更高的信心：每個 variant 的 CPUUtilization 和 MemoryUtilization（捕捉規格不足的綠）、OverheadLatency（SageMaker 端的開銷，捕捉配置錯誤），以及由 Model Monitor 或應用程式程式碼發出的模型特定品質自訂 CloudWatch 指標（捕捉精確度回退、公平性回退或業務 KPI 降級）。以合理的閾值配置每個警報（例如 5xx 率超過 1%、P99 延遲超過 500ms、精確度低於 0.85），然後在部署護欄 AutoRollbackConfiguration 中列出這些警報。沒有列出的警報，即使指標降級部署也會繼續——警報驅動的回滾只對配置監控的警報觸發。

Q6：可以在同一個 endpoint 上同時運行 shadow 部署和 A/B 測試嗎？

實際上可以——實時 endpoint 上的生產 variant 可以包含標準 variant（有非零流量權重）和 shadow variant（從指定的生產 variant 映射流量而不提供回應）。配置變得複雜：variant A 權重 0.7（當前生產）、variant B 權重 0.3（新模型的 A/B 測試），以及 variant C 作為 variant A 的 shadow（驗證候選模型而不暴露）。這在實際中很少見，因為成本高（三套推論執行個體）且分析面複雜。典型模式是按序列：先 shadow 驗證安全性，再 A/B 衡量影響，然後全面推廣。同時結合 shadow 和 A/B 是為擁有深度 MLOps 成熟度和專用實驗基礎設施的組織保留的。

Q7：Model Registry 和部署策略如何在端到端 MLOps 流水線中整合？

Model Registry 持有版本化的模型套件，狀態為 Approved / PendingManualApproval / Rejected。SageMaker Pipeline 訓練模型，運行 ConditionStep 來把關品質（例如 AUC > 0.85），通過後呼叫 RegisterModel 步驟，以 PendingManualApproval 在 Model Package Group 中建立新模型套件。ML Engineer 或業務利益相關者審核模型套件（訓練指標、評估報告、模型卡、血緣關係），然後批准或拒絕。批准發出一個 EventBridge 事件（SageMaker Model Package State Change），觸發 CodePipeline 或 Lambda，以部署護欄配置呼叫 UpdateEndpoint——通常是有自動回滾警報的 canary blue/green。如果部署失敗（警報觸發），模型套件狀態可以自動切換為 Rejected，防止進一步的部署嘗試。如果部署成功，前一個模型套件被標記為 Archived（自訂狀態慣例），新套件成為部署的生產版本。這個閉環模式——訓練 → 登錄 → 批准 → 受護欄保護的部署 → 成功或回滾——是 MLA-C01 測試的標準端到端 MLOps 流程。