一场静悄悄的范式转移
2026 年 7 月,第 43 届 ICML 在首尔落幕。23,918 篇投稿、6,352 篇录用(录用率 26.6%)的规模背后,"AI 基础设施与分布式系统"成为最受瞩目的方向之一。如果说过去两年行业的关键词是"抢卡""囤卡""万卡集群",那么这届 ICML 传递出的信号截然不同:大模型基建正在告别"算力暴力"时代,进入"精密系统工程"时代。
所谓"算力暴力",指的是过去那套粗放打法------盲目采购单一规格硬件、静态分配资源、粗粒度调度、用同构 GPU 的简单堆叠去硬扛所有负载。这套打法的代价越来越触目惊心:一边是频频撞上的"显存墙",一边是高企的资本支出与低得可怜的实际利用率。ICML 2026 上那批代表性工作(HexGen-3 的完全解耦推理、CONTINUUM 的弹性张量抽象、DuetServe 的 SM 级切分、ConServe 的亚迭代抢占、QiMeng-PerceptOS 的内核级虚拟化......)像一组精密的外科手术,自上而下重构了从集群、芯片到操作系统内核的每一层。作者从中提炼出四条主线:分离式架构的极致化、调度颗粒度向亚迭代/子任务级下沉、从同构堆叠走向异构协作、以及穿透操作系统的内核级虚拟化。
虽然由于Token火爆,ICML讨论主题更多在推理 Serving 侧。但它真正的内核------"从堆卡转向精算,用精细化的调度、存储与弹性来换取利用率和成本" 是训练和推理通吃的底层哲学。而这套哲学,恰恰是理解 PAI DLC 这一轮能力演进的最佳坐标系。DLC 作为面向大规模分布式训练的容器化引擎,它近期发布的异构算力混合调度、Spot、联合训练、本地缓存、JuiceFS、Custom 这组能力,不是零散的功能点,而是同一套"精密系统工程"思想在训练场景的系统性落地。

异构算力混合调度:训推分离与异步计算,直击范式转移的核心
痛点
这是当下最尖锐、也最能体现范式转移的战场。以 RLHF/RLAIF 为代表的后训练(Post-training)流程,把多种性质迥异的负载耦合在了同一个同步循环里:样本生成(rollout,推理密集)、奖励模型打分(reward)、优势函数计算(advantage)、以及策略模型更新(训练,通信密集、依赖高速网络)。它们对硬件、网络、显存的诉求完全不同, 如果被迫共用一套同构资源、串行等待彼此。结果就是导致大量的算力空转与资源错配------训练在等生成、生成在等打分,昂贵的 GPU 在流水线的间隙里大面积闲置。预训练与 AI 数据预处理同样受困于此:CPU 密集的数据清洗/编码与 GPU 密集的计算,配比一旦失衡,就是一方等另一方。

应对
PAI-DLC 上线的异构算力混合调度 ,正面回应了这一困局。它支持不同网络架构(高网与非高网)、不同计算节点(CPU 与 GPU)的协同运行,让训练作业不再被绑死在单一同构资源上; 支持训推分离 ,把训练与推理生成解耦到各自最适配的资源上独立伸缩, 支持异构资源灵活配比 ,按负载特征动态匹配算力;提供了异步奖励/优势函数计算能力 ,把 reward 与 advantage 的计算从主训练循环里剥离出来、异步流水化执行,不再阻塞策略更新。这套能力覆盖 LLM 预训练、后训练与 AI 数据预处理等核心场景,目标直指"最优训练效率"。 这一项几乎是 ICML 2026 三条主线的集中落地。其一,异构协作网络------大会判定 "同构 GPU 静态堆叠走向终结,基建演变为算子特征与物理载体精准匹配的异构协作网络",而高网/非高网、CPU/GPU 的协同混合调度,正是这一判断在训练侧最直接的工程实现。其二,分离式架构的极致化 ------训推分离,与文章反复强调的"Prefill/Decode 分离、乃至算子级物理打散"同出一辙,都是"让不同性质的负载各得其所"。其三,调度颗粒度向子任务级下沉------异步奖励/优势函数计算,本质上是把 RLHF 这条流水线拆解成可独立调度、独立伸缩的子任务,与大会 HybridFlow"子任务 DAG 自适应路由"的思想遥相呼应。
价值
后训练(尤其是强化学习)是当下大模型能力竞争的最前沿与最烧钱的环节,谁能把 RLHF 流水线的异构解耦与异步流水做到极致,谁就握住了训练效率与成本的胜负手。更深一层,训推分离 + 异步计算标志着 DLC 正从一个"训练引擎",演进为覆盖预训练、后训练、数据预处理的训推一体、面向 LLM 全生命周期的算力底座------这已经不只是跟上趋势,而是在趋势的最前沿卡位。
Spot 抢占式训练:把"独占保障"变成"弹性抢占"
痛点
训练任务对算力的胃口是无止境的,但预算不是。长期以来,训练作业默认跑在预付费的"独占"资源上------为了那点确定性,企业不得不为大量并非始终满载的算力付全价。这本质上是一种"以成本换确定性"的保守策略,在卡价高企、供应链紧张的当下代价尤其沉重。

应对
DLC 推出的 Spot 抢占式训练,允许作业运行在价格显著更低的抢占式实例上。它的关键不在于"便宜",而在于把抢占的代价工程化地压到最低 :配合DLC easyckpt、弹性容错、grace stop 和 自动重调度,当实例被回收时,作业能从最近的 checkpoint 自动恢复、在新拿到的资源上继续,整个过程无需人工介入。这与 ICML 2026 上 ConServe 的"亚迭代级抢占"、Token 级增量 KV 备份是同一条思想脉络------承认资源是可以被抢占、被打断的,关键是让"恢复"足够快、足够廉价。学术界在推理侧论证"抢占-快速恢复"的可行性, DLC 则在训练侧把它做成了生产级能力。GPU 由此从"必须独占才能保障"的紧俏资产,转变为"可被抢占、可被共享"的流动资源。
价值
对客户而言,这意味着同样的预算能跑更多实验、更大规模的预训练;对平台而言,这是把闲置的、碎片化的低价算力盘活、提升整体售卖率与利用率的关键抓手。在算力成本成为 AI 落地最大障碍的今天,Spot 是最直接的"降本"杠杆。
联合训练(PAI-Forge):在安全可信的"熔炉"中锻造行业大模型
痛点
大模型的能力跃迁,越来越依赖两类稀缺资产的结合:一端是头部厂商手里顶尖的闭源基模与高质量数据(甲方),另一端是行业客户手里独有的业务数据与真实场景(乙方)。但这两端天然互不信任------基模方不愿交出模型权重与训练数据,业务方也不敢把敏感的私域数据外送。数据与模型"不敢出域",让本可以强强联合的行业大模型训练,卡在了商业互信这道墙前。

应对
PAI-Forge(Federated Orchestration for Reliable LLM Generation Ecosystem)正是为打破这道墙而生,它的核心是 "双盲"安全,重塑商业互信 。平台为甲乙双方做安全授信,在代码、容器、网络、存储多个层面进行隔离与加密,确保甲方的闭源数据/模型可以参与乙方的模型训练,而训练的中间过程互不可见、特定结果仅在甲方授权下按需提供,从而在保护双方核心资产的前提下完成联合训练。在这层安全底座之上,PAI-Forge 复用了 PAI 成熟的大模型训练工具链------支持模型开发/训练/微调,支持高代码自定义训练代码,提供完整的日志指标、故障告警与自愈能力,兼容 PyTorch、Megatron、DeepSpeed、Ray 等 10+ 主流训练框架,并针对 Rlinf、Slime 等 RL 框架做了专项优化。ICML 2026 的四条主线聚焦于"效率",而联合训练在效率之外,把"精密系统工程"的思想延伸到了一个新维度------安全边界的精密划分 。大会关于"内核级虚拟化、重置软硬边界"的判断,其内核是用精细的隔离与虚拟化,让原本相互冲突的负载安全共存;联合训练则把同一套"精密隔离"哲学用在了更高的层次:让原本因商业壁垒无法共处的甲乙双方数据与模型,在代码/容器/网络/存储多层隔离的"安全熔炉"里安全共训。这是"精密"从性能维度向信任维度的一次自然外延。
价值
联合训练开辟的,是一个此前被商业壁垒锁死的巨大增量市场------它让"顶尖闭源基模 × 行业私域数据"的组合第一次变得安全可行。落地成效已经印证了这条路的价值:通义(甲方)分别与荣耀、Tesla(乙方)基于 PAI 平台,用甲方加密模型/数据 + 乙方业务数据完成 online/offline 等多场景 RL 训练,共同打造下一代超级智能,同时为阿里云带来数亿元营收。这已经不只是一项训练调度能力,而是 PAI 在"大模型训练消费生态"上卡位的战略支点。
本地缓存:打穿数据供给的"时间黑洞"
痛点
一个常被忽视的事实是,昂贵的 GPU 经常在等数据 。训练数据集通常存放在 OSS 等远程对象存储,每个 epoch 反复远程拉取,网络与 IO 成为瓶颈,GPU 算力在数据供给不及时的间隙里白白闲置。ICML 2026 的综述里有一个触目惊心的数字------在长上下文与 RAG 场景中,受内存带宽限制的、不规则的检索与数据搬运,竟占据端到端延迟的22%~97%,是导致算力闲置的"时间黑洞"。训练侧虽形态不同,但"数据供给跟不上算力"的本质痛点如出一辙。

应对
DLC 的本地缓存,把热点数据集缓存到计算节点的本地高速盘(NVMe/内存)。首次读取后,后续 epoch 直接命中本地缓存,免去重复的远程拉取,数据加载延迟大幅下降,GPU 的数据供给率随之显著提升。对应趋势: 这直接呼应了大会对"存储墙 / 内存带宽墙"的集体关注。当计算本身已经被优化到极致,瓶颈就会转移到数据的搬运路径上。优化重心从"算得多快"转向"喂得多稳",本地缓存正是这一转向在训练侧最务实的落点。
价值
它提升的不是峰值算力,而是有效算力利用率------同样的卡,喂得更饱,单位时间产出更多。在卡是最稀缺资源的当下,任何把 GPU 空转时间还给计算的能力,都是实打实的降本增效。
JuiceFS:兼容AI工具链,乐高拼装组合,多层级加速
痛点
大模型训练的数据形态越来越复杂:海量小文件、跨节点共享读写、对象存储与 POSIX 语义的鸿沟......底层存储的物理碎片和异构性,直接暴露给上层训练框架时,会带来极高的适配成本和性能损耗。

应对
JuiceFS 是云原生的分布式文件系统,在云上往往基于对象存储(如 阿里云的 OSS) 为基础,叠加内存/本地盘的多级缓存,向训练作业呈现一个统一的、POSIX 兼容的、高吞吐的文件视图 。开发者面对的是一个"普通文件系统",而底层的对象存储、缓存分层、跨节点一致性都被透明地屏蔽和加速了对应趋势 。这与 ICML 2026 上 CONTINUUM 的"弹性张量抽象"、以及"软件定义流水线屏蔽物理碎片、向上呈现统一虚拟化资源"是同一套设计哲学:用一层软件抽象,把破碎、异构、复杂的底层物理资源,收敛成一个干净、统一、高性能的上层视图。 学术界在显存层面做这件事(把碎片化物理显存抽象为逻辑连续张量),JuiceFS 则在存储层面做同样的事。
价值
它降低了大规模训练在数据工程上的门槛与损耗,让存储不再是训练加速的短板;更深一层,它体现了"软件定义基础设施"的方向------用软件的灵活性去驾驭硬件的复杂性,这正是"精密系统工程"区别于"算力暴力"的分水岭。
Custom:承载异构与多样范式的灵活底座
痛点
大模型的技术栈演进极快:今天是 Megatron,明天是新的并行策略;今天是同构 GPU,明天可能要在异构卡型上混合训练。任何把用户锁死在固定框架、固定拓扑上的平台,在这种快速演进中被甩下。

应对
DLC 的 Custom(自定义作业)提供了完全的灵活性:自定义镜像、自定义分布式框架与并行策略、自定义启动命令与拓扑。它不预设"你只能怎么训",而是提供一个可编排的底座 ,让用户把自己的训练范式、乃至异构硬件组合,自由地承载上来。 这呼应了大会最深刻的一条判断:同构 GPU 静态堆叠模式走向终结,基建正演变为"算子特征与物理载体精准匹配"的异构协作网络。异构协作要落地,前提就是平台层必须足够灵活、足够"软件定义"------Custom 正是这种灵活性的载体,它与异构算力混合调度形成一软一硬的配合:混合调度在底层把异构资源拉通,Custom 在上层把多样范式承载起来,共同让"把合适的负载放到合适的硬件上"从理念变得可操作。
价值
灵活性就是面向未来的兼容性。在技术范式高速迭代的窗口期,一个开放、可编排的底座,意味着平台能持续吸纳最新的训练方法与硬件形态,而不必推倒重来。这是平台长期生命力的根基。
RNQ (Ray Quota):池化调度 + 内核级优化,榨干高密短时任务的每一秒

痛点
有一类负载,和大模型训练"长时、独占、同构"的画像正好相反------它们数量巨大(单日百万级)、并发极高(数万任务同时在跑)、单个却极短(很多只运行几十秒甚至几秒),还伴随高 IO 的本地盘读写。以数据产线为代表的这类高密短时任务,把三重矛盾摆上了台面:其一,启动即瓶颈------原生 K8S Pod 要走调度、网络初始化、拉起容器一整套流程,对秒级任务而言,光启动耗时就可能超过任务本身的运行时间,高频启停还给系统组件带来巨大的 QPS 压力;其二,密度上不去------单节点网卡密度有限(灵骏约 40),而每个 Pod 至少占用一块网卡,任务密度被死死卡住,只能给每个任务分配冗余的卡,PPU 利用率白白浪费;其三,高水位下的稳定性---大量任务挤在一起跑,IO/CPU/内存峰值互相踩踏,一个任务的高 IO 写回就足以拖垮同节点上其他容器的启动。
应对
PAI-RNQ (Ray Quota)给出的是一套"池化 + 深度重构"的组合拳:它把 RayCluster 做成按需分配、持续运行的池化 Quota,让用户近乎无感地对接与迁移;在此之上自上而下地重构 Ray、容器与存储底座。针对启动效率,它把任务提交批量异步化(1000 个任务的列表查询从约 5s 降到 200ms 以内)、引入 FIFO 公平排队化解大规格任务饥饿、把容器只读层与写入层分离到不同设备隔离 IO,更基于 Linux 内核 Overlayfs Volatile 特性去掉高 IO 场景下非必要的 PageCache 刷盘,让容器启停不再被 IO 拖垮;针对资源利用率,它让同一 Worker 内的任务共享网络环境,一举突破网卡密度上限,单节点最高可并发千级任务,再用 cgroup 弹性管理让任务间平滑复用资源、削平峰值;针对易用与稳定,它以 PAI Quota 统一管理、复用 DLC 任务接口与全链路可观测,并基于 DinD 能力为每个 Ray 任务支持免特权、高性能的自定义镜像。
RNQ 几乎是"精密系统工程"两条主线在数据处理场景的合流。其一,调度颗粒度向子任务级下沉------它把原本以 Pod 为最小单元的粗粒度调度,细化到单 Worker 内千级任务的共享与弹性复用,正是大会所强调的"把资源切得更细、调度得更准"的极致体现;其二,穿透操作系统的内核级虚拟化------容器读写层分离、Overlayfs Volatile 免刷盘、tmpfs 元信息、ramfs 日志分离,这些优化直接下探到 Linux 内核与文件系统层,与大会 QiMeng-PerceptOS"内核级虚拟化、重置软硬边界"的判断如出一辙。它还顺势把 Ray 这一 RL 与数据处理领域最热门的框架纳入 PAI 体系,与异构混合调度、Custom 遥相呼应。
价值
RNQ 直面的是一个被长期低估的战场:大模型的竞争不只在训练那一刻,数据产线的吞吐与成本同样是胜负手。它交出的是实打实的数字------单日处理百万级任务、单 RayCluster 并发五千(压测上万)、任务端到端耗时降低 20%、同等资源下并发能力提升 4 倍、PPU 利用率提升约一倍。当"精密"从长时训练延伸到高密短时任务,DLC 证明了同一套系统工程方法论,既能服务动辄数周的大规模预训练,也能榨干每一个几秒钟小任务背后的算力------这让它的算力底座覆盖了更完整的 AI 生产链路。
组合价值:从单点能力到"精密系统工程"闭环

单独看,这七项能力各解一个痛点;组合起来看,它们构成了一个完整的降本增效闭环------异构混合调度打通训推与 CPU/GPU 的协同、Spot 压成本、联合训练以"双盲"安全打开多方共训的增量生态、本地缓存与 JuiceFS 打穿数据供给瓶颈、Custom 提供异构与演进的灵活底座、RNQ 以池化调度与内核级优化榨干高密短时任务的吞吐。成本、安全、数据、异构、灵活性、吞吐,训练与数据处理全生命周期里最关键的维度,被这组能力系统性地覆盖了。其中,异构算力混合调度是这套体系的中枢------它把训推分离、异步计算、CPU/GPU 与高网/非高网协同这些"精密调度"能力,直接嵌入了 LLM 预训练与后训练的核心链路。
这恰恰是 ICML 2026 想说的:未来的竞争力,不在于你堆了多少卡,而在于你能否把每一张卡、每一比特数据、每一次调度都用到极致。DLC 这一轮能力演进的意义正在于此------它不是在追逐单点性能的军备竞赛,而是在把"精密系统工程"的方法论,做成客户开箱即用的工程能力。学术界在论文里论证"应该这么做",DLC 已经在生产环境里"这么做了",这本身就是很强的前瞻性佐证。
结语与展望
从"算力暴力"到"精密系统工程",ICML 2026 描绘的是 AI 基建演进的星辰大海;而 PAI DLC 的异构混合调度、Spot、联合训练、本地缓存、JuiceFS、Custom 与 RNQ,则是这条航路上已经落地、可被客户直接使用的坚实航标。尤其是异构算力混合调度所支撑的训推分离与异步奖励/优势计算、以及 RNQ 把精密系统工程延伸到高密短时任务,已经把"训推一体、子任务级解耦"这类原本还停留在论文里的前沿命题,变成了服务 LLM 全链路的生产能力------这意味着 DLC 不只是在跟随趋势,而是在趋势的最前沿构建护城河。
展望下一程,当"精密"从集群、节点、训推流水线进一步深入到单卡内部------更细粒度的 GPU 共享、拓扑感知的智能调度、乃至内核级的资源虚拟化,DLC 仍有广阔的演进空间。方向已经清晰:把每一份异构算力,都调度到它最该去的地方。
相关链接:
-
Paper Digest: ICML 2026 Papers & Highlights www.paperdigest.org/2026/05/icm...
-
HexGen-3: A Fully Disaggregated LLM Serving Framework with Fine-Grained Heterogeneous Resource Autoscaling
-
CONTINUUM: Restoring the Contiguous Tensor Abstraction Efficiently for Dynamic AI Workloads via Hardware Virtualization
-
Understand and Accelerate Memory Processing Pipeline for Large Language Model Inference
-
ConServe: Fine-Grained GPU Harvesting for LLM Online and Offline Co-Serving
-
HybridFlow: Resource-Adaptive Subtask Routing for Efficient Edge-Cloud LLM Inference arxiv.org/abs/2512.22...
-
QiMeng-PerceptOS: Semantic-Aware Kernel Optimization for OS-Intensive Workloads via Hardware-Software Alignment