回到頂部
同一個生成式 AI 模型通過延遲、吞吐與成本三條實體測試軌道,最後由工程師選擇部署規格

SageMaker 推論推薦怎麼用?延遲、吞吐與成本實測指南

Amazon SageMaker Studio 可自動比較 GPU、容器與推論最佳化。整理使用流程、費用、四項指標與上線前的真實流量驗證。

內容查核: 來源查核:

Amazon SageMaker AI Studio 的推論推薦,適合已選定模型、卻還在猜 GPU 規格與服務參數的團隊;它不替你判斷模型答案好不好。 8 月 20 日的更新把原有 API 流程帶進 Studio,使用者可選工作負載、最佳化目標與模型來源,再比較實測後的部署組合。

AWS 表示,推薦會使用 NVIDIA AIPerf 在實際 GPU 基礎設施量測,也可能依模型最佳化文件套用推測解碼或核心調校。這比只看硬體規格表有用,但結果仍是指定流量設定下的基礎設施測試,不包含繁中答案品質、內容安全與業務正確率。

使用流程與真正要填的資料

Studio 的路徑在 Jobs 下的 Inference optimization。依 AWS 操作說明,流程可拆成四步:

步驟選項實務判斷
工作負載Interact、Generate、Summarize、Custom預設只適合初篩,正式案應用 Custom 放入自有資料
目標最低延遲、最高吞吐、最低成本一次只代表一個排序優先,不是三者同時最優
模型來源JumpStart、S3、Model Registry、既有模型自有模型還要確認容器、權重格式與權限
運算範圍自動挑選或指定執行個體有保留容量或地區限制時,先縮小候選範圍

AWS 文件列出的結果包含首個 Token 時間(TTFT)、Token 間延遲(ITL)、吞吐與成本。客服聊天通常更在意 TTFT 和尾端延遲;批次摘要較在意整體吞吐;高流量 API 還要換算每個成功請求的完整成本。

免費推薦不等於免費測試

AWS 公告明確寫出,產生推薦沒有額外服務費,最佳化工作和基準測試期間建立的端點仍按標準運算費率計費。模型大、候選機型多、Custom 資料長或併發高,測試帳單自然增加。

我的建議是先跑一輪小範圍初篩,再把前兩名放進長時間壓力測試。不要同時開十幾種昂貴 GPU,只為得到一張看似完整的排名表。成本治理可搭配AI 成本最佳化方法,上線後則要用SageMaker 推論可觀測性持續確認 GPU 與輸出品質。

上線前怎麼驗收

先從最近的真實請求建立輸入與輸出長度分布,讓 Custom 測試同時涵蓋短問答、長上下文與極端輸出。流量也不能只填平均併發;平日、尖峰與瞬間突發要分開模擬,再記錄 p50、p90、p95 延遲,才看得到少數使用者是否一直等不到第一個 Token。

成本分母只放成功請求。逾時、空回覆、被安全政策擋下與品質不合格,都要列入失敗率;同一份品質測試集則要在最佳化前後各跑一次,確認速度沒有換來退步。最後驗證地區容量、資料傳送限制和回退設定,讓推薦的第一名拿不到容量時,服務仍有已知可用的第二選擇。

這項功能在 Bedrock 與 SageMaker 的選擇上也沒有改變基本分工。要深度控制權重、容器和 GPU,才偏向 SageMaker;若重點是直接呼叫受管模型,可先看Bedrock 與 SageMaker 比較。我不建議只因 Studio 出現一鍵部署,就把原型端點直接當正式環境。

常見問題

SageMaker Generative AI Inference Recommendations 免費嗎?

推薦服務本身不另收費,但最佳化工作與基準測試建立的運算資源仍會計費。執行前要限制候選機型、測試時間與預算告警。

最低 TTFT 就是最好的 LLM 部署嗎?

不一定。TTFT 只反映開始回覆的速度,還要看 Token 間延遲、整體吞吐、失敗率、答案品質與每次成功請求成本。

可以直接用 Interact 預設資料決定正式規格嗎?

預設設定適合先篩選候選組合,不足以代表你的流量。正式決策應用 Custom 帶入真實長度、併發與評測資料,再做持續壓力測試。

參考來源

№ · further reading

延伸閱讀