AI 网关怎么选:BUZZ vs OpenRouter vs Helicone vs LiteLLM

当一个团队的生产环境里有不止一个 LLM 功能在跑,AI 网关就不再是可选项。你需要一个统一的地方来管 key、看花销、做模型路由、控隐私。真正值得讨论的不是要不要在模型调用前面加一层网关,而是用哪一家、为什么。

市场已经分化出几种清晰的形态。BUZZ 是隐私优先的透明托管网关,把四家前沿厂商收敛在一把 key 后面。OpenRouter 是宽目录的模型市场,主打跨上游路由。Helicone 是以代理形态交付的可观测性平台。LiteLLM 是开源、自托管的代理。每一种都在为不同的目标做最优化,把它们摆在一起对比时,取舍立刻就显形了。

这篇不是排名,是决策框架。先看真正决定选型的几个维度,在每个维度上诚实地给四家打分,最后给场景化的推荐。

选型的几个核心维度

很多"AI 网关对比"内容写得像功能勾选表,这恰恰掩盖了唯一重要的事:四款产品分别做了哪些底层取舍。模型覆盖广的,通常隐私上薄;可观测性深的,通常留存重;自托管代理的,token margin 上便宜,但工程时间上贵。下面这五个维度,你不可能全都拉满,只能挑其中两三个对你最关键的。

1. 模型覆盖

一把 key 能打通多少厂商和模型。这个维度在你做探索性工作时最重要:跑跨多模型评估、想接长尾或开源模型、希望团队能自由切模型不被合同绑死。如果你的生产流量已经稳定集中在两三个前沿模型,这个维度就没那么重要了。

2. 价格相对直连的差距

网关价格可以高于、等于或低于上游官方价。高于的少见,通常拿可观测性或路由能力来撑。市场型网关一般是"等于上游 + 一点 margin",换来一张统一账单。低于上游的更稀有,要靠网关自身的商业结构和量级议价能力。最诚实的比法是拿你上个月的真实流量,在每家分别算一遍账,而不是看挂牌价。

3. 隐私与数据留存

请求和响应的 body 在请求结束之后存在哪里。这个领域的默认姿态是"为了反滥用、调试或分析,保留至少一部分流量",通常带一个可选关闭开关。少数派姿态是"字节透传,从不落库"。如果你的 Prompt 里包含客户数据、被你视为 IP 的 system 提示、或者不该离开你边界的检索上下文,这个维度就是决定性的。如果是没有 PII 也没有专有内容的 C 端功能,它的权重会下降。

4. 可观测性与工具链

流量离开你的应用之后,你还能看见多少。一端是透明转发器,只给账单元数据,假定你在自己的边界内打日志。另一端是可观测性优先的代理,提供逐请求的仪表盘、Prompt 版本管理、评估、回放。取舍是直接的:可见性需要留存。同一家厂商不可能同时给你深度的 Prompt 级分析和零留存。

5. 自托管 vs 托管

谁来运行这层网关。托管服务给你的是一个 base URL 和一份账单关系。自托管代理给你的是一份 Helm chart 和一个值班排班表。自托管的合理场景:合规要求网关必须在你的 VPC 内、想用代码扩展路由策略、已经有运维团队不想再依赖一家厂商。错误场景:小团队为了"我们应该有自己的基础设施"这种感觉而选自托管,结果把本该写功能的时间全花在调代理上。

四家方案的横向对比

下面这张表是四家在每个维度上的快速定位。表下面的文字是真正有信息量的部分。

BUZZ:透明转发器,隐私优先

BUZZ 是有意把范围收窄设计的。一把 API key 通到 Claude、GPT、Gemini、Grok。网关字节级转发请求和响应,Prompt Cache、Tool Use、流式、Extended Thinking 全部支持 —— 因为这些都是上游协议本身的特性,透明转发器按定义就保留它们。Body 不写日志、不入库、不在用户之间缓存做回放、不转发到第三方分析或内容审核管线。每一次请求只留下账单元数据:模型名、token 数、时间戳、user ID、状态、延迟。

BUZZ 把完整的 价格接口开放成机器可读的公开资源,带能力描述的模型目录放在另一个独立接口,你都可以直接接进自己的 provisioning 逻辑。BUZZ 在它支持的几家上游上,挂牌价低于上游官方价。

诚实地讲讲 trade-off:BUZZ 不打算做市场。如果你想评测十个冷门开源模型、或者路由到某个小众厂商,BUZZ 不适合你。它适合的是已经把工作负载收敛到主流前沿厂商的团队 —— 想要一把 key 在前面挡着、关心透明转发和更紧的隐私姿态远超过关心目录大小。

# BUZZ + Anthropic SDK
from anthropic import Anthropic
client = Anthropic(
    base_url="https://buzzai.cc",
    api_key="sk-buzz-..."
)

# 同一把 key,OpenAI SDK
from openai import OpenAI
client = OpenAI(
    base_url="https://buzzai.cc/v1",
    api_key="sk-buzz-..."
)

OpenRouter:模型市场,目录最广

OpenRouter 的核心标签是"广"。目录覆盖一百多个模型,横跨众多厂商,包括前沿闭源、各家推理服务托管的开源权重、长尾的实验性发布。一把 key 通吃,跨上游 fallback 和路由规则也支持,比如你可以写"优先这家,被限流就走那家"。

价格通常贴近上游官方价加少量 margin,加上 credits 计费,可以在不同模型上分配预算而不用维护一堆独立的厂商账户。对探索型工作负载这是真实的优势 —— 跑跨二十个模型的评估,合同关系从二十份压缩到一份。

留存方面,OpenRouter 文档里写明默认保留一部分流量做滥用和内容监控,在账户设置里有显式的 opt-out。想要 OpenRouter 的目录但更紧的隐私姿态,务必显式去切换设置并在账户配置里二次确认。这对一家宽目录市场型网关来说是合理的运营姿态:覆盖广就意味着上游约束多,需要可执行的合规手段。

当你的优先级是"一把 key 通到尽可能多的模型"、并且市场型网关默认的留存策略(可配置)能接受时,OpenRouter 是最合适的选择。

Helicone:可观测性代理

Helicone 是另一个产品类别。最准确的理解是:这是一个用代理形态交付的 LLM 可观测性平台。仪表盘才是产品本身 —— 逐请求日志、Prompt 版本管理、评估、自定义属性、用户级分析、延迟与成本拆解。如果你曾经希望自己的 LLM 流量看起来更像一个 Datadog 仪表盘,Helicone 就是市面上最接近这个目标的方案。

这种价值按设计依赖留存。Helicone 把流经它的请求和响应记录下来,这样之后才能展示给你看。会选 Helicone 的团队,通常正是冲着这种可见性来的。它围绕 Prompt 管理、打分评估和流量内省搭的工具,对那些主要工程难题是"我们看不出 Prompt 在生产里到底发生了什么"的团队,是真的有用。

取舍正好是 BUZZ 的反面。当可观测性是主导问题、把流量交给厂商以便厂商展示给你看是一种特性而不是风险时,Helicone 是合适的。当"最小化 Prompt 落点"是硬约束时,Helicone 不合适。

LiteLLM:开源自托管代理

LiteLLM 是开源选项。你自己部署、在环境里配上各家上游的 credentials、对外暴露一个统一的 OpenAI 兼容接口。代码库活跃,上游列表很全,你也可以在 Python 里扩展路由层,内置策略覆盖不到的情况自己写。

它的优点是真实存在的。每 token 成本就是上游收的那一份,没有代理 margin。合规团队要求网关跑在自家 VPC 内的,自托管刚好满足。Cache、脱敏、模型选择、路由的自定义 hook 想加就加,不用提 feature request 等厂商。配置格式之外没有任何 vendor lock-in。

代价是运维。要有人去部署它、扩容它、加固它、升级它、监控它,出问题时值班。对一个已有平台工程能力的团队,这是可以接受的开销。对一个想交付产品功能的小团队,每一小时花在调自托管代理上的时间,就是没花在应用本身上的时间。当约束(合规、自定义、超大量级下的成本)真正需要自托管时,LiteLLM 是对的。当团队是出于"我们应该自己跑基础设施"这种感觉而选它时,通常是错的。

什么场景挑哪一家

上面的维度和厂商分析是通用的。下面这几个场景是大家实际会问的具体情况。

迁移时要考虑什么

切网关比切数据库轻很多,但也不是免费的。摩擦集中在三处。

协议兼容

当前网关如果原样转发上游 API(Anthropic 的 /v1/messages、OpenAI 的 /v1/chat/completions),改 base URL 就是一行的事。如果引入了自家请求 schema、响应 wrapper 或专有 feature flag,每一处用了非标字段的调用点都会变成迁移项。选型时要倾向于和上游协议保持一致的网关,正是为了这一点。

# 之前:直连上游
client = Anthropic(api_key="sk-ant-...")

# 之后:走 BUZZ,只改 base URL 和 key
client = Anthropic(
    base_url="https://buzzai.cc",
    api_key="sk-buzz-..."
)

账单对账

新旧网关的账单格式不会一样。计划一个一个月的并行期,把一小部分流量切到新网关,逐项对比,确认逐模型的总账能对上。这样能抓出 cache token 计费方式差异、tool 调用计费差异、限流触发的上游 fallback 改变了实际单价等边缘情况。

合规与合同

如果你的数据处理协议(DPA)里点名了旧厂商,换网关意味着要签新的 DPA,可能还要给客户更新 sub-processor 列表。换成透明零留存的转发器时,这份变更说明可以写得比之前短得多,因为数据流路径更简单。无论如何,法务流程要预留时间,不只是技术流程。

所以,你应该选哪个

四个候选都是好产品,只是为不同优先级做的最优化。最短的版本:

• 看重隐私 + 主流模型上的更低成本,且要托管:BUZZ。
• 看重一把 key 接最多模型:OpenRouter。
• 看重 Prompt 级深度可观测性:Helicone。
• 看重自托管掌控:LiteLLM。

谁告诉你某一家网关"全方位最好",谁就是在卖东西。合适的网关是它的架构取舍刚好和你真实的约束对齐。如果你的约束是隐私、透明转发、跨前沿厂商支持 Prompt Cache 和 Tool Use、价格低于官方挂牌,BUZZ 就是为这个负载造的。如果不是,另外三家中会有更合适的,这也没问题。

常见问题

结语

AI 网关是架构里很小的一块,但它会吸收掉一大堆决策。模型策略、厂商管理、隐私姿态、可观测性、部署归属,全部都隐式编码在你最终选了哪家这件事里。最干净的思考方式是:先把你真正在意的两三个维度写下来,然后挑那个就是为这两三个维度设计出来的网关。强迫一个网关变成它本来不是的样子,比一开始就选对一个要贵得多。

如果你的优先级是透明转发、body 零留存、一把 key 通主流前沿厂商、价格低于官方挂牌,BUZZ 就是为这种负载造的。如果不是,另外三家中会有更合适的。无论选哪家,基于你能讲清楚的取舍来决定,而不是基于一个想包揽一切的营销页。