1、CPU和GPU的差异，不只是贵，是结构性的。大模型时代，单卡分配跑任务的时代终结，集群调度必须兼顾算力、网络拓扑、节点异构多重条件；
2、只拆分训练、推理独立池子优化利用率，永远存在资源闲置。打通训推双池，依托潮汐错峰调度，才是集群提效最优解；
3、国产算力短板不在单卡算力，核心缺失英伟达CUDA全链路适配、算子优化、稳定运维生态；
4、软件调度优化存在双层天花板：硬件算力天花板、业务SLO服务指标天花板，抵达阈值后，只能依靠硬件扩容解决业务增量。

---
一、GPU稀缺不是问题，结构性稀缺才是
InfoQ：从2018年加入蚂蚁到现在，您经历了云原生从通算到智算的完整演进。有没有一个具体的时刻，让您感受到GPU和CPU是完全不同性质的资源——不只是贵，而是一种结构性的稀缺？这个认知转变是怎么发生的？
吴伟：我原先深耕传统CPU、K8S通用算力研发，后续转向GPU赛道，负责大模型训练、推理资源调度基建。大模型普及之前，行业也有小规模GPU算力管理，但模型参数体量小，业务体感偏弱，我一度认为CPU、GPU调度逻辑同质化，无非是分配核心、分配算力卡，底层逻辑没有区别。
大模型规模化落地后，二者结构性差异彻底凸显，集中体现在训练、推理两大场景：
训练侧：单任务动辄需要上千张GPU联动，不再支持单卡独立交付。调度平台必须具备gang scheduling（成组调度）能力，一次性匹配组网算力；同时GPU存在极强异构性，交换机组网拓扑、节点内部硬件参数各不相同，调度必须贴合硬件排布最优分配算力。而CPU属于标准同构资源，微服务申请4C8G即可随意分配，几乎无需考量硬件差异。
推理侧：分布式推理普及后，TP/PP并行、Prefill与Decode分离式推理成为标配，推理服务本身具备复杂组网逻辑。同时推理联动GPU、CPU、分布式KV显存内存协同调度，资源排布复杂度远超传统通算业务。
简言之，GPU稀缺不止单价高昂，而是业务组网+硬件异构叠加而来的复合型、结构性稀缺。
InfoQ：GPU利用率低是业界公开的秘密，但大多数企业选择接受现状。蚂蚁决定系统性解决这个问题，真实的触发点是什么——是某个利用率数字跌破了阈值，还是某次扩容申请被卡住，还是成本压力到了某个临界点？
吴伟：当下头部企业AI算力集群规模暴涨，例如行业周知的XAI二十万卡集群，普遍存在利用率偏低难题，超大算力集群精细化运营，已经成为行业必答题。
蚂蚁早期AI基建阶段，优先级是兜底业务交付，优先保障模型能跑、业务上线，完全不计算力损耗。倒逼我们下场重构调度体系，分为内外两大核心原因：
外部约束：英伟达高端GPU长期对华限购，采购品类、采购体量双重受限，算力增量渠道被锁死，企业只能向内挖潜，盘活存量算力，而非无限采购新卡。
内部痛点：早期蚂蚁训推集群物理隔离，专属集群各司其职。常态化出现推理集群空载闲置、训练任务排队拥堵；大促、对外营销节点反向出现训练算力闲置、在线推理算力紧缺。训推潮汐错峰无法互通，算力浪费肉眼可见，倒逼我们搭建一体化调度体系。
InfoQ：在GPU受限的背景下，“提升利用率”和“申请更多资源”是两条路。蚂蚁内部怎么在这两条路之间分配投入——调度软件这条路，它的天花板在哪里，到什么程度还是得靠扩容解决？
吴伟：软件调度提效有明确双层天花板，抵达边界后，只能依靠硬件扩容承接增量业务。
第一层：硬件物理天花板。存量GPU硬件算力、显存、组网带宽固定，硬件上限决定集群可承载业务总量，软件无法突破硬件物理极值。
第二层：业务SLO服务天花板。推理业务面向C端用户，硬性约束TTFT首token时延、TPOT吞吐时延核心指标，不能为了打满GPU算力，牺牲用户交互体验。集群算力必须预留冗余Buffer，这就注定GPU无法百分百满载运行。
行业提效分为两层打法：
1、贴近硬件天花板：优化训推引擎，打磨算子合并、软硬件适配、流水线气泡优化、定制自研算子，DeepSeek、蚂蚁自研引擎，都是在做单机硬件极致榨取；
2、贴近SLO天花板：依托集群调度能力落地，包含训推合池混部、业务流量自动扩缩容、高低优任务抢占，在保障线上服务指标前提下，吃掉集群碎片化闲置算力。
二、在SLO和成本之间走钢丝，我们是怎么“榨干”硬件的
InfoQ：弹性配额、优先级抢占、动态混部三层，理论上可以只做前两层、放弃混部的复杂度。蚂蚁为什么判断三层都必须做？认真评估过“只做两层”的方案吗，最终放弃的原因是什么？
吴伟：我们完整评估过仅做弹性配额+优先级抢占的轻量化方案，最终放弃，核心原因：仅业务内抢占，无法跨池消化潮汐闲置算力。
推理、训练潮汐节律完全割裂：推理绑定用户作息，夜间、周末C端流量断崖下跌，算力空载；训练绑定研发办公节奏，工作日实验、评测任务扎堆爆发，节假日训练任务锐减。二者波峰波谷完全错配，隔离集群等于永久浪费错峰算力。
因此蚂蚁坚定落地「弹性配额+优先级抢占+训推动态混部」三层体系，落地分为三大步骤：
第一步：底层软件栈全域打平。统一集群内核、CUDA驱动、管控运维组件，单集群原生兼容训练、推理两类任务，破除硬件准入壁垒；
第二步：精细化权限与任务管控。划定高低优任务等级，预训练、C端在线推理划定高保等级；利用弹性配额超卖闲置算力，承接低优离线实验、微调任务；
第三步：可控抢占Failover机制。算力资源冲突时，自动化下线低优任务、留存Checkpoint断点，无损交还算力，全程保障高优业务SLO不破线。
InfoQ：优先级抢占依赖低优先级任务能够Checkpoint，但不同训练任务的Checkpoint成本差异极大。实际落地时怎么处理“Checkpoint代价高到不可接受”的任务——豁免、限制触发频率，还是要求业务改造？这个边界是怎么谈下来的？
吴伟：我们做了分级兜底策略，划分高保、低保两类训练任务，差异化处理抢占逻辑：
1、超大卡量核心预训练任务：划入最高保等级，默认豁免主动抢占。仅物理机宕机、机房故障等被动异常，才触发断点保存、任务重启，从源头规避高额重启算力损耗；
2、微调、消融实验等低保任务：统一强制接入平台自动化Checkpoint框架，平台提供异步断点、智能定时快照能力，大幅降低业务改造成本与断点损耗；
同时平台增设抢占排序策略：优先抢占刚完成Checkpoint快照的任务，算力恢复成本最低；延后抢占长期未存断点的任务，最大限度减少无效算力损耗。
InfoQ：动态混部的核心赌注是负载可预测，但预测失准的代价是在线推理服务抖动。你们怎么设计这个风险边界——预测置信度低于多少时系统保守退化？有没有一套“宁可浪费资源也不赌”的兜底逻辑，这个逻辑是怎么校准出来的？
吴伟：混部弹性的第一铁律：稳定性优先级永久高于算力利用率，绝不以线上服务抖动换算力省钱。
整套兜底逻辑经过上万次流量复盘校准，分为三重防护：
第一，历史流量画像建模。依托全年分时用户流量、大促峰值、节假日数据建模，算出固定时段基础算力保底值，保底算力绝不参与混部超卖；
第二，动态冗余Buffer加持。在保底算力之上，叠加动态浮动冗余算力，承接突发爆量、黑天鹅流量，抵御预测偏差；
第三，置信度降级机制。实时流量预测置信度低于阈值时，系统自动收缩混部算力、关停低优任务抢占，回归隔离运行模式，宁可闲置算力，绝不击穿线上SLO底线。
InfoQ：XPU统一抽象必然有信息损失。你们怎么决定哪些芯片差异值得屏蔽、哪些必须透传——有没有因为抽象太彻底，导致某类任务跑在某款芯片上性能意外劣化的情况？
吴伟：蚂蚁现阶段采用保守异构算力管控逻辑：一套调度平台统一管理英伟达、国产全品类算力，但硬件核心差异完全不透传屏蔽。用户申请算力时，必须自主选定芯片型号，平台不做无感混卡调度。
不透传屏蔽两大核心原因：
一是硬件性能代差不可逆，混卡调度会打乱并行组网策略，直接拉低集群整体算力；
二是训练推理精度强绑定硬件，屏蔽卡型后，无法溯源Loss收敛异常、推理输出偏差问题，运维排查成本极高。
目前仅在非敏感离线数据处理、海量低精度蒸馏场景试点弱化芯片差异，由平台动态分配卡型，业务框架自适应适配硬件，生产核心业务依旧保留硬件选型权限。工业界全域无感XPU抽象调度，现阶段依旧不具备落地条件。
三、差的不是单卡算力，是全链路生态
InfoQ：很多企业现在面临一个真实的焦虑：NV卡买不到或买不起，国产芯片是不是真的可以承接生产级的训练和推理负载？蚂蚁已经跑过了，能不能直接说——现阶段国产芯片在你们的生产环境里，是“够用”、“将就用”还是“某些场景真的不行”？
吴伟：分开场景客观判定：
推理场景：国产算力已经规模化可用，足以承接企业常态化线上推理、业务问答、内容生成生产负载，完全达标生产可用标准；
训练场景：中小体量微调、专项实验可以稳定落地，但千亿级、万亿级基座大模型预训练，依旧存在落地短板。
行业普遍误区：对标单卡FLOPS浮点算力评判芯片实力。实际上英伟达真正的护城河是CUDA闭环生态：算子极致优化、驱动适配完备、集群运维成熟、故障自愈体系完善，全链路效率碾压国产算力。国产卡单卡纸面算力差距不大，但全链路适配、稳定性、运维成本差距明显。
长期来看，各大国产厂商持续加码生态研发，软硬件差距会持续收窄。
InfoQ：把国产芯片纳入统一调度，适配工作量往往超出预期。你们实际花的时间和最初预估相比差距有多大——哪个层面的工作量是被严重低估的，背后的原因是什么？
吴伟：即便是英伟达新一代同系显卡上线，规模化投产适配工作量都远超预估，国产芯片适配难度更是成倍增加，被全网低估的工作量只有一件：跨芯片精度对齐。
行业统一以英伟达算力结果为基准基线，国产卡需要逐条对齐推理输出文本、训练Loss收敛曲线。软硬件栈不同、编译逻辑不同、算子底层实现不同，极易出现微小精度偏移，偏移会逐级放大，最终导致模型输出失真、训练不收敛。
精度对齐无法全自动化完成，需要算力复测、人工拆解算子链路、微调编译参数，人力、算力、时间消耗极大，这也是国产算力接入调度成本最高的一环。除此之外机房组网、故障运维、Failover改造，都属于可预估适配成本。
InfoQ：对于现在正在评估国产芯片替代的企业，蚂蚁的经历能给出什么判断——不是“哪款芯片好”，而是：做这件事之前，企业需要先具备什么能力或条件，否则大概率会在哪个环节卡住？
吴伟：入局国产算力替代前，企业必须自建全链路算力评测体系，没有这套能力，入局一定会卡在业务精度、线上稳定性环节。评测体系包含四大维度：
1、功能评测：适配企业自有模型，校验组网、启停、断点复原全流程功能可用；
2、性能评测：对标英伟达基线，核验推理吞吐、训练收敛速度达标；
3、精度评测：闭环校验训练Loss、推理输出一致性，规避隐性精度偏差；
4、稳定性评测：大规模集群压测，核定芯片故障率、故障自动化处置能力。
跳过系统化评测直接采购上架，最终都会陷入“能跑，但不稳、不准、不好运维”的困境。
InfoQ：训推一体这套体系的适用边界在哪？有没有一种企业——集群规模够大、资源浪费也明显，但仍然不适合走训推一体这条路——因为业务形态、组织结构或者技术债使这条路走不通？
吴伟：三类企业无需强行落地训推一体混部调度，强行合池反而弊大于利：
第一类：业务初创迭代期企业。模型、业务架构高频改版，训推技术栈差异极大，物理隔离算力，可以规避版本冲突、组网干扰，优先保障业务快跑迭代；
第二类：单业务赛道企业。只做大模型训练、只做线上推理，无双向算力错峰需求，合池调度无收益；
第三类：算力预算充足企业。算力储备充足、无需控本降耗，隔离运维架构简单、故障风险更低，无需承担混部调度研发、运维复杂度。