疑问一：AI词元服务器为何比普通Web服务器更‘吃’网络？
本周事故的根因并非带宽不足，而是词元（Token）级流量特征。传统Web请求是“长连接、大报文”，而AI推理服务（如LLM生成）会产生高频、小包、突发的词元流——单次推理可能拆分出数千个仅几十字节的UDP包。IDC的交换设备默认缓存队列是按大报文设计的，小包突发瞬间打满队列，触发尾丢弃（Tail Drop），即使总带宽利用率仅40%，也会出现毫秒级抖动。SRE需在接入层开启显式拥塞通知（ECN），并对AI服务器网卡启用DCTCP（数据中心TCP）算法，而非传统CUBIC。
疑问二：为什么‘加带宽’治标不治本？
本周复盘会上，有人建议将客户带宽从10G升到20G。但实际流量模型显示：AI任务存在同步屏障（Barrier）——当所有GPU等待最慢节点时，网络瞬间空闲；一旦屏障释放，所有节点同时发送checkpoint数据，形成“洪峰”。线性扩容只会让峰值更高，但洪峰期间的微突发依然存在。我们最终采用的方案是在IDC出口部署基于AI预测的流量整形器：利用LSTM模型预测未来200ms内的词元流量趋势，提前在边缘交换机调整WRED（加权随机早期检测）丢弃概率，让突发包在源端附近被平滑，而非在核心层丢弃。
疑问三：软件层面能否替代硬件网络调优？
不少SRE倾向用软件层重传机制兜底，但本周事故证明：重传救不了实时推理。客户的大模型服务要求P95延迟低于50ms，一旦发生TCP超时重传，用户可直接感知到“生成卡顿”。我们本周的解决思路是混合软硬协同：硬件侧，在IDC机架交换机上启用基于INT（带内网络遥测）的路径检测，每微秒采集队列深度；软件侧，开发了词元级路由嗅探器，当检测到某链路队列深度超过阈值，立即通过BGP Flowspec规则将后续词元流切换到备用光路，切换耗时从传统秒级降至120ms内。这个补丁已在周四上线，事故复现测试中，丢包率从2.3%降至0.02%。
本周核心结论：AI负载下，SRE必须从“带宽思维”转向“时延敏感型微突发治理”。建议每季度做一次小包风暴演练，并检查交换机buffer是否支持动态分配（如Broadcom Jericho2芯片）。若您也遇到类似问题，欢迎在评论区留下您的队列深度参数。
0 留言