Amazon AIF-C01: AI/ML 成本最佳化與定價 — 學習指南
屬於 AWS AI Practitioner AIF-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
Bedrock、SageMaker 與 EC2 的成本驅動因素及定價模型
AI/ML 工作負載的定價可分為運算、儲存、網路和服務特定指標的計費。透過 Amazon Bedrock 存取基礎模型，文字工作負載通常是按請求或 token 計費，而串流 API 則是按秒計費；SageMaker 則針對訓練和多租戶託管收取執行個體小時費用，外加資料傳輸和儲存費用。以 EC2 為基礎的託管則產生原始的執行個體小時成本，並額外收取 EBS、EFS 或 FSx 的儲存費用以及 VPC 的出口流量費用。主要的成本驅動因素包括模型大小（較大的模型會增加 token/數學運算量和記憶體佔用空間）、推論吞吐量（對延遲敏感的同步呼叫若固定在昂貴的 GPU 上，成本會更高），以及用於檢索增強生成 (RAG) 的資料移動，在這種情況下，嵌入查詢和向量搜尋會使呼叫次數倍增。從業人員常見的陷阱包括：低估高 QPS 的 RAG 系統的嵌入成本、讓多個閒置的 SageMaker 端點持續運行，以及為了將 PII 保留在區域內而忽略了跨區域的出口流量費用。因此，決策標準應考量請求量、每個請求的延遲容忍度、模型是否需要微調或可直接使用現成模型，以及在計入管理和擴展的額外開銷後，由供應商管理的推論 (Bedrock/SageMaker 端點) 或自行託管的 EC2/GPU 執行個體何者能提供更佳的 TCO。
執行個體選擇、Spot 執行個體與運算優化模式
選擇執行個體會同時影響效能和成本。對於訓練，當大規模矩陣吞吐量至關重要時，應使用 Trainium (trn1) 或 GPU 叢集 (p4/p5)；對於推論，則建議優先選擇 Inferentia/Inf2 (inf1/inf2) 或基於 Graviton 的 CPU 推論來處理較小的模型，以降低成本。像 SageMaker Managed Spot Training 和 SageMaker Distributed Training 這類的託管服務整合了檢查點設定 (checkpointing)，並能自動回收 Spot 容量，從而大幅降低訓練成本；然而，對於低延遲的生產環境，除非結合了穩健的備援機制，否則使用 Spot 是個陷阱。能減少開支的架構模式包括：非同步批次處理、具備冷啟動保護的自動擴展、使用多模型端點將許多小模型整合到單一主機上，以及利用混合精度和量化來降低記憶體和吞吐量需求。使用 DeepSpeed 或 ZeRO 等框架來降低大型模型訓練的記憶體佔用空間，並評估參數效率微調 (LoRA/adapters) 以避免完整的模型重新訓練。一個常見的錯誤是，在 CPU 或 Inferentia 執行個體能提供更佳性價比的情況下，仍為嵌入密集型的工作負載使用頂級 GPU。
模型選擇的權衡取捨與成本感知策略
模型的選擇是在成本、延遲、準確性和資料敏感性之間的一種權衡。Bedrock 中的基礎模型提供託管擴展、安全工具和快速迭代，但會產生按呼叫或按 token 計算的費用，這些費用在規模擴大時可能佔主導地位；而在 SageMaker 或 EC2 上託管的開源模型，若您能攤提託管和維運的額外開銷，則可以降低每次推論的費用。混合式架構運作良好：用一個小型、便宜的模型處理大部分請求，並在遇到複雜查詢時升級到較大的模型；或者使用檢索增強生成，其中繁重的上下文由向量儲存庫 (OpenSearch、由 Amazon QLDB 支援的向量資料庫或第三方服務) 提供，而只將簡潔的提示傳送給 LLM。微調決策應考慮參數效率方法 (LoRA、adapters) 以及用於 text-to-text 任務的 JSONL 提示-完成對 (prompt-completion pairs)，以限制資料集和運算資源的使用。常見的陷阱包括：不必要地微調過大的模型，而不是使用提示工程；忽略提示 token 長度的膨脹問題；以及未對高重複性查詢的回應進行快取或去重複化。
用於成本控制的儲存、資料本地性、治理與可觀測性
儲存方案的選擇會影響每月成本與法規遵循。對於資料集，應使用 S3 搭配生命週期政策、Intelligent-Tiering 及壓縮格式 (Parquet/TFRecord)；將活躍的訓練資料暫存於高吞吐量的儲存層，並將原始資產封存至 Glacier。針對 PII 與資料落地需求，應將 S3 儲存貯體、KMS 金鑰及運算資源保留在指定的 AWS Region 內，並透過 VPC 端點、IAM 政策及私有網路控制存取，以防止意外的跨區域資料傳輸。RAG 的檢索管線應將向量儲存 (Amazon OpenSearch Service 或建置在 EC2/EBS 上的嵌入儲存) 與推論層部署在同一位置，以避免傳輸成本與延遲。SageMaker Clarify、Debugger 與 Model Monitor 等可觀測性與可解釋性工具能提供治理與早期漂移偵測，但會增加成本——應部署基於抽樣的監控器來控制開銷。透過選擇高效晶片 (Inferentia/Trainium) 與批次處理來最小化環境足跡與帳單費用；一個常見的錯誤是啟用完整的日誌記錄與持續模型監控，卻未設定抽樣閾值，這不僅推高成本與雜訊，所提供的增量價值卻微乎其微。
實務問題：使用案例情境
情境：Acme Retail 執行一個 AWS AI 技術堆疊，使用 Amazon Bedrock 存取 LLM、Amazon SageMaker 進行模型訓練/託管、S3 儲存資料，以及 Amazon OpenSearch 建立產品索引。他們每日必須生成數千筆段落長度的產品描述，同時要維持一致的品牌語氣、遵守嚴格的區域內 PII 規定，並達成緊湊的成本目標。
挑戰：大規模交付高品質、具品牌風格的描述，同時最小化每筆描述的成本，並確保客戶資料絕不離開指定的 AWS Region。
建議方法：
- 使用雙層推論管線：首先將所有請求路由到一個輕量級、本地託管在 SageMaker 或 EC2 上的模型 (經過量化)，以處理常見的 SKU 與簡單描述；將複雜或低信賴度的案例升級交由 Bedrock 基礎模型處理。
- 將嵌入與檢索索引儲存在區域內的 Amazon OpenSearch 中；使用精簡的檢索內容以降低 Bedrock 的 token 使用量，並將常見的回應快取在 ElastiCache 中。
- 使用參數效率方法 (LoRA) 在 SageMaker Managed Spot Training 上微調一個小型的特化模型，並將檢查點儲存至 S3，盡量減少完整模型的重新訓練。
- 強制執行區域邊界控制：將 S3 儲存貯體與 KMS 金鑰置於區域內，為 Bedrock/SageMaker 設定 VPC 端點，並使用基於抽樣的 Model Monitor + Clarify 來限制監控成本。
基本原理：結合一個低成本的基準模型與選擇性升級機制，可以最小化每筆描述的 token 與執行個體成本，而 RAG 與快取則能減少對 Bedrock 的呼叫。Managed Spot Training 與參數效率微調降低了訓練費用與儲存開銷，同時區域內的控制措施也滿足了 PII 與合規性要求。
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →