作者 | 棱镜
近年来，全球 AI 算力规模按接近指数级的幅度增长，GPU 已然是整个数据中心的绝对主角，而 CPU 一般被认为只是承担数据预处理、任务调度和通信协同的次要部分。然而，在真实的大模型训练与推理集群里面，我们察觉到一种长期存在的资源矛盾：在 GPU 满负荷运转的场景下，CPU 的利用率往往处于偏低水平。根据《DLBench：深度学习框架的综合实验评估》（DLBench: a comprehensive experimental evaluation of deep learning frameworks）数据显示，在 CNN 架构的大部分时间里，GPU 利用率接近 100%，而每个 CPU 核心的利用率在 9.3% 到 23% 之间。此外，当 GPU 利用率高时，CPU 利用率往往较低，反之亦然。
从企业的角度看，浪费掉的不只是资源，同时也是成本。以一台典型的 8 卡 H100 服务器作为例子，该服务器按照市场平均月租金评估大约是 8.5 万元，其中 CPU 成本占总成本的比例约为 30%，就是 2.55 万元。如果 CPU 平均利用占比为 15%，也就意味着每月约有 2.17 万元的 CPU 资源被浪费掉了，若把服务器数量扩展到 100 台，一年当中浪费金额高达 2600 万元，足以购置 25 台 H100 服务器。
值得留意的是，这种 CPU 闲置不是因为任务不需要，而是因为业务不敢把它用上，GPU 密集计算过程中，CPU 必须随时为数据加载、任务调度、通信同步等环节提供及时响应，而这时 CPU 被别的任务占满，就会引发训练延迟、通信阻塞甚至任务无法达成，鉴于 CFS 等传统调度机制无法做到绝对优先级保障，所以行业内许多 GPU 训练集群都采用极为保守的 CPU 使用策略，形成了普遍的资源浪费。
与此同时，各类互联网业务的服务端组件、大数据任务、批处理计算都希望获得更多 CPU 资源。一边是 CPU 处于闲置情形，另一边是 CPU 紧缺的状况。怎样在确保不干扰 AI 训练任务的情形下，释放 GPU 节点上那些空闲的 CPU 资源？这并非只是资源利用率的问题，而是操作系统层面的技术阻碍：从设计来看，Linux CFS 调度类不适配异构计算与高优实时任务的需求。
正是在这样的背景下，TencentOS 如意 (RUE) 的在离线混部技术吸引了行业目光，采用深度改造 Linux 内核调度体系的办法，它可以把 GPU 节点闲置的 CPU、网络、IO、内存资源再次激活，使一台服务器可安全承载两类任务，实现算力的高效释放。
1 Linux CFS 的限制：为什么企业“不敢混”
在离线混部并非新的概念。其核心是将延迟敏感的在线任务跟计算密集但对时延没那么敏感的离线任务部署到同一台物理机上，以此提升资源利用率。然而，要搞懂在离线混部难以落地的原因，就得从操作系统的调度方面去看，Linux 默认采用的 CFS 调度类，力求做到公平，即便高优任务也得参与公平队列的时间片分配。但是，在实际的人工智能和在线服务中，延迟敏感型任务所需的是绝对的优先，而非公平。
CFS 调度类无法给予绝对的抢占能力，哪怕高优的 GPU 训练任务需要 CPU 资源，但是如果 CPU 正在运行某个离线批处理任务，CFS 也只能按照调度周期依次切换，这样的延迟足以造成相当明显的卡顿。此外，CFS 隔离主要聚焦于 CPU 时间片，而在 IO、网络以及内存这些方面依靠的是 cgroups，然而 cgroups 的资源限制往往仅具备建议属性，面对高争抢场景无法给予严格保证。
在大规模业务实践时，企业往往会利用提高在线任务权重、分配更多 CPU 配额等方式来避免资源冲突，然而收效甚微。在推进混部尝试的阶段，网络带宽猛然下降使得请求超时、离线大文件读写造成 IO 的阻塞现象、CPU 争抢引起卡顿，都是司空见惯的现象。因此，虽然混部从理论角度讲是可行的，然而在稳定性要求极为苛刻的 AI 训练、在线交易等场景，企业宁可付出额外的成本，也不敢贸然尝试。
2 调度的新秩序：绝对抢占如何成为可能？
在离线混部不能仅仅是碰运气的方案，而是得做到彻彻底底的可控，TencentOS 团队对 Linux 内核进行了增强，形成了可同时实现 CPU、网络、IO 和内存四项资源绝对隔离的体系，其中最关键的创新就是自研的 BT 调度类。BT 调度类并非仅仅是对 CFS 做简单增强，而是新增加了一个独立于 CFS 的调度层级，借此实现高优任务的绝对抢占机制！
在 Linux 调度类的层级里，高优任务通常由 DL 和 RT 调度类负责，然后就是 CFS。BT 调度作为新的调度类，排在 CFS 调度类后面，调度链路从高到低逐个检查各类队列，只要上层队列有可操作的任务，下层队列的全部任务均需马上让出 CPU。这意味着只要 CFS 队列有任务需要开启运行，BT 队列中的离线任务将被强制剥夺运行权，实现毫秒级的绝对抢占效果。依靠 BT 调度器，只要 GPU 需要 CPU 协同配合，即可马上获得执行权，而不会受到离线任务的干扰。
同时，BT 调度器也拥有独立的 CPU 限额控制能力，可按照任务水位线动态限制离线任务的 CPU 占用，让 CPU 一直处于既不过度利用也不被闲置浪费的运行区间。
除了 CPU 调度，TencentOS 如意还对网络、IO 以及内存方面加以强化。
在网络层，按照优先级体系，如意实现了带宽的快速抢占机制，高优先级任务在带宽受限有网络传输要求时，可在一秒内迅速拿回带宽资源，而传统方案一般得花十几秒甚至更长时间。这对直播、电商、推理服务这类对延迟敏感的业务十分关键。
在 IO 层，如意把 BFQ 调度器与动态 writeback 抑制结合起来，借助实时分析历史读写比例以调整带宽分配策略，解决了传统 IO 限速在混合负载情形下适应性差的问题。在同步与异步 IO 场景下，此种动态调优可大幅提升有效带宽利用率，把带宽利用率提升 30% 到 90%。同时，高优读写请求在队列中可拿到绝对优先级，保障离线任务的写入不会对在线任务的读取产生抖动或延迟堆积。
内存层面的强化让混部变得可预测并且可控。凭借全局预留、分级回收以及 pagecache 隔离等方式，如意把高低优任务的内存行为彻底分隔开，高优任务不管遇到什么样的系统压力，都可在极低延迟下成功得到内存，而离线任务则是按照优先级逐级回收，必要时按照优先级触发 OOM 清理。
更核心的是，在如意体系中，CPU、网络、IO、内存不再是孤立治理，而是通过统一的优先级及抢占模型做到协同运作。当高优任务被唤醒时，CPU 层的 BT 调度能在毫秒级中断离线任务，网络层马上收回带宽，IO 层抑制离线数据的写回，防止 IO 出现堵塞，内存层保证高优任务的分配请求马上得以满足，四者相互作用形成一个完整的资源让渡循环圈，使高优任务在多维资源范畴获得绝对优先。依靠这样的系统机制，如意消除了原本无从控制的混部风险，从而在根本上实现在线任务零感知、零干扰，并且把离线任务的资源利用空间压榨至最大化。
3 生产环境的验证：从 15% 到 45% 的资源利用率跃迁
任何创新最终都要接受生产环境的检验。腾讯 TencentOS 如意（RUE）的在离线混部方案覆盖规模达 2000 万核以上，且在大规模业务场景中已实现显著的资源提升。
在微信业务中的某时延敏感模块里，由于任务链路对 CPU 响应时间要求极高，混部前，整机 CPU 利用率被限制在约 15% 的水平，引入如意后，CPU 利用率提升到 45% 左右。不仅如此，业务跟单独运行时相比，请求超时次数未出现明显的改变，稳定性远胜于传统的 cgroup 混部方案。
在外部的客户案例中，某教育科技界的巨头企业依靠如意实现混部能力后，整体成本较之前下降 43%，服务可用性升至 99.995%，接口响应的速度提升了约 10%。某头部短视频平台利用如意混部技术 OS 内核所提供的强隔离、性能主动告警、云原生 SLI 等高级能力，资源利用率往上提升了 100%，一年节省成本达数百万！
值得一提的是，除了经过大量验证的通用服务器实际场景，如意正进一步对新一代智算服务器开展应用拓展，其在智算服务器的灰度实施也已启动，且于早期试点阶段表现出极高的稳定性和安全性。在试点集群里，如意的绝对的抢占机制和跨资源强隔离能力，让 GPU 集群在保障高优任务不受干扰的基础上，释放出大量闲置的 CPU 能力。
4 写在最后
以往被迫处于闲置状态的 CPU 资源，正凭借可靠的操作系统调度机制被激活。在算力成为基础设施的今天，其价值是无限的。随着 GPU 计算能力的提升，CPU 在训练路径中的占比逐渐下降。但这不意味着 CPU 不重要，相反，CPU 对于实时性、同步性任务的支撑需求反而越来越高。如果缺乏强大的 QoS 调度机制，将影响异构计算系统的稳定运行。
TencentOS 如意的创新做到了高优任务的绝对抢占机制，这使混部从不可把控的风险源转变为可约束起来的基础能力。统一的 CPU、网络、IO、内存优先级体系为高优任务带来跨资源的一致保障，由此实现效率提升。同时，这套机制也为 GPU 时代的调度器提供新的模板。当大模型演进至多模态、更长序列和更大参数规模阶段，CPU 闲置的问题将更加突出化，缺乏调度体系反而会让 CPU 成为主要瓶颈。因此，如意在离线混部的价值不只是体现在节省成本上，更在于对算力供给方式进行重构，为未来大规模智算基础设施打造可靠的基础支撑能力。
热门跟贴