范德良,周佳煊,张振华作者

Yarn已过时!Kubeflow实现机器学习调度平台才是未来

机器学习,特别是深度学习,在蘑菇街这样的电商平台有大量实际业务的落地场景,比如搜索推荐、图像算法、交易风控反作弊等等。随着业务的快速发展,之前已有的基于 Yarn 的调度平台已经无法满足大规模机器学习的计算需求,因此我们在 2018 年和算法工程团队一起建设了基于 Kubeflow 和 Kubernetes 的分布式机器学习平台,并深入到业务层面进行分布式改造,并且从 Kubernetes、Tensorflow 和业务等多个层面进行了一系列的性能调优。

背    景

随着机器学习人工智能的迅猛发展,业界出现了许多开源的机器学习平台。由于机器学习大数据天然的紧密结合,基于 Hadoop Yarn 的分布式任务调度仍是业界主流,但是随着容器化的发展,Docker + Kubernetes 的云原生组合,也展现出了很强的生命力。

表 1. 互联网业界机器学习平台架构对比

痛    点

在建设分布式训练平台的过程中,我们和机器学习的各个业务方,包括搜索推荐、图像算法、交易风控反作弊等,进行了深入沟通,调研他们的痛点。从中我们发现,算法业务方往往专注于模型和调参,而工程领域是他们相对薄弱的一个环节。建设一个强大的分布式平台,整合各个资源池,提供统一的机器学习框架,将能大大加快训练速度,提升效率,带来更多的可能性,此外还有助于提升资源利用率。

痛点一:对算力的需求越来越强烈

算力代表了生产力深度学习在多个领域的出色表现,给业务带来了更多的可能性,同时对算力提出了越来越高的要求。深度学习模型参数的规模陡增,迭代的时间变的更长,从之前的小时级别,变成天级别,甚至月级别。以商品推荐为例,面对几亿的参数,近百亿的样本数量,即使采用 GPU 机器,也需要长达一个星期的训练时间;而图像业务拥有更多的参数和更复杂的模型,面对 TB 级的训练样本,单机场景下往往需要长达近一个月的训练时间。

再者,机器学习具有试错性非常强的特点,更快的训练速度可以带来更多的尝试,从而发掘更多的可能性。Tensorflow 从 0.8 版本开始支持分布式训练,至今为止,无论高阶还是低阶的 API,对分布式训练已经有了完善的支持。同时,Kubernetes 和 Hadoop 等具有完善的资源管理和调度功能,为 Tensorflow 分布式训练奠定资源层面的基础。

Tensorflow On Yarn 和 Tensorflow On Spark 是较早的解决方案,奇虎 360Xlearning 也得到众人的青睐。而基于 Kubernetes 的 kubeflow 解决了 Yarn 的痛点,展现出旺盛的生命力。

上述方案无一例外的将各个部门分散的机器纳入到统一的资源池,并提供资源管理和调度功能,让基于 Excel 表的资源管理和人肉调度成为过去,让用户更专注于算法模型,而非基础设施。在几十个 worker 下,无论是 CPU 还是 GPU 的分布式训练,训练速度都能得到近乎线性的提升,将单机的训练时间从月级别缩短到一天以内,提升效率的同时也大大提升了资源利用率。

蘑菇街早期的业务方往往独立维护各自团队的 GPU 机器“小池子”,机器的资源分配和管理存在盲区,缺乏统一管理和调度。GPU 的资源存在不均衡和资源利用率低下的问题。事实上,大数据团队之前已经将 CPU 类型的训练任务接入了 Xlearning,尝到了分布式训练的甜头,但也发现一些问题:

  1. 公司目前的 Yarn 不支持 GPU 资源管理,虽然近期版本已支持该特性,但存在稳定性风险。

  2. 缺乏资源隔离和限制,同节点的任务容易出现资源冲突。

  3. 监控信息不完善。在发生资源抢占时,往往无法定位根本原因。

  4. 缺少弹性能力,目前资源池是静态的,如果能借助公有云的弹性能力,在业务高峰期提供更大的算力,将能更快的满足业务需求。

痛点二:人肉管理的成本很高

业务方反馈的第二大问题是人肉管理的成本问题。人肉化的管理主要包含了部署和训练任务管理两大方面。

 人肉部署

一个典型的场景是:团队内的成员共享一批机器,每次跑训练任务前,用户手动登陆机器,下载代码,安装对应的 Python 包,过程繁琐且容易出现安装包版本的冲突。

由于不同的训练任务对 Python 的版本和依赖完全不同,比如有些模型使用 Python 2.7,有些使用 Python 3.3,有些使用 TensorFlow 1.8,有些使用 TensorFlow 1.11 等等,非常容易出现依赖包冲突的问题。虽然沙箱能在一定程度上解决这问题,但是也带来了额外的管理负担。

此外,不同 GPU 机型依赖的 Nvidia 驱动也不同,较新的卡,比如 V100 所依赖的版本更高。人肉部署还需要管理和维护多个不同的驱动版本。

 训练任务管理

人肉启动训练任务时,需要手动查看 / 评估资源的剩余可用情况,手动指定 PS 和 Worker 的数量,管理配置并进行服务发现。这些都给业务方带来了很大的负担。

 解决的思路

Docker 和 Kubernetes 很好地解决了人肉管理的问题:

  1. 部署:借助 Docker 良好的隔离性,各个容器的文件系统互不影响,将训练任务和驱动程序制作成镜像,避免了多次安装的繁琐。此外 Kubernetes 提供了服务发现功能,简化了分布式的部署。

  2. 训练任务生命周期管理:Kubernetes 提供了生命周期管理的 API,用户基于 API 即可一键式完成训练任务的增删改查,避免人工 ssh 的各种繁琐操作,可以大幅提升用户体验和效率。

痛点三:监控的缺失

监控也是分布式训练重要的一环,它是性能调优的重要依据。比如在 PS-Worker 的训练框架下,我们需要为每个 PS/Worker 配置合适的 GPU/CPU/Memory,并设置合适的 PS 和 Worker 数量。如果某个参数配置不当,往往容易造成性能瓶颈,影响整体资源的利用率。比如当 PS 的网络很大时,我们需要增加 PS 节点,并对大参数进行 partition;当 worker CPU 负载过高时,我们应该增加 Worker 的核数。

早期版本的 Hadoop 和 Yarn 并不支持 GPU 的资源可视化监控,而 Kubernetes 已拥有非常成熟监控方案 Prometheus,它能周期采集 CPU,内存,网络和 GPU 的监控数据,即每个 PS/Worker 的资源使用率都能得到详细的展示,为优化资源配置提供了依据。事实上,我们也是通过监控信息为不同的训练任务分配合适的资源配置,使得在训练速度和整体的吞吐率上达到一个较好的效果。

痛点四:资源隔离较弱

早期的机器学习平台基于 Yarn 的 Angel 和 XLearning,由于 Yarn 缺乏对实例之间的资源隔离,我们在内存,网络,磁盘等均遇到不同程度的问题。

由于 Yarn 没有对任务的内存进行隔离,所以,业务方常常因对内存资源估计不准而导致 worker 的进程 OOM。由于所有的进程都共用宿主机的 IP,很容易造成端口冲突,此外磁盘 IO 和网络 IO 也很容易被打爆。

表 2. Hadoop Yarn 和 Kubernetes 的横向对比

Kubeflow 及核心组件

Kubeflow 是由 Google 等公司于 2017 年推出的基于 Kubernetes 的开源项目,它支持常见的机器学习框架。

Kubeflow 简介

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable.

Kubeflow 旨在支持多种机器学习框架运行在 Kubernetes 之上,比如 Tensorflow, Pytorch, Caffe 等常见框架。它包含了 operator、pipeline、超参数调优、serving 等诸多模块。它通过提供对应的 operator,基于 Kubernetes 的 Pod/headless Service 等基础资源为框架提供与之相配的更高层次的资源。比如 tf-operator 为 Tensorflow 提供了 job 维度的生命周期管理能力,以满足 Tensorflow 分布式训练的资源和拓扑需求,达到了一键式部署 Tensorflow 训练任务的效果。

Kubeflow 包含如下 operator,分别对应主流的分布式计算框架。蘑菇街主要采用了 kubeflow 中的 tf-operator,来实现对机器学习任务的统一管理。

图 1. Kubeflow 所支持的主流分布式计算框架

Distributed Tensorflow

蘑菇街业务方使用的计算框架主要是 Tensorflow,因此有必要先介绍一下 Tensorflow 的分布式训练,Tensorflow 支持如下三种分布式策略:

  • MirroredStrategy:适用于单机多卡的训练场景,功能有限,不在本文讨论范围内。

  • ParameterServerStrategy:用于多机多卡场景,主要分为 worker 节点和 PS 节点,其中模型参数全部存储在 PS 节点,worker 在每个 step 计算完梯度后向 PS 更新梯度,蘑菇街当前使用这种方案。

  • CollectiveAllReduceStrategy:用于多机多卡场景,通过 all-reduce 的方式融合梯度,只需要 worker 节点,不需要 PS 节点,从另外一个角度说,该节点既充当 worker 角色,又充当 PS 角色。该方案是带宽优化的,具有性能好,可扩展性强的特点,是 Tensorflow 推荐的未来方向。

以 ParameterServerStrategy 为例,一个分布式训练集群至少需要两种类型的节点:PS 和 worker。由于在训练中需要一个 worker 节点来评估效果和保存 checkpoint,因此单独把该节点作为 chief(或者叫 master) 节点。通常情况下,一个集群需要多个 worker 节点,多个 PS 节点,一个 chief 节点。所有 worker 节点的 CPU/ 内存 /GPU 等资源配置完全相同,所有 PS 节点的 CPU/ 内存等资源配置也相同。从资源拓扑角度出发,如果能够提供一种 Kubernetes 资源,用户可以基于该资源定义 PS/worker/chief 的数量和规格,用户就可以一键式创建分布式集群,大大简化了分布式集群的部署和配置。tf-operator 定义了 TFJob 资源,用户可以借助 tf-operator 在 Kubernetes 上一键拉起分布式训练集群。

从 Tensorflow 分布式训练的使用方式出发,用户在启动每个节点的任务时,需要传入集群所有节点的网络信息。这意味着分布式训练集群的每个节点需要预先知道所有其它节点的网络地址信息,即要求服务发现功能。tf-operator 基于 Kubernetes headless service,完美的提供了服务发现功能,无需用户再手工指定 PS/Worker 的 IP 信息,极大的降低了用户的部署成本。

图 2. Tensorflow 分布式训练的 ClusterSpec 配置

落地实践

图 3. 基于 Kubernetes 的机器学习基础平台总体架构

主要包含了以下几部分:

Tensorflow 生命周期管理 (tf-operator)

在部署 tf-operator 之后,首先需要在 Kubernetes 中创建对应的 TFJob CRD,之后就可以创建 TFJob 资源了。

在如下的样例中,我们定义了一个具有 10 个 worker,4 个 ps,1 个 chief 的分布式训练集群。从 TFJob 参数不难发现,它对 ParameterServerStrategy 和 CollectiveAllReduceStrategy 这两种策略方式都支持,只是在 CollectiveAllReduceStrategy 场景下,无需要设置 PS 资源。

apiVersion: "kubeflow.org/v1alpha1"
kind: "TFJob"
metadata:
 name: "example-job"
spec:
 replicaSpecs:
   - replicas: 1
     tfReplicaType: CHIEF
     template:
       spec:
         containers:
           - image: gcr.io/tf-on-k8s-dogfood/chief_sample:latest
             name: tensorflow
         restartPolicy: OnFailure
   - replicas: 10
     tfReplicaType: WORKER
     template:
       spec:
         containers:
           - image: gcr.io/tf-on-k8s-dogfood/worker_sample:latest
             name: tensorflow
         restartPolicy: OnFailure
   - replicas: 4
     tfReplicaType: PS
     template:
       spec:
         containers:
           - image: gcr.io/tf-on-k8s-dogfood/ps_sample:latest
             name: tensorflow

Tf-operator 启动后,通过 list-watch 不断的监听 TFJob 资源相关事件,当收到创建 TFJob 事件时,tf-operator 依次创建 PS/Worker/Chief(Master) Replica 资源。以 PS Replica 为例,根据 replicas 数量依次创建等同数量的 pod,并为每个 pod 创建 headless service。此外,它还生成 TF_CONFIG 环境变量,这个环境变量记录了所有 pod 的域名和端口,最终在创建 pod 时候注入到容器中。

图 4. tf-operator 的配置示例

任务调度 (kube-batch)

通过引入 kube-batch,满足了业务方对批量任务调度的需求。没有采用 Kubernetes 默认的调度器,主要是基于以下两点考虑:

  1. GANG scheduling:Kubernetes 默认的调度器是以 pod 为粒度的,并不支持 GANG scheduling。机器学习的训练任务要求集群保持一个整体,要么所有的 pod 都能成功创建,要么没有一个 pod 能被创建。试想资源处于临界状态时,如果采用默认的调度调度一个分布式训练集群,则会导致部分节点因资源不足而无法成功调度,那些成功创建的 pod 空占用资源,但是无法进行训练。

  2. 任务排队:Kubernetes 默认的调度器无法提供队列调度的功能,而不会像 Hadoop 任务那样进行排队。而面向机器学习 / 大数据 /HPC 的批量任务调度,往往要求系统能维护一个或多个队列,进行任务排队。当任务结束并且释放资源后,后续的任务可以继续执行。

Kube-batch 目前是 Kubernetes SIGs 旗下的一个孵化项目,是一个运行在 Kubernetes 上面向机器学习 / 大数据 /HPC 的批调度器(batch scheduler),它支持以 Pod Group 为单位进行资源调度,并支持 preempt 和 priority。对于暂时无法满足资源条件的 Pod,在 Kubernetes 中会处于 pending 状态,直到资源释放从而继续执行。

Kube-batch 的基本流程如下图,它通过 list-watch 监听 Pod, Queue, PodGroup 和 Node 等资源,在本地维护一份集群资源的全局缓存,依次通过如下的策略(reclaim, allocate, preemption,predict) 完成资源的调度

图 5. kube-batch 基本流程

图 6. kube-batch 工作流程

kube-batch 旨在通过配置策略,提供 gang scheduling 的调度能力,由于是基于 queue 的调度思想,kube-batch 对机器学习大数据任务的调度具有很大的潜力。

图 7. 蘑菇街的使用姿势

由于 kube-batch 对任务的 actions 有四种,可以根据自身的业务特点,指定只使用其中的一种或者多种:如果简单的分配,使用 allocation 即可;如果资源存在碎片,让调度器能够感知并重新分配,可以将 allocation 与 backfill 结合起来使用。如此既可满足业务的调度需求,又可以在一定程度上提升调度性能。

认证和授权(Dex)

我们引入了由 CoreOS 研发的 dex 组件,并嵌入到我们的 SDK 中,实现了与公司 LDAP 的对接。我们将 Kubernetes 中的 namespace 映射成不同的应用组,应用的负责人会自动授予(Rolebinding)管理员的角色(Role),同时针对一些特权用户还会创建 clusterRole 及 clusterRolebinding,方便这些特权用户访问某些需要高级权限的 API(如查询 node 信息等)。

图 8. Dex 认证流程

图 9. Dex 授权流程

多租户的隔离性

平台需要接入多个不同的业务方,自然需要考虑多租户间的隔离性。我们利用 Kubernetes 提供的 resource quota,以 namespace 为单位对资源进行分配。

$ kubectl get resourcequota --all-namespaces
NAMESPACE                        NAME                AGE
default                          compute-resources   73d
tinyplus-docker-algo-anticheat   compute-resources   74d
tinyplus-docker-algo-image       compute-resources   74d
tinyplus-docker-algo-search      compute-resources   74d
tinyplus-docker                  compute-resources   74d

图 10. 多租户下的资源配额

性能调优

这里介绍一下蘑菇街在分布式机器学习调优的一些经验,主要分为 Kubernetes 层面、Tensorflow 层面和业务层面的一些调优。

Kubernetes 层面调优

CPUShare VS CPUSet

以商品推荐常用的 wide and deep 模型为例,该模型采用 CPU 资源进行训练,宿主机的规格为 80C256G。

从直觉上说,训练本质上是大量的矩阵运算,而矩阵运算在内存地址空间具有良好连续性的特点。若充分利用 CPU cache,将有助于提升 cache 的命中率,最终加快训练速度。Kubernetes 从 1.8 开始支持 CPU Manager 特性,该特性支持对于 Guaranteed 类型的 pod,采用 CpuSet 为 Pod 分配独占的 CPU core。在相同训练任务下,对比 CpuSet 和 CpuShare 对训练速度的影响,发现在 worker CPU 核数较少的情况下,CpuSet 的性能远远超过 CpuShare。

图 11. CpuSet 和 CpuShare 性能对比(Y 轴数值越大越好)

虽然 Guaranteed 类型的 Pod 牺牲了资源弹性,但是 CpuSet 带来的性能收益要高于弹性带来的收益。即使对 CpuShare 容器不设置 cpu limits,当跑满容器的 CPU 资源时,相同 cpu requests 下,CpuSet 容器的性能依旧比 CpuShare 的性能高出 20% 以上。

在 kubelet 中开启 CPU Manaer 特性的配置参数如下

--feature-gates=CPUManager=true
--cpu-manager-policy=static
--cpu-manager-reconcile-period=5s
--kube-reserved=cpu=500m

 Pod Affinity

PS/Worker 训练框架下,PS 节点作为中心节点,网络流量往往非常大,容易把带宽跑满。通过 Pod AntiAffinity 将所有 PS 节点尽可能打散到不同的宿主机上,从而分摊网络流量。

podAntiAffinity:
     preferredDuringSchedulingIgnoredDuringExecution:
     - weight: 100
       podAffinityTerm:
         labelSelector:
           matchExpressions:
           - key: tf-replica-type
             operator: NotIn
             values:
             - ps
         topologyKey: kubernetes.io/hostname

 设置合适的资源配比

不同模型的计算量和参数各不相同,因此针对每个模型都应该设置一个合适的 PS/Worker 的规格和数量。在监控完善的条件下,可以根据监控数据分析瓶颈,调整实例的规格和数量,使得整体的训练速度和平台吞吐量能达到较好的水平。

 Kube-batch 调度

由于 kube-batch 默认开启“reclaim, allocate, backfill, preempt”四种 actions,导致每次调度时轮询周期较长,通过配置 actions 为 allocate 一种可以提高 30% 的调度效率。

Tensorflow 层面调优

Tensorflow 的调优主要参考了官网文档。

 线程数

由于 sysconf 系统调用等隔离性的问题,容器观察到的 CPU 信息往往是宿主机的。Tensorflow 默认的线程数为 CPU 核数,如此情况下,Tensorflow 创建的线程数远远超过实际分配到的 CPU 核数。同样以 wide and deep 模型为例,通过保持与 cpu limit一致的线程数,上下文切换降低约 40%,训练速度提升约 5%。

config = tf.ConfigProto()
config.intra_op_parallelism_threads = cpu_limit_cores
config.inter_op_parallelism_threads = cpu_limit_cores
tf.Session(config=config)

业务层面调优

 Partition

在某次训练中发现 PS 流量节点的分布不均匀,其中某个 PS 节点的流量非常大,而其它 PS 节点的流量相对较低。通过分析 timeline.json 发现某个 embedding 向量非常大,所以通过 partition,将该 tensor 分散到不同的 PS 节点上,从而避免了某个 PS 节点成为瓶颈。

图 12. 通过 partition 将 tensor 打散到不同的 PS 节点

partitioner = tf.fixed_size_partitioner(ps_number, axis=0)
with tf.variable_scope("emb_layer", partitioner= partitioner) as scope:
   ...
 Adam 优化器

由于 Adam 优化器会更新所有参数的梯度,所以在大 embedding 向量下,如果采用 adam 优化器,会大大增加计算量,严重影响训练速度。因此建议采用 Lazy_Adam_Optimizer 或者 Adadelta 优化器

总结和体会

目前上述基于 Kubernetes 的机器学习平台已经在生产环境为多个业务方提供了服务。建设这套平台的过程,也是我们探索的过程。以下我们总结了一些还不尽如人意的地方,以及我们对未来的展望。

tf-operator

从落地的情况来看,tf-operator 的功能能满足基本的要求,稳定性较高。但是在故障恢复稍有欠缺,对于 pod 级别的故障,依赖 kubelet 来恢复;对于 node 级别的故障,目前还不支持故障恢复。分布训练下,故障概率随着 worker 数量和训练时间的增加而增加。worker 作为无状态节点,故障恢复既是可行的,也是非常有必要的。

kube-batch

目前 kube-batch 功能薄弱,成熟度有待商榷。比如 kube-batch 只有 predict 功能,没有 priority 功能。并且 predict 功能也非常薄弱,仅支持部分基础的 filter,比如 PodMatchNodeSelector, PodFitsHostPorts 以及基本的资源调度等。特别是 PodAffinity 特性,对于 PS-Worker 架构非常有用,因为 PS 节点的网络流量非常大,所以需要 PS 节点之间反亲和,将各个 PS 节点分散。此外,kube-batch 也不支持多任务之间依赖关系。

Kube-batch 的落地效果差强人意,社区的维护力度较低。除了功能薄弱以外,我们也碰上了诸多的问题,处于勉强可用状态。我们建议可将 pod 群维度的资源判断功能放到上层,只有当空闲资源满足创建整个分布式训练集群时,再将请求发送给 Kubernetes,由 Kubernetes 默认的调度器完成调度,当然,这种方式也存在一些缺点。

GPU 虚拟化

目前 GPU 相关的监控、隔离性以及更细粒度的调度,仍然是业界的痛点问题。Nvidia 提供的 GPU 虚拟化方案需要收取高额的 Lincense 费用,目前业界还没有免费的 GPU 虚拟化方案。

在实际的业务场景中,一些业务的 GPU 使用率并不高,但以虚拟机或者容器方式运行时往往会独占一块 GPU 卡,虽然可以通过设置 CUDA_VISIBLE_DEVICES 来实现多个容器共享一块 GPU 卡,但任务之间的隔离性是无法保证的。

另外,Kubernetes 进行 GPU 资源分配时,默认还不感知 GPU 的 Topology,而不同分配的策略,对训练的性能也会产生很大的影响。YARN 和 Kubernetes 开源社区都在努力增强这块的调度能力。

Kubeflow 展望

Kubeflow 是目前基于 Kubernetes 的主流机器学习解决方案,它抽象了和机器学习相关的 PS-Worker 模型,实现了一套 pipeline 的工作流,支持超参数训练和 Jupyter notebooks 集成等能力。

由于 Kubeflow 解决了基于 Yarn 的机器学习平台的痛点,同时容器化越来越普及。基于 Kubernetes 这样大规模的企业级容器平台,将会是未来的方向,相信 Kubeflow 在 2019 年将会有更好的发展。

作者介绍

范德良,花名揽胜,毕业于浙江大学,专注于 OpenStack 和 Kubernetes,在私有云和公有云等基础设施领域有多年建设经验和维护经验。目前正基于 Kubeflow 建设蘑菇街分布式机器学习平台,服务算法,图像,风控等业务。

周佳煊,花名楚河,前 HPE 软件部高级技术顾问,主要服务于大型公有云厂商,并有多年基础架构运维开发经验,对 Cloud Native 领域有深刻理解,目前任职于蘑菇街 PaaS 平台,结合腾讯 TKE 打造服务于蘑菇街全站业务的 PaaS 平台。

张振华,花名郭嘉,蘑菇街 PaaS 平台负责人,毕业于浙江大学软件学院,10 余年软件研发和技术管理经验,曾在英特尔、思科等公司工作。从零开始带领团队研发了蘑菇街的 IaaS 和 PaaS 平台,在 Docker、Kubernetes、DevOps、Kubeflow、Serverless 等领域拥有丰富经验。

理论机器学习Kubeflow
5
相关数据
英特尔机构

英特尔是计算创新领域的全球领先厂商,致力于拓展科技疆界,让最精彩体验成为可能。英特尔创始于1968年,已拥有近半个世纪产品创新和引领市场的经验。英特尔1971年推出了世界上第一个微处理器,后来又促进了计算机和互联网的革命,改变了整个世界的进程。如今,英特尔正转型成为一家数据公司,制定了清晰的数据战略,凭借云和数据中心、物联网、存储、FPGA以及5G构成的增长良性循环,提供独到价值,驱动日益发展的智能互联世界。英特尔专注于技术创新,同时也积极支持中国的自主创新,与产业伙伴携手推动智能互联的发展。基于明确的数据战略和智能互联全栈实力,英特尔瞄准人工智能、无人驾驶、5G、精准医疗、体育等关键领域,与中国深度合作。面向未来,英特尔致力于做中国高价值合作伙伴,在新科技、新经济、新消费三个方面,着力驱动产业协同创新,为实体经济增值,促进消费升级。

https://www.intel.com/content/www/us/en/company-overview/company-overview.html
相关技术
深度学习技术

深度学习(deep learning)是机器学习的分支,是一种试图使用包含复杂结构或由多重非线性变换构成的多个处理层对数据进行高层抽象的算法。 深度学习是机器学习中一种基于对数据进行表征学习的算法,至今已有数种深度学习框架,如卷积神经网络和深度置信网络和递归神经网络等已被应用在计算机视觉、语音识别、自然语言处理、音频识别与生物信息学等领域并获取了极好的效果。

数据分析技术

数据分析是一类统计方法,其主要特点是多维性和描述性。有些几何方法有助于揭示不同的数据之间存在的关系,并绘制出统计信息图,以更简洁的解释这些数据中包含的主要信息。其他一些用于收集数据,以便弄清哪些是同质的,从而更好地了解数据。 数据分析可以处理大量数据,并确定这些数据最有用的部分。

Adadelta 优化器技术

Adadelta优化器是Adagrad的延伸,试图减少其过激的、单调降低的学习率。 Adadelta不积累所有过去的平方梯度,而是将积累的过去梯度的窗口限制在一定的大小。

机器学习技术

机器学习是人工智能的一个分支,是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、计算复杂性理论等多门学科。机器学习理论主要是设计和分析一些让计算机可以自动“学习”的算法。因为学习算法中涉及了大量的统计学理论,机器学习与推断统计学联系尤为密切,也被称为统计学习理论。算法设计方面,机器学习理论关注可以实现的,行之有效的学习算法。

感知技术

知觉或感知是外界刺激作用于感官时,脑对外界的整体的看法和理解,为我们对外界的感官信息进行组织和解释。在认知科学中,也可看作一组程序,包括获取信息、理解信息、筛选信息、组织信息。与感觉不同,知觉反映的是由对象的各样属性及关系构成的整体。

调度技术

调度在计算机中是分配工作所需资源的方法。资源可以指虚拟的计算资源,如线程、进程或数据流;也可以指硬件资源,如处理器、网络连接或扩展卡。 进行调度工作的程序叫做调度器。调度器通常的实现使得所有计算资源都处于忙碌状态,允许多位用户有效地同时共享系统资源,或达到指定的服务质量。 see planning for more details

人工智能技术

在学术研究领域,人工智能通常指能够感知周围环境并采取行动以实现最优的可能结果的智能体(intelligent agent)

参数技术

在数学和统计学裡,参数(英语:parameter)是使用通用变量来建立函数和变量之间关系(当这种关系很难用方程来阐述时)的一个数量。

超参数技术

在机器学习中,超参数是在学习过程开始之前设置其值的参数。 相反,其他参数的值是通过训练得出的。 不同的模型训练算法需要不同的超参数,一些简单的算法(如普通最小二乘回归)不需要。 给定这些超参数,训练算法从数据中学习参数。相同种类的机器学习模型可能需要不同的超参数来适应不同的数据模式,并且必须对其进行调整以便模型能够最优地解决机器学习问题。 在实际应用中一般需要对超参数进行优化,以找到一个超参数元组(tuple),由这些超参数元组形成一个最优化模型,该模型可以将在给定的独立数据上预定义的损失函数最小化。

TensorFlow技术

TensorFlow是一个开源软件库,用于各种感知和语言理解任务的机器学习。目前被50个团队用于研究和生产许多Google商业产品,如语音识别、Gmail、Google 相册和搜索,其中许多产品曾使用过其前任软件DistBelief。

网络流技术

在图论中,网络流(英语:Network flow)是指在一个每条边都有容量(capacity)的有向图分配流,使一条边的流量不会超过它的容量。通常在运筹学中,有向图称为网络。顶点称为节点(node)而边称为弧(arc)。一道流必须匹配一个结点的进出的流量相同的限制,除非这是一个源点(source)──有较多向外的流,或是一个汇点(sink)──有较多向内的流。一个网络可以用来模拟道路系统的交通量、管中的液体、电路中的电流或类似一些东西在一个结点的网络中游动的任何事物。

映射技术

映射指的是具有某种特殊结构的函数,或泛指类函数思想的范畴论中的态射。 逻辑和图论中也有一些不太常规的用法。其数学定义为:两个非空集合A与B间存在着对应关系f,而且对于A中的每一个元素x,B中总有有唯一的一个元素y与它对应,就这种对应为从A到B的映射,记作f:A→B。其中,y称为元素x在映射f下的象,记作:y=f(x)。x称为y关于映射f的原象*。*集合A中所有元素的象的集合称为映射f的值域,记作f(A)。同样的,在机器学习中,映射就是输入与输出之间的对应关系。

大数据技术技术

大数据,又称为巨量资料,指的是传统数据处理应用软件不足以处理它们的大或复杂的数据集的术语。

查询技术

一般来说,查询是询问的一种形式。它在不同的学科里涵义有所不同。在信息检索领域,查询指的是数据库和信息系统对信息检索的精确要求

分布式计算技术技术

在计算机科学中,分布式计算,又译为分散式運算。这个研究领域,主要研究分布式系统如何进行计算。分布式系统是一组电脑,通过网络相互链接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。

Jupyter技术

Jupyter Notebook(此前被称为 IPython notebook)是一个交互式笔记本,支持运行 40 多种编程语言。 Jupyter Notebook 的本质是一个 Web 应用程序,便于创建和共享文学化程序文档,支持实时代码,数学方程,可视化和 markdown。 用途包括:数据清理和转换,数值模拟,统计建模,机器学习等等 。

优化器技术

优化器基类提供了计算梯度loss的方法,并可以将梯度应用于变量。优化器里包含了实现了经典的优化算法,如梯度下降和Adagrad。 优化器是提供了一个可以使用各种优化算法的接口,可以让用户直接调用一些经典的优化算法,如梯度下降法等等。优化器(optimizers)类的基类。这个类定义了在训练模型的时候添加一个操作的API。用户基本上不会直接使用这个类,但是你会用到他的子类比如GradientDescentOptimizer, AdagradOptimizer, MomentumOptimizer(tensorflow下的优化器包)等等这些算法。

腾讯机构

腾讯科技股份有限公司(港交所:700)是中国规模最大的互联网公司,1998年11月由马化腾、张志东、陈一丹、许晨晔、曾李青5位创始人共同创立,总部位于深圳南山区腾讯大厦。腾讯由即时通讯软件起家,业务拓展至社交、娱乐、金融、资讯、工具和平台等不同领域。目前,腾讯拥有中国国内使用人数最多的社交软件腾讯QQ和微信,以及中国国内最大的网络游戏社区腾讯游戏。在电子书领域 ,旗下有阅文集团,运营有QQ读书和微信读书。

http://www.tencent.com/
360机构

奇虎360科技有限公司,是中国领先的互联网和手机安全产品及服务供应商。据第三方统计,按照用户数量计算,360是中国领先的互联网安全公司,用户6亿,市场渗透率96.6%;中国领先的移动互联网安全公司,用户数近8亿,市场渗透率近70%;中国领先的浏览器公司之一,活跃用户达到4亿,渗透率超过70%。 360致力于通过提供高品质的免费安全服务,为中国互联网用户解决上网时遇到的各种安全问题。面对互联网时代木马、病毒、流氓软件、钓鱼欺诈网页等多元化的安全威胁,360以互联网的思路解决网络安全问题。360是免费安全的首倡者,认为互联网安全像搜索、电子邮箱、即时通讯一样,是互联网的基础服务,应该免费。为此,360安全卫士、360杀毒等系列安全产品免费提供给中国数亿互联网用户。同时,360开发了全球规模和技术均领先的云安全体系,能够快速识别并清除新型木马病毒以及钓鱼、挂马恶意网页,全方位保护用户的上网安全。

https://www.360.cn/
推荐文章
暂无评论
暂无评论~