Source UnderstandingAegaeon / SOSP 2025

Core claim

Aegaeon 把 GPU 池化从“等请求结束”推进到“按 token 抢占”

论文的核心判断不是“多模型共存”，而是 request-level autoscaling 在 LLM 长服务时间下仍会被活跃模型数卡住；Aegaeon 用 token-level scheduling 和低成本 preemptive autoscaling 才把池化密度推到生产可用。

Figure 2: request-level versus token-level auto-scaling overview
Figure 2：从 request-level “等请求结束”改为 token-level preemptive autoscaling。
Fig.1长尾与 burst 解释为什么 dedicated GPU 浪费。
Fig.6prefill/decoding 分治解释怎么守 SLO。
Fig.11/18实验 goodput 与生产 GPU 节省闭环。
Problem模型市场里长尾模型低频、热门模型突发，dedicated GPU 预留造成结构性浪费。
Mechanism在 token 间隙抢占模型，而不是等完整请求结束后再 autoscale。
Result通过调度、组件复用、自管内存和 KV 同步，把高密度池化做成在线路径。
82%生产部署 GPU 从 1,192 降到 213
7/GPU实验中支持最高 7 个模型共享每张 GPU
97%autoscaling overhead 通过全栈优化降低
1.5-9x相对 baseline 的 goodput 提升范围
Thesis first; details follow
Source Understanding deck，仅用于审批来源理解；本 skill 到此结束。
01 / Problemmarket workload

Long tail + burst

模型市场的浪费来自两个方向：冷门长尾和热门突发

Aegaeon 的问题背景是 Alibaba Cloud Model Studio 这类模型市场：模型很多、请求分布极不均匀，dedicated serving 会给低频模型预留整张 GPU，同时热门模型又需要额外冗余抗突发。

论文报告：94.1% 的 779 个模型只承载 1.35% 的 167.6M 请求，却占用 17.7% 的 30K GPU；这类请求平均低于 0.2 req/s/GPU。
Dedicated serving每个模型预留实例，冷门模型空转；热门模型还要额外 reserve 抗突发。
Pooling target把低频/突发请求并入共享 GPU，但不能让 HOL blocking 破坏 TTFT/TBT。
Figure 1: workload skew and burst traffic
Figure 1：长尾模型请求占比和热门模型 burst 现象。
Evidence: Figure 1 + introduction workload statistics
02 / Limitactive-model bound
Figure 4: active model count over time
Figure 4：100 个模型、总到达率 3.7 req/s 时，活跃模型数估计值 E[m]=46.55。

The bottleneck

request-level autoscaling 被“活跃模型数”卡住

即使请求总量低，LLM 请求服务时间长也会让很多模型同时处于 active 状态。现有 autoscaling 只能等一个请求完成后再换模型，少配 GPU 会让新模型请求在队首阻塞。

方案
粒度
瓶颈
结果
Multiplexing / MuxServe
同卡常驻
显存容量
通常 2-3 模型/GPU
ServerlessLLM
request
等待请求结束
HOL blocking
Aegaeon
token
autoscaling 成本
目标是低成本抢占
Evidence: Theorem intuition + Figure 4
03 / Key ideapreempt before request end

Token-level pivot

Aegaeon 的关键动作：不等请求结束，就在 token 间隙换模型

request-level 让模型 B/C 等待模型 A 的完整请求完成；token-level 则在每步 prefill/decoding 之间抢占，把 pending model 拉上 GPU，从而减少 TTFT/TBT deadline miss。

  • 抢占对象：active model 的下一段 token 计算，而不是完整请求生命周期。
  • 优化目标：最大化 per-token SLO attainment，而不是只追求吞吐。
  • 工程前提：autoscaling 必须低到能插进 token 调度循环。
Figure 2: request-level versus token-level auto-scaling
Figure 2：request-level 与 token-level auto-scaling 的对比。
Evidence: Figure 2 + §3.2 approach
04 / Objectivetoken deadline
Figure 3: token-level SLO attainment
Figure 3：SLO attainment 是 token generation time 满足 deadline 的比例。

SLO lens

调度目标对齐用户体感：首 token 和后续 token 分开看

论文把 SLO 定义为 token deadline 达标比例。TTFT 太慢会造成用户明显停顿；单个后续 token 延迟可能被已输出内容缓冲掩盖，因此 prefill 与 decoding 需要不同调度策略。

TTFT首 token deadline，用户最容易感知等待
TBT后续 token 间隔 deadline，影响流式输出连续性
Buffered已有 token 能吸收部分后续延迟
SLO按 token 达标比例，而不是单一平均值
Scheduler围绕 deadline 做抢占和批次选择
Evidence: Figure 3 + §2.1 metric definition
05 / Architectureproxy + prefill + decode

System shape

Aegaeon 把请求路由、token 调度和模型换入换出合在一条控制链里

Proxy 接收不同模型请求；实例被划分为 prefill 和 decoding；每个实例内部有 scheduler、VRAM buffer、unified CPU KV cache、model cache，并通过 Redis 同步请求状态。

  • 同一 GPU 实例可接不同模型请求，但执行前要完成模型和 KV cache 切换。
  • 抢占式 auto-scaling 是热路径操作，不再是后台扩缩容。
  • 内存管理跨 GPU VRAM 与 CPU DRAM，避免频繁 GC 和碎片化。
Figure 5: Aegaeon system overview
Figure 5：Aegaeon system overview。
Evidence: Figure 5 + §3.3 overview
06 / Schedulingdisaggregation

(a) Prefill-prioritized scheduling

GPU 0
P1P4D1P5TBT miss
GPU 1
P2P3D2D2D2P6TBT miss
prefill 优先能照顾首 token，但 decoding 被拖延，后续 token deadline 更容易错过。

(b) Decoding-prioritized scheduling

GPU 0
P1D1D1D1P3P4P5
GPU 1
P2D2D2D2D2D2TTFT miss
decoding 优先能守住流式输出，但长输入或突发 prefill 会拉高 TTFT。

(c) Disaggregated scheduling

Prefill
P1P2P3P4P5P6
Decode
D1D1D2D2D345D345
Aegaeon 将 pool 分区：prefill 用 grouped FCFS，decoding 用 weighted round-robin。

Why split phases

统一调度很难同时照顾 TTFT 与 TBT

prefill-first 会在突发请求中伤害 TBT；decoding-first 会在长输入请求中伤害 TTFT。Aegaeon 因此把 GPU pool 分成 prefill partition 和 decoding partition。

阶段
调度策略
优化对象
原因
Prefill
Grouped FCFS
TTFT
首 token 等待更敏感
Decoding
Weighted round-robin
TBT
按 deadline 风险分配 turn quota
Autoscaling
joint decision
SLO attainment
换模型成本进入调度判断
Evidence: Figure 6 + §4 scheduling
07 / Scale-up path97% overhead reduction

From tens of seconds to token-loop feasible

97% overhead 不是单点优化，而是把换模型路径逐段拆掉

Figure 7 crop: default preemptive autoscaling stages
Figure 7 左侧放大：默认路径含 KVout、GC、DistExec init、Modelin、Profile、KVinit、KVin 等阶段。
Figure 7 crop: inference engine initialization and 26.9s vs 0.8s bars
Figure 7 右侧放大：vLLM 初始化约 26.9s，Aegaeon 组件复用后约 0.8s。
Default T0
26.9s
Reuse
-80%+
Memory
no GC
Prefetch
hidden
Final
0.8s
组件复用executor、worker、profiling、tokenizer 跨模型保留，只换权重与 KV cache。
显存自管自管 VRAM buffer 和 host memory pool，去掉 allocator 碎片与 GC。
KV 重叠Figure 10 的 CUDA event 同步让 transfer overlap 不破坏 inference。
97% 论文结论：上述全栈优化将 preemptive autoscaling latency 从默认路径逐步压低到优化路径；Figure 7-10 分别支撑组件复用、显存/内存自管、KV cache 同步和最终 overhead reduction。
Evidence: Figure 7 + §5.1 component reuse
08 / Memoryexplicit management

Fragmentation control

显存与 CPU KV cache 自管，是 token-level 抢占能跑起来的工程底座

Aegaeon 启动时一次性申请模型权重和 KV cache 所需 VRAM，monkey-patch 参数分配进入自管 buffer；CPU 侧用 unified KV cache 处理不同模型 KV 形状，减少碎片和复制阻塞。

Table 1: KV cache shape and size by model
Table 1：不同模型单 token KV cache 形状和大小不同，固定块预分配会浪费。
Figure 9: explicitly managed memory in Aegaeon
Figure 9：self-managed VRAM buffer、model cache、stage buffer 和 unified CPU KV cache。
Evidence: Figure 9 + Table 1 + §5.2
09 / Synchronizationevent-gated transfers
Figure 10: fine-grained KV cache synchronization
Figure 10：KV cache swap in/out 与 decoding 之间存在三类依赖，需用 CUDA event 跨 stream/instance 同步。

The hidden race

KV transfer 必须重叠，也必须防止数据竞争

为了继续压低 autoscaling 延迟，Aegaeon 让 KV swap-in 和 swap-out 在不同 CUDA stream 异步执行；但推理、源块和目标块都有依赖，必须用 event 保护。

Rule 1 · 推理前置decode 不能在目标请求的 KV cache 完成 swap-in 前开始。
Rule 2 · 源块可读新的 transfer 要等源 blocks 上一次 transfer 完成。
Rule 3 · 目标块可写新的 transfer 不能覆盖仍被异步访问的 target blocks。
CUDA eventsrecord / query / stream wait / IPC handle 组合成跨 stream 与跨进程同步。
Evidence: Figure 10 + Table 2 + §5.3
10 / EvaluationSLO attainment

Goodput boundary

实验结果显示：Aegaeon 的收益主要来自更多模型和更高到达率下仍能守住 SLO

Figure 11: SLO attainment under load tolerance
Figure 11：固定 10 个 decoding instances，Aegaeon 在更多模型和更高 RPS 下维持更高 SLO attainment；vertical lines 表示满足 90% SLO 的最大 goodput。
2xRPS=0.1 下相对 ServerlessLLM 更高 goodput
2.5xRPS=0.5 下请求率优势更明显
7010 个 decoding instances 支持 70 个模型
90%goodput 边界按整体 SLO requirement 定义
Evidence: Figure 11 + §7.2 load tolerance
11 / Productiondeployment evidence

Production readout

生产证据强在资源节省，但口径包含冗余和混合并行配置

Figure 18: GPU utilization before and after Aegaeon
Figure 18：70 小时 GPU utilization，部署后从 13.3%-33.9% 提升到 48.1%，且论文称无可观察 SLO violation/service disruption。
213跨地域 H20 GPU 集群，承载 beta 部署
1,192原 dedicated serving 所需 GPU 数
4728 个 1.8-7B + 19 个 32-72B 模型
边界生产冗余用于峰值和容错；绝对利用率不能直接等同实验 goodput
Evidence: §7.5 production deployment + Figure 18