如何用 OpenRouter 集中管理 AI API Key 与花费治理
AI 的 API Key 是怎么在团队之间扩散的、OpenRouter 实际收敛了什么、一套盘点—切流—吊销的迁移做法,以及集中化并没有消除的风险。
发布于
一句话结论:AI 的 API Key 扩散方式和影子 IT 一模一样——一个团队一个团队地来,每一次都有正当理由。结果是好几把仍然有效的凭据、好几张账单,以及对两者都没有集中视图。OpenRouter 把它们收敛到一把 Key 之下,带上按 Key 的额度上限和用量可见性。这是"用一把结实的锁换掉六把松的",而不是"不上锁"。
八个月前,市场部的某个人把一把 OpenAI 的 Key 接进了内容脚本。支持团队的工单摘要用的是一个外包顾问配的 Anthropic Key。Vercel 的环境变量里躺着一把 Google 的 Key,加它的人早就离职了,从那以后没人碰过。研发有两把,其中一把肯定躺在某个 git 历史里。
这些在当时都不是错误。每一把 Key 都是"最快把东西跑起来"的那条路,而每一个跑起来的东西,如今都在每天被用。
问题在于它们加起来是什么。问一个简单的问题——上个月 AI 花了多少钱,如果今晚把所有 Key 全轮换掉,哪些系统会挂——没人答得上来。这才是真正的治理缺口,而它为什么比以前更要紧,值得说清楚。
一家公司是怎么走到"六把 Key、一把都没有归属人"的
一把泄露的 AI 厂商 Key,和一个泄露的 SaaS 密码不是同一类事故,区别在于计费。
多数凭据泄露暴露的是数据。而一把 AI 厂商 Key 暴露的是数据加上一条按量计费、没有封顶的花钱通道。在公开仓库里捡到你 Key 的人,可以一直用你的账号跑推理,直到你发现为止——而通常会提醒你的那个机制,也就是异常账单,是一个滞后好几周的指标。
在几乎每一家已经用了一年 AI 的中小企业里,都会出现三个具体缺口:
- 没有台账。没有人手上有一份"哪些 Key 存在、在哪些系统里、谁建的"的清单。最该担心的恰恰是那些不在任何清单上的 Key,而建它们的人可能已经离职了。
- 没有花费上限。厂商账号上通常只有一个支付方式,顶多加一个软性限额。一个跑飞的循环或者一把被盗的 Key,不会停在你选定的那个数字上。
- 看不出是谁在用。厂商控制台显示的是这个账号的总用量。它很少会告诉你:其中 80% 来自某个团队的批处理任务,而那个任务本来每周跑一次就够了,现在每小时跑一次。
这个形状,正是无代码自动化平台上会出现的影子 IT 问题——有人在角落里搭了个有用的东西,然后它悄悄变成了生产系统。AI Key 版本更尖锐,因为暴露的不只是信息,还有钱。
OpenRouter 实际收敛了什么
OpenRouter 是一个网关,坐在你的应用和大量模型厂商之间。你调 OpenRouter,它代你去调 OpenAI、Anthropic、Google、Meta 的托管模型以及其他家。它的 API 与 OpenAI 兼容,这正是"迁移在实践上可行"的原因——多数客户端库只需要换掉 base URL 和 Key,而不是重写代码。
真正在做治理这件事的是两项能力。套餐层级和限额的具体机制会变;在围绕任何一个具体数字做设计之前,先看现行文档。
一把 Key、多个模型,以及厂商级的兜底路由
你的应用只持有一把凭据,而不是每家厂商一把。仅这一个变化,就让后面所有事情变得可处理:轮换变成一次操作,台账变成一份你真的产得出来的清单,而接入一个新模型不再意味着多一个账号、多一张账单、多一个会被弄丢的密钥。
路由是另一半。因为网关能触达多家厂商,当主选厂商报错或过载时,请求可以回落到备选——这很有用,但也值得实话实说:一次把你的提示词悄悄发给了另一家厂商的兜底,是一次数据治理事件,而不只是一个可用性特性。请显式配置允许哪些厂商,而不是接受默认集合。
按团队的花费上限与用量可见性
第二项能力是:你可以在一个账号下签发多把 Key,每一把带自己的额度上限,并且按 Key 看用量拆分。给市场部的内容脚本一把自己的 Key、自己的天花板,给支持团队的摘要器另一把。
这才是改变行为的那部分。厂商控制台告诉你这个账号花了多少。按 Key 的拆分告诉你是哪个系统花的,而这是唯一一个别人能拿去做事的版本。而一个按 Key 的硬性上限,会把一个跑飞的脚本从"账单惊喜"变成"一次失败的 API 调用"——一个立刻自己报出来、报在正确的地方、报给闯祸那个团队的事件。
一套可落地的迁移:盘点、切流、吊销
先盘点,并且预期这份清单是不全的。去每家厂商的账号里看已签发的 Key,然后搜你自己的地盘:托管平台的环境变量、CI/CD 的 secrets、Serverless 配置、自动化平台,以及——很难看但必须查的——git 历史。直接去问每个团队他们在跑什么;人会主动交代出扫描找不到的东西。最后得到一份"Key、系统、归属人、最后使用时间"的清单。
不要跳过"这个还在用吗"这一列。你查出来的东西里,相当一部分正在支撑某个没人记得的功能。这些 Key 是纯风险、零收益,也是整个过程里最容易拿下的分。
一次迁一个工作负载,从最不关键的开始。换 base URL 和 Key,把旧的厂商 Key 留着但不再使用;如果这个负载重要,就短期内两条路并行跑一阵。请求换了路由之后,模型行为可能有细微差异,所以要在真实样本上检查输出质量,而不是默认它就是个无痛替换。
按使用方签发 Key,而不是按人。一个系统或一个团队一把 Key,额度上限依据实际观测到的用量加余量来定——不是拍脑袋定。这个上限是断路器,不是预算。
吊销旧 Key,并确认真的吊销了。这一步最容易被推迟然后忘掉,结果是你同时拥有了新网关和旧的散乱。先吊销,再确认没有东西挂掉,再去厂商控制台确认这把 Key 真的没了。
把账号的归属人写下来。一个没有具名负责人的单点收敛,就是一个单点故障。一个人负责 OpenRouter 账号,一个人是有记录的备份人,而且这两件事记录在一个不会随他们离职而消失的地方。
OpenRouter vs 各团队各拿各的 Key vs 自建内部网关
- 用 OpenRouter 收敛。一把凭据、按 Key 的天花板、按使用方的用量可见性,以及不用每次新开账号就能用上很多模型。代价是你多了一个依赖:一个中间层现在处在每一个请求的路径上,有它自己的可用性和它自己的条款。对多数中小企业这是笔划算的交易,因为另一个选项并不是"没有中间层"——而是"六家厂商各有各的中间层"。
- 各团队保留自己的厂商 Key。没有迁移成本、没有新供应商,而且和每家厂商都是直接关系——如果某个场景确实需要某家厂商的企业级数据条款,这一点是真的重要。代价就是你现在的处境:没有台账、没有上限、没有统一视图,而且一次轮换意味着要同时协调所有团队。
- 自建内部网关。控制力最强。路由、日志、脱敏、限额都你说了算,凡是你没发出去的东西就不会离开你的基础设施。但它同时也是一个你现在要养的服务:值班、升级、跟着厂商 API 变化改、以及建它要花的那几个人月。在规模足够大或者数据处理要求足够严的场景下站得住脚,对一家 50 人的公司则很少站得住。
适合多数中小企业的模式是:普通负载走网关,换取可见性和天花板;同时为那一个"数据处理需要特定合同"的场景,保留一条刻意为之的厂商直连关系。
收敛解决不了什么
一把被攻破的网关 Key,现在能碰到所有模型。这是诚实的权衡。你把六把松的锁换成了一把结实的,那这把就最好真的结实:尽可能短生命周期、按使用方收窄、按周期轮换、绝不进仓库。集中化是真实存在的风险,而答案是——对这一把凭据的照顾,要超过那六把中任何一把曾经得到过的。
提示词内容仍然离开了你的网络。网关改变的是"你向谁付费、你轮换什么"。它并不改变这个事实:你的提示词——里面可能有客户数据、内部文档或源代码——正在被发给一个第三方,再转给一家模型厂商。去看网关的现行数据处理条款和各厂商的策略,并对敏感负载限制允许的厂商范围。
故障变成共享的。当所有负载都走同一条路,中间层出问题就是所有负载同时出问题。兜底路由缓解的是模型厂商的故障,不是网关本身的故障。请提前决定哪些负载可以直接失败,哪些需要一条"打破玻璃"的厂商直连通道——Key 保持有效但平时不用。
这里没有任何东西在审查大家在建什么。对花费和凭据的治理,不等于对使用场景的治理。一个按 Key 的限额,不会告诉你某个团队正在把客户合同喂给一个本来就不该看到它的模型。
把它做对:轮换、最小权限,与什么时候该让 IT 介入
按周期轮换,也在人员离职时轮换。收敛让轮换变得便宜,这就抽掉了过去"所以我们从来不轮换"的那个借口。定一个周期,写进有归属人的日历,并且在任何有权限的人离开时立刻轮换。
每把 Key 只对应一个使用方。永远不要签发一把多个系统共用的通用 Key。当你需要紧急吊销时,你希望只弄坏一样东西,而且你希望在动手之前就知道是哪一样。
用实测用量来定上限。先跑几周,看每把 Key 的真实数字,再带余量设限。凭空拍出来的天花板要么没用,要么会在凌晨两点为一个行为完全正常的负载把人叫醒。
在网关侧记日志,并把日志放在厂商删不掉的地方。按 Key 的用量时间序列就是你的早期预警:一次无法解释的阶跃,要么是 bug,要么是被攻破,两种都得当天看。
把这个账号当生产基础设施对待。账号开多因素认证、限制管理员访问、对限额变更告警、有书面归属人。持有"通往所有模型的那一把 Key"的账号不是一次注册,它是一套记录系统。
把盘点做诚实、决定什么走网关而什么保留厂商直连合同、写出一套忙起来也还会被遵守的 Key 处理规则,是 AI+ 支持的活儿。底下的凭据卫生——密钥存储、轮换、多因素、离职回收,以及在散乱重新积累起来之前就抓住它——属于托管 IT 安全服务。日常把它跑起来则是普通的托管 IT 支持。关于无代码自动化里非常相近的影子 IT 模式,可以看我们关于用 Power Automate 做 AI 工作流自动化的文章;想在做任何决定之前先把盘点跑一遍,也可以直接联系我们。
常见问题
OpenRouter 会看到每一条提示词的内容吗?
请求要经过网关,所以请把内容视为对它可见,并据此治理。具体记录什么、留多久、按什么条款,由现行文档和你的账号设置(包括各厂商的数据策略)决定——请直接去读那些,而不是依赖任何摘要,包括这一篇。对真正敏感的负载,更稳妥的设计是与一家你确实审过其企业条款的厂商建立刻意为之的直连关系。
如果 OpenRouter 自己挂了怎么办?
所有走它的东西会同时受影响。兜底路由帮的是模型厂商挂掉的情况,不是网关挂掉的情况。请提前决定哪些负载可以直接失败,哪些需要一条"打破玻璃"的通道:一把保持有效、也在轮换的厂商直连 Key,加上一份告诉别人怎么切过去的操作手册。没演练过的应急通道,在事故中第一次演练时是不会成功的。
某个敏感场景还能直连厂商吗?
可以,而且对很多公司来说这才是正确架构:普通负载走网关,那个需要特定合同的场景保留一条直连。关键在于这个例外是刻意的、有记录的,而不是迁移之前遗留下来的。一个没有记录的例外,和散乱是分不出来的。
怎么给每个团队设硬性花费上限?
按团队或系统分别签发 Key,并给每一把挂上额度上限;具体机制看现行文档。数字要基于几周的实测用量加余量,而不是猜。另外还要决定:一把 Key 撞到天花板时应该发生什么——调用失败正是目的,但得有人被通知到,而且这个告警应该发给拥有这个负载的团队,而不是只发给账号所有者。
这比直连各家厂商更便宜吗?
成本不是主要论点,也不要默认它会下降。网关可能在底层厂商定价之上加一层。收敛可靠买到的是可见性、天花板,以及一次操作就能完成的轮换。实践中真正出现的节省,往往来自"看清了每个使用方的用量",然后发现某个每小时跑一次的负载其实并不需要那么跑。
需要改我们的应用代码吗?
通常改得很少。它的 API 与 OpenAI 兼容,多数客户端换个 base URL 和 Key 就行。时间要预留给验证而不是重写:在真实样本上确认输出仍然是你期望的,因为路由可能把你的请求送到了和以前不同的模型或厂商面前。
有团队不肯迁怎么办?
把它当治理问题,不是技术问题。由一个有权限的人立下规则:新的 AI 负载一律走网关,存量在某个明确的日期前迁完。没有这条,你会同时拥有一个网关和继续扩散的散乱,那比两者中任何一个单独存在都更糟——你多了一样要管的东西,却没拿到你当初要的那份可见性。
分享:
📬 亚太IT月报
中国合规动态、网络安全预警及亚太IT实践指南,每月一期。
不发垃圾邮件,随时可取消订阅。