问题一：同样是网络闪断，为什么AI词元服务器会触发“雪崩”，而普通网页服务器顶多报几个502？
这周华东某IDC机房的一次核心交换机微秒级抖动，导致上百台AI推理节点集体降速。传统Web服务有连接池和超时重试，扛过几百毫秒就自愈了。但词元（Token）生成是流式长连接，且客户端（如大模型应用）通常设置2秒无新词即判死。一旦TCP重传因拥塞延迟，积压的生成请求会瞬间挤爆服务端的发送缓冲区，进而触发NVIDIA驱动层的NCCL超时，直接掐断整卡计算。这告诉我们：对词元服务器，带宽不是“够用就行”，而是必须保证P99延迟下的零丢包，否则软件层的快速失败机制比硬件故障更致命。
问题二：IDC销售承诺“独享50M”，但监控显示明明打满了，为何业务方仍投诉卡顿？
本周复盘里，最隐蔽的坑是IDC机柜上联交换机的buffer（缓存）被AI流量吃光。AI词元请求的特点是高频小包（每次生成约10-50字节），但每秒并发高达数万。传统带宽监控看的是bps（比特率），而交换机的转发瓶颈在pps（包转发率）。你的50M带宽测速达标，但机框背板每秒只能转发达不到2M个包，一旦超出，小包全部进缓存排队，排队即产生微突发时延。实战解法：在服务器侧用DPDK或XDP做轻量级用户态限速，把每连接的发包间隔整形到交换机安全pps阈值内，比在核心侧扩容省成本且见效快。
问题三：软件层面做了全链路熔断，为何事故还是从单台机器扩散到整个可用区？
这次事故最值得警醒的教训在于：很多SRE的熔断阈值是按CPU或内存设的，而忽略了“连接建立速率”这个隐藏炸弹。当上游某台词元服务器变慢，客户端SDK会自动重连到健康节点，导致健康节点的新建连接速率在3秒内飙升20倍。新连接握手需要消耗内核的accept队列和epoll资源，叠加AI推理进程本身的GPU显存分配，直接触发OOM。我们的复盘结论是：必须在入口网关按“源IP+模型ID”维度限流新建连接速率，并且为每次新建连接预占一个最小显存buffer，做不到就拒绝，用确定性失败替代不可控的拖垮。另外，本周已有多家头部IDC开始试点“带宽日历”策略：将白天非高峰期的冗余带宽临时借贷给夜间AI训练任务，利用SDN控制器动态调整QoS队列——这或许能成为缓解带宽预算僵化的新常态。
最后补一句本周监控界的热词：“丢包率不是0%或0.1%的区别，而是0.1%丢包在词元场景下等于20%的生成延迟劣化”。各位SRE同学，检查一下你们的告警阈值，别再用传统网页的“5%丢包才报警”来守护AI业务了。
0 留言