第一步：先算清“词元/秒”对应的真实带宽
别被“AI服务器”三个字吓住。本周多个社交平台技术群在传一张测算表：一个70B参数模型，在FP8精度下，每次推理输出一个词元约产生2~4KB网络回传（含中间激活值传输）。如果业务侧要求每秒并发处理2000个词元，单向带宽就是4~8MB/s，双向则翻倍。可执行建议：立刻向客户索要“峰值词元吞吐量”而非“多少张卡”。拿这个数除以0.6的安全系数，才是你IDC侧要预留的带宽下限。
第二步：识别四种“隐形带宽杀手”网络软件
本周热点里有人吐槽“上了AI推理集群后，监控软件比模型还吃流量”。重点排查：分布式追踪代理（如Jaeger）、服务网格sidecar（如Envoy）、GPU直连存储（如NFS over RDMA）、以及多租户下的VXLAN封装。建议做法：在测试环境关闭上述软件后对比带宽曲线，通常能回收20%~40%的无效占用。对于必须保留的sidecar，改为eBPF旁路模式。
第三步：按“词元优先级”做带宽QoS分级
IDC出口不要一刀切。把流量分成三级：实时推理回传（最高，延迟<5ms）、模型分片同步（中，可容忍50ms）、日志与埋点（最低，可丢弃）。用交换机或DPU上的DSCP标记即可实现。本周已有运营商IDC开始提供“AI词元保障带宽”增值包，价格比普通带宽高30%，但能避免因日志突发把推理链路打爆。
第四步：软件栈必须支持动态词元批处理
如果你的网络软件还是固定批次转发，AI场景下会浪费大量带宽。推荐检查：是否支持连续批处理（continuous batching）的gRPC流式接口？是否允许按词元而非按请求做ACK？一个小技巧：把TCP_NODELAY打开，同时将最大分段大小从1460降到1200，能降低小词元包的头部开销约8%。
第五步：建立“词元-带宽”实时看板，每周复盘
最后一条最容易被忽略。用Prometheus抓取推理服务的词元生成计数，再与交换机端口字节数做关联。当“字节/词元”比值突然上升15%以上，大概率是网络软件版本回退或某台服务器网卡降速。建议每周五下午花15分钟对照本文清单过一遍，比事后救火省下至少4小时。
本周热点终会过去，但IDC里那些AI词元服务器不会消失。把上面五步做成检查表，下次客户再问“你们带宽扛不扛得住”，你直接翻到第三行给他看。
0 留言