详细内容或原文请订阅后点击阅览
在 Amazon ECS 和 Amazon Bedrock 上使用 LiteLLM 设置 OpenAI ChatGPT Codex
使用 AWS Fargate 在 Amazon ECS 上部署客户操作的 LiteLLM 网关，将其连接到 Amazon Bedrock 上的 OpenAI 模型，并配置 Codex 通过网关的响应 API 使用范围内的身份、预算、速率限制和遥测来路由请求。我们还比较了直接 IAM Identity Center 访问和托管 Portkey 部署。
来源:亚马逊云科技 _机器学习OpenAI ChatGPT Codex 与 LiteLLM 可以为生成式 AI 编码代理提供集中式企业控制。这些代理帮助开发人员了解存储库、编写代码、运行测试以及完成多步骤工程任务。随着组织从个人实验转向托管采用，团队需要一种一致的方法来控制模型访问和属性消耗。他们还必须应用预算和速率限制，并观察模型访问路径。
OpenAI Codex (Codex) 在开发人员工作站上运行其任务循环。它读取本地文件并在其本地沙箱和批准设置下运行批准的工具。客户仍然可以通过客户 AWS 账户中的基础设施路由模型推理。
在本文中，我们将引导您在 Amazon Elastic Container Service (Amazon ECS) 上部署客户操作的 LiteLLM 网关。我们展示了如何将其连接到 Amazon Bedrock 上的 OpenAI 模型，并配置 Codex 以使用网关的响应 API。我们还展示了如何验证语义延续、流式传输和函数调用。最后，我们解释了直接 AWS IAM Identity Center 访问或 Portkey 等托管网关何时更适合。
完整的实现可以在guidance-codex 存储库中找到。对于本文中的主要路径，请遵循 AWS 上的 LiteLLM 快速入门。
解决方案概述
以下架构将 LiteLLM 置于 Codex 和 Amazon Bedrock 之间。 LiteLLM 成为模型身份验证、路由、预算、速率限制和网关遥测的共享控制点。 Codex 保留对本地任务和工具执行循环的责任。
下图显示了从开发人员工作站通过网关到 Amazon Bedrock 并返回的端到端请求流。寻找通过基础设施跟踪单个模型的五个编号步骤。
图 1：Codex 通过 LiteLLM 发送模型请求，而本地工具执行保留在开发人员工作站上
请求流程分五个步骤进行：
参考部署还使用：
这种分离很重要。网关不会在 AWS 账户中收到通用 shell，并且不会取代 Codex 的本地批准。它控制着每个模型的转弯。
为什么针对此模式使用 LiteLLM
当您需要执行以下操作时，LiteLLM 是一个有用的客户操作选项：
仅允许批准的模型别名。
发出用户或团队范围的网关密钥。
运营责任是主要的权衡。您的团队拥有网关可用性、数据库生命周期、版本升级、事件响应和容量规划。
在 Amazon ECS 上为 Codex 部署 LiteLLM 网关
本部分将引导您部署 LiteLLM 网关、将其连接到 Amazon Bedrock 以及配置 Codex 以通过网关发送请求。
先决条件
对于本演练，您需要：
本演练已在美国东部（弗吉尼亚北部）区域 (us-east-1) 进行验证，网关别名为 openai.gpt-5.5，该网关别名映射到 LiteLLM 配置中的 bedrock_mantle/openai.gpt-5.5。型号可用性因账户和区域而异。
成本说明：此解决方案创建可计费资源，包括 Application Load Balancer、Fargate 任务、Amazon RDS、AWS WAF、日志和模型推理。示例 VPC 还可能产生网络费用。查看您所在区域的当前定价，并按照演练后的清理部分进行操作。
在 Amazon ECS 上部署 LiteLLM
克隆存储库并创建本地部署环境文件：
git 克隆 https://github.com/openai-on-aws/guidance-codex.git
CD指南-法典
git checkout feat/企业网关准备情况
cp 部署/litellm/.env.deploy.example \部署/litellm/.env.deployGit 会忽略 real.env.deploy 文件。设置预期的 AWS 配置文件、区域、源 CIDR 以及 DNS 或证书值。以下摘录显示了面向生产的设置：AWS_PROFILE=您的个人资料AWS_REGION=us-east-1BEDROCK_REGION=us-east-1ENABLE_TLS=trueGATEWAY_DOMAIN_NAME=codex-gateway.example.comROUTE53_HOSTED_ZONE_ID=Z0123456789示例ALB_CERTIFICATE_ARN=ALLOWED_CIDR=203.0.113.10/32ENABLE_WAF=trueDB_MULTI_AZ=trueDESIRED_COUNT=2MIN_TASK_COUNT=2MAX_TASK_COUNT=10通过设置 ALB_CERTIFICATE_ARN 而不是 ROUTE53_HOSTED_ZONE_ID 来使用现有证书。对于客户登陆区域，还需要提供现有的 VPC 以及单独的公共、私有应用程序和私有数据库子网，如生产部署指南中所述。
运行只读预检：
进行 litellm 检查
# Make 使用的直接帮助器调用：
# 部署/scripts/litellm-stack.sh 检查
当 cfn-lint 可用时，预检会验证 AWS CLI v2、AWS 身份、Docker、不可变映像引用、区域一致性、CIDR 限制、TLS 输入、本地文档链接和 AWS CloudFormation 语法。
构建经过审核的 LiteLLM 映像并将其推送到 Amazon ECR：
CONFIRM_AWS_WRITE=1 make litellm-build
# Make 使用的直接帮助器调用：
# CONFIRM_AWS_WRITE=1 部署/scripts/litellm-stack.sh 构建
构建使用摘要固定的 LiteLLM 基础映像，并将生成的 ECR 摘要记录在本地忽略状态文件中。 CloudFormation 接收不可变摘要，而不是可变图像标签。在内部，帮助程序创建或重用不可变的 Amazon ECR 存储库、登录 Amazon ECR、运行 docker buildx build --push 并解析推送的映像摘要。
创建未执行的 CloudFormation 更改集：
制定 litellm 计划
# Make 使用的直接帮助器调用：
# 部署/脚本/litellm-stack.sh 计划
这将为网络或网关模板调用 aws cloudformation deploy --no-execute-changeset。它创建可审查的变更集但不执行它。
查看更改集，然后部署：
CONFIRM_AWS_WRITE=1 进行 litellm-deploy
使诉讼状态
# Make 使用的直接帮助器调用：
# CONFIRM_AWS_WRITE=1 部署/scripts/litellm-stack.sh 部署
# 部署/脚本/litellm-stack.sh 状态
部署帮助程序为网络堆栈运行 aws cloudformation deploy，然后为 LiteLLM 网关堆栈运行。状态帮助程序运行 aws cloudformation describe-stacks 并打印堆栈状态和输出。
ECS 服务使用部署断路器回滚和应用程序负载均衡器健康检查。该参考模板还配置目标跟踪自动扩展、加密日志和数据、RDS 备份、ALB 访问日志和操作警报。
对于客户环境，请保留 ENABLE_TLS=true，使用受信任的 DNS 名称和 ACM 证书，并将 Application Load Balancer 限制为经批准的公司或 VPN CIDR。将 ECS 任务和 Amazon RDS 放置在私有子网中。不要公开暴露 ECS 任务端口 4000 或 PostgreSQL 端口 5432。
创建范围网关身份不要将 LiteLLM 主密钥分发给开发人员。在忽略的部署文件中配置用户或团队身份和策略：CODEX_API_SECRET_ID=codex-litellm-gateway/alice-keyCODEX_KEY_ALIAS=alice@example.comCODEX_KEY_USER_ID=alice@example.comCODEX_KEY_MODELS=gpt-5.5CODEX_KEY_MAX_BUDGET=50CODEX_KEY_BUDGET_DURATION=30 天CODEX_KEY_TPM_LIMIT=100000CODEX_KEY_RPM_LIMIT=1000配置密钥：CONFIRM_AWS_WRITE=1 make litellm-provision-key# Make 使用的直接帮助器调用：# CONFIRM_AWS_WRITE=1 部署/scripts/litellm-stack.sh 配置密钥帮助程序解析子进程内的主凭证，使用配置的模型、预算和费率策略调用 LiteLLM/key/generate API，并将生成的密钥直接写入 KMS 加密的 Secrets Manager 密钥。它不会将凭据放入命令参数中或将其打印到终端。对于企业部署，授予每个开发人员配置文件仅读取其分配的范围密钥机密并使用堆栈 KMS 密钥对其进行解密的权限。为团队或环境使用单独的秘密路径和 IAM 策略。配置 Codex生成提供程序块：生成的配置具有以下形状：探测器验证：
制作 litellm-codex-config
# Make 使用的直接帮助器调用：
# 部署/脚本/litellm-stack.sh codex-config
帮助程序从 CloudFormation 读取已部署的网关端点并打印以下 Codex 提供程序配置。它不会自动写入用户配置。
将输出添加到用户级 ~/.codex/config.toml。提供者和身份验证设置属于用户级别配置。 Codex 会忽略项目本地 .codex/config.toml 文件中的它们。
型号 = "gpt-5.5"
model_provider =“litellm-网关”
web_search =“已禁用”
[model_providers.litellm-gateway]
名称 =“LiteLLM 网关”
base_url =“https://codex-gateway.example.com/v1”
wire_api =“响应”
“--region”，“us-east-1”，
“--secret-id”，“codex-litellm-gateway/alice-key”，
“--字段”，“LITELLM_API_KEY”，
“--配置文件”，“开发人员配置文件”，“打印令牌”]超时毫秒 = 30000刷新间隔时间 = 300000Codex 在没有标准输入的情况下运行身份验证命令，并从其标准输出中读取不记名令牌。帮助程序使用指定的 AWS 配置文件检索当前密钥，因此令牌不会存储在 config.toml 中。在 LiteLLM 管理 UI 中，模型 + 终端节点显示了开发人员可用的稳定别名及其上游 Amazon Bedrock 映射。这提供了一种快速的视觉检查，开发人员可以看到网关别名，而不是直接将其 Codex 配置耦合到特定于提供商的模型 ID。下图显示了配置了两个模型别名的模型 + 端点页面。在继续进行 Codex 配置之前，请确认您的网关别名出现在此列表中。图 2：模型管理视图显示 gpt-5.4 和 gpt-5.5 别名及其 Amazon Bedrock Mantle 映射通过 LiteLLM 测试 Codex启动一个新的交互式 Codex 会话并使用/status 验证 litellm-gateway 是否是选定的提供程序。对于可重复的非交互式测试，首先运行最小烟雾请求：codex exec --sandbox 只读 --ephemeral \“仅回复 LITELLM_GATEWAY_OK，不要使用其他文字。”该命令应成功退出并打印 LITELLM_GATEWAY_OK。接下来，使用需要模型推理和本地工具的任务来练习代理循环：codex exec --sandbox 只读 --ephemeral \“使用shell工具阅读README.md并总结部署架构。不要修改文件。”Codex 通过 LiteLLM 发送任务和工具定义。如果模型要求读取文件，Codex 会在本地运行该命令并通过同一网关返回工具结果。在 LiteLLM 管理 UI 中打开日志，选择请求日志，然后筛选到测试窗口。验证：请求的状态为成功。密钥别名标识专用演练或开发人员密钥。模型解析为预期的 Amazon Bedrock 映射。填充令牌计数、请求持续时间和成本。当 Codex 在后续响应请求中发送工具结果时，使用工具的任务会创建多行。LiteLLM 中出现的行之前的 403 响应通常表示上游网络或 AWS WAF 块。 401 响应表示网关身份验证缺失或无效。请勿在屏幕截图中发布提示、响应、原始密钥、完整请求 ID 或真实员工身份。验证 Responses API 合约与 previous_response_id 的语义延续。
下图显示了多个成功的 Codex 请求通过网关后的 LiteLLM 请求日志页面。使用此页面可确认请求已到达 Amazon Bedrock 并通过状态代码排查错误。
图 3：请求日志显示成功的 Codex 轮次归因于 codex-walkthrough 密钥别名，包括模型、成本、持续时间和第一个令牌的时间
成功的文本提示并不能证明代理工作流是兼容的。 Codex 不仅仅依赖于基本的聊天完成响应。运行包含的严格探针：
进行 litellm 验证
服务器发送的事件流以及完整的终端响应。
带有调用 ID 的强制功能工具调用。
继续测试在第一个响应中记录唯一的测试标记，并验证它是否可以在后续响应中调用。这捕获在语法上接受 previous_response_id 但不保留先前响应状态的网关。
现场部署通过了完整的合同。 CloudFormation 成功完成，ECS 服务达到了预期的任务计数，部署部署完成，ALB 目标运行正常，加密的 PostgreSQL 数据库可用且不可公开访问。
下图显示了从实时演练堆栈中捕获的端到端部署验证仪表板。查看总体通过/失败状态以及确认基础设施运行状况、API 合同合规性、数据层配置和安全状况的四个详细面板。
图 4：验证输出确认 AWS 部署正常以及 Codex 所需的 Responses API 行为
验证脚本是兼容性门，而不是负载测试。在生产之前，还要测试并发代理会话、长时间运行的流、请求取消、密钥撤销、故障恢复和预期峰值流量。
运营 LiteLLM 供企业使用
成功的 Codex 执行和合约测试表明 Codex 可以使用网关，但兼容性只是起点。在加入开发人员之前，定义网关如何控制模型访问、属性使用、强制执行消费策略以及为每个模型请求提供操作记录。
从允许开发人员使用的模型表面开始。仅针对组织批准的模型发布稳定的网关别名，并将每个上游映射固定在deployment/litellm/litellm_config.yaml 中。重建网关映像并通过环境推广相同的 Amazon ECR 摘要。开发人员可以继续配置稳定的别名，同时系统团队保留对其背后的 Amazon Bedrock 模型的控制。当每个请求都有可归因时，模型策略就会变得更加有用。为用户、团队或工作负载颁发单独的范围密钥，而不是分发 LiteLLM 主密钥。 Amazon Bedrock 在上游请求中看到 LiteLLM ECS 任务角色，因此在范围密钥、LiteLLM 记录和导出的遥测数据中携带原始身份。这可以保留网关上的开发人员或团队归属，并允许请求 ID 与 AWS 服务日志相关联，而无需记录凭证。图 5：使用情况仪表板提供所选验证期间的模型级请求、令牌、支出和成功率可见性
相同作用域的身份可以强制执行消费策略。配置密钥时设置 CODEX_KEY_MAX_BUDGET、CODEX_KEY_BUDGET_DURATION、CODEX_KEY_TPM_LIMIT 和 CODEX_KEY_RPM_LIMIT。通过跨越配置的阈值并确认 LiteLLM 拒绝下一个请求，使用一次性身份验证这些控件。这会测试策略本身，而不仅仅是确认设置已被接受。
操作网关还需要查看完整的请求路径。 AWS 基础设施信号显示服务是否正常，而 LiteLLM 记录显示谁使用了哪种模型以及请求消耗了多少容量或预算。监控 ECS 所需和正在运行的任务计数、部署回滚、Application Load Balancer 目标运行状况和延迟、Amazon RDS 运行状况、LiteLLM 请求和拒绝、令牌使用情况、支出、秘密访问、IAM 更改和 AWS WAF 块。
在开发人员入职之前，决定是否可以记录提示和响应。将此内容视为潜在敏感的客户数据，并相应地定义修订、加密、访问控制和保留。生产部署应在模型访问路径上启用 Amazon Bedrock Guardrails，以进行内容过滤、拒绝主题检测和接地检查。网关级控制（预算、速率限制和路由）补充但不能取代模型层应用的负责任的人工智能防护措施。
下图显示了 LiteLLM 使用页面，该页面聚合了使用网关的所有开发人员的请求和令牌指标。使用此视图可以监控采用情况，识别成本异常，并在调整预算或速率限制之前按用户或时间范围隔离流量。
图 5 中的验证窗口包括成功的流量和失败的请求，表明仪表板公开了正常活动和错误。使用工具的任务可以生成多个请求日志行，因为 Codex 在后续响应请求中将本地工具结果返回到模型。结果使执行边界在操作数据中可见：LiteLLM 管理并记录模型请求，而 Codex 在开发人员工作站上执行工具。
考虑两种替代访问路径
LiteLLM 是主要演练，因为它使附加网关控件可见。它并不适合每个客户。
通过 IAM 身份中心直接访问
当 AWS 本机身份和审计控制足够时，使用内置的 amazon-bedrock Codex 提供商：
model_provider = "亚马逊基岩"
型号 =“openai.gpt-5.5”
[model_providers.amazon-bedrock.aws]
profile =“法典基岩”
区域 =“us-east-1”
开发人员使用命名的 IAM Identity Center 配置文件登录：
aws sso 登录 --profile codex-bedrock
此路径删除网关、数据库和关联操作。它在 AWS CloudTrail 日志中保留开发人员的 AWS 会话身份，但不会添加集中式网关级硬预算或路由策略。
存储库的 IAM Identity Center 快速入门包括 CloudFormation 和帮助程序命令，用于创建隔离组和权限集、将该组分配给 AWS 账户、打印客户端配置以及根据 Amazon Bedrock 验证登录配置文件。在添加网关之前，请使用此直接路径作为基线。使用 Portkey 进行托管或混合访问当客户需要托管控制平面、集中式路由和策略或受支持的混合数据平面而不需要操作 LiteLLM 参考堆栈时，Portkey 会很有用。清理预览 CloudFormation 将删除和保留的内容：结论
对于 Codex 评估，请配置 Portkey 工作区密钥、Amazon Bedrock 模型目录提供程序和响应有线协议：
model_provider = "端口密钥"
模型 =“@bedrock-validation/<批准的模型 ID>”
[model_providers.portkey]
名称=“门钥匙”
base_url =“https://api.portkey.ai/v1”
env_key =“PORTKEY_API_KEY”
wire_api =“响应”
在升级之前运行相同严格的响应探测。特别是，验证语义 previous_response_id 延续、流式传输、函数调用、确切的 Amazon Bedrock 路由以及 IAM 角色和外部 ID 设计。仅产品文档或认证响应并不能证明预期模型路径满足完整的 Codex 合同。
当托管或混合操作模型比完全在您的 AWS 账户中运行网关更重要时，请选择 Portkey。作为架构决策的一部分，审查供应商许可、数据处理、区域可用性、故障模式和支持边界。
制定 litellm-cleanup-plan
# Make 使用的直接帮助器调用：
# 部署/脚本/litellm-stack.sh 清理计划
这会读取堆栈并列出资源和保留行为，而不删除任何内容。
只有在确认其确切的堆栈名称后才能删除网关：
CONFIRM_STACK_DELETE=codex-litellm-gateway \
进行 litellm 清理
# Make 使用的直接帮助器调用：
# CONFIRM_STACK_DELETE=codex-litellm-gateway \
# 部署/脚本/litellm-stack.sh 清理帮助程序检查 Amazon RDS 删除保护，调用 aws cloudformation delete-stack，并等待网关堆栈删除完成。对于未共享的示例网络堆栈，请单独选择加入并确认：CONFIRM_STACK_DELETE=codex-litellm-gateway \DELETE_NETWORKING=1 \CONFIRM_NETWORKING_DELETE=codex-网络 \进行 litellm 清理# Make 使用的直接帮助器调用：# CONFIRM_STACK_DELETE=codex-litellm-gateway \# DELETE_NETWORKING=1 \# CONFIRM_NETWORKING_DELETE=codex-networking \# 部署/脚本/litellm-stack.sh 清理这还会删除网关堆栈之后的示例网络堆栈。不要将此选项用于共享网络。参考堆栈创建最终 Amazon RDS 快照并保留 KMS 密钥、Secrets Manager 密钥、CloudWatch 日志组和 ALB 访问日志存储桶。 ECR 映像和配置的范围密钥机密也在堆栈删除之外。根据您的数据保留策略查看并删除保留的资源。通过 LiteLLM 路由 Codex 为模型选择、范围身份、预算、速率限制和遥测提供客户操作的控制点，同时保留 Codex 的本地任务和工具执行模型。重要的生产门不是网关是否可以返回文本。问题在于网关是否保留代理工作流程所需的响应行为，以及系统团队是否可以可靠地操作添加的基础设施。当本机 AWS 控件满足要求时，开始直接访问 IAM Identity Center。当客户运营的网关策略证明运营工作合理时，添加 LiteLLM。当托管或混合运营模式更适合组织时，评估 Portkey，并对每条路径应用相同的合同测试。资源关于作者尼克·麦卡锡苏尼尔·贝马克Sunil 是 Amazon Web Services Gen AI 的高级合作伙伴解决方案架构师。他与大型语言模型 (LLM) 提供商合作，帮助客户在 AWS 上采用和实施生成式 AI。苏迪什·萨西达兰
Nick 是 Amazon Bedrock 团队的高级生成式 AI 专家解决方案架构师，专注于 Amazon Bedrock 上的 OpenAI 模型和 Codex。他与医疗保健、金融、体育、电信和能源等多个行业的 AWS 客户合作，帮助他们通过使用人工智能和机器学习来加速实现业务成果。
Sudeesh 是 OpenAI 市场推广人员的成员，专注于 OpenAI API 和 Codex。他的工作包括在 Amazon Bedrock 上与 AWS 合作，帮助组织采用和部署 OpenAI 的前沿模型。