AI閘道器基準測試：GoModel vs LiteLLM vs Portkey vs Bifrost
本文對比了四種AI閘道器在請求路徑上的執行時開銷，包括延遲、吞吐量、記憶體、CPU、冷啟動時間和映象大小。測試結果顯示，GoModel在幾乎所有指標上表現最優，而LiteLLM則因資源消耗巨大而成為短板。文章還討論了閘道器的開源中立性和對本地模型部署的影響。
2026年6月26日，Jakub A. Wasek發表了一篇關於AI閘道器基準測試的詳細文章。文章指出，大多數AI閘道器的比較忽略了執行時開銷這一關鍵因素。作者最初基於LiteLLM構建自己的創業專案，但將其部署在熱路徑上後，發現其資源消耗過高。於是，他開發了GoModel——一個使用Go語言編寫的輕量級開源AI閘道器，並承諾進行可復現的基準測試。
基準測試在AWS c7i.large例項上進行，使用Docker部署，各閘道器連線相同的模擬後端以排除網路抖動。測試涵蓋六種工作負載（包括聊天補全和響應API的流式與非流式模式），每種閘道器執行8000次請求，併發數為10。測試指標包括中位延遲、P99延遲、吞吐量、峰值記憶體、請求效率、冷啟動時間和Docker映象大小。
結果如下：GoModel表現最佳，中位延遲僅1.8毫秒，P99延遲6.9毫秒，吞吐量4900請求/秒，峰值記憶體37MB，冷啟動只需0.56秒，映象壓縮後僅16MB。Bifrost緊隨其後，中位延遲2.5毫秒，P99延遲18.3毫秒，吞吐量3100請求/秒，記憶體143MB，冷啟動7.1秒。Portkey中位延遲9.7毫秒，P99延遲30.5毫秒，吞吐量950請求/秒，記憶體112MB，冷啟動1.1秒。LiteLLM表現最差，中位延遲30.6毫秒，P99延遲39.3毫秒，吞吐量僅324請求/秒，記憶體高達2.3GB，冷啟動需要25.5秒，映象壓縮後372MB。
作者強調，這些數字決定了閘道器能否部署在目標環境中。例如，本地模型（如vLLM、Ollama）的響應時間較短，閘道器的開銷會顯著影響使用者體驗。輕量級閘道器適合作為邊車或執行在小型虛擬機器、無伺服器和邊緣裝置上。
文章還討論了開源和中立性問題。Bifrost由Maxim AI開發，與其評估平臺緊密整合；Portkey的儲存、儀表板等功能位於閉源託管層；LiteLLM的企業版需要商業許可。GoModel目前完全開源，核心閘道器保持獨立。
基準測試的完整程式碼和執行指令碼已公開，讀者可透過“./run.sh”在AWS上覆現（需自付費用）。作者最後總結，他建立GoModel並非為了增加另一個AI閘道器，而是因為現有的閘道器在熱路徑上成為了問題本身。