一個 AI Gateway 置於一組工作 AI 伺服器之前。應用程式只需以一個 URL 和一把金鑰連接至該 Gateway，彷彿它是一台單一的 AI Server；在背後，Gateway 會將每個請求負載平衡至各工作伺服器，對每台伺服器進行健康檢查，並在伺服器故障前將流量轉移至健康伺服器，令呼叫方無感 [1]。這並非獨立產品。AI Gateway 是 AI Server 以其叢集前端模式運行，因此 OpenAI 相容的 /v1/* 及 Ollama 相容的 /api/* 所呈現的單一伺服器介面，正是該叢集所提供的 [1]。
一個 URL 和一把金鑰，背後是一個叢集
Gateway 平衡平台所服務的所有請求類型：聊天、嵌入、圖像生成、視覺及音訊，包括即時語音 WebSocket [1]。請求依您選擇的策略分配——輪詢、最低延遲、最少連線、加權或每客戶端黏著。模型感知路由會將請求導向已預熱該模型的工作伺服器，避免冷啟動延遲，否則較冷的機器可能會接手該請求 [1]。
新增 GPU 主機即可擴充容量；客戶端無需更改。維護時關閉主機，其流量會優雅地排空，確保不會丟失任何進行中請求。我們在自家測試套件中會在流量中途終止工作伺服器以驗證此保證：故障的工作伺服器請求會在健康伺服器上重試，且故障轉移在 Gateway 內部完成，客戶端不會見到錯誤 [1][3]。
叢集引入的信任邊界
叢集改變了憑證持有者，設計上保持該邊界嚴謹。客戶端的 Gateway 金鑰絕不會傳至工作伺服器。Gateway 會向每台工作伺服器呈現其專屬金鑰，因此即使 Gateway 金鑰外洩，也無法直接重放至工作伺服器，且每台工作伺服器的憑證均保留在叢集內 [2]。呼叫者身份，即哪個應用程式及安裝發出請求，會傳遞至工作伺服器。每台工作伺服器的無內容審計日誌因此記錄真實發起者，而非全部歸因於 Gateway [2]。
背壓取代逾時
當所有工作伺服器飽和時，Gateway 會回傳明確的「請稍後重試」訊號，而非持續保持連線直到逾時 [1]。呼叫方會收到可採取行動的訊號。兩項部署控制運行於同一路由層。金絲雀發布會在新機器承擔全部負載前，持續分配固定比例流量。零停機升級會排空工作伺服器、升級後再回歸叢集，端點全程保持運作 [1]。
Kubernetes 無需手動編輯叢集
在 Kubernetes 上，工作節點會隨著擴展自動被發現，因此自動擴展的叢集無需手動編輯閘道器的工作節點清單 [2]。此方案從同一產品提供三種部署方式：用於單機示範的 Docker Compose、Kubernetes 清單，以及用於叢集的 Helm chart。無論是筆記型電腦還是 GPU 叢集，產品本身、API 及授權均完全相同 [2]。
運行一個叢集的成本
每台伺服器（包括閘道器）都會自帶即時儀表板，並且公開原生 Prometheus 指標以監控整體狀態、延遲、使用率及容量 [3]。叢集的可視化是一個儀表板，而非在第一個請求前組裝的監控堆疊。網絡服務在每個節點均受控：非迴環地址的綁定失敗會自動關閉，除非該節點擁有 Pro 授權及至少一個 API 金鑰，這可防止未授權或無金鑰的設備在局域網上悄悄暴露自己 [1][4]。
閘道器叢集是平台可用性架構的核心：當某台設備故障時，AI 端點仍保持運作，且請求路徑中不經過任何供應商雲端。此功能作為 Pro 商業版授權的一部分提供，並非獨立產品銷售 [4]。