AWS AI
全生命週期 MLOps：SageMaker 與自研 AI 晶片
全生命週期 MLOps：SageMaker 與自研 AI 晶片
第一次翻 SageMaker 的功能列表，多數人的反應是「這到底有幾個東西」。清單很長，名字又互相接近，看完常常更不知道該從哪裡下手。
比較好用的看法是把它當成一條產線：資料進來、訓練出模型、評估後登錄、部署成端點、監控後回頭重訓。這篇就照這條產線走一遍，最後再談 Trainium 與 Inferentia 這兩顆自研晶片該怎麼取捨。
你將學到什麼
當產線不當工具箱
五個階段各自對應哪些元件，先有這張地圖，功能列表才讀得動。
先查誰不再收新客
2026 年有幾個經典元件已不對新客戶開放，動工前先確認你依賴的那個還在不在。
推論端點的新介面
OpenAI 相容 API 與端點層可觀測性，讓生成式模型的線上服務好接也好查。
晶片從支援度倒推
Trainium 與 Inferentia 的選型判準是 Neuron 支援哪些框架與模型，不是規格表好看。
MLOps 做不起來，通常不是缺工具，而是沒有一個所有人都認的交接點。
先把 SageMaker 看成一條產線
SageMaker AI 的元件很多，硬記名字沒有意義。把它們按生命週期排一次，就會發現每個階段其實只有兩三個你真的會用到。
這張圖故意畫得簡單，因為 MLOps 的難處從來不在圖上。難的是把每個箭頭變成自動的、有紀錄的、失敗會叫人的流程。
動工前先確認：你要用的元件還收不收新客戶
這一段放在很前面，是因為它會直接讓一份照舊教學寫的架構文件失效。網路上大量的 SageMaker 教學仍在教那些元件。
依 AWS 官方文件（2026 年 8 月查閱），Amazon SageMaker Ground Truth 已不再開放新客戶。既有客戶可以照常使用，AWS 會持續投入安全與可用性，但不再規劃新功能。
SageMaker Clarify 的說明頁上有同樣的註記。這代表偏差偵測與可解釋性這一塊，新專案要另外找方案。
把你架構圖上每一個 AWS 元件的官方文件首頁打開，只看最上面那個提示框。維護模式、不再開放新客戶、改名這三種公告都會出現在那裡。這件事花不了多久，但可以省下「照著教學做卻拿到權限錯誤」的整個下午。
訓練這一段：什麼時候才需要 HyperPod
多數團隊的訓練其實用一般的訓練任務就夠了：把資料指過去、跑完、產出模型成品、收工。這條路便宜也簡單。
SageMaker HyperPod 解的是另一種問題。官方定義是提供常駐的機器學習環境，跑在具備韌性的叢集上，用來開發大型語言模型與擴散模型這類大模型。
關鍵字是韌性。當訓練要跑好幾天、幾百張加速卡，節點壞掉不是意外而是常態，平台就必須把故障復原做進來。
- HyperPod recipes：官方說明可在 HyperPod 或訓練任務中執行，訓練配接器建立在 NVIDIA NeMo 框架與 Neuronx 分散式訓練套件之上。
- 叢集編排：除了 Slurm，也支援以 Amazon EKS 編排，讓既有的 Kubernetes 訓練流程接得上。
- 任務治理：針對 EKS 叢集提供資源配置與可觀測性，看得到各團隊的用量、等待時間與可用運算。
- 訓練計畫：一種運算預留能力，讓你在指定時程內取得高需求的加速運算資源。
- Ray 支援：AWS 於 2026 年 8 月宣布強化 HyperPod 的 Ray 支援，包含內建可觀測性與韌性訓練。
判斷方法很直接：如果你的訓練從沒因為節點故障而重跑，你還不需要 HyperPod。等到「重跑一次要三天」變成真實成本，它才划算。
推論這一段：四種端點與 2026 年補上的介面
部署是最容易選錯的一段，因為大家習慣用模型大小去挑，但真正的判準是流量形狀與延遲要求。
| 端點型態 | 適合的流量 | 常見誤用 |
|---|---|---|
| 即時端點 | 穩定、需要低延遲的線上服務 | 為一天幾百次呼叫養著整排常駐執行個體 |
| 無伺服器端點 | 稀疏、可接受冷啟動的內部工具 | 拿來扛延遲敏感的前台請求 |
| 非同步端點 | 單次推論很久或請求酬載很大 | 硬拆成即時端點再自己刻佇列 |
| 批次轉換 | 完全離線、按批處理的工作 | 為了排程方便而長期掛著端點 |
2026 年這一側有幾個對生成式模型很實際的更新，值得知道。以下日期依 AWS 官方公告。
- OpenAI 相容 API（2026 年 5 月 21 日）：官方公告說明只要改端點網址，既有的 SDK 呼叫、串流邏輯與框架整合就能繼續運作，並點名 OpenAI SDK、LangChain 與 Strands Agents。
- 推論端點可觀測性（2026 年 6 月 18 日）：以 OpenTelemetry 原生指標自動發布，涵蓋首個 token 延遲、token 之間延遲、佇列深度、每秒 token 數、GPU 使用率與冷啟動拆解，可用預建的 CloudWatch 儀表板檢視，也能接 Grafana。
- 容量感知的推論部署（2026 年 4 月）：端點可以指定一份有優先序的執行個體型別清單，首選型別容量不足時自動遞補。
- 生成式 AI 推論建議進 Studio（2026 年 8 月）：原本以 API 提供的推論建議，補上了視覺化流程。
第二項的價值很容易被低估。生成式模型上線之後最難回答的問題是「它現在慢在哪裡」，而首個 token 延遲與佇列深度就是分辨「模型慢」與「排隊慢」的那把尺。
把它接成一條流水線：交接點只能有一個
元件都在，接不起來的原因幾乎都一樣：訓練的人交出的東西，跟部署的人期待的東西不是同一種東西。
所以 MLOps 產線第一個要立的規矩，是模型只能從模型登錄出去。筆記本裡跑出來的成品不算數，個人帳號裡的檔案不算數。
- Pipelines 負責串。 前處理、訓練、評估、註冊寫成一條可重跑的流程，不是四份手動筆記本。
- Model Registry 是唯一出口。 版本、核准狀態與跨帳號部署都掛在這裡，部署端只認登錄裡核准過的版本。
- 血緣與模型卡要一起產。 這份模型用了哪批資料、哪次訓練、哪組參數，事後要問得出來。
- Model Monitor 盯線上。 資料漂移與品質下滑要有告警，不能等業務單位來反映。
- 實驗紀錄集中。 用 MLflow 這類追蹤介面把實驗結果收在一處，不要散在各人的筆記本裡。
- 回路要真的接上。 監控觸發重訓、重訓走同一條流水線、產出再回到登錄，這個圈閉起來才算完成。
漂移告警自動觸發重訓沒問題，但自動把新版本推上線是另一回事。留一個核准關卡在模型登錄上，讓人看過評估報告再放行。全自動的 MLOps 在投影片上很漂亮，在半夜出事的時候你會希望中間有一個人。
自研晶片：Trainium 與 Inferentia 的定位與取捨
AWS 自研加速器的主線是兩個名字：Trainium 與 Inferentia。名字看起來就是訓練與推論分工，但 2026 年的實際定位要看得再細一點。
官方對 Trainium 的說法是為單一目標打造的 AI 晶片，追求大規模 AI 訓練與推論的最佳經濟效益。注意這句話同時包含了訓練與推論。
官方的 Trn3 UltraServers 頁面也把它定位在訓練與服務新一代代理式、推理型與影片生成應用，並列出可透過 EC2、SageMaker、SageMaker HyperPod、EKS、ECS 與 ParallelCluster 使用（2026 年 8 月查閱）。
Inferentia 這一側，官方頁面定位在深度學習與生成式 AI 的推論，對應的執行個體是 Inf1 與 Inf2。它仍然是成熟的推論選項。
自研晶片的第一個關卡不是效能，是支援度。AWS Neuron SDK 原生支援 PyTorch、vLLM、Hugging Face Transformers 與 Ray 等工具，也提供 Neuron Kernel Interface 讓你寫底層核心。但你的模型架構、運算元與量化方式是否在支援清單上，要逐項確認過才算數。這件事查文件要半小時，猜錯要重來一週。
務實的取捨大致是三種情況。第一種：運算成本已經是專案主要成本，模型也在支援清單上，那就值得認真評估。
第二種：還在探索階段、模型天天換架構，那就先用最通用的環境把方法試對，別把時間花在遷移上。
第三種：程式碼裡有大量自訂運算元或綁死特定生態工具，那遷移成本要誠實計入，不能只算單位運算價差。
不要用官方的比較數字做決策，用你自己的模型、自己的批次大小、自己的序列長度跑一次端到端測試，量的是完成一批真實工作的總成本與總時間。加速器的宣傳數字是在特定條件下量的，而你的工作負載幾乎不會剛好長成那個條件。
收尾：先立規矩，再挑工具
SageMaker 的元件會改名、會進維護模式、會有新介面補上來，這是常態。真正能撐過改版的是規矩，不是工具。
- 模型只從模型登錄出去，核准狀態是唯一的通行證。
- 每個部署都要能回答「這是哪次訓練、哪批資料」。
- 端點型態依流量形狀選，不依模型大小選。
- 上線之後的指標要看得到排隊與延遲，不只看錯誤率。
- 架構圖上的每個元件，每季確認一次它的官方狀態。
這五條跟你用哪家雲、哪個版本都無關。工具換了照樣成立，而這正是它們值得先立的原因。
