亚马逊AWS官方博客

Serverless is all you need: 在AWS上一键部署大模型API聚合管理平台OneHub

在AI 应用开发过程中, 开发者会使用到各大模型API, 只使用一家LLM provider 往往难以满足需求, 而在接入多家API时, 我们往往会遇到如下问题:

  1. 各家LLM provider 的 认证凭据不同, 需要进行集中管理.
  2. 不同 LLM provider 的API 调用方式有差别, 会提升业务代码的复杂度.
  3. 各个 LLM provider 的调用量和消费情况需要进行统计.
  4. 业务团队对不同模型API 的调用权限需要进行管理.

针对此类场景,  解决方法往往是增加一个 LLM Gateway 进行统一管理, 比较流行的有 LiteLLM、OpenRouter 和 Ollama 等, 我们测试下来,  针对大量终端客户做 API 分发的场景, 开源项目 One Hub 较为实用, 此项目以 one-api 为基础（one-api 已不再维护）. 本文主要探讨如何在 AWS 上快速部署此项目且轻松实现弹性和高可用.

方案特点:

✅ AWS CloudFormation 一键部署.
✅ 绝大部分服务为 Serverless 服务, 几乎零运维负担.
✅ 高弹性架构, 闲时节约成本, 高峰时期可承载高并发.
✅ 存算分离, 高可用架构.
✅ 安全可靠, 源站资源全部私有化部署, CloudFront 自带抗DDOS. 所有网络防火墙规则可通过 WAF 统一管理.

注1: 本方案的所有项目分析和 CloudFormation 部署脚本皆由 AWS AI 工具 Kiro/Amazon Q Developer CLI 实现, 笔者辅助调节.

注2: 文中所提到的开源项目使用  Apache License Version 2.0, 本文仅探讨关于源码分析, 项目部署和功能使用层面的内容, 不涉及对原项目的代码或商标修改. 在实际使用中请遵守项目协议. 若涉及到二次开发请标明原项目出处, 若涉及到商标修改和发布, 请联系原作者.

方案架构

对于 AWS Globa Region 可以使用此处的 yaml文件 在 CloudFormation 中一键部署:
部署时务必将 DatabasePassword, SessionSecret, UserTokenSecret 这三个参数的默认值替换.

注意: 新 AWS 账号或没有创建过ECS 资源的账号在创建堆栈时可能会报错(提示缺少ECS服务链接角色, 此角色为首次使用 ECS 时AWS 自动创建), 删除堆栈再次尝试即可.

项目部署分析

对此项目进行单机部署很简单，在单机中直接运行 docker container 即可. 关于多机部署, 在项目部署文档中也有说明, 其中第三条提到了从服务器 slave 和主服务器 master 的概念, 但并没有详细说明这两种服务器类型的行为有什么区别, 而理清这一点对我们后续的部署策略和流量分发策略非常重要.

使用 Kiro/Amazon Q Developer 分析源码以明确部署策略

Kiro 和 Amazon Q Developer 是 AWS 发布的 AI IDE 和 AI Agent 工具, 可以自动读取项目代码文件和搜索整个代码仓库从而实现对项目源码的精准分析. 用户可以根据自己的喜好选择任意一款工具快速完成项目分析任务. 笔者这里在Visual Studio Code 中打开了 One Hub 项目并启用了命令行工具 Amazon Q Developer CLI 对整个项目进行了分析, 最终结论如下:

详细分析请见: NODE_TYPE_分析报告

由此报告我们可以总结出部署需要注意的事项:

  1. 数据库连接：所有节点需要连接同一个数据库
  2. 配置同步：Slave 节点会定期从数据库同步配置
  3. 唯一性：建议只部署一个 Master 节点
  4. 网络访问：确保 Slave 节点能访问数据库

ECS 集群部署规划

我们计划创建一个 ECS Cluster 并部署两个 Service.
创建两个 Task Definition 以为 Master 节点和 Slave 节点配置不同的环境变量.

Master Service

  1. 使用 master-task-definition 启动 ECS Task.
  2. 只启动一个 ECS task,  运行 Master 节点.

Slave Service

  1. 使用 slave-task-definition 启动 ECS task.
  2. 启动多个 ECS task, 运行 Slave 节点.
  3. 在 Task Definition 中设置环境变量
  4. 开启自动扩展, 以 CPU 或内存占用率为扩展指标.

ECS Service 开启 Availability Zone rebalancing，以确保 LLM API 服务始终高可用.

数据库

由上文可以明确，所有节点需要连接到同一个数据库, 而只有Master 节点会进行写入操作.
本文部署 Aurora Serverless V2 for MySQL, 具有如下特点:

  1. 可以根据使用情况自动扩缩容，从 0.5 ACU（1 GiB 内存）到 256 ACU（512 GiB 内存）, 最小扩展单位为 0.5 ACU.
  2. 数据存储部分按实际使用量收费，无需预置存储容量.
  3. 原生高可用, 自动故障转移.

ALB 流量分发策略

  • Master 节点：负责数据管理、定时任务和系统维护
  • Slave 节点：负责请求处理和服务扩展

我们可以使用 ALB 监听器规则将 LLM API 请求全部转发到 Slave Target Group, 将所有其他与前端页面操作（主要是管理动作）相关的请求转发到 Master Target Group. 示例如下:

注意这里设定的规则:

Path = *v1*

主要是为了匹配多种 LLM API 调用格式, 如

/v1/chat/completions
/claude/v1/messages

但实际上这个规则并不能覆盖市面上所有的调用格式，且易与其他 API path 冲突, 需要针对使用场景进行修改.

网络规划

该项目大多数场景是在互联网上提供服务, 为确保服务数据安全且长期稳定运行, 在网络规划方面我们有以下几个要点:

  1. ECS task 全部运行于 VPC 私有子网, 通过公有子网的 NAT Gateway 实现公网访问.
  2. 数据库 Aurora 运行于 VPC 私有子网, 配置安全组规则允许 ECS task 访问.
  3. ALB 部署在 VPC 私有子网, 禁止公网访问.
  4. CloudFront 采用 VPC origin 连接源 ALB.

通过此配置, 我们在没有额外配置 WAF 的情况下即可实现:

  • 源站无公有 IP, 所有公网入站流量只能通过 CloudFront, 极大降低了攻击面.
  • CloudFront 自带的 Standard Shield 可以抵御大部分 DDoS 攻击.
  • 通过 CloudFront 关联 WAF 规则, 可以在单一入口完成防护配置和流量分析, 运维简单.
  • 通过 CloudFront 全球 PoP 点快速接入 AWS 骨干网, 降低 API 访问延时.

功能测试

部署完毕后，在 CloudFormation Stack Output 中找到 CloudFront URL, 根据此 使用说明 登陆系统进行 API 测试.
此处可配置 AWS Bedrock 可用模型以及自定义映射关系:

AWS Bedrock 相关模型的映射关系可以在此处找到.
配置完成后, 使用 Insomnia 进行 API 测试:

可观测性

  • Aurora 集群默认开启 RDS Data API, 可通过AWS 控制台 Query Editor 直接连接数据库并运行 MySQL, 无需额外配置堡垒机.
  • 所有 AWS ECS Task 产生的日志默认发送到 CloudWatch, 可实时查看和分析.
  • 可开启 ECS Exec 以直接登陆正在运行的 Container 进行问题排查.

成本分析

本方案绝大部分服务为 Serverless 服务, 成本与应用实际承载流量正相关. 以本文中提供的一键部署文件配置为例, 费用主要包含如下部分:

  1. AWS ECS Fargate 部署费用（共三个，单个配置为 256 CPU + 512 Memory, 表示 1/4 vCPU 和 512 MiB 内存）
  2. AWS Aurora Serverless V2 部署和存储费用, 默认 0.5 ACU
  3. ALB 部署费用.
  4. NAT Gateway 部署费用.

在个人使用场景下，经测试每日成本在 3.7-5.4 美元之间（不含大模型 API 调用费用）, 不同 Region 部署会有差别. 可以看出 Serverless 架构用于部署流量不确定或业务起步阶段的应用具有巨大成本优势.

总结与展望

在将此方案部署落地到产品时，我们有如下改进方向：

  1. CloudFront 默认与源站的连接 Timeout 最高为60s, 可以通过提交工单提升到 180s, 以适应超长 prompt 或输出的 API 调用场景.
  2. 配置关联到 CloudFront 的 WAF 规则, 启用实用托管规则比如限流规则以及 Layer 7 DDoS 防护规则.
  3. ECS Cluster 支持 EC2 + Fargate 混合部署, 考虑到 Master 节点只需部署一台而不做扩缩容, 若需要长期提供服务, 可以将 Master Task Definition 改为 EC2 实例部署并购买预付实例.
  4. 若需要提升接口响应速度, 可以考虑部署 Amazon ElastiCache Serverless for Redis. 同样不会增加运维压力.

通过充分利用 AWS 的 Serverless 服务，我们将基础设施运维的重担转移给了云服务商,让开发团队能够将更多精力集中在业务创新和产品迭代上. 与此同时，AI 工具的应用也极大提升了我们的工作效率，缩短了产品从开发到部署上线的周期。

人工智能和云计算的结合是当下科技发展的大趋势,我们期望通过这些前沿技术,不断优化产品交付模式,为客户提供更加卓越的解决方案和服务体验。

参考链接

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

李永乐

亚马逊云科技解决方案架构师，专注于各行业的生成式 AI 解决方案的架构咨询和设计。在加入亚马逊云科技之前，曾就职于微软、惠普软件等企业，具有丰富的云计算实践经验。