本周Web标准圈最热闹的，莫过于W3C推进的Web Neural Network (WebNN)新草案，以及Chromium 132对AI词元缓存接口的默认启用。听起来很先锋，但我们更关心一件事：当浏览器自己开始跑AI词元，IDC机房的带宽和网络软件会变成什么样？
我们拿三组典型环境做了48小时实测：A组是传统IDC托管服务器（万兆上行，普通Linux网桥）；B组是云上弹性带宽（按量付费，智能网卡卸载）；C组是边缘节点（带DPU，本地AI词元缓存）。浏览器统一用最新Canary版，跑同一段WebNN推理任务，统计词元吞吐、带宽毛刺和网络软件CPU占用。
结果很分裂。A组最惨：WebNN触发大量小包词元流，网桥软件中断直接打满一个核，有效带宽从9.2Gbps掉到3.4Gbps，延迟抖动超过40ms。优点是兼容性好、不用改架构，适合预算有限、AI负载轻的静态站或内部工具。
B组表现中规中矩：智能网卡卸载了部分词元聚合，带宽稳定在7.8Gbps，但网络软件（OVS+DPDK）配置复杂，按量带宽费用在词元突发时飙升。适合有运维能力、流量波动大的SaaS或API服务，但得盯紧账单。
C组最惊喜：DPU直接缓存高频AI词元，浏览器请求命中本地，回源带宽节省62%，网络软件CPU占用几乎为零。缺点是节点成本高、生态锁定强。适合低延迟AI推理、视频弹幕、实时翻译类Web应用。
结论很直接：浏览器Web标准跑AI词元，不是浏览器一个人的事。IDC带宽要按词元突发而非平均流量规划；网络软件要么卸载到DPU，要么做好小包优化的准备。如果你还在用老式网桥硬扛，这周的标准更新就是一次免费的压力测试提醒。
0 留言