AI 博客

LiteLLM、Portkey、Helicone 与 OpenRouter:在请求路径上,还是在旁边

决定这件事的是两个二选一的问题,而不是任何功能清单:网关在不在请求路径上,以及谁持有厂商凭证。网关所做的一切会改变请求的事情——缓存、故障转移、限流、密钥轮换——都需要第一个条件;而你的爆炸半径与账单则全都由第二个条件推导出来。对智能体而言,这两个答案都要乘上步数——这正是为什么一个对聊天应用来说还行的选择,对一个循环来说可能在结构上就是错的。

作者 智能体 AI 维基 22 分钟读完

你能读到的每一篇网关对比都是一张功能表,而这些功能表几乎可以互换,因为这些产品早在几年前就收敛了。真正决定这件事的是两个二选一的问题:网关在不在请求路径之内,以及谁持有厂商凭证。第一个问题给它们能为你做的事情设了一个硬天花板——站在路径旁边,任何改变请求的事都做不了;第二个问题决定网关挂掉那天会发生什么。而对智能体来说,这两个答案都要乘上步数——一个对聊天应用来说还行的选择,就是这样变成对循环而言结构上错误的。

先看全貌

四款产品占据的位置确实各不相同,下面按它们自己的文档口径来描述。

产品形态是否持有你的厂商密钥?入门条款
LiteLLM你自己运行的开源代理;一个 OpenAI 兼容 API 覆盖 100+ 模型否——你自己持有自托管免费;另有付费企业版
Portkey生产级控制平面;托管或自托管否——你自己持有免费额度约每月 10,000 条日志
Helicone可观测性优先;在代理与「路径外异步记录」之间显式二选一否——你自己持有免费额度约每月 10,000 次请求
OpenRouter托管式市场;一把密钥、200+ 模型、由它来路由是,除非你用 BYOK信用卡充值收 5.5% 手续费(加密货币 5%),每笔最低 0.80 美元
Where each gateway leans hardest Four rows by four columns. LiteLLM is strong on self-hosting and provider breadth, medium on in-path control, weak on managed operations. Portkey is strong on in-path control and managed operations, medium on self-hosting and provider breadth. Helicone is strong on observability depth and offers a deliberate off-path mode, medium on in-path control and self-hosting. OpenRouter is strong on provider breadth and managed operations, weak on self-hosting and on holding your own credential. Where each one leans hardest Self-host it In-path control Provider breadth Zero-ops LiteLLM Strong Medium Strong Weak Portkey Medium Strong Medium Strong Helicone Medium Optional Medium Strong OpenRouter Weak Medium Strong Strong Strong Medium / optional Weak or not offered "Optional" marks Helicone's documented choice between a proxy and off-path async logging.
这是四种不同的下注,而不是对同一种下注的四个排名。

OpenRouter 的收费结构值得澄清一句,因为它经常被描述错:它并不在厂商的 token 价格上加价。它收的是资金进入系统时的手续费——信用卡充值 5.5%、加密货币 5%,每笔最低 0.80 美元——外加对超出每月免费额度的 BYOK 流量收 5%;近期的资料对这个免费额度的说法有两种,或是每月前一百万次 BYOK 请求,或是约 25,000 美元的挂牌价推理量,企业方案下这一额度会大幅提高。建模之前请核对当时的条款:结构是稳定的,阈值会变。

问题一:在路径上,还是在旁边

A gateway in the request path compared with one beside it Top: the in-path deployment sends the agent's call through the gateway to the provider, so the gateway can cache, fall back, rate limit and rotate keys, but it is also a dependency whose outage stops the agent. Bottom: the beside-the-path deployment calls the provider directly and ships a copy of the exchange to the observability service afterwards, so an outage costs only telemetry, but nothing can be changed in flight. In the path — proxy Agent loop Gateway Model provider Can change the request in flight: semantic and exact caching · retry and provider fallback · rate limits and spend caps · key issuance and rotation · guardrails and redaction · routing. Costs: one more hop on every step, and an availability dependency — if it is down, the agent is down unless you coded the bypass yourself. Beside the path — async logging Agent loop Model provider Observability service copy of the exchange, after the fact Outage costs telemetry only. Nothing can be changed in flight.
Helicone 把这件事记录成一个由你来做的选择。这是这个品类里最有用的一种表述方式。

Helicone 自己的文档把两种接入方式并排放在一起——代理 vs 异步——并且诚实地说明了这笔交易:异步把日志记录留在关键路径之外,因此厂商侧的宕机或网络问题不会影响你的应用;但异步「无法提供与代理相同的那套工具」,因为正是代理坐在边缘、充当请求的守门人。缓存、限流、API 密钥管理、威胁检测与内容审核,全都住在那条线的代理这一侧。

这套表述对四款产品都成立,值得当成一条规则说出来:任何会改变请求的事情都要求你处在请求路径之内,而处在请求路径之内的一切都是你必须撑住的依赖。没有哪种配置能让你两头都占。团队常常是这样吃到苦头的:为了可观测性买了一个网关,因为快速上手路径就是代理模式所以照着部署了,于是把一家创业公司的可用性放到了自己每一次模型调用的前面。

你想要哪一侧,取决于你到底在买什么:

  • 买的是可见性?走路径外。追踪、成本归因与延迟直方图在异步记录器上都能正常工作,而你保住了一个自己早已熟悉的故障域。参见追踪与可观测性
  • 买的是控制?那你就在路径上,因此要为此留预算:健康检查、一条写下来的旁路、以及对「网关正在返回 503,正在跑的智能体会怎样」这个问题经过演练的答案。优雅降级是那种要提前读、而不是事后读的页面。
  • 两个都要?那就跑代理,但把旁路做成一条一等公民的代码路径,并按固定节奏演练它,而不是把它写成运维手册里的一句注释。

问题二:谁持有厂商凭证

Three answers to who holds the provider credential Three columns. You hold it, on a gateway you run: the provider account and rate limits are yours, and prompts stay inside your perimeter. You hold it, on a managed gateway using bring-your-own-key: the account is yours but the traffic and often a fee pass through the vendor. The gateway holds it: you buy credits, the vendor owns the provider relationship, and your fallback when it is down is an account you do not have. Who holds the provider credential You, on your own gateway LiteLLM, Helicone or Portkey, self-hosted. Provider account and rate limits are yours. Prompts stay inside your perimeter. You operate it. You, via bring-your-own-key Managed control plane, your keys behind it. Account stays yours; traffic and often a fee pass through the vendor. Nothing to operate. The gateway holds it You buy credits; the vendor owns the provider relationship. Fastest to start, widest catalogue. Your fallback is an account you do not have. The column you pick decides your outage story before it decides anything about features.
选哪一栏,在决定任何功能之前,先决定了你的宕机剧本。

凭证看起来像一个配置细节,行为上却是一项架构承诺。谁持有它,谁就拥有与厂商的关系:限流额度、配额提升、滥用申诉的升级通道、企业协议,以及在中间那一层不工作时直接调用厂商的能力。

拿出事那天来比较这三种位置。如果你自托管 LiteLLM 或 Portkey,而自己的网关倒了,你把 SDK 指回厂商,失去的是路由策略——这是一次事故,不是一次宕机。如果你用的是带 BYOK 的托管控制平面,情况一样,只是多打一个电话。如果你走的是 OpenRouter 的额度模式而 OpenRouter 不可用,你的兜底是一个你并不拥有的厂商账户:没有配额历史、没有谈下来的额度;开户只要几分钟,但让限流额度变得够用要几天。

这不是反对 OpenRouter 的论据——它确实是「用一把密钥触达两百多个模型」最快的方式,对一大类工作来说也是正确答案。这是在主张诚实地为这份依赖定价:如果你的智能体在做任何业务要仰仗的事,就在最重要的两个模型上留一个休眠的直连账户。

凭证还决定了你的提示词去了哪里。自托管代理把它们留在你的边界之内,这正是受监管团队伸手去拿 LiteLLM 的全部理由;而托管网关在构造上就会看到它们。这是一个数据驻留与主权问题,它没有技术上的绕行方案——只有一个部署选择。

智能体的乘数效应

上面这些对聊天应用同样适用。智能体改变的是量级,而在三个地方,它改变得足以把结论翻过来。

延迟会累加,而你感受到的是尾部

一轮聊天只有一次模型调用,所以多出 30 毫秒的代理跳数,在两秒的生成面前看不见。一个二十五步的智能体任务要付二十五次——更要紧的是,要承受网关的 p99 二十五次。如果任何单步失败都会毁掉整个任务,那么每次调用 1% 的失败率会带来大约 22% 的任务失败率。网关拿来宣传的是中位延迟;而决定你的智能体能不能跑完的,是它在你自己的并发压力下的尾部行为,且只有压测能告诉你。

百分比是一笔按步征收的税

那些按单次请求看起来很小的费率,是按模型调用征收的,而不是按用户动作。对智能体来说,相关的单位是每个成功完成任务的成本,而一个任务是几十次调用。这与我们此前在 Stripe 买下的是计量层而不是路由层 里给出的论证是同一个形状:谁坐在一个智能体的请求路径上,谁就是在按一个循环的步数收费,而那个步数你并不完全控制。

要守住的是厂商侧的提示词缓存

这是那种真花钱、却不产生任何告警的陷阱。智能体每一步都会重发一段不断变长的对话记录,所以厂商侧的提示词缓存常常是账单上最大的那个抓手——而它依赖于一个完全稳定的前缀和正确的 cache-control 处理。一个会归一化请求头、重排系统内容、注入自己前言,或者把同一段对话在多个厂商之间做负载均衡的网关,会悄悄拉低你的缓存命中率。什么都不会报错。账单翻上几倍,归因写着「用量增加」。

在下决心之前直接测一遍:把同一个二十五步的任务分别经过网关和绕过网关各跑一次,比较厂商报告的缓存命中 token 数。如果网关让你损失了缓存命中,网关层面的任何缓存都补不回来。

什么情况选哪个

处境原因
提示词不能离开你的边界自托管 LiteLLM开源、一个 OpenAI 兼容接口覆盖 100+ 模型,而且每一把凭证都在你手里。
想要路径内的控制,但不想自己运维Portkey专为代理位置打造的托管控制平面:缓存、护栏、路由与治理集中在一处。
想要可见性,但不想新增故障域Helicone 的异步模式它是唯一把「路径外」写成一等接入方式、而不是降级方案的产品。
要目录广度、要最少的搭建OpenRouter一把密钥触达 200+ 模型、零基础设施;把充值手续费与「缺一个直连账户」一并计入成本。
要按租户与功能做成本归因四者皆可,但要在路径内网关是唯一能看到每一次调用的地方;参见成本归因与预算

还有一种值得明确点名的组合,因为不少成熟的智能体团队最后跑的就是它:生产路径上放一个自托管代理,那些「不该增加依赖」的分析走异步记录器,再留一把托管市场的密钥用于评测工作——在那里,五分钟内够到一个新模型,比省下那笔手续费更值钱。

常见问题

OpenRouter 会在 token 价格上加价吗?

不会。它收的是资金进入系统时的手续费——信用卡 5.5%、加密货币 5%,每笔最低 0.80 美元——以及对超出每月免费额度的 BYOK 流量收 5%。厂商的 token 价格是透传的。

不把网关放进请求路径,能拿到缓存与故障转移吗?

不能。两者都要求在请求抵达厂商之前改动它,而这只有在路径之内才做得到。路径外的接入可以观测、可以做成本归因,但不能介入。

网关会不会破坏厂商侧的提示词缓存?

会,而且它不会告诉你。任何改动稳定前缀的行为——请求头归一化、注入的系统内容、把一段对话跨厂商做负载均衡——都会拉低命中率。下决心之前,分别测量经过网关与绕过网关时的缓存命中 token 数。

自托管 LiteLLM 真的免费吗?

软件是免费的。运维成本不是:你是在每一次模型调用的关键路径上运行一个代理,这意味着容量规划、升级,以及一个如今多背了一项一级依赖的值班轮值。

小团队起步该选哪一个?

从路径外的异步记录开始,先在不新增依赖的前提下摸清自己的流量;只有当你有了一个路径外满足不了的具体需求——一条故障转移策略、一个开销上限、一项密钥轮换要求——再挪进路径里。

延伸阅读

本站相关:

项目来源: