面向AI原生负载的统一弹性调度体系：Aether架构实践

导语

大模型时代的到来，让AI工作负载呈现出高吞吐、高算力、低延迟的“三极化”特征。为了最大化算力投资回报率，训推混部已成为行业常态——白天保障高并发推理服务，夜间释放算力给大规模训练任务。然而，这种潮汐式的算力复用需求，对底层调度系统提出了前所未有的挑战。

京东零售九数AI平台自研了 Aether 统一弹性调度体系，旨在解决大模型时代训推混部下的潮汐流量、常态故障、资源碎片化及异构硬件多样性等痛点。本文将深度拆解 Aether 的架构设计与落地实践，探讨如何通过动态SLA规则、自适应资源调度和预测性保障与自愈，实现对训练、推理和服务负载的统一高效调度。

核心问题与挑战

在万卡级GPU集群的日常运营中，传统调度系统往往面临以下四大核心痛点：

1. 潮汐流量与资源争抢：推理服务白天承载高并发流量，训练任务夜间抢占算力。负载波动导致资源争抢激烈，难以同时保障推理的SLA和训练的利用率。
2. 万卡集群故障常态化：大规模集群中GPU/NPU故障从偶发转为常态，导致长周期训练任务频繁中断，推理节点抖动严重影响服务稳定性。
3. 资源碎片化严重：集群中存在大量单卡、半卡等碎片化资源，大通信矩阵的训练任务无法有效利用，算力被白白闲置。
4. 异构硬件多样性：多厂商、多代际异构硬件导致算力规格、显存与算子兼容性差异极大，调度复杂度指数级上升，难以实现业务无感调度。

方案与实践

整体架构设计：Aether核心引擎

为解决上述痛点，我们设计了Aether统一弹性调度体系。其核心引擎包含三大组件：

• Brain：全局大脑，负责收集作业执行历史，进行全局调度决策与规则生成。
• Driver：作业驱动器，负责单作业的生命周期管理、状态机维护与规则执行。
• Executor Manager：执行器管理器，负责底层资源调谐、节点状态监控与具体指令执行。

在调度编排流程上，Aether遵循清晰的三阶段与三步骤：

• 调度编排三阶段：入队统一管理 -> 排序打分 -> 绑定集群。
• 资源编排三步骤：资源预占 -> 部署分发 -> 监听调谐。

关键技术挑战与方案实现

1. 云原生融合与动态SLA保障

面对潮汐流量，Aether融合了KubeRay等云原生框架，并引入动态SLA规则引擎。该引擎支持人工设置与自动生成，根据用户提供的模型、数据与QPS要求，动态生成SLA规则，指导推理与训练作业的弹性伸缩，实现“推理服务白天扛流量，训练任务夜间抢算力”的平滑过渡。

2. 自适应资源调度与碎片聚合

针对资源碎片化与异构算力调度难题，Aether基于资源画像与预测模型，实现了自适应资源调度与智能弹性伸缩。在底层，通过调度器插件机制（优先级队列、资源预留、负载感知），实现了精细化调度与碎片聚合，将零散的单卡、半卡资源重新打包分配给可拆分的负载，榨干集群算力。

3. 自动故障检测与隔离

针对异构硬件的常态故障，Aether实现了自动化的故障检测与隔离机制。当检测到GPU/NPU节点异常时，系统立即将其从可用资源池中隔离，避免训练任务被分配到坏节点，同时触发替换恢复流程。

4. 动态组网与拓扑自愈

长周期训练任务对通信拓扑极度敏感。Aether支持分布式训练场景下的动态组网与拓扑自愈。当Worker节点发生故障被隔离后，系统能够自动重新拉起新的Worker，动态调整通信组网拓扑，实现训练任务的无感容错恢复。

业务落地实践

Aether架构已在京东零售业务中全面落地，取得了显著的量化收益：

• 训练提效：有效训练时间占比（ETTR）提升至 97%，极大减少了因故障和资源等待带来的算力浪费。
• 推理降本：显著缩短了批量推理时间，并通过潮汐混部大幅降低了整体算力成本。
• 架构升级：在PD分离架构（Prefill与Decode分离）的大模型推理服务中，Aether有效提升了端到端的推理效率与服务吞吐。

原则/方法论沉淀

在构建统一弹性调度体系的过程中，我们沉淀了以下核心方法论：

• 弹性调度四要素：

  • 条件（感知层）：何时触发扩缩容，依赖精准的流量与负载感知。
  • 策略（决策层）：如何扩缩容，依赖动态SLA规则与预测模型。
  • 粒度（执行层）：扩缩容的最小单位，需兼顾业务特性与资源池现状。
  • 速度（效率层）：扩缩容的端到端耗时，决定了对流量突发的响应能力。

• 故障处理机制：坚持“及时检测隔离、自动容错恢复、弹性计算增减节点”的原则，将故障应对从人工抢救升级为系统自愈。

总结与行动建议

Aether架构的实践证明，面向AI原生负载，统一、弹性、韧性的调度体系是释放算力价值的关键。对于正在构建或优化AI基础设施的工程团队，建议：

1. 将韧性调度作为一等公民：在万卡规模下，故障是常态，调度系统必须原生具备检测、隔离与拓扑自愈能力。
2. 重视资源画像与预测模型：弹性调度的前提是“可预测”，建立精准的业务画像与资源基线是智能伸缩的基础。
3. 拥抱云原生与标准化：通过插件化与云原生框架融合，屏蔽底层异构硬件的复杂性，向上提供标准化的调度能力。

未来，Aether计划支持更多异构算力，并逐步走向开源，与社区共建AI原生调度新范式。

开放问题与延伸方向

1. 动态SLA规则引擎在感知潮汐流量并触发弹性伸缩时，其端到端决策与执行延迟的具体基准数据是多少？（关联SLA规则引擎的实效性评估）
2. 落地实践中“显著提升有效训练时间占比”与“缩短批量推理时间”的具体量化指标及其测试前提条件是什么？（关联落地数据的严谨性与可复现性）
3. 多厂商异构硬件的算子兼容性差异极大，仅靠调度层屏蔽底层复杂性是否过于乐观，隐性适配成本会不会抵消弹性收益？（关联异构适配的深层工程挑战）
4. 训练任务具有强通信依赖而推理任务对尾延迟极度敏感，Aether在训推混部时如何避免网络与显存争抢导致的SLA雪崩？（关联混部场景下的底层隔离机制）
5. 万卡规模下，中心化的Brain组件是否会成为调度决策的单点瓶颈，其状态同步的延迟如何影响拓扑自愈的实效性？（关联架构在超大规模下的扩展性）
6. 基于资源画像与预测模型的自适应调度，是否意味着Aether能够实现无人工干预的“夜间训练、白天推理”算力无缝切换？（关联自适应调度的自动化极限）
7. 面对单卡、半卡等碎片化资源，除了调度器层面的碎片聚合，是否考虑过在算子编译层引入动态切分与拼接机制来提升利用率？（关联计算与调度协同的优化空间）
8. Aether的动态组网与拓扑自愈机制，能否迁移应用于跨数据中心的多地多活算力调度场景，以应对机房级故障？（关联自愈机制的跨边界泛化能力）
9. 在Aether走向开源的Roadmap中，如何平衡通用性（适配多种K8s发行版）与京东内部极致性能优化之间的架构矛盾？（关联开源战略的架构解耦思路）
10. 评价统一弹性调度体系优劣的核心指标体系是什么，是否应包含资源碎片率、SLA违约率与故障恢复MTTR的综合权衡？（关联调度系统方法论的标准构建）