AI 网关怎么选：自建、聚合平台与本地代理的取舍
数据截至 2026-07，价格与限额以各官网为准。
AI 网关这件事不存在通用最优解，选型基本被”谁来承担运维”和”密钥交给谁”这两个问题决定：一个人在本机写代码，跑个本地代理最省事；一个团队要统一账单和审计，自己部署一套网关才说得通；不想碰运维、也接受多一层第三方托管，直接用聚合平台最快。三条路的技术实现差别没有想象中大，真正的差别在责任边界。
先破一个常见误解：很多人以为”AI 网关”是个高大上的基础设施组件，得有 K8s、得配限流、得上可观测性。实际上现在大量所谓的网关，就是一个把自己伪装成 OpenAI 接口的进程——它对外暴露一个 /v1/chat/completions，对内按规则把请求转发给真正的模型供应商。你的 IDE、CLI、脚本只认这一个地址，换模型、换供应商都不用改代码。这个进程可以跑在你的笔记本上，也可以跑在公司机房里，还可以是别人替你跑的 SaaS。形态不同，本质是同一件事。
三条路线到底在解决什么问题
把需求拆开看，网关一般被用来解决四类事，不同路线擅长的项不一样：
- 统一接口：把 GPT、Claude、Gemini、国产模型的差异抹平成一套 OpenAI 兼容调用。三条路都能做到。
- 故障回退：某家供应商挂了或者额度用完，自动切到下一家。本地代理和自建网关能自己定策略，聚合平台按平台自己的规则来。
- 成本与账单：谁在花钱、花在哪个模型上。团队场景下这是自建的核心理由。
- 合规与数据边界：请求正文经过谁的服务器。这一项决定了很多企业不能选托管方案。
如果你只需要第一项，别急着上网关——很多 SDK 本身改个 base_url 就够了。真正需要网关的信号是：你手上有三家以上供应商的账号，且经常需要切换或回退。
路线一：本地代理，个人开发者的默认解
本地代理指的是把网关进程跑在自己的开发机上，只服务本机的 IDE 和 CLI，通常监听 localhost。它不解决团队协作，也不解决审计，就解决一件事：让你手上所有 AI 工具共用一套供应商配置。
开源项目 OmniRoute 是这条路线目前比较典型的形态，可以拿来说明它长什么样。它是 MIT 协议的开源网关，仓库自述覆盖 290+ 供应商、500+ 模型，涵盖 Kimi、Claude、GPT、Gemini、GLM、DeepSeek、MiniMax 等，并声称可以对接 Claude Code、Codex、Cursor、OpenCode、Cline、Copilot 等工具。它的核心用法就一句话：把所有工具的接口地址统一指向 http://localhost:20128/v1。
启动方式相当轻：
npx omniroute@latest
或者用 Docker：
docker run -p 20128:20128 diegosouzapw/omniroute
跑起来后打开 http://localhost:20128 就是管理面板。仓库自述有 80+ 条命令，日常大概率只会用到这几条：omniroute 启动网关和面板、omniroute setup 走首次配置向导、omniroute doctor 自检、omniroute chat 开一个交互式 TUI 聊天、omniroute models --search <term> 查某个模型当前有没有供应商能提供（也可以直接请求 GET /api/models/catalog）。
加供应商的路径是面板左侧 Providers → + Add Provider → 搜索点选 → Connect → Test Connection 验证。认证方式分四类，理解这四类比记住具体供应商更有用：
- OAuth：由网关代管登录流程，不需要你手动粘 API key；
- web cookie：借用网页端会话；
- API key：常规付费方式，部分供应商带免费额度；
- Local：接本机跑的推理服务，比如 Ollama、LM Studio、vLLM 这类。
最后一类值得单独说：本地代理和本地模型是两件事，但可以拼在一起——网关既能转发到云端供应商，也能转发到你自己机器上的推理服务。想走纯离线路线的，可以先看用本地大模型跑 AI 编程那篇把推理端跑通，再用网关做统一入口。
关于免费档，仓库自述有 90+ 家带免费档、其中 40+ 家永久免费，具体点名的免费选项包括 Kiro、OpenCode Free、Pollinations，文档建议新手从 Kiro AI 起步——免费、不需要 API key、可以用到 Claude 系模型。但这一段请务必当成”当前快照”而不是承诺：免费额度是各家供应商最容易改的东西，今天写的”永久免费”明天可能就变成限量，实际以仓库文档当前版本和各供应商官网说明为准。真要依赖它做生产，你会很被动。
路线二：托管聚合平台，用钱换省事
聚合平台就是别人替你跑好的网关：你注册一个账号、拿一个 key，平台帮你对接背后几十上百个模型，按用量结账。这条路的优点非常直接——零运维、零配置文件、出问题有客服，缺点也非常直接——你的请求正文要经过第三方服务器，账单和路由规则由平台定，模型的可用性也随平台的商务关系变化。
它适合的场景很清楚：小团队原型阶段、个人做副业项目、需要短时间内试遍很多模型做横向比较。不适合的场景同样清楚：涉及客户数据或代码资产、公司有明确的数据出境或第三方处理者审查要求。
站内已经有几篇专门写这条路的，选型时可以对照着看：API 聚合/中转平台怎么选 讲的是聚合与直连的整体取舍，OpenRouter API 怎么接入 是其中一家的具体接法，国产 API 价格对比 则适合确定要走国产供应商的人。
这里必须补一句不太好听但躲不开的事实：OpenAI、Anthropic、Google 这几家的官方服务并不支持中国大陆直连，这属于准入政策问题，不是网络优化能解决的。市面上确实存在各类第三方中转服务声称能转发这些模型，本文不背书、不点具体渠道——这类服务的合规性、计费透明度、数据处理方式都需要你自己核实并承担风险。把这一点想清楚，比比较任何网关的功能列表都重要。
路线三：自建网关，团队规模才值回票价
自建是把开源网关部署到自己控制的服务器上，供整个团队使用。技术上和本地代理没有本质区别——很多项目本身就支持 Docker 部署——差别在你需要额外承担一堆事：谁有权限改配置、密钥怎么存、日志留多久、有人离职了怎么撤销、网关本身挂了谁值班。
值得自建的信号通常是这几条同时出现：团队五人以上、需要按项目或按人分摊 AI 成本、有合规要求不能让请求正文流经不受控的第三方、已经在用 MCP 之类的扩展协议需要统一治理（不了解这块可以先补MCP 协议是什么）。
只满足其中一两条的话，自建大概率是给自己找活干。一个真实的判断办法：估一下你团队一个月在模型上的实际花费，如果这个数字还不够付半天运维人力，那自建省下来的钱是负的。
一些容易被忽略的实现细节
模型 ID 不要想当然。 网关一般直接透传供应商的原生模型 ID，所以形态五花八门。OmniRoute 仓库里出现的示例包括 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5 这类写法，其中带点号的版本号是因为上游 API 本身就是那么要求的，不是笔误。抄旧教程里的模型名是最常见的 404 来源，接入前先用网关自带的查询命令确认一遍。
auto 是把双刃剑。 OmniRoute 支持把模型字段填成 "auto"，由网关自动挑选。这在探索阶段很方便，但一旦你要复现某次输出、或者要核对成本，自动路由会让问题变得难查。建议开发调试用 auto，任何需要稳定行为的地方写死具体模型。
回退链要自己设计。 接多个供应商之后就能启用配额感知的自动回退——某家额度用完自动切下一家。仓库给的零成本组合示例是 gemini-cli/gemini-3-flash-preview（标注每月 180K 免费）→ if/kimi-k2（标注无限免费）→ qw/qwen3-coder-plus（标注无限免费）。这个链条的思路值得借鉴：把配额有限但质量好的放前面，把无限但质量一般的放兜底。但同样地，这些额度标注是仓库文档当时的口径，实际额度以各供应商官网为准。
token 压缩要实测。 OmniRoute 提到内置 RTK+Caveman 压缩，仓库称能省 15-95% token。这个区间宽到几乎没有参考价值——压缩率完全取决于你的 prompt 结构，重复模板多的场景收益大，本来就精简的对话可能没什么效果。开启前后各跑一批真实请求对比用量，比看任何宣传数字都可靠。
扩展生态。 它还支持 MCP 与 A2A、提供 Desktop 和 PWA 客户端，工具侧除前面提到的几个，还包括 Kiro、Command Code、Antigravity、Windsurf、AMP 以及任意 OpenAI 兼容工具；仓库把 33 个工具的逐一配置放在 docs/reference/CLI-TOOLS.md，OpenCode 的插件包名是 @omniroute/opencode-provider。
风险与不适用场景，说在前面
这一节不能跳过。任何网关的本质都是”你把各家凭证集中交给一个进程”，这带来三层风险：
第一，凭证集中。一个网关配置文件里可能同时存着你五六家供应商的 key，泄露一次全线沦陷。本地代理至少还在自己机器上，托管平台则是你连”存在哪”都不知道。最低限度的自保：给网关用的 key 尽量单独申请、设独立额度上限，不要和生产系统共用一把。
第二，服务条款。有些供应商的免费额度、OAuth 登录、网页会话是给自家客户端用的，通过第三方网关转发未必符合其条款。web cookie 这类认证方式尤其要留意。用之前看一眼对应供应商的条款，账号被封的成本通常比省下来的那点钱高得多。
第三，项目本身的可持续性。OmniRoute 是由 9router fork 而来、也是 Go 项目 CLIProxyAPI 的 TypeScript 移植，第三方资料称它有 23k+ GitHub stars、500+ 贡献者。热度高说明社区活跃，但开源项目的 fork 链条长本身也意味着上游变动会传导下来。另外供应商数量在不同来源的口径并不一致（268+ 与 290+ 两种说法都出现过），这类自述数字看个量级就好，不必当精确指标。
不适用的场景也说清楚：需要严格审计每一次调用、需要 SLA 承诺、需要出事有人负责的生产系统，不要把开源网关直接摆在关键链路上。它更适合开发环境、内部工具、实验性项目。真上生产，要么用供应商官方 SDK 直连并自己做重试，要么用有商务合同的托管服务。
怎么快速做决定
给三个可操作的判断句，对号入座就行：
- 你是一个人、主要在本机的 IDE 和 CLI 里用 AI，且手上有多家账号 → 跑本地代理。成本最低、回滚最容易，不合适删掉进程就完事。
- 你不想碰任何配置、接受第三方处理请求、且数据不敏感 → 用托管聚合平台。先看站内那几篇对比，选一家跑通再说。
- 你要给团队统一账单、有合规红线、月度模型开销已经到了值得专人管的量级 → 自建部署，并且从第一天就把密钥轮换和权限收口的方案定下来。
还有第四种情况经常被忽略：你其实只用一两家模型。那就别上网关了，直连最简单，少一层就少一个故障点。工具链的复杂度是有利息的，你今天多装的每个组件，将来都要在某个赶工期的晚上还回来。
小结
AI 网关的三条路线——本地代理、托管聚合、自建部署——技术差异不大，区别在于谁承担运维和谁持有密钥。个人开发者用本地代理性价比最高，OmniRoute 这类开源项目降低了尝试成本，但免费额度、供应商数量这类信息变动极快，务必以仓库文档和各供应商官网当前说明为准。托管平台省事但要接受数据经过第三方，且要清醒面对部分海外模型在大陆没有官方直连渠道这一事实。自建只在团队规模和合规要求同时到位时才划算。最后记住那条反向判断：如果你只固定用一两家模型，不上网关才是更优解。