如果你刚接手AI推理业务的IDC运维，看到“词元服务器”和高并发同时出现，很容易只盯着GPU利用率。但本周我们处理的一个真实案例恰恰说明：瓶颈往往先出现在带宽和网络软件层。
案例背景：某AI平台部署在华东某IDC，提供大模型词元级流式输出。上周因产品活动，并发请求从日常5k QPS飙到约22k QPS，首词元延迟从180ms恶化到1.2s，部分节点开始丢包。硬件没有变，变的是流量模型——流式响应让长连接和上行小包暴增。
第一步：定位是带宽还是网络软件。新手常犯的错是直接升级带宽。我们先用iftop和ss -ti观察，发现物理带宽峰值仅用到62%，但TCP retransmit和send-q在部分网卡队列堆积。结论：不是总带宽不够，是网络软件层的中断亲和性与队列调度没跟上。
第二步：调整网卡多队列与中断亲和。将词元服务器网卡RSS队列从8个调到16个，并用irqbalance配合手动绑核，避免所有中断集中到CPU0。这一项就让P99首词元延迟下降约35%。避坑提示：不要盲目绑到同一NUMA节点，否则内存访问跨节点反而更慢。
第三步：优化TCP与流式响应参数。针对词元流式输出的小包特性，开启TCP_NODELAY，适当调大tcp_wmem和tcp_rmem，并启用SO_REUSEPORT让多个推理进程分担连接。同时把net.core.somaxconn从128提到1024，避免accept队列溢出。避坑：不要直接照搬“高并发参数模板”，必须结合IDC实际RTT和交换机缓冲。
第四步：网络软件与IDC边界协同。与IDC运营商确认上行Policing策略，本周案例中运营商侧对突发小包做了200Mbps限速，导致重传。调整QoS标记后，词元服务器带宽利用率稳定在78%，延迟回到210ms以内。
新手避坑总结：1）不要先加带宽，先看重传和队列；2）不要忽视流式AI流量的长连接与小包特征；3）不要只调服务器，IDC网络软件策略同样关键。高并发优化是端到端的，词元服务器、带宽、网络软件和IDC边界必须一起看。
0 留言