作者：Liam Crilly of F5
本文轉載自 The New Stack。
AI 閘道是 AI 基礎設施領域的新焦點。AI 閘道正在成為 AI 基礎設施中的重要技術。這些系統作為關鍵的緩衝，負責在 AI 應用與外部使用者，以及內部 AI 建模團隊之間提供安全防護與負載平衡。導入 AI 閘道的需求已日益迫切。
隨著大型語言模型（LLM）、先進電腦視覺演算法及其他機器學習技術成為應用的重要部分，整合與管理的挑戰也越來越複雜。AI 閘道為這些難題提供了一種創新的解決方案，同時也成為 AI 工作負載的集中管理點。
不過，許多 AI 閘道的提供商並未直接使用「AI 閘道」這個名稱，而是將其描述為 AI 開發者入口、AI 防火牆、AI 安全防護或 AI 負載平衡——這些功能其實都屬於 AI 閘道的範疇。
毫不意外地，AI 閘道經常被拿來與 API 閘道相比較。管理 API 是 AI 閘道的一大核心功能，這些閘道通常被設計來與大型雲端服務或 OpenAI 等外部 AI 供應商進行互動。（事實上，一些號稱 AI 閘道的產品，本質上就是在 API 閘道的基礎上，額外加入針對 AI 應用的調整與最佳化插件。）
因此，若要設計符合現代應用需求的 AI 基礎設施，了解 API 閘道與 AI 閘道之間的差異至關重要。
API 閘道仍然扮演不可或缺的角色
API 閘道作為客戶端與後端服務之間的中介，能幫助應用開發人員、安全團隊及 DevOps 或 Platform Ops 團隊簡化 API 在應用端的管理與部署。API 閘道同時具備安全防護與負載平衡功能，不僅確保企業 API 的安全性，也能保護企業的外部 API 免於攻擊者的濫用。
API 閘道的主要功能包括：
- 治理：制定並執行一套策略、標準與流程，以管理、監控及控制 API 的使用、開發與維護。
- 請求路由：智慧地將請求導向適當的服務，確保數據能送達正確的 AI 模型進行處理。
- 身份驗證與授權：透過 API 金鑰、OAuth 及 JSON Web Token（JWT）等機制執行嚴格的存取控制。
- 效能優化：透過速率限制（防止過度使用）與快取（儲存常用回應）來提升回應速度與資源使用效率。
- 監控與記錄：提供 API 使用情況、錯誤率及整體系統健康狀況的詳細資訊，對於故障排除與優化至關重要。
- 商業變現：提供基於 API 的產品與服務的商業變現機制，決定 API 產品及功能的消費對象與收費標準。
AI 系統需要專門的閘道
如今，大多數企業透過第三方 API（如 OpenAI、Hugging Face 或超大規模雲端服務商）來使用 AI。而實際建置、調校並自主管理模型的企業，則可透過內部 API 來存取這些模型。AI 閘道的核心功能是幫助應用開發人員、AI 數據工程師及營運團隊能夠快速、輕鬆地調用 AI API，並將其整合至應用之中。AI 閘道的運作方式類似於 API 閘道。
然而，兩者之間存在顯著差異。例如，在運算需求上，AI 應用與傳統應用有根本性的不同，並且需要使用不同的硬體。訓練 AI 模型、微調 AI 模型、為其添加專業數據，甚至查詢 AI 模型等各種作業，都可能有不同的效能、延遲或頻寬需求。
由於深度學習的內建並行運算特性，或推理過程對即時回應的要求，AI 工作負載的分配方式可能與傳統應用不同。此外，要評估 AI 系統的資源消耗，還需要深入理解令牌使用情況及模型效能。
AI 閘道會監控傳入的提示（prompt），偵測濫用行為，例如提示注入或模型竊取。簡單來說，雖然 API 閘道對於傳統應用至關重要，但在面對 AI 特有的流量模式與需求時，可能無法完全勝任，例如：
- 成本最佳化：AI 模型的使用成本高昂，AI 閘道能提供詳細的指標與成本追蹤工具，協助企業進行更精確的成本管理決策。
- 模型多樣性：AI 應用通常使用來自不同供應商的多種模型，每個模型可能有不同的介面與協議。AI 閘道提供統一的交互介面，簡化開發流程。
- 模型版本控制與部署：AI 模型的發展速度快，AI 閘道可簡化不同模型版本的更新、回滾及 A/B 測試。
- 安全防護需求：AI 模型可能涉及機密數據，因此需要專門的安全機制。AI 閘道支援針對 AI 工作負載量身打造的 fine-grained 授權、輸入驗證與加密。
- 可觀測性：對於 AI 而言，僅監控標準 API 指標是不夠的。AI 閘道能追蹤推理時間、偏差偵測、令牌使用狀況及概念漂移等模型特定指標，提供必要的運營洞察，以便主動維護。
- 負載平衡：AI 相關的負載平衡比傳統負載平衡更為複雜，因為 AI 運算任務類型繁多，包括推理、訓練及內外部任務。此外，AI 運算通常使用昂貴的 GPU，因此確保並行運算流程的平衡與同步至關重要。
AI 閘道採購或部署前應考量的問題
在選擇 AI 解決方案時，取捨之間往往伴隨風險與挑戰。有些企業選擇僅使用單一 AI 服務，並自行管理該服務的 API，以降低整合難度。然而，這樣的做法可能導致 AI 供應商鎖定（lock-in）風險，並限制團隊在 AI 服務上實現客製化功能的能力。因此，在決定導入 AI 閘道之前，建議先思考以下幾點：
- 全面的模型支援：閘道是否能夠輕鬆處理來自內部與外部不同供應商的各種 AI 模型？
- 進階安全防護與治理：專為 AI 模型設計的安全機制是否可靠？能否執行 fine-grained 的存取控制，並偵測潛在的濫用或誤用行為？
- 成本管理與最佳化：AI 閘道是否提供細緻的使用量與成本追蹤工具？是否具備最佳化技術來有效控制 AI 運行成本？
- 深度可觀測性：該平台是否能監控推理時間、準確度、概念漂移與偏差等關鍵 AI 模型健康指標，以實現主動管理？
- 易於整合與擴展：AI 閘道能否無縫整合現有的開發與部署流程？是否具備擴展能力，以因應 AI 工作負載的成長？
API 閘道與 AI 閘道將會共存
值得注意的是，AI 閘道作為一項相對新興的技術，在短期內可能會快速發展。然而，企業不應幻想它能適用於所有情境，因為某些 AI 應用仍然可以與傳統 API 閘道良好搭配。
舉例來說，如果應用主要依賴 OpenAI API，且未進行大量調整或額外訓練，那麼該應用的需求可能與傳統應用無異。在這種情況下，導入 AI 閘道反而可能增加成本並提升營運的複雜性。
實際上，AI 應用的部署模式很可能同時使用 API 閘道與 AI 閘道，因為這兩者的用途不僅能夠共存，甚至可以互補。
目前，AI 閘道的功能已逐步整合進現有的 API 閘道產品之中。同時，許多 AI 團隊也採用了 NGINX 反向代理與 Ingress 控制器（Ingress Controller），以為 AI 應用（無論是訓練或推理）提供治理、負載平衡及交付能力。
未來，AI 閘道可能會以多種形式與規模嵌入現有的 API 閘道產品，或作為獨立方案使用。事實上，AI 閘道的出現正是 API 閘道在 AI 時代演進的必然結果，就如同 API 閘道是從反向代理技術發展而來一樣。
理解 API 閘道與 AI 閘道之間的差異，有助於企業掌握這兩者的互補性，以及如何正確地將它們應用於相關或相依的應用與微服務架構中。