问：为什么最近很多AI客服项目在IDC侧“降速”了？
本周某华东IDC运营商透露，一个中型电商客户部署了基于大模型的智能客服后，单次会话平均产生1200-1800个词元的交互。当并发坐席从50路扩到300路时，出口带宽峰值直接打满1Gbps。问题不在GPU算力，而在词元流出的网络管道——AI客服的响应是“流式”的，每个词元都要经过服务器网卡、交换机、防火墙、负载均衡，最终到达用户端。任何一跳的网络软件（如DPDK转发效率、TLS卸载策略）都会成为隐形瓶颈。
问：那是不是堆带宽就能解决？
不完全是。我们观察到一个反直觉现象：某客户将带宽从1G升到10G后，首词元延迟仅下降18%。原因是其IDC内部网络软件仍采用传统内核协议栈，每个词元包都要经历完整的中断和拷贝。近期有厂商开始推荐“词元感知”的智能网卡——把流式响应的分片重组、优先级标记下沉到硬件，配合服务器侧的CPU亲和性调优，实测吞吐可提升2.3倍。但代价是IDC需要支持SR-IOV或RDMA，目前只有约三成机房具备条件。
问：上周DeepSeek-V3降价后，对IDC落地有什么新影响？
降价刺激了更多企业把AI客服从“试点”转为“全量”。但我们也看到，部分IDC的词元计费模型还没跟上——过去按带宽峰值计费，现在客户希望按“百万词元吞吐量”结算。这倒逼IDC升级流量采集软件，能区分文本词元、语音词元和图片描述词元。某华南IDC本周刚上线基于eBPF的细粒度统计，可以按坐席、按模型版本输出词元消耗报表。
问：对于想本周就优化AI客服延迟的团队，最务实的动作是什么？
三个优先级：第一，检查服务器网卡是否开启了多队列和RSS，把词元流分散到不同CPU核；第二，在网络软件层启用HTTP/2或gRPC的头部压缩，减少每个词元的协议开销；第三，与IDC协商将AI客服节点部署在离出口路由器更近的机柜，避免经过多层VXLAN隧道。根据本周实测，仅前两项就能把P99首词元延迟从850ms降到420ms左右。
AI客服的竞争正在从“模型参数”转向“词元物流”。IDC、服务器、带宽、网络软件，这四个词必须放在同一张架构图里看，否则再聪明的模型也会卡在网线上。
0 留言