SageMaker Model Registry 與版本控制

SageMaker Model Registry 與版本控制，是每個生產機器學習系統的治理骨幹。SageMaker Model Registry 是一個集中式目錄，記錄每個訓練好的模型產出物、每個評估指標、每組超參數和每個審核決策，並附帶版本控制、血緣和稽核支援。在 MLA-C01 考試中，Model Registry 跨越三個任務陳述——3.1（部署基礎設施選擇）、3.2（基礎設施腳本化）和 3.3（CI/CD 編排）——對於單一主題來說，這種廣度並不尋常，也說明了此張證照對模型治理的高度重視。來自 Pluralsight 的社群回饋特別指出，從觸發器到 Registry 到部署的完整再訓練迴圈，作為案例研究模式在真實考試題幹中多次出現。

本指南端到端地涵蓋 Model Registry：模型包群組作為組織單元、模型包版本作為已登記的產出物、ModelApprovalStatus 工作流程及其自動和手動變體、透過 Resource Access Manager 和 S3 複製的跨帳戶共享模式、ML Lineage Tracking 整合、用於文件化的模型卡、透過 EventBridge 事件的 Registry 驅動 CodePipeline 部署，以及回滾和歷史版本模式。最後以考試透過排序和配對題型測試的以 Registry 為核心的再訓練迴圈，以及常見 Registry 失敗的疑難排解決策樹作結。

什麼是 SageMaker Model Registry，為何 MLA-C01 跨三個任務測試它

SageMaker Model Registry 是一個完全受管的服務，將訓練好的模型產出物作為版本化、受治理、不可變的記錄進行目錄管理。已登記的模型攜帶的元資料包括訓練任務 ARN、來源訓練資料 S3 URI、推論容器映像 URI、評估指標、血緣圖和審核狀態。沒有 Model Registry，ML 團隊只能依賴臨時 S3 路徑和電子表格追蹤哪個模型在生產中——失去了回滾、稽核或重現模型的能力。有了 Model Registry，每個生產模型都有穩定的識別碼（模型包 ARN）、清晰的審核血緣和有保證的可恢復歷史記錄。

Model Registry 出現的三個任務陳述

Task 3.1（選擇部署基礎設施）將 Model Registry 作為端點部署的來源進行測試——模型包 ARN 是 CreateModel 和 CreateEndpointConfig 呼叫的輸入。Task 3.2（建立並腳本化基礎設施）測試透過 CloudFormation、CDK 和 Terraform 建立 Model Registry，以及跨帳戶共享的 IAM 權限。Task 3.3（CI/CD 管線）將 Model Registry 測試為 SageMaker Pipelines（登記模型）和 CodePipeline（消費審核事件以觸發部署）之間的整合點。跨越三個任務陳述的主題比錨定在單一任務的主題值得花更多時間學習。

為何版本控制是治理要求而非便利功能

受監管行業（金融、醫療、保險）要求每個服務生產推論的模型都能追溯到具備可重現輸入的特定訓練執行。當監管機構問「3 月 15 日做信貸決策的是哪個模型」時，答案必須是帶有元資料的特定模型包 ARN，顯示訓練資料版本、演算法、超參數、評估報告和審核部署的人員。Model Registry 在設計上提供這個稽核記錄——模型包 ARN 是不可變識別碼，審核狀態變更被記錄，血緣被自動捕捉。把 Model Registry 當成可選項是等待發生的合規失敗。

白話文解釋 SageMaker Model Registry

Model Registry 是那種治理、版本控制和部署全都在一個服務中匯聚的主題。三個具體類比讓結構更容易記憶。

類比一——帶有目錄、審核和流通的圖書館

想像一所研究型大學圖書館。教職員出版的每本書（每個訓練好的模型）在能夠借給讀者（部署到生產端點）之前，都要經過首席圖書館員的目錄整理（Model Registry 登記）。目錄系統按系列組織書籍（模型包群組——「詐騙偵測系列」、「推薦系列」、「圖像分類系列」）；系列內每本書的新版本都獲得連續版本號（模型包版本 1、2、3...）。圖書館有審查委員會（審核工作流程）在蓋上核准流通章之前讀完每個新版本；被拒絕的版本留在私人書架上待修訂。卡片目錄（登記元資料）記錄每本書的每個細節——作者（訓練任務）、出版商（訓練容器映像）、出版日期、章節清單（超參數）、審查者備注（評估指標）和審核簽名。當讀者要求「最新的詐騙偵測書」（生產端點更新）時，流通台（CodePipeline）查找最近核准的版本並寄出一本複本。當在當前版本中發現缺陷（生產漂移）時，圖書館員可以立即從書架上取下以前核准的版本（回滾），無需從頭重建。圖書館不會丟棄舊版本——它們保留在檔案中，目錄完整，可供任何歷史研究查詢。

類比二——帶有藥品審核和版本控制的藥廠

想像一家製造藥物的製藥公司。每種新配方（每個訓練好的模型）都要經過臨床試驗（訓練和評估），然後向藥品主管機關提交申請（以 PendingManualApproval 狀態向 Model Registry 登記）。機構審查委員會（合規官員或自動指標閘道）審查試驗結果（評估指標、模型卡、公平性分析），並批准配方分發（狀態 → Approved）或帶著評論拒絕（狀態 → Rejected）。核准的配方獲得藥品許可碼（模型包 ARN），永遠唯一識別該版本。藥局按 ARN 分發，而非按「當前最佳的」——因為在分階段推出期間，不同地區的藥局可能正在使用不同的核准版本配送處方。當藥物警戒（Model Monitor）在生產中偵測到特定配方的不良事件信號時，公司可以立即召回那個特定藥品碼（回滾到以前的模型包 ARN），同時正在開發新配方。跨藥局分發（跨帳戶部署）需要分發協議（RAM 共享或跨帳戶 IAM 信任），以便消費者藥局可以使用中央目錄配送處方。即使在更新版本取代後，每種製造出來的配方仍保留在歷史記錄中——監管機構要求如此，你的稽核員也會要求。

類比三——帶有專輯版本和編輯審核的音樂串流服務

想像一個音樂串流服務。藝術家上傳專輯（資料科學家訓練模型）。音樂攝取團隊（CI/CD 管線）將每次上傳目錄整理到主目錄（Model Registry）中，歸入藝術家的歌曲集頁面（模型包群組）。每次上傳獲得曲目列表、音頻文件 URL、歌詞元資料、ISRC 碼和編輯審核狀態（Registry 元資料欄位）。編輯團隊（審核閘道）在批准每張新專輯上架全球目錄（狀態 → Approved）之前，審查內容政策合規、音頻品質和元資料正確性。串流應用程式（生產端點）向聽眾提供最新核准版本；當藝術家發布重新製作版本時，新版本成為預設，但原版保留在檔案中。如果發現版權侵害（生產模型缺陷），編輯團隊可以立即下架那個特定版本（回滾）並提供以前核准的版本。向區域夥伴分發（跨帳戶部署）透過授權協議（RAM 共享）進行，讓夥伴平台引用中央目錄而非維護自己的重複目錄系統。藝術家歌曲集中的版本歷史頁面（部署歷史）顯示每個曾上線的版本及其時間，稽核員和版權律師都很喜歡。

模型包群組——組織單元

每個模型包恰好屬於一個模型包群組。群組是系列或血緣；包是該系列中的特定版本。

群組中包含什麼

模型包群組代表一個邏輯模型系列——「fraud_detection_credit_card」、「recommendation_homepage」、「image_classification_product」。該系列的每個重新訓練版本——相同的業務問題、相同的輸入 schema、相似的架構但可能不同的超參數或訓練資料——在群組中登記為新的模型包。群組不應混合不相關的模型；即使兩者都由相同團隊訓練，也不要把詐騙偵測和推薦放在同一個群組中。

群組命名慣例

最佳實踐：以穩定的業務領域識別碼命名群組，而非使用日期或模型架構。「fraud_detection_v1」是糟糕的群組名稱，因為它嵌入了版本，在模型迭代後會變得誤導性。「fraud_detection_credit_card」是好的群組名稱，因為它跨架構持久（可以從 XGBoost 重新訓練到神經網路並留在同一群組）。

群組標籤用於成本分配和存取控制

模型包群組上的標籤會傳播到其中的所有模型包（有關時序的注意事項）。使用標籤進行成本分配（Project、CostCenter、Owner）、存取控制（Environment=Production 限制誰可以更新審核狀態）和探索（BusinessDomain、ModelType）。MLA-C01 考試透過引用 aws:ResourceTag/Environment 的 IAM 條件來測試基於標籤的存取控制。

CreateModelPackageGroup IAM 要求

建立模型包群組的 IAM 主體需要 sagemaker:CreateModelPackageGroup。更新其描述或策略的主體需要 sagemaker:UpdateModelPackageGroup 和 sagemaker:PutModelPackageGroupPolicy。忘記後者是常見的跨帳戶共享失敗——群組存在，但授予其他帳戶將包登記進去的資源策略遺失了。

模型包版本控制——版本化的產出物

模型包是被部署的東西。記住它包含什麼。

模型包捕捉哪些元資料

已登記的模型包包含 ECR 中的推論容器映像 URI、模型產出物 S3 URI（訓練好的權重）、推論規格（實例類型、環境變數、回應內容類型）、來源訓練任務 ARN、評估指標（精確率、召回率、AUC、自訂指標）、資料品質基準、審核狀態、審核描述、自訂元資料鍵值對，以及（可選）模型卡引用。這些元資料足以從頭重建模型、評估其品質並部署它。

群組內的連續版本號

模型包版本在群組內自動遞增。版本號不能跳過或重複使用。如果版本 5 被拒絕，下一次登記仍然是版本 6，而非版本 5 的重新登記。這是有意為之的設計——模型包版本號是稽核記錄的一部分，必須不可篡改。

model_package_arn 是不可變的

模型包 ARN（例如 arn:aws:sagemaker:us-east-1:111111111111:model-package/fraud_detection_credit_card/7）是 CodePipeline、EventBridge 規則、CloudFormation 引用和稽核日誌使用的持久識別碼。即使在模型被拒絕、刪除或被取代後，ARN 引用仍可從 Registry 歷史中恢復。

從訓練任務建立 CreateModelPackage

典型的管線模式：SageMaker 訓練任務完成，SageMaker Pipeline RegisterModel 步驟以訓練任務 ARN、評估 S3 位置和所需審核狀態（預設為 PendingManualApproval）呼叫 CreateModelPackage。Registry 從訓練任務 ARN 自動計算血緣。在管線外手動登記會失去這個自動血緣，必須明確填寫元資料。

用於可重現性的自訂元資料

除了標準元資料，自訂屬性（CustomerProperties 字典）對稽核等級的可重現性至關重要——TrainingDataS3VersionId（訓練時訓練資料的 S3 版本 ID）、ContainerImageDigest（推論容器的 sha256 摘要）、GitCommitSha（原始碼 commit）、RequirementsHash（requirements.txt 的雜湊值）。六個月後，這些自訂屬性就是允許重新產生模型的關鍵。

ModelApprovalStatus——審核工作流程

審核是訓練好的模型和生產部署之間的守門人。

三種審核狀態

模型包有三種 ModelApprovalStatus 值之一：PendingManualApproval（登記時的預設值，等待審查）、Approved（已清除可進行生產部署）、Rejected（審查未通過，不會部署，但作為歷史記錄保留在 Registry 中）。狀態變更記錄了操作者身份和可選的審核描述。

如何更新審核狀態

三種機制：(1) SageMaker 主控台審核按鈕——對人工審查者最快，但不可擴展；(2) UpdateModelPackage API 呼叫——由實作自動審核邏輯的 Lambda 函數使用；(3) 帶有 model_approval_status="Approved" 的 SageMaker Pipelines RegisterModel 步驟——當管線已透過評估指標的 ConditionStep 把關審核時使用。

手動審核工作流程

手動審核模式：SageMaker Pipeline 以 PendingManualApproval 登記，EventBridge 規則在登記事件上觸發 SNS 通知，通知 ML 負責人附帶模型卡和評估報告的連結，負責人審查後在主控台點擊批准，狀態變更為 Approved，EventBridge 規則在審核事件上觸發 CodePipeline 部署。根據審查 SLA，這個迴圈通常需要數小時到數天。

透過 ConditionStep 實現自動審核

對於較低風險的環境，在 SageMaker Pipeline 內使用 ConditionStep 嵌入審核，比較評估指標與門檻。如果指標通過，RegisterModel 步驟直接將狀態設為 Approved；如果指標失敗，FailStep 停止管線並不登記任何內容。這將迴圈壓縮到幾分鐘，並將人類從審核關鍵路徑中移除。

多層審核

受監管的工作流程可能需要多層審核——ML 工程師簽署技術指標，公平性官員簽署偏差分析，合規官員簽署監管標準。透過自訂元資料屬性（MLEngineerApproved=true、FairnessApproved=true、ComplianceApproved=true）加上只有當三個屬性都設定時才將 ModelApprovalStatus 翻轉為 Approved 的 Lambda 來實作。每個審核者更新一個屬性；Lambda 是連接詞。

跨帳戶 Model Registry 共享

生產 ML 通常跨越多個帳戶——開發、暫存、生產。Model Registry 透過幾種機制支援跨帳戶共享。

模式一——RAM 共享模型包群組

推薦模式。AWS Resource Access Manager（RAM）與消費者帳戶共享模型包群組。消費者帳戶透過共享群組 ARN 讀取模型包元資料、列出版本，以及（如果被授予）更新審核狀態。這種模式在一個帳戶（通常是專用的 MLOps 或稽核帳戶）中集中 Registry，同時讓消費者帳戶針對它運作。

模式二——模型包群組上的資源型策略

模型包群組可以有資源型策略，授予特定主體（其他帳戶、IAM 角色）sagemaker:DescribeModelPackage、sagemaker:UpdateModelPackage 或 sagemaker:CreateModel 等動作。當 RAM 共享不適合時使用（例如，AWS 組織外部的第三方夥伴帳戶）。

模式三——模型產出物的 S3 跨帳戶複製

對於氣隙或嚴格隔離的消費者帳戶，將模型產出物 S3 物件複製到消費者帳戶的儲存桶，並在本地重新登記引用複製產出物的新模型包。失去了集中血緣，但提供了完整的帳戶隔離。用於高度受監管的多租戶場景。

跨帳戶部署機制

當生產帳戶中的 CodePipeline 部署 MLOps 帳戶擁有的模型包時：CodePipeline 在生產帳戶中扮演跨帳戶角色，該角色以跨帳戶模型包 ARN 呼叫 CreateModel，SageMaker 驗證生產帳戶已被授予存取（透過 RAM 或資源策略），模型在生產帳戶中被建立，引用中央 Registry 的元資料，端點正常部署。產出物 S3 位置也必須可被生產帳戶讀取——透過跨帳戶儲存桶策略或複製產出物。

跨帳戶 Registry 的 IAM 權限

最小 IAM 動作集：sagemaker:DescribeModelPackage（讀取元資料）、sagemaker:CreateModel（在消費者帳戶中實例化模型）、sagemaker:CreateEndpointConfig 和 sagemaker:CreateEndpoint（部署），以及 S3 在模型產出物位置的讀取或 KMS 對產出物加密金鑰的解密。遺忘 KMS 權限是頻繁的跨帳戶部署失敗——產出物看起來可透過 S3 路徑存取，但解密靜默失敗。

SageMaker ML Lineage Tracking——免費的來源

ML Lineage Tracking 是自動捕捉 SageMaker 資源產出物來源的兄弟服務。

自動追蹤哪些內容

當 SageMaker Pipeline 執行時，血緣被自動捕捉：訓練資料 S3 路徑被記錄為 Artifact，訓練任務被記錄為 Action，訓練好的模型是另一個 Artifact，模型包登記是另一個 Action，關係（訓練資料 → 訓練任務 → 模型產出物 → 模型包）形成圖。查詢模型包的血緣，返回一直追溯到來源訓練資料的完整上游鏈。

為何血緣對稽核和可重現性很重要

當監管機構問「在 Y 日期做出決策 X 的是哪個資料訓練的模型」時，答案來自血緣——查詢模型包 ARN，向上游走到訓練任務，再向上游走到訓練資料 S3 路徑，讀取 S3 版本 ID。沒有血緣追蹤，這條鏈必須從不同日誌中手動重建，通常是不可能的。有了血緣，這是一個類 GraphQL 的查詢。

血緣和自訂產出物

自訂產出物（Feature Store、模型卡、評估報告）可以透過 AssociateTrialComponent 和 CreateArtifact API 新增到血緣圖中。最佳實踐：將特徵組 ARN 和評估報告 S3 URI 作為血緣產出物附加到訓練任務，這樣稽核查詢就能到達它們。

血緣查詢模式

SageMaker Studio 中的 Visualizer 組件以視覺方式顯示血緣圖。透過 LineageQuery API 的程式化存取支援帶深度限制的前向（下游）和後向（上游）遍歷。常見查詢：「訓練資料版本 X 下游的所有模型包」（發現資料品質問題時的影響分析）和「模型包 Y 上游的所有訓練資料」（稽核回應）。

模型卡——作為一等產出物的文件

模型卡捕捉預期用途、評估結果和限制作為結構化文件。

為何模型卡對治理很重要

模型卡是描述模型的標準化 JSON 文件：預期用例、不適用的用例、評估方法、跨切片的評估結果、公平性分析、訓練資料來源、授權限制和聯絡資訊。模型卡是負責任 AI 合規框架（歐盟 AI 法案、ISO 42001）要求的產出物，並越來越受監管機構要求。

將模型卡附加到模型包

CreateModelCard API 建立模型卡；模型包上的 AdditionalInferenceSpecifications 和 CustomerMetadataProperties 可以引用卡片 ARN。最佳實踐：生產中的每個模型包都有附加的模型卡，與之一起儲存在 Registry 元資料中。

模型卡生命週期

卡片有狀態：Draft（進行中）、PendingReview（等待審查）、Approved（已發布）、Archived（已取代）。卡片生命週期獨立於模型包審核，但通常一起追蹤——在同一審查週期中批准卡片和相關的模型包。

自動生成卡片部分

SageMaker 可以從 Registry 元資料自動填充模型卡的部分——評估指標、訓練資料來源、訓練任務 ARN、超參數。人工撰寫的部分（預期用途、不適用範圍、倫理考量）需要手動內容。將模型卡視為資料科學家和產品經理的可交付成果，而非自動生成的樣板文字。

透過 EventBridge 的 Registry 驅動部署

最簡潔的生產模式使用 EventBridge 將 Registry 變更與部署解耦。

Model Package State Change 事件

每當模型包的審核狀態改變時，SageMaker 向 EventBridge 發出 Model Package State Change 事件，其中包含模型包 ARN、之前的狀態、新狀態和時間戳。這個事件是下游自動化的自然整合點。

審核觸發部署的 EventBridge 規則

標準規則模式匹配 source = aws.sagemaker, detail-type = SageMaker Model Package State Change, detail.ModelApprovalStatus = Approved，目標是 CodePipeline 管線（透過 aws.codepipeline.startPipelineExecution）或直接呼叫 UpdateEndpoint 的 Lambda 函數。規則模式還可以按 ModelPackageGroupName 過濾，使不同的群組觸發不同的管線。

審核與部署的解耦

這種模式將審核（一個 Registry 問題）與部署（一個運維問題）解耦。審核者不需要知道哪個 CodePipeline 管線部署模型；他們只需在 Registry 中批准。管線運維人員不需要監控 Registry；EventBridge 規則自動觸發部署。這是 AWS 認可的整合模式，也是 SageMaker Projects MLOps 範本實現的方式。

多環境路由

不同環境（暫存、生產）可以訂閱不同的審核狀態轉換。暫存訂閱 PendingManualApproval（自動部署候選模型進行暫存測試）。生產訂閱 Approved（僅在人工審核後部署）。這種路由透過具有不同過濾模式的獨立 EventBridge 規則實現，所有規則都從同一個模型包狀態變更事件流讀取。

使用 Model Registry 的回滾模式

回滾是 Registry 提供的最高價值能力之一。

回滾到以前的核准版本

當生產部署導致效能下降（Model Monitor 偵測到漂移、延遲超過 SLA、錯誤率飆升）時，ML 工程師查詢 Registry 找到之前核准的模型包，以之前模型包的 CreateModel 衍生端點設定呼叫 UpdateEndpoint，流量轉移回去。恢復總時間：如果有腳本則需幾分鐘，如果透過藍/綠端點設定預先暫存則不到一分鐘。

透過 CloudWatch 告警實現自動回滾

設定了部署防護欄的生產端點，可以在金絲雀或線性部署視窗期間 CloudWatch 告警觸發時自動回滾。防護欄從部署歷史讀取之前的端點設定，無需操作員動作即可切換回去。

為何回滾優於重新計算

Registry 型回滾的替代方案是從頭重新訓練之前的模型，需要數小時，且取決於訓練資料是否仍以相同形式可用。Registry 型回滾使用不可變的模型包，在幾分鐘內完成。這是將 Model Registry 視為強制基礎設施的最有力論據之一。

Schema 變更的回滾注意事項

如果舊版本和新版本之間的推論請求 schema 改變了，回滾到舊版本可能會破壞期望新 schema 的上游呼叫者。緩解措施：在部署期間保持 schema 變更向後相容，或在請求負載中包含 schema 版本，使模型可以優雅地拒絕不支援的 schema。考試在提及「回滾端點返回 500 錯誤」的題幹中測試 schema 不相容場景。

MLA-C01 Model Registry 常見考試陷阱

陷阱一——審核自動部署到生產

錯誤。審核更改狀態欄位；部署是通常由審核事件上的 EventBridge 規則觸發的單獨 API 呼叫。

陷阱二——模型包等同於 SageMaker Model

錯誤。模型包是 Registry 條目；SageMaker Model 是透過 CreateModel 從模型包建立的可部署單元，它被附加到端點設定。它們是具有獨立 ARN 的獨立資源。

陷阱三——模型包群組包含多個不相關的模型

錯誤。群組是一個模型系列。將詐騙偵測和推薦混合在同一群組中會破壞血緣查詢和審核工作流程。

陷阱四——跨帳戶共享只需要 RAM

錯誤。跨帳戶部署還需要對產出物的 S3 跨帳戶存取（如果加密則需要 KMS 存取），以及消費者帳戶中 SageMaker 動作的 IAM 權限。RAM 是必要但不充分的。

陷阱五——刪除的模型包從稽核中消失

錯誤。刪除的模型包從 Registry 的活躍列表中被移除，但其存在和審核歷史永久記錄在 CloudTrail 和血緣中。稽核記錄得以保存。

陷阱六——群組重建後版本號重置

陷阱題幹模式。如果模型包群組被刪除並以相同名稱重建，版本號從 1 重新開始。含義：永遠不要刪除有活躍生產引用的群組；改為歸檔。

陷阱七——血緣只捕捉管線驅動的模型

錯誤。血緣對任何 SageMaker 訓練任務都有捕捉，而不僅僅是管線驅動的。手動訓練任務和 notebook 驅動的訓練也產生血緣記錄。管線驅動的訓練因為有明確的步驟關係而增加了更豐富的血緣。

陷阱八——模型卡是登記的自動要求

錯誤。模型卡是可以與模型包關聯的獨立產出物，但不是登記的必要條件。最佳實踐將生產部署的閘道設置在卡片存在；基本登記不需要它。

必記數字與 Model Registry 重要事實

Registry 概念

• 模型包群組是系列/血緣容器
• 模型包是群組內的版本化產出物
• 版本在群組內自動遞增順序，不跳過，不重用
• 三種審核狀態：PendingManualApproval、Approved、Rejected
• 被拒絕的包作為歷史記錄保留在 Registry 中

審核機制

• 主控台手動審核（人工，慢）
• UpdateModelPackage API（Lambda 自動化）
• 帶有 model_approval_status 的 RegisterModel 步驟（管線內部自動化）
• ConditionStep 在 SageMaker Pipelines 內把關自動審核

跨帳戶共享

• RAM 共享模型包群組是推薦模式
• 群組上的資源型策略是非組織帳戶的替代方案
• S3 複製用於氣隙消費者
• 所有三個層（RAM/策略 + S3 + KMS）都必須被授予

整合點

• EventBridge Model Package State Change 事件用於審核驅動的部署
• CodePipeline 讀取核准的模型包 ARN 進行部署
• ML Lineage Tracking 自動捕捉上游來源
• 模型卡透過 CustomerMetadataProperties 附加用於治理

可重現性自訂屬性

• TrainingDataS3VersionId
• ContainerImageDigest
• GitCommitSha
• RequirementsHash
• 自訂審核層標誌（MLEngineerApproved、FairnessApproved、ComplianceApproved）

FAQ——SageMaker Model Registry 熱門問題

Q1——模型包、模型包群組和 SageMaker Model 之間有什麼區別？

模型包群組是持久的系列識別碼（「fraud_detection_credit_card」），跨越重新訓練存在。模型包是該群組中的特定版本化產出物（「fraud_detection_credit_card/7」），包含訓練好的權重、容器映像、評估指標和審核狀態。SageMaker Model 是透過 CreateModel 從模型包建立的可部署運行時實例——它被附加到端點設定。考試在配對題中測試這個；混淆三者是常見錯誤。群組是系列，包是版本，Model 是可部署實例。CodePipeline 引用包 ARN；端點引用 Model 名稱；Registry 按群組組織包。

Q2——如何從中央 MLOps 帳戶與生產帳戶共享核准的模型進行部署？

三個層必須對齊。首先，透過 AWS Resource Access Manager（RAM）與生產帳戶共享模型包群組——生產帳戶現在可以描述和讀取群組中的包。其次，透過儲存桶策略授予生產帳戶對持有模型產出物的 S3 儲存桶的讀取存取——S3 是帳戶範圍的，指向產出物的 Registry 元資料不會自動授予跨帳戶讀取。第三，如果產出物用客戶管理的 KMS 金鑰加密，透過金鑰策略授予生產帳戶解密權限。有了所有三個層，生產帳戶中的 CodePipeline 可以用跨帳戶模型包 ARN 呼叫 CreateModel，產生的模型可以部署到本地端點。缺少三個層中的任何一個都會產生 CreateModel 成功但端點啟動失敗的症狀，這在考試中被大量測試。

Q3——何時應使用透過 ConditionStep 的自動審核，何時應使用 CodePipeline 中的手動審核？

當部署風險低且指標完全捕捉模型品質時使用自動審核（管線內 ConditionStep 評估指標）——通常適用於暫存部署、僅內部模型和低影響功能。好處：部署迴圈在幾分鐘內完成，無需人工介入。當部署風險高時使用手動審核（帶 SNS 通知給審查者的 CodePipeline 審核動作）——受監管行業的生產部署、具有重大業務影響的模型、評估指標無法完全捕捉品質的模型（需要主觀評估），或新模型系列的任何首次部署。許多團隊結合兩者：自動審核把關晉升到暫存，手動審核把關晉升到生產。MLA-C01 考試測試速度（自動）和風險控制（手動）之間的取捨。

Q4——如何在偵測到生產漂移時回滾到之前的模型版本？

最快的回滾路徑：查詢模型包群組找到之前核准的模型包，以那個包的 ARN 呼叫 CreateModel，以新的 SageMaker Model 呼叫 CreateEndpointConfig，以新的端點設定呼叫 UpdateEndpoint。SageMaker 執行藍/綠切換，流量在幾秒鐘內轉移到之前的模型。預先暫存以獲得最快恢復：保持兩個端點設定（當前和之前）準備就緒，這樣 UpdateEndpoint 只需在它們之間切換。更快：在帶有 CloudWatch 告警的生產端點上設定 SageMaker Deployment Guardrails，在部署視窗期間告警觸發時自動回滾。Registry 型回滾比從頭重新訓練（需要數小時，且取決於訓練資料仍以相同形式可用）快出幾個數量級——這是將 Model Registry 視為強制生產基礎設施的最有力論據之一。

Q5——如何為稽核證明六個月前的某個日期哪個確切的模型在服務生產流量？

結合三個來源。首先，UpdateEndpoint 呼叫的 CloudTrail 日誌顯示每次端點設定變更及其時間戳和新端點設定 ARN；逆向工程找到稽核日期有效的設定。其次，端點設定引用 SageMaker Model，SageMaker Model 引用模型包 ARN——查詢 Registry 取得那個包的元資料。第三，包上的 ML Lineage Tracking 返回訓練任務 ARN、帶版本 ID 的訓練資料 S3 路徑、來源碼 commit SHA（來自自訂元資料）和容器映像摘要。三者結合，稽核答案是「模型包 fraud_detection_credit_card/7，從 S3 versionId X 訓練，程式碼 commit Y，容器映像摘要 Z，由 ML 工程負責人在 W 日期審核」。這種稽核等級的可重現性正是監管機構期望的，也是 Registry 在你填寫登記時的自訂元資料屬性時免費提供的。

Q6——可以刪除不再使用的模型包群組嗎？歷史引用會怎樣？

技術上可以——DeleteModelPackageGroup 從 Registry 的活躍列表中移除群組和其所有包。實際上不應該這樣做。刪除群組使每個引用它的 CodePipeline 定義失效，破壞穿過它的血緣查詢，並需要僅從 CloudTrail 重建稽核記錄。推薦做法是歸檔（將所有包移到 ApprovalStatus=Rejected，描述為「已棄用」）而非刪除。如果必須刪除，在稽核記錄中記錄刪除原因、日期和決策授權，並事先確認沒有生產端點、沒有 CodePipeline 和沒有監控系統引用該群組。MLA-C01 考試將刪除視為破壞性操作，並在場景答案中偏好歸檔。

Q7——Model Registry 如何與 SageMaker Projects MLOps 範本互動？

SageMaker Projects MLOps 範本開箱即用地構建包含 Model Registry 整合的完整 CI/CD 管線。「用於模型建置、訓練和部署的 MLOps 範本」建立以專案命名的模型包群組，設定 SageMaker Pipeline 以 PendingManualApproval 狀態登記每次成功的訓練執行，設定審核事件上的 EventBridge 規則，以及設定 CodePipeline 讀取核准的模型包並部署到暫存然後生產端點。「用於模型部署的 MLOps 範本」處理多帳戶變體——Registry 在一個帳戶中，部署在另一個帳戶中，預先設定了跨帳戶 RAM 共享。對於 ML CI/CD 的新手團隊，從 SageMaker Project 範本開始是最快達到生產等級 Registry 驅動管線的路徑；替代方案是手動串接所有活動部件，這既脆弱又耗時。MLA-C01 考試期望熟悉這些範本，並在場景題幹中測試它們。

延伸閱讀——官方 AWS 文件

超出 MLA-C01 範圍的深度，權威 AWS 來源包括：Amazon SageMaker 開發人員指南（Model Registry 部分、ML Lineage Tracking 部分、Model Cards 部分、Pipelines 部分）、AWS MLOps 機器學習持續交付白皮書，以及 AWS Well-Architected 機器學習專題（涵蓋版本控制和可重現性的卓越運維支柱）。