Balinder Walia
執行摘要
企業團隊越來越多地將在雲中託管基礎模型，而不是從頭開始訓練所有內容。Amazon Bedrock和Microsoft Azure AI Foundry（基於 Azure OpenAI 服務和更廣泛的型號目錄構建）提供託管 API、安全性和合規性構建塊，但不受控制的令牌使用、錯誤的容量模型和缺少可觀察性可以將試點變成意外發票。本文概述瞭如何在兩個平臺上部署生產工作負載，並且可以在不阻礙創新的情況下控制成本。
為什麼選擇託管而不是自行管理的 GPU？
自託管可以透過專門的平臺團隊贏得穩定、大容量的工作負載。對於許多組織來說，託管服務減少了無差異的繁重工作：修補、區域可用性、協商的 SLA 以及與身份和資料治理的整合。權衡是單位經濟效益，您必須積極管理— 尤其是當使用量隨著採用而激增時。
- 可預測的安全狀況：專用連線、加密、金鑰管理和審計跟蹤與企業策略保持一致。
- 更快實現價值：透過 API 交換或比較模型，而不是為每個實驗重建叢集。
- 彈性規模：Burst 適用於沒有長期 GPU 容量的營銷活動 — 如果您將彈性與預算和提醒結合起來。
AWS Bedrock：早期
的標準化內容 Amazon Bedrock在通用 API 表面後面公開了多個基礎模型。成本控制從賬戶結構和護欄開始，而不僅僅是型號選擇。
- 模型選擇：將任務複雜性與模型層相匹配 — 使用更小、更快的模型進行分類、路由和提取；為真正需要的任務保留最大的多模式模型。
- 按需與預配置吞吐量：按需適合尖峰或探索性流量。如果您有持續的每分鐘令牌數要求，請評估預配置吞吐量，以穩定可預測峰值的成本 — 始終與代表性視窗上測量的使用情況進行比較。
- 批次推理：對於離線評分、彙總積壓或資料集標記，批次 API 分攤工作，並且與互動式聊天路徑相比，通常會提高每個代幣的價格。
- 提示快取和快取重用：在平臺支援快取長系統提示或檢索上下文的情況下，重用可減少重複結構的計費輸入令牌。
- 區域策略：價格和資料駐留因區域而異；在合規性允許的情況下集中工作負載，避免意外的多區域蔓延。
- 可觀察性：發出每個應用程式的請求 ID，儘可能在客戶端記錄令牌計數，並與 CloudWatch 和成本分配標籤關聯以進行退款。
Azure AI Foundry：部署和支出控制
Azure AI Foundry將 Azure 上的模型部署、工具和治理結合在一起。您通常會與部署的型號（包括 Azure、OpenAI 相容端點）和周邊服務進行互動，以進行搜尋、評估和監控。
- 部署型別：瞭解基於消耗的端點和預留容量選項（例如適用的預配置吞吐量單位）之間的差異。具有窄延遲目標的穩定生產流量通常受益於預留容量；突發性的內部工具可能會繼續按使用量付費。
- 速率限制和配額：設定訂閱和工作區級別限制，以便一個租戶無法耗盡共享容量 - 與重試策略和客戶端回退配對。
- 內容安全和過濾器：儘早阻止濫用類別，以避免對不允許的提示進行浪費推理 - 將安全過濾器視為風險和成本控制。
- 與 Azure 監視器整合：跟蹤延遲、令牌使用情況和錯誤率；匯出到儀表板以供 FinOps 稽核以及成本管理匯出。
- 專用網路：使用專用端點和託管身份來減少攻擊面，同時使流量保持在可預測的路徑上以確保合規性。 Azure 上的
企業代理：定價和託管位置
對於 Microsoft 堆疊上的生產 AI 代理，從同一位置規劃支出和架構：官方Microsoft Foundry定價、代理服務以及自定義 sidecar 或 API 的可選計算。
- Microsoft Foundry 定價— 平臺和功能計費中心（包括用於基礎模型使用的Foundry 模型行）；選擇區域和貨幣，然後交叉檢查令牌和吞吐量假設。無需訂閱即可探索 Foundry 體驗；計費服務遵循其列出的計量表（請參閱常見問題解答頁面）。
- Azure AI 代理服務定價— 企業代理工作負載的編排和託管（重定向到當前代理服務定價詳細資訊頁面）。
- Microsoft Foundry 文件— 在一處構建、評估、部署和管理代理和應用程式。
- Azure 定價計算器— 在廣泛推出之前估算每月成本；登入檢視特定計劃的價格。
- Azure 容器應用程式— 用於 HTTP 的無伺服器式託管或位於 Foundry API 旁邊的佇列驅動代理服務。
- Azure Kubernetes 服務 (AKS)— 當您需要針對定製代理執行時進行叢集級控制（網路策略、GPU 節點池、多租戶名稱空間）時。
Microsoft Foundry 定價集線器和代理服務費率共同為財務和平臺團隊提供了企業代理路線圖的可靠基準。
跨雲成本控制手冊
無論供應商如何，都適用相同的 FinOps 模式。
1. 代幣預算和所有權
將成本中心分配給每個工作負載（客戶支援機器人、內部副駕駛、批次管道），並具有每月代幣或支出上限。向產品所有者展示近乎實時的使用情況；工程師最佳化產品測量的內容。
2. 路由和較小模型
插入路由器層（基於規則或輕量級分類器），將簡單查詢傳送到較小、較便宜的模型，並僅在置信度較低時升級。這種單一模式通常可以在不影響質量的情況下實現最大程度的節省。
3. 檢索而不是巨大的提示
更喜歡使用簡潔的檢索塊的RAG，而不是將整個文件填充到上下文視窗中。更少的輸入令牌可以直接降低成本，並且通常可以提高準確性。
4. 快取答案
在應用邊緣（Redis、CDN、API 閘道器）快取確定性或近確定性響應，以解決常見問題解答和重複分析問題 — 不要每次都重新推斷相同的提示。
5. 批處理和非高峰工作負載
在適用折扣或較低爭用時，在批處理或非高峰視窗中安排彙總、索引和評估作業。
6. 結構化輸出
要求 JSON 或模式約束輸出，以縮短後續輪次並減少多步驟聊天迴圈。
7. 連續評估
切換模型時定期執行基準測試 - 如果更便宜的模型與您的評估集的質量相匹配，請在路由規則中提升它。
無僵局的治理
成本控制不僅僅是技術性的。為新的高消費端點建立輕量級批准，在架構決策記錄中記錄模型選擇，並對團隊進行及時衛生培訓（冗長的成本很高）。將安全審查與成本審查保持一致，以便私有端點和日誌記錄在您擴充套件時保持不變。
Workstation 如何幫助
Workstation 幫助團隊設計多雲 AI 平臺：Bedrock 和 Azure AI Foundry 的著陸區、身份、可觀察性和安全模式，包括開發人員實際遵循的 FinOps 儀表板和治理。如需架構審查或交付支援，請聯絡info@workstation.co.uk。