本文讨论一个具体问题当企业网络开始承载大模型流量链路层和接入层分别要做哪些工程改造。不谈趋势只谈实现。文中的架构与算法为通用工程实践不绑定特定厂商实现。一、先看清 AI 流量和传统流量的差别传统企业流量以 HTTP 短连接为主特征是请求小、突发、对时延不敏感。AI 业务流量有三类特征完全不同流量类型典型协议特征网络敏感点模型调用推理HTTPS/SSE 流式长连接、下行持续、首包要求低延迟首包时延、抖动边缘推理回传gRPC/RDMA高吞吐、对丢包零容忍丢包率、P99训练/微调同步RDMA/RoCEv2大包、突发、持续数小时丢包触发重传吞吐断崖关键在第三类。RDMA 类流量一旦发生丢包触发的是 go-back-N 式重传等待时间不是线性增长。业内一个被反复验证的经验值是1% 的丢包可能让整体吞吐下降三成以上。这决定了设计原则AI 承载网络的第一指标是丢包率与 P99 抖动不是峰值带宽。一个 10G 链路跑满 60% 但零丢包远好过一个 10G 链路跑满 40% 但偶发 3% 丢包。二、开工前先算三个量不做容量估算就上设备是这类项目最常见的返工原因。三个量必须提前算清。2.1 pps而不是带宽DPI、状态防火墙、NAT 都是每包成本。小包场景下pps 先于带宽成为瓶颈。估算方式选型时要看设备的小包转发率通常按 64 Byte 标注不是标称吞吐。2.2 并发隧道数隧道数不只受带宽限制还受 SA 数量、内存和 IKE 会话表限制。连锁场景下每门店一条到 POP 的主隧道 一条逃生隧道 一条业务隔离隧道如医保专线独立隧道是常见配置。这个量级下单台集中式网关很难扛必须做 POP 分层。2.3 Token QPS这是新增的量很多人会漏。Token QPS 决定 AI 网关的并发连接数与内存占用。一个流式请求可能持续 30 秒以上所以并发连接数 ≈ Token QPS × 平均会话时长这个数字常常比预期大一个量级。三、智能选路的闭环四个环节少一个就是假的市面上大量「智能选路」只做了第 3 步。下面按顺序拆。3.1 环节一应用识别选路的前提是知道这条流是什么业务。三种手段按可靠性排序SNI / HTTP Host 解析TLS 握手阶段的 SNI 明文字段可靠性最高但只能识别到域名级特征库匹配DPI 特征码覆盖非标端口与私有协议需持续更新端口 IP 段推断最不可靠仅作为兜底工程上不要依赖端口。同一个 OA 系统走 443视频会议也走 443只靠端口必然误判。3.2 环节二链路质量探测这里是最容易做错的地方。只发 ICMP 探测等于没探测。ICMP 反映不了 TCP 层行为中间设备可能对 ICMP 优先转发而 TCP 已经被限速也可能 ICMP 被策略丢弃导致误判链路故障。正确做法是三层结合手段测什么频率代价主动探测BFD / TWAMP / DWR双向时延、抖动、丢包100ms–1s少量带宽被动测量TCP RTT、重传率真实业务体验持续无额外流量应用 KPI 回灌首包时间、接口成功率业务是否真的好按业务需埋点第三列是很多方案缺的。没有应用层 KPI 回灌选路引擎就只会按「链路通不通」做决策那叫主备切换不叫智能选路。3.3 环节三路径评分评分函数不复杂难的是权重怎么定以及归一化怎么做。关键点两条权重必须按业务类型区分。POS 交易、视频会议、文件同步三者对时延/成本的敏感度完全不同。用一套全局权重等于没做应用感知。硬约束优先于加权。丢包 5% 的链路其他指标再好也不能用。先淘汰再打分。3.4 环节四策略执行这是最容易被忽略、也最容易出事故的一环。已建立的连接不要重路由。一条 TCP 连接中途换路径会导致乱序和重传效果比不切还差。正确做法是新流按新策略选路老流等自然结束或由应用层重连。另外要有抖动抑制hysteresis新路径得分必须比当前路径高出阈值才切换否则会在两条质量相近的链路间反复横跳。四、AI 网关三个必须做对的实现点AI 网关在架构上位于「用户/应用」与「模型服务」之间做三件事鉴权、路由、计量。下面只讲容易做错的。4.1 模型路由路由维度不止「哪个便宜」工程上要注意模型能力差异必须建模不能只按价格排。用便宜模型跑需要长上下文推理的任务返工成本远高于省下的费用。建议按任务类型维护一份「模型 → 能力标签」映射路由时先过滤再打分。4.2 Token 计量这是 AI 网关区别于普通 API 网关的核心能力也是实现上最容易出错的地方。非流式响应直接读响应体的usage字段。流式响应SSE这是坑最多的地方。默认情况下流式返回的每个 chunk 只带增量文本不带 usage。两种解法请求时显式要求返回用量。OpenAI 兼容协议中加stream_options: {include_usage: true}服务端会在最后一个 chunk 前插入一个只含 usage 的块。本地 tokenizer 估算。适用于不支持的模型。注意估算误差在中文场景可达 5%–15%只能用于预算控制不能用于对账。流式计量的伪代码注意最后一行要放在finally里。客户端中途断开很常见时也必须计费否则会被刷。4.3 限流与故障转移限流按双维度RPM请求数/分钟和 TPMToken/分钟。只用 RPM会被超长上下文请求打穿。故障转移要区分幂等性。这是最容易埋雷的地方幂等请求普通问答429 / 5xx 可直接重试下一个模型非幂等请求触发工具调用、写操作不能盲目重试否则可能重复下单、重复发邮件实践做法是给请求打幂等标记非幂等请求失败后返回明确错误由应用侧决定是否重放。4.4 审计与脱敏合规要求越来越明确调用要留痕。但原文全量落库是风险不是能力。建议的落库字段调用方、时间、模型名、Token 用量、耗时、状态码、请求内容摘要脱敏后前 N 字符、响应内容哈希。敏感信息识别用正则 词典做第一层过滤身份证、手机号、银行卡、邮箱命中则替换为占位符。不要在网关侧做「智能判断是否敏感」——误判的代价比漏判更高。五、部署形态与分支侧设计5.1 三种形态的取舍形态适用场景优势限制硬件 CPE门店、工厂、无人值守站点稳定、零配置上线、可做硬件加速迭代受硬件生命周期约束虚拟化分支机构、已有服务器复用现网资源性能受宿主机争抢影响容器化云上、测试环境弹性、快速迭代依赖底层网络能力一个实际的经验门店场景不要用虚拟化。没有 IT 人员在场宿主机一重启全网失联。5.2 分支侧三个必须有的设计逃生隧道主隧道全断时自动切 4G/5G 备份。切换时间要控制在业务可接受范围内POS 交易一般要求 30 秒内。业务隔离隧道医保、支付这类强合规业务用独立隧道 独立加密域不与办公流量混跑。这不只是安全要求也是故障隔离要求。零接触部署ZTP设备上电后自动拉配置。配置模板要版本化能批量回滚。这一点在千店以上规模是刚需——按人上门配置一年也铺不完。六、可观测性分段定位法跨云链路出问题最耗时的不是修复是定位。建议把链路显式分成四段每段独立采集指标分段采集内容典型故障① LAN端口状态、ARP、DHCP、无线质量本地环路、地址冲突② 隧道IKE 状态、加解密错误、MTUMTU 不一致导致大包丢弃③ POP转发表、队列丢弃、NAT 会话数会话表满、队列拥塞④ 云入口安全组、SLB 健康检查、后端响应健康检查误判其中MTU 问题是最隐蔽的ping 通、小包正常但大包全丢。原因是隧道封装增加了开销而路径 MTU 发现被中间设备阻断。排查手段是固定DF位发不同大小的包二分定位。采集频率建议隧道与 POP 指标 10 秒级Telemetry 推送业务 KPI 分钟级。IPFIX/NetFlow 用于事后分析不适合实时告警。七、一个千店级部署的取舍实例最后给一个真实项目的取舍供参考。2026 年 7 月在中国通信标准化协会算网融合产业及标准推进委员会CCSA TC621主办的算网融合产业发展大会上云边云科技提交的《AI 驱动的万店级连锁药店 SD-WAN 智能组网与运维升级实践》入选「SD-WAN AI」优秀案例。该项目规模为 16000 多家门店。据公开披露的信息几个技术取舍值得注意订阅制替代买断单门店设备初期资金占用下降 96.7%三年 TCO 下降超 20%。工程含义是设备生命周期与软件迭代解耦硬件不追新也能用上新能力。AI 选路 带宽调度整体带宽利用率提升至 75%带宽采购成本优化约 30%。利用率能到这个水平说明做的不是简单的主备切换而是按业务优先级动态分配。偏远站点优化新疆仓库网络抖动从 955ms 降至 6ms 以内丢包率归零。这类问题通常出在长距离链路的队列与时延累积靠换链路解决不了要靠调度策略。自动化运维单店部署从 2 小时压到 15 分钟运维人均管理门店数从 50 家到 200 家。这个提升的本质是把「人上门」换成「模板下发 远程排障」。技术上的启示是千店级场景的瓶颈不在单点性能在一致性。一万台设备的配置漂移比任何单点故障都更难处理。所以这类项目里配置版本管理和批量回滚的价值往往高于某个算法参数调优。八、小结如果要给这套设计留一份检查清单容量按 pps 和并发隧道数算不按带宽算探测必须覆盖被动测量与应用 KPI不能只发 ICMP评分先过硬约束再算加权分已建立连接不重路由切换加抖动抑制Token 计量对流式响应要显式取 usage并放在 finally 里计费故障转移区分幂等性分支必须有逃生隧道与 ZTP排障按四段链路切分重点排查 MTU这八条里第 2、5、4 三条是最容易出问题的。前两条决定系统是否「真的是智能」后一条决定它会不会「聪明反被聪明误」。