生成式 AI 推論的難處不在模型本身，而在模型動輒數十到數百 GB、延遲以每秒 token 計算、冷啟動可能長達數分鐘，而傳統監控工具看不到任何 token 層級訊號。AWS 在 2026 年 9 月 18 日的文章裡回顧了 SageMaker AI 今年以來的 13 項推論能力，分成兩條部署路徑：全託管的 managed endpoints，以及給需要 Kubernetes 原生控制的團隊用的 SageMaker HyperPod Inference。
對產品團隊來說，這份清單的價值不是「又多了幾個功能」，而是過去只能靠猜的幾個決策點，開始有具體參數可以調。
選執行個體不再靠兩三週的人工 benchmark
過去要挑對 instance type、serving container 與最佳化設定，通常得花兩到三週手動測試上千種組合，而多數團隊根本沒有這種人力。2026 年 4 月推出的 inference recommendations 把這件事拆成三步：先依模型架構、大小與記憶體需求縮小 instance 範圍，再依目標套用對應技術（吞吐量用 EAGLE 3.0 speculative decoding、延遲用 kernel tuning、依模型大小決定 tensor parallelism），最後在真實 GPU 上跑 NVIDIA AIPerf 並附上多次執行的信心區間。
輸出是一份可直接部署的 SageMaker Model Package，附帶 TTFT、ITL、P50/P90/P99 延遲、吞吐量與成本預估。AWS 示範的例子是在 GPT-OSS-20B 上把吞吐量拉到每秒兩倍 token，而請求延遲不變。產生建議本身不收費，有 ML Reservations 的客戶可以在保留容量上免費 benchmark。
這裡的實務意義是：容量與成本的取捨從「先上線再觀察」變成「上線前就有數字」。如果你的團隊正在做模型選擇與路由的決策，這種把候選方案先量化再決定的流程，和我們先前談過的 LLM routing 與模型選擇的取捨 是同一個思路。
容量不足不再是單點故障
2026 年 5 月的 capacity-aware instance pools 處理的是一個很具體的痛點：以前 endpoint 綁定單一 instance type，一旦該規格缺容量，endpoint 會在服務第一個請求之前就失敗。現在客戶可以定義最多五種 instance type 的優先順序清單，SageMaker 在建立、scale-out 與 scale-in 三個階段自動依序嘗試。建立時第一順位沒容量就立刻退到下一順位；擴容時由下一個可用規格吸收需求；縮容時先移除備援執行個體，讓機隊隨容量釋出回到偏好的硬體。
每個 instance type 有獨立的 CloudWatch metric dimension，可以對異質機隊套用加權 scaling policy，每個 pool 項目也能各自指向不同的最佳化模型設定。這對需要同時兼顧成本與延遲的團隊來說，等於把「缺容量就掛掉」換成「降級但仍可服務」。
可觀測性從事後追查變成預設開啟
2026 年 6 月的 inference observability 讓 SageMaker 透過原生 OpenTelemetry 輸出 100 多項推論指標，並附上 CloudWatch 的 Insights dashboard，不需要自己埋 instrumentation。新 endpoint 預設開啟，進入 InService 狀態後兩分鐘內就有指標。dashboard 覆蓋三塊：效能（TTFT、ITL、吞吐量、KV cache 使用率、佇列深度）、容量（GPU 使用率、記憶體、溫度、磁碟，用蜂巢視覺化呈現）、可靠性（可用區分布與風險評分、冷啟動各階段拆解、擴縮事件歷史）。另外提供 PromQL 相容端點，可從 Amazon Managed Grafana 以 SigV4 查詢。
同一批更新裡還有幾個降低整合摩擦的項目：OpenAI 相容 API 讓原本用 OpenAI SDK、LangChain 或 Strands Agents 的應用只要改 endpoint URL，認證改用最長 12 小時的 bearer token；container caching 在支援的加速器機型上自動啟用，AWS 以 Qwen3-8B 在 ml.g6.2xlarge 搭配 LMI container 為例，端到端啟動延遲從 525 秒降到 258 秒；async inference 現在接受最大 128,000 bytes 的 inline payload，省掉每次請求先上傳 S3 的步驟。
該怎麼看這份清單
已確認的事實是：AWS 說 2026 年以來在這兩條路徑上共推出 13 項能力，並在文章中列出各自的發布月份與適用範圍。至於這些能力在真實生產環境的長期表現，來源沒有提供第三方驗證，示範數字也都來自 AWS 自己的測試情境。
對正在評估推論平台的團隊，實際可做的下一步是：先確認自己卡住的是哪一層。如果是選型與成本估算，inference recommendations 值得先試；如果是尖峰時容量拿不到，instance pools 的優先順序清單可以直接對應；如果是事故發生後查不到原因，那 100 多項預設指標與 dashboard 會比事後補 instrumentation 便宜得多。把問題定位清楚，再決定要不要動架構。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。