最近AI推理服务在IDC里越来越常见，尤其是“词元服务器”这种按token吞吐计费的场景。本周我所在的团队想验证一个简单假设：把服务器带宽从1Gbps升级到2.5Gbps，同时调整网络软件参数，是否能让词元生成的首包延迟明显下降。因为预算有限，我们决定用A/B测试平台先跑一周小流量实验。
第一步：明确唯一变量，别贪多
新手最容易犯的错，是同时改带宽、改拥塞控制算法、改网卡队列。我们第一版实验就因此失败——A组和B组差异混在一起，根本分不清是谁的功劳。后来只保留一个变量：带宽上限。A组保持1Gbps，B组限速到2.5Gbps，网络软件统一使用默认的BBR。其他如词元服务器型号、模型版本、并发数全部对齐。
第二步：在A/B测试平台上正确切流
IDC环境不像公有云那样有现成的网关。我们用了平台自带的“按请求头哈希”分流：给每个推理请求打上X-Exp-Group标签，A组走旧带宽策略，B组走新策略。注意：不要按用户ID切流，因为词元服务器的调用方是内部服务，没有稳定用户ID。按请求哈希反而更均匀。
第三步：避坑——监控带宽之外的指标
我们第一周只盯着带宽利用率，结果B组虽然带宽更宽，但词元生成延迟反而抖动更大。排查发现是网络软件侧的TCP缓冲区没有同步调大，导致高带宽下出现微突发丢包。教训：带宽变了，网络软件参数必须联动检查，但别在实验中途改——应该作为下一轮实验的独立变量。
近期讯息带来的启发
就在本周，某头部IDC厂商发布了“AI词元服务器网络基线报告”，提到2.5Gbps正成为推理节点的新起点，但强调网卡RSS队列数要和vCPU数量匹配。我们据此在B组把RSS队列从4调到8，延迟P99下降了约12%。这个改动没有混入主实验，而是作为后续优化项单独记录。
给新手的三个避坑清单
- 别用生产全量跑：先拿1%的词元请求做实验，观察24小时再扩到5%。
- 记录网络软件版本：不同内核版本的BBR行为不同，实验前后必须锁定。
- 不要忽略冷启动：词元服务器首次加载模型会拉高延迟，A/B两组都要等模型常驻内存后再对比。
最终，我们用了5天完成一次干净的A/B测试，结论是：在AI词元服务器上，单纯升级带宽对首包延迟改善有限（约3%），但配合RSS队列调整后收益明显。下周准备把网络软件参数作为第二个变量正式开跑。如果你也是新手，建议从“只改一个变量、先小流量、监控要全面”这三条开始。
0 留言