企业规划 AI 推理集群时，网络讨论容易集中在 GPU 节点之间的东西向通信，却低估了南北向路径。用户请求从 API 网关进入，流式 Token 持续返回；新节点启动时拉取容器和模型制品；负载均衡器频繁执行健康检查；指标、日志和追踪又向可观测平台输出。平稳运行时这些流量可能互不显眼，集中扩容、版本切换或故障恢复时却会同时放大。若所有流量共享同一入口、出口和队列，一个模型加载风暴就可能拖慢在线请求。
先按生命周期拆分流量
请求路径关心连接建立、排队、首 Token 和持续返回；模型加载关心大对象吞吐、并发下载和校验；健康检查数据量小但频率高，错误阈值会直接触发摘除；遥测通常可缓冲，却可能在异常时爆发。容量模型应分别记录平均、峰值、突发持续时间和失败后的重试行为。不能把日流量除以秒得到一个平均带宽，再据此设计入口。真正决定稳定性的往往是五分钟扩容窗口或大面积重连。
流式推理改变连接模型
与短 HTTP 请求相比，流式响应会保持连接并持续发送小块数据。入口代理、负载均衡、服务网格和防火墙需要同时承受连接数、状态表与字节吞吐。超时、空闲检测和客户端取消必须端到端一致，否则中间层可能关闭仍在生成的会话，后端继续占用 GPU。测试应覆盖慢客户端、移动网络重连、请求取消和输出长度上限，而不是只在同一局域网用固定并发压测。
模型加载要有独立的放大系数
一次扩容可能让多台节点同时下载相同模型。若每台都从远端对象存储拉取，出口、存储网关、DNS 和认证服务会形成共同热点。可通过分层缓存、预热、限速和分批放行降低冲击，但每种机制都要验证一致性和失败处理。缓存命中不能牺牲模型版本确认；下载完成也要校验制品摘要，防止节点加载了同名不同内容的文件。模型加载流量不一定适合与实时请求享受相同优先级。
健康检查要反映可服务状态
进程存活不代表模型已加载，更不代表后端具有接收新请求的余量。启动探针、就绪探针和存活探针应承担不同职责，并为大模型加载留出合理窗口。过于激进会制造重启循环，过于宽松又让故障实例长期接流量。建议把模型版本、必要依赖和最小推理检查纳入就绪判断，同时避免让每次检查执行昂贵生成。大规模集群还要给健康检查本身做频率预算，防止控制面成为持续噪声源。
故障设计必须覆盖入口之外
多入口并不自动等于高可用。DNS、证书、鉴权、配额、路由、模型仓库和遥测后端都可能在关键路径。应明确每个依赖故障时系统选择拒绝、降级、缓存还是继续服务，并验证连接中的请求如何处理。若跨机房部署，还要考虑状态与模型版本一致性，不能让流量切到尚未完成预热的站点。网络团队与推理平台团队应共享一张依赖图和同一套演练时间线。
上线前的容量与故障演练
- 分别构造在线请求、流式返回、模型加载、健康检查和遥测流量，记录各自峰值。
- 模拟批量扩容与模型切换，观察入口、出口、仓库、DNS 和认证服务的队列。
- 验证客户端取消、慢速读取、代理超时和后端摘除后的连接行为。
- 中断模型仓库或遥测后端，确认在线请求按预定策略继续、降级或拒绝。
- 在单入口、单可用区和跨站点故障下测量恢复时间，并保存请求级失败分布。
推理网络的目标不是追求所有链路长期低利用率，而是在突发、扩缩容和依赖故障时仍能保护关键请求。Triton 模型仓库、模型控制模式和加载行为可从 NVIDIA Triton Inference Server 模型管理文档核对。实际入口架构还需结合所用网关、编排平台和模型服务版本验证。
WeChat
Profile