本文导读

面向生产环境的大模型服务，系统需要在同一集群中同时承载大量参数规模、流量特征和时延目标各不相同的模型。突发流量要求系统快速扩容，长尾应用需要高密度共享资源，不同模型在显存容量、计算单元和显存带宽上的差异又带来了新的调度空间。现有方案通常只解决其中一部分问题，难以同时兼顾服务质量、资源效率与弹性。

Janus 是一套面向生产级多大模型服务的 Service–Engine 协同系统。系统以双时间尺度调度为核心：慢路径通过多维向量装箱提升长尾模型的资源利用率，快路径通过亚秒级弹性扩缩容应对头部应用的突发流量；在执行引擎中，Janus 进一步引入 xTensor 虚拟显存、三状态模型生命周期和设备间 D2D Fork，为多模型共置与快速副本启动提供运行时支持。

本工作由北京大学、京东零售xLLM团队、中国科学院大学、中国科学技术大学和上海交通大学的研究团队共同完成，论文已被第 32 届ACM Symposium on Operating Systems Principles（SOSP 2026）接收，也是京东首篇被 SOSP 接收的论文。SOSP 2026 共收到 390 篇投稿，最终录用 62 篇，录用率为 15.9%。

·       论文：Janus: Multi-LLM Serving at Production Scale

·       链接：https://zirui.cool/assets/pdf/Janus_SOSP26.pdf

·       会议录用率：62/390 = 15.9%

01 摘要

生产级大模型服务平台通常需要在共享集群中承载数百个异构模型，由此面临三个彼此关联的挑战：不可预测的突发流量、呈幂律分布的应用热度，以及异构但具有互补性的资源需求。已有系统很难同时解决这三个问题。

为此，本文提出 Janus，一套围绕双时间尺度调度构建的多模型服务系统。Janus 采用中心化 Service 层与分布式 Engine 层协同设计。在 Service 层，Performance Oracle 为 Model Scheduler 提供性能预测：慢路径每 30 秒执行一次多维向量装箱，用于稳定流量下的模型共置；快路径每 0.5 秒进行一次弹性决策，用于响应突发流量。Request Scheduler 则采用新的 LST-IMH 算法，在多实例之间调度请求，并为最大化按时完成请求数提供 2-近似保证。

在 Engine 层，xTensor 将显存抽象为统一的虚拟地址空间，三状态模型生命周期与 D2D Fork 则支持弹性共置和亚秒级扩容。Janus 已部署在一个包含 768 个加速设备的生产集群中，该集群承载 62 个应用和每日 4560 万次请求。基于其中60.3 万次请求的开放环回放实验显示，Janus 的 SLO 达成率保持在 0.97–1.0，最强基线为 0.80–0.92；同时，Janus 每日使用 13,440 device-hours，相比静态 ServerlessLLM 减少 27%。

02 动机

从单模型优化走向多模型集群调度

早期大模型推理系统主要关注单个模型的吞吐与时延，例如如何提高连续批处理效率、降低 KV Cache 碎片或优化单实例内核。然而，生产级 Model-as-a-Service 平台面对的是另一类问题：同一集群需要同时服务大量模型与应用，模型参数量可以从 0.6B 跨越到 671B，每个应用又具有不同的请求速率、输入输出长度和 TTFT/TPOT SLO。

因此，系统的核心问题不再只是“如何让一个模型运行得更快”，而是“如何将大量异构模型高效地放置、扩缩容并调度到共享集群上”。对生产轨迹的分析进一步揭示了三个关键现象。

24 小时 Token 速率显示，不同应用存在明显的秒级突发流量。

应用热度呈幂律分布，排名前 12% 的应用贡献 80% 的请求。

不同模型在 HBM 容量、计算和带宽上的需求异构且具有互补性。

观察一：流量突发且难以预测

多数应用的流量相对稳定，但少数应用会在数秒内出现 5–10 倍的请求增长。这类突发可能来自促销活动或上游业务触发，对推理平台本身不可见，因此很难依靠长期预测提前扩容。

传统扩容通常需要完成进程或容器启动、显存分配、模型权重加载以及通信组初始化，耗时可达数十秒甚至数分钟。即使只考虑 H2D 权重加载，大模型也可能需要 0.4–2.7 秒。要在突发期间维持 SLO，系统必须显著缩短模型副本的激活路径。

观察二：应用热度呈明显的幂律分布

生产轨迹中，排名前 12% 的应用贡献了 80% 的请求，前 30% 的应用贡献了 80% 的 Token。头部应用吞吐高、波动大，需要预留足够的 KV Cache 空间并快速扩容；长尾应用单体流量很低，但模型种类多，若为每个模型独占设备，会造成大量资源浪费。

这意味着头部与长尾应用不适合使用同一种管理策略：头部应用更需要弹性和隔离，长尾应用则更需要紧凑共置。

观察三：不同模型的资源需求具有互补性

不同应用对 HBM 容量、计算单元和 HBM 带宽的压力并不相同。大参数模型通常受显存容量约束，小模型的高吞吐场景可能更依赖计算资源，而 Decode 密集型工作负载则容易受显存带宽限制。

这些差异同时带来了共置机会。例如，显存容量占用高但计算利用率低的模型，可以与计算密集型模型共享设备。若调度器只把设备数量视为单一标量，就无法利用这种多维资源互补性。

现有方法的局限

已有系统通常分别优化多模型共置、模型冷启动或单应用弹性扩容，但很少同时处理突发流量、幂律热度和多维资源异构性。静态共置难以及时吸收突发流量，按应用独立扩缩容又缺少跨应用的全局协调；周期性全局重排虽然能够改善资源利用率，但可能在重配置期间暂停请求。

基于这些观察，Janus 的目标是同时实现三项能力：

·       面向突发流量的亚秒级弹性扩容；

·       面向头部与长尾应用的差异化资源管理；

·       面向 HBM 容量、计算和带宽的多维感知放置。

03 方法

Janus 由中心化 Service 层和分布式 Engine 层组成。Service 层负责全局性能建模、模型放置、扩缩容和请求分发，Engine 层负责每个实例上的显存、计算资源与模型生命周期管理。两层通过运行时遥测形成闭环：Engine 持续上报负载和性能数据，Service 根据最新状态在对应时间尺度上调整决策。

Janus 系统架构：Service 层负责全局决策，Engine 层负责弹性资源与模型生命周期管理。

双资源池与双时间尺度调度

Janus 将设备划分为 Steady Pool 和 Elastic Pool。

Steady Pool 面向流量稳定的长尾应用。系统在慢路径上执行多维向量装箱，将资源需求互补的模型放置到同一实例，通过模型共置降低设备占用。

Elastic Pool 面向高流量、强波动的头部应用。每个实例主要服务一个模型，系统在快路径上根据实时负载快速调整副本数，并利用 D2D Fork 缩短新副本的激活时间。

慢路径每 30 秒重新评估模型放置，快路径每 0.5 秒检查弹性需求。两条路径分别处理长期资源效率和短期流量变化，避免用同一种调度周期同时承担两个目标。

Performance Oracle：为调度器提供可学习的性能模型

Performance Oracle 为每个模型维护两类高斯过程模型。

·       Capacity GP 将请求速率、输入输出长度等工作负载特征映射为 HBM 容量、计算与带宽组成的三维资源向量，为慢路径的模型放置提供依据。

·       Elasticity GP 根据工作负载特征和实例数量预测 SLO 达成率，为快路径判断扩容或缩容提供依据。

两类模型使用相似的输入特征，但预测目标不同。高斯过程在样本稀疏时仍具有较好的数据效率，并能输出预测不确定性，因此适合刚接入、历史观测较少的新模型。

Model Scheduler：慢路径装箱与快路径扩缩容

慢路径将模型放置建模为多维向量装箱问题。每个模型的资源需求由 Capacity GP 给出，系统将 HBM、计算和带宽约束共同纳入放置决策，并采用增量算法减少频繁全局求解带来的开销。

快路径由 Elasticity GP 预测不同副本数下的 SLO 表现。当当前容量不足以应对负载变化时，调度器在 Elastic Pool 中启动更多副本；负载下降后，再逐步回收冗余实例。

Request Scheduler：面向 SLO 的 LST-IMH 调度

副本数量确定后，请求仍需要被分配到具体实例。简单的轮询或最小负载策略只关注当前队列，难以判断请求能否在截止时间前完成。

Janus 将请求分发形式化为并行机截止时间调度问题，并提出 LST-IMH 算法。算法综合请求截止时间、预计执行时长以及不同实例的最早可用时间，优先保留能够按时完成的请求。LST-IMH 将经典的单机 Moore–Hodgson 调度推广到多实例场景，对最大化按时完成请求数提供 2-近似保证，时间复杂度为 O(mn log n)。

xTensor：统一管理权重、KV Cache 与激活值

传统推理引擎通常为不同模型或不同类型的张量静态划分显存，模型间难以动态借用空闲空间。xTensor 将 HBM 暴露为连续的虚拟地址空间，并将所有物理页组织为统一页池。

在同一 xTensor 中，模型权重从低地址向上增长，KV Cache 与激活值从高地址向下增长。双向分配避免了预先固定权重区与 KV 区的比例，也使共置模型能够按实时需求动态重新分配显存。预注册的全局地址区域还可以直接作为 D2D Fork 的接收缓冲区，减少启动新副本时的内存准备开销。

三状态模型生命周期与 D2D Fork

Janus 将模型生命周期与推理实例生命周期解耦，将模型划分为 Active、Warm 和 Cold 三种状态。

·       Active：模型权重与运行资源均已就绪，可以立即处理请求。

·       Warm：保留可快速恢复所需的运行时状态，但释放部分设备资源。

·       Cold：设备侧资源已释放，需要重新加载或复制权重。

系统提供两种恢复路径。常规恢复可以从主机侧执行 H2D Wakeup；突发扩容则优先从同一高速互连域内的活跃副本直接复制权重，即 D2D Fork。后者绕过较慢的主机到设备路径，使大模型副本也能够在亚秒级完成激活。

04 实验结果

生产级实验环境

Janus 部署在一个由 768 个加速设备组成的生产集群中，服务 62 个应用，覆盖从 0.6B 到 671B 参数规模的模型。生产系统每日处理约 4560 万次请求。论文从其中一天采样 60.3 万次请求，通过开放环方式回放，以保留原始到达时间和流量突发特征，并与 Prism、BlitzScale 和 ServerlessLLM 等系统进行比较。

端到端性能

62 个应用生产轨迹回放下的 Goodput、设备用量以及 TTFT/TPOT/整体 SLO 达成率。

在完整生产轨迹回放中，Janus 的 SLO 达成率保持在 0.97–1.0，最强基线为 0.80–0.92。与此同时，Janus 每日使用13,440 device-hours，相比静态 ServerlessLLM 降低 27%。

进一步提高请求速率时，在相同的 90% SLO 达成率目标下，Janus 可承载 BlitzScale 的 1.3–1.5 倍请求速率，并达到Prism 和 ServerlessLLM 的 3 倍以上。不断收紧 SLO 阈值时，Janus 可承受的时延目标比 BlitzScale 严格 5 倍，说明其优势并不依赖宽松的 SLO 设置。

小结： Janus 的收益来自跨应用的全局协调。慢路径提高长尾模型的共置密度，快路径快速复制头部模型，两者共同降低设备用量并维持突发期间的服务质量。

双资源池消融

双资源池与 Elastic-only、Steady-only 两种单池设计的 SLO 对比。

论文将双资源池方案与 Elastic-only 和 Steady-only 两种单池变体进行对比。在包含稳定应用和突发应用的 120 秒实验中，双资源池达到 97.8% 的整体 SLO 达成率，并在突发开始后 9 秒内恢复。

相比之下，Elastic-only 和 Steady-only 分别只有 59.0% 和 37.1%。前者无法通过紧凑共置保护稳定流量，后者又无法及时吸收突发流量。五个代表性应用的结果显示，双池方案能够同时将各应用的 TTFT 和 TPOT SLO 达成率维持在 96% 以上。

小结： Steady Pool 与 Elastic Pool 并不是两种可相互替代的实现，而是分别解决长期资源效率与短期流量弹性。任何单池设计都难以同时覆盖这两个目标。

D2D Fork 与模型生命周期

671B 参数 DeepSeek-V3 突发期间，D2D Fork 与 H2D Wakeup 的 SLO 表现。

对于 Qwen3-8B、Qwen3-32B 和 DeepSeek-V3 671B 等不同规模的模型，D2D Fork 均能在 388–783 毫秒内完成副本激活。对于 671B 模型，D2D Fork 耗时 0.74 秒，而 H2D Wakeup 需要 2.71 秒，前者快约 3.7 倍。

在 671B 模型的突发实验中，D2D Fork 将 SLO 达成率维持在约 98%，H2D-only 则下降到约 90%。与此同时，复制过程对源实例的影响较小：671B 模型的 P99 TPOT 最大上升 5.7%，传输完成后立即恢复。

小结： D2D Fork 的关键价值不仅是缩短权重复制时间，而是把大模型扩容延迟压缩到能够真正响应秒级突发的范围内。

xTensor 效果

在包含 12 个服务和 3 个基础模型的驻留密度实验中，共享 xTensor 只需要 1 个设备，静态分区和每进程独立 xTensor 均需要 3 个设备，实现了 3 倍的模型驻留密度。

在四个 1.7B 模型共享单设备的突发实验中，关闭 xTensor 后，平均 SLO 达成率下降到 81%，P99 TTFT 上升到数秒；启用动态显存重分配后，SLO 达成率保持 100%，P99 TTFT 仅为几十毫秒。在 10、30 和 60 秒周期的持续显存分配压力下，xTensor 的碎片率始终低于 0.3%。

小结： xTensor 并非单纯的显存分配优化，而是实现高密度多模型共置、弹性显存重分配和 D2D Fork 的共同基础。

请求调度与装箱质量

在请求调度实验中，LST-IMH 在高负载下明显优于 Round-Robin 和 Least-Load。请求速率达到 2 倍时，LST-IMH 的TTFT SLO 达成率为 91.2%–92.4%，Round-Robin 和 Least-Load 分别为 64.8% 和 70.2%。

在 24 小时轨迹上，Janus 的在线增量装箱算法在 99.99% 的时间里与 OR-Tools 的最优设备数量一致，从未比最优解多使用超过一个设备，同时决策速度提升 4.3 倍。该结果说明系统可以在不频繁求解全局优化问题的情况下，保持接近最优的放置质量。

05 总结

Janus 面向生产级多大模型服务中的三个核心问题：突发且难以预测的流量、呈幂律分布的应用热度，以及模型间异构但互补的资源需求。系统以双时间尺度调度为主线，将中心化 Service 层与分布式 Engine 层协同起来。

在 Service 层，Performance Oracle、慢路径向量装箱、快路径弹性扩缩容和 LST-IMH 请求调度分别负责性能建模、资源放置、容量调整与 SLO 感知分发；在 Engine 层，xTensor、三状态模型生命周期和 D2D Fork 为多模型共置与快速副本启动提供运行时基础。

生产轨迹实验表明，Janus 能够在降低 27% 设备用量的同时，将 SLO 达成率维持在 0.97–1.0。双资源池、D2D Fork 与xTensor 的消融结果进一步说明，生产级多模型服务不能只依赖单一调度策略或单点优化，而需要让全局调度与底层资源管理共同围绕流量变化进行协作。

06 开源与生态

2025 年 8 月，xLLM 项目正式开源。xLLM 将与多家国产芯片厂商、大模型厂商一起，继续加速技术演进。欢迎在 GitHub 了解详情：

• xLLM：https://github.com/xLLM-AI/xllm
• xLLM-service：https://github.com/xLLM-AI/xllm-service

最后，感谢每一位团队成员的付出，也感谢一路以来支持与信任我们的生态伙伴。基础设施领域的黄金时代才刚刚开始，让我们一起，继续深耕大模型推理系统，建设一流的人工智能基础设施。