博客 / 詳情

返回

Serverless is all you need: 在亞馬遜雲科技上一鍵部署大模型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 已不再維護）. 本文主要探討如何在亞馬遜雲科技上快速部署此項目且輕鬆實現彈性和高可用.

方案特點:

✅ Amazon CloudFormation 一鍵部署.
✅ 絕大部分服務為 Serverless 服務, 幾乎零運維負擔.
✅ 高彈性架構, 閒時節約成本, 高峯時期可承載高併發.
✅ 存算分離, 高可用架構.
✅ 安全可靠, 源站資源全部私有化部署, CloudFront 自帶抗DDOS. 所有網絡防火牆規則可通過 WAF 統一管理.

注1: 本方案的所有項目分析和 CloudFormation 部署腳本皆由 Amazon AI 工具 Kiro/Amazon Q Developer CLI 實現, 筆者輔助調節.

注2: 文中所提到的開源項目使用  Apache License Version 2.0, 本文僅探討關於源碼分析, 項目部署和功能使用層面的內容, 不涉及對原項目的代碼或商標修改. 在實際使用中請遵守項目協議. 若涉及到二次開發請標明原項目出處, 若涉及到商標修改和發佈, 請聯繫原作者.

📢限時插播：無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。
⏩快快點擊進入《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》實驗構建無限, 探索啓程！

方案架構

圖片

對於 Amazon Globa Region 可以使用此處的 yaml文件 在 CloudFormation 中一鍵部署:部署時務必將 DatabasePassword, SessionSecret, UserTokenSecret 這三個參數的默認值替換.

注意: 新亞馬遜雲科技賬號或沒有創建過ECS 資源的賬號在創建堆棧時可能會報錯(提示缺少ECS服務鏈接角色, 此角色為首次使用 ECS 時亞馬遜雲科技自動創建), 刪除堆棧再次嘗試即可.

項目部署分析

對此項目進行單機部署很簡單，在單機中直接運行 docker container 即可. 關於多機部署, 在項目部署文檔中也有説明, 其中第三條提到了從服務器 slave 和主服務器 master 的概念, 但並沒有詳細説明這兩種服務器類型的行為有什麼區別, 而理清這一點對我們後續的部署策略和流量分發策略非常重要.

圖片

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

Kiro 和 Amazon Q Developer 是亞馬遜雲科技發佈的 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 點快速接入亞馬遜雲科技骨幹網, 降低 API 訪問延時.

功能測試

部署完畢後，在 CloudFormation Stack Output 中找到 CloudFront URL, 根據此 使用説明 登陸系統進行 API 測試.
此處可配置 Amazon Bedrock 可用模型以及自定義映射關係:

圖片

Amazon Bedrock 相關模型的映射關係可以在此處找到.
配置完成後, 使用 Insomnia 進行 API 測試:

圖片

可觀測性

  • Aurora 集羣默認開啓 RDS Data API, 可通過亞馬遜雲科技控制枱 Query Editor 直接連接數據庫並運行 MySQL, 無需額外配置堡壘機.
  • 所有 Amazon ECS Task 產生的日誌默認發送到 CloudWatch, 可實時查看和分析.
  • 可開啓 ECS Exec 以直接登陸正在運行的 Container 進行問題排查.

成本分析

本方案絕大部分服務為 Serverless 服務, 成本與應用實際承載流量正相關. 以本文中提供的一鍵部署文件配置為例, 費用主要包含如下部分:

  • Amazon ECS Fargate 部署費用（共三個，單個配置為 256 CPU + 512 Memory, 表示 1/4 vCPU 和 512 MiB 內存）
  • Amazon Aurora Serverless V2 部署和存儲費用, 默認 0.5 ACUALB 部署費用.
  • 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. 同樣不會增加運維壓力.

通過充分利用亞馬遜雲科技的 Serverless 服務，我們將基礎設施運維的重擔轉移給了雲服務商,讓開發團隊能夠將更多精力集中在業務創新和產品迭代上. 與此同時，AI 工具的應用也極大提升了我們的工作效率，縮短了產品從開發到部署上線的週期。

人工智能和雲計算的結合是當下科技發展的大趨勢,我們期望通過這些前沿技術,不斷優化產品交付模式,為客户提供更加卓越的解決方案和服務體驗。

參考鏈接

  1. https://github.com/MartialBE/one-hub
  2. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-cluster-console-v2.html
  3. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html

*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。

本篇作者
圖片

本期最新實驗《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！
人工智能
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.