模型网关不是多接几家 API 当接口人——给厨房配个会比价、会兜底、会记账的采购总管

你缺的从来不是多接几家菜贩的电话而是一个替你比价、替你兜底、替你记账把定价权重新攥回自己手里的人。上篇我们把那笔账掰开揉碎讲透了agent 是你的厨房token 是每天要下锅的食材你要是只认一家菜贩进货人家哪天单方面涨价、限量、断供你除了认栽没有第二条路。定价权、稳定性、议价的底气全捏在别人手里。那这一篇咱们卷起袖子干活讲讲这个困局到底怎么破。我猜你脑子里可能已经蹦出一个念头了那我多接几家菜贩不就行了吗今天这家贵就打那家电话那家断货就换另一家。听起来挺对但这恰恰是最容易拐错的第一个弯。多存几个菜贩的电话你只是从认死一家变成了手忙脚乱地认好几家——每家报价方式不一样、送货规矩不一样、出了岔子甩锅的话术也不一样全得你这个大厨亲自扛。你不是解决了问题你是把一个问题拆成了好几个。真正该干的事是给这间厨房请一个采购总管。一、先说清楚采购总管不是接口人咱们先把这个角色定准不然后面全跑偏。很多人一听模型网关第一反应是不就是写个转发嘛——前面架一层把请求收进来再挑一家模型 API 转出去。多接几家供应商写几个if-else判断该走谁齐活。这个理解只对了个皮毛。按这个理解做出来的东西不是采购总管而是个跑腿的接口人。他的活儿就是接你电话、照单转给菜贩、再把菜拎回来。你让他打给谁他就打给谁你不发话他啥也不琢磨。菜价涨了他不知道这家断货了他傻站着月底你问这个月买菜花了多少钱、都是哪道菜要的料他一问三不知。这种接口人你要他干嘛无非是把你自己打电话换成你指挥他打电话中间那点脏活累活一点没替你分担。采购总管的价值从来不在他能联系上几家菜贩而在他能不能替你把采购这件事真正管起来。管起来是什么意思三件事——他得会比价。同一档次的食材这家摊位卖五块那家卖一块他门儿清能用便宜的绝不给你打到贵的那家去。他得会兜底。一家菜贩今天突然断供他二话不说立刻切到备用摊位不让你的厨房停火但他也不是无脑乱切而是分得清这是人家真断货了还是你把订单地址写错了。他得会记账。每一笔进货走的哪个摊位、花了多少钱、是哪道菜要的料全记在账本上月底一翻钱花在哪儿清清楚楚。你看会比价、会兜底、会记账——这三件事才是采购总管和跑腿接口人的分水岭。说回技术语言这三件事对应的就是模型网关真正要承担的三项职责多供应商竞标路由、失败兜底 fallback、统一计量与成本治理。它把模型调用这件事从接一个 API升级成了一个可以被治理的调用入口。我特别想把这句话钉在你脑子里模型网关不是多接几家 API 当接口人是给厨房配个会比价、会兜底、会记账的采购总管。你要是只当它是个转发层那你请回来的永远只是个跑腿的白瞎了这个位置。好定性讲完咱们一件一件拆。先说第一件也是最能立刻替你省钱的——会比价。二、第一件事·会比价让该省的订单绝不打到贵摊位先讲个最朴素的道理不是所有的菜都得上高档食材。你厨房里一天要出的活儿其实五花八门。有的是硬菜——逻辑复杂、要动脑子的活那确实得请个好模型来炒可更多的是杂活——把一段话总结一下、把格式规整一下、把一批数据分个类这种活儿随便一个便宜模型都干得利利索索。要是你不管三七二十一所有订单一律打给最贵那家摊位那你就是在拿买鲍鱼的钱去买大白菜。那这中间的差价有多大我给你看一组公开数据——先声明一句模型价格是公开数据、随时在变这里只让你感受量级同样都是能力过得去的档位比如通用知识测评 MMLU 在 75% 到 80% 这一段贵的那档一百万 token 要好几美元便宜的那档一百万 token 只要几美分要是你自己在本地跑个小模型摊薄下来还能更低。掐指一算同一个档位里价差能拉到大概 50 倍。50 倍是什么概念就是这句话要说的同一档位的食材便宜的那家你用一个月的钱够你在贵的那家用一天。关键就看你能不能把常识题和专家题给分诊开。所以采购总管的第一项本事就是比价路由来一个订单先掂量掂量这活儿的分量再决定派给哪个摊位。这活儿具体怎么派一般看三个维度——按菜的种类派写代码的活给擅长写代码的、要长记性的活给上下文长的、按价钱派能用便宜货解决的订单绝不打到贵摊位、按靠谱程度派对稳定性要求高的关键订单只交给服务最有保障的那家。那这套比价具体怎么落地这里有个特别关键的设计思想我得给你讲透——抽象层。你的厨房只该认识采购总管一个人想象一下如果没有采购总管你的大厨也就是 agent 代码会是什么样他得亲自记住A 菜贩要用微信下单、B 菜贩只收电话、C 菜贩得填表格每家的暗号、脾气、结算方式全不一样。哪天想再加一家 D 菜贩大厨还得回炉重学一套 D 的规矩。这不叫解耦这叫把绑死一家换成了绑死一堆规矩。前面我说的那个if-else转发坏就坏在这儿——你以为多接了几家很灵活其实每加一家菜贩你都得回去改一遍大厨的脑子。所以我得把一句话说透解耦真正的难点从来不是你有几家可以换而是每家接口都长得不一样你得有一个统一的抽象层把它们抹平。采购总管就是这个抽象层。有了他你的大厨这辈子只需要认识一个人。大厨要料只管跟总管说给我一份能力中等的模型把这段话总结一下至于总管背后是打给了 A 摊位还是 B 摊位、用的什么暗号什么结算方式大厨一概不用管、也不该管。大厨只认一个入口供应商之间的差异全塞进采购总管的脑子里消化掉。这样一来你哪天想再加一家新供应商动的是采购总管的通讯录大厨那边一个字都不用改。落到工程上这个统一入口通常长成一个兼容 OpenAI 格式的调用地址agent 代码只对着这一个地址说话而那份供应商清单配在网关这一侧。拿业界常见的一种网关配置举个例子它大致是这么个结构注意这里的密钥、地址全是占位真实环境里绝不能这么明晃晃写出来model_list:-model_name:primary-coderlitellm_params:model:provider-a/coder-modelapi_base:os.environ/PRIMARY_MODEL_BASE_URLapi_key:os.environ/PRIMARY_MODEL_API_KEY-model_name:backup-coderlitellm_params:model:provider-b/coder-modelapi_base:os.environ/BACKUP_MODEL_BASE_URLapi_key:os.environ/BACKUP_MODEL_API_KEY你看这份清单primary-coder和backup-coder是大厨嘴里喊的名字底下provider-a、provider-b才是真正的菜贩。大厨只喊名字喊哪个由总管的路由规则说了算。密钥和地址一律用os.environ这种环境变量占位来引绝不写死在配置里——这条后面讲安全时我还要专门回来敲。不想自己搭也有现成的总管可租讲到这儿你可能会问这么个总管非得我自己从头搭吗不一定。市面上也有现成的托管型采购总管可以直接租最典型的就是一类聚合路由服务——它一家就替你接通了一百多个模型还提供好几种现成的派单策略有主打省钱和速度平衡的、有主打把吞吐拉满最快出结果的、也有主打把工具调用准确率做到最高的。你把订单丢给它它替你在背后挑摊位。以 OpenRouter 当前公开收费为例它会按底层供应商的公开价格透传模型费用但在购买额度或使用自带密钥时另收费用用 Stripe 购买额度收 5.5%最低 0.80 美元用 Coinbase 购买额度收 5%使用自带密钥也按调用成本收 5%。所以这笔钱不能笼统理解成“所有 token 单价统一加 5%”而要看你怎么充值、是否使用自带密钥。值不值得得你自己算图省心、不想自己养一套就把它当成省心费量大到自己搭更划算那就自己搭。这里不替你站台任何一家只告诉你有这么条路。三、第二件事·会兜底不是无脑换摊是先分清真断供还是你写错了比价解决的是钱花得值不值兜底解决的是另一个更要命的问题——别停火。你厨房正忙着出餐主力菜贩那边突然出岔子要么限流不接单了、要么额度用完了、要么服务器直接挂了。这时候一个称职的采购总管会立刻拎起备用摊位的电话把订单转过去保证你灶上的火一秒都不断。这就是 fallback失败兜底。落到工程上它一般由这么几个旋钮拿捏我给你翻成人话重试几次num_retries一家没打通先原地多打两次电话说不定就是网络抖了一下。切给谁fallbacks主力这组彻底不行了切到哪个备用摊位组去。失败到什么程度才拉黑allowed_fails这不是错一次就拉黑而是一段时间内错够了几次才把这家先晾一边。晾多久cooldown_time被晾起来的摊位冷静多长时间再重新给机会。这几个旋钮不难懂。但真正的坑不在旋钮怎么拧而在一个特别容易被忽略的判断上——哪些错该兜底哪些错碰都不能碰我把最扎心的一句话先撂这儿fallback 不是一个模型挂了就无脑换另一个。你想想采购总管接到这单没成的回话他得先分清这是哪一种没成第一种是菜贩那头真出事了。排队排爆了429、这个月的额度用光了、后厨着火了5xx 服务器错误、电话占线打不通超时、连接中断。这类是该兜底的——不赖你赶紧切备用摊位天经地义。第二种是你这头的单子本身就写错了。你报的暗号根本不对401/403也就是密钥、权限配错了、你点了一道菜单上压根没有的菜invalid model模型名写错了、你的订单格式乱七八糟人家看不懂请求体或工具描述格式错误。这类是碰都不能碰兜底的。为什么因为你把第二种错当第一种去兜底就等于亲手把真 bug 埋进土里。举个最典型的你的密钥配错了主力摊位回你一个 401。要是总管傻乎乎地当成人家断供了立刻切到备用摊位——备用摊位的密钥要是碰巧是对的这单还真就成了。表面上风平浪静一切正常。可实际上呢你主力那家的密钥一直是错的你永远不知道直到某天备用也挂了整条链子哗啦一下全塌你才手忙脚乱地回来查发现这个错早就存在了几个月。所以这句话你得记死把 401 当 429 去兜底你就永远发现不了真正的 bug。兜底是用来扛不可抗力的不是用来替你掩盖配置错误的。这两件事一旦混为一谈你的系统会用一种看起来很健康的方式慢慢烂掉。有一样东西上线前必须亲口尝一遍讲兜底还得多提一句特别实在的工具调用tool call是 POC 阶段必须亲测的一项。现在的 agent 干活很多时候不是光聊天是要真去调工具的——查个天气、跑个查询、调个接口。这个能力能不能稳不光看你 agent 写得好不好还看两头一头是你切过去的那个备用模型它到底支不支持工具调用另一头是采购总管这个中转它有没有把工具的描述、调用指令、流式返回这些字段一个不漏地原样传过去。这里最容易翻车的就是兜底那一刻平时主力模型好好的工具调用一切正常你以为稳了。结果哪天主力挂了总管把订单切到备用摊位——偏偏这家备用模型压根不支持工具调用或者中转时把工具字段给弄丢了。你的 agent 当场就傻了。所以别等上线才发现。你选备用摊位的时候就得把它支不支持工具调用、切过去之后工具还灵不灵当成一道必答题亲口尝一遍再定。备用摊位不是随便拉一家来凑数的它得能在关键时刻把主力的活儿接得严丝合缝。四、第三件事·会记账让每一笔钱都花得明明白白比价省了钱兜底保了命可还有一件事没干——这些钱到底花哪儿去了这就是采购总管的第三项本事会记账。你想想一个不记账的采购哪怕他再会砍价、再会兜底月底你也是一笔糊涂账这个月买菜花了多少钱哪道菜最烧钱是哪个厨子、哪个窗口点的料最多走的哪家摊位一问全懵。这种看不见钱去哪了的状态才是成本失控最深的根子。会记账的采购总管是把每一笔进货都落到账本上的给每个来要料的人发一张专属的记账卡virtual key谁刷的卡一清二楚给每张卡设一个花钱的上限budget到顶了自动拦住不让某个窗口一顿乱点把整月预算烧光每一笔都记下花了多少、走的哪个摊位、哪个模型用量统计 命中模型记录。这么一套记下来你就能回答那个最关键的问题谁、用了多少、走了哪个模型、花了多少钱。每一项都可观察、可归因。我一直觉得记账这件事是所有成本治理的地基。你连钱花在哪都说不清谈什么优化、谈什么降本全是空中楼阁。你砍不动一笔你根本看不见的开销。只有先把账记明白了你才知道哪道菜在偷偷烧钱、哪张卡该收紧、哪个模型的性价比其实虚高——所有的省钱动作都得从这本账开始。五、别急着造平台分阶段落地先跑通再补台道理讲到这儿你可能已经跃跃欲试想搭一个功能齐全的采购总管出来了。先按住。这里最容易犯的错就是一上来就想做平台——又要路由、又要兜底、又要记账、又要管理后台、又要多租户权限恨不得一步到位搭个大而全的东西。结果往往是链路还没跑通先陷在管理后台的泥潭里出不来。我给你一个更稳的顺序先分清两类活儿的定位差异。市面上这类工具粗略分两个流派。一类偏调用链路的治理——它管的是请求怎么进来、怎么路由、失败怎么兜底、成本怎么观测核心是把你和模型之间那条调用链路做稳。另一类偏资源和渠道的管理——它管的是有哪些模型渠道、谁能用、额度怎么分、后台怎么看核心是把一堆模型资源管起来、分出去。这两类不是二选一而是有先后的。落地的正确顺序是先把调用链路跑通再按需补管理后台。为什么这个顺序不能反因为调用链路是命脉——它一断你的 agent 当场就歇菜而管理后台是锦上添花——没有它你顶多是管理不方便但活儿照跑。先保命再谈舒服。你连稳定调用都还没做到就先花大力气搭一个漂亮的后台那是本末倒置。至于具体用哪个开源项目来搭我在这里只做个点到即止的盘点不替你种草——这些数据都是公开的、随时在变你真要选型务必自己上去核一遍最新的有的项目主打接得最多号称接通上百种模型是社区里事实上的首选star 数五万开外主仓库大部分代码采用较宽松的 MIT 许可但enterprise/目录另有独立许可商用前仍要按实际使用范围核对。有的项目主打国内的渠道分发和资产管理后台、计费、权限做得全中文模型开箱即用star 数四万上下用的是更严格的传染性开源许可AGPL-3.0——这个许可条款你商用前一定要看清楚别踩坑。这两条路其实对应了两种不同的需求LiteLLM 走的是调用链路治理路线——把路由、fallback、计量、virtual key 全收在网关层适合你已经有模型供应商、需要一条统一入口的场景New API 走的是资源渠道管理路线——把渠道接入、额度分配、用户权限、计费对账做成一个管理后台适合你需要把模型资源分发给多个用户的场景。两条路不冲突但你得先想清楚你到底要解决调用链路稳定还是模型资源分发——选错了再好的项目也不好使。我得再强调一遍以上 star 数是公开数据、随时会变各家宣称的性能也大多是项目自述、没经过独立验证。别拿别人的宣传当你的结论。选型这事方法比结论重要——先想清楚你到底要治理调用链路还是管理模型资源再去挑对应流派里维护得最活跃、许可证最合你意的那个自己跑个小样验一验。六、最后一道红线这个总管手里攥着你全部的秘密在收尾之前有一件事我必须单拎出来郑重地跟你说——安全。你想想采购总管这个位置有多敏感你厨房里每一道菜的完整配方、每一次跟菜贩的通话内容、你手里所有摊位的暗号和结算账户全都要从他这里过一遍。他是整条链路上唯一一个什么都看得见的人。翻译成技术语言就是模型网关会经手完整的 prompt、上下文、工具调用参数还有一部分响应内容。这意味着安全边界必须在设计的第一天就摆上桌而不是等出了事再补。几条红线你焊死了记住真实密钥绝不落地。不在日志里记真实的 API Key不把内部的真实调用地址暴露出去日志该脱敏就脱敏。前面那份配置里我为什么全用os.environ占位就是这个道理——密钥只从环境变量里读绝不写死在任何一份会被别人看到的文件里。权限和密钥要隔离。谁能用哪张卡、谁能碰哪个渠道得分得清清楚楚敏感数据存多久也得有个说法不能无限期堆着。公开场合只能出现抽象的东西。你写文档、发文章、做分享能出现的只有抽象的模型名、环境变量占位、本地示例地址、通用的架构图。绝不能出现真实的密钥、Token、真实的内部地址、客户的私有账号、真实的业务请求内容、还没公开的成本和业务数字。这一条不是可有可无的补充说明。采购总管权力越大越要给他立规矩。一个能看见你全部秘密的人你不给他划死红线那不是信任而是把家门钥匙连同密码本一起交出去。七、写在最后咱们把这一篇的心思收一收。上篇讲的是病根——只认一家菜贩进货你就把定价权、稳定性、议价的底气全交到了别人手里。这一篇讲的是那味药——请一个采购总管把这三样东西一件件夺回来。我知道很多人一提模型网关脑子里就是多接几家 API、写个转发层。可你回头看这一整篇真正值钱的从来不是你接通了几家供应商而是这个总管到底会不会那三件事——会比价。该省的订单绝不打到贵摊位同一档位的食材便宜的那家你用一个月的钱够你在贵的那家用一天就看你舍不舍得把常识题和专家题分诊开。会兜底。一家断供立刻切备用但绝不无脑乱切——先分清是人家真出事了还是你自己单子写错了。把 401 当 429 去兜底你就永远揪不出那个早就埋下的真 bug。会记账。每一笔进货走哪个摊位、花多少钱、谁点的料全落在账本上。你砍不动一笔你根本看不见的开销——记账是所有省钱动作的第一块地基。说到底模型网关不是多接几家 API 当接口人而是给厨房配个会比价、会兜底、会记账的采购总管。你要的从来不是多几个菜贩的电话而是一个替你把关、替你兜底、替你算账的人。把定价权、稳定性和风险重新握回自己手里——这才是你真正要请这个采购总管的理由。只认一家菜贩是把厨房的命脉拴在别人的心情上请个采购总管才是把厨房的账本、灶火和底气一样样收回自己名下。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline