Q1：AI词元请求为什么能瞬间吃满服务器带宽？
很多人以为推理流量不大，其实关键在响应侧的流式输出。本周事故中，客户接入的是流式词元接口，单个长上下文会话峰值可达数十Mbps，并发一上来，千兆口几分钟就顶到95%。复盘结论：AI业务选带宽不能只看平均值，要按并发会话数 × 单会话峰值速率 × 1.5做容量预留，并给推理集群单独划分VLAN和带宽池，避免和常规Web业务抢同一条上行。
Q2：带宽告警设多少才不误报？
只盯80%阈值容易两头误判。我们本周调整为三段式：70%预警（观察趋势）、85%告警（准备限流或扩容）、95%紧急（自动触发QoS降级）。同时把P95和P99速率纳入看板，因为AI流量是脉冲式的，均值毫无参考价值。补充提醒：IDC侧的端口带宽和服务器网卡速率要对齐核查，本周就有一台机器网卡协商成了百兆，白白背了半小时锅。
Q3：限流会不会影响AI业务体验？
会，所以要分层限。本周实践是按词元接口优先级做QoS：核心推理接口保底带宽，批处理与日志上报类流量可降级；单IP并发会话数设上限，防止个别客户端拖垮整台机器。限流阈值上线前先在灰度环境跑了两天压测，确认P99延迟增幅在可接受范围内再推全量，这是这次复盘里最值得保留的动作。
Q4：网络软件层面还能做什么？
除了加带宽，软件侧的收益很直接：开启网卡多队列与RSS分散软中断；检查内核TCP参数，AI长连接场景下适当调大somaxconn与tw_reuse；对推理服务前置一层轻量代理做连接复用，减少重复握手开销。本周某节点仅调整多队列绑定，单机吞吐就提升了约18%，比直接扩容划算得多。
Q5：事故复盘怎么落到机制上？
本周复盘形成三条硬性动作：一是AI业务上线必须提交带宽容量测算表；二是IDC机架端口速率与网卡协商状态纳入每日巡检脚本；三是每季度做一次单机架带宽打满演练，验证限流与告警链路真的能触发。事故不可怕，怕的是复盘只写不查——下周我们会回头验收这三项，而不是等下一次凌晨被打满。
0 留言