腾讯广告模型基于"太极"的训练成本优化实践-人工智能-PHP中文网

腾讯广告模型基于"太极"的训练成本优化实践

近年来，大数据加大模型成为了 AI 领域建模的标准范式。在广告场景，大模型由于使用了更多的模型参数，利用更多的训练数据，模型具备了更强的记忆能力和泛化能力，为广告效果向上提升打开了更大的空间。但是大模型在训练过程中所需要的资源也是成倍的增长，存储以及计算上的压力对机器学习平台都是巨大的挑战。

腾讯太极机器学习平台持续探索降本增效方案，在广告离线训练场景利用混合部署资源大大降低了资源成本，每天为腾讯广告提供 50W 核心廉价混合部署资源，帮助腾讯广告离线模型训练资源成本降低 30%，同时通过一系列优化手段使得混部资源稳定性和正常资源持平。

1、引言

近年来，随着大模型在 NLP 领域横扫各种大数据磅单取得巨大成功之后，大数据加大模型成为了 AI 领域建模的标准范式。搜索、广告、推荐的建模也不例外，动辄千亿参数，上 T 大小的模型成为各大预估场景的标配，大模型能力也已经成为各大科技公司军备竞赛的焦点。

在广告场景，大模型由于使用了更多的模型参数，利用更多的训练数据，模型具备了更强的记忆能力和泛化能力，为广告效果向上提升打开了更大的空间。但是大模型在训练过程中所需要的资源也是成倍的增长，存储以及计算上的压力对机器学习平台都是巨大的挑战。同时平台能够支撑的试验数量直接影响算法迭代效率，如何用更小的成本，提供更多的试验资源，是平台努力的重点方向。

2、太极机器学习平台介绍

太极机器学习平台，致力于让用户更加聚焦业务AI问题解决和应用，一站式的解决算法工程师在 AI 应用过程中特征处理，模型训练，模型服务等工程问题。目前支持公司内广告，搜索，游戏，腾讯会议，腾讯云等重点业务。

太极广告平台是太极为广告系统设计的集模型训练和在线推理的高性能机器学习平台，平台具备万亿参数模型的训练和推理能力。目前该平台支持腾讯广告召回，粗排，精排数十个模型训练和在线推理；同时太极平台提供一站式特征注册，样本补录，模型训练，模型评估以及上线试验的能力，极大提升了开发者效率。

训练平台：目前模型训练支持 CPU 和 GPU 两种训练模式，利用自研高效算子，混合精度训练，3D 并行等技术，训练速度和业界开源系统相比提升 1 个量级。
推理框架：太极自研的 HCF（Heterogeneous Computing Framework）异构计算框架，通过硬件层，编译层和软件层联合优化，提供极致性能优化。

3、成本优化具体实现

（1）整体方案介绍

随着太极平台的不断发展，任务数和任务类型日益增多，资源需求也随之增多。为了降本增效，太极平台一方面提升平台性能，提升训练速度；另一方面，我们也寻找更加廉价的资源，以满足不断增长的资源需求。

峰峦——腾讯公司内部云原生大数据平台，利用云原生技术，对公司整个大数据架构进行升级。为满足大数据业务持续增长的资源需求，峰峦引入混部资源，在满足资源需求的同时，又可极大降低资源成本。峰峦针对不同场景下的混部资源，提供了一系列的解决方案，把不稳定的混部资源变成对业务透明的稳定资源。峰峦混部能力支持3类混部资源：

复用在线空闲资源。在线资源因波峰波谷现象、资源使用预估过高和集群资源碎片等原因，导致集群资源利用率不高，有大量的空闲资源。峰峦挖掘这部分临时空闲资源，来运行大数据任务，目前已在在线广告、存储、社交娱乐和游戏等场景混部。
离线资源弹性借出。大数据平台有些任务也具有潮汐现象，在白天大数据集群资源使用率低的时候，峰峦支持把部分资源临时弹性借出，待大数据集群高峰到来之前，再拿回这部分资源。这种场景非常适合解决节假日和大促期间在线任务临时需要大量资源问题，峰峦当前已支持春节和 618 等重大节假日。
复用算力资源。算力资源是以低优 CVM 方式挖掘云母机的空闲资源，所谓低优 CVM 是指在云母机上启动具有更低 CPU 优先级的 CVM 虚拟机，该虚拟机可实时被其他的虚拟机抢占资源。峰峦基于底层算力提供的资源信息，在调度、过载保护、算力迁移等方面做了大量的优化，目前已有百万核的大数据任务在算力资源上稳定运行。

同时，峰峦引入云原生虚拟集群技术，屏蔽底层混部资源来自不同的城市和地域导致的分散性特点。太极平台直接对接峰峦租户集群，该租户集群对应底层多种混部资源，而且租户集群拥有独立和完整的集群视角，太极平台也可无缝对接。

（2）资源混部方案

在线空闲资源

峰峦自研了 Caelus 全场景在离线混部方案，通过将在线作业和离线作业混部的方式，充分挖掘在线机器的空闲资源，提升在线机器资源利用率，同时降低离线作业的资源成本。

如下图所示，是 Caelus 的基本架构，各个组件和模块相互配合，从多方面保证了混部的质量。

首先，Caelus 全方位保证了在线作业的服务质量，这也是混部的重要前提之一，比如：通过快速的干扰检测与处理机制，主动感知在线服务质量，及时进行处理，并且支持插件化的扩展方式支持业务的特定干扰检测需求；通过全维度的资源隔离、灵活的资源管理策略等，保证在线服务的高优先级。

其次，Caelus 从多方面保证了离线作业的 SLO，比如：通过混部资源与离线作业画像，为作业匹配合适的资源，避免资源竞争；优化离线作业驱逐策略，优先排序驱逐，支持优雅退出，策略灵活可控。与大数据离线作业大多是短作业（分钟级甚至秒级）的特点不同的是，太极作业的运行时间大多较长（小时级甚至天级）。通过长周期的资源预测与作业画像更好地指导调度，为不同运行时长、不同资源需求的作业找到合适的资源，避免作业运行几小时甚至几天后被驱逐，导致作业状态丢失，浪费资源与时间。当出现需要驱逐离线作业的情况时，会优先通过运行时热迁移，将作业实例从一个机器迁移到另一个机器，并且保持内存状态和IP等不变，作业几乎无影响，极大地提升了作业的 SLO。为了更好地把混部资源利用好，Caelus 还具备其他更多的能力，详见 Caelus 全场景在离线混部方案（//m.sbmmt.com/link/caaeb10544b465034f389991efc90877）。

潮汐资源

大数据任务一般是白天任务量相对少，晚上任务量多，峰峦把白天部分空闲的大数据资源出让给太极平台，夜间再回收这部分资源，我们把这种资源称为潮汐资源。潮汐资源的特点是节点上的大数据任务几乎是完全退出的，但节点上还保留着大数据的存储服务 HDFS，运行太极作业时不能影响到 HDFS 服务。太极平台使用潮汐资源时需要和峰峦平台协商一致，峰峦平台在固定时间点提前根据历史数据筛选一批节点，待大数据任务优雅退出后，通知太极平台有新的节点加入，太极平台开始在峰峦租户集群提交更多的任务。借用时间到达前，峰峦通知太极平台部分节点要回收，太极平台有序归还节点。

如下图所示，潮汐资源的挖掘、管理和使用涉及到多个系统的分工配合：

大数据资源出让系统：该系统会根据各个机器上不同的作业运行情况以及集群过去一段时间的运行数据，基于机器学习算法，找到最合适的待下线的机器节点，以满足特定的资源需求并且对正在运行的作业影响最小，然后禁止调度新的作业到这些节点上，等待节点上正在运行的作业运行完毕，最大限度地降低对大数据作业的影响。
Caelus 混部系统：虽然出让系统腾挪出来的机器资源上没有运行大数据作业了，但上面还运行着 HDFS 服务，还提供着数据读写服务。为了保护 HDFS 服务，引入Caelus混部系统，将 HDFS 作为在线服务，通过 Caelus 一系列的在线服务保证手段（如：通过 HDFS 关键指标检测其是否受到影响）保证 HDFS 服务质量不受影响。
通过虚拟集群的方式使用潮汐资源：这些出让的机器资源会由峰峦统一管理和调度，并以虚拟集群的方式提供给太极平台使用，提供 K8S 原生接口，这样做到了对上层平台屏蔽底层资源的差异性，保证应用使通过相同的使用方式使用资源。
与应用层断点续训打通：潮汐资源在晚上会被回收以用于运行大数据作业，为了减少回收的影响，峰峦和应用层的断点续训功能进行了打通，实现资源切换不中断训练，切换后不影响业务的继续运行。

算力资源

算力资源的特点是给业务呈现的是一个独占的 CVM，对业务方使用来说比较友好。然而，使用算力资源的挑战在于云母机层面低优 CVM 的 CPU 资源会随时被在线 CVM 压制，导致算力资源非常不稳定：

算力机器不稳定：算力机器会因为碎片资源盘整、机房电力不足等原因下线。
算力资源优先级低：为了保证正常 CVM 机器的服务质量不受影响，算力资源上的作业优先级最低，会无条件为高优资源上的作业让步，导致性能极不稳定。
驱逐频率高：多种原因（算力资源性能不足、磁盘空间不足、磁盘卡住等）会触发主动驱逐 pod，增加了 pod 的失败概率。

为了解决算力资源的不稳定性问题，通过峰峦主控层扩展各项能力，从多方面对算力资源优化，提升算力稳定性：

① 资源画像与预测：探索和搜集各种机器性能指标，生成聚合指标，预测低优 CVM 未来一段时间的可用资源情况，这些信息用于调度器调度 pod 和驱逐组件驱逐 pod，满足 pod 的资源要求。

② 调度优化：为保证太极作业的服务质量，针对作业的需求和资源的特点，在调度策略上有较多的优化，将作业性能提升了 2 倍以上。

同城调度：将 PST 和训练作业调度到同城同机房，将作业实例之间的网络延时降到最低，并且同城内的网络带宽成本也更低，起到了降低成本的作用。
单机调度优化：结合资源预测的结果以及 CPU stealtime 等指标，为作业选择性能更佳的 CPU 进行绑核，更好地提升作业性能。
分级调度：对所有管理的资源做自动打标和分级，把 Job Manager 等对容灾要求比较高的作业自动调度到相对稳定的资源上。
调优调度参数：根据资源资源画像和预测数据，调度器为作业优先挑选性能更优和更稳定的节点。另外为了解决步调不一致导致的梯队过期问题，将同一个作业的实例调度到性能接近的机器

③ 运行时服务质量保证

主动驱逐阶段引入运行时热迁移，做到业务基本无感知：为了应对资源不稳定以及 pod 被驱逐导致应用被 kill 的问题，实现了运行时热迁移，并且提供了多种热迁移策略满足不同场景的需求。目前从线上数据看，使用迁移优先策略时，对于大内存的容器来说，热迁移的中断时间是 10 多秒。我们还实现了与内存大小无关的常数中断时间（恢复优先的策略）。当前每天成功主动迁移 pod 数 2 万多次，且支持跨集群热迁移，极大地降低了驱逐的影响。
优化驱逐策略，将驱逐造成的影响降到最低：每台机器每次驱逐时，优先驱逐后启动的 pod，避免影响已启动任；每个任务每次只驱逐一个节点，避免单任务上下游一起被驱逐，造成任务级重启；pod 被驱逐时，和上层 Flink 框架联动，主动告知 Flink，快速单点恢复。

④ 自反馈优化：通过资源画像，周期性的替换掉性能差的机器，并且与底层平台打通，实现对 CVM 的平滑抽离，让峰峦有机会以对业务无影响的方式逐个迁移应用实例，降低对实例的影响。

⑤ 提升 Flink 层的容灾能力，支持单点重启和层级式调度

TM（Task Manager）单点重启能力避免 Task 失败导致整个 DAG 失败，可以更好适配算力抢占式特性；分层调度避免 gang scheduling 造成过长的作业等待，并且可以避免 TM Pod 过度申请的浪费。

（3）应用层优化方案

业务容错

离线训练任务要使用廉价资源一个大前提就是不能影响资源上原有任务的正常运行，所以混部资源有以下几个关键挑战：

混部资源大多是临时资源，会频繁下线；
混部资源会无条件为高优资源让步，导致机器性能极不稳定；
混部资源的自动驱逐机制也极大加大了节点和 pod 的失败概率。

为了保证在混部资源上任务可以稳定运行，平台使用三级容错策略，具体解决方案如下：

热迁移技术：在 Task Manager 将要发生驱逐前，提前感知，把相应的 Task Manager 迁移到另外一个 pod 上；同时利用内存压缩，流式并发，跨集群热迁移等能力持续优化热迁移成功率。
Task Manager 重启：当任务当中一个 Task Manager 由于异常或者驱逐等原因导致运行失败之后，整个任务不会直接失败退出，而是先保存该 Task Manager 的状态，然后重新启动该 Task Manager，从而降低整个任务失败的概率。
任务 Full Recovery: 当一个任务的由于 Flink 状态异常，处于无法恢复状态时，会触发 Job Manager 的重启，为了保证 Job Manager 的稳定性，平台把 Job Manager 部署在稳定性较好的独立资源上，保证任务状态正常。
断点续训：如果前面几个容错策略都失败了，平台会基于历史的某一个 ckpt 重新启动任务。

通过业务层的容错，运行在混部资源上的任务稳定性从最初的不到 90% 提升到最终的 99.5%，基本和普通独占资源上任务稳定性持平。

任务潮汐调度

针对潮汐资源要求离线训练任务只能白天使用，晚上需要提供给在线业务使用，所以太极平台需要在白天时根据资源到位情况，自动启动训练任务；在晚上对任务做冷备，同时停止对应的训练任务。同时通过任务管理队列来管理每个任务调度的优先级，对于晚上新启动的任务会自动进入排队状态，等第二天早上再启动新的任务。

核心挑战：

潮汐现象：资源白天的时候可以提供给离线任务使用，晚上的时候需要回收。
资源动态变化：在白天时，资源也是不稳定的，资源会随时发生变化，一般是早上的时候资源比较少，然后资源逐渐增加，到晚上的时候资源到达高峰值。

解决方案：

资源感知的调度策略：早上在资源逐步增加的过程中，潮汐调度服务需要感知资源变化，同时跟进资源情况来启动待继续训练的任务。
模型自动备份能力：在晚上资源回收前，需要把当前平台上运行的所有任务逐步做备份，这对于平台的存储和带宽压力非常大，因为平台上有几百个任务，每个任务冷备大小从几百 G 到数 T 大小不等，如果在同一时间做冷备的话需要在短时间传输和存储数百 T的数据，对于存储和网络都是巨大的挑战；所以我们需要有一套合理的调度策略，逐步做模型的存储。
智能资源调度能力：潮汐调度和传统训练相比，每个任务在晚上资源回收时的模型备份和每天早上任务新启动的时候的开销是额外开销，为了降低这部分额外开销，我们调度时需要评估哪些任务在当天就能跑完，哪些任务需要跑多天，对于当天能跑完的任务，我们优先给它分配更多资源，保证当天任务运行完成。

通过这些优化能够保证任务能稳定在潮汐资源上运行，对于业务层基本无感知。同时任务的运行速度不会受太大影响，由于任务启停调度带来的额外开销控制在 10% 以内。