1. 先查你的流量画像里“词元包”占比是否超过15%。本周多家云厂商内部数据显示，AI推理请求的token化数据包已占IDC东西向流量的12%-18%。如果你的监控面板还只看传统bps峰值，建议今天就在sFlow或NetFlow采集器里增加一条过滤规则：匹配HTTP/2流中content-type为application/x-ndjson或含“stream=true”的会话。若占比超过15%，说明你的带宽模型需要重算。
2. 给GPU推理节点做一次TCP_NODELAY强制开启。词元逐块返回时，Nagle算法会累积小包再发，导致首词延迟增加20-40ms。本周可执行动作：在Kubernetes的Pod模板中增加sysctl配置net.ipv4.tcp_low_latency=1，或在Nginx/Envoy侧对SSE接口单独设置TCP_NODELAY。改完用curl -N观察chunk间隔，通常能压缩到5ms以内。
3. 把RDMA网卡的中断亲和性从“全核”改为“绑核到NUMA本地”。AI词元服务器的特点是短连接、高并发小包。本周正好有运维团队反馈，将Mellanox ConnectX-6的中断从默认的irqbalance全核分发改为绑定到GPU所在NUMA节点的物理核后，P99词元间延迟从8.3ms降到3.1ms。操作命令：for i in $(ls /sys/class/net/eth0/device/msi_irqs/); do echo
4. 检查你的网络软件是否支持“词元感知”的拥塞控制。传统CUBIC在丢包时降窗过猛，对词元流不友好。本周可以试点的方案：在推理服务端和负载均衡之间启用BBRv2，并设置初始窗口为20个MSS。多数Linux 6.x内核已内置，只需sysctl -w net.ipv4.tcp_congestion_control=bbr2。注意：先在一组灰度节点上跑，观察重传率是否低于0.1%。
5. 做一次“带宽-词元吞吐”的基准曲线。不要只看带宽峰值。本周可执行：用wrk或k6脚本模拟持续生成128个并发token流，逐步增加带宽限制（tc qdisc），记录每Gbps带宽能支撑的token/s。多数IDC在10Gbps以内呈线性，超过后因PCIe或内存带宽出现拐点。把拐点值写进容量规划文档，下周采购就有据可依。
6. 把网络软件日志的采样率从1:1000调到1:100（仅限词元路径）。词元请求的错误模式与传统HTTP不同——常表现为“流中途截断”或“首包后超时”。本周可操作：在Envoy的access log中增加%RESPONSE_FLAGS%和%BYTES_RECEIVED%，并针对/stream路径单独设置采样率1:100。周五前就能抓到过去一周被忽略的UPSTREAM_RESET或STREAM_IDLE_TIMEOUT。
7. 为下一批AI词元服务器预留“带外管理带宽”的独立通道。本周有IDC报告指出，当推理节点满载时，IPMI/BMC的共享网口会因业务流量挤占导致带外失联。可执行建议：采购时要求服务器至少提供1个独立的1GbE RJ45专用于BMC，或在现有节点上把BMC VLAN从业务上行链路中剥离。这是防止“节点假死却无法远程重启”的最低成本改造。
0 留言