独家揭秘：腾讯千亿级参数分布式ML系统无量背后的秘密

做者 | 袁镱

编辑 | Vincent

AI 前线导读：千亿参数规模的模型已经被业界证实可以有效提升业务效果。如何高效训练出这样的模型？百 GB 级别的模型如何在线上实现毫秒级的响应？这些能力在各个大厂都被视为核心技术竞争力和机器学习能力的技术壁垒。要具有这样的能力，对相关系统有什么样的挑战？本文将从系统的角度去详细分析这些问题，并给出腾讯公司的无量系统对这些问题的解答。

更多干货内容请关注微信公众号“AI 前线”，（ID：ai-front）

简 介

在互联网场景中，亿级的用户天天产生着百亿规模的用户数据，造成了超大规模的训练样本。如何利用这些数据训练出更好的模型并用这些模型为用户服务，给机器学习平台带来了巨大的挑战。下面以网页 / 图文 / 视频推荐场景分析这些挑战，下文中均称为推荐场景。

1. 样本数量大。在推荐场景下，天天的样本量能够达到百亿量级。若是须要按一个月的样本进行训练，样本量会在千亿级别。若是每一个样本平均 500 特征值，单个样本的大小就是 5KB 左右，一千亿样本的大小就是 500TB。即使只使用一周内的样本，样本数据的大小也在 100TB 这个级别。

2. 特征维度多。巨大的样本量使高维度模型的训练成为可能。为了给用户提供更合理的推荐结果，须要对用户和被推荐的文章 / 图片 / 视频进行详细的描述。各个业务都会创建起丰富的用户模型，也会对文章 / 图片 / 视频进行多维度的标注。

   在系统进行推荐时，还会使用到用户如今的上下文信息，好比：时间，位置，以前浏览的页面等。当这些特征被引入到模型中时，会致使特征规模的迅速增长。若是再考虑交叉等特征转换操做，模型的特征维度会轻松地膨胀到千亿甚至万亿级别。

3. 训练性能要求高。咱们面对的是百 TB 的样本和百亿 / 千亿参数的模型。而业务须要在短期内训练出一个性能指标好的模型，以便快速上线验证。这对机器学习平台训练能力有很高的要求。

前面 1～3 点，提出的是超大规模模型的训练框架面临的挑战，然而训练出模型只是重要的第一步。最终模型须要上线为用户提供服务才能体现其业务价值。对于以往的机器学习中的中小模型，模型上线服务并非一个特别被关注的事情。可是，当最终模型文件很大，甚至超过单机的内存大小时，模型上线服务就变成了棘手的问题。

1. 模型大但用户须要毫秒级响应。以最简单的 LR 模型为例，一个 10 亿特征的模型的大小也会达到 12GB（每一个参数须要一个 8Byte 的 key 和 4Byte 的 float value）。若是是 DNN 模型，模型大小到达 TB 也是可能的。当训练好一个模型后，模型就被上线，为用户提供预测服务。 为了达到良好的用户体验，预测服务的响应时间须要在 10ms 这个量级。以手机用户的推荐场景为例，从用户在手机上刷新页面到看到推荐结果，时间不能超过 1s，扣除掉网络通信的开销，IDC 内在线服务的响应时间须要控制在 200ms 之内。可是，整个推荐的流程至少有召回，排序和展现控制三个阶段。 在排序阶段，须要对 200 个以上的文章进行特征拼接和点击率预估，因此模型对这 200 个文章进行点击率预估的总时间要在 30ms 之内。如何使用这么大规模的模型进行高性能，高并发的预测也对平台能力的重大考验。

2. 模型实时上线。对于资讯推荐类场景，用户的关注点变化很快。系统须要根据最新的用户行为数据调整模型，而后以最快的速度将如此大规模的模型更新到多个地区的在线预测服务。

为了解决以上挑战，咱们：

1）开发了一个基于参数服务器架构的机器学习计算框架 -- 无量框架，已经可以完成百亿样本 / 百亿参数模型的小时级训练能力。无量框架提供多种机器学习算法，不但能进行任务式的离线训练，还能支持以流式样本为输入的 7*24 小时的在线训练。

2）在无量框架的基础上，咱们构建起自动化模型管理系统 -- 无量模型管理，模型可以在离线训练任务，在线训练集群和在线预测服务之间无缝地高效流转，实现 10GB 级模型的分钟级上线。

3）为了提升大模型的线上预测服务，咱们还开发了高性能的预测模块和服务 -- 无量预测服务，对于数十 GB 的模型，只需几毫秒便可完成 100 个样本的预测。

无量框架，无量模型管理和无量预测服务共同构成了无量系统的主要部分。下面咱们将对无量系统的架构和各个主要组成部分进行详细的介绍。

1. 系统流程与架构

工做流程

在广告 / 推荐等场景下，模型的生产和使用过程，大体分为几个步骤：

1.日志采集与样本生成。经过收集用户的线上行为信息，生成模型须要的样本。这些样本能够被存储起来用于离线训练，也可使用流式数据的方式推送给在线训练集群。

2.模型训练。有了样本以后，在训练集群中训练出具体的模型。开发人员经过调整的超参数或模型结构来获取好的模型。

3.模型评估。在模型被放到线上服务以前，须要对模型进行一些评估工做。

4.模型上线预测。无量系统目前包括以上步骤中的模型训练，模型评估和上线预测。

为了让模型从训练集群到在线预测服务顺利地流转，无量系统提供了模型管理功能，可以自动化地将从训练机器导出新模型到在线预测服务。业务也可以在模型自动化上线过程当中定义模型评估操做，避免训练效果差的模型被放到在线预测服务中。另外当模型上线以后，也须要验证线上的模型是否有问题。

在模型的开发过程当中，超参数调试耗费了模型开发人员大量的时间。无量系统经过与般若系统结合，实现了模型训练效果的实时监控，为自动化调参提供了决策数据。无量系统正在进行自动调参工具的开发。算法人员也能够基于这些数据上实现自定义自动调参功能。

系统架构

在一个机器学习系统中，机器学习算法的代码只是训练或预测过程当中很是小的一部分。如下是 Google 对其机器学习系统的一个统计。

[1 ] Hidden Technical Debt in Machine Learning Systems, Google.

为了让机器学习任务运行起来，须要大量的配套服务设施的支持，包括数据管理与存储，训练框架，在线预测框架和资源管理等多个模块。无量系统的系统架构以下所示：

系统架构图

无量系统的训练任务运行在 MIG 专门针对机器学习和深度学习任务的般若调度系统上，在线训练集群和在线预测服务部署在 Sumeru 系统上。般若系统和 Sumeru 系统均是基于 docker 容器化技术构建，为无量系统的快速部署和扩展提供了可靠的基础设施保障。

下层存储系统支持 HDFS 和 ceph 两种分布式网络存储。HDFS 做为经常使用的分布式网络存储，与其余的数据分析系统无缝对接。Ceph 以其高性能与灵活的文件操做，弥补了 Hdfs 在文件操做上的不便。

日志采集使用 MIG 的灯塔系统，并配合了自研的流式数据处理服务实时生成训练样本。

经过自研的基于参数服务器架构的无量计算框架，无量系统支持了千亿级模型的任务型离线训练和流式在线训练。无量计算框架采用 C++ 实现以达到优异的性能，并支持了推荐和搜索场景经常使用的 LR/FM/FFM/DNN 等模型，用户只需作简单的配置便可实现超大规模模型的训练。

对于千亿级参数的模型，模型大小至少会有几十 GB。无量系统为业务的在线预测服务提供了两种模型使用模式：

1）模型服务组件。模型服务组件包含了模型版本管理和模型预测两个主要功能。因为模型服务组件对内存管理进行深度优化，业务可以在本身的预测服务中直接加载和使用 100G 如下的模型。

2）模型存储服务。当模型大小超过单机可以存放的大小时，就须要分布式的模型存储服务来进行模型管理和提供预测服务。

在样本生成，模型训练，在线预测模块之上，是无量系统的平台服务。用户在这里管理本身的数据，训练任务和模型。

至此，咱们简单介绍了无量系统的各个部分。让读者可以对无量系统有一个总体的了解。下面，咱们将重点介绍无量计算框架，模型管理与模型预测服务。

2. 无量计算框架

为了获得一个好的模型，至少须要三个方面的内容：1. 数据；2. 模型和算法；3. 计算框架。

正如前面介绍中所述，互联网用户为咱们产生了大量的样本数据，为学习出一个好的模型提供了数据基础。在本节中，咱们将重点介绍后面两部份内容。

首先咱们会介绍推荐场景经常使用的模型和算法，并由此推导出为了实现这些模型的训练，对计算框架有什么样的需求，以及无量计算框架如何知足这些需求，实现高性能的模型训练。

推荐模型与算法

随着商业化推荐的兴起，预测用户点击率（Click Through Rate，简称 CTR）领域获得了大量的研究关注，产生了不少 CTR 预估模型。下面对大规模场景下的几个表明性的模型作简单的对比介绍。他们分别是 LR，FM，DNN。对于推荐场景中经常使用的 GBDT 算法，因为其不适应大规模特征的输入，在此不作对比。

LR 模型

LR 是一个简单而有用的线性模型。优势：它实现简单并且很是容易支持大规模特征的样本输入。在实际应用中，每每能取得不错的效果，经常被用做 baseline。缺点：因为是线性模型，须要大量的特征工程的工做来让它获得好的效果。而特征交叉等操做也直接致使了模型的特征空间急剧膨胀。

FM 模型

FM 在 LR 线性模型的基础上，引入了二次项，使得 FM 模型可以自动学习特征之间的二阶交叉关系。优势：自动学习二阶交叉关系，减小了部分特征工程的工做。缺点：要学习二阶以上的交叉关系，仍然须要进行交叉特征选择的工做来生成相应的样本。

DNN 模型

随着深度神经网络（DNN）在图像、语音等领域的突破性发展，DNN 被引入到 CTR 模型中来，但愿学习到特征之间的复杂关系，获得更好的模型。在 CTR 预估中，输入特征是高维稀疏的，不能直接使用全链接网络直接进行学习，因此用于 CTR 预估的网络通常采用 embedding 层 + 全链接层的结构。经过 embedding 层将稀疏特征转换为低维稠密特征，再输入后面的全链接层。优势：能够直接输入原始特征，减小了交叉特征的选择工做。缺点：训练调参相比 LR 和 FM 等更难。因为 DNN 稠密参数的引入，训练性能也比 LR 和 FM 更低。

[Google 2016] Wide & Deep Learning for Recommender Systems

前面简单介绍了三种表明性的模型，在这三种基本结构上，经过不一样的组合和改进，衍生出了 FFM，FNN，DeepFM，DIN 等模型结构。若是想详细了解相关的模型，请见参考文献 [3][4]。

从上面的模型基本结构，咱们能够总结出 CTR 模型的参数特色：

1）超大规模稀疏的输入特征参数。LR，FM 和 DNN 的 embedding 层的输入都是稀疏的，参数值多是一个单独的值（LR 的 w），也有多是一个向量（FM 中的 w+v 和 embedding 层的 w）。

2）稠密的交叉关系参数。DNN 中全链接层参数都是稠密的。

由此能够看出，计算框架须要同时支持稀疏和稠密两种参数格式。另外，一些统计类特征（例如：文章的曝光数，点击率等）在训练中也是很重要的。这些参数也须要在训练过程当中方便地计算获得。

在推荐场景下，可推荐的内容存在必定的时效性，随着热点的变化，用户的关注点也会发生相应的变化，致使 CTR 模型应用到线上后，预测性能会随着时间的流逝而降低，因此 CTR 模型都须要进行及时的更新。在不一样的业务应用场景下，这个更新频率能够是分钟级，也多是天级别的。 然而，从新训练一个百亿规模的模型会消耗大量的时间和计算资源，为了以低廉的资源成本完成模型的及时更新，推荐场景下会采用在线训练的方式。因此计算框架须要支持多种在线训练算法。目前应用于在线训练的优化算法主要有 Ftrl，Adagrad 等。

高性能大规模并行机器学习框架

在咱们的系统设计目标中有三个关键维度：

1）千亿级模型参数；

2）千亿级样本数据；

3）高性能。

如何同时提升上面的三个维度的目标，咱们须要仔细分析分布式计算过程。以如今经常使用的基于梯度降低的分布式优化算法为例。在使用样本数据 I 进行一轮训练的过程当中，有如下几个基本步骤，

1) 数据分片，将全部数据拆分后分配到多台机器上；

2) 并行计算 g，各台机器上的计算节点按照指定算法计算梯度；

3) 聚合 g，将各台机器上计算的 g 收集起来；

4) 更新 w，使用上一步获得的 g 更新 w；

5) 广播 w，将更新后的 w 传输给计算机器。

这样的学习逻辑经过将数据分布到多台机器上计算，有效地解决了样本数据量的问题。Hadoop 和 Spark 都采用这样的逻辑进行机器学习，Spark 因为 RDD 的方式充分利用内存来存储中间数据，大大提升了训练性能。可是在这样的训练逻辑下，存在两个问题：

1) w 被存储在一台机器上，限制了框架可以训练的模型的规模，只能是单机可存储的模型，以 128G 的内存的机型为例，10 亿个参数的模型就达到他的存储极限了；

2) w 被广播给各个机器。因为是广播推送方式，当模型规模变大的时候，广播操做带来的带宽成本会急剧增长。以咱们的测试来讲，用 Spark 训练一个百万参数的模型时就发现性能难以忍受了。

以上分布式训练逻辑是梯度降低算法的逻辑，而如今机器学习尤为是深度学习中普遍使用的是随机梯度降低算法（SGD）。模型参数是以 minibatch（128 个样本，甚至更少）为单位来更新的。这致使参数更新频率急剧提高，带来的是巨大的网络带宽需求。因此必需要解决上面两个问题，才可以进行千亿级参数的模型训练。参数服务器架构由此产生。

参数服务器的基本结构和工做流程图

从 2010 年被提出，通过了几年的发展演进，如今广泛使用的是第三代参数服务器架构。相对于前面 Algorithm 1 的流程，参数服务器有两点主要的不一样：

1) 有一种新的角色 Server，专门用于分布式地存储模型参数，并进行参数的更新计算。这使得可以训练的模型规模再也不受限于单机的内存大小，同时将多个 worker 节点的参数请求分摊到多个 server 上，减小了单个 server 上因参数和梯度传输致使的网络瓶颈。

2) 负责计算的 Worker 节获取参数的方式是 pull 方式。因为不是被动的等待广播参数，pull 方式使得 worker 节点能够根据训练数据的需求来获取参数。尤为是在推荐场景下，样本都是很是稀疏的。 举例来讲，一个模型可能有 100 亿个特征输入，而具体到一个特定的样本，只会有几百个有效特征值。因此只须要获取与这几百个有效特征值有关的参数便可，而不须要传输整个模型。

简而言之，参数服务器架构下，多个 server 分摊参数存储和传输的压力，多个 worker 按需获取和更新参数下降了参数和梯度传输的网络需求。这使得千亿参数模型的高性能训练成为了可能。

经过上面的分析，咱们获得了如下的结论。参数服务器可以在模型规模，样本数量和训练性能三方面知足咱们的设计要求。

Hadoop/Spark/ 参数服务器对比

了解了通用的参数服务器架构以及其特色，咱们回到无量计算框架，继续分析一个通用的参数服务器架构在实际中面临的问题以及咱们的解法。

在模型和算法的分析中，咱们知道，要实现两类稀疏和稠密两类参数的传输与更新。

1）超大规模稀疏的输入特征参数。这里稀疏有两层含义。

首先，模型可能的参数是千亿个，可是由于并非全部特征都有可能出如今训练样本中，因此通常不会全部参数都有值，通常最终的模型可能只有 1/10 的参数是有值的。若是使用了稀疏化的技术，这个比例会更低。

其次，对于每一个样本只会使用到很是少的特征。在一个千亿特征的模型中，单个样本一般只会命中到几百个特征。

从上面的分析中，能够看出，参数服务器架构在大规模稀疏特征的模型训练中尤其高效。由于 worker 训练一个 minibatch 的样本时，只须要获取与这些样本相关的参数便可，若是每一个样本平均有 500 个特征，那么 100 个样本最多只须要获取 5 万个特征的相关参数便可。

2）稠密的交叉关系参数。与稀疏的输入特征参数不一样，交叉关系参数规模相对较小，可是每一个样本的训练会使用到所有的稠密参数。假设全链接层中最大的一层是 1024*512，那么每次计算使用到的稠密参数就是在 50 万这个量级。

从这里咱们能够看出，稀疏和稠密两种参数在训练过程当中存在不一样的性质。稀疏参数整体规模大，可是每次训练只使用到很小的一部分。稠密参数整体规模相对较小，可是每次训练都须要被所有使用到。因为两种类型参数的性质差别，被天然地切分红了基于 Kv 和基于矩阵的数据结构。

下面咱们继续分析训练各个阶段的性能问题与咱们的解法。

1）参数获取。在实际的超大规模模型的训练中，网络常常成为性能瓶颈。为了减小由于参数获取而致使的网络传输压力，咱们引入了参数缓存机制，worker 并非每一个 minibatch 都从 server 获取最新的参数。然而，在分布式训练中，缓存模型参数存在训练正确性的风险。 因为在数据并行状况下，各个计算节点使用的训练数据是不一样的，若是进行屡次训练而不一样步更新参数，则模型可能出现没法收敛的问题。在学术研究领域，这是一个训练的网络带宽与模型训练正确性保障的问题。已有不一样的同步控制协议的研究。 咱们的实现借鉴了 ssp 协议 [5] 中有限版本差别的思想，经过控制缓存的使用次数，在保障训练正确性的前提下，减小因参数获取而致使网络传输。

2）梯度更新。计算完成后的梯度上传也会有大量的数据须要经过网络传输。按照模型的梯度计算逻辑，全部使用到的参数都会获得相应的梯度。可是，是否须要发送某个参数的更新，或者以什么样的方式发送给Server倒是能够选择的，这个过程称为梯度压缩。梯度压缩的方法大体能够分两类：

1）梯度量化。将梯度从double/float等原始类型量化成二值/三值等用几个bit就能表示的类型，以减小传输数据量。

2）梯度稀疏化。选择重要的梯度当即上传，不是很重要的梯度更新，则累积起来，稍后再上传。如读者对这个研究领域感兴趣，能够阅读参考文献[6][7]。

传统的梯度压缩技术存在与模型大小至关的内存消耗，因此主要使用在单机可存储的稠密模型的训练中，在无量所应对的超大规模模型的训练中，咱们对现有的梯度压缩技术进行了改进，使之适应了百亿稀疏参数规模模型的训练，能够减小99%以上的梯度传输而不影响训练效果。

3）梯度计算。在机器学习，尤为是深度学习过程当中，模型的梯度计算过程会有大量的数值计算操做。除了使用多线程并行训练的方式充分利用多个 cpu 的计算能力，咱们还使用 SSE 等 CPU 并行计算指令和 Eigen 线性计算库实现梯度计算过程，充分利用了 CPU 芯片的流水线和并行指令能力，比单纯的多线程并行的计算性能高 10+ 倍。

在实际的生产环境中，数据被存放在 hdfs 集群上，而训练时拉取数据变得很耗时。咱们经过将数据读取异步化，使得数据读取不影响训练的参数传输，梯度计算和更新过程。同时经过优化数据读取模块的内存管理和样本缓存机制，以极小的内存开销知足训练对样本随机性的需求。

3. 无量模型管理 -- 全流程模型管理

在推荐类业务中，文章和视频资料快速更新，社会热点随时出现和消失，用户的兴趣也常常变化。为了取得优秀的推荐效果，不少具备时效性的特征信息被加入到预测模型中，致使 CTR 模型须要及时更新。无量系统提供了全流程的模型管理服务。

模型流转的基本流程

在管理超大规模的模型时，存在两个主要的挑战：

1）模型超大致使的模型上线性能的问题。对于千亿参数的模型，若是每一个参数都以 4 字节的 float 格式存储，最终存储的模型将会接近 TB 级别。若是要实现分钟级别地将新模型更新到多地的在线预测服务上，仅从数据传输和文件解析的性能上看，每次都使用全量模型的方式就是不可行的。 幸运的是，模型在训练过程当中的变化是渐进的，而当模型上线时，是一个相对稳定的状态，在线训练更多的是对模型的微调。所以，对于超大规模的模型，通常采用全量 + 增量的方式进行管理。首先使用全量模型加载到线上服务，而后按期将模型的差别部分以增量的方式叠加到线上服务的模型中。

2）模型分片致使的管理问题。在全量 + 增量的模型上线模式下，线上服务的模型对应着多个模型文件。若是线上服务出现故障须要恢复或者由于请求量上升须要扩容时，就须要使用多个模型文件来恢复出模型。在某些状况下，业务发现当前模型效果差，须要替换模型或者进行版本回滚时，须要另外的一组模型文件。 另外，不一样于单机可存储的模型，在参数服务器框架下，模型被分片存储在不一样的机器上。为了提升模型导出效率，多个 server 节点会并行导出多个模型分片文件。假设存在 100 个 server，那么就会有 100 个模型分片文件。给模型管理工做带来了挑战。

为了不模型开发和使用者陷入这些管理问题，同时也为了保障系统的稳定运行，无量模型管理服务将全部模型管理的相关工做承接下来。用户只需进行必要的配置，模型管理服务就会自动地发现新版本的模型，验证模型的完整性并将新模型传输和发布到指定的在线预测服务中。 对用户彻底屏蔽下层相似全量，增量，分片等细节。后期，用户还能够自定义模型验证的方法，对即将上线的模型进行模拟请求等校验，避免有效果差的模型被上线，给业务形成损失。

4. 无量模型服务

使用千亿参数的大模型进行线上预测，面临有许多的问题，下面咱们就一些主要问题进行分析并介绍咱们的方案：

1）模型加载的内存问题。当被加载到内存中时，须要构建相关的数据结构，所消耗的内存大小会比模型文件大不少。以最简单的 LR 模型为例，每一个特征只会有一个 float 类型的模型参数，一个 10 亿有值特征的模型的文件大小大概是 12GB（每一个特征 8 字节 key+4 字节值 value）。使用 stl 标准库中 unordered_map 加载这个模型须要超过 25GB 的内存。也就是说会有超过模型大小 1 倍的内存开销，这使得单机可以存储的模型大小受到极大的制约。 咱们本身实现了一个 hash_map：tl_hash_map，专门针对模型稀疏参数特色进行了内存优化。内存消耗只比模型数据大 20% 左右。这意味着 tl_hash_map 有效地提升了可以被单机存储的模型的大小极限。以 128GB 内存的机器为例，使用 tl_hash_map，最大能支持的 lr 模型文件大小是 100GB 左右，而标准 unordered_map 最大能支持 50GB 左右。

2）模型服务的性能问题。为了达到良好的用户体验，预测服务的响应时间须要在 10ms 这个量级。以手机用户的推荐场景为例，从用户在手机上刷新页面到看到推荐结果，时间不能超过 1s，扣除掉网络通信的开销，IDC 内在线服务的响应时间须要控制在 200ms 之内，而整个推荐的流程至少有召回，排序和展现控制三个阶段。在排序阶段，须要对 200 个以上的文章进行特征拼接和点击率预估，因此模型对这 200 个文章进行点击率预估的总时间要在 30ms 之内。

从排序服务发出请求开始，到请求完成，至少存在两个性能瓶颈点：

1）请求包的网络传输与编解码。为了预测文章的可能点击率，须要为每一个文章准备全部的样本特征。假定每一个样本有 500 个特征，那么 200 个文章的请求就有 10 万个特征。整个请求包的数据会有 1MB 左右。网络传输和编解码的性能对整个 rpc 框架都带来了极大的挑战。咱们定义了一套针对模型预测场景的特征编解码格式，避开了现有 rpc 框架在编解码格式上的性能缺点，而且最大化地减小了须要传输的数据大小。

2）模型参数查询和计算性能。为完成模型的预测功能，首先须要从模型中找到须要的参数，而后完成预测值的计算。面对超大规模的模型，首先要解决的就是模型存储方式的问题。若是模型可以单机存储，那么模型参数的查询则能够在本机完成。若是模型超过单机存储的极限，则须要使用分布式存储的方式提供查询服务。 考虑上面的例子，一个请求须要 10 万个特征的参数，这些特征被存储在多台机器上。即便忽略预测计算时间，要保证这个请求在 30ms 以内返回，那么全部存储参数的节点都必须在 30ms 以内返回结果。这就会出现木桶现象，任何一个存储节点出现了超过 30ms 的响应延时，整体请求时间都必定会超过 30ms。这样的存储系统对请求排队是接近 0 容忍的。但推荐场景又是一个高并发的场景，预测服务须要支持每秒上万的用户请求。 无量系统开发了一套分布式模型预测服务，专门针对分布式预测场景下高并发的模型参数请求的性能问题进行优化，实现对 TB 级模型的高并发预测服务支持。

5. 总结

随着互联网服务的发展，愈来愈精细和定制化的服务须要更好的模型支持，而超大规模预测模型已经成为主流的解决方案。经过深度的研究与优化，无量系统开发了可以支持千亿级参数模型训练的高性能计算框架，并经过模型管理，模型预测服务，实现了超大规模模型的训练，管理以及上线的全流程支持。 无量系统已经支持了 LR/FM/FFM/DNN 等多种经常使用模型，并在移动手机浏览器业务中实际使用和验证，帮助业务取得了巨大的业务指标提高。无量系统将逐步扩展功能，好比正在探索的基于 GPU 的深度学习技术，以覆盖更多的现有业务场景以及最新的 AI 类应用场景，为业务的进一步提高提供强大的系统支持。

做者介绍

袁镱博士，腾讯科技有限公司高级研究员

参考文献

[1] Hidden Technical Debt in Machine Learning Systems, Google. In NIPS'15

[2] Wide & Deep Learning for Recommender Systems, Google 2016

[3] 常见计算广告点击率预估算法总结 https://cloud.tencent.com/developer/article/1005915

[4] 深度学习在 CTR 预估中的应用 mp.weixin.qq.com/s/CMZHhxAMn…

[5] Solving the stragglerproblem with bounded staleness. In HotOS (2013).

[6] TernGrad: Ternary Gradients to Reduce Communication in Distributed Deep Learning

[7] Deep Gradient Compression: Reducing the Communication Bandwidth for Distributed Training