按适配场景选择

托管与自托管 AI Gateway：决定运维责任放在哪里

托管 AI Gateway 由服务运营方负责网关部署、扩缩容和大部分故障链路；自托管则把基础设施、凭证、存储、升级和可用性放到团队自己手中。托管访问通常更快进入生产；只有基础设施位置、自定义策略或供应商账户控制值得持续运维时，自托管才更合理。 [1] [2] [3] [4] [5] [6]

最后复核 2026-08-15 · 编辑复核: KeepRouter Editorial

托管与自托管 AI Gateway 之间的责任分工图 — 两种模式下，部署、凭证、存储、升级与故障响应由不同角色承担。

责任对照表

责任	托管网关	自托管网关
网关部署	厂商运营	平台团队部署并扩缩容
供应商账户	厂商额度、客户 BYOK 或混合	通常使用客户自己的供应商 Key
数据面位置	厂商架构与可用区域	自己的云、网络或集群设计
日志与存储	厂商产品和保留控制	自己的数据库、备份与删除任务
可用性	厂商服务加上游供应商	自有网关、依赖和上游供应商
升级	厂商发布流程	自己测试、灰度、回滚与处理依赖
支持	合同化服务路径	内部值班加开源或商业支持
成本	用量、额度、订阅或平台费	基础设施、存储、人力和供应商账单

这首先是责任决策，然后才是软件决策。自托管软件可以很快启动，却难以在负载下运营；托管产品能减少运维，也会增加新的厂商与数据路径。

托管更清晰的情况

小团队需要一个可用端点、不想运营网关基础设施，并希望有明确支持路径时，适合托管。运营方同时负责供应商关系和计费时，托管模型访问尤其简单；必须保留供应商账户，但不想负责部署与策略运维时，可以选择 BYOK 托管控制面。

KeepRouter 属于托管模型访问。Vercel AI Gateway 与 OpenRouter 是供应商控制不同的托管路由产品。Helicone 在可观测平台旁提供托管网关。AI Gateway 候选名单提供具体产品入口。

自托管何时值得

网关必须运行在特定网络、连接内部身份与策略，或需要托管产品无法提供的路由行为时，可以自托管。已经运营 Kubernetes、service mesh、API Gateway 和生产数据库的团队，更容易吸收额外服务。

LiteLLM 是常见自托管代理路径，Portkey 发布自托管选项，Kong AI Gateway 则扩展已有 Kong 平台。三者 License、控制面和功能边界不同，不能只看开源标签。应分别查看 LiteLLM 对比、Portkey 对比和 Kong 对比。

选择软件前先建立责任登记表

为每项必须持续到生产环境的责任建立一行：请求入口、网关运行时、供应商凭证、供应商合同、模型允许名单、路由变更、提示词与输出处理、请求日志、用户访问、用量对账、故障响应和回滚。每一行都要写明负责团队、运行步骤、证明步骤有效的证据，以及谁批准例外。不要只写部门名称，至少要指向可执行的 runbook、告警、报表或合同边界。

同一张表分别填写托管候选和自托管候选。托管方案中，"厂商负责"只有在产品文档或合同写清服务边界，并且内部已经记录升级路径时才算完整。自托管方案中，"平台团队负责"只有在已有操作手册、告警与恢复测试时才算完整。如果凭证轮换由安全团队执行、费用归属由财务平台处理、模型回退由应用团队决定，就应分别列出，不能把三项责任压进一句"平台负责"。

最终产物应是一张可以逐行评审的责任表。如果某项生产责任没有 owner、所需日志无法取回，或团队无法说明升级失败后由谁恢复服务，就淘汰该候选。安全、财务和值班人员应在切流前对自己的行签字。这样得到的是可运行的责任安排，不是对某个产品界面的偏好。

表格容易遗漏的成本

自托管成本包括计算、数据库、缓存、日志、备份、出口流量、密钥管理、高可用、告警、依赖更新、故障处理和工程责任。托管产品则要计算网关费、额度费、套餐限制、数据保留、可能的供应商加价与厂商依赖。

模型推理通常是主要变量成本，但并不是全部运行成本。失败尝试与回退可能在多条线路产生费用。LLM 计费答案与成本控制指南提供请求级计算方法。

设定成本、迁移与证据边界

比较时固定评估周期和逻辑工作负载。托管网关一侧要记录模型费用、网关或平台费用、接入工作、仍需保留的可观测系统，以及访问复核和故障处理中没有消失的人力。自托管一侧要记录供应商账单、计算、存储、出口流量、备份、密钥管理、部署、监控、升级和值班。一次性迁移工作与持续运行成本应分列，否则切换月份的集中投入会扭曲稳定运行估算。

不要只统计成功响应。一个逻辑请求可能产生主线路尝试、重试与回退，日志和缓存也会带来存储与读取成本。每个成本项都应附上证据类型，例如账单明细、用量导出、基础设施 meter、带假设的人力估算或故障记录。厂商计算器可以帮助建立初稿，但不能证明自己的流量结构和人员负担。对模型调用成本的具体拆解可继续使用成本控制指南，不要在本文复制会变化的单价。

比较开始前写好迁移门槛：必需路由通过契约测试，安全团队接受数据路径，账单记录能在约定误差内核对，值班团队完成失败演练，回滚达到服务目标。每类证据只能证明所在层。网关用量记录不能证明供应商最终账单，云账单也不能证明应用收到有效回答。无法建立这条证据链时，应保持现有路径并继续补测，而不是按产品类别推断总成本或可靠性。

决策前运行故障演练

让供应商凭证失效，观察用户看到的错误。
让主上游超时，检查重试与回退证据。
在部分输出后中断流式。
从备份恢复网关或替换不健康实例。
撤销客户 Key，并确认日志不再暴露访问。
回滚网关版本或策略变化。
把每次尝试与用量和计费记录核对。

托管候选必须提供足够证据解释故障，自托管候选则要证明团队能够运行恢复路径。演练时使用安全清单与故障切换指南。

混合模式仍有两套责任

部分产品提供托管控制面与客户自托管数据面，或提供带 BYOK 的托管网关。这可以满足网络与供应商所有权要求，但不会消除责任分割。必须记录谁升级每个组件、日志在哪里，以及故障由哪一方处理。

常见问题

自托管一定更便宜吗？

不一定。比较总成本时，要在供应商费用之外加入基础设施、存储、安全、升级、高可用与人力。

托管是否意味着没有运维？

不是。团队仍负责应用行为、Key 权限、评测、数据分级、故障决策与厂商审查。

托管网关可以使用我的供应商 Key 吗？

有些可以通过 BYOK。应核验当前套餐中的凭证存储、费用、供应商回退与账单核对。

上游模型故障由谁处理？

两种模式都依赖上游，区别在于谁运营网关检测、重试、回退与客户沟通。

什么是混合网关部署？

通常是托管控制面加客户自托管数据面，或把托管路由与客户供应商凭证结合。

参考的一手资料

来源复核日期 2026-08-15