本周信号：多家云厂商在近期财报与技术峰会上透露，AI推理请求的“词元吞吐量”已超越训练成为IDC内网流量的主要增长源。与此同时，800G端口出货加速，但真正拖慢响应时间的往往是网络软件栈。以下5条可立即对照执行。
1. 按“词元/秒/机架”重新核算带宽预算。别再只用GPU利用率做容量规划。本周多个案例显示，当单机架词元生成速率超过2万/秒时，南北向带宽比东西向先打满。建议：对推理集群单独设立带宽水位线，预留30%突发余量给KV Cache跨节点传输。
2. 给服务器带宽做“分级错峰”而非平均分配。近期某头部IDC的丢包数据显示，晚高峰推理请求中70%是小包词元流。可执行动作：在ToR交换机上为AI推理流量启用基于词元速率的动态限速，而非固定QoS。把大包训练流量压到低优先级队列，避免其阻塞词元响应。
3. 检查网络软件的“词元感知”能力。传统负载均衡器看不懂词元长度和生成进度。本周建议：升级或替换为支持gRPC流式感知的网关软件，能按“已生成词元数”做后端亲和调度。否则长序列请求会反复重连，白白吃掉服务器带宽。
4. 用DPU卸载词元路由表。本周多个技术社区讨论指出，纯CPU做词元级路由转发时，每万词元消耗约0.3核。建议至少将流表卸载到可编程网卡，把CPU还给推理框架。实测可降低端到端延迟12%～18%。
5. 本周立刻可做的压测：模拟“词元突发+带宽收缩”。不要只跑稳定吞吐。执行方案：用真实词元分布（含长尾）发起请求，同时将服务器带宽限速到峰值的60%。观察网络软件是否触发重传风暴。若重传率超过2%，优先调大TCP接收窗口或切换QUIC。
总结：本周互联网技术趋势的核心不是买更多带宽，而是让每一段服务器带宽都对应可计量的AI词元产出。从网络软件配置入手，比升级硬件更快见效。
0 留言