关于美团:GPU在外卖场景精排模型预估中的应用实践

GPU 等专用芯片以较低的老本提供海量算力，曾经成为机器学习畛域的外围利器，在人工智能时代施展着越来越重要的作用。如何利用 GPU 这一利器赋能业务场景，是很多技术研发者都要面临的问题。本文分享了美团外卖搜寻 / 举荐业务中模型预估的 GPU 架构设计及落地的过程，心愿能对从事相干利用研发的同学有所帮忙或启发。

1 前言

近些年，随着机器学习技术的蓬勃发展，以 GPU 为代表的一系列专用芯片以优越的高性能计算能力和愈发低廉的老本，在机器学习畛域失去宽泛认可和青眼，且与传统的 CPU 体系一直交融，造成了新的异构硬件生态。

在这种技术浪潮之中，很多技术研发者会面临着这样的问题：在咱们的业务上利用 GPU 硬件能取得什么？如何疾速、平滑地从传统 CPU 体系根底上实现切换？站在机器学习算法设计的角度，又会带来什么影响和扭转？在 GPU 生态下泛滥的技术路线和架构选型中，如何找到一条最适宜本身场景的门路？

美团外卖搜寻举荐团队，也面临着相似的挑战和问题。本文咱们会分享美团外卖搜寻 / 举荐业务中，模型预估的 GPU 架构设计与落地过程，并将一些技术细节和测试数据做了详尽的披露，心愿能为宽广的技术同行提供一些有价值的参考。

2 背景

以后，美团外卖次要通过搜寻和举荐两种流量散发形式，满足用户对“万物到家”的需要。除了首页的搜寻、举荐性能外，重点品类会在首页减少独立入口（下文称之为“金刚”），每个金刚入口中都有相似于首页搜寻、举荐的区域，而不同场景入口独特服务于外卖的最终成单。首页、金刚、店内的联动关系如下图所示：

面向点击率（CTR）/ 转化率（CVR）预估的深度学习，是每一个电商类搜寻 / 举荐产品中的核心技术，间接决定了产品的用户体验和转化成果，同时也是机器资源耗费的“小户”。而 CTR/CVR 精排模型的设计和实际，也是美团外卖搜寻举荐（下称搜推）技术团队必须要攻克且一直谋求卓越的必争之地。

从搜推零碎设计的角度上看，不同的搜寻、举荐入口会天然造成独立的调用链路。在传统的模型设计思路下，会对不同入口链路、不同漏斗环节的 CTR/CVR/PRICE 多个指标独立设计模型，这也是美团外卖搜推过往模型设计的经典形式。而从 2021 年起，基于多场景全局优化的考量，搜推场景的 CTR/CVR 预估模型开始逐渐走向多模型对立，综合利用多个入口的数据、联合不同入口本身的业务特点实现多个入口的联动优化，逐渐实现“One Model to Serve All”的指标。

从模型计算实际的角度上看，外卖精排模型的倒退，让模型 Dense 网络的计算量显著收缩，以 CPU 为计算主力的软硬件架构曾经难以应答算法的倒退需要，即使老本耗费大幅加剧，算力天花板依然“近在眉睫”。而 GPU 硬件面向浓密计算的算力劣势，恰好吻合新的模型特点，能够从根本上突破精排模型预估 / 训练中的算力困局。因而，从 2021 年开始，美团外卖搜推场景的深度学习体系开始逐渐从纯 CPU 架构走向 CPU+GPU 的异构硬件计算平台，以满足美团外卖模型算法演进对算力的新要求。

本文接下来的内容，会从外卖搜推场景的精排模型设计登程，联合美团理论的软硬件特点，为大家具体分享在外卖精排模型预估畛域，从纯 CPU 架构转型到 CPU+GPU 异构平台的摸索和实际过程，供宽广技术同行参考。

3 外卖搜推场景下的精排模型

本章节次要介绍在外卖场景下多模型对立的演进思路、模型特点以及在实践中的挑战。本文只对模型设计思路做简略的阐明，引出后续模型计算在 GPU 落地中的实际思考。

3.1 精排模型的设计思路

如前文所述，在美团外卖多入口联动的场景特点下，经典的单体模型设计存在着以下局限：

1. 首页举荐与各金刚入口举荐各保护一个精排模型，不仅保护老本高而且训练数据割裂，导致精排模型不能捕捉到用户在所有举荐场景的趣味。
2. 举荐场景的精排模型只应用举荐场景的训练样本，未利用用户在其余重要入口的训练样本，比方搜寻、订单页，模型只学习到用户在部分场景的偏好信息。
3. 举荐场景的训练样本中存在 Position Bias 问题，具体是指用户点击一个商家，有可能只是因为该商家在举荐 Feeds 中排序地位比拟靠前，而非因为用户对此商家真正感兴趣，此类 Bias 会引起模型训练有偏。
4. 多指标之间存在贝叶斯束缚，网络结构中未思考，CXR=CTR × CVR，CXR 预估值应比 CTR 小，模型在验证集上会呈现 CXR 比 CTR 还高的景象，预估不精确。

基于此，在 2021 年，美团外卖搜推场景提出了向超过单体的多模型对立演进、逐渐实现“One Model to Serve All”的思维，这一理念在模型设计中具体体现在：

1. CTR/CXR 多指标的交融，实现多指标预测的模型对立。
2. 场景专家网络与 Attention 网络的交融，实现不同流量入口之间的模型泛化和对立。
3. 畛域专属网络和共享网络的交融，实现举荐场景向搜索场景的迁徙学习。

随着外卖精排模型的倒退和演进，模型 Dense 网络的参数量显著减少，单次推理的 FLOPs 达到 26M，对 CPU 计算架构造成了微小压力。另一方面，咱们采纳 Float 16 压缩、特色主动抉择、网络穿插代替手动穿插特色等技术手段，将模型由 100G 放大到 10G 以内，并且过程中通过模型的优化，做到了模型成果无损。

综上，外卖搜推精排模型浓密局部计算简单、稠密局部体积可控，这些良好的个性，为咱们在 GPU 硬件架构上落地推理计算提供了绝对合适的模型算法根底。接下来，咱们将探讨如何在高吞吐、低耗时的外卖搜寻举荐零碎中，利用 GPU 硬件无效解决外卖精排模型在线预估中的老本和性能问题，并给出咱们的实际过程和后果。

3.2 模型利用的特点与挑战

在搜寻 / 举荐技术畛域中，稠密模型预估（CTR/CVR）是决定算法成果的外围因素，模型预估服务是搜寻举荐零碎中必不可少的组成部分，业内各大公司已有很多经典的实现计划。在探讨具体实际之前，先介绍一下咱们的场景特点：

① 需要层面

• 模型构造 ：如前文介绍，外卖场景下的精排模型的浓密网络局部绝对简单，单次推理的 FLOPs 达到 26M；而模型的稠密局部通过大量的优化，体积失去了无效的管制，模型规模在 10G 以内。
• 服务质量要求 ：举荐服务作为经典的高性能 To C 场景，业内大部分同类零碎的超时管制在百毫秒量级，合成到预估服务，超时个别须要管制在十毫秒的量级。

② 软件框架层面

• 开发框架 ：模型开发采纳 TensorFlow 框架 [1]。作为支流的深度学习第二代框架，TensorFlow 具备弱小的模型表达能力，这也导致其算子粒度比拟小，这一特点无论是对 CPU 还是 GPU 架构都会带来很大的额定开销。
• 在线服务框架 ：采纳 TensorFlow Serving 框架 [2]。基于此框架，可将离线训练好的机器学习模型部署到线上，并利用 rpc 对外提供实时预估服务。TensorFlow Serving 反对模型热更新及模型版本治理，次要特点是应用灵便，性能较好。

③ 硬件层面

• 机型个性 ：美团基于晋升算力密度的考量，在预估服务采纳了 GPU BOX 机型。绝对于传统的 GPU 插卡机型，这一类机型每张 GPU 卡配套的 CPU 和内存绝对无限，这须要咱们在设计在线服务时，精细化的考量 CPU、GPU 上的计算和数据分布，达到更好的利用率平衡。
• GPU 固有属性 ：GPU kernel 大体上能够划分为传输数据、kernel 启动、kernel 计算等几个阶段 [3]，其中每个 kernel 的启动须要约 10us 左右。因而，GPU 预估会面临一个普适问题，大量的小算子导致每个 kernel 的执行工夫很短，kernel 启动的耗时占了大部分。相邻的 kernel 之间须要通过读写显存进行数据的传输，产生大量的访存开销。而 GPU 的访存吞吐远远低于计算吞吐，导致性能低下，GPU 的利用率并不高。

总结而言，与业内其余支流搜推场景绝对比，咱们的 CTR 模型预估场景有两个显著特点：

• 浓密网络局部计算复杂度高，绝对的，稠密网络在模型设计环节通过了大量的优化，体积绝对较小。
• 应用 GPU BOX 机型，单 GPU 卡的 CPU 配额受限，须要针对性优化 CPU 的计算负荷。

基于这两个特点，咱们在面向 GPU 的优化实际中就能够更具针对性了。

4 模型服务架构概览

本章节简要介绍美团外卖搜推在线预估服务的整体架构和角色分工，也是外卖搜推精排模型在 GPU 落地实际的工程零碎根底。

零碎要害角色

• Dispatch：承当着特色获取和特色计算的职能，如前文所述，美团应用 GPU BOX 机型搭建预估服务，推理计算的 CPU 资源自身就非常吃紧，因而天然会思考将在线特色工程局部独立部署，防止 CPU 资源的抢占。本局部和 GPU 实际关系不大，不是本文的重点。
• Engine：承当着模型在线推理的职能，通过 RPC 的形式输出特色矩阵、输入预估后果。采纳 GPU BOX 机型（单容器 8 核 +1 NVIDIA Tesla T4），均匀响应工夫需管制在 20ms 以内，下文所述 GPU 优化实际次要面向这一模块的特点进行。
• Booster：在模型更新过程中离线执行的模型优化器，外部以 Optimizer 插件的形式，混合了手工优化器插件和 DL 编译优化器插件，是下文所述 GPU 优化操作的执行者。

5 GPU 优化实际

本章节将开展分享精排模型预估计算在 GPU 架构落地中的优化过程。

与 CV、NLP 等经典机器学习畛域不同，以 CTR 模型为代表的稠密模型因为构造多变、蕴含大量业务特化等起因，硬件供应商难以对这一类未收敛的模型构造提供端到端优化工具。因而，在 CTR 模型大规模利用的畛域中，个别会联合 GPU 个性，面向应用场景对模型执行 Case By Case 的优化措施。按模型优化的指标来辨别，能够大抵分类为系统优化和计算优化：

① 系统优化 ：个别指通过对计算、存储、传输的调度，使 CPU+GPU 的异构硬件体系能够更有效率的协同和被应用。典型的系统优化包含：

• 设施摆放
• 算子交融
• GPU 并发 / 流水线优化

② 计算优化 ：个别指面向硬件个性，优化模型前向推理网络的结构设计和算子执行逻辑，使模型推理计算在 GPU 上的计算开销更小，效率更高。典型的计算优化包含：

• 冗余计算去除
• 量化计算
• 高性能库的利用

在本文介绍的优化工作中，咱们对上述常见优化中的大部分思路进行了摸索和实际，下文会逐个进行论述，并给出优化成果和面向理论场景的总结剖析。

5.1 系统优化

5.1.1 设施摆放

TensorFlow 会为计算图中每个 Node 主动设置 Runtime Device，计算较重者搁置在 GPU，计算较轻者搁置在 CPU。在简单计算图中实现一次残缺的 inference，数据会在 CPU 和 GPU 之间重复传输。因为 H2D/D2H 传输很重，这会造成数据传输耗时远大于 op（operator）外部计算耗时，在 GPU 下模型一次预估耗时为秒级别，远高于只应用 CPU 时的耗时。此外，如前所述，咱们所应用的 GPU 机型上 CPU 资源受限（一张 T4 卡仅对应 8 核 CPU），这也是咱们在异构架构设计中须要解决的核心技术挑战。

为解决 TensorFlow 主动设定 Runtime Device 不合理的问题，咱们为计算图中每个 Node 手动 Set Runtime Device。思考到 CPU 资源受限，咱们尽量的将计算较重的子图（包含 Attention 子图、MLP 子图）搁置在 GPU 计算，计算较轻的子图（次要为 Embedding 查问子图）搁置在 CPU 计算。

为进一步缩小设施间数据传输，咱们在 CPU 和 GPU 之间减少 Concat op 和 Split op，CPU 数据先 Concat 到一起再传输到 GPU，之后再按需 Split 成多份并传给对应 op，将 H2D/D2H 从上千次升高到数次。如下图所示，设施摆放优化之前，有大量的 H2D 数据传输；优化之后，H2D 缩小为 3 次，优化成果非常显著。

5.1.2 All On GPU

实现根本的设施摆放优化后，计算较轻的 Sparse 查问局部在 CPU 实现，计算较重的 Dense 计算局部在 GPU 实现。尽管 CPU 上计算较轻，但压测发现其仍旧是整体吞吐瓶颈。思考到整体计算图较小（约 2G），咱们天然的想到是否能够将整图放在 GPU 执行，绕开 CPU 配额的限度，此即 All On GPU。为了将原在 CPU 进行的 Saprse 查问改为在 GPU 执行，咱们新增了 LookupTable op 的 GPU 实现。如下图所示，HashTable 搁置在 GPU Global Memory，它的 Key 与 Value 对立存储在 Bucket 中。针对输出的多组 Key，利用多个 Block 的 Threads 并行查问。

同时，为进步 GPU 利用效率，升高 kernel launch 开销，咱们利用 TVM 对计算图进行编译优化（下文会进行具体介绍）。优化后的 All On GPU 模型图解决了 CPU 资源受限带来的瓶颈，整体吞吐晋升显著（qps 55->220，约 4 倍）。

5.1.3 算子交融

外卖搜推精排模型十分复杂，计算图中蕴含上万个计算 Node。GPU 上执行计算图时，每个 Node 都有 kernel launch 开销，多个 Node 之间还有拜访显存开销。此外，TensorFlow 框架自身在 Node 执行时会带来肯定开销，每个 Node 执行时都会创立、销毁 Input/Output Tensor，内存管制引入额定老本。因而，计算图中 Node 过多会重大影响执行效率。为解决这一问题，罕用的办法是进行算子交融，即在计算结果等价的前提下，将多个 Node 交融成一个 Node，尽量升高计算图 Node 数量，这样既能够将 Node 之间的拜访显存开销转为拜访寄存器开销，同时也能够缩小计算图中每个 Node 带来的固定开销。

算子交融次要通过三种形式进行：

• 特定算子手动交融。例如模型训练阶段中，针对一个 Embedding Table 会有多个 Node 拜访，在线预估阶段可将其交融成一个 Node，即查问 Node 和 Embedding Table 一一对应。尔后可进一步交融算子，一个 Node 负责查问多个 Embeddding Table。
• 常见算子主动交融，次要是利用 TensorFlow Grappler[4] 优化器进行算子主动交融。
• 利用深度学习编译器主动交融，下文会具体进行介绍。

5.2 计算优化

5.2.1 FP16 低精度优化

一方面，在 CPU 架构下，为了升高内存开销，曾经将 Embedding Table 压缩为 FP16[5] 存储，然而计算时仍会开展为 FP32，这引入了转换开销；另一方面，模型预估仅进行模型图的前向计算，应用低精度计算引入的误差较小。因而，业界广泛应用低精度形式进行模型预估计算。

针对以后的业务场景，咱们尝试了 FP16、INT8[6] 等低精度计算，FP16 半精度计算对模型成果无显著影响，INT8 量化则会造成成果衰减。因而，咱们采纳 FP16 半精度计算的形式，在不影响模型成果的前提下，进一步晋升预估服务的吞吐。

5.2.2 broadcast 优化

模型图中的数据能够分为 user 和 item 两类。通常状况下，申请中蕴含一个 user 以及多个 item。在模型 Sparse 局部，user 和 item 别离获取 Embedding；在模型 Dense 局部，两类 Embedding 组合成矩阵后进行计算。通过深入分析，咱们发现模型图中存在冗余查问和计算。如下图橙色局部所示，在模型 Sparse 局部，user 信息先被 broadcast 成 batchsize 大小再去查问 Embedding，导致同一个 Embedding 查问了 batchsize 次；在模型 Dense 局部，user 信息同样被 broadcast 成 batchsize 大小，再进行之后所有计算，实际上在和 item 穿插之前不用 broadcast user，同样存在冗余计算。

针对以上问题，咱们对模型图进行了手工优化，如下图紫色局部所示，在模型 Sparse 局部，user 信息只查问一次 Embedding；在模型 Dense 局部，user 信息与 item 穿插时再 broadcast 成 batchsize 大小，即整体上将 user 信息的 broadcast 后置。

5.2.3 高性能库利用

应用 CPU 时，能够利用 Intel MKL[7] 库对计算进行减速。受限于 CPU 硬件特点，减速成果无限。应用 GPU 时，咱们能够利用 Tensor Core[8] 进行减速计算。每个 Tensor Core 都是一个矩阵乘累加计算单元，以后应用的 NVIDIA T4 卡具备 320 个 Tensor Core，在混合精度计算时算力为 65 TFLOPS，在单精度计算时算力为 8.1 TFLOPS，具备极强的推理性能。在 TensorFlow 中，可利用 cuBLAS[9] 调用 Tensor Core 进行 GEMM 减速计算，利用 cuDNN[10] 调用 Tensor Core 进行 CNN、RNN 网络减速计算。

5.3 基于 DL 编译器的主动优化

随着深度学习网络越来越简单（Wider And Deeper），硬件设施越来越多样（CPU、GPU、NPU），神经网络的优化工作也变得越来越艰难。在繁多硬件、繁多框架上的优化会受到优化库限度，很难进一步调优。在不同硬件、不同框架的优化又很难做到通用，优化很难移植。这导致优化神经网络时，须要大量的手动调优工作，老本很高。

为了升高手动优化的老本，业界广泛应用深度学习编译器（Deep Learning Compiler）对计算图进行主动调优。比拟风行的深度学习编译器包含 TensorRT[11]、TVM[12]、XLA[13] 等，咱们在以后的模型场景下利用深度学习编译器做了较多的优化尝试，下文会具体进行介绍。

5.3.1 基于 TensorRT 的尝试

TensorRT 是 NVIDIA 推出的高性能深度学习推理优化框架，反对主动算子交融、量化计算、多流执行等多种优化伎俩，并且能够针对具体 kernel 抉择最优实现。TensorRT 的各优化均通过对应开关管制，应用很简略；然而整体闭源，并且反对的算子不多，只能对计算图的局部算子做优化，遇到不辨认的算子则会跳过，非常影响优化效率。利用 TensorRT 优化后的计算图，仍旧存在大量 op，整体性能晋升无限。为解决这个问题，咱们从以下两个角度进行尝试。

① 手动切分子图

利用 TensorRT 进行图优化时，会先利用 Union Find 算法在全图中寻找可辨认 op 并将其聚类，每个聚类进行具体的编译优化，并产生一个对应的 TRTEngineOp。因为计算图中存在大量不辨认 op，对聚类过程造成了烦扰，即便可辨认 OP 也不肯定能实现聚类，则无奈进行对应编译优化，造成优化效率较低。为解决这一问题，图优化前咱们先进行手动切图，将全计算图切分为若干个子图，每个可辨认 op 都放入对应子图中，并将子图送入 TensorRT 进行优化。通过这一办法，无效解决了可辨认 op 未优化的问题，无效升高了全图 OP 数量。

② 算子替换

如前所述，TensorRT 反对 OP 类型无限，全图中存在大量 TensorRT 无奈辨认的 op，导致优化效率偏低。为了缓解这一问题，咱们将 TensorRT 不辨认的 OP 尽量替换成其反对的等价 op。例如下图中，TensorRT 无奈辨认 Select op，咱们将其替换成 TensorRT 反对的 Multiply op，并将 Select 关联的 ExpandDims op 从图中消掉。通过相似的等价转换操作，无效升高了未辨认 op 数量，进步了编译优化覆盖率。

5.3.2 基于 TVM 的尝试

在尝试 TensorRT 优化时咱们发现，TensorRT 对 TensorFlow 的算子覆盖率较低（只能笼罩约 50+ 算子），在以后的模型计算图中，有十多个算子无奈反对。即便通过简单的算子替换优化工作，依然存在多个算子难以替换。由此咱们思考采纳其余的深度学习编译器进行图优化。

TVM 是陈天奇团队推出的端到端机器学习主动编译框架，在业界宽泛应用。和 TensorRT 相比，TVM 代码开源，具备更强的拓展性和定制能力。此外，TVM 反对的 TensorFlow 算子超过 130 个，算子覆盖率远超 TensorRT。在以后计算图中，TVM 不反对的 OP 只有自定义的 LookupTable，这一 OP 负责查问 Embedding，无需进行编译优化。

因而，咱们尝试利用 TVM 取代 TensorRT 对以后计算图进行主动编译优化。思考到 TensorFlow 对 TensorRT、XLA 均做了官网反对，实现了对应的 wrapper op，但目前尚未反对 TVM，咱们对 TensorFlow 做了适配革新，采纳和 TensorRT 相似的形式，实现了 TVMEngineOp 以反对 TVM。思考模型特点，咱们将计算较重的 Attention 子图和 MLP 子图放入了 TVMEngineOp 中，利用 TVM 进行编译优化，如下图所示：

6 性能体现与剖析

本章节展现理论生产环境下的测试数据，并剖析上文一系列业内典型优化思路，在咱们的特定场景下的体现及其背地起因。

压测环境中，CPU 环境为 32 核 Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz+32G 内存，GPU 环境为 8 核 Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz+Tesla T4 GPU+16G 内存。上图中，左图比照了不同 QPS 下（x 轴），精排模型在不同优化伎俩下的推理耗时（y 轴），其中 base-gpu 示意只通过简略的图优化并在 GPU 计算，trt 示意通过 TensorRT 优化并在 GPU 计算，tvm 示意通过 TVM 优化且叠加 All On GPU 优化并在 GPU 计算；右图示意极限 QPS 下，不同优化伎俩对应的 CPU 和 GPU 利用率。从图中能够看出：

• 只利用 CPU 进行预估计算时，极限 qps 为 55，此时 CPU 利用率曾经高达 76%，成为瓶颈。
• 利用惯例手工优化（设施摆放 + 算子交融 +Broadcast 优化 + 高性能库）的 GPU 预估时，雷同 qps 下 latency 大幅升高，且能够将极限 qps 晋升至 85（较 CPU 版晋升 55%）。达到极限吞吐时 GPU 利用率并不高，瓶颈仍旧为 CPU 利用率。
• 利用 TensorRT 优化预估（手工优化 +TensorRT+FP16）时，得益于图编译优化，雷同 qps 下 latency 升高约 40%。因为瓶颈仍为 CPU，极限吞吐未变动。
• 利用 TVM 优化预估（手工优化 +TVM+FP16+All On GPU）时，将所有 OP 都搁置于 GPU 计算，CPU 只负责根本的 RPC，极大缓解了 CPU 配额的瓶颈。雷同 qps 下 latency 大幅升高约 70%，极限吞吐大幅晋升约 120%。达到极限吞吐时，GPU 利用率较高，成为瓶颈。

通过一系列优化，整体吞吐晋升约 4 倍（qps 从 55->220），优化成果非常显著。

7 总结

综上，咱们针对美团外卖场景的业务特点，将经典的 CTR/CVR 模型从多入口、多环节、多指标的单体模型，逐渐演进到“One Model to Serve All”的多模型对立状态。

同时，联合美团的硬件条件和根底，实现了纯 CPU 预估架构向 CPU+GPU 异构架构的切换，在固定成本前提下，无效的开释了算力空间，计算吞吐晋升了近 4 倍。针对 GPU BOX 机型对 CPU 资源的限度，咱们采纳手工优化 +DL 编译优化联合、模型网络计算 All On GPU 的思路，无效的晋升了 GPU 在模型预估计算中的利用率，并在本文中具体分享了 GPU 落地中的优化过程和实测数据指标。

8 作者简介

• 杨杰、俊文、瑞东、封宇、王超、张鹏等，来自到家事业群 / 到家研发平台 / 搜寻举荐技术部。
• 王新、陈卓、駃飞等，来自根底研发平台 / 数据迷信与平台部 / 数据平台核心。

9 参考文献

• [1] https://www.usenix.org/system/files/conference/osdi16/osdi16-abadi.pdf
• [2] https://www.tensorflow.org/tfx/guide/serving
• [3] https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html
• [4] https://www.tensorflow.org/guide/graph_optimization
• [5] https://en.wikipedia.org/wiki/Half-precision_floating-point_format
• [6] https://www.nvidia.com/en-us/data-center/tensor-cores/
• [7] https://www.intel.com/content/www/us/en/develop/documentation/get-started-with-mkl-for-dpcpp/top.html
• [8] https://www.nvidia.com/en-us/data-center/tensor-cores/
• [9] https://docs.nvidia.com/cuda/cublas/index.html
• [10] https://developer.nvidia.com/zh-cn/cudnn
• [11] https://docs.nvidia.com/deeplearning/frameworks/tf-trt-user-guide/index.html
• [12] https://tvm.apache.org/docs/
• [13] https://www.tensorflow.org/xla

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。