问：为什么AI词元服务器特别容易把IDC带宽打满？
答：与普通Web服务器不同，词元服务器在推理阶段呈现“微突发+长连接”特征。单次请求的输入可能很短，但模型逐词元返回时，网络包小而密。近期我们监控到某集群在QPS仅上升15%时，出口带宽瞬时冲高至92%，原因是多个大模型同时触发流式响应，而IDC默认的带宽整形策略仍按传统HTTP短连接设计，缓冲队列迅速溢出。复盘结论：带宽规划要从“平均吞吐”转向“P99突发容忍”。
问：网络软件层面，最容易忽视的配置是什么？
答：三个点。第一，TCP_NODELAY未开启，导致小包被Nagle算法合并，词元延迟抖动从8ms跳到40ms以上。第二，网卡多队列与CPU亲和性错位，软中断集中在单个核，收包丢包率在高峰时达0.7%。第三，服务网格sidecar未对词元流做独立限流，健康检查流量与推理流量混跑。本周一次事故中，正是sidecar的mTLS握手风暴占用了12%带宽，导致真实词元响应超时。
问：事故复盘后，你们优先调整了哪三件事？
答：第一，在IDC交换机侧为词元服务器单独划分QoS队列，保证突发时至少40%带宽预留。第二，将网络软件栈的 ring buffer 从1024提升到4096，并开启GRO/GSO，降低CPU收包压力。第三，对词元流实施基于“首包时间+持续时长”的动态限流，而非单纯QPS。调整后，同一压测场景下，带宽峰值下降28%，P99词元间隔从210ms回落到95ms。
问：近期AI词元服务器还有哪些新坑？
答：多模型混合部署带来的“带宽竞争”最典型。不同模型的词元输出速率差异大，若共享同一物理网卡，慢模型的长尾流会阻塞快模型的微突发。我们正在试验基于eBPF的流级优先级标记，让关键推理流的包优先出队。另外，IDC侧建议关注液冷机柜的网线走线，高温下光模块误码率上升也会伪装成带宽丢包。SRE的边界，正在从软件延伸到物理层。
0 留言