開源 AI Gateway 全面對比：OmniRoute vs Alephant vs Portkey

每次有新 LLM 推出，團隊就要改 code、換 API key、重寫 fallback 邏輯。呢個 cycle 重複咗兩年，但大部份人仍然未用上 AI Gateway。原因唔係冇好嘅工具，而係選擇太多，個個都話自己係「標準層」。我將三個開源 AI Gateway 由底層技術到 routing 策略到生產環境表現逐項拆開，等你哋可以直接跳到最啱自己團隊嗰個。

Portkey AI Gateway：生態圈大到唔需要解釋

Portkey 係目前無可爭議嘅領先者。GitHub 接近 12,000 粒星，每日處理超過 100 億 tokens，支援 1,600+ 模型橫跨 45+ 供應商。呢啲數字唔係 marketing bullshit——當你嘅 gateway 要同 200 間企業嘅 production traffic 打交道，每一個 edge case 都被逼修好。

佢嘅核心優勢係完整度。一般 gateway 做到 routing 同 caching 已經收貨，Portkey 仲包咗 50+ guardrails、PII redaction、semantic caching、load balancing、automatic retries，甚至有個獨立嘅 MCP Gateway 比你管理 MCP servers。Install 就一行 npx @portkey-ai/gateway，122KB footprint 做到 <1ms latency，呢個 performance 對 production 嚟講係 serious。

但 Portkey 唔係冇痛點。佢用 TypeScript / Node.js 寫，如果你嘅 infra 行緊 Rust 或者 Go stack，多一個 Node runtime 就多一個攻擊面。進階功能（prompt management、advanced analytics）鎖喺 hosted version，self-host 嘅社群版功能齊但唔係全部開源。仲有，佢嘅 routing strategy 係透過 config 實現，冇 Alephant 嗰種 agent-aware 嘅 routing policy——呢點對 agentic workflow 嚟講係明顯差距。

對大部分團隊嚟講，Portkey 係 safest bet。你唔會因為揀 Portkey 而被 fired。但你會因為冇理解自己嘅 routing pattern 而用錯佢嘅 config model。

Alephant Agent Gateway：Rust 性能 + Agent-First 設計

Alephant 係三者當中最有趣嘅 newcomer。83 粒星、2026 年 5 月先開源，但佢嘅設計哲學直接針對 Portkey 嘅 blindspot：agentic AI 產品嘅 routing 唔同於傳統 LLM proxy。

傳統 gateway 嘅 routing 係 stateless 嘅：request in, model out。Alephant 嘅 routing 係 agent-aware——佢理解你嘅 request 屬於邊個 agent、需要咩 context、邊個 provider 嘅 tool-calling 能力最好。呢個差異喺 production 好明顯：當你嘅 agent 需要係 GPT-4 嘅 tool calling 同 Claude 嘅長 context 之間切換時，Portkey 要你寫 config rules，Alephant 直接喺 policy router 層面處理。

技術架構上 Alephant 用 Rust 寫（94.8% Rust），支援 50+ providers、320+ 模型。Caching 層有 KV cache 加 Qdrant 做 semantic cache，observability 有原生 traces 同 metrics。佢最破格嘅功能係 x402 / MPP payment rails——你可以將 agent capability publish 做 paid endpoint，呢個對想做 AI API marketplace 嘅團隊嚟講係 killer feature。

代價係成熟度。Beta v0.2.0，文件未有 Portkey 咁完整，社群仲好細。如果你係 early adopter 類型，Alephant 值得而家就 try；如果你要 production-ready 嘅 support，可能要等多幾個月。

OmniRoute：四種策略嘅輕量 proxy

OmniRoute 係光譜另一端。佢唔係 platform，係一個好專注嘅 routing proxy：四種策略（cheapest、fastest、best-quality、round-robin）、四個 provider（OpenAI、Anthropic、Gemini、Ollama）、YAML config。就係咁多。

呢種 minimalism 唔係缺點，而係取捨。如果你嘅團隊得三個人、product 仲喺 MVP 階段、production traffic 每日幾千個 request，Portkey 同 Alephant 嘅 complexity 係 overkill。OmniRoute 嘅 OpenAI-compatible API 代表你隨時可以 swap 出去，唔會有 vendor lock-in。

缺點好明顯：冇 caching、冇 guardrails、冇 observability dashboard、冇 agent support。GitHub 接近零 stars 意味你唔好 expect 任何社群支援。呢個 tool 適合嘅場景好窄——但喺呢個窄場景入面，佢做得好好。

點揀：Bottleneck 決定一切

揀 AI Gateway 唔係 feature count 比賽，係 bottleneck 匹配。你條 team 嘅 bottleneck 喺邊？

如果 bottleneck 係「寫咗好多 provider-specific code，每次轉 model 要改 business logic」——Portkey 嘅 1,600+ model coverage 同 unified API 直接解決呢個問題。你唔需要再為每個 provider 寫 adapter。

如果 bottleneck 係「agent 之間嘅 routing 愈嚟愈複雜，stateless proxy handle 唔到」——Alephant 嘅 agent-first architecture 值得而家就投入。用 Rust 寫嘅 performance 對 latency-sensitive 嘅 agent orchestration 係 bonus。

如果 bottleneck 係「我只係想喺 MVP 階段快速試幾個 model，唔想俾 overhead 拖慢 ship speed」——OmniRoute 嘅輕量設計係正確答案。四個 routing strategy 加 auto-fallback 已經 cover 到 90% 嘅早期需求。

最後一個 advice：唔好過早抽象化。你而家冇 AI Gateway 都活得好好，亂咁加一層唔會令你嘅 product 更好。先理解你嘅 traffic pattern，再揀 gateway。Portkey 係最安全，Alephant 係最有野心，OmniRoute 係最誠實。揀適合你而家呢刻嘅，唔係適合你想像中嗰個 future。