夜雨聆风很多人做 AI 项目，第一天只关心一个问题：到底用哪个模型？
Claude 够不够强？Gemini 便不便宜？DeepSeek 能不能顶上？Qwen、Kimi、各种开源模型平台要不要都接一下？
我以前也这么想。
但我这段时间折腾 OpenRouter、OpenClaw、Hermes 之后，发现真正烦人的往往不是模型本身。
OpenClaw 和 Hermes 里配置 OpenRouter provider，其实很简单，很快。难的是后面。
余额不足。限流。API key 越配越乱。
这不是小事，也不是玄学。
我之前用过 NVIDIA Build 上的 NIM API 免费端点。它能免费用一些开源模型，但会限流和排队。
不是说这个平台不好，而是只要你开始同时接多个模型、多个 provider，这些问题迟早会冒出来。
以前我会觉得，只要 provider 配通了，后面就是模型能力的问题。
后来才发现，provider 只是第一关。真正影响稳定性的，是你有没有把余额、限流、fallback、key 管理这些杂事放到一个能看见、能调整的位置。
这就是 LLM gateway 这层存在的原因。
它不是模型
LLM gateway 不是一个新模型，也不是新的聊天软件。
它是夹在你的应用和模型供应商中间的一层。
你的代码不直接去找 OpenAI、Anthropic、Google、DeepSeek 或各种开源模型平台，而是先打到这一层，再由它决定走哪个模型、用哪个 key、失败了要不要切、账单怎么算、日志怎么留。
OpenRouter 这周连发了几篇官方对比文章，分别拿自己和 LiteLLM、Portkey 做了比较。我看完之后，觉得这事挺适合讲给正在做 AI 工作流的人。
尤其是已经在用 Codex、OpenClaw、Hermes、Claude Code、Cursor 的人。
你现在可能还没感受到网关的必要性。没关系，等你接第二个模型的时候，它就会来找你。
这个过程通常不是突然发生的。
它更像桌面上的数据线，一开始只有一根，后来越接越多，某天你发现自己已经分不清哪根线通向哪里。
三个工具别混
OpenRouter 更像托管模型路由网络。
我重新看了一遍官方页面，当前更稳的口径是：Providers 页显示 75 个 provider，模型页对应 400+ models。免费模型不要乱算，按 :free 变体看大概是 25 个；如果把所有零价条目都算进去，会混入 router、音频、图像、rerank 这些不适合拿来当普通聊天模型的东西。
你买 credits，用一个 OpenAI-compatible API 调不同模型，它负责路由和 failover。Pay-as-you-go 的平台费是 5.5%，模型 token 价格本身不加价。
LiteLLM 更像你自己部署的模型代理。
本地试用可以很轻，生产就不是一条命令的事了。官方现在有 Docker、Kubernetes、Helm、Terraform 这些部署方式，生产环境要固定版本，不要依赖会漂的 latest 标签。要用 virtual keys、spend tracking、admin 这类能力，Postgres 基本绕不开；多实例共享限流、缓存和路由时，Redis 也会变得很有用。
Portkey 更像 AI control plane。
它不是单纯帮你找模型，而是放在你已有的 provider keys 前面，做治理、日志、prompt 管理、guardrails、观测和预算控制。价格上，Developer 是免费层，Production 是 49 美元/月，记录日志额度是 100k/month。这里有个小坑：Portkey 文档里 logs 和 requests 的口径容易混在一起，真上生产前要以控制台或销售确认的口径为准。
一句话：
别一上来就问哪个最好。
先问自己：你现在乱的是模型访问，还是团队治理？
什么时候该看
如果你只是自己玩 ChatGPT，或者一个 demo 只接一个模型，其实不用急着上网关。
一个 key、一个模型、一个账单，能跑就行。为了所谓架构优雅，多加一层反而是负担。
真正需要认真考虑网关，通常是这几种情况：
你已经接了两个以上模型。 Agent 或工作流不能跑到一半突然断。 你开始遇到余额不足、限流、key 混乱。 你想让便宜模型处理低价值任务，强模型处理关键任务。
注意，前 3 条就够了。
很多个人开发者还没到团队治理那一步，但已经会遇到余额和限流问题。我就是这样。
我的选择顺序
如果你是个人开发者，或者正在做自己的 AI 内容工厂、小工具、Agent workflow，我会先看 OpenRouter。
原因不是它一定最强，而是省事。
OpenClaw 官方教程里有一个 onboard 命令，可以直接把 OpenRouter 配进去：
openclaw onboard --auth-choice openrouter-api-key我自己在 OpenClaw 和 Hermes 里都配过 OpenRouter provider，体感就是：这部分没什么神秘的。真正要想清楚的是后面的模型选择和 fallback。
比如 OpenClaw 里 Auto Router 的默认写法是 openrouter/auto。
如果你已经在公司里做 AI 应用，客户会问数据去哪里了，或者内网数据不能先经过第三方托管层，那就别只盯着 OpenRouter。LiteLLM 这种自部署路线更值得看。
如果你们已经有很多 provider keys，问题不是 "怎么接模型"，而是 "谁用了多少、日志在哪、权限怎么控、guardrails 怎么配"，那 Portkey 的位置就更接近你的痛点。
成本别只看平台费
OpenRouter 官方在对比 LiteLLM 时给了一个算法：用你的自建基础设施成本，除以 5.5% platform fee。
按它的例子，如果自建基础设施大约 200 美元/月，那么模型月花费超过约 3600 美元时，LiteLLM 可能开始更划算；如果基础设施是 500 美元/月，分界线大约是 9100 美元。
这个数字不用死记。
真正要记的是：自建不是免费，只是把平台费换成了服务器、数据库、监控、排障和人的时间。
很多人一听开源就觉得便宜。真上生产以后，半夜限流、日志丢了、Redis 挂了，才知道便宜也有另一种价格。
先做个小检查
不用急着把系统推倒重来。先做 4 件事：
把你现在用的模型和 provider 列出来。 标出每个 provider 的 key 放在哪里、谁在用、余额在哪里看。 给关键工作流配置一个 fallback 顺序。 记录每个模型适合干什么。
这一步做完，你基本就知道自己需不需要网关了。
如果你发现自己连 key 在哪都说不清，那先别谈 Agent 多聪明。基础设施已经在提醒你了。
这里还有一个很现实的判断：越早期的项目，越不应该把系统做重；但越是想长期跑的工作流，越不能假装 provider 永远稳定、余额永远够、key 永远不乱。
网关不是为了显得专业，它是为了让你少在这些小坑里反复摔。
能少掉一次线上中断，就已经值回不少时间。
这个坑非常贵。
最后怎么选
个人开发者，先 OpenRouter。它不是万能，但最容易把多模型调用这件事跑起来。
数据边界严格，或者公司要求自托管，看 LiteLLM。
团队已经有很多 key，开始重视日志、权限、prompt、guardrails，看 Portkey。
已经在跑 OpenClaw、Hermes 这类 Agent 项目，又想少处理 provider 的破事，可以先把 OpenRouter 接进去，再慢慢决定要不要加 LiteLLM 或 Portkey。
不要为了架构而架构。
你真正要解决的问题，不是 "我用了哪个最酷的模型网关"，而是：当余额不足、限流、provider 抽风、key 越来越多的时候，你的工作流还能不能继续跑。
这才是网关这层的价值。
你现在 AI 项目是直接调模型 API，还是已经上了 OpenRouter、LiteLLM、Portkey 这类网关？评论区说下你最烦的是余额、限流，还是 API key 管理。
