对话蚂蚁吴伟：训推一体池化调度，如何把GPU用到极限

作者 | 吴伟

审核｜李忠良

策划 | AICon 全球人工智能开发与应用大会

当 GPU 成为大模型时代最稀缺的生产资料，如何把每一张卡用到极致，已经不是一个成本优化问题，而是一个生存问题。

今年 AICon 大会上，我们邀请了蚂蚁集团高级技术专家、容器调度团队负责人吴伟，带来《训推一体潮汐弹性：蚂蚁集团在智算基础设施的池化调度实践》的主题演讲。在大会开始前，我们和他做了一次深度对话，聊了聊 GPU 资源调度这个难题的真实解法。以下是这次对话中，吴伟的几个核心判断：

• “CPU 和 GPU 的差异，不只是贵，是结构性的。” 大模型时代，分配一张卡就能跑任务的日子结束了。训练任务需要一次性分配上千张卡，还要考虑网络拓扑和节点内部差异，这是一道全新的排列组合题。
  

• “只在推理或训练内部做优化，注定有资源是空闲的。” 训练和推理各有潮汐特征，只在各自池子里做优先级抢占，永远有一部分时间资源在闲置。蚂蚁选择把两个池子打通，让任务在波峰波谷之间流动起来。

• “国产卡差的不是单卡算力，是全链路生态。” 英伟达的护城河是 CUDA 生态，从适配、算子优化到运行稳定性，全链路跑通才是真正的门槛。

• “软件优化有天花板，到了硬件极限，还是得靠扩容。” 提升利用率的路上横着两条线：硬件天花板和业务 SLO 天花板。在这两条线之内能解决的问题，终究是有上限的。

以上只是这次对话的要点摘录。关于训推一体池化调度架构的完整设计思路、推理 SLO 与资源成本之间的动态均衡算法、国产芯片精度对齐的具体踩坑经验，以及训推一体池化的落地效果数据，吴伟将在 AICon 大会现场做更深入的分享。感兴趣的读者，欢迎来线下当面交流。

1 GPU 稀缺不是问题，结构性稀缺才是

InfoQ：从 2018 年加入蚂蚁到现在，您经历了云原生从通算到智算的完整演进。有没有一个具体的时刻，让您感受到 GPU 和 CPU 是完全不同性质的资源——不只是贵，而是一种结构性的稀缺？这个认知转变是怎么发生的？

吴伟：我原先做的是传统的 CPU 和 K8S 相关的通算，后来转到了 GPU，做大模型出来后训练和推理的资源调度与支持。在大模型刚出来之前，也有一些 GPU 资源管理，但那时模型参数少，体感不强烈，会认为 CPU 和 GPU 差不多，都是分配一张卡和一个核，逻辑上没什么区别。但到了大模型时代，这个差异的体感就非常大了，主要体现在训练和推理两个方面。

训练侧，仅仅提交一个任务、分配一张 GPU 卡，已经无法满足训练任务的使用场景。一个训练任务占用的卡数非常多，所以在资源管理和调度层，需要知道应该一次性分配多少卡，这要求调度具备“gang scheduling”的能力。

同时，GPU 本身存在拓扑差异，包括网络交换机的连接拓扑，以及超节点或节点内部的差异。这些差异要求在分配资源或调度时，能以任务为粒度，把资源合理地分配出来，让硬件性能达到最优。这不像 CPU 时代，我们可以简单认为它是同构的，任何微服务申请 4C8G，分配好资源就行，硬件带来的异构差异相对较少。

推理侧逻辑类似。大模型出来后，推理层做了分布式推理，包括各种并行模式（TP、PP 等），甚至在 LLM 推理中还有Prefill 和 Decode 分离的推理。这带来的差异和训练类似，即如何将一个有着复杂结构的推理服务整体进行资源分配。

推理除了分配 GPU 资源，还有 CPU 资源，也会用到分布式的 KV Cache（显存、内存），如何让它们有一个更好的资源排布，这与通算是非常不同的。所以，从大模型来了之后，能感受到 CPU 和 GPU 不只是一个资源的差异，更是要去理解一个全新的业务形态，它的差异再加上硬件的差异，组合成了一个非常复杂的排列组合式的结构性差异。

InfoQ：GPU 利用率低是业界公开的秘密，但大多数企业选择接受现状。蚂蚁决定系统性解决这个问题，真实的触发点是什么——是某个利用率数字跌破了阈值，还是某次扩容申请被卡住，还是成本压力到了某个临界点？

吴伟：现在大家在建各种 AI 数据中心集群，规模越来越大，比如据说XAI 的 20 万卡集群，利用率相对较低。如何把这么大规模的 GPU 卡用好，是业界公认的难题。对蚂蚁而言，我们也经历了大模型 AI 时代的快速发展期，那时关注的是业务需求是什么、能否快速支撑，对 GPU 利用率或集群的资源使用效率关注不多。

但到了某个阶段，当集群和卡达到一定规模后，就会开始考虑有没有把它们用好。具体到触发事件，有两个。

外部原因是英伟达的卡从几年前开始对国内进行限购，导致能采购到的卡的数量和类型变少，资源一定会受限，不能再通过不断地买英伟达卡来满足需求，必须考虑如何把当前卡用好。

内部原因是在早期建设阶段，蚂蚁的训练和推理集群及业务方案是分开的，可能一个 K8S 集群给训练用，另一个给推理用。但到了某个时间点后发现，可能推理集群的资源有空闲，而训练任务一直在另一个集群排队，或者反过来，在做促销或对外活动时，训练任务其实可以出让一些空闲资源。这两类事情让我们意识到，必须从更大的层面去解决资源使用效率和提升利用率这件事。

InfoQ：在 GPU 受限的背景下，“提升利用率”和“申请更多资源”是两条路。蚂蚁内部怎么在这两条路之间分配投入——调度软件这条路，它的天花板在哪里，到什么程度还是得靠扩容解决？

吴伟：提升利用率的手段一定是有天花板的，这个天花板是由硬件或卡本身决定的。你一共就这么多硬件，它所能支撑的训练或推理任务，从硬件上就有一个绝对的天花板。除此之外，业务也会有SLO 的天花板。

特别是在推理集群，推理任务不是像训练一样可以一直把 GPU 的显存和算力榨干或打满。它要对外提供服务，尤其是面向 C 端用户，需要保证一定的 SLO，也就是常提到的TTFT、TPOT等核心指标。

为了保障这个 SLO，它本身会有推理的第二层天花板，即不可能把每台 GPU 服务器都用推理请求打满，打满的话 TTFT 或 TPOT 就会变得非常差。所以，从硬件和推理业务的 SLO 两方面，给定了一定的物理硬件资源后，就存在这两层天花板的限制。做 GPU 利用率提升，本质上就是怎么尽量去接近这两个天花板。

接近硬件天花板，主要靠推理引擎和训练引擎的优化。在引擎层面尽量把硬件用到极致，这包括很多算子优化、并行策略优化（比如降低 PP 的 Bubble）、算子合并或写更高效的算子，以及针对不同硬件和模型，通过模型适配让硬件用得更优。这是很多 LLM 大厂都在做的事，比如 DeepSeek 开源的很多论文就专注在这个层面，蚂蚁也做了很多事情。

接近业务 SLO 天花板，则需要通过系统层面的解决方案来处理。即无论推理还是训练，引擎已经把单机硬件使用情况做到一个比较好的状态后，在整个集群乃至多集群的分布式规模化场景里，如何再把资源用好。

这包括把训练和推理合池一起跑、推理任务的Auto Scaling按业务请求数动态扩缩容、快速抢占和启动优化等。很多技术结合在一起，才能把整个集群的资源利用效率再往上提升，尽量往另一个天花板靠近。

2 在 SLO 和成本之间走钢丝，我们是怎么“榨干”硬件的

InfoQ：弹性配额、优先级抢占、动态混部三层，理论上可以只做前两层、放弃混部的复杂度。蚂蚁为什么判断三层都必须做？认真评估过“只做两层”的方案吗，最终放弃的原因是什么？

吴伟：只做前两层，可以理解为在推理或训练本身内部，做资源更大范围的优化。比如通过弹性配额和优先级抢占，在推理内部将服务分高低优、高优抢占低优；训练侧同理。但这意味着，如果只在推理业务内部做抢占和资源分配，总会面临一部分时间资源是空闲的。

因为训练和推理有各自的业务特征和优先级。

推理更多面向 To C 业务，与人的使用习惯相关，有明显的流量特征，比如晚上和周末使用少，对算力的需求在晚上和周末更少。训练也有类似的潮汐现象，虽然不像推理那么有规律，但它与研发提交任务的节奏有关，比如周期性评测、消融实验或训练任务，会在不同时间段出现任务波峰和波谷。

因此，这两种差异可以通过训练和推理任务的混部，把它们合并到一起，在更大的范围内提升资源使用效率。这就是蚂蚁决定要做训练和推理合池、统一调度的原因。

动态混部具体实现主要分三步。第一步是软件栈打平，将底层的 AI 数据中心集群的软件栈全部打平，包括节点的 OS Kernel 版本、CUDA 驱动版本、上层管控的软件栈，这意味着在一个集群里，从能力上就同时支持训练和推理任务。

第二步是精细化的资源和任务管理，保障高优任务（如训练中的预训练、推理中的 To C 业务）在合并后不受影响，SLO 不因资源问题受损。

同时，将不同时段空闲的资源通过弹性配额的方式超卖出来，让训练或推理任务可以跑一些低优先级的任务。第三步是发生争抢时的回收机制，当资源发生争抢和抢占时，把低优的任务杀掉，让它自动进行 Failover，把资源还给高优任务。

InfoQ：优先级抢占依赖低优先级任务能够 Checkpoint，但不同训练任务的 Checkpoint 成本差异极大。实际落地时怎么处理“Checkpoint 代价高到不可接受”的任务——豁免、限制触发频率，还是要求业务改造？这个边界是怎么谈下来的？

吴伟：这确实是训练任务在抢占时遇到的问题。处理方式上，最核心的高保任务，比如大规模预训练，占用卡数非常多，每次被抢占后重新拉起，耗时和算力损耗非常高。这部分通过高保资源来保障，尽量减少抢占，它只有在物理机故障这种不可避免的情况下才会做 Failover 和 Checkpoint 的重新加载与训练。

对于低保任务，蚂蚁内部默认所有任务都要能进行 Checkpoint 自恢复。这依靠平台和上层业务的协作改造，平台会提供自动化的 Checkpoint 框架让业务接入，接入成本非常低。同时，在 Checkpoint 方面做了很多优化，包括异步 Checkpoint、控制 Checkpoint 的触发时机，以最小化其本身的损耗。

此外，在执行抢占时，还会考虑任务的 Checkpoint 执行时间。如果发现一个任务刚做完 Checkpoint，它在被抢占时会排在比较靠前的位置，这样抢占后的算力损耗最小。反之，如果一个任务已经运行很久且没做 Checkpoint，会尽量把它排在最后被抢占，以减少算力损耗。

InfoQ：动态混部的核心赌注是负载可预测，但预测失准的代价是在线推理服务抖动。你们怎么设计这个风险边界——预测置信度低于多少时系统保守退化？有没有一套“宁可浪费资源也不赌”的兜底逻辑，这个逻辑是怎么校准出来的？

吴伟：这是目前遇到的一个难题。做推理的自动弹性，本质上是要在业务 SLO 和资源成本这两个跷跷板上做均衡。如果弹性扩缩容配置过于激进，可能省了很多成本，但业务请求会受损；反之，要保证业务 SLO 完全不受影响，就必须预留更多资源 Buffer，导致资源浪费。这在工程上没有万能的解药，只能在中间做均衡和选择。

我们总结出的思路是，最底线的逻辑一定是要保障用户最核心的 SLO，在稳定性的基础上做弹性，而不是反过来。业务的稳定性是第一个基座，不能因为做弹性就把业务搞得经常不可用或 SLO 破线，这是做弹性之初就定下的核心原则。在这个原则下，我们做了大量分析，对业务流量做历史数据画像，据此判断大概每天在什么时间点需要预留多少资源才能满足 SLO。

在画像基础上，还会加一些预留的动态 Buffer，以保障即使有不在预期内的突发流量，也能做一些兜底动作，不会立即导致业务请求被打爆或出现破线问题。弹性应该是在有了这些最底线的保护之后，再根据实时的请求，去尽量节省更多的资源。

InfoQ：XPU 统一抽象必然有信息损失。你们怎么决定哪些芯片差异值得屏蔽、哪些必须透传——有没有因为抽象太彻底，导致某类任务跑在某款芯片上性能意外劣化的情况？

吴伟：关于不同芯片间的抽象，目前选择的还是一个比较保守的逻辑。蚂蚁会统一管理所有的 GPU 资源，用同一套资源上报、拓扑上报和使用方式来管理所有异构算力，包括英伟达和国产芯片。但是，默认情况下不会对用户屏蔽算力差异，用户在申请时仍需指定使用哪种型号的卡。

这样考虑的原因是不同芯片存在两方面的差异。

一是性能差异，不同厂商甚至同一厂商不同代际，硬件配置不同，性能不同，如果屏蔽了这件事，很多优化业务将无法进行。

二是精度差异，尤其是训练任务，精度损失影响很大；推理任务在某些关键场景下，也要求多次请求能尽量减少精度差异。如果完全屏蔽硬件、做成统一抽象，用户就没办法知道同一个请求是否跑在了不同卡上，也就无法保障精度差异是硬件、框架还是业务逻辑导致的。因此，默认保留了硬件差异，只是在算力管理上用同一套体系。

同时我们也在做一些探索。对于某些对精度或性能不那么敏感的业务，比如用大模型做数据处理，只要求更大吞吐量，可容忍一定性能和精度差异，我们希望提供一种统一的算力申请，在运行过程中才根据弹性动态决定分配哪一种 GPU 卡型号。

这需要上层框架做一些适配，在启动前感知到分配的卡型并做相应初始化和配置调整。完全把硬件屏蔽掉这件事，在学术界可能有很多研究，但在工业界确实还很难落地。

3 差的不是单卡算力，是全链路生态

InfoQ：很多企业现在面临一个真实的焦虑：NV 卡买不到或买不起，国产芯片是不是真的可以承接生产级的训练和推理负载？蚂蚁已经跑过了，能不能直接说——现阶段国产芯片在你们的生产环境里，是“够用”、“将就用”还是“某些场景真的不行”？

吴伟：国产芯片是这两年国内讨论较多的话题，大家多多少少都在开始用一些国产卡跑大模型的推理和训练。从蚂蚁的经验来看，推理场景中，国产卡能承载比较不错的任务，可以在生产中规模化地使用起来。训练场景也有一些任务在国产卡上跑，但整体来看，主要的缺点还是在生态上。

英伟达的核心护城河是CUDA 生态，全链路打通后，训练效率能提得很高。国产卡在整个生态上还是差了一些。如果只看单卡算力（FLOPS），差异可能没那么大，但如果看全链路跑通，包括是否能快速适配、运行中所有算子是否得到最好优化、以及运行稳定性，这些加起来，国产化和 NV 还是有不少差异的。

但我个人判断，现在各厂商都投入了很大成本去优化，这个差异应该会有一个缩小的趋势。

InfoQ：把国产芯片纳入统一调度，适配工作量往往超出预期。你们实际花的时间和最初预估相比差距有多大——哪个层面的工作量是被严重低估的，背后的原因是什么？

吴伟：芯片的适配不只是国产卡，即便是一个新的英伟达硬件型号出来，要到生产上真正稳定地跑起来，也需要非常多的适配工作，包括数据中心建设，各软件层面的流程适配，引擎层面的性能优化、精度对齐或开启硬件新特性，任务端到端运行起来的稳定性、自动化、Failover 能力，以及大规模扩容过程中交换机和芯片的故障率是否在预期范围内。

对于国产芯片，这些流程是一样的，但适配工作量上会更多，额外多了一个精度对齐的工作。

因为通常会以英伟达作为 baseline，同一个任务先在英伟达上跑一遍看效果，同步地需要在国产卡型上用相同方式和配置去跑，看整个链路是否能保持一致。实际场景中，由于硬件不同、软件栈（驱动等）差异、引擎本身适配差异、软件启动配置差异等，总会出现各种精度不对齐的情况，这非常消耗算力、人力和时间，要做非常细致的排查。

虽然有自动化工具，但很大一部分仍依靠人工经验和分析。精度对齐就是其他所有内容和配置都一样的情况下，看同一个任务能否推理出相同的结果，或者训练的 Loss 收敛程度是否一样。

InfoQ：对于现在正在评估国产芯片替代的企业，蚂蚁的经历能给出什么判断——不是“哪款芯片好”，而是：做这件事之前，企业需要先具备什么能力或条件，否则大概率会在哪个环节卡住？

吴伟：整个芯片的引入或选择，本质上就是一个评测，和大模型的评测类似。出了一款新模型，需要评测才知道是否引入生产环境。硬件也是类似，需要一套系统化和工程化的能力去评测这款芯片在引入后，系统是否能符合预期或有变好。这个评测能力是在大规模引入前必须提前构建好的。

这个评测包括端到端全链路：功能测试要验证引入芯片后，所有功能是否符合预期；性能验证和测试要确认性能上和原来是否保持一致或有提升，如训练性能变快、推理单位时间内产出的 Tokens 变多；精度测试和评测要能保证引入芯片后，不会带来训练任务 Loss 不收敛等问题；稳定性测试要验证芯片引入后，其故障率是否符合预期，每个故障是否都能在现有系统中自动化地发现和处理。

只有这套流程全部做完，才能有信心地说，引入了一个新芯片或厂商，并能够在生产中规模化地铺开。

InfoQ：训推一体这套体系的适用边界在哪？有没有一种企业——集群规模够大、资源浪费也明显，但仍然不适合走训推一体这条路——因为业务形态、组织结构或者技术债使这条路走不通？

吴伟：我个人判断，有两个明确的场景可能没有必要强行把训练和推理合并到一起。

第一个是业务快速发展的初期阶段，在这个阶段，需要快速迭代，保证每个业务场景能快速演进和发展。强行把训练和推理放在一起，会带来各种干扰，包括人员上的知识干扰、技术栈差异带来的干扰、任务本身配置的各种干扰。如果两边能隔离、分开，干扰是最小的，这更适合初期快速迭代两种不同业务的场景。

第二个是只有单一技术栈的公司，如果一家公司只做训练或只做推理，本身就没有这个需求，就不需要单独做这件事。另外，如果实在不差钱，有足够的卡，那也不需要过早或过多地做这类优化。

嘉宾介绍：

吴伟，蚂蚁集团高级技术专家，蚂蚁容器调度团队负责人，负责蚂蚁内部通智一体容器平台的资源调度和资源管理。18 年加入蚂蚁以来，经历了云原生资源调度从通算到智算的演进。在通算时代，参与了蚂蚁内部系统 k8s 云原生化的升级改造、CPU 在离线混部、CPU 利用率提升等多个项目；在智算时代，负责蚂蚁 GPU 异构资源编排，正在探索通过训推池化、推理服务弹性、任务优先级抢占、自动化 FO 等技术手段，来提升 XPU 资源使用效率，以更好地服务蚂蚁百灵、阿福、灵光等 AI 业务。

会议推荐

AICon 上海站 4 大核心看点：Keynote 前瞻洞见、Agent 工程化专题拆解、前沿技术 + 产业落地全覆盖，Google Cloud 专家实操带练。更多详情可扫码或联系票务经理 13269078023 进行咨询。