万卡竞赛背后：容器正在成为 AI 时代的调度大脑

今年，我们见证了 Agent 与 AIGC 应用的大爆发。在基础设施层面，究竟什么能够推进 AI 应用的持续发展？Gartner 给出的参考答案是容器——预计到 2027 年，超过 75％ 的 AI/ML 工作负载将通过容器技术进行部署。但这个答案并不完整。值得注意的是，由于 AI 负载普遍具备大规模分布式、硬件强亲和、高数据吞吐、快速故障自愈等特性，现有的容器技术栈并不能“拿来即用”。

任何团队基于容器开展 AI 业务前，都需要解决两大技术挑战：

其一，是如何重构以 Kubernetes 为核心的 AI 基础设施，找到算力调度与容器编排的真正“最优解”，充分发挥底层算力价值；其二，随着 Kubernetes 集群规模不断扩大，运维和资源管理的复杂性急剧攀升——如何借助容器封装不同资源（如 CPU、GPU），以统一的容器算力抽象描述业务对异构算力的需求，从而简化配置与管理流程、推动业务高效迭代？

二者难度都很高，许多团队在应对第一个挑战时，可能就会陷入迷茫——毕竟，如果业务负载变了，底层算力也变了，位于中间的 Kubernetes 还是那个“最优解”吗？

K8s 还是最优解，但需要做出改变

Kubernetes 能够成为容器编排领域的事实标准，关键在于其强大的开源生态，以及为实现容器化应用的统一部署、扩展与管理所奠定的技术基础。

阿里云 ACS 智算技术负责人逐灵的观点是，在 AI 时代， Kubernetes 并不是“要被颠覆的旧平台”， 恰恰相反，它正是当下承载 AI 的最佳底座。

Kubernetes 通过强大的扩展机制，已经提供了对 GPU 调度，RDMA 高性能网络，以及各类云存储（如 OSS、CPFS 等）。而且在 Kubernetes 已经成长出 KubeRay, Kubeflow 等丰富的 AI/ML 应用生态。

只不过，Kubernetes 毕竟并非为 AI 任务而生的，因此还需要在技术上作出调整。

传统微服务中，副本通常是无状态且对等的，任何一个实例宕机都能被快速替代，一个 Deployment 足以轻松管理一切。

但在 AI 场景下，一个训练 Job 或推理服务往往由多种角色的、有状态的副本组成（如 Parameter Server、Worker-0、Worker-N 等）。这些副本在启动顺序、生命周期和异常处理上紧密耦合，必须“同生同死”。

此外，运行 AI 负载的底层硬件也从 CPU 主导转为 GPU 主导。而要实现 GPU 的最佳调度，核心面临三大挑战：

• 异构设备协同：任务不再只关心 GPU，还需同时绑定特定的 RDMA 网卡、NVLink/PCIe 拓扑、NUMA 节点等，任何一项错配都会导致性能急剧下降。

• 拓扑感知调度：为避免通信瓶颈，调度器必须确保同一作业的多个 GPU 实例落在同一高带宽域内（如 NVSwitch 或 InfiniBand 子网），并保证 CPU 与 PCIe 的亲和性。

• GPU 利用率提升：业界正探索 GPU 切片、动态共享、MIG、时间片复用等多种技术，试图将多任务塞进同一张卡，最大化昂贵硬件的价值。

因此，AI 场景下的调度系统必须围绕“异构拓扑 + 资源切分”重新设计，而非简单沿用旧策略。

最后，除此之外，在 Kubernetes 运行 AI 工作负载仍然有众多的工程挑战，如何在底层故障后快速恢复？如何加速大模型推理冷启动时效等？

目前，行业出现两条解决路径：

第一条是扩展 Kubernetes，构建 GPU 调度、AI 应用负载、数据加速、故障自愈等核心能力，让 Kubernetes 原生成为运行 AI 应用的第一选择。

第二条是把 CPU/GPU/ 网络 / 存储全部打包，变成“可秒级交付的算力单元”，以 Kubernetes 为界面，开发者只需将需求写进 YAML，就能以更低门槛的方式调动千卡集群。

而过去十年，将同一套容器底座，置于国内最大电商流量洪峰、全球最大 AI 训练集群里分别验证过的阿里云，同时跑通了这两条路线，最终呈现为阿里云容器服务 Kubernetes 版 ACK(简称 ACK ）、阿里云容器计算服务 ACS（简称 ACS ）的协同演进。

从集群到算力： 容器技术双轨演进

2017 年阿里云 Kubernetes 服务 ACK 开始对外提供技术服务。2023 年，ACK 提供云原生 AI 套件，让企业能够在 Kubernetes 容器平台上快速构建和运行 AI 应用，实现全栈优化。

从 2023 年 Gartner 首次发布《容器管理魔力象限》报告开始，阿里云入选“领导者”象限。8 月 7 日，Gartner 公布了 2025 年度全球《容器管理魔力象限》报告，阿里云已经连续三年入选“领导者"象限。在最新发布的 Gartner 容器管理 MQ-CC 说明中，除了在部分 Use Case 中表现优秀，阿里云还在云部署、IT 运维两项关键能力上与其他厂商并列第一；在本地部署、AI/ 机器学习以及容器平台功能、安全与治理四项关键能力上，甚至超越了亚马逊、微软等美国领导厂商。

目前，包括月之暗面（Kimi）、Minimax、百川智能在内的多家头部 AI 公司，都选择 ACK 作为其核心的容器编排平台。

但阿里云不止步于此，由于 K8s 所需技术技能太高了。企业如何才能参照业务特性与规模，更简单、灵活地使用容器服务？

这是阿里云于 2023 年推出容器计算服务 ACS 时想要解决的问题。ACS 并非简单地为 K8s 增加一个 Serverless 选项，而是将其内核能力进行了一次革命性的重塑，将关注点从“管理集群”彻底转向“消费算力”。

所谓“消费算力”，其实是在“ACS 模式”下，弱化“物理资源”、“节点池”等概念，从根本上解耦物理 GPU，并且从被动运维转向主动式智能管控。

传统的 Kubernetes 调度器将 GPU 视为一个不可分割的、绑定在特定物理节点上的“黑盒”资源（如 nvidia.com/gpu: 1）。这种模式直接导致了三大难题：资源浪费（一张高端 GPU 卡只跑一个小任务）、调度僵化（任务必须等待特定节点上的整卡释放）和运维复杂（驱动、拓扑、故障处理全部压在用户身上）。

而阿里云自研了深度融合硬件特性的 GPU 虚拟化技术，它不再将 GPU 视为一个整体，而是将其精准地“切片”为更细粒度的虚拟资源单元。这种切片并非简单的 cgroup 隔离，而是深入到显存（VRAM）和流式多处理器（SM, Streaming Multiprocessor） 层面。

ACS 的调度器能够理解并独立调度 X GiB 的显存和 Y% 的计算单元。这意味着，一张物理 GPU 卡可以被多个不同需求的 Pod 安全、高效地共享，从根本上解决了资源浪费问题。这种技术使得“按显存粒度切分”和“秒级计费”成为可能，用户只需为自己消耗的“算力切片”付费，而非整张物理卡。

更进一步，ACS 将云的底层资源拆解为可秒级交易的“算力碎片”，再用 K8s 语法封装成 Pod。用户只需提交 Pod，ACS 便能在数秒内从一个庞大的公共资源池中瞬时拉起所需算力，无需再为集群的峰值容量规划并付费。

此外，在庞大的、跨地域的异构资源池中，如何为分布式训练等任务找到全局最优的算力组合？这不仅仅是找到可用的 GPU 资源那么简单。

ACS 的全局调度器集成了智能的拓扑感知能力，并在“数据中心级”级别寻找全局最优的拓扑。它将整个云底层的 GPU、节点内 NVLink/PCIe、节点间 RDMA 网络带宽构建成一张庞大的实时图谱。当一个需要 8 个 GPU 切片的分布式训练任务提交时，调度器并非随机分配，而是在亚秒内求解一个复杂的多目标优化问题：在满足资源需求的同时，最小化跨节点、跨地域的通信延迟。这确保了即使用户按需获取的是分散的“算力碎片”，也能获得媲美物理集群的高性能通信，解决了 Serverless 形态下分布式训练的性能瓶颈。

最令 DevOps 工程师开心的还是 ACS 在主动式智能管控方面的工作。ACS 的控制面彻底接管了所有底层的“脏活累活”。逐灵表示：我们建立了一个主动式的管控系统，它自动化处理了从驱动安装、版本兼容、到节点运维和故障自愈的全链路。例如，当底层硬件出现 ECC 错误或驱动异常，ACS 会主动感知并上报异常，控制面会自动隔离该故障“算力切片”所在的物理资源，并以事件的方式通知受影响的 Pod。客户可结合任务框架实现对应的异常回调函数，从而实现灵活的 failover 策略。

对用户而言，这是一个符合直觉的自愈过程，用户无需订阅并管理产品提供的故障发现组件（更无需用自主构建），可以实时获得阿里云内部超大规模异构计算集群积累的故障自愈知识库。

在 ACS 的产品形态下，用户可以用 K8s 统一描述 CPU 与 GPU 异构算力资源需求，不再关心底层节点池管理与维护。在 2024 年 9 月的云栖大会上，ACS 也首次引入了“柔性”算力概念，其 Serverless 算力支持以 0.5vCPU、1GiB 内存为步长进行精细化配置和秒级热变更。这种极致的粒度与速度（每分钟可弹至 10000 个 Pod），让算力匹配应用负载的精度和效率达到了新的高度。

“容器即算力”，这是阿里云在裸金属和虚拟机之外，通过 ACS 给到的第三类算力形态和服务承诺。而随着 2025 年，AI 应用落地的进一步加速，阿里云对 ACK 和 ACS 仍在持续加码投入。在 8 月 14 日的飞天发布会上，阿里云又正式对外宣布了 ACK 和 ACS 两项容器服务的最新进展。

其中，阿里云容器服务 ACK 在保障稳定性和提升效率两个维度均有新的技术突破。

在系统稳定性方面，ACK 实现三项突破：

• 统一 ACK 架构，收敛 GPU、灵骏、RDMA、CPFS 等异构智算资源的管理和调度，为适配工作减负；

• 实现 GPU 故障全生命周期自动化检测、诊断、修复，降低人工干预和故障影响的代价；

• 实时 AI Profiling 无侵入式观测 GPU 应用的性能表现，帮开发者按时间轴快速还原问题现场，在线定位性能瓶颈，将 GPU 应用性能的诊断效率提升 50% 以上。

此外，ACK 也全新发布了云原生 AI 套件 Serving Stack，精准解决企业内部署、集成和管理大模型推理服务的生产落地挑战。AI Serving Stack 包括 RoleBasedGroup 控制器（简称 RBG）和 Gateway Inference Extention（简称 GIE） 两大组件。

RoleBasedGroup 控制器（简称 RBG）是该套件在 Kubernetes 集群中针对 LLM 推理工作负载的抽象。RBG 支持 vLLM，SGLang，TRT-LLM 等主流 LLM 推理引擎；兼容 Dynamo，Mooncake 等各类推理性能优化架构。 RBG 能够将分布式推理工作负载中的不同任务角色（如 Prefill worker、Decode worker、Router 等），灵活地抽象为独立的 Role；并支持采集不同角色的关键监控指标（如 TTFT、TPOT、Token throughput，Request rate 等），联动推理运行时可支持基于 SLO（如平均 TTFT/TPOT）的弹性伸缩。RBG 也兼容 HPA、cronHPA、KPA、AHPA、KEDA 等 Kubernetes 生态中各类应用弹性伸缩架构，采用了 Fluid 的分布式缓存和数据预热技术。

GIE 则是 ACK 基于 Kubernetes Gateway API 的推理扩展组件，支持灰度发布、过载检测、请求排队、熔断限流。

总的来看，RBG 负责 LLM 推理服务的部署、更新、升级等全生命周期管理，并根据业务指标动态调整实例规模，GIE 负责根据实时负载情况和模型处理能力智能路由流量。如果以 DeepSeek R1 作为统一测试目标，那么 RBG 可以将 Deepseek R1 模型加载耗时减少了 90%，GIE 可以将长尾场景下的首包延迟提升 73%，缓存利用率提升 90%，并通过前缀感知负载均衡优化，带来 40% 的响应速度提升。

容器计算服务 ACS 此次则上线了 AMD 通用算力。AMD 通用算力在性能方面实现以下突破：

• 在视频编解码、图形渲染、大数据处理等典型的计算密集型场景中，其端到端性能最高可提升 55%。

• 提供更精细化的资源规格。ACS 的 CPU 与内存最小粒度为 0.5vCPU/1GiB 步长，且 CPU 和内存配比可在 1:1~1:8 之间自由组合，贴合容器实际所需，避免配额浪费。

• 弹性能力支持分钟级万 Pod 弹出、AHPA 预测试伸缩。客户可以根据场景需求灵活选择，既可以单独指定 AMD 实例，也可以选择 AMD 和其他异构资源混部。

• 支持 BestEffort 模式。新增可抢占式 AMD 实例，价格约为常规实例的 20%；系统会在资源紧张时自动驱逐这些实例，很适合离线批处理、测试等对稳定性要求低、对价格极敏感的业务。

• 按日承诺折扣计划。允许用户按“每天预计消费金额”提前锁定折扣，用得越多省得越多，进一步压低长期运行的单位算力成本。

ACS 一号位智清透露，ACS 上线不到两年，就有不少客户把原本跑在传统算力形态上的工作负载迁了过来。原因其实只有一句：”换得值”。

从业务场景走出来，在开源社区回归初心

从 2011 年阿里云内部灰度上线 T4 容器，到 2023 年双十一支撑 17.5 万笔 / 秒的交易峰值，阿里巴巴把核心电商交易系统都押在阿里云容器上。十年下来，一套技术体系既能跑电商秒杀，也能跑万卡 AI 训练，由此奠定技术复利的起点。

从技术突破到云产品成熟，阿里云 ACS 架构师懿川认为，一切源于阿里云的技术深度、资源厚度、组织温度。

其中组织能力是最难以被定位和清晰描述的一项，你很难断言阿里云如今的组织能力到底来自哪一次内部迭代，但通过阿里在开源项目上的投入，或可发现一些端倪——阿里对开源的投入，几乎是国内规模最大，时间最长的。在阿里开源社区内，已捐赠项目达到 11 个，活跃贡献者超过 2500 人。

比如开源 Koordinator。阿里内部用 8 年时间把在线、离线任务混跑在同一套集群里，把利用率从 30% 提到 60% 以上。这套技术一直被视作阿里云弹性计算的一大“杀器”。但 2022 年 4 月，团队决定把它完全开源。

消息一出，外部最大的疑问是关于商业模式的：云计算企业与开源的相性，不如初创软件公司，尤其对于阿里而言，于国内市场不存在“以小博大”的必要。如今把核心技术开放，是否会给年度利润目标制造障碍？

智清告诉 InfoQ，团队在内部实则做了多轮辩证，结论是，坚持“技术普惠、客户第一”的哲学。希望借助开源技术降低行业的技术使用门槛，推动更广泛的技术采纳，同时也让更多开发者能够通过参与开源项目实现协作，共同促进技术领域的创新与进步。

客户反馈也表明，阿里云开源 Koordinator 是正确的决定。开源一年半，国内 30 余家头部互联网和金融科技公司直接采用 Koordinator 做二次开发。例如小红书就已经把数千节点的推荐业务平滑迁移到容器。

前文提到的 Fluid 是另一个较为典型的开源项目，由南京大学 PASALab、阿里巴巴、Alluxio 联合发起，于 2020 年 9 月正式对外开源，于 2021 年 5 月正式成为 CNCF Sandbox 项目。社区用户将其称之为：云原生环境下“数据物流系统”，可以解决现有云原生编排框架运行此类应用面临数据访问延时高、多数据源联合分析难、应用使用数据过程复杂等问题。

在这些过程中，阿里云也在无形之中完成了一次次对开源社区的“反哺”。

容器从最初的封装应用，到 Kubernetes 用声明式自动化部署编排，再到今天，阿里云容器服务进一步将调度优化、资源弹性、秒级自愈等能力下沉到基础设施，让系统自动做决策，开发者只描述需求即可，从而更加专注业务本身。

当这场变革逐渐深入，容器将成为智能算力的调度中枢，而阿里云在做的，就是定义这台中枢的“底层逻辑”——用开放标准把复杂留给自己，把简单和普惠的算力留给行业。