透過 LiteLLM 使用 Bedrock

如果組織透過 LiteLLM 將 Codex 路由到 Amazon Bedrock，請使用 本頁。如果已有 LiteLLM 閘道器，先連線 Codex。只有在 組織需要新閘道器時，才部署 LiteLLM。

其他閘道器產品遵循相同的閘道器要求 和 Codex 連線流程。

連線到現有閘道器

向閘道器管理員取得以下值：

• HTTPS 基礎 URL，例如 https://gateway.example.com/v1。
• LiteLLM 路由到獲准使用的 Bedrock 模型的模型別名。
• Codex 設定中要使用的供應商 ID。
• 限定權限範圍的閘道器憑證，或傳回該憑證的身分驗證輔助程式。
• 隨組織設定分發的模型目錄。

然後按以下順序完成連線：

1. 請閘道器團隊確認閘道器提供 POST /v1/responses， 支援串流回應、保留後續對話輪次和工具呼叫，並路由 獲准使用的別名。請參閱閘道器相容性。
2. 按照連線到閘道器中的說明 設定供應商、模型和憑證。
3. 驗證當前生效的供應商和別名，傳送連線指南中的簡短 gateway-ok 提示詞， 並確認 LiteLLM 記錄顯示預期的 使用者和別名。
4. 要在整個組織中分發，請繼續參閱透過閘道器部署 Codex。

閘道器憑證用於向 LiteLLM 驗證你的身分。閘道器自行管理 Bedrock 憑證；你無需將這些憑證複製到工作站。

準備閘道器

僅在連線 Codex 之前需要建立 LiteLLM 閘道器時，才使用 本節。

部署之前

確認已具備：

• 在 AWS 環境中部署已獲核准的 LiteLLM 架構的權限。
• 對將要路由的模型或推理設定檔的 Bedrock 存取權限。
• 已審查的 LiteLLM 映像和部署方案。
• 可信的 HTTPS 主機名和憑證。
• 受限的用戶端網路範圍。

對於下方的 Runtime 範例，閘道器的 AWS 身分需要對所選推理設定檔和帳戶的預設專案擁有 bedrock:InvokeModel 權限。有關所需權限，請參閱 AWS 的 GPT-6 Sol 設定說明。

架構

部署將 LiteLLM 置於 Codex 和 Bedrock 之間，在用戶端 邊界使用 HTTPS。負載平衡器和 LiteLLM 位於組織的閘道器 邊界內；供應商憑證保留在閘道器上。

將入站存取限制為獲准使用的用戶端，保持資料庫和快取埠私有，並只授予閘道器所需的 Bedrock 權限。透過摘要固定部署映像，避免重啟時實現發生靜默變化。

提示詞、原始碼摘錄和工具結果會經過閘道器，並可能進入其日誌。在啟用請求日誌記錄前，先確定保留、存取和脫敏策略。MCP server和外掛使用獨立的連線和身分驗證；此閘道器設定不會設定它們。

部署檢查點

在將閘道器交付給開發者之前，按順序完成以下檢查：

以下各節介紹每個檢查點。對於生產環境推廣，還應測試 後續對話輪次、工具和憑證撤銷。

選擇 Bedrock 路由

LiteLLM 上游路由決定 Bedrock 端點、模型識別符和身分驗證方法。部署或更改閘道器時，請一並考慮這些選擇。

新設定應使用 Bedrock Runtime。以下範例使用其相容 OpenAI 的 Responses 端點。

有關替代路由，請參閱 LiteLLM 的 Bedrock Mantle 整合。

有關 AWS 部署範例，請使用固定版本的 LiteLLM on ECS 參考實現。該實現使用 Bedrock Runtime，並從 ECS 任務角色重新整理身分驗證憑證。請一並遵循其部署和身分驗證步驟，並根據你的網路、TLS、日誌記錄和資源保留策略審查其生產環境要求。

無論選擇哪條路由，都應根據閘道器相容性驗證已部署的閘道器版本、上游端點和模型組合。上游模型出現在閘道器模型清單中，並不能證明其串流傳輸、對話延續和工具行為可與 Codex 正常配合。

設定 Runtime 模型路由

將穩定的 Codex 模型別名對映到已獲核准的上游模型。使用此 Runtime 範例前，確認你的 AWS 帳戶和區域具備存取權限。

model_list:
  - model_name: company-coding-model
    litellm_params:
      model: openai/global.openai.gpt-6-sol
      api_key: os.environ/AWS_BEARER_TOKEN_BEDROCK
      api_base: https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1

透過敏感資訊管理系統，以 AWS_BEARER_TOKEN_BEDROCK 提供有效的 Bedrock API key。對於短期有效的金鑰，應在過期前簽發替代金鑰、更新閘道器程序環境，並重啟或重新部署使用該金鑰的工作程序。ECS 參考實現則在程序內從任務角色重新整理憑證；請配套使用其設定和入口程式。

openai/ 字首選擇 LiteLLM 的 OpenAI 相容轉接器；設定的 api_base 將請求傳送到 Bedrock Runtime。全域（Global）推理設定檔可以將請求路由到來源區域之外。選擇滿足 AWS 權限和資料駐留要求的設定檔及區域，並按需替換這兩個值。

用戶端傳送 company-coding-model；LiteLLM 使用設定的上游路由。此自訂別名需要下文介紹的匹配用戶端目錄。通用閘道器不會繼承內建 Bedrock 供應商的後設資料調整。

準備用戶端目錄

對於使用 Codex 0.158.0 的此 GPT-6 Sol/Runtime 範例，請從該版本的模型目錄中取得完整的 gpt-6-sol 條目作為起點。對該條目應用以下所有修改：

保留其餘欄位，包括模型指令和上下文限制。將編輯後的條目保留在目錄的頂層 models 陣列中。這些更改與已發布的 Bedrock 後設資料調整和 Runtime 搜尋限制一致。更改用戶端版本或上游模型時，請對照匹配的原始碼重新檢查。

按照透過閘道器部署 Codex中的說明，分發完整 JSON 檔案並設定 model_catalog_json。在 Runtime 用戶端設定中保留 web_search = "disabled"。向更多使用者分發之前，先透過閘道器驗證編輯後的目錄。

驗證 Responses 支援

在面向用戶端的 HTTPS 端點提供 POST /v1/responses。設定負載平衡器及所有反向代理，使其無緩衝地傳遞串流事件。保留後續對話輪次和函式呼叫結果。僅有可用的 Chat Completions 端點不足以支援此連線。

分發用戶端設定之前，完成閘道器相容性中的檢查。使用與使用者相同的主機名、網路控制和身分驗證路徑進行測試。

簽發測試憑證

為一位測試使用者建立限定權限範圍的 LiteLLM 虛擬金鑰。將其限制為獲准使用的別名，並設定有效期、速率限制和預算。有關適用的控制項，請參閱 LiteLLM 的虛擬金鑰文件。

透過敏感資訊管理流程或身分驗證輔助程式分發金鑰。不要向使用者提供 LiteLLM 管理金鑰，也不要將閘道器憑證嵌入 config.toml。

驗證使用者連線

擴大存取範圍之前，完成以下檢查：

1. 確認 HTTPS 憑證與閘道器主機名匹配，且服務執行正常。
2. 按照連線到閘道器中的說明連線一位使用者。
3. 執行簡短提示詞、後續對話輪次和唯讀工具任務。
4. 確認閘道器記錄顯示預期的身分、別名和上游路由，且不暴露憑證或敏感的提示詞內容。
5. 測試憑證過期或撤銷，並確認未經授權的模型別名會被拒絕。

將部署的映像版本、路由設定和測試結果儲存在推廣記錄中。有關團隊分發和持續運維，請繼續參閱透過閘道器部署 Codex。

排查連線問題

根據出錯層縮小問題範圍：

修復後重新測試同一使用者路徑。閘道器健康檢查成功，並不能驗證經過身分驗證的推理請求或完整的 Codex 對話輪次。