AWS 出 Amazon Bedrock 成本控制 playbook：五步把 AI 出糧分到人頭

五步把 AI 出糧分到人頭

10 月 30 日，AWS 喺自家 Machine Learning 博客放咗份「Amazon Bedrock 成本控制 playbook」。Bedrock 係 AWS 嘅生成式 AI API 服務，呢份係廠商自己寫畀 FinOps（雲費用管理）同平台工程團隊嘅操作指南，唔係獨立測試。

核心論點係：生成式 AI 嘅成本唔係換個平啲嘅模型、或者叫各組縮短 prompt 就搞掂。真問題係三個——呢筆錢係邊個團隊用咗、用喺邊個 workload、有冇喺批准嘅預算之內。AWS 話喺 agentic（AI 代理）工作流下面，呢三個問題更迫在眉睫。

Agent 嘅錢使法同對話唔同

AWS 喺文內對比咗兩類負載：一般對話助手每次用户回合通常只呼叫一次模型；AI coding agent（會規劃改動、讀檔案、呼叫工具、反覆迭代嘅編程代理）會喺同一個 task 做多次模型呼叫，而且每次呼叫都揹住更大 context。

佢哋結論係 token 消耗隨「你畀 workflow 幾大自主權」同「context 幾大」而放縮，而唔係跟用户互動次數線性放大。因為消耗取決於 workload 點樣設計同運作，AWS 話生成式 AI 成本控制係「架構同運作層面嘅紀律」，並建議用 AWS Pricing Calculator 同 Bedrock 定價頁去建模，再用文內 Step 2 量度你哋實際 workload 嘅消耗。

AWS 出 Amazon Bedrock 成本控制 playbook：五步把 AI 出糧分到人頭 資料圖片：Pixabay

五個步驟做一條 loop

呢份 playbook 把成本控制拆成五個互相依賴嘅階段，排好順序行成一個 loop：

Attribute（歸屬）——每一分 Bedrock 出喺計費流水線都落到某個 identity、team、application。AWS 強調所有下游（chargeback、預算、強制、異常偵測）都靠呢一步。
Observe（觀察）——每個 request 都 log 落足夠 metadata，可以解釋嘢錢係點生返嚟。
Enforce（執行）——預算要「有牙」，最低限度要有 alert，風險夠高就設 hard block。
Optimize（優化）——喺平台層面做 model routing、caching、token limits 去除浪費，而唔係叫每個 team「小心啲」。
Operate（運作）——用小 scorecard 加定期 review cadence，將數據變成決定。

分工方面，FinOps 主導第一及第五步，平台工程主導二至四步，review 係雙方共同。AWS 特別講：跳過歸屬同觀察直接跳到 optimize，就係「盲估」。