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。