北京
在上一篇文章里，我们设计了一个双 Roaring Bitmap 库存引擎，把 GPU 机架的运行时可用状态映射成一个极小的数据载荷。我们搭好了 Server-Sent Events（SSE），在 localhost 上测试，看着延迟掉到亚毫秒级，感觉自己打败了系统。
然后我们把它发布到了生产环境。到周二下午，带宽账单开始飙升。我们那套优雅的位图架构，一头撞上了网络规模的真实墙。这就是我们的网络层如何崩掉、以及我们如何重新设计订阅路由来扛住负载的故事。
广播风暴
最初的方案很简单：只要某个 GPU 机架上的运行时可用状态发生变化，就把这个机架的双位图序列化，通过 SSE 推送给连接到该集群区域的所有活跃调度代理。
规模一上来，数学就开始收账了。如果一个集群区域有 10000 个活跃调度代理或边缘节点，某个像 Llama-3-70b 这样的运行时没有空闲槽位了，我们就把一个 100 字节的载荷发给这 10000 个代理。也就是 1MB，听起来不算什么。
但如果我们有 500 个机架，在调度器峰值负载下每秒有 10 个运行时发生状态变化，我们推送的量就是：
10 次更新/秒 × 10000 个代理 × 100 字节 × 500 个机架 ≈ 5 GB/s
这些代理里绝大多数跑的是静态流水线，根本用不到 Llama-3 这个运行时。我们在白白消耗 CPU 和带宽，推送着没人关心的更新。
修复方案：内存内的 Watchlist 路由
我们意识到，调度代理只关心它们正在调度或监控的那些运行时的状态变化。与其广播整张位图，我们在编排网关节点上做了一个 Watchlist Router。
当边缘代理打开一条 SSE 连接时，它注册一个动态订阅，声明自己当前正在使用或准备使用哪些运行时 ID。
边缘代理 ---> 订阅（运行时：10821，44012）---> SSE 连接节点
在连接节点上……
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
