本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 成本最佳化
<a name="cost-optimization"></a>

隨著無伺服器和 AI 工作負載的擴展，成本可見性和控制成為永續營運的基礎。與傳統運算不同，其中每個執行個體小時的成本是可預測的，無伺服器和生成式 AI 服務帶來了新的成本維度：
+ 依字符用量的推論成本 （例如 Amazon Bedrock)
+ 每次調用計費 （例如 AWS Lambda 和 AWS Step Functions)
+ 事件磁碟區驅動觸發 （例如，Amazon EventBridge 和 Amazon S3)
+ 知識庫、工具呼叫和擷取增強產生 (RAG) 擴展動態

如果沒有仔細的規劃和監控，組織會面臨意外的計費高峰，尤其是使用可擴展的大型語言模型 (LLMs) 或無限制的事件迴圈。

## 為什麼成本最佳化對無伺服器 AI 至關重要
<a name="section-cost-importance"></a>

下列因素會導致無伺服器 AI 系統的成本：
+ **LLM 大小選擇** – 較高層級的模型 （例如 [Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/what-is-nova.html) Premier) 每個權杖的價格明顯更高。
+ **提示長度和詳細程度** – 較長的輸入和輸出會線性增加 Amazon Bedrock 成本。
+ **工具調用擴展 – **使用太多或備援工具的代理程式可能會機架化 Lambda 和資料傳輸費用。
+ **Step Functions 工作流程精細程度** – 過度分割的工作流程會增加狀態轉換和執行持續時間。
+ **資料移動** – 過多的跨區域流量、不必要的 RAG 索引或重複的知識庫擷取可能會變得昂貴。

## 成本最佳化策略
<a name="section-cost-strategies"></a>

請考慮實作下列策略，以最佳化無伺服器 AI 工作負載中的成本：
+ **使用分層模型選擇** – Amazon Nova、Amazon Titan 和 Anthropic Claude 等模型提供成本、速度和準確性權衡的不同定價模型。若要實作此策略，請將低複雜度提示路由至 Amazon Nova Micro，並只在可信度低時才呈報。
+ **修剪提示和輸出** – 字符計數是 Amazon Bedrock 中最大的成本驅動因素。若要實作此策略，請強制執行提示大小上限、使用簡潔的措辭，並避免詳細完成。
+ **控制 RAG 擷取範圍** – 知識庫中未繫結的文件可以擴展內容。若要實作此策略，請使用中繼資料篩選條件和排名前 K。此外，僅將相關內容插入 LLM 提示中。
+ **用於推論的批次事件** – 個別推論呼叫的成本高於批次處理。若要實作此策略，請將輸入分組 （例如情緒分析和摘要），並執行每個批次的單一推論。
+ **使用 Step Functions 進行彙總，而非微管理** – 過度使用原子狀態轉換會導致長時間。若要實作此策略，請將相關邏輯分組為 Lambda 單位，並避免狀態爆炸模式。
+ **非同步回應處理** – 不要等待慢速模型來封鎖運算。若要實作此策略，請使用 [EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 搭配 [Amazon Simple Queue Service](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) (Amazon SQS) 和 Lambda 進行延遲回應模式 （例如，非同步摘要）。
+ **使用 Amazon Bedrock 成本分配標籤** – 標籤可根據應用程式和團隊提供可見性。若要實作此策略，請將標準化標籤套用至 Amazon Bedrock 呼叫 （例如 `Project=MarketingAI`和 `Team=GenOps`)。
+ **調校重試和可信度邏輯** – 不必要的重試或備用鏈會膨脹成本。若要實作此策略，請使用結構化可信度閾值和提早結束來限制重試。
+ **使用快取進行工具呼叫** – 許多客服人員工具叫用重複資料擷取。若要實作此策略，請將最近的工具結果與存留時間 (TTL) 存放在 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) 中，並在未變更時重複使用。
+ **利用預留並行或佈建並行** （如有需要） – 在大量情況下，此策略可減少冷啟動和成本不確定性。僅針對具有可預測流量和長暖機時間的函數啟用此策略，以實作此策略。

## 範例：成本感知生成式 AI 助理
<a name="section-cost-example-assistant"></a>

支援助理是使用 [Amazon Bedrock Agents](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html) 建置。它也使用 Lambda 中整合用於即時資料存取的工具 （例如，使用者訂單和傳回政策）。最後，它使用知識庫，其中包含產品文件、FAQs和政策 PDF 檔案。

助理的 函數如下所示：

1. 它透過 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) 透過聊天 （前端） 接收自然語言請求。

1. 對於政策查詢等簡單問題，它會執行下列動作：
   + 叫用輕量型 LLM (Amazon Nova Lite) 來制定答案。
   + 從 Amazon Bedrock 知識庫提取基礎內容。

1. 對於更複雜的查詢，例如多步驟解析，它會執行下列動作：
   + 啟用具有目標導向協同運作的 Amazon Bedrock 代理程式。
   + 使用 Lambda 工具`initiateReturn(orderId)`，例如 `getOrderStats(userId)`、 和 `lookupDeliveryOptions(zipCode)`。

1. 回應會經過後製處理，以執行下列動作：
   + 移除外部輸出。
   + 驗證符合政策的訊息。
   + 日誌互動資料。

下列成本最佳化策略適用於此範例 AI 助理：
+ **分層模型路由**透過使用較小的模型處理較小的請求來降低成本。此方法將 Amazon Nova Lite 用於常見問答集樣式提示，Claude 3 Sonnet 僅用於需要推理或多個工具呼叫的 10% 案例。
+ **提示修剪和範本控制**可維持一致、成本可預測的用量。提示以權杖為上限，並以結構化範本建置 （例如，最多 400 個具有內容的權杖）。
+ **內容 RAG 範圍界定**可避免將多餘的文件注入 LLM 提示。知識庫會使用中繼資料篩選，將擷取限制為相關產品類別或政策網域。
+ 當使用者重述時，**工具呼叫結果快取**可避免重複的 Lambda 調用。來自 `getOrderStatus`和 的結果`lookupReturnWindow`會以 10 分鐘的 TTL 快取在 DynamoDB 中。
+ **以可信度為基礎的模型提升**平衡體驗 LLM 成本控制的品質。如果 Amazon Nova Lite 回應可信度 （由結構和 regex 啟發式測量） 很低，請回到 Anthropic Claude 或人工提升佇列。
+ **回應驗證器 Lambda** 可將不必要的輸出字符減少約 25%。此方法會消除詳細的模型完成、將回應格式化為簡潔的輸出，並記錄字符大小。
+ **成本標記**可啟用每個函數和每個環境的 FinOps 報告。所有 Amazon Bedrock 呼叫都會標記 `Application=SupportAssistant`、 `Environment=Production`和 `Team=CustomerSuccess`。

此範例顯示智慧型架構選擇如何降低營運成本，同時仍提供高品質、可擴展的支援自動化，例如分層模型路由、快取、範圍擷取和推論稽核。生成式 AI 助理範例提供可重複使用的範本，適用於人力資源助理、IT 服務台、合作夥伴入門機器人或客戶教育助理等領域。在每種情況下，範本都有助於在成本效益、信任和擴展之間取得平衡。

## 監控和提醒成本最佳化
<a name="section-cost-monitoring"></a>

下列 AWS 服務 協助監控和最佳化無伺服器 AI 工作負載的成本：
+ [CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)會追蹤 Amazon Bedrock 字符用量、Step Functions 步驟持續時間和 Lambda 調用成本。
+ [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) 在違反成本閾值時 （例如，每日字符成本） 提醒團隊。
+ [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) 和 [Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)提供每個應用程式、團隊或模型的支出檢視。
+ [Amazon Bedrock API](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#br-cloudwatch-metrics) 日誌 （透過 CloudWatch) 可分析提示結構和回應大小。
+ [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) 和 [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html) 日誌支援一次性或臨時查詢從 AWS CloudTrail 或自訂日誌匯出的用量資料。

## 成本最佳化警告訊號
<a name="section-cost-warning-signals"></a>

監控下列訊號以識別潛在的成本最佳化問題：
+ **字符使用量峰值** – 可以指示提示變更、新模型版本或過多的 RAG 擷取。
+ **增加 Amazon Bedrock 延遲** – 可能會導致較長的 Lambda 持續時間和每次推論的成本增加。
+ **每個客服人員工作階段的工具呼叫激增 **– 建議工具濫用或無效的提示邏輯。
+ **長時間執行的 Step Functions 步驟** – 可能是由過度分解的狀態或封鎖的非同步事件所導致。
+ **使用不足的模型層** – 表示為低風險請求的一級準確性付費。

## 成本最佳化摘要
<a name="section-cost-summary"></a>

AI 驅動的無伺服器成本最佳化不僅在於將支出降至最低。這是關於使運算和模型用量與每個決策的商業價值保持一致。透過適當的策略，組織可以負責任且自信地擴展，平衡創新與成本控制。

透過結合分層模型策略、提示和權杖紀律、工作流程調校，以及可觀測性和標記，企業可以從 AI 投資中釋放最大值，而無需預算超支。