AI 网关:LiteLLM、Portkey、Kong AI Gateway 与 Bifrost

AI 网关:LiteLLM、Portkey、Kong AI Gateway 与 Bifrost

本节摘要:网关位于你的应用与模型厂商之间。核心特性是厂商路由、回落、重试、限流、密钥引用、可观测性、护栏。2026 年市场分裂:LiteLLM 是 MIT 开源,100+ 厂商、OpenAI 兼容,但在约 2000 RPS 附近崩(8 GB 内存,已发基准里级联失败);最适合 Python、<500 RPS、开发/原型。Portkey 是控制面定位(护栏、PII 脱敏、越狱检测、审计轨迹),2026 年 3 月转 Apache 2.0 开源,20~40 ms 延迟开销,49 美元/月生产层。Kong AI Gateway 基于 Kong Gateway——Kong 自家基准在同样 12 CPU 上:比 Portkey 快 228%、比 LiteLLM 快 859%;定价 100 美元/模型/月(Plus 层最多 5 个);已在 Kong 上的企业首选。Bifrost(Maxim AI)——带可配退避的自动重试,OpenAI 429 时回落到 Anthropic 是经典配方。Cloudflare / Vercel AI Gateways——托管、零运维、基础重试。数据驻留驱动自托管决策;Portkey 与 Kong 处于中间(开源 + 可选托管)。

对应原课程:Phase 17 · Lesson 19 · 19-ai-gateways(原英文 phases/17-infrastructure-and-production/19-ai-gateways/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 列出网关的六七项核心特性(路由、回落、重试、限流、密钥、可观测、护栏)。
2. 把四个 2026 网关(LiteLLM、Portkey、Kong AI、Bifrost)映射到规模上限与用例。
3. 引用 Kong 基准(比 Portkey 快 228%、比 LiteLLM 快 859%)并解释为何对 >500 RPS 重要。
4. 给定数据驻留与运维预算,在自托管与托管间选型。

一、问题与直觉

你的产品调 OpenAI、Anthropic、自托管 Llama。每个厂商有不同 SDK、错误模型、限流、鉴权方案。你要故障转移(OpenAI 429 时试 Anthropic)、单一凭据存储、统一可观测、按租户限流。

在应用层重造这些,把每个服务与每个厂商耦合。网关层把它收进一个进程、一套 API(通常 OpenAI 兼容),扇出到各厂商。

二、核心概念

六七项核心特性

1. 厂商路由 —— OpenAI、Anthropic、Gemini、自托管等藏在一套 API 后。
2. 回落 —— 429、5xx 或质量失败时,在别处重试。
3. 重试 —— 指数退避,有界尝试。
4. 限流 —— 按租户、按 key、按模型。
5. 密钥引用 —— 运行时从 vault 拉凭据(永不进应用)。
6. 可观测性 —— OTel + GenAI 属性(第 13 节)+ 成本归因。
7. 护栏 —— PII 脱敏、越狱检测、允许话题过滤。

LiteLLM —— MIT 开源、Python

• 100+ 厂商,OpenAI 兼容,路由配置、回落、基础可观测。
• Kong 基准里约 2000 RPS 崩;8 GB 内存,持续负载下级联失败。
• 最适:Python 应用、<500 RPS、开发/预发网关、实验性路由。
• 成本:开源 0 美元;有云免费层。

Portkey —— 控制面定位

• 2026 年 3 月起 Apache 2.0 开源。护栏、PII 脱敏、越狱检测、审计轨迹。
• 每请求 20~40 ms 延迟开销。
• 生产层 49 美元/月,含留存 + SLA。
• 最适:需要护栏 + 可观测打包的受监管行业。

Kong AI Gateway —— 规模牌

• 基于 Kong Gateway(成熟 API 网关产品,lua+OpenResty)。
• Kong 自家基准在 12-CPU 等效上:比 Portkey 快 228%、比 LiteLLM 快 859%。
• 定价:100 美元/模型/月,Plus 层最多 5 个。
• 最适:已在 Kong 上;>1000 RPS;愿许可。

Bifrost(Maxim AI)

• 带可配退避的自动重试。
• OpenAI 429 时回落到 Anthropic 是经典配方。
• 较新入场;商业。

Cloudflare AI Gateway / Vercel AI Gateway

• 托管、零运维。基础重试与可观测。
• 最适:Cloudflare/Vercel 上的边缘服务 JavaScript 应用。
• 在护栏与限流上比 Kong/Portkey 弱。

自托管 vs 托管

数据驻留是强制函数。医疗与金融默认自托管(LiteLLM 或 Portkey 开源或 Kong)。消费产品默认托管(Cloudflare AI Gateway)或中间层(Portkey 托管)。混合:受监管租户自托管,其他托管。

延迟预算

• LiteLLM:典型 5~15 ms 开销。
• Portkey:20~40 ms 开销。
• Kong:3~8 ms 开销。
• Cloudflare/Vercel:1~3 ms 开销(边缘优势)。

网关延迟直接加到 TTFT。TTFT P99 < 100 ms SLA → Kong 或 Cloudflare;P99 < 500 ms → 任一。

限流语义要紧

简单令牌桶到中等规模够用。多租户要滑动窗口 + 突发余量 + 按租户分层。LiteLLM 出令牌桶;Kong 出滑动窗口;Portkey 出分层。

网关 + 可观测 + 路由组合

第 13(可观测)+ 16(模型路由)+ 19(网关)是生产里同一层。选一个覆盖三者的工具,或仔细接线:多数 2026 部署把 Helicone(可观测)或 Portkey(护栏)与 Kong(规模)组合分担。

你该记住的数字

• LiteLLM:约 2000 RPS 崩,8 GB 内存。
• Portkey:20~40 ms 开销;2026 年 3 月起 Apache 2.0。
• Kong:比 Portkey 快 228%、比 LiteLLM 快 859%。
• Kong 定价:100 美元/模型/月,Plus 层最多 5 个。
• Cloudflare/Vercel:边缘 1~3 ms 开销。

三、从零实现:网关路由模拟器

原课程 code/main.py 模拟带跨三厂商回落的网关路由,注入 429/5xx,报告延迟、重试率、回落命中率。下面给最小可读的回落命中率骨架。

def fallback_hit_rate(primary_error_rate, fallback_error_rate,
                      num_providers=3):
    """估算多厂商回落链的用户可见失败率。

    假设:OpenAI → Anthropic → 自托管 顺序回落,各独立错误率。
    """
    # 用户可见失败 = 所有厂商都失败
    rates = [primary_error_rate, fallback_error_rate]
    if num_providers >= 3:
        rates.append(0.01)  # 自托管假设 1% 错误
    visible_failure = 1.0
    for r in rates[:num_providers]:
        visible_failure *= r
    # 回落命中率 = 主厂商失败率(触发了回落)
    primary_fail = rates[0]
    return round(primary_fail, 4), round(visible_failure, 6)


# 案例:OpenAI 5% 错误,Anthropic 3% 错误,自托管 1%
hit, visible = fallback_hit_rate(0.05, 0.03, num_providers=3)
print(f"回落触发率 {hit*100:.1f}%, 用户可见失败率 {visible*100:.4f}%")
# 三厂商回落把 5% 失败压到 0.0015% 可见——这就是网关的价值
​

💡 网关的回落不是「锦上添花」,是把单厂商的 5% 失败压到多厂商的 0.0015% 可见。三个独立厂商同时挂的概率,比单厂商低几个数量级。

四、框架对比:四网关横向对照

心法:低 RPS + Python → LiteLLM;受监管 + 护栏 → Portkey;高 RPS + 企业 → Kong;边缘 JS → Cloudflare/Vercel。

五、可复用产物

本节产出 outputs/skill-gateway-picker.md(原课程目录)。给定规模、运维姿态、合规、延迟预算,它选网关:

1. 规模判定:RPS 上限与延迟预算筛选。
2. 合规判定:数据驻留 → 自托管;护栏需求 → Portkey。
3. 组合建议:网关 + 可观测 + 路由的分担拓扑。
4. 限流策略:令牌桶 vs 滑动窗口 vs 分层,依多租户复杂度。

六、练习

1. 跑通模拟器:运行 code/main.py。配 OpenAI→Anthropic→自托管回落。在 5% 厂商错误率下,预期命中率多少?

2. 延迟预算:你的 SLA 是 300 ms 基线上 TTFT P99 < 200 ms。哪些网关在预算内?

3. 医疗客户:某医疗客户要自托管 + PII 脱敏 + 审计。选 Portkey 开源还是 Kong?

4. 迁移点:对比 LiteLLM vs Kong,在什么 RPS 上限该团队迁移?

5. 多租户限流:为多租户 SaaS(免费层、试用层、付费层)设计限流策略。令牌桶还是滑动窗口?

本节要点回顾

1. 网关是应用与厂商间的一层:路由、回落、重试、限流、密钥、可观测、护栏。
2. LiteLLM 是 MIT 开源 Python:100+ 厂商,但约 2000 RPS 崩,<500 RPS 最适。
3. Portkey 是控制面定位:2026-03 起 Apache 2.0,护栏 + PII 脱敏 + 审计,20~40 ms 开销。
4. Kong AI 是规模牌:比 Portkey 快 228%、比 LiteLLM 快 859%,>1000 RPS 企业首选。
5. Bifrost 是自动重试配方:OpenAI 429 → Anthropic 回落。
6. Cloudflare/Vercel 是托管边缘:1~3 ms 开销,JS 边缘应用零运维。
7. 数据驻留驱动自托管:医疗金融默认自托管,消费默认托管。
8. 网关延迟直接加 TTFT:P99 <100 ms 选 Kong/Cloudflare,<500 ms 任一。
9. 限流语义要紧:令牌桶(简单)→ 滑动窗口(精确)→ 分层(多租户)。
10. 网关 + 可观测 + 路由是同层:Helicone(观测)+ Portkey(护栏)+ Kong(规模)分担是 2026 常见模式。

下一节,我们看 LLM 上线最难的部分——影子流量、金丝雀、渐进部署:如何在没有单元测试、失败模式弥散、信号延迟的情况下安全地把新模型推到生产。