Article · AI translation
开发者希望使用只需少量配置的 AI 编码助手。借助大语言模型（LLM）网关和 LiteLLM，他们可以快速访问 Amazon Bedrock 上提供的基础模型（FM），而您则可以掌握使用情况并加以控制。平台团队需要监控延迟和错误，财务团队需要将推理成本归属到团队和项目，安全团队则需要一致的访问控制。LLM 网关通过提供一个集中管理的访问点来连接驱动编码助手的模型，可以帮助满足这些需求。本文介绍如何使用 Amazon Bedrock 应用程序推理配置文件，以及在 AWS Fargate 上运行的 LiteLLM，构建一个自助式 LLM 网关，通过兼容 OpenAI 的 API 封装 Amazon Bedrock。采用这种模式，开发者可以通过单一 API 和专用密钥访问基础模型，而您可以获得按用户划分的成本控制能力和模型性能可观测性。读完本文，您将充分了解这一模式，能够依据示例代码片段和 AWS Cloud Development Kit（AWS CDK）构造自行构建一个版本。本文以 Claude Sonnet 和 Claude Haiku 模型为例。有关按 AWS 区域划分的模型及其可用性列表，请参阅 Amazon Bedrock 中的“按 AWS 区域划分的受支持模型”。这种 LLM 网关模式遵循一个直接的请求流程：请求从开发者发出，经过 LiteLLM 层，再到 Amazon Bedrock 和底层基础模型。下图展示了这一流程背后的生产环境拓扑。为简化说明，我们没有介绍如何添加 Amazon Bedrock Guardrails，例如内容过滤和依据来源进行事实核查；但在部署到生产环境之前，通常应加入适当的负责任 AI 控制措施。开发者使用的兼容 OpenAI 的客户端通过 Amazon Route 53、Amazon CloudFront 和应用程序负载均衡器（ALB）访问 LLM 网关。客户端使用按用户分配的 API 密钥向 Fargate 上的 LiteLLM 进行身份验证。在后端，请求会使用 Amazon Relational Database Service（Amazon RDS，PostgreSQL）中存储的虚拟密钥及支出状态信息。它还会与作为缓存的 Amazon ElastiCache for Valkey 以及用于管理密钥的 AWS Secrets Manager 交互。最终，LiteLLM 使用限定了权限范围的 AWS Identity and Access Management（IAM）任务角色调用 Amazon Bedrock 应用程序推理配置文件。Amazon CloudWatch 采集每分钟请求数（RPM）和每分钟令牌数（TPM）指标，并监控配额告警。图 1：LLM 网关架构（生产环境拓扑）该架构包含以下核心组件：AWS Fargate 上的 LiteLLM：LiteLLM 提供一个代理，公开兼容 OpenAI 的 API。我们将其运行在 AWS Fargate 任务上，并根据 CPU 利用率进行目标跟踪自动扩缩容。开发者将工具指向这一端点，无需直接与 Amazon Bedrock 交互。自助服务门户：LiteLLM 包含一个轻量级门户，供管理员和开发者自助使用。这个 Web 应用程序可以与企业单点登录（SSO）集成。运维工程师通过该门户设置支出策略，开发者则在这些参数范围内自行创建 API 密钥。持久化存储和缓存存储：LiteLLM 使用 Amazon ElastiCache for Valkey 进行非持久化响应缓存。它还协调跨 AWS Fargate 任务的速率限制。单独的 Amazon RDS（PostgreSQL）数据库是 API 密钥元数据和支出跟踪等持久化状态的权威数据源。Amazon Bedrock 应用程序推理配置文件：每个模型（例如 Claude Sonnet 和 Claude Haiku）都有各自的推理配置文件，您可以使用 AWS Cloud Development Kit（AWS CDK）进行管理。这样，您便可以按模型隔离配额，并在 LiteLLM 配置与 Amazon Bedrock 的模型版本管理之间建立清晰的抽象层。Langfuse：用于提示词级遥测、延迟跟踪和调试的开源 LLM 可观测性工具。它通过提供应用程序层面的洞察，对 Amazon CloudWatch 的基础设施层面指标形成补充。 通过使用兼容 OpenAI 的协议，开发者可以用一个基础 URL 和 API 密钥配置 Claude Code、Continue 和 Cursor 等工具。随后，开发者可以在 Amazon Bedrock 后端之上的一层进行操作，无需改动开发者的配置，就能切换模型、添加备用模型或迁移模型提供商。前提条件：部署此项目需要 AWS 账户、Amazon Bedrock 模型访问权限以及适当的 IAM 权限。还需要 LiteLLM。LiteLLM AI Gateway 组件是开源的，虽然存在一些限制，但适合小规模试点。根据 LiteLLM 文档，AI Gateway 可供最多 5 名用户免费使用，超过这一人数则需要许可证。LiteLLM Enterprise 是一个可扩展、面向生产环境的许可版本，包含开源网关，以及单点登录、审计日志、委派管理员角色和支持服务。免费版虽然支持虚拟密钥，但本文所述的自助签发密钥功能需要 Enterprise 版本。端到端配置：从左到右。我们将逐层介绍从开发者计算机到基础模型的配置。步骤 1：开发者 IDE 配置（例如 Claude Code）。开发者将编程助手配置为指向 LLM 网关。这是开发者需要对工具进行的唯一配置：{ "apiProvider": "openai-compatible", "apiBaseUrl": "https://llm-gateway.internal.example.com/v1", "apiKey": "sk-user-abc123", "model": "claude-sonnet-4-20250514" } 完成配置后，每位开发者都可以从自助服务门户获取自己的 API 密钥，并将其填入工具配置。步骤 2：LiteLLM 网关配置。按照 LiteLLM 文档将 LiteLLM 部署到容器服务。在此示例中，我们使用 AWS Fargate。部署还包括门户，本地测试时可通过 http://localhost:4000/ui 打开。LiteLLM 网关用于将模型名称映射到 Amazon Bedrock 推理配置文件 ARN，并实施该映射，同时执行每个密钥的支出限额：model_list: - model_name: claude-sonnet-4-20250514 litellm_params: model: bedrock/arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/sonnet-profile-id aws_region_name: us-east-1 max_retries: 3 timeout: 900 # 扩展思考的超时时间为 15 分钟 # 支出跟踪必需：当 `model` 是原始推理配置文件 ARN 时，# LiteLLM 无法在其内置成本表中找到它，并默认将成本设为 $0，# 这意味着每个密钥的 `spend` 保持为 0，预算永远不会生效。请明确设置 # 每个 token 的成本。model_info: input_cost_per_token: 0.000003 # 示例成本 output_cost_per_token: 0.000015 # 示例成本 - model_name: claude-haiku-4-5 litellm_params: model: bedrock/arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/haiku-profile-id aws_region_name: us-east-1 timeout: 120 model_info: input_cost_per_token: 0.000001 # 示例成本 output_cost_per_token: 0.000005 # 示例成本 litellm_settings: max_budget: 250 # 每个密钥的示例成本预算 budget_duration: 7d # 滚动 7 天窗口 max_parallel_requests: 10 set_verbose: false cache: true cache_params: type: redis # Valkey 与该协议兼容，因此这里仍为 "redis" host: elasticache-endpoint port: 6379 master_key: os.environ/LITELLM_MASTER_KEY database_url: os.environ/DATABASE_URL 在 Fargate 任务中通过 AWS Secrets Manager 设置：LITELLM_MASTER_KEY=sk-platform-admin-... DATABASE_URL=postgresql://user:password@rds-endpoint:5432/litellm 注意：不要在 config.yaml 中硬编码 master_key 或数据库凭据。LiteLLM 会在加载时解析 os.environ/VAR_NAME 引用，因此应将 LITELLM_MASTER_KEY 和 DATABASE_URL 设置为 Fargate 任务中的环境变量，并从 AWS Secrets Manager 获取其值。在步骤 5 中，以相同方式设置 Langfuse 凭据。例如，当开发者调用 claude-sonnet-4-20250514 时，LiteLLM 会将其解析为推理配置文件 ARN。然后，它使用 AWS Fargate 任务的 IAM 角色向 Amazon Bedrock 进行身份验证，并以 OpenAI 格式流式返回响应。 步骤 3：Bedrock 推理配置文件（CDK）借助 Amazon Bedrock 应用程序推理配置文件，你可以为特定模型创建具名端点，从而实现配额隔离和细粒度 IAM 控制。选择跨区域推理（CRIS）：地理范围或全球范围 Amazon Bedrock CRIS 免去了自行实现跨区域请求路由的工作。其他优势包括：可使用更广泛的区域容量池；自动将请求路由到有可用容量的受支持区域；可选择更多模型，因为有些模型只能通过推理配置文件使用。对于这种代理模式，如果所选模型支持全球跨区域推理，且组织政策允许在全球受支持的 AWS 商业区域处理推理请求，我们建议使用全球跨区域推理。地理范围跨区域推理将处理限定在指定地理范围内。例如，美国推理配置文件只会将请求路由到受支持的美国区域。全球跨区域推理可使用更广泛的区域容量池，与地理范围跨区域推理相比，还可能带来价格优势。你可以通过最新的 AWS 文档和 AWS 定价页面核实模型可用性、适用的服务配额以及具体模型的价格。CDK 构造代码 import * as cdk from 'aws-cdk-lib'; import * as bedrock from 'aws-cdk-lib/aws-bedrock'; import * as iam from 'aws-cdk-lib/aws-iam'; // 创建指向全球 CRIS 系统定义推理配置文件的应用程序推理配置文件（注意 ARN 中的 `global.` 前缀）。 const sonnetProfile = new bedrock.CfnApplicationInferenceProfile(this, 'SonnetProfile', { inferenceProfileName: 'claude-sonnet-gateway', modelSource: { copyFrom: `arn:aws:bedrock:us-east-1:${this.account}:inference-profile/global.anthropic.claude-sonnet-4-20250514-v1:0`, }, description: 'Claude Sonnet for developer coding assistants (Global CRIS)', }); // 授予 LiteLLM 的任务角色调用该配置文件的权限。 // 对于全球 CRIS，纳入推理配置文件、区域基础模型和全球基础模型资源。 litellmTaskRole.addToPolicy(new iam.PolicyStatement({ effect: iam.Effect.ALLOW, actions: ['bedrock:InvokeModel', 'bedrock:InvokeModelWithResponseStream'], resources: [ sonnetProfile.attrInferenceProfileArn, 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-20250514-v1:0', 'arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-20250514-v1:0', ], })); 重要：对于全球 CRIS，copyFrom ARN 必须指向带有 global. 前缀的系统定义推理配置文件，而不能直接指向基础模型 ARN。使用基础模型 ARN 会创建不具备跨区域路由功能的单区域配置文件。此外，IAM 策略必须包含调用实际涉及的资源 ARN：应用程序推理配置文件，以及请求可能被路由到的任何区域中的底层基础模型（区域使用通配符）。如果权限仅限定于应用程序推理配置文件 ARN，调用时会返回 not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1::foundation-model/...。这种权限设置遵循最小权限原则：它指定了所用的确切模型，而不是 bedrock:* 或 *。步骤 4：Bedrock 调用基础模型 推理配置文件会透明地处理模型解析和跨区域路由，无需额外配置。当 LiteLLM 调用推理配置文件 ARN 时，Amazon Bedrock 会将请求路由到已配置 AWS 区域中的可用容量，并返回响应。步骤 5：Langfuse 可观测性 LiteLLM 通过日志回调与 Langfuse 集成，无需更改开发者工具的配置，即可查看模型调用情况。 要启用集成，请将以下条目合并到步骤 2 配置中现有的 litellm_settings 块，并保留现有的回调条目：litellm_settings: success_callback: ["langfuse"] failure_callback: ["langfuse"] # 同时记录失败的请求。在 Fargate 任务中，将 Langfuse 公钥、密钥和部署端点配置为环境变量。将凭据存储在 AWS Secrets Manager 中：LANGFUSE_PUBLIC_KEY=pk-lf-... LANGFUSE_SECRET_KEY=sk-lf-... LANGFUSE_HOST=https://us.cloud.langfuse.com # 或你的自托管 URL。端点必须与所选的 Langfuse Cloud 区域或自托管部署相匹配。根据数据治理和运营要求选择托管方案。在启用提示词和响应日志记录前，请审查该集成捕获的内容，并配置适当的脱敏、保留期限和访问控制。根据集成和日志配置，Langfuse 跟踪记录可能包含提示词、响应、模型参数、令牌用量和延迟。这些信息有助于调查意外的模型响应，并补充 Amazon CloudWatch 收集的运营指标。实施成本控制。成本控制是成功实施 AI 战略的重要一环。缺乏成本控制时，大量使用扩展思考功能可能导致费用意外高涨；我们在早期试点中就遇到过这种情况。步骤 2 中配置的支出限额（max_budget: 250、budget_duration: 7d）对每个 API 密钥强制执行滚动的 7 天窗口，前提是已设置各模型的 model_info 成本（参见步骤 2 的注释）。当用户达到限额时，LiteLLM 会返回 HTTP 429 状态码，并附上明确说明其预算已超出的消息。不会悄然降低服务质量，也不会产生意外账单。开发人员和工程团队可以通过以下任一方式查看当前支出和重置时间：每日支出：使用 start_date 和 end_date 范围查询 GET /user/daily/activity，获取按天统计的支出、提示词令牌数、补全令牌数和 API 请求数，并按模型、提供商和 API 密钥细分。每用户支出：查询 GET /user/info?user_id=…，获取用户总支出及其关联的每个 API 密钥的支出汇总。门户仪表板：管理界面（https://<proxy-host>/ui）包含一个 Usage 选项卡，开发人员和管理员无需直接调用 API，就可以按模型、用户和标签查看支出。财务团队也可以使用这些端点获取每用户的费用归属，无需自行构建计量基础设施。定时调用 /user/daily/activity 或 /global/spend/report 的作业，就足以为成本仪表板或费用分摊报告提供数据。开发人员自助服务门户。自助服务门户还负责密钥生命周期管理流程。开发人员通过企业 SSO 身份验证，生成与其身份绑定的密钥；如果密钥泄露，或需要遵循轮换策略，之后可以重新生成。平台工程师只需配置一次预算策略，开发人员便可在约束范围内自主开展工作。开发人员直接通过门户完成两件事：生成密钥：在管理界面的 Virtual Keys 页面（https://<proxy-host>/ui），通过 SSO 身份验证的开发人员选择 Generate Key，创建与自己身份绑定的密钥。查看速率限制：每个 /chat/completions 响应都包含 x-litellm-key-remaining-requests-{model} 和 x-litellm-key-remaining-tokens-{model} 标头，因此开发人员可以直接在其工具的响应中看到该模型剩余的 RPM 和 TPM 配额。这与本文前面提到的按金额计算的支出跟踪不同。监控与可观测性。对于 LLM 网关，延迟百分位数等传统指标可能具有误导性，尤其是使用扩展思考模型时，单个请求可能需要数分钟。因此，我们主要关注每分钟请求数（RPM）和每分钟令牌数（TPM）。 在这里，Amazon CloudWatch 可以通过以下配置帮助您监控这些信号并设置告警。用于配额管理的 Amazon CloudWatch 告警 new cloudwatch.Alarm(this, 'BedrockTPMAlarm', { metric: new cloudwatch.Metric({ namespace: 'LiteLLM/Gateway', metricName: 'TokensPerMinute', statistic: 'Sum', period: cdk.Duration.minutes(1), }), // 在账户 TPM 配额约 60% 时告警（请在 Service Quotas 中核查您的 // 实际限额；默认值因模型和账户而异）。 threshold: 600000, evaluationPeriods: 3, comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD, alarmDescription: 'TPM approaching Bedrock quota - request increase proactively', }); 请注意，这项告警配置会在配额使用率达到 60–70% 时发出警报，而不是等到请求受到限流。这样就能在用户体验下降之前，留出提高 Amazon Bedrock 配额的时间。发送指标：LiteLLM 没有内置回调将名为 TokensPerMinute 的指标发布到 LiteLLM/Gateway 命名空间，因此该告警需要一个指标来源。一个在每次请求时调用 CloudWatch PutMetricData 的小型自定义日志记录器回调即可完成这项工作。应通过 litellm_settings.success_callback 注册它（这种方式会追加回调），而不是通过 callbacks 注册。callbacks 列表会替换 LiteLLM 的内部日志记录器列表，其中包括内置的支出跟踪日志记录器，并会在没有提示的情况下禁用预算执行。下面是使用 LiteLLM 的 CustomLogger 类实现的该回调的精简版本： import boto3 from litellm.integrations.custom_logger import CustomLogger cloudwatch = boto3.client("cloudwatch") class TPMEmitter(CustomLogger): async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): total_tokens = kwargs.get("standard_logging_object", {}).get("total_tokens", 0) cloudwatch.put_metric_data( Namespace="LiteLLM/Gateway", MetricData=[{ "MetricName": "TokensPerMinute", "Value": total_tokens, "Unit": "Count", }], ) # 与 success_callback 一同注册，而不是取代它： import litellm litellm.callbacks = [TPMEmitter()] 为了调试提示词层面的问题，我们将 Langfuse 与 CloudWatch 一起运行。当开发者报告“模型给出了糟糕的回答”时，您可以使用 Langfuse 查看确切的提示词、令牌数量和模型参数。对于合规要求较高的环境，Amazon Bedrock 原生的调用日志记录功能可将日志写入 Amazon Simple Storage Service (Amazon S3)，提供不可篡改的审计记录。规模化运行的经验教训 我们在一个新的 AWS 账户中端到端部署了这一模式，以确认示例代码片段能够正常工作。在我们自己的部署中，我们将这个 LLM 网关扩展到供数百名开发者使用，并总结了几项经验教训。运维经验 大规模运行的主要发现：扩展思考会显著改变延迟情况。使用 Claude 扩展思考功能的请求可能需要几分钟甚至更长时间，具体取决于思考预算。如果负载均衡器的空闲超时时间为 60 秒，这些请求将悄然失败。为解决这一问题，您可以将负载均衡器的空闲超时时间设为至少 900 秒，并相应配置 LiteLLM 的请求超时时间（本文前面第 2 步配置中的 timeout: 900）。受到限流时，应先退避并重试同一模型，再考虑启用后备方案。我们最初的直觉是在受到限流时从 Sonnet 切换到 Haiku。但对于编程助手而言，这并非最佳做法，因为更换模型会破坏开发者所依赖的行为一致性。相反，应在代理层使用指数退避重试同一模型（第 2 步中的 max_retries: 3）。如果重试后仍无法处理请求，应明确显示错误，而不是返回另一个模型的补全结果。将自动化工具调用与开发者流量分开。持续集成和持续交付 (CI/CD) 流水线以及自动化代码审查工具应使用各自的推理配置文件和配额直接调用 Amazon Bedrock。 将自动化流量与开发者的交互式流量混在一起，会导致延迟难以预测，也妨碍有意义的成本归属分析。如果可行，从一开始就使用 Global CRIS。我们最初使用 Geographic (US) CRIS，但在达到 Regional 配额上限后，最终迁移了推理配置文件。我们的用例没有数据驻留限制，因此可以使用 Global CRIS。Global CRIS 将请求路由至多个区域，以利用更广泛的容量资源池，简化大规模管理。部署注意事项：有两种配置错误很常见，而且在支出或连接出现问题之前很难察觉：要执行预算限制，必须配置每个模型的成本。如果要跟踪每位用户的成本控制，每个模型上的 model_info 块不可省略。当 model 指向 Amazon Bedrock 推理配置文件 ARN 时，LiteLLM 无法在其内置定价表中查到该 ARN。它会改为记录每个令牌的成本为 $0，因此 max_budget 和 429 限流机制会悄然失效。无论处理多少令牌，支出始终显示为 $0。可通过设置 input_cost_per_token 和 output_cost_per_token（或 input_cost_per_million_tokens）解决此问题。数据库与缓存：database_url 必须指向 PostgreSQL。LiteLLM 的虚拟密钥（/key/generate）、store_model_in_db 和支出跟踪都由 Postgres 支撑。我们还在检查清单中加入了几个较小的部署细节：Global CRIS 的 IAM 权限需要涵盖基础模型资源，不能只有 app-inference-profile ARN。否则，调用会在运行时被拒绝。为 Fargate 任务分配足够的内存。LiteLLM 的网关镜像在内存为 512 MB 时会耗尽内存，并在通过运行状况检查之前被终止（退出代码 137）。约 2 GB 是比较稳妥的下限。覆盖容器的 entryPoint。官方镜像的入口点是 litellm。如果在启动时使用 shell 脚本生成配置，请设置 entryPoint: ['/bin/sh','-c']，否则脚本会作为参数传给 litellm。IAM 角色和安全组的描述必须使用 ASCII 字符。IAM 和 Amazon EC2 会拒绝长破折号和 -> 箭头。确认模型在您的账户和区域中可用。模型 ID 和 CRIS 配置文件会变化。使用 aws bedrock list-inference-profiles 进行核实（例如，我们使用了 claude-haiku-4-5，因为 claude-haiku-3-5 不可用）。清理：本文使用示例代码片段介绍这一模式，而非提供单个可部署的堆栈，因此没有一条命令即可完成的清理方法。但该架构依赖多种资源，这些资源在运行期间会持续产生费用。其中包括 AWS Fargate 服务、Amazon RDS（PostgreSQL）、Amazon ElastiCache for Valkey 和应用程序负载均衡器，以及配套的 Secrets Manager 密钥、CloudWatch 告警和 Amazon Bedrock 应用程序推理配置文件。测试完成后，请删除这些资源，以免持续产生费用。如果您使用 Guidance for Multi-Provider Generative AI Gateway on AWS 部署了完整解决方案，请按照该解决方案的清理说明删除其创建的所有资源。对于 AWS CDK，运行 cdk destroy。对于 AWS CloudFormation，删除堆栈。如果您根据本文的代码片段自行构建了这一模式，请逐一删除以下资源：AWS Fargate 服务和集群：删除 Amazon Elastic Container Service（Amazon ECS）服务，以停止任务并等待任务退出，然后删除集群。应用程序负载均衡器：删除 ALB 及其侦听器和目标组。Amazon RDS（PostgreSQL）：删除数据库实例。只有在需要保留 API 密钥和支出数据时，才先创建最终快照。Amazon ElastiCache for Valkey：删除复制组或集群。它只存储缓存数据，因此无需创建快照。Amazon Bedrock 应用程序推理配置文件：通过移除 AWS CDK 构造或运行 aws bedrock delete-inference-profile，删除步骤 3 中创建的配置文件。AWS Secrets Manager 密钥：安排删除代理使用的密钥，例如主密钥和数据库凭证。 Amazon CloudWatch 警报和日志组：删除 TPM 警报及所有 LiteLLM 日志组。先删除 AWS Fargate 服务和 ALB，再删除它们所依赖的 Amazon RDS 和 ElastiCache 端点，以免在拆除过程中，正在运行的任务因后端已被移除而报错。结语 在本文中，我们详细介绍了一种 LLM 网关模式，它对 Amazon Bedrock 的多模型架构进行抽象，为您的团队提供可扩展、可观测的自助访问方式。由于 Amazon Bedrock 通过单一接口在不同模型之间路由，无需更改基础设施，您的开发人员便可通过熟悉的 API 即时访问基础模型。工程和安全团队可以获得成本治理、可观测性和统一控制平面；财务团队则无需您构建自定义计量基础设施，就能按用户归属成本。首先，按照本文介绍的模式和代码片段操作，了解各部分如何协同工作。AWS CDK 代码片段涵盖 Amazon Bedrock 应用推理配置文件、其 IAM 策略以及 CloudWatch 警报。周边的 AWS Fargate 服务、Amazon RDS、Amazon ElastiCache、ALB 和 AWS Secrets Manager 资源遵循标准 AWS CDK 模式，本文未予展示。准备好采用完整、可部署的实现时，AWS 上的多提供商生成式 AI 网关指南（Guidance for Multi-Provider Generative AI Gateway on AWS）与此模式高度契合。您可以在 AWS Solutions Library 中找到该指南，以及配套的博客文章和 GitHub 项目。虽然本文逐步讲解了相同的核心模式，但重点是将 Amazon Bedrock 用于开发人员编码助手。更大的解决方案架构增加了多提供商支持、Amazon ECS 或 Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon CloudFront 和 AWS WAF 选项，以及管理界面。您可以结合 Amazon Bedrock Inference Profiles、LiteLLM 网关、AWS Fargate 和 Langfuse 的其他文档，了解此架构的各个组件。在您的组织中尝试这一模式。从一个试点团队开始，验证成本控制措施，然后逐步扩大规模。关于作者 Sitaraman Vijay Krishna Sitaraman Vijay Krishna 是 AWS 的高级技术客户经理，负责与客户合作开展生成式 AI、智能体 AI 和 AI 可观测性方面的工作，包括亲自推动 AWS DevOps Agent 的采用。工作之余，他是一位终身体育迷，既喜欢上场运动，也喜欢坐在看台上观赛。Saurav Bhattacharya Saurav Bhattacharya 是 Amazon Web Services（AWS）的高级解决方案架构师，在电信、宽带和媒体领域拥有丰富经验。在目前的岗位上，他专注于解决媒体和娱乐行业面临的挑战、加快技术销售，并构建可扩展的解决方案，以加速客户的数字化转型。Eric Christensen Eric Christensen 是 Amazon Web Services（AWS）的技术客户经理，在云财务管理和成本优化方面拥有深厚经验。他已在 AWS Solutions Library 发布大量代码示例，以及多个成本与运行状况跟踪仪表板。