你的业务把命运押在一家模型 API 上，迟早会遇到一次：它限流、它涨价、它抽风返回空。前面放一层网关，把多家供应商挂在同一个 OpenAI 兼容地址后面，是性价比极高的保险。Portkey 是这类网关里上手较快的一个。
模型网关到底解决什么问题？
不是又一个聚合 API，而是三件事：故障自动兜底，主供应商超时就切备线；按规则路由，简单问题走便宜模型、复杂问题走强模型；以及统一可观测，所有请求的 token、延迟、错误集中在一处。上层代码只认一个 base URL。
最小配置该怎么搭？
起一个 Portkey 实例，配置里登记多家供应商的密钥，定义一条策略：默认走主模型，连续失败两次或超过超时阈值就切到备用，备用再失败切第三家。设置重试次数与退避间隔。对上层应用，请求格式完全是 OpenAI 兼容的，改一个 base URL 就接上了。
多模型路由策略怎么定？
别让所有请求都走最贵的模型。按任务复杂度分桶：分类、摘要、抽取这类结构化任务走便宜模型；创作、推理走强模型。网关支持按请求内容或元数据路由，这套分流本身就能把账单砍掉一截。
自动兜底有什么隐患？
自动兜底会掩盖问题——主供应商明明在持续故障，被备线悄悄兜住，你可能几周都没发现。务必打开告警：当兜底触发次数超过阈值就通知，让你知道主链路出了状况，而不是被备线蒙在鼓里。
密钥和账单该怎么管？
多家供应商的密钥统一收在网关节点，别散落在各个业务服务里，方便轮换和吊销。更实用的是账单视角：网关把所有请求归一后，你能清楚看到每个模型实际被调了多少次、花了多少。很多团队第一次看这张表才发现，一个没人维护的旧接口每天还在偷偷调用最贵的模型——关掉它就是纯利润。这种盲区，不用网关你永远看不见。
多供应商兜底值不值得现在上？
多供应商兜底不是大企业专属，一个网关配置就能让你的智能体在某家模型抽风时不挂。把它当成基础设施保险，成本极低，关键时刻能保住一整个下午的在线服务。