跳到正文
AWS Machine Learning Blog· Sitaraman Vijay Krishna·· 3 小时前AI 评分56

AWS 官方博客：用 Amazon Bedrock 与 LiteLLM 搭建自服务 LLM 网关

Building a self-service LLM gateway with Amazon Bedrock and LiteLLM

AI 导读

AWS Machine Learning Blog 发布教程，讲解如何用 Amazon Bedrock Application Inference Profiles 和运行在 AWS Fargate 上的 LiteLLM 搭建自服务 LLM 网关，将 Amazon Bedrock 抽象为 OpenAI 兼容 API。

正文 · AI 翻译

开发者希望 AI 编程助手无需繁琐配置即可使用。借助大语言模型（LLM）网关和 LiteLLM，他们可以快速访问 Amazon Bedrock 上提供的基础模型（FM），同时你能获得可观测性和用量控制。平台团队需要监控延迟和错误，财务团队需要将推理成本归因到各团队和项目，安全团队需要一致的访问控制。LLM 网关可以通过为驱动编程助手的模型提供一个集中管理的访问点，来帮助满足这些需求。

在这篇文章中，我们演示如何使用 Amazon Bedrock Application Inference Profiles 构建一个自助式 LLM 网关，并在 AWS Fargate 上运行 LiteLLM，通过 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 和一个 Application Load Balancer（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 Application Inference Profiles。Amazon CloudWatch 会采集每分钟请求数（RPM）、每分钟令牌数（TPM）指标以及配额告警。

Self-Service LLM Gateway for Amazon Bedrock production topology

图 1：LLM 网关架构（生产拓扑）

该架构由以下核心组件构成：

  1. AWS Fargate 上的 LiteLLM：LiteLLM 提供一个代理，暴露 OpenAI 兼容的 API。我们在一个 AWS Fargate 任务上运行它，并基于 CPU 利用率配置目标跟踪自动扩缩。开发者将他们的工具指向此端点，无需直接与 Amazon Bedrock 交互。
  2. 自助门户：LiteLLM 包含一个供管理员和开发者自助使用的轻量级门户。这个 Web 应用可以与你的企业单点登录（SSO）集成。通过该门户，运维工程师设定消费策略，开发者则在这些参数范围内自行配置 API 密钥。
  3. 持久化和缓存存储：LiteLLM 使用 Amazon ElastiCache for Valkey 进行非持久化响应缓存，并跨 AWS Fargate 任务协调速率限制。一个独立的 Amazon RDS（PostgreSQL）数据库作为持久状态（如 API 密钥元数据和消费跟踪）的权威数据库。
  4. Amazon Bedrock Application Inference Profiles（应用程序推理配置文件）：每个模型（例如 Claude Sonnet 和 Claude Haiku）都有自己的推理配置文件，你可以使用 AWS Cloud Development Kit (AWS CDK) 来管理它。这样，你就能获得按模型隔离的配额，并在 LiteLLM 的配置与 Amazon Bedrock 的模型版本管理之间建立一个干净的抽象层。
  5. Langfuse：开源的 LLM 可观测性工具，用于提示词级别的遥测、延迟跟踪和调试。它以应用层面的洞察补充了 Amazon CloudWatch 的基础设施级指标。

通过使用 OpenAI 兼容协议，开发者只需一个基础 URL 和一个 API 密钥即可配置他们的工具，例如 Claude Code、Continue 和 Cursor。随后，开发者可以在 Amazon Bedrock 后端之上的层面进行操作，无需改动开发者配置，就能切换模型、添加回退机制或迁移模型提供商。

前提条件

你需要一个 AWS 账户、Amazon Bedrock 模型访问权限，以及部署此项目所需的适当 IAM 权限。你还需要 LiteLLM。LiteLLM AI Gateway 组件是开源的，适用于有某些限制的小型试点。LiteLLM 文档将 AI Gateway 描述为最多可供五名用户免费使用，超过此数量则需要许可证。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 min for extended thinking
    # REQUIRED for spend tracking: when `model` is a raw inference-profile ARN,
    # LiteLLM can't find it in its built-in cost map and defaults the cost to $0
    # which means per-key `spend` stays 0 and budgets NEVER enforce. Set the
    # per-token costs explicitly.
    model_info:
      input_cost_per_token: 0.000003        # example cost
      output_cost_per_token: 0.000015    # example cost

  - 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       # example cost
      output_cost_per_token: 0.000005    # example cost

litellm_settings:
  max_budget: 250            # example per key cost
  budget_duration: 7d      # Rolling 7-day window
  max_parallel_requests: 10
  set_verbose: false
  cache: true
  cache_params:
    type: redis    # Valkey is protocol-compatible, so this stays "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

注意：不要将 master_key 或数据库凭证硬编码在 config.yaml 中。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 Application Inference Profiles，你可以为特定模型创建命名端点，从而获得配额隔离和细粒度的 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';

// Create an Application Inference Profile pointing to the Global CRIS
// system-defined inference profile (note the `global.` prefix in the ARN).
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)',
});

// Grant LiteLLM's task role access to invoke the profile.
// For Global CRIS, include the inference profile, the regional FM, and the global FM resources.
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"]  # also log failed requests

在 Fargate 任务上以环境变量的形式配置 Langfuse 公钥、私钥和部署端点。将凭据存储在 AWS Secrets Manager 中：

LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://us.cloud.langfuse.com  # or your self-hosted URL

端点必须与所选的 Langfuse Cloud 区域或自托管部署相匹配。请根据数据治理和运营要求选择托管选项。在启用提示词和响应日志记录之前，请检查该集成捕获的内容，并配置适当的脱敏、保留和访问控制。

根据集成和日志记录配置，Langfuse 跟踪可以包含提示词、响应、模型参数、token 用量和延迟。这些信息有助于调查意外的模型响应，并补充在 Amazon CloudWatch 中收集的运营指标。

实施成本控制

成本控制是成功 AI 战略的重要维度。如果没有成本控制，大量使用扩展思考功能可能导致意外的高额费用，我们在早期试点中就观察到了这一点。

在步骤 2 中配置的消费限额（max_budget: 250、budget_duration: 7d）会按 API 密钥强制执行一个滚动 7 天窗口，前提是已设置各模型的 model_info 费用（参见步骤 2 说明）。当用户达到限额时，LiteLLM 会返回 HTTP 429 代码，并附上清晰的消息说明其预算已超支。不会出现静默降级或意外账单。开发者和工程团队可以通过以下任一方式查看当前消费和重置时间：

  • 每日消费：查询 GET /user/daily/activity，并传入 start_date 和 end_date 范围，即可获取按天的指标：消费、提示词 token、补全 token 和 API 请求数，并按模型、提供商和 API 密钥细分。
  • 按用户消费：查询 GET /user/info?user_id=…，可获取某用户总消费及其关联的每个 API 密钥消费的摘要。
  • 门户仪表板：管理界面（Admin UI）（位于 https://<proxy-host>/ui）包含一个 Usage 标签页，开发者和管理员可以在其中按模型、用户和标签浏览消费情况，无需直接调用 API。

这些端点正是财务团队实现按用户归因的方式，无需你自己构建自定义计量基础设施。一个定时任务调用 /user/daily/activity 或 /global/spend/report 就足以支撑成本仪表板或费用分摊报告。

开发者自助服务门户

自助服务门户还负责密钥生命周期流程。开发者使用贵公司的 SSO 进行身份验证，生成与其身份绑定的密钥；如果密钥泄露或为符合轮换策略，他们之后可以重新生成。平台工程师只需配置一次预算策略，开发者即可在其约束内自主操作。开发者直接使用该门户的两个场景：

  • 密钥生成：在管理界面（Admin UI）的 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）和每分钟 token 数（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),
  }),
  // Alert at ~60% of your account's TPM quota (check Service Quotas for your
  // actual limit, defaults vary by model and account).
  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 命名空间，因此告警需要一个数据来源。一个小的自定义 logger 回调，在每个请求上调用 CloudWatch PutMetricData，即可完成这项工作。通过 litellm_settings.success_callback 注册它（这是增量式的），而不要用 callbacks。callbacks 列表会替换 LiteLLM 的内部 logger 列表，其中包括内置的消费跟踪 logger，并会静默禁用预算强制执行。

下面是该回调的一个最小化版本，使用 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",
            }],
        )

# Register alongside success_callback, not in place of it:
import litellm
litellm.callbacks = [TPMEmitter()]

对于提示词级别的调试，我们将 Langfuse 与 CloudWatch 一起运行。当开发者报告“模型给出了糟糕的响应”时，你可以使用 Langfuse 检查确切的提示词、token 计数和模型参数。对于合规敏感的环境，Amazon Bedrock 原生向 Amazon Simple Storage Service (Amazon S3) 的调用日志提供了不可篡改的审计跟踪。

大规模实践中的经验教训

我们在一个全新的 AWS 账户上端到端地部署了这一模式，以确认示例代码片段可以正常工作。在我们自己的部署中，我们将这个 LLM 网关扩展到数百名开发者，并总结出一些经验。

运维层面的经验

大规模运行的主要发现：

  • 扩展思考彻底改变了延迟表现。使用 Claude 扩展思考功能的请求可能需要几分钟甚至更长时间，具体取决于思考预算。如果你的负载均衡器的空闲超时为 60 秒，这些请求将静默失败。为解决这个问题，你可以将负载均衡器的空闲超时设置为至少 900 秒，并相应地配置 LiteLLM 的请求超时（即本文前面 Step 2 配置中的 timeout: 900）。
  • 被限流时，先在同一模型上退避并重试，再触发回退。我们的最初直觉是被限流时从 Sonnet 回退到 Haiku。但这对编程助手来说并非最优，因为更换模型会破坏开发者所依赖的一致性表现。正确做法是在代理层面使用指数退避在同一模型上重试（即 Step 2 中的 max_retries: 3）。当请求在重试后仍无法得到服务时，应清晰地呈现错误，而不是返回另一个模型的补全结果。
  • 将自动化工具的调用与开发者流量分开。持续集成与持续交付 (CI/CD) 流水线和自动化代码审查工具应使用各自的推理配置文件和配额直接调用 Amazon Bedrock。将自动化流量与交互式开发者流量混在一起会导致不可预测的延迟，并妨碍有意义的成本归因。
  • 如果可行，从第一天起就使用 Global CRIS。我们最初使用的是 Geographic (US) CRIS，但在达到区域配额上限后最终迁移了推理配置文件。对于我们的使用场景，我们没有数据驻留限制，因此可以使用 Global CRIS。Global CRIS 跨区域路由请求，从而利用更广泛的容量池，简化大规模管理。

部署注意事项

有两种常见的配置错误，在支出或连通性出现问题之前很难察觉：

要强制执行预算，配置每个模型的成本是必须的。如果你想实现按用户的成本控制，每个模型上的 model_info 块不是可选项。当 model 指向 Amazon Bedrock 推理配置文件 ARN 时，LiteLLM 无法在其内置定价表中查找该 ARN。它会按每个 token $0 来记录，因此 max_budget 和 429 的限流强制执行会静默失效。无论流入多少 token，支出始终为 $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 需要 foundation-model 资源，而不仅仅是应用推理配置文件的 ARN。否则，调用将在运行时被拒绝。
  • 为 Fargate 任务分配足够的内存。LiteLLM 的网关镜像在 512 MB 内存下会耗尽内存并被终止（退出码 137），无法通过健康检查。大约 2 GB 是一个安全的下限。
  • 覆盖容器的 entryPoint。官方镜像的 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 和 Application Load Balancer，以及配套的 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）服务以停止并清空任务，然后删除集群。
  • Application Load Balancer：删除 ALB 及其监听器和目标组。
  • Amazon RDS（PostgreSQL）：删除数据库实例。仅在需要保留 API 密钥和支出数据时，先拍摄最终快照。
  • Amazon ElastiCache for Valkey：删除复制组或集群。它只保存缓存数据，因此无需快照。
  • Amazon Bedrock 应用程序推理配置文件：删除在步骤 3 中创建的配置文件，方法是移除 AWS CDK 构造或运行 aws bedrock delete-inference-profile。
  • 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 模式，故未在文中展示。

当你准备好获取完整、可部署的实现时，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 推理配置文件、LiteLLM 网关、AWS Fargate 和 Langfuse。

在你的组织中尝试这一模式。先从一个试点团队开始，验证成本控制措施，然后再逐步扩展。

关于作者

来源： AWS Machine Learning Blog · aws.amazon.com

#教程/实践#RAG#部署/工程#Anthropic