直连和经网关有什么区别？适用场景分开讲

先把结论放上来：大模型服务的内部系统之间、调用方单一、追求最低延迟的链路，直连更合适；对外开放、调用方众多、需要统一鉴权限流的场景，经网关更稳妥。直连和经网关的区别，不在快慢一词，而在「链路里多了什么、少了什么」。

直连就是调用方拿着服务地址直接发请求，中间不加任何环节；经网关则是所有请求先到一个统一的入口层，由它转发给后端服务。扣子这类编排平台把多家模型接口收拢成统一入口，扮演的就是网关角色；纳米AI 的聚合调用思路也类似——入口统一，后面各走各的。

先说结论：什么场景要过网关

三种信号出现时，就该考虑网关了。一是调用方多了：几十个业务都直连同一个服务，鉴权凭证、限流策略、地址变更通知要复制几十份，管不过来。二是对外开放了：外部调用方的行为不可控，必须有统一的一层做身份校验、流量整形和滥用拦截。三是链路变复杂了：后端有多个版本、多个供应商需要按规则分发，直连没法承载这种路由逻辑。三条都不占，直连就是更轻的选择。

直连路径快在哪

直连省掉了中间一跳，请求从调用方直达服务进程，少一次转发、少一排队列、少一层序列化反序列化。对延迟敏感的内部链路，这一跳能省下可观的毫秒数，同时故障点也更少——网关本身宕机这种事在直连架构里不存在。代价是每个调用方各自维护地址、凭证和重试逻辑，服务一迁移，所有调用方跟着改配置。

网关拦下了哪些麻烦

网关的价值不在转发，而在拦下三类麻烦。第一类是安全麻烦：鉴权、鉴权后的配额校验、恶意流量的拦截，统一在一层做完，后端服务保持干净。第二类是运维麻烦：后端地址变更、版本切换、按权重分流，都在网关改配置，调用方无感。第三类是观测麻烦：所有请求过同一道门，日志、指标、链路追踪天然齐全，故障排查时有一条完整的请求轨迹可查。Kimi、豆包这类服务对外开放的接口之所以稳定可控，背后的入口层功不可没。

延迟与排查的取舍

两边的代价要摆在一起看。经网关多一跳，正常情况下增加几毫秒，网关过载时排队会放大延迟——这是买「统一管理」要付的价格。直连省了这一跳，但出问题时排查要靠各调用方自己的日志拼图，跨团队的故障定位常常拖成长尾。选择的关键问题是：你的场景更怕延迟抖动，还是更怕治理失控。

直连与网关对照表

• 内部少调用方、极限追延迟：直连
• 对外开放、多调用方、要统一治理：经网关
• 直连省一跳但配置分散，网关多一跳但运维集中
• 排查：网关有统一链路轨迹，直连靠日志拼图

入口定了，链路后面还有文章。后端成本怎么算，见API 调用和本地推理差在哪？成本模型；框架选型影响网关转发行为，参考推理框架之间是怎么比的？分界点在哪；算力计费模式怎么挑，看预留和按量有什么区别？一张表分清；新版本发布走网关分流时，蓝绿和灰度有什么区别？边界一次说清讲了两条路线。

换个问法再问直连网关三句

• 网关会不会成为单点？：网关自身要集群部署加健康探测，设计良好的网关层比散落的直连配置更抗故障，偷懒单点部署则真的会变成单点。
• 能不能又直连又走网关？：能，常见的做法是外部流量统一走网关，内部高频链路保留直连，按安全边界划线。
• 网关超时怎么设？：覆盖后端最长响应加转发余量，同时区分普通请求与长生成请求的超时档位，一刀切超时会误伤长任务。