2026-10-01
亚马逊公开Bedrock的WLM:每分钟百万级请求、30余个区域,把prompt缓存稳定当成一等路由约束,用有界不一致换掉全局同步。
基础模型推理平台手里的加速器是稀缺资源,而且各地区到货量不均匀。请求消耗的 token 数量差几个数量级,生成过程中还会边跑边暴露;同一池子还要同时伺候低延迟对话和高吞吐批处理,目标和 SLA 互相打架。
这篇是 Amazon Bedrock 的工业界系统论文,讲线上已经在跑的 Workload Management System(WLM)。摘要给出的规模是:每分钟百万级推理请求,覆盖 30 多个区域。ACM Digital Library 被 Cloudflare 拦截,这篇 2026-09-28 刚见刊,未检索到预印本或作者主页 PDF,下面只依据 Crossref / OpenAlex 重建出的摘要,实验数字不编。
架构按两条原则搭。
第一,把请求入口和真正执行拆开,在允许的地理范围和模型放置范围内组成逻辑执行池,并且把 prompt 缓存是否稳定当成一等路由约束。KV / prompt cache 命中依赖「同类前缀尽量打到同一批机器」;如果路由只看剩余算力,缓存会被打散,首 token 延迟和加速器利用率一起掉。把缓存稳定写进路由,等于承认生成式负载的局部性比传统无状态 API 强得多。
第二,接受有界不一致,用纵深防御代替全局同步。跨 30 多个区域做同步准入,请求路径会被最慢的那次协调拖住。WLM 的做法是:准入和路由用本地或缓存状态当场拍板;配额消耗事后在区域之间定期对账;路由权重不走请求路径,而由各区域的容量和健康信号在后台刷新。
五个子系统按摘要列出的名字分工:准入控制、流量分类、跨区域路由、请求调度、编排。流量分类大概用来切开不同延迟/吞吐目标,再交给后面的路由和调度;编排负责把逻辑池和真实加速器对上。摘要没有展开每个子系统的算法、队列结构和失败切换细节。
评估用了三类证据:生产观测、基准测试、以及「有界陈旧 vs 同步准入」的受控压测。观察面包括加速器利用率、缓存稳定性、请求延迟、优先级行为、吞吐、请求路径开销、配额执行精度,以及若干故障下的表现。
摘要没有给出任何具体数字。没有利用率百分比,没有延迟分位数,没有和同步准入相比吞吐差多少,也没有故障注入的恢复时间。论文正文有 52–64 页共 13 页,这些数字应当在结果节里,但本轮取不到全文,不能填。
能确定的只有实验设计本身:他们把「有界不一致」当成可测量的选择,专门拿同步准入做对照。这说明作者认为全局一致的配额和路由在这个规模上是错的,并且愿意用生产流量来辩护。
公开的 LLM serving 论文大多停在单集群调度、PD 分离、前缀感知路由。Bedrock 要同时满足多模型、多区域、多 SLA,还要让 prompt cache 在路由层不被打散,问题集合比 vLLM 类系统大一截。百万请求/分钟、30 余区域这个量级,本身就是少见的生产披露。
对做推理平台的人,可带走的设计选择有两条。入口和执行解耦,才能在合规地理围栏里把加速器当成一个池。配额和路由权重不走请求热路径,用定期对账换尾延迟,这和数据库里「读自己写」的取舍同类,只是对象换成了 GPU 配额。prompt cache 稳定性被写成一等约束,说明在这个服务里,缓存命中已经贵到必须影响跨区域路由,而不是事后优化。
最大的局限是本轮没有全文。摘要点名了五个子系统和八类指标,但没有基线名字、没有消融、没有故障集合。WLM 是否只服务 Bedrock 无服务器路径、如何处理预留吞吐、如何与模型提供商的容量合同衔接,摘要都没说。
「有界不一致」在配额上意味着什么,也只能停在字面:短窗口内某个区域可能超卖或拒之过严,事后对账再纠。纵深防御的具体层数未知。流量分类如果只是优先级标签,和业界常见的 prefill/decode 分池是不是一回事,无法判断。论文许可是 CC BY-NC-ND,按理可公开下载,卡在 ACM 站点的反爬,不代表付费墙。