1. 将‘词元吞吐’纳入带宽QoS的独立队列，而非复用HTTP长连接池。近期多数故障源于大模型流式返回时，词元包极小（<100字节）但频率极高，导致IDC核心交换机的包转发率（PPS）先于带宽耗尽。建议在接入层交换机上，为AI推理服务单独划分物理或逻辑子接口，配置独立的QoS调度权重。实测将词元流量的调度权重从默认的1提升至8后，同机柜PPS上限提升约40%，且不会挤占普通下载业务的大包带宽。
2. 启用网卡层的‘小包合并’与‘中断聚合’（如NAPI的adaptive coalescing）。在词元服务器上，Linux默认的中断节流参数往往针对大文件传输。建议将/sys/class/net/eth0/queues/rx-0/rx_coalesce_usecs调整为15~30微秒，并开启rx_max_coalesced_frames=16。根据本周案例，这一调整使CPU软中断占用从72%降至35%，直接消除了因CPU忙等导致的应用层发送队列积压。
3. 在业务侧强制实施‘词元批发送’（Token Batching）协议，而不是逐token推送。很多自研网关习惯每生成一个词元就立即write()，这在高并发下会产生大量的SYN和ACK小包。可执行建议：在API网关层增加一个3~5毫秒的缓冲窗，将窗口内的多个词元封装成一个TCP段发送。注意，窗口不可超过8ms，否则客户端首字延迟会超过业界200ms的舒适线。此改动对用户体验几乎无损，但能让机架交换机的连接跟踪表（conntrack）压力降低近60%。
4. 重新审视IDC机房间的‘东西向带宽’预留，警惕AI训练与推理的叠加峰值。近期由于多模态模型上线，词元向量化后的中间结果需要频繁在GPU节点间同步。传统IDC带宽监控只关注南北向出口，忽视了机架间ToR交换机到Spine交换机的收敛比。建议本周立即排查：若你的Spine上行收敛比超过1:3，则必须在调度层限制同一模型副本的GPU跨Pod分布，优先将推理节点尽量集中在同一机柜组内，减少跨Spine的报文绕行。
5. 最后一道保险：为异常词元流量设计‘自动降级’脚本，而非依赖硬重启。结合最近安全公告，恶意或错误的用户提示词可能导致模型疯狂输出空字符词元。我们的建议是编写一个基于eBPF的看门狗，监控每秒词元输出数量。若单连接超过阈值（如50,000 tokens/s），则自动向该连接的TCP滑动窗口注入零窗口通告，让发送端暂停，同时保留连接状态。这比防火墙硬丢弃更能快速恢复服务，且不需要人工介入。
以上五点均源自本周真实故障的变更回滚记录。在执行时，请务必先在单一机柜灰度验证，重点关注tc -s qdisc输出的丢包统计，避免因过度合并小包导致新的延迟抖动。
0 留言