Janus：生产规模的多模型服务（SOSP 2026）
原题：Janus: Multi-LLM Serving at Production Scale
一句话总结：62 个应用的生产轨迹同时呈现秒级突发、长尾热度和模型资源需求差异；Janus 用 30 秒的稳定放置与 0.5 秒的弹性扩缩容处理不同时间尺度，再以共享显存管理和设备间复制支撑快速执行。在 603,000 请求的开放环回放中，SLO 达标率为 0.97–1.0，静态 ServerlessLLM 基线为 0.80–0.92，设备时减少 27%（摘要、§7）。
问题与动机
单模型引擎优化吞吐，解决不了模型服务平台同时容纳几十到几百个应用的放置问题。不同模型的权重占用、SM 计算和 HBM 带宽需求不同，请求量也随时间变化。给每个模型固定 GPU 副本浪费容量；完全按短期流量搬迁权重，则会把负载波动变成频繁的冷启动。
作者从 2026 年 3 月 10 日的 62 个应用轨迹观察到：前 12% 应用贡献约 80% 请求，同时有明显秒级流量突发；模型的 HBM 容量、计算和带宽需求可互补（§2.2、图 1）。这使“多模型共享”同时成为放置、请求路由和运行时内存管理问题。这里的应用是同一基础模型的不同微调权重，评测共九种基础模型；请求热度按应用统计，不应误读为九个基础模型的热度（§7.1）。
Janus 的生产硬件并非 NVIDIA GPU 集群。端到端实验使用 48 台服务器、共 768 个 Ascend 910C NPU die，每个 die 64 GB HBM；同一 supernode 内设备间实测单向 163.6 GB/s，host→device 为 59.0 GB/s（§7.1）。因此论文中的设备间快速复制优势，与这种跨服务器统一互连能力有关；若部署在 PCIe 网络或普通多机 GPU 集群，复制时间必须重新测量。
关键观察 / 隐含假设
- 热度分布与突发时间尺度不同：长尾模型适合较慢的紧凑放置，头部模型需要更快的副本伸缩。30 秒与 0.5 秒两个周期对应这两类变化（§2.2、§4.2）。若流量在更短时间内剧烈变化，快周期也可能滞后。
- 多资源互补有共享收益：模型的 HBM 容量、SM 和 HBM 带宽占用不能用单一“GPU 数量”准确表示（图 1c）。但共置收益依赖性能预测器能识别相互干扰，不能仅凭平均利用率判断。
- 扩容路径必须避免完整冷加载：快速调度只有在引擎能复用现有权重、设备间直接复制时才有效（§5）。这隐含同一集群内存在可用的源副本和足够的传输带宽。
- SLO 预测比单纯流量阈值更贴近决策：相同请求数可以对应不同输入、输出长度；Oracle 用 token/request rate 和长度均值、方差推资源向量与 SLO 达标率（§4.1）。但均值、方差难完整表达极端长请求的尾部。
- 两层资源池有明确优先级：稳定池先占用足够设备，弹性池使用剩余设备；弹性目标总量超预算时按比例缩小配额，再用最大余数法离散化（§4.2）。这种策略在紧缺时保护模型驻留，但不保证头部应用的单请求公平性。
核心方法
Janus 分为集中决策的 Service 层和分布执行的 Engine 层（图 2）。Oracle 包含两个不同目标的高斯过程：Capacity GP 预测模型在稳定负载下的 HBM 容量、SM 算力和 HBM 带宽三维需求；Elasticity GP 接受相同工作负载特征及当前副本数，预测 SLO 达标率。前者驱动 30 秒一次的稳定池装箱，后者通过二分搜索最小可行副本数，驱动 0.5 秒一次的弹性池伸缩（§4.1–§4.2）。训练样本稀少时，GP 的不确定性用于保守超配。
稳定池把每台设备看作容量 (1,1,1) 的三维箱子；新模型放入资源互补且可行的箱子，模型离开时只有碎片损害超过阈值才重新装箱，后台再周期性做全局整理。这个潜势函数方案的目标是既减少设备数又减少模型迁移，不能只用最低箱数评价它。弹性池在资源不足时按目标副本数比例分摊，反振荡窗口拒绝在最近两个计划之间来回切换；从缩容模型释放的设备可与扩容模型激活重叠（§4.2）。
Request Scheduler 维护每个模型的集中队列以及各预填充实例的预计完成时间。一个实例接近空闲时触发 LST-IMH：先处理截止时间约束更紧的实例，在每台实例上用 Moore–Hodgson 选择可按时完成的请求；被拒的请求再尝试后续实例，最终无法容纳的请求立即超时或按放宽截止时间重新入队（§4.3）。论文给出最大化按时完成数的 2 近似保证，但这是针对估算处理时间的数学问题；真实请求长度预测错误仍可造成违约。主动丢弃长请求也改善总体达标率，却可能损害长输入用户。
Engine 层用 xTensor 在框架分配器下面提供连续虚拟地址空间，物理 HBM 页统一入池。权重长期稳定，启动时映射并注册大块全局 xTensor，此后通过片段分配避免频繁驱动调用；KV cache 和 activation 短命且细粒度，从已映射页缓存分配，缓存不足时后台再映射。权重从物理页池一端取页、动态状态从另一端取页，降低互相碎片化（§5.1、图 3）。作者测得逐 2 MB 页 map/unmap 约 37/235 微秒；若大权重逐页映射，累计可达到秒级，解释了为什么不能简单把所有 tensor 都当成同一种分页对象。这条路径与 PagedAttention 的请求内 KV 分页不同，目标是多模型之间的显存弹性。
模型生命周期有活动、温热和冷态。稳定池唤醒温热模型可从 pinned host memory 做 H2D 加载；弹性池急需新副本时，D2D fork 从活动副本直接把权重送到目标设备，不经 host 暂存。模型创建时的 TP/DP 度数固定，伸缩副本数不改变单个副本的并行形态（§5.2）。多模型计算依靠独立 stream 复用硬件。P/D 分离所需的 KV 地址注册不能直接套用延迟物理映射，因此实现使用启动时注册的全局 xTensor 并转换偏移（§5.3）。
设计取舍
- 更紧的共置换取性能预测与隔离成本：预测器的误差会传播到放置和请求截止时间；多租户干扰可能使原本互补的资源需求失效。
- 快速扩容换取待命容量：弹性池和可复制源副本占用设备；完全饱和时没有免费扩容空间。
- 统一显存池换取运行时改造：xTensor 避免固定切分，但地址管理、框架兼容和模型状态迁移变复杂（§5.3）。
- 按时完成数换长请求待遇：LST-IMH 会主动舍弃可能拖累多个短请求的任务。若服务合同要求所有请求最终完成，须启用重入并接受较低达标率。
- 保守预测换设备占用：新模型样本少时高斯过程高不确定度促使超配，这有利于 SLO，却会暂时降低弹性池可用设备。
实验与结果
- 作者报告部署在 768 个 Ascend 910C NPU die 的生产集群，覆盖 62 个应用、每日约 4560 万请求。W0 先按比例抽取约 603,000 请求，再把 24 小时到达时间压缩为 30 分钟，实际回放平均到达率约为生产日的 0.64 倍；保留应用占比、到达顺序与归一化突发形态。系统在相同设备池、模型、TP、SLO 与到达序列下开放环比较，错误和超时计为违约（§7.1）。
- W0 日间高峰时 Janus 达标率 0.97–1.0，Prism 通常 0.80–0.92 且一次降至 0.51，BlitzScale 约 0.60–0.65，静态 ServerlessLLM 约 0.22–0.30。Janus 日间有效吞吐约 400–500 请求/秒，峰值约 620；夜间四者约 30–80 请求/秒，说明收益主要出现于资源竞争期（§7.2、图 4）。
- Janus 使用约 390–480 台设备（夜间）与 580–660 台设备（日间），折合 13,440 device-hours/天；静态 ServerlessLLM 为 18,432，节约 27%。W0 的绝对延迟 P50/P90/P99 TTFT 为 57.5/161/395 ms，TPOT 为 7.2/12.3/18.5 ms（§7.2、§7.4）。
- 隔离全局协调作用：给 Prism 加 Janus 的跨应用设备分配器，应用平均达标率从 92.7% 升到 97.6%，最低应用仅 50.2%→57.2%；移除 Janus 全局协调后平均从 99.4% 降到 96.9%，最低应用降至 82.0%；完整系统最低应用为 90.0%。这说明全局分配、快速复制和装箱分别影响平均与尾部应用（§7.2）。
- 单组件与预测器：五应用的双池消融达标率 97.8%，仅弹性池 59.0%，仅稳定池 37.1%（图 10–11）；DeepSeek-V3 的 D2D fork 742 ms，H2D 唤醒 2712 ms（表 1）。Capacity GP 的 HBM 预测 P90 相对误差 2.75%，SM/带宽约 24%；Elasticity GP 的 SLO 预测 P90 绝对误差达 19 个百分点，表明极端负载仍可能错误扩容（图 8）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 多模型负载同时需要慢放置和快扩容 | 62 应用的突发与热度分布（§2.2、图 1）；双周期调度（§4.2） | 单一平台、单日轨迹 | 中 |
| 联合调度与运行时能提高 SLO 达标率 | 日间 0.97–1.0，Prism 0.80–0.92（§7.2、图 4） | 603,000 请求、压缩 30 分钟、平均速率约真实日 0.64 倍 | 强（该回放） |
| 双池各自不可替代 | 97.8% 对仅弹性 59.0%、仅稳定 37.1%（§7.4、图 10） | 五应用、120 秒突发片段 | 中到强 |
| 共享资源降低容量成本 | 13,440 device-hours/天，比静态 ServerlessLLM 少 27%（§7.2） | Ascend supernode、固定模型/TP；静态基线占满 768 die | 中到强 |
| 快速复制依赖互连能力 | DeepSeek-V3 D2D 742 ms 对 H2D 2712 ms（表 1） | UnifiedBus D2D 163.6 GB/s、H2D 59.0 GB/s | 强（该硬件） |
批判性分析
论证链条
图 1 的三类生产现象分别对应双时间尺度放置、弹性扩容和多维资源预测。双池和全局协调的消融比纯端到端比较更能定位收益。最需要区分的是“生产部署”与“量化对照”：主结果来自采样后压缩到 30 分钟的 W0 回放，不是连续 24 小时在线 A/B；0.64 倍原生产日平均到达率也可能低估容量压力。
假设压力测试
若应用热度高度均匀，稳定池的长尾紧凑放置收益会下降；图 7 的较均匀 Poisson 负载中系统间差距确实缩小。若模型频繁变更、权重版本多且源副本难复用，设备间 fork 的复制优势也会减弱。跨机网络拥塞或异构 GPU 会让 0.5 秒决策周期与实际副本就绪时间脱节。与主评测的 Ascend 统一互连相比，普通 PCIe 多机 GPU 的 D2D 路径尤其需要重测。
实验可信度
真实生产轨迹、多个模型规模和开放环回放比合成均匀请求更有代表性；W2–W7 公共轨迹提供补充。但单日抽样、单个 Ascend supernode、请求数压缩后的速率以及对照系统的移植配置限制了外推。ServerlessLLM 基线被静态绑定到均分设备池，因而 27% 设备时收益部分反映“弹性对静态”的差异；更难的比较是同样支持全局弹性且使用相同 D2D 路径的系统。近似算法保证依赖估算处理时间，不能证明所有租户的公平性。
系统性缺陷
Service 层集中预测和决策成为控制面依赖，论文未充分量化预测持续漂移、故障时策略降级和租户隔离。xTensor 需要引擎配合，且连续权重区在外部碎片过高时要回退到独立虚拟映射；“统一池”并没有消除所有碎片。实现规模约增加 Service 8 KLOC、Engine 21 KLOC（§6），维护成本不可忽略。负载提高到 5 倍时平均排队占总延迟 43.3%，提示调度器本身在高压力下成为新瓶颈（§7.4、图 9）。
局限与后续工作
- 用多日、多租户轨迹报告扩缩容触发次数、源副本缺失率、预测误差与 P99 SLO 违规率；保留 24 小时真实时间轴做对照，检验时间压缩影响。
- 在跨机网络受限或异构 GPU 条件下测量设备间 fork 的就绪时间和稳定池重排成本，与同样支持全局弹性的基线比较。
- 测量被 LST-IMH 主动舍弃的长请求比例、重入后的完成率与租户公平性。
- 将设备时成本与电力、冷启动、模型版本更新成本放到同一优化目标中比较。
相关
- 同会议：SOSP-2026；相邻问题：SANDHI-SOSP26 的共置内存压缩、EnerTune-SOSP26 的能耗约束、ACDC-SOSP26 的离线任务调度。
- 全文：作者公开 PDF。