我们差点人手一份AWS密钥，于是我造了个LLM网关

几个月前，一个熟悉的请求躺在了我的工单里——非技术团队想调用公司的大语言模型，问能不能给他们开通亚马逊云科技Bedrock的权限。单看纸面，这事简单到可以十分钟解决：Bedrock已经部署在账号里，模型也激活了，身份与访问管理（IAM）顺手就能分配权限。然而只要真的把它当成十分钟的活来处理，三周之内必然后悔。

这个判断不是凭空而来的。表面上我们只有两条路可走，而一旦思考超过第一个使用者，就会发现两条路都不怎么好。第一条路是直接下发IAM凭证或者一个能调用Bedrock的角色。单独给一个人没问题，但多几次之后，AWS的密钥就会散落到各个角落：藏在.env文件里，卡在某个持续集成变量里，流进某人的Postman收藏夹，甚至钻进你永远无法追查的笔记本代码片段里。轮换密钥的时候，你得掘地三尺找到每一处落脚点。而且IAM权限的边界往往比想象的要宽，一个允许调用Bedrock的策略总会顺手带出其他几样东西，因为第一天没人会精细地裁剪它们——等到察觉时，第一天已经变成了一年前。

第二条路是搭建一个内部接口，背后塞一把共享的密钥，所有人都指向那里。这办法搭建最快，但致命缺陷是每一个请求看起来都没区别，你无法分辨到底是哪个团队的代码在烧钱。一个粗心的死循环就能在午饭前吞掉整月的预算，而你连出问题的团队都定位不到。更麻烦的是，想切断某一个人的访问，就必须把所有人正在用的密钥全部轮换掉。两种方案在涉及超过两三个人的时候都迅速崩塌。最刺痛的地方还在后头：当财务部门终于问起人工智能费用的飙涨时，你拿不出任何可以展示的东西。

其实这个问题已经有了一整套成型的解决方案。市面上冒出了一类专门处理这个场景的工具，人们管它们叫AI网关或者大语言模型网关。LiteLLM、Portkey、Helicone、Cloudflare的AI Gateway，还有一堆其他的选择。它们都挡在你的应用和模型提供方之间，交还给你两样最想要的东西：谁能调用什么的控制权，以及每个人花了多少钱的记录。这和普通API网关的概念一样，只是把目标指向了大模型调用的令牌。

我花了一些时间打量托管的那些，坦白说，对大多数团队我会直接建议挑一个用起来就好。但我们没有走这条路，理由一点都不性感。我们是一家金融科技公司，发出的提示和获得的补全内容里，有一部分携带的数据我不想让它离开自己的网络。仅仅为了得到一份用量图表，就把这些东西通过别人的软件即服务（SaaS）中转，这种交换我不愿意做。我要的是整套东西完全关在自家的边界之内，直连Bedrock，日志落到我们自己的数据库里。所以，我造了一个小型的版本。

整个设计归结为一个粗暴的决定：谁都不许拿AWS凭证。开发者不行，服务不行，除了网关本身，任何对象都不行。人们拿到手的，是网关自己发明的一种密钥——一个带前缀的令牌，比如llmkey_9f3c之类的，AWS从来都不知道它的存在。你把令牌放进应用，把客户端指向网关的网址，而不是原来Bedrock的地址。这样一来，任何对底层模型的调用都必须先通过网关，经过校验、记录、配额检查，再转化成一封有权限的AWS请求。一旦某个令牌需要吊销，你可以立刻作废它，完全不影响其他任何人。而IAM凭证始终只锁在网关的配置里，从不外流。

构建这个系统的过程，本质上是对过往经验的一次清算。以往很多人会把IAM密钥随手黏到文档里、聊天群里，这种脆弱性本质来自于把云平台的权限当成单一用户权限来使。网关把所有对模型的访问聚合成一种门禁式的管理，背后每一项调用都带着明确的归属和可追溯的审计痕迹。这也是为什么后来财务再来询问时，我们能按团队、项目甚至具体模型版本拉出精确的成本报表，而不是两手一摊。

这里还透着另一个被经常忽视的视角：数据流动的拓扑结构。当所有开发者都直接对准云服务商时，数据路径是扇形的，每个端点都独立承载凭证和连接，表面看零散却不易集中控管。网关把拓扑掰成了星形，只有中心节点掌握凭证，其余所有节点通过临时令牌进行鉴别。这种改变让安全边界变得更加可控，即便某个令牌被暴露在公开仓库，攻击者能摸到的也仅仅是经过限额和路由策略约束的调用渠道，而不是底层的云账户。

对于团队内部的摩擦，网关也充当了一层缓冲。不同组申请模型调用的时候，原先得走工单、审批、手动绑定角色，一轮下来少则数天。现在只要生成一个带有语义前缀的令牌，就能在几分钟内让某个项目试验起来。令牌的名字可以帮助运维一眼看出什么团队在做什么事，而用量上限的设置又能让试验期的失控不至于传导到整体预算上。更妙的是，这种令牌和应用的绑定关系，天然留下了变更历史，谁在什么时间接入了什么模型，一目了然。

在整个决策链条里，两方的论调一直在拉扯。一方坚持应该用现成的商业网关，上手快，有现成的仪表盘和告警，缺的只是把数据过一道外部网络。另一方则觉得凡涉及模型交互的内容都带有潜在的数据残留，尤其在金融合规的语境下，任何过墙的流量都可能增加审查负担。最终迫使天平倾斜的，是一种对长期成本的判断：商业网关按令牌消耗抽成或者按月付费，当调用量膨胀到一定阶段，费用曲线会变得陡峭；而自建虽然搭进去开发人天，但只要团队有能力维护，边际成本无限趋近于零。而且，日志落库后的可分析性也远高于托管的有限导出。

不过，自建网关也并非没有暗角。需要自己设计缓存层的策略以降低重复提示的成本，需要考虑多区域部署以满足延迟要求，还要应对模型供应商接口变更带来的适配工作。但这些都可以通过逐步迭代来消化。真正关键的，是始终抓住一条主干：谁用什么模型，花掉多少预算，什么时候该截断。只要骨架撑住了，肌肉就可以慢慢长上去。

回头看，最初的工单看似只是一个无伤大雅的权限请求，实际上是在考量整个组织的模型治理策略。如果没有立刻跳出“给权限”的思维定势，而是顺着惯性分发了一把把AWS密钥，那么后续的泄漏、滥用、成本不可测都将成为必然。用一扇网关将所有对模型的渴望收束在可控的通道里，这不是过度工程，而是用一种明确的设计，替未来所有潜在的混乱提前付了一笔很小的保险费。