一個 AWS Bedrock、Google Vertex AI、Gemini 和 Anthropic 的 AI 通道

Bifrost 可透過一個與 OpenAI 兼容的 API，將 AWS Bedrock、Google Vertex AI、Gemini 和 Anthropic 一起路由，並共享認證、故障轉移和治理。

企業的 AI 团隊只運營單一供應商的一個模型是罕見的。大多數公司的生產堆栈看起來通常像這樣：Claude 在 AWS Bedrock 上運營一類工作負載，Gemini 在 Google Vertex AI 上運營另一類，原生 Anthropic API 用於提示緩存等功能，而直接 Google Gemini API 帶動低延遲的消費者路徑。每個供應商說它自己的協議，需要它自己的認證方案，並發行它自己的 SDK。Bifrost 將所有這些壓縮成單一與 OpenAI 兼容的終端，同時面向 AWS Bedrock、Google Vertex AI、Google Gemini 和 Anthropic，並且故障轉移、負載平衡和治理內建在網關本身中。

Bifrost，由Maxim AI開發的開源AI網關，每秒可處理5,000個請求，每個請求僅增加11微秒的額外開銷，並透過一個API連接20多家LLM供應商。本指南解釋了團隊為何將Bedrock、Vertex、Gemini和Anthropic部署在Bifrost後面，逐步說明了每個供應商的配置方法，並展示了Bifrost的路由層如何確保多供應商工作負載的穩定性。完整的開銷配置文件記錄在Bifrost的發布了的基準測試

為何 Claude 和 Gemini 終究會跨越多個雲端

Anthropic 將Claude 通過 AWS Bedrock、通過Google Vertex AI，以及通過其自身的原生 API。Google 在 Vertex AI 和直接 Gemini API 上都提供 Gemini 企業會選擇超過一種這些平台，有三大常見原因，都與採購、延遲和功能相關：

AWS Bedrock 能完美融入已持有 AWS 合約的團隊，透過 AWS Organizations 進行存取管理，並且擁有與 AWS 地區相關的數據駐留對應規劃。
Google Vertex AI 在已使用 Google Cloud 的組織中或希望統一控制平面以整合 Gemini、Claude 和第三方模型的團隊中，往往能贏得青睐。
原生 Anthropic API 提供了如提示緩存和最新測試版標頭等功能，這些功能在發布後可能需要數週或數月才能在 Bedrock 和 Vertex 上可用。
Gemini API 提供到 Gemini 模型的最短直接路徑，並搭配寬厚的免費層級，對於原型設計非常有幫助.

一旦工作負載從原型階段升級到生產規模，團隊幾乎總是依賴這些路徑中的多於一種。當每個路徑都透過其原生 SDK 操作時，真正的痛苦才顯現出來.

管理四個獨立供應商的成本是多少

沒有中間的閘道，每個提供者都拖入自己的相依性與程式路徑：

不相容的SDKs：boto3用於Bedrock、Google Cloud SDK for Vertex、google-genai用於Gemini，以及Anthropic SDK用於直接API存取.
不同的驗證模型：IAM憑證和SigV4簽名用於Bedrock，OAuth2服務帳戶用於Vertex，一個用於Gemini的API金鑰，以及一個用於Anthropic的持有者令牌.
不同的請求形態：Bedrock的Converse API不符合Anthropic的Messages API，而且也都不符合Vertex的generateContent終點.
沒有共同的故障轉移故事：如果Bedrock的Claude端點觸及速率限制，您的程式碼必須知道如何切換到Anthropic的直接API作為備援。
分片使用數據：每個提供者分別報告成本和消費，這使得跨團隊或最終客戶的成本分配變得複雜。

跨足 OpenAI、Anthropic、Google Vertex AI 與 AWS Bedrock 的可靠生產 AI 系統，無法僅憑直接 API 呼叫和手動編寫的重試邏輯來維持。解決這個確切問題正是 Bifrost 存在的目的。

Bifrost 統一 Bedrock、Vertex、Gemini 和 Anthropic 的方法

Bifrost 位置於應用層和這四個提供者之間，顯示出一個 OpenAI 兼容的終端點。應用程式碼呼叫 Bifrost，而 Bifrost 則負責協議翻譯、驗證以及路由至上游提供者。這是即插即用的模式：在您現有的 OpenAI、Anthropic、Bedrock 或 Google SDK 中切換基本 URL，您其他的程式碼仍然可以正常運作。

交換中您獲得的內容：

一個端點涵蓋所有四個提供者以及超過16個額外提供者。
一個單一的設定介面，用於金鑰、區域、專案和IAM角色。
無論哪個提供者回應了呼叫，都使用同一個OpenAI伺服器傳送事件流格式。
內建的的路由規則，可根據模型名稱、虛擬金鑰或加權來目標化請求。
跨所有上游供應商共享可觀察性、治理和權限框架.

供應商針對使用provider/model語法。bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0連接到Bedrock上的Claude。vertex/gemini-2.5-flash連接到Vertex上的Gemini。gemini/gemini-2.5-pro呼叫直接的Gemini API。anthropic/claude-sonnet-4-20250514觸及原生Anthropic API.

在Bifrost中設定每個供應商

提供者可透過 Bifrost 網頁介面、API、一個 config.json 檔案，或 Go SDK 來進行設定。下方片段說明了設定形態；完整資訊記錄在文件中.

AWS Bedrock

Bifrost 內建的 AWS Bedrock 提供者接受靜態 IAM 凭證、EKS 上的 IRSA、EC2 实例配置，以及AWS_ACCESS_KEY_ID 設定環境變數。它也涵蓋了帶有外部 ID 和會話名稱的假設 IAM 角色，這與跨帳戶 Bedrock 存取所使用的標準模式相符。

{
  "providers": {
    "bedrock": {
      "keys": [{
        "models": ["*"],
        "weight": 1.0,
        "aliases": {
          "claude-3-5-sonnet": "us.anthropic.claude-3-5-sonnet-20241022-v2:0"
        },
        "bedrock_key_config": {
          "region": "us-east-1",
          "role_arn": "env.AWS_ROLE_ARN",
          "external_id": "env.AWS_EXTERNAL_ID"
        }
      }]
    }
  }
}

將存取金鑰和秘密金鑰留空會指示 Bifrost 回退至 AWS 預設認證鏈，該鏈接會依序掃過 IRSA、ECS 執行任務角色、EC2 实例配置文件、環境變數和共用認證文件。

Google Vertex AI

Bifrost 的 Google Vertex AI 提供者經由 Google Cloud 學習到 Gemini、Claude 與第三方模型。此模型家族（Gemini 與 Anthropic）會自動偵測，並應用正確的請求轉換。Vertex 上支援三種驗證路徑：服務帳戶 JSON、應用程式預設憑證（GKE Workload Identity 的建議路徑），以及僅供 Gemini 使用案例的 API 金鑰。

{
  "providers": {
    "vertex": {
      "keys": [{
        "models": ["*"],
        "weight": 1.0,
        "vertex_key_config": {
          "project_id": "env.VERTEX_PROJECT_ID",
          "region": "us-central1",
          "auth_credentials": "env.VERTEX_CREDENTIALS"
        }
      }]
    }
  }
}

OAuth2 token 缓存與刷新會自動發生在 Bifrost 內。對於 Vertex 上的 Claude，anthropic_version 標頭會被設定為 vertex-2023-10-16，且任何不支援的 beta 標頭都會在請求轉發前被移除。

Google Gemini

The Gemini 提供者使用來自 Google AI Studio 的簡單 API 金鑰進行驗證。當 Vertex 的專案、區域和 IAM 設備超過工作負載需求時，請使用這個路徑。

{
  "providers": {
    "gemini": {
      "keys": [{
        "value": "env.GEMINI_API_KEY",
        "models": ["gemini-2.5-flash", "gemini-2.5-pro"],
        "weight": 1.0
      }]
    }
  }
}

Gemini 的原生串流格式經由 Bifrost 轉換為標準的 OpenAI 服務端發送事件形態，您的客戶端已經預期，因此相同的請求主體可以運行對bedrock/... 也運行在 gemini/... 上，且客戶端無需任何變更。

Anthropic

The Anthropic 提供者直接調用 Anthropic 的原生 API。當工作負載需要提示緩存、beta 標頭，或任何尚未傳播到 Bedrock 或 Vertex 的 Claude 功能時，請使用此接口。

{
  "providers": {
    "anthropic": {
      "keys": [{
        "value": "env.ANTHROPIC_API_KEY",
        "models": ["claude-sonnet-4-20250514", "claude-opus-4-20250514"],
        "weight": 1.0
      }]
    }
  }
}

當所有四個提供者都設定完成後，一個 OpenAI 兼容的請求可以透過交換 model 項目來目標化它們中的任何一個。應用程式碼不需要變更.

跨提供者路由、故障移轉和負載平衡

當 Bedrock、Vertex、Gemini 和 Anthropic 都坐落於 Bifrost 之後，你便可以將它們串聯起來，形成可靠性和成本策略，這些策略否則需要自訂程式碼：

自動故障轉移：Bifrost 的重試和回退允許你宣告一個主要鏈路和一個備用鏈路。如果 Bedrock 的 Claude 端點開始拋出 429 錯誤或 5xx 錯誤，Bifrost 可以將呼叫轉發到在 Vertex 上運行的 Claude，然後再到 Anthropic 自己的 API，所有這些都不需要任何應用程式端的干預。
加權負載平衡：Bifrost 的金鑰和負載平衡會根據加權分發流量至各服務提供者。以一個例子而言，Claude的70%流量可以在Bedrock上處理，而剩下的30%則會導向Vertex，這是在分階式遷移期間的安排。
考量成本的導流：較便宜或對延遲敏感的請求可以發送到Gemini，而高風險的推理呼叫則會留在Claude上。
考量區域的導流：歐洲流量可以維持釘定在Vertex上。eu-west1，而來自美國的流量則會落在us-east-1上，且應用程式碼不會變更.

因為路由決策是在閘道中做出，應用程式團隊從來不必自行思考供應商可用性或失效模式.

複合供應商工作負載：治理與可觀察性

將 Bedrock、Vertex、Gemini 和 Anthropic 透過一個入口整合起來，也將操作表面整合至單一控制平面。Bifrost 提供：

虛擬金鑰、預算和速率限制：團隊或客戶的虛擬金鑰可以發行，並設有專用的支出上限和速率限制，無論哪個上游提供者處理請求。Bifrost 的治理能力覆蓋虛擬按鍵、RBAC、審計日誌和粒度化的速率限制.
統一的可觀察性: 原生的 Prometheus 和 OpenTelemetry導出器跨過每個提供者發布請求級別指標、分佈式追蹤和成本數據.
限制器：透過 AWS Bedrock Guardrails、Azure Content Safety 或 Patronus AI 的內容安全政策，適用於所有上游供應商。
審計記錄：每個請求的不變追蹤記錄，包括供應商、模型、延遲時間、代碼片段和成本，支援 SOC 2、GDPR、HIPAA 和 ISO 27001 合規報告。

對於運行 Bifrost for AWS Bedrock 的團隊在他們自己的 VPC 內，所有這些流量從未離開客戶的 AWS 帳戶.

在 Bifrost 上開始使用 Bedrock、Vertex、Gemini 和 Anthropic

將 Bedrock、Vertex、Gemini 和 Anthropic 合併至 Bifrost 上，將四個 SDK、四種身份驗證方案和四個獨特的錯誤處理層合併為單一個 OpenAI 兼容的終端。協議翻譯、OAuth2 和 IAM憑證處理、流動標準化以及路由都在閘道內完成，因此應用程式團隊可以向單一個 API 推送，而平台團隊則能完全控制成本和治理。

想了解 Bifrost 能為您的多供應商 AI 堆疊做些什麼，請隨隊伍預約示範。

推薦訂閱源

DEV Community