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 還要換算每個成功請求的完整成本。
測試資料怎麼準備，結果又怎麼選？
先把「我要做客服」改成可測量的工作：每次輸入包含哪些對話、最長會帶多少文件、希望輸出多長，以及多少人可能同時發問。依 Studio 操作流程，預設工作負載可以用來初篩；但看到結果前，要先核對它使用的輸入與輸出長度、併發設定，是否接近你的服務。
準備代表資料不等於把整個客服資料庫原封不動上傳。可以從已獲准使用的請求整理長度分布，再建立去識別的短問答、長文件問答與多輪對話樣本。帳號、電話、訂單編號改成測試值，但保留讓請求變長的結構。Custom 欄位、支援格式與模型限制以當前介面和文件為準，不能把本文的分析表直接當成可上傳的檔案格式。
下面是假設在相同模型、相同測試流量下取得的結果，只示範判讀，不是 AWS 機型報價，也不是本站 GPU 實測。完整請求延遲包含輸出結束前的時間，與首個 Token 時間不同。
| 指標 | 組合 A | 組合 B |
|---|---|---|
| 首個 Token 時間中位數 | 0.4 秒 | 0.8 秒 |
| 完整請求 P95 延遲 | 12 秒 | 7 秒 |
| 每小時成功完成請求 | 900 | 1,500 |
| 測試中的每小時運算成本 | US$2 | US$3 |
若客服需求是「多數人很快看到第一個字」，A 值得保留；但假設另訂完整請求 P95 不超過 8 秒，A 就不合格，不能因起頭較快而忽略長尾等待。P95 可以理解為約 95% 請求在這個時間內完成，其餘仍可能更慢；實際服務要同時看錯誤與逾時，不能把失敗件排掉後宣稱體驗良好。
若做晚間批次摘要，同一段持續負載下，A 的每千件成功運算成本約為 2 ÷ 900 × 1,000＝US$2.22，B 則為 3 ÷ 1,500 × 1,000＝US$2.00。B 每小時較貴，完成相同工作卻可能更省。這只算表內運算費，不含儲存、傳輸、維護或人工；白天流量很低、機器閒置時，也不能直接沿用這個滿載單價。
真正可採用的結果還需要答案品質不退步。假如 B 的速度來自不同精度或最佳化設定，請另外比較固定問題集的答案與結構化輸出；「服務有回 200」不是內容正確。最後留下模型版本、容器、輸入分布、併發與測試時間，下一次換規格才能公平重測。
免費推薦不等於免費測試
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 帶入真實長度、併發與評測資料，再做持續壓力測試。
參考來源
- AWS What’s New：Generative AI Inference Recommendation for Amazon SageMaker now available in the SageMaker AI Studio（2026-08-20）
- AWS Machine Learning Blog：Launching UI for generative AI inference recommendations in Amazon SageMaker AI（2026-07-13）
- AWS Documentation：Generative AI inference recommendations（2026-08-24 查核）
- AWS Documentation：Optimize model inference in Amazon SageMaker AI（2026-08-24 查核）
- GitHub ai-dynamo：AIPerf（2026-08-24 查核）