目录:

- 前沿

1. 算力需求与供给

1.1 算力需求:模型复杂度

1.2 算力供给:异构硬件计算能力

1.3 问题与优化方法

2. 算法-系统-硬件协同性能优化

2.1 算法优化

2.2 系统优化:以GPU优化为例

2.3 硬件升级:以含光NPU为例

2.4 性能结果

- 总结与展望

▐  前言

在全球数字化时代,数字广告产业举足轻重,数字广告占广告整体支出的比重逐年上升,2019年数字广告支出首次超过传统广告;全球数字广告市场规模超过3000亿美元[1],中国数字广告市场规模超过700亿美元[2]。对于国内外头部互联网公司,数字广告收入在整体营收中均占很大比重。与传统广告不同,数字广告的收入与点击率和转化率等投放效果指标直接相关,因此基于深度学习的广告精准投放是一个价值很高的问题。

▐ 1. 算力需求与供给

1.1 算力需求:模型复杂度

为满足在线服务的延时约束,深度学习计算一般需要CPU与GPU/NPU等加速器的协同计算,以CPU-GPU单机系统为例(如图1.1),服务能力(QPS)可以简单表示为如下公式:

其中,QPS由请求并行度(parallelism)和延时(latency)共同决定,α1和α2表示并发效率,最优时多并发与单并发延时相同,最差时多并发等同于串行计算;对于每个请求而言,延时为CPU和GPU计算时间的总和。

图1.1 CPU-GPU单机系统[3]

结合上述公式,我们对广告深度学习在线服务做两点说明:

(1) 在线系统的优化目标是 latency-bounded QPS。 如图1.2,请求并行执行(parallelism > 1)在一般情况下(cache等共享资源竞争不太激烈时)能有效提高资源利用率(例如CPU和GPU利用率),但并行执行时每个请求的延时也将上涨。由于在线系统有比较严格的延时限制,因此服务能力不能通过资源利用率简单换算,需要在延时约束下进行评估。当系统各种资源利用率均较低,延时是制约因素时,优化或适当放宽延时可以有效提升系统服务能力。

图1.2 多并发延时和资源利用率

(2) 模型复杂度由计算量和计算密度共同决定。 CPU/GPU的计算时间主要由数据移动效率(包括CPU/GPU内存读写、PCIe数据传输、GPU kernel launch)和计算效率(CPU/GPU各种计算单元的速度)决定。需要注意的是,FLOPs是最经常被用作评估模型复杂度的指标,但FLOPs仅直接影响compute_cycles;即使是compute_cycles,FLOPs一般也只能用于评估MatMul/Conv等计算密集型算子的复杂度,对于访存密集型算子没有指导意义。因此,FLOPs只是众多计算复杂度指标之一,不能直接换算服务能力。

对于GPU等加速器,计算密集型算子的性能(例如每秒浮点计算次数,FLOPS)增长很快,这使得另一个方面的性能优化越来越重要:提升计算密度,即在模型FLOPs相当的情况下减少访存量,减少kernel个数,提高FLOPs/byte或FLOPs/kernel_launch。例如:尽量减少使用tensor变换算子(Concat/Split/Transpose等算子)、减少Tile/Gather等算子导致的中间结果内存读写膨胀、尽量增大每次请求的batch size等。

1.2 算力供给:异构硬件计算能力

在计算需求增长的同时,芯片制造工艺和计算机体系结构推动计算机硬件(处理器、内存和外存系统、网络互联设备)不断推陈出新[3]。这里仅简述与深度学习计算最直接相关的处理器和内存系统的近期发展趋势,主要体现为三个方面:

(1) 处理器专用化和异构化成为趋势。 近年来CPU性能提升速度无法匹配应用日益增长的计算需求。为大幅提升典型应用的性能和效率(性价比、能效比等),处理器向专用化方向发展(例如针对深度学习的专用处理器)。伴随着处理器专用化的趋势,计算机系统中集成的处理器类型日渐丰富,形成异构处理器计算机系统。以阿里妈妈广告系统为例,为满足不同应用和场景的需求,CPU、GPU和ASIC均有不同程度的使用。

(2) 体系结构创新推动数值计算性能快速提升。 处理器数值计算性能提升主要源自两方面:芯片制造工艺的持续进步,芯片内晶体管数目逐步增长;体系结构设计根据应用需求优化晶体管使用,例如为典型应用/算法增加专门处理单元(例如深度学习专用处理器,以及针对深度学习中常见GEMM运算,NVIDIA GPU中增加的TensorCore、Intel CPU中增加的AVX512/AMX)。其中,后者对数值计算性能的提升尤为显著,例如TensorCore单元大幅提高NVIDIA GPU的计算能力(图1.3)。

图1.3 NVIDIA Tesla GPU浮点/整数计算性能

(3) 数据访问带宽决定计算性能的发挥。 内存数据读写的速度无法匹配处理器的计算速度限制了应用性能的提升(memory wall),为缓解这个问题目前主要有两种思路:在处理器内部集成更大规模的SRAM,减少对速度相对较慢的DRAM的访问,这在深度学习专用处理器中广泛应用;通过2.5D/3D封装技术提升DRAM带宽,例如高带宽存储器 (HBM)和混合存储立方体 (HMC),前者在AMD/NVIDIA高端GPU中已有集成。阿里妈妈深度学习计算采用多种异构硬件,这些硬件之间的数据访问带宽差异较大:阿里巴巴自研的AI芯片含光800 NPU集成较大的SRAM,NVIDIA P100/V100S GPU集成HBM/HBM2,数据访问瓶颈相对较小;Intel Skylake/Cacade Lake CPU和NVIDIA T4 GPU的SRAM空间和DRAM带宽相对较小,数据访问瓶颈较大。除内存数据访问外,对于协处理器,跨设备的输入输出和计算指令等数据传输也影响计算性能发挥,例如GPU计算中CPU-GPU数据传输、GPU kernel launch的速度。

表1.1概述了目前阿里妈妈主力深度学习硬件的计算能力,包括数值计算性能(FLOPS/OPS)、DRAM带宽、PCIe带宽、kernel launch throughput。由于硬件本身的差异,不同硬件的性能瓶颈可能不同(表1中粗体数字表示在实际应用中已经/在短期内可能成为瓶颈)。其中,kernel launch throughput通过多线程反复启动空kernel得到,由于软件约束在某些版本docker中P100 GPU无法使用MPS;NPU使用PCIe Gen 4.0,但受限于CPU型号Intel Cascade Lake 8269CY (仅支持PCIe3.0),带宽仅为32GB/s;GPU DRAM带宽通过在kernel中仅进行不同模式的数据访问得到;CPU为two-sockets,DRAM理论带宽为每个socket带宽*2简单估计得到,实测带宽为线上系统关闭NUMA测试结果;GPU实测FLOPS为GEMM结果;CPU FP32 FLOPS为cores * AVX512 * 2 AVX512 units/core * 1.6GHz下估算结果。

表1.1 典型深度学习硬件计算能力

1.3 问题与优化方法

为实现更精准的投放,广告的计算需求在日益增长。以阿里妈妈信息流广告排序模型为例:在DIEN (Deep Interest Evolution Network) [4] 基础上引入基于搜索范式的超长用户行为建模新方法,升级为SIM (Search-based user Interest Model) [5];在SIM基础上引入交叉特征相关内容,升级为CAN (Co-Action Network) [6]。从DIEN到CAN模型,FLOPS增加3x,访存增加3x,输入规模增加4x(以上为粗略估计,具体增长与业务场景有关)。面对迅速增长的算力需求,我们打造了新一代广告深度学习计算引擎XDL-Blaze,算法-系统-硬件密切配合,充分利用硬件能力,掩盖硬件自身的弱点,实现性能目标(latency-bounded QPS)的最大化。

▐ 2. 算法-系统-硬件协同性能优化

2.1 算法优化

我们在广告场景中的算法优化实践大致分为三个方向:(1)模型裁剪,裁剪无用和低贡献结构;(2)近似计算,用近似且轻量的计算结构替换耗时的计算结构;(3)计算压缩,根据数据特点,压缩重复计算。

以算法与工程配合最紧密的计算压缩为例,广告精排模型在训练和推理时输入数据各有特点,训练时由于数据压缩比非常低,所有的输入特征都是展开的;而推理时压缩比就相当可观了,如果对重复数据进行压缩,就可以大幅降低PCIe拷贝量、计算量和访存量。

如图2.1,模型中存在三种计算压缩:

(1)推理时每个batch只包含一个user,因此可以将user类的特征从候选广告的batch size压缩为1,利用TensorFlow算子的broadcast语义完成计算后,在最后进入全连接前Tile到ad batch size;

(2)用户长历史类目与候选广告的类目一一对应,候选广告中有多个商品的类目是相同的,因此可以将长历史类目特征压缩到总类目数,然后构造对应的indicator,通过Gather扩展到ad batch size;

(3)每条候选广告对应多个创意,每条创意都是一条待打分的广告,多条创意中广告部分特征是相同的,只有创意相关的少量特征不同,因此可以将创意压缩到广告batch size,然后构造创意的indicator,通过gather扩展到创意batch size。

图2.1 推理计算压缩

user类特征和历史行为类别特征扩展到ad维度,再扩展到创意维度的映射关系如图2.2所示,多级的压缩从多个维度降低了推理模型的计算复杂度,降低模型latency,提高吞吐量。

图2.2 数据展开映射关系

我们可以根据数据特点对推理的计算图进行优化,尽量将数据展开操作延后,计算压缩使每次请求的FLOPS、访存、输入规模均大幅下降,QPS @ T4提升3x。

2.2 系统优化:以GPU优化为例

从1.1节QPS和latency公式可以看到,GPU执行时间由计算效率(计算密集型算子、访存密集型算子效率)、kernel launch和PCIe拷贝决定,我们的优化也针对这几个方面展开。

2.2.1 计算密集型算子优化

广告场景中GEMM是最重要的计算密集型算子,对于常见的GEMM规模,cuBLAS一般情况下能提供性能较优的实现,但是在工程中遇到一些特殊规模的 GEMM,cuBLAS提供的性能不尽人意。例如在相同的 FLOPS 下,M 与 K、N 相差较大的长条型 GEMM 与匀称型GEMM相比,cuBLAS GEMM 计算时间增加了3倍。对于广告模型中常见的长条形 GEMM 规模,我们用 TVM 自动生成更优的 kernel,与 cuBLAS 库函数相比有 7x 以上的加速比。

此外,我们针对广告模型在 GPU FP32+FP16 混合精度上做了一些工作,包括精度评估和使用 TensorCore 加速 GEMM,并且在 FP32 和 FP16 之间精度转换的开销上做了一些优化。由于 GEMM 计算效率的提升以及 FP16 带来的访存减少,FP32+FP16 混合精度取得了 1.3-2x 的加速比。

2.2.2 OP/Kernel Fusion

对于广告模型推理场景而言,GPU计算密集型算子的性能增长很快,这就需要有足够的数据喂给GPU计算单元,但大多的情况下,访存和 kernel launch 更容易先到达瓶颈。为了降低访存和 kernel launch 开销,我们做了大量代码生成方面的工作,主要有两个方面:基于 XLA/MLIR 等编译器进行 Kernel fusion 和针对访存热点的pattern fusion。代码生成优化在降低访存开销的同时,也会大幅减少kernel个数,因此kernel launch开销也会降低。

在定向广告场景中我们的自动Kernel fusion工作主要在TensorFlow XLA层面展开,包括两个方面工作。一方面是编译策略优化,针对业务场景中XLA生成的指令执行效率比较低的策略进行调优。另一方面是解决XLA不支持dynamic shape的问题,一种解决方法是分桶warmup:将输入规模归类划分,padding到多个固定shape ;另一种解决方法是AutoPadding:在XLA cluster前后自动插入padding/unpadding OP,自适应的调配桶大小。

通过深入分析广告模型中访存热点,有些情况无法通过编译优化自动融合。针对这个情况我们实现了更加高效的算子融合来优化访存热点,下面以Gather和BatchMatMul融合为例说明。我们在SIM模型的工程实践中,发现一个典型的访存热点:Gather+BatchedMatmul,Gather和BatchedMatmul之间存在大量的global memory读写操作,如图2.3所示。其中,Gather和BatchedMatmul的memory读写规模总共为12.4MB;SIM模型中有6个相同的结构,这些memory访问显著增加了访存压力,例如当QPS=1000时,总共消耗约74.4GB/s的访存带宽。

图2.3 Gather+BatchedMatmul优化

为降低带宽压力,我们通过kernel fusion将Gather + BatchedMatmul合并成一个自定义OP(IndicatorMatMul),减少96%的global memory读写。IndicatorMatMul的语义如下:Gather操作在这里的本质含义,实际上是将BatchedMatmul左边a矩阵的batch维度batch_a升到跟右边b矩阵batch_b对齐,进行batch_b个MatMul计算;cuBLAS的gemmBatched函数,可以输入一组a矩阵的指针和b矩阵指针,因此我们将Gather(a)简化为指针计算,将计算好的指针直接送往gemmBatched函数,完成Gather + BatchedMatmul的计算。这个优化可以大幅提升latency-bounded QPS(例如,使SIM模型10ms latency约束下的QPS提升2.6x)。

2.2.3 调度和开销优化

性能优化是个复杂的系统工程,计算优化只是其中的一部分。除计算优化外,还需要实现各种硬件高效协同,以充分压榨硬件潜力,在有限的预算下保证服务质量。系统层面上,我们一方面降低系统各部分开销,比如优化TensorFlow图执行器 (executor)的线程调度,避免线程上下文频繁切换,从而降低高负载压力下的长尾延时;另一方面提高异构加速器的并发度,从而提高资源利用率,下面从这个角度展开说明。

与面向大batch的训练任务不同,在线预估服务中计算一般有两个特点:单次请求的batchsize小,单个服务的并发规模大。这导致GPU kernel执行时间一般较短,无法充分掩盖kernel launch开销,因此需要优化kernel launch效率。针对这个问题,我们进行了两个优化:多stream并发launch kernel,实现stream间相互overlap;使用多CUDA context降低kernel launch的互斥锁开销。

Multi-streams:在线预估场景中,可以通过同时提供多个模型服务,每个模型同时处理多个打分请求,提高资源利用率(尤其是GPU 利用率)。目前,在线预估服务通过在单个进程内启动多个CPU线程实现上述并行执行。但是,在单进程模式下,我们发现使用TensorFlow默认执行选项时,提高并行度并不能显著提升throughput,且CPU和GPU利用率均不高。其原因是:TensorFlow默认不会开启GPU多stream,造成所有并行请求在GPU上均使用单个stream串行执行。另外,TensorFlow多stream的实现也不适合在线预估场景:TensorFlow在stream assignment时,目标是利用多stream实现单个计算图内inter-op的并行,缩短单个计算图的执行时间;这种stream assignment策略导致低效的stream同步,在大多数场景下多stream不能带来性能提升。

为解决这个问题,分析发现:(1) TensorFlow中stream与GPU device一一对应;(2) TensorFlow提供virtual_device选项将一个physical GPU划分成为多个虚拟GPU,每个虚拟GPU有独立的stream。因此,我们开启TensorFlow virtual_devices选项,允许并行的打分请求在不同的virtual GPU和stream上并行执行。注意,更高的并行度需要消耗的更多的GPU device memory(包括存储权值和临时数据的空间消耗);但是device memory空间有限(一般小于16GB),导致在一些场景中device memory成为系统瓶颈。后续需要针对这个问题重点优化。

Multi-contexts:分析广告应用在GPU上的性能时发现:多线程并发launch kernel时,几乎每一次kernel launch均有一次开销较大的获取锁的函数调用(pthread_mutex_lock),极大影响了kernel launch的效率(图2.4)。

图2.4 CUDA runtime/driver mutex开销

与厂商确认上述mutex与CUDA runtime/driver中context [7]相关,mutex与context一一对应,因此我们尝试通过增加context数目减少mutex竞争。我们进行了几组测试(图2.5),在不同contexts数目的情况下,用CPU多线程启动空GPU kernels(不计算直接返回)得到理想情况下的GPU kernel launch throughput。测试结果显示:多contexts可以改善kernel launch throughput,P100、V100S、T4上改善程度递增。基于上述测试,我们修改TensorFlow框架,将每个物理GPU对应一个default context修改为多个contexts,并发任务使用不同的context进行kernel launch从而降低开销。注意这里有两个限制:在目前CUDA runtime/driver的实现中,GPU不能在不同contexts的并发GPU kernel之间spatial sharing(即使单个kernel无法充分利用所有GPU streaming multiprocessor),需要启用CUDA MPS (Multi-Process Service)避免这个限制;目前我们的服务均运行在docker中,P100不支持在某些docker版本中开启MPS。

图2.5 CUDA runtime/driver mutex开销

2.2.4 PCIe拷贝优化

广告模型有数百个embedding特征输入需要从CPU host memory经过PCIe拷贝到GPU device memory,PCIe每次数据传输均会带来额外的开销。我们通过合并琐碎数据减少拷贝次数,PCIe数据传输耗时从4.5ms降低到400us。

2.3 硬件升级:以含光NPU为例

我们在广告场景部署阿里自研AI芯片含光800 NPU。由于其专用低精度计算逻辑,NPU在部分深度学习应用上的性能大幅优于CPU/GPU。但是NPU也存在一些短板:对主流深度学习OP的支持程度弱于CPU/GPU,不利于模型快速迭代,不支持的OP回退到CPU上执行导致额外的数据转换和传输开销;矩阵乘仅支持INT16/INT8低精度运算(模型在部署前需要进行量化),INT16/INT8计算与FP32计算结果存在一定偏差,对一些累积误差较大的结构不适用,部署难度大于CPU/GPU。

为了发挥NPU的算力优势、规避短板,场景和模型的选择非常关键。我们选取粗排模型DQM作为第一个适配场景:这个场景候选广告数多,一次用户请求需要对几千到上万个广告的CTR进行预估,算力消耗占到整个广告系统算力消耗的一半以上;模型主要结构是全连接,GEMM计算占很大比重,适合使用NPU专用计算逻辑,且算子大多能被NPU原生支持,少数特殊OP也能通过简单变换得以支持。

为了适配NPU量化计算模式,需要引入量化流程。量化最简单的做法就是在模型设计/训练阶段固定tensor数值范围,从而省去通过calibration收集tensor数值范围的过程。但是目前广告模型在设计时没有考虑这点,因此我们通过若干在线样本回流到模型量化流程,收集tensor数值范围,计算量化参数。在具体实践中我们发现对于粗排模型量化参数非常稳定,一次calibration的结果可以复用到之后的模型量化。实测DQM模型INT16量化与FP32的误差分布如下(图2.6)。

图2.6 DQM INT16量化与FP32精度对比(1000条样本)

精度对比测试发现,NPU量化前后99%的数值结果相对误差可以控制在1%以内,对广告点击率预估(粗排)的相对序的影响可以忽略,从业务效果上看量化前后的效果持平。

值得注意的是,在真实线上环境中NPU的算力并没有得到充分发挥(仅使用了4个NPU cores中的1个,能力发挥不到25%),其原因在于:embedding计算和NPU输入量化均由CPU完成,随QPS升高CPU利用率先到达瓶颈(约60%);在embedding规模较小的场景,CPU与NPU之间的PCIe带宽先成为瓶颈。这个现象不仅出现在NPU上,随着协处理器算力增强,这个问题将更加普遍。因此,我们后面的优化需要超越模型计算,在整个广告系统层面进行feature-embedding-dense计算的全局优化;另外,与模型计算专用硬件加速类似,也可以考虑针对embedding等短板选择/实现更优的硬件。

2.4 性能结果

图2.7展示了XDL-Blaze对定向主要模型在线上典型batchsize下的性能优化效果。对比不同的硬件:(1)对仅有简单FC结构的DQM模型,NPU与T4/V100S相比有很大的性能优势(约两倍);(2)由于GPU硬件的升级,在SIM和CAN上,P100、T4、V100S的性能递增。对比不同的优化实现:(1)计算优化(子图合并、OP替换等与TensorFlow框架无关的图等价变换)对SIM和CAN可以带来4-5X的加速比,DQM因为其图结构相对简单(只有FC结构)收益不大;(2)除DQM@P100以外,基于定制/自动编译优化和系统优化,XDL-Blaze与社区原生TF1.15+XLA相比,均有2X以上的加速比。

图2.7 DQM/SIM/CAN性能优化效果

为了给后续性能优化或硬件选型/设计提供依据,我们整理了不同模型对不同硬件的使用情况。图2.8展示了DQM、SIM和CAN在不同batchsize下对GPU主要硬件资源的利用率(实际使用量/achievable峰值能力,achievable峰值数据见表1.1)。可以很清楚的看出:在batchsize较小时,P100、V100S、T4存在不同程度的kernel launch瓶颈,其中P100的瓶颈更大;T4则经常遇到GPU显存带宽的瓶颈;三者横向比较,V100S除FLOPS稍显过剩外,整体表现相对更均衡。另外,在V100S上增大batchsize可以在一定程度上缓解kernel launch瓶颈,提高整体硬件利用效率。DQM在NPU上的性能瓶颈相对简单,主要是CPU利用率和PCIe带宽,不在这里详细列出。

图2.8 DQM/SIM/CAN硬件利用效率

▐ 总结与展望

持续的算法创新和业务升级给广告营收带来大幅增长的同时,也给系统能力带来了巨大的挑战,其中以对深度学习引擎计算能力的挑战为甚。针对这个问题,我们打造了新一代广告深度学习计算引擎XDL-Blaze,以充分释放数十万CPU处理器核和数千张GPU/NPU加速卡的计算能力,服务数百万峰值QPS。未来我们要持续通过软硬件协同优化挖掘硬件潜力,例如:针对计算密集型算子尝试INT8/BFLOAT16/TF32/Sparse等低精度/近似计算;针对访存密集型算子实现更激进的kernel fusion。此外,我们需要将广告典型深度学习模型总结为完善的benchmark集合,以全面评估CPU/GPU/NPU等深度学习处理器、以及多种处理器的组合方式,为硬件选型提供科学指导。

[1] Global Digital Ad Spending Update Q2 2020, https://www.emarketer.com/content/global-digital-ad-spending-update-q2-2020

[2] China Digital Ad Spending Update Q2 2020, https://www.emarketer.com/content/china-digital-ad-spending-update-q2-2020

[3] CUDA toolkit Documentation, https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html

[4] Zhou, Guorui, et al. "Deep interest evolution network for click-through rate prediction." Proceedings of the AAAI conference on artificial intelligence. Vol. 33. 2019.

[5] Qi, Pi, et al. "Search-based User Interest Modeling with Lifelong Sequential Behavior Data for Click-Through Rate Prediction." arXiv preprint arXiv:2006.05639 (2020).

[6] Zhou, Guorui, et al. CAN: Revisiting Feature Co-Action for Click-Through Rate Prediction, 2020. https://arxiv.org/abs/2011.05625

[7] CUDA Driver API, https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__CTX.html#group__CUDA__CTX

END

招聘信息

我们是阿里妈妈工程平台预测引擎团队,欢迎感兴趣同学加入我们~

点击下方↓↓「阅读原文」了解岗位详情

广告深度学习计算:异构硬件加速实践相关推荐

  1. 广告深度学习计算:多媒体AI推理服务加速利器high_service

    本文作者:雨行.列宁.阿洛.腾冥.枭骑.无蹄.逍城.少奇.持信.云芑 本文是上一篇内容<广告深度学习计算:阿里妈妈智能创意服务优化>工作的进一步延伸,欢迎阅读交流. 概述 随着视频.文案. ...

  2. 神经网络深度学习计算的高效加速

    武汉芯逻辑科技 神经网络加速器IP 1.1 EEP-TPU 张量处理器架构介绍 神经网络编程模型的本质是计算图模型,如下图所示,计算图的输入/输出是张量 数据,计算图的类型代表操作类型.因此,直观的, ...

  3. 模型加速:深度学习模型的硬件加速:NVIDIAT240

    作者:禅与计算机程序设计艺术 模型加速:深度学习模型的硬件加速:NVIDIA T240 在当前深度学习模型的规模和复杂度不断增加的情况下,硬件加速已经成为一个重要的技术手段.本文将介绍NVIDIA T ...

  4. 什么是CUDA和CUDNN?——GeForce NVIDIA显卡用于深度学习计算的GPU加速工具

    1.什么是CUDA? CUDA的概念 统一计算架构CUDA(Compute Unified Device Architecture)是为了让nvidia gpu可以完成通用计算任务的一种集成技术 ,通 ...

  5. 广告深度学习计算:召回算法和工程协同优化的若干经验

    ▐  背景 阿里妈妈展示广告召回大多采用 Tree-based Deep Model(以下简称TDM)模型,它通过对候选广告的聚类,构造了深达十余层的二叉树索引,并使用 beam search 在此索 ...

  6. 广告深度学习计算:阿里妈妈智能创意服务优化

  7. 深度学习的异构加速技术(一):AI 需要一个多大的“心脏”?

    欢迎大家前往腾讯云社区,获取更多腾讯海量技术实践干货哦~ 作者:kevinxiaoyu,高级研究员,隶属腾讯TEG-架构平台部,主要研究方向为深度学习异构计算与硬件加速.FPGA云.高速视觉感知等方向 ...

  8. 从深度学习计算过程来分析深度学习工作站\服务器的硬件配置

    柯洁和AlphaGo的故事已经结束,输赢显得并不重要,这个天才少年曾落泪哽咽:它太完美我看不到希望.搭载谷歌无人驾驶技术的车辆已经完成200万英里的测试,如今它打算要载人了,无人驾驶真的已经不远.在苹 ...

  9. 王喆:深度学习计算广告

    <DataFun·5周年系列技术文章>专栏·第02篇 作者 | 王喆 策划 | Hoh 导读:大家好,我是<深度学习推荐系统>的作者王喆,很多同行可能读过这本系统性介绍推荐系统 ...

最新文章

  1. Git之深入解析凭证存储
  2. 地图漫游功能的具体体现_一卡通考勤门禁管线系统主要模块功能说明
  3. 2013年工作中用到的10个命令:11-20
  4. poj 1952 BUY LOW, BUY LOWER dp 但去重真是令人纠结
  5. host=‘api.github.com‘, port=443): Max retries exceeded with url
  6. kafkaStream执行过程中出现TimeoutException异常退出
  7. Mac OS用Anaconda安装Jupyter Notebook
  8. Android应用系统签名方法
  9. 问题解决:你需要trustedinstaller提供的权限才能删除
  10. openlayers学习——13、openlayers比例尺
  11. .NET 开发从入门到精通
  12. 微信小程序断网异常处理
  13. 数仓中的维度、原子指标、派生指标、衍生指标、指标分类、缓慢变化维等的含义
  14. [Irving] Wpf DevexPress GridControl 获取选中行
  15. JS显示和隐藏div
  16. html制作透明正方形,用css3简单的制作3d半透明立方体图片详解
  17. 华为怎么显示返回按键_你见过这台会跑的“华为手机”吗?深度体验极星Polestar 2车机系统...
  18. 高恪智能流控怎么设置_磊科285G智能QoS与高恪K2P智能流控多用户对比评测(下, 多用户对比测试)...
  19. 00-前端开发和前端开发工具
  20. 部署Kubernetes集群(二进制 v1.18.8版)

热门文章

  1. developer pack_上汽大众MEB电池Pack制造车间
  2. vue 关闭弹如何销毁子组件_vue中的eventBus会产生内存泄漏吗
  3. python2异步编程_Python 异步编程入门
  4. Android关于Handler发送消息里面的arg1和arg2以及obj和what的用法
  5. python调用sparksql,使用Python从MySQL数据库表读取SparkSQL
  6. html5图片怎么顶格,iQOO 5系列几乎达到了“顶格”的性能状态。
  7. TCP/IP数据包结构分解
  8. Swift--基本运算符
  9. GPRS模块AT呼叫控制命令
  10. 解决Cannot change version of project facet Dynamic Web M