SLO 0.97：京东 Janus 怎么回放线上

SLO 0.97：京东 Janus 怎么回放线上

京东云开发者社区在 2026 年 8 月 19 日发了多大模型服务系统 Janus。页面作者是社区账号 fd****。工作由北京大学、京东零售 xLLM 团队、中国科学院大学、中国科学技术大学和上海交通大学一起做，论文是 SOSP 2026 的 Janus: Multi-LLM Serving at Production Scale。SOSP 2026 投稿 390 篇，录用 62 篇，录用率 15.9%。这个录用率不是线上 SLO。

生产集群要同时放很多模型。参数从 0.6B 到 671B，每个应用的请求速率、输入输出长度、TTFT 和 TPOT 的 SLO 都不一样。TTFT 是首 token 时延，TPOT 是后续每个 token 的时延。这篇把问题收成三件同时要做的事：突发流量下亚秒扩容，头部长尾分开管，按显存容量、计算和带宽做放置。

慢路径 30 秒，快路径 0.5 秒

设备分成两池。Steady Pool 给流量稳的长尾，慢路径做多维向量装箱，把资源互补的模型放在同一实例。Elastic Pool 给波动大的头部，一个实例主要服务一个模型，快路径按实时负载加减副本。慢路径每 30 秒重看一次放置，快路径每 0.5 秒看一次要不要扩缩。两条周期不混用。

Performance Oracle 给每个模型两个高斯过程。Capacity GP 把请求速率和输入输出长度映射成显存、计算、带宽三维向量，给慢路径用。Elasticity GP 按负载和实例数预测 SLO 达成率，给快路径用。新模型历史少，高斯过程还能给出不确定性。

请求分发叫 LST-IMH。它把单机 Moore–Hodgson 调度推广到多实例，按截止时间、预计执行时长和实例最早空闲时间挑请求。原文写对「最大化按时完成的请求数」有 2-近似，复杂度 O(mn log n)。轮询和最小负载只看当前队列，不看能不能在截止前做完。

引擎侧三块。xTensor 把显存做成连续虚拟地址，权重从低地址往上，KV Cache 和激活值从高地址往下，不预先钉死两区比例。模型生命周期跟实例拆开，分成 Active、Warm、Cold：Active 能立刻接请求，Warm 留着可恢复状态但放掉一部分设备资源，Cold 要重新加载或复制权重。扩容优先走同一高速互联域里的 D2D Fork，从活跃副本直接拷权重；常规恢复才走主机到设备的 H2D Wakeup。

生产轨迹里的三个观察，是后面实验的前提，不是实验结果：少数应用几秒内请求涨 5–10 倍；前 12% 的应用贡献 80% 的请求，前 30% 的应用贡献 80% 的 Token；只算 H2D 加载，大模型也要 0.4–2.7 秒。

60.3 万次回放，不是全天 4560 万

集群有 768 个加速设备，62 个应用，每天约 4560 万次请求。实验从其中一天抽 60.3 万次，开放环回放，保留原来的到达时间和突发。对照是 Prism、BlitzScale 和静态 ServerlessLLM。各应用的 TTFT、TPOT 阈值写在图里，正文没有逐应用列出。

完整轨迹上，Janus 的 SLO 达成率保持在 0.97–1.0。原文写最强基线是 0.80–0.92，没有点名是三家里的哪一个。Janus 每天 13,440 device-hours，比静态 ServerlessLLM 少 27%。Goodput 的逐系统数字在图里，正文没写成表。

把请求速率再抬高，在同样 90% SLO 达成率下，Janus 能扛 BlitzScale 的 1.3–1.5 倍请求速率，并且是 Prism 和 ServerlessLLM 的 3 倍以上。把时延目标收紧时，Janus 能接受的目标比 BlitzScale 严 5 倍。90% 这一档和 0.97–1.0 那一档不是同一次对比。

120 秒、里面既有稳定应用也有突发应用：双池整体 SLO 达成率 97.8%，突发开始后 9 秒内恢复。只做 Elastic 是 59.0%，只做 Steady 是 37.1%。五个代表性应用上，双池把各应用的 TTFT 和 TPOT SLO 都维持在 96% 以上。五个应用的名字和各自的分数没有展开。

D2D Fork 在 Qwen3-8B、Qwen3-32B 和 DeepSeek-V3 671B 上，副本激活落在 388–783 毫秒。671B 这一档写明是 0.74 秒，H2D Wakeup 是 2.71 秒，大约快 3.7 倍。8B 和 32B 的单独秒数没有从区间里拆开。671B 突发里，D2D Fork 把 SLO 维持在约 98%，只走 H2D 掉到约 90%。复制时源实例的 P99 TPOT 最多升 5.7%，传完就回到原水平。

12 个服务、3 个基础模型的驻留实验：共享 xTensor 用 1 个设备，静态分区和每进程独立 xTensor 都要 3 个设备。四个 1.7B 模型挤在一个设备上，关掉 xTensor 后平均 SLO 达成率掉到 81%，P99 TTFT 升到数秒；打开动态重分配后 SLO 达成率 100%，P99 TTFT 是几十毫秒。10 秒、30 秒、60 秒的分配压力下，碎片率都低于 0.3%。「数秒」和「几十毫秒」没有更细的数。

请求速率到 2 倍时，LST-IMH 的 TTFT SLO 达成率是 91.2%–92.4%，Round-Robin 64.8%，Least-Load 70.2%。区间对应的两档负载，正文没有分开写。24 小时轨迹上，在线增量装箱有 99.99% 的时间与 OR-Tools 的最优设备数一致，从不多用超过一个设备，决策快 4.3 倍。

这几组不能加总。0.97–1.0 是 60.3 万次开放环回放。97.8% 是 120 秒双池实验。98% 和 90% 是 671B 突发。100% 和 81% 是四个 1.7B 共置。91.2%–92.4% 是请求调度。27% 是相对静态 ServerlessLLM 的 device-hours，不是相对另外两个基线。

能直接拿去用的是评测切法：从一天的线上请求里抽开放环回放，保留到达时间；SLO 分成 TTFT 和 TPOT，再报整体达成率；速率加压和阈值收紧分开做；双池、拷权重路径、显存分配、请求调度各自消融，不合成一个总分。

京东云开发者社区，fd****，SOSP 2026｜京东首篇！Janus：面向生产级多大模型服务的双时间尺度调度系统，2026-08-19，https://developer.jdcloud.com/article/4555