LiteLLM vs Portkey：AI 网关的路由、预算和部署成本

只有一个应用、一个模型供应商时，直接调用供应商 SDK 往往就够了。接入网关的动机，通常从第二个供应商、第二个团队开始：密钥不能到处复制，某个供应商限流时要有备用路径，月底还得说清楚每个应用花了多少钱。

LiteLLM 和 Portkey 都能承担模型调用入口。我的判断是，团队准备自己管理路由和运行环境，LiteLLM 很适合作为起点；如果更急着把多个团队的凭证、权限和预算统一起来，Portkey 商业平台能减少一部分管理系统建设。Portkey 也有开源 Gateway，单独需要请求转发和路由时，它同样在候选范围内。

差价要按这个范围来算。开源网关已经具备不少功能，企业管理、托管运维和支持又是另外的采购内容。

观测云｜2026-10-09 更新。依据官方资料比较，未测量网关延迟或吞吐。Portkey 官方当前使用 Prisma AIRS AI Gateway 标识，本文沿用 Portkey 名称。

请求处理和管理平台

LiteLLM 的路由与密钥能力可以通过配置组织起来。Portkey 商业平台则提供组织和工作空间相关的管理入口。两者都有可以自行部署的部分，实际需要哪些商业功能，会影响最后的费用。LiteLLM Router、Virtual Key、Portkey Gateway、Portkey 方案。

重试放在哪里

应用 SDK 重试两次，网关也重试两次，看起来各自都很克制。但如果都是首次请求加两次重试，且内层耗尽以后外层重新发起，一次业务请求最多会在主模型路径上尝试九次。再接备用目标，次数还可能增加。这是两层配置叠加的结果，并非任一产品的默认行为。

延伸阅读AgentOps vs LangSmith：Agent 调试、评估和自托管怎么选→

LiteLLM 把当前目标的重试与后续模型组 fallback 分开配置。Portkey 也有目标和触发条件，可以限制哪些状态码进入切换。增加这层网关以后，应用侧原有的重试策略也要一并调整，否则延迟和模型消耗都会被放大。LiteLLM 可靠性配置、Portkey fallback。

更现实的限制是用户愿意等多久。一次交互最多等十秒，就没有空间让三个目标分别耗尽十秒。连接时间、首 Token 等待和整段输出的总时限也不同。离线任务可以等一会儿再跑，在线助手往往需要更早结束并告诉用户当前没有完成。

因此，业务请求的总时限要先定下来，再分给各次尝试。网关已经替应用提供重试机制，策略仍需按业务安排。

备用模型的差别

同一模型的另一个部署，与换成另一个模型，工作量不同。前者主要处理容量、访问地址与区域；后者还涉及工具参数、结构化输出、上下文长度和任务质量。

例如订单查询要求返回包含订单号和时间范围的 JSON。备用模型接受了请求，却缺少一个字段，网关可以返回 200，业务依旧无法执行。增加 fallback 提高了请求得到响应的机会，未必提高任务完成率。

同样，参数无效时，把它依次送给几个目标通常没有意义。限流和连接故障适合进入重试或备用路径；输出内容不合格，则需要应用校验或评估结果参与判断。两个产品都提供路由机制，模型是否适合替代当前任务，仍由应用决定。

如果候选目标是同一模型的多部署，路由策略相对简单；如果准备随时切到不同模型，预算里就要加上回归评估和兼容维护。后者往往比多写几个路由规则费时间。

流式请求

流式响应更容易暴露应用与网关之间的分工问题。

延伸阅读Opik vs Phoenix：RAG 评估平台的功能、部署和使用成本→

前半句已经发给用户，后半段突然断开。所用版本即使提供恢复或切换能力，客户端仍然得知道前面的内容怎么办。直接把第二次生成拼在后面，可能得到重复句子，也可能得到无法解析的工具参数。

所以流式处理要连着客户端一起设计：完整收到并校验工具参数后再执行写操作，业务端保留幂等标识；普通文本中断则采用符合产品体验的提示或重试方式。不同网关版本的流式策略会变化，但已经产生的业务副作用始终需要执行端处理。

对只跑批处理的团队，这部分要求可以低一些；对会调用下单、退款等工具的 Agent，结构完整与幂等更重要。它们应当影响路由配置，而不是等故障以后再补。

多个团队共用时，预算怎么管

请求次数、Token 速度和金额预算解决不同问题。一次很长的上下文可能只算一个请求，却消耗大量 Token；同样的 Token 量，换一个模型又会产生不同费用。

LiteLLM 的 Virtual Key 可以配置模型访问、预算与速率。Portkey 当前的 Integration 管理把供应商凭证分配给不同工作空间，再分别设置金额或 Token 预算及速率限制。共享一套供应商凭证，不必意味着所有团队共用一份没有区分的额度。LiteLLM 密钥配置、Portkey Integration。

团队越多，管理流程的工作就越多：谁能增加模型，谁能调高额度，离开的应用如何回收权限。已有内部配置和审批系统，接入 LiteLLM 可以复用这些流程；缺少这套系统，直接购买具备所需能力的商业方案，可能比自行补界面、权限和审计更省。

金额对账还依赖价格口径。供应商协商价、缓存价和公开价不一定相同。并发请求接近预算上限时，还会有在途消耗。预算配置的效果要结合计量和执行方式理解，不能只凭一个限额数字估算最大账单。

最后的成本

总费用里有模型实际消耗，也有网关、依赖存储、运行维护和管理能力。失败尝试仍可能产生上游费用，月底只统计成功请求，账就很难对上。

如果平台团队已经具备部署、配置管理和服务值守能力，LiteLLM 自建有明显的复用空间。若业务需要的是尽快交付多团队治理，自己再建一套管理流程会拖慢上线，Portkey 商业平台的费用就有了对应的替代工作。只需要基础网关，仍可独立比较 Portkey OSS，无需把整个商业平台一起买进来。

有一部分费用与网关选型无关：模型切换后的质量回归、工具幂等和应用自身的耗时。它们不会因为路由已经成功而消失。

业务已经使用观测云时，可以把接入范围内的 Agent 步骤、模型消耗和应用链路放在一起调查。例如网关已经返回，任务仍在等工具，就可以继续沿工具调用找下游 API。观测云承担的是观测与调查，模型路由和预算执行仍由网关负责。观测云 Agent 监测。

这样分工的收益是少维护一套数据关联。前提是所选接入方式能保留实际模型、Token 和调用上下文；网关地址接通，本身不会自动生成完整业务链路。