SageMaker Endpoint 類型與選擇——實時、非同步、無伺服器與批次

SageMaker endpoint 類型選擇是 MLA-C01 Domain 3 中測試最深的決策，考試不會讓你以「實時 vs 批次」這種層次輕鬆過關——它會深入考察四種生產推論模式（實時、非同步、無伺服器、Batch Transform）以及兩種 hosting 拓撲（多模型 endpoint、多容器 endpoint）之間的細微差異。選錯 endpoint 類型的 ML Engineer，將為流量零星的服務多付 10 倍的實時 endpoint 費用，或讓一個需要 30 秒的模型卡在同步請求後面錯過延遲 SLA，又或者把 200 MB 的影片檔案塞進 6 MB 的 payload 上限。考試的題幹明確給出流量模式、payload 大小、延遲目標和成本限制，而且只有一種 endpoint 類型能同時滿足全部四個條件。熟記選擇標準；靠猜測必敗。

本指南依序深入介紹四種 endpoint 類型、多模型與多容器拓撲、最佳化服務（Inference Recommender、Neo、自動擴展），最後給出能把題幹直接對應到正確答案的決策矩陣。本文以 MLOps 的角度撰寫——ML Engineer 實際需要配置什麼、哪些 CloudWatch 指標重要，以及 MLA-C01 考試在答案選項中設下的哪些陷阱。

什麼是 SageMaker Endpoint 類型，為何選擇很重要

SageMaker 推論 endpoint 是部署模型服務預測的執行時介面。與訓練任務（執行、完成、關閉）不同，endpoint 是具有自身生命週期、擴展策略、網路設定和計費模式的長期 hosting 基礎設施。SageMaker 提供四種不同的 endpoint 架構，因為沒有任何單一設計適用於所有工作負載。對延遲敏感的請求-回應 API 需要持久容量。長時間執行的大型 payload 任務需要佇列緩衝。流量零星且無 SLA 的服務需要縮減至零。週期性對數百萬筆資料進行離線評分需要完成後消失的臨時算力。

四向決策維度

MLA-C01 上每一道 endpoint 選擇題都可歸結為四個具體維度：延遲 SLA（毫秒以下 / 秒 / 分鐘 / 小時）、payload 大小（KB / MB / GB）、流量模式（穩定 / 突發 / 零星 / 一次性）、以及成本形態（常開 / 按請求計費 / 按任務計費）。同時滿足全部四個條件的 endpoint 類型勝出；違反任何一個限制的答案就是錯的，無論看起來技術上多麼合理。

為何 ML Engineer 容易答錯

資料科學家的思維模式預設是「實時 endpoint」，因為這是 SageMaker 教學的預設值。生產 ML Engineer 首先思考的是流量形態和 payload 大小——一個每天只被呼叫一次供隔夜批次任務使用的模型，絕對不應使用實時 endpoint；一個處理 500 MB 影片的視覺模型，絕對不應試圖塞入 6 MB 的同步 payload 上限。MLA-C01 考試獎勵的是工程本能，而非教科書預設值。

白話文解釋 SageMaker Endpoint 類型

四種 endpoint 類型在抽象層面難以區分，直到你把它們對應到日常的配送模式才會豁然開朗。三個具體類比讓差異清晰可記。

類比一：台灣夜市攤位的服務模式

把台灣夜市想像成有四種不同的攤位服務方式，每種對應不同的客人流量模式。實時推論是固定攤位的鹹酥雞——爐子一直開著、廚師隨時待命，客人點餐三十秒內就能拿到，即使夜市還沒開始熱鬧，攤主也得付廚師薪水。成本高因為人力持續投入，但服務瞬間完成。非同步推論是預訂辦桌的外燴服務——你預訂五十桌的婚宴、留下菜單和訂金，四小時後接到通知說菜都備好了。廚房在背景處理這份訂單，如果前面還有別的訂單就排隊，工作人員規模隨需求調整而非維持在尖峰狀態。無伺服器推論是只在廟會時出現的臨時攤位——沒有廟會就沒有攤位、也沒有成本，但第一個客人要等爐子預熱（冷啟動）。廟會結束，攤位收攤，不再計費。Batch Transform 是每週一次替全校員工製作便當的包餐服務——週一早上開工、把整批訂單全部做完、送出去、關廚房。沒有常設容量、沒有佇列、沒有按請求計費——一份訂單、一張發票、完工。多模型 endpoint 是美食廣場中五家餐廳共用一個廚房和一個收銀台，隨著訂單到來交換食材。多容器 endpoint 是自助餐檯的流水線，每個托盤依序經過沙拉站、主餐站、甜點站。為客人流量挑對服務模式，廚房才能高效運轉；選錯了，不是讓客人等太久就是空燒爐子浪費錢。

類比二：快遞公司的配送層級

想像一家郵購公司的四種配送服務。實時推論是門市自取服務——倉庫持續有人，每筆訂單一小時內出貨，客戶期待立即完成，公司要付倉庫人力隨時待命，即使平靜的日子也一樣。非同步推論是國際貨運代理——大型貨件（最高 1 GB payload，即 SageMaker 非同步上限）在碼頭的佇列中等候，代理依序處理，客戶幾小時或幾天後收到清關通知。碼頭可依平均負載調整規模，因為佇列吸收了尖峰浪。無伺服器推論是按需啟動的快遞服務——沒有閒置的司機、沒有車隊成本，但司機需要十分鐘才能到取貨點（冷啟動）。對零星的出貨需求而言這是最便宜的選項；對持續的流量而言，呼叫快遞的模式永遠不會結束。Batch Transform 是每月一次的大宗郵寄行動——資料庫裡每個地址都在一次大型任務中處理，郵資以量制優，卡車只跑一趟，之後不留任何基礎設施。MLA-C01 問「你有五萬筆資料要在夜間評分並在早上前拿到結果，最便宜的方案是什麼」——答案是 Batch Transform，而非一台每天閒置二十二小時的實時 endpoint。

類比三：醫院急診分流

想像一家醫院有四種病人流程。實時推論是急救室——每分鐘都很關鍵，全套醫療人員二十四小時待命，接受空床的成本是必要的，因為中風病患不能等。延遲 SLA 在次秒到幾秒之間。非同步推論是排隊等待核磁共振的放射科成像——掃描被排進佇列、依序執行，放射師幾小時後再看結果。Payload（MRI 掃描，數百 MB 到一 GB）太大無法走急救室的即時流程，但佇列確保每次掃描最終都能完成。無伺服器推論是隨傳隨到的專科醫師——罕見的內分泌科會診被提出，醫師十五分鐘後到達（冷啟動），處理完病例後回家。閒置時不支薪。Batch Transform 是年度世代研究——去年所有病患資料在一次離線任務中跑過風險評分模型，結果寫入資料倉庫，之後不留算力。多模型 endpoint 是一天中由五位不同專科輪流使用的共用診間；多容器 endpoint 是每位病患依序經過麻醉、手術、恢復的手術流水線。選對流程節省生命和金錢；把病患送錯流程正是 MLA-C01 考試測試的失誤。

實時推論 Endpoint——預設選項

實時 endpoint 是 SageMaker 的預設值，也是真正請求-回應 API 的正確答案。

架構與佈建

實時 endpoint 在一個或多個專用 EC2 執行個體上 hosting 模型，這些執行個體位於 SageMaker 管理的 Load Balancer 後方。每次 InvokeEndpoint 呼叫都是同步的——客戶端發送 payload（最高 6 MB），模型產生預測，回應在連線逾時（預設 60 秒）內返回。執行個體是持久的——它們持續運行直到你縮減或刪除 endpoint，無論是否有流量都按秒計費。

延遲特性

實時 endpoint 對典型模型能提供低個位數毫秒到次秒的延遲。P50 延遲取決於模型大小和執行個體類型；P99 延遲取決於冷啟動規避、GC 暫停，以及是否正在擴展中。實時是唯一能真正達到 100ms 以下 SLA 的 endpoint 類型。

自動擴展配置

SageMaker endpoint 自動擴展支援目標追蹤（最常見——對 InvocationsPerInstance 目標值進行擴展）、步進擴展（CloudWatch 警報閾值觸發離散擴展步驟），以及排程擴展（預期的負載模式）。目標追蹤是應對不可預測生產流量的正確答案；步進擴展適合已知的尖峰模式；排程則適合已知的週期性（例如僅在上班時間服務的系統）。

何時選擇實時

• 有嚴格延遲 SLA（< 1 秒）的 API 服務
• 持續中到高流量，閒置成本被請求量抵消
• Payload 小於 6 MB
• 需要熱模型以避免任何冷啟動延遲
• 用於 A/B 測試或 shadow 部署的生產 variant

非同步推論 Endpoint——大型 Payload、長時間處理

非同步推論解決了實時無法處理的情況：大型 payload、長時間執行的模型呼叫，以及可以忍受以分鐘計算的等待時間。

架構

客戶端將輸入上傳至 S3，以 S3 URI 呼叫 InvokeEndpointAsync，並立即收到 InferenceId。請求落入 SageMaker 管理的 SQS 佇列。後端執行個體從佇列取出請求、執行模型、將回應寫入 S3 輸出位置，並在完成時選擇性地發布至 SNS 主題。最大 payload：1 GB。每個請求最長處理時間：1 小時。

縮減至零

非同步 endpoint 支援將自動擴展策略的 MinCapacity 設為零來實現縮減至零。當佇列耗盡且流量停止時，執行個體數量降至零並暫停計費。佇列中的新請求觸發冷啟動（執行個體開機、模型載入），然後繼續處理。縮減至零是非同步（和無伺服器）獨有的特性——實時 endpoint 始終至少保留一個執行個體。

何時選擇非同步

• Payload 在 6 MB 到 1 GB 之間（超過實時上限）
• 處理時間超過 60 秒、最長 1 小時
• 流量可以忍受基於佇列的傳遞
• 對成本敏感、在突發之間縮減至零可節省費用
• 長時間執行的推論，如影片處理、大型文件 OCR、多步驟 LLM 推理

非同步 vs Batch Transform——常見混淆

非同步持有佇列，隨時間非同步地提供個別請求服務；Batch Transform 在一個任務中處理一個定義好的資料集並完成。如果你需要逐一提供進來的請求服務、結果幾分鐘後送達，使用非同步。如果你有一個固定的 N 筆資料集要一次性評分且之後沒有更多請求，使用 Batch Transform。

無伺服器推論 Endpoint——零星流量

無伺服器推論是低流量零星模型的成本最佳化模式。

架構與冷啟動

沒有持久執行個體。AWS 按請求佈建容量、按使用的毫秒計算費用，並在閒置時關閉。閒置後的第一個請求觸發冷啟動——執行時容器載入模型，大型模型可能需要幾秒到幾十秒。在熱窗口內的後續請求會重用已載入的容器。

配置限制

• 記憶體：1 GB 到 6 GB（以 1 GB 為單位）
• 最大並發：1 到 200 個並發請求（佈建並發可以較高成本減少冷啟動）
• Payload：4 MB 請求，4 MB 回應（比實時小）
• 逾時：每個請求 60 秒

佈建並發

若要以成本換取冷啟動規避，配置佈建並發——始終保持熱的容器數量。按低於按需的每毫秒費率計費，但需支付基礎小時費用。當已知低流量仍需要次秒首次請求延遲時很有用。

何時選擇無伺服器

• 有多分鐘閒置間隔的零星流量
• 可接受冷啟動（或有佈建並發的預算）
• Payload 小於 4 MB
• 對成本敏感、實時 endpoint 會在閒置時浪費費用
• 內部工具、開發/測試 endpoint、低流量 API

Batch Transform——離線大量評分

Batch Transform 根本不是 endpoint——它是一種臨時推論任務模式。

架構

你提交一個 CreateTransformJob 請求，指定模型、輸入 S3 前綴、輸出 S3 前綴、執行個體類型和執行個體數量。SageMaker 啟動請求的執行個體、將輸入跨執行個體分區、並行執行推論、將結果寫入輸出前綴，然後關閉執行個體。沒有持久 endpoint、沒有佇列、沒有自動擴展——只是一個有限邊界的任務。

輸入模式

• MultiRecord——一個 HTTP 請求攜帶多筆記錄，批次量最高 MaxPayloadInMB（預設 6 MB）
• SingleRecord——每筆記錄一個 HTTP 請求，速度較慢但對可變大小輸入更簡單

分割策略

SplitType 參數控制 SageMaker 如何分割輸入檔案：Line（以換行符分割，CSV/JSONL 常用）、RecordIO（二進位 RecordIO 格式）、TFRecord（TensorFlow 記錄），或 None（每個請求整個檔案）。

何時選擇 Batch Transform

• 在一個任務中評分的定義資料集（無串流請求）
• 延遲 SLA 以小時計（隔夜批次可接受）
• 對成本敏感——只為任務持續時間付費
• 需要跨多個執行個體並行化以減少實際時間的大型資料集
• 週期性評分（每天/每週/每月），長期存在的 endpoint 是浪費

為何 Batch Transform 比 Endpoint 更適合大量資料

透過實時 endpoint 處理一千萬筆記錄需要在整個過程中保持 endpoint 熱啟動（按秒計費）或建立一個自訂客戶端來限流請求以避免 5xx 錯誤。Batch Transform 只需一個 API 呼叫就自動處理分區、並行和關閉。成本大幅降低，因為任務持續時間正好等於工作持續時間——沒有閒置時間。

多模型 Endpoint——在共享基礎設施上 Hosting 多個模型

多模型 Endpoint（MME）在共享的執行個體叢集上 hosting 數千個模型，按需從 S3 動態載入模型。

架構

單一 SageMaker endpoint 具有單一推論容器，指向包含多個模型成品的 S3 前綴。當 InvokeEndpoint 到達並帶有指名特定模型的 TargetModel 標頭時，容器檢查該模型是否已載入記憶體；如果沒有，它從 S3 拉取成品、載入模型、如果記憶體滿了則驅逐最近最少使用的模型，然後提供預測。對同一模型的後續呼叫從記憶體快取提供服務。

何時選擇 MME

• 許多相似的模型使用相同框架（例如 SaaS 場景中每個客戶一個模型）
• 許多模型，每個模型的個別流量都很低
• 模型足夠小，可以同時在記憶體中放置多個
• 可以接受驅逐後首次呼叫的冷載入延遲（幾秒鐘）

MME 的錯誤場景

• 異質框架（一個模型用 TF，另一個用 PyTorch——MME 需要一個容器）
• 嚴格的每模型延遲 SLA，冷載入不可接受
• 少數大型模型，每個都佔滿一個執行個體的記憶體

MME vs 多容器 Endpoint

MME 在一個容器後面 hosting 多個模型；多容器 endpoint 在一個 endpoint 後面以序列鏈接多個容器。MME = 水平模型扇出；多容器 = 垂直容器流水線。混淆兩者是頻繁被測試的陷阱。

多容器 Endpoint——容器的序列流水線

多容器 endpoint 在一個 endpoint 後面鏈接最多十五個容器，有直接（單容器呼叫）或序列（流水線）模式可選。

序列模式——流水線模式

每個請求依序流過容器：容器 1（前處理）→ 容器 2（模型）→ 容器 3（後處理）。用於需要在推論時套用一致前處理的 ML 流水線，以匹配訓練時套用的前處理，消除訓練-服務偏差。

直接模式

多個模型共享一個 endpoint，但每個都用 TargetContainerHostname 獨立呼叫。當你想要 endpoint 層級的成本整合但需要每次呼叫的容器隔離時很有用。

何時選擇多容器

• 需要在推論時套用前處理/後處理，而不打包進模型容器
• 希望特徵轉換和模型程式碼之間有清晰的分離
• Hosting 輸出依序組合的集成模型

多容器的錯誤場景

• Hosting 許多獨立模型——那是 MME 的領域
• 需要每個步驟獨立擴展——多容器共享一個 endpoint 的擴展

SageMaker Inference Recommender——基於效能測試的執行個體選擇

為 endpoint 選擇正確的執行個體類型並非易事——Inference Recommender 自動化了效能測試。

它做什麼

Inference Recommender 用模擬負載對候選執行個體類型列表（或完全托管的預設列表）執行你的模型，測量延遲和吞吐量，並產生按延遲、成本或每美元吞吐量排名的建議報告。

預設 vs 進階任務

• 預設任務——對 SageMaker 精選的執行個體列表進行快速效能測試
• 進階任務——自訂執行個體列表、自訂流量模式、自訂模型延遲目標、自動擴展配置建議

輸出

列出每個候選執行個體及其測量的 P50/P90/P99 延遲、最大吞吐量、每百萬次推論成本，以及針對指定目標的建議執行個體類型的報告。建議可以直接套用到實時 endpoint 配置。

何時使用

在為生產確定執行個體類型之前，始終執行 Inference Recommender。手動選擇執行個體幾乎每次都會在任一方向出錯 2-3 倍（過度或不足佈建）。

SageMaker Neo——為目標硬體編譯模型

SageMaker Neo 將訓練好的模型編譯為在特定目標硬體上最佳化執行，包括邊緣裝置和雲端執行個體。

工作原理

提交一個訓練好的模型和目標硬體規格；Neo 使用 TVM 或其他編譯器將模型圖編譯成最佳化的二進位，通常能達到 2 倍加速和更小的記憶體佔用。目標包括 ml.c5、ml.p3、ml.inf1（Inferentia）、Jetson 裝置、Raspberry Pi 等更多。

Neo 搭配 Inferentia

若要在大規模下獲得最高成本效益的推論，透過 Neo 編譯至 AWS Inferentia（ml.inf1、ml.inf2）。對於許多工作負載，Inferentia 相比同等 GPU 執行個體的每次推論成本低了高達 70%。

何時使用 Neo

• 邊緣部署（Greengrass、IoT 裝置），最佳化的二進位必須適合受限的硬體
• 雲端 endpoint 的成本最佳化——透過 Neo 編譯至 Inferentia
• 不改變執行個體類型的情況下降低延遲

Endpoint 自動擴展——配置模式

除 Batch Transform 外的所有 endpoint 類型都支援自動擴展。

目標追蹤——預設

預設值是 SageMakerVariantInvocationsPerInstance——當每個執行個體的呼叫次數超過目標值時向上擴展，低於時向下擴展。簡單、穩健，建議用於大多數生產 endpoint。

步進擴展

CloudWatch 警報閾值觸發離散擴展步驟。比目標追蹤控制更精細，但更難調整。

排程擴展

在已知的流量事件前預先擴展（黑色星期五、季末報告）。與目標追蹤結合作為安全網。

縮減至零

透過設定 MinCapacity = 0 可用於無伺服器和非同步 endpoint。實時 endpoint 不可用——它們始終至少運行一個執行個體。

SageMaker Endpoint 決策矩陣

這是回答大多數 MLA-C01 endpoint 選擇問題的單頁參考。

如何在考試中使用矩陣

題幹給你限制條件。劃掉違反任何限制的欄位。剩餘的欄位就是答案。如果兩個欄位都符合，尋找成本最佳化提示或延遲提示，選擇更符合的那個。

MLA-C01 常見 Endpoint 類型陷阱

陷阱一：零星流量使用實時

一個每天被呼叫 100 次的實時 endpoint 成本與被呼叫一千萬次相同。考試用「每兩小時」或「不頻繁」的提示設置這道題——正確答案是無伺服器。

陷阱二：有嚴格截止時間時使用非同步

非同步 endpoint 有佇列。如果佇列深度增加，回應延遲就線性增長。非同步對「請求必須在 30 秒內完成」的場景是錯誤的——那是實時的領域。

陷阱三：串流請求使用 Batch Transform

Batch Transform 處理固定資料集然後關閉。如果工作負載是持續的傳入請求串流，需要幾分鐘後的結果，那是非同步，不是 Batch Transform。

陷阱四：異質框架使用多模型 Endpoint

MME 在一個推論容器後面 hosting 多個模型。所有模型必須使用相同的框架和容器。混合 TensorFlow 和 PyTorch 模型需要多容器 endpoint 或獨立的 endpoint，不是 MME。

陷阱五：100ms 以下 SLA 使用無伺服器

冷啟動使無伺服器不適用於嚴格的 100ms 以下 SLA。即使使用佈建並發，長時間閒置後的第一個請求可能產生啟動成本。延遲關鍵的生產環境 = 實時。

陷阱六：Inference Recommender 的輸出是可選的

考試期望你對生產規模調整使用 Inference Recommender。「選擇執行訓練的執行個體類型」永遠是錯的。

陷阱七：Neo 編譯是免費的

Neo 編譯任務在 SageMaker 算力上執行並產生費用。Neo 是一次性投資，透過降低 endpoint 成本來回收——但編譯本身不是免費的。

陷阱八：實時支援 1 GB Payload

實時 payload 上限是 6 MB 請求和 6 MB 回應。對於更大的 payload，使用非同步（最高 1 GB）或先上傳至 S3 然後在小型 payload 中傳遞 S3 URI（常見模式）。

FAQ——SageMaker Endpoint 類型選擇

Q1：當兩者都能滿足工作負載時，如何在非同步推論和 Batch Transform 之間選擇？

看請求模式。非同步服務持續的個別請求串流，每個請求在不同時間到達並獲得自己的回應。Batch Transform 在一個任務中處理一個固定資料集，整個資料集在任務開始前作為輸入已準備就緒。如果你的輸入是整天持續到來的請求串流，使用非同步。如果你的輸入是作為一組 S3 物件具體化的已知資料集，使用 Batch Transform。從成本角度，Batch Transform 對一次性任務更便宜，因為兩次執行之間沒有持久 endpoint；非同步對有縮減至零的串流比實時更便宜，但當工作可以批次到單一任務時比 Batch Transform 更貴。MLA-C01 題幹關鍵詞：「持續請求」或「整天」→ 非同步；「夜間批次」或「處理資料集」→ Batch Transform。

Q2：多模型 Endpoint 何時優於獨立的單模型 Endpoint？

當你有許多相似的模型（相同框架、相同容器）且個別流量很低時。每個獨立的單模型 endpoint 至少運行一個執行個體，無論流量如何都要全額付費。有一百個低流量模型，就意味著至少一百個執行個體。在一個 MME 後面，這一百個模型共享幾個執行個體，按需從 S3 載入模型，記憶體壓力下驅逐。成本可降低 10 到 100 倍。盈虧平衡點取決於每個模型的流量——一旦個別模型流量足以支撐自己的執行個體，MME 就不再有幫助。MLA-C01 題幹中「數千個客戶特定模型」或「SaaS 應用中每個租戶一個模型」幾乎總是以 MME 為正確答案。

Q3：無伺服器推論冷啟動的實際成本是多少，如何緩解？

冷啟動對中等模型通常是 5-30 秒，取決於容器大小和模型成品大小。長時間閒置後的第一個請求支付全部成本；熱窗口內（通常 5-15 分鐘）的後續請求以次秒延遲命中熱容器。緩解選項：啟用佈建並發（熱容器始終保留，較低的每毫秒費率但有基礎小時費用）、使用更快載入的小型模型、以更小成品格式快取模型，或者如果只影響工作階段的第一個使用者則接受冷啟動。對於內部工具和開發/測試，原始無伺服器就夠了。對於外部面向、低流量的 API，第一個使用者不能看到冷啟動的情況，並發性 = 1 的佈建並發是典型的修復方案。

Q4：可以對具有多個生產 variant 的實時 endpoint 使用自動擴展嗎？

可以——每個生產 variant 有自己的自動擴展配置。你可以根據每個 variant 的流量獨立擴展 variant A 和 variant B，當 variant A 獲得 90% 流量而 variant B 獲得 10% 流量的 A/B 測試時很有用。10% 的 variant 縮減至其最小容量（實時通常是 1 個執行個體），而 90% 的 variant 隨著負載增長向外擴展。生產 variant 的自動擴展是 SageMaker 部署護欄用於安全發布的配置之一——護欄監控新 variant 的指標，如果 variant 意外擴展或違反 CloudWatch 警報閾值，可以觸發自動回滾。

Q5：何時應該用 SageMaker Neo 編譯模型，典型的效能提升是多少？

當你部署到邊緣硬體（受限記憶體或算力）或想要在 AWS Inferentia 上執行以獲得成本最佳化的雲端推論時，用 Neo 編譯。典型提升：在相同硬體上延遲降低 2 倍，從 GPU 移到 Inferentia 時成本降低 3 到 10 倍。Neo 對具有定義良好運算子集的視覺和 NLP 模型最有效（ResNet、BERT、YOLO 衍生品）；最先進的自訂架構可能無法乾淨地編譯。工作流程：在 GPU 上訓練、用 Neo 編譯目標為 ml.inf1 或 ml.inf2、在 Inferentia 執行個體類型上將編譯成品部署在實時 endpoint 後面、驗證延遲和精確度一致性、然後切換。MLA-C01 考試將 Neo 測試為邊緣部署的答案，以及「不重新訓練的情況下降低推論成本」的答案。

Q6：Inference Recommender 與手動測試執行個體類型有何不同？

手動測試需要將模型部署到每個候選執行個體、執行負載生成器、測量指標、拆除、對每個執行個體類型重複——通常四到八種執行個體類型意味著四到八個完整的部署週期，每個耗時三十分鐘到一小時。Inference Recommender 自動化這個過程：一個 API 呼叫啟動效能測試，SageMaker 並行佈建每個候選執行個體、執行模擬負載、擷取延遲和吞吐量指標，並在十五到三十分鐘內產生比較報告。輸出按你選擇的目標（最低延遲、每百萬次推論最低成本、最高吞吐量）排名執行個體，並建議自動擴展配置。對於生產部署決策，Inference Recommender 是 AWS 建議的模式；手動測試對一次性實驗是可接受的。MLA-C01 考試可靠地將 Inference Recommender 測試為「什麼是選擇 endpoint 執行個體類型的建議方式」的正確答案。

Q7：是否有 SageMaker endpoint 模式能將前處理、模型推論和後處理組合在一個部署中？

有——序列模式的多容器 endpoint。你定義最多十五個容器的序列（通常是前處理 → 模型 → 後處理），SageMaker 按每個請求鏈接它們：輸入進入容器 1，容器 1 的輸出成為容器 2 的輸入，依此類推。這個模式把前處理邏輯從模型容器中分離出來，當前處理必須匹配訓練時的前處理（消除訓練-服務偏差）以及當你想要在多個模型版本間共享一個前處理容器時很有用。替代方案是把前處理打包進模型容器本身（更簡單但耦合前處理和模型版本），或在客戶端做前處理（偏差風險高）。對於 MLOps 成熟度，多容器序列模式是當問題提到「訓練和推論間一致的前處理」或「模型前的特徵轉換流水線」時的正確答案。