推薦系統(tǒng)驅(qū)動(dòng)你在網(wǎng)上采取的每一個(gè)行動(dòng)，從你現(xiàn)在正在閱讀的網(wǎng)頁(yè)的選擇到更明顯的例子，如網(wǎng)上購(gòu)物。它們?cè)谕苿?dòng)用戶(hù)參與在線(xiàn)平臺(tái)、從成倍增長(zhǎng)的可用選項(xiàng)中選擇一些相關(guān)商品或服務(wù)方面發(fā)揮著關(guān)鍵作用。在一些最大的商業(yè)平臺(tái)上，推薦占據(jù)了高達(dá) 30% 的收入。推薦質(zhì)量提高 1% 就可以帶來(lái)數(shù)十億美元的收入。

隨著行業(yè)數(shù)據(jù)集規(guī)模的快速增長(zhǎng)，深度學(xué)習(xí)（ Deep Learning ， DL ）推薦模型利用了大量的訓(xùn)練數(shù)據(jù)，與傳統(tǒng)的基于內(nèi)容、鄰域和潛在因素的推薦方法相比，具有越來(lái)越大的優(yōu)勢(shì)。 DL 推薦模型是建立在現(xiàn)有技術(shù)的基礎(chǔ)上的，例如 embeddings 用來(lái)處理分類(lèi)變量，以及 factorization 用來(lái)建模變量之間的相互作用。然而，他們也利用大量快速增長(zhǎng)的關(guān)于新型網(wǎng)絡(luò)架構(gòu)和優(yōu)化算法的文獻(xiàn)來(lái)構(gòu)建和訓(xùn)練更具表現(xiàn)力的模型。

因此，更復(fù)雜的模型和快速數(shù)據(jù)增長(zhǎng)的結(jié)合提高了培訓(xùn)所需計(jì)算資源的門(mén)檻，同時(shí)也給生產(chǎn)系統(tǒng)帶來(lái)了新的負(fù)擔(dān)。為了滿(mǎn)足大規(guī)模 DL 推薦系統(tǒng)訓(xùn)練和推理的計(jì)算需求， NVIDIA 引入了 Merlin 。

Merlin 是一個(gè)基于 – GPU 框架的端到端推薦程序，旨在提供快速功能工程和高訓(xùn)練吞吐量，以實(shí)現(xiàn) DL 推薦程序模型的快速實(shí)驗(yàn)和生產(chǎn)再訓(xùn)練。 Merlin 還支持低延遲、高吞吐量和生產(chǎn)推斷。

在深入研究 Merlin 之前，我們將進(jìn)一步討論大規(guī)模推薦系統(tǒng)目前面臨的挑戰(zhàn)。

推薦系統(tǒng)概述

圖 1 顯示了一個(gè)端到端推薦系統(tǒng)體系結(jié)構(gòu)示例。

圖 1 。端到端推薦系統(tǒng)架構(gòu)。 FE ：特征工程； PP ：預(yù)處理； ETL ：提取轉(zhuǎn)換負(fù)載。

推薦系統(tǒng)是使用收集到的關(guān)于用戶(hù)、項(xiàng)目及其交互（包括印象、點(diǎn)擊、喜歡、提及等等）的數(shù)據(jù)來(lái)訓(xùn)練的。這些信息通常存儲(chǔ)在數(shù)據(jù)湖或數(shù)據(jù)倉(cāng)庫(kù)中。

在實(shí)驗(yàn)階段，提取 – 轉(zhuǎn)換 – 加載（ ETL ）操作準(zhǔn)備并導(dǎo)出用于培訓(xùn)的數(shù)據(jù)集，通常以表格數(shù)據(jù)的形式，可以達(dá)到 TB 或 PB 級(jí)別。這種類(lèi)型的一個(gè)示例公共數(shù)據(jù)集是 Criteo-Terabyte 點(diǎn)擊日志 dataset ，它包含 24 天內(nèi) 40 億次交互的點(diǎn)擊日志。行業(yè)數(shù)據(jù)集可以大幾個(gè)數(shù)量級(jí)，包含多年的數(shù)據(jù)。

在實(shí)驗(yàn)過(guò)程中，數(shù)據(jù)科學(xué)家和機(jī)器學(xué)習(xí)工程師使用特征工程，通過(guò)轉(zhuǎn)換現(xiàn)有特征來(lái)創(chuàng)建新的特征；以及預(yù)處理，為模型使用工程特征做準(zhǔn)備。然后使用 DL 框架（如 TensorFlow 、 PyTorch 或 NVIDIA 推薦者特定的訓(xùn)練框架 HugeCTR ）執(zhí)行訓(xùn)練。

模型經(jīng)過(guò)離線(xiàn)培訓(xùn)和評(píng)估后，可以進(jìn)入生產(chǎn)環(huán)境進(jìn)行在線(xiàn)評(píng)估，通常是通過(guò) A / B 測(cè)試。推薦系統(tǒng)的推理過(guò)程包括根據(jù)用戶(hù)與候選項(xiàng)交互的預(yù)測(cè)概率對(duì)候選項(xiàng)進(jìn)行選擇和排序。

對(duì)于大型商業(yè)數(shù)據(jù)庫(kù)來(lái)說(shuō)，選擇一個(gè)項(xiàng)目子集是必要的，因?yàn)橛袛?shù)百萬(wàn)個(gè)項(xiàng)目可供選擇。選擇方法通常是一種高效的算法，例如近似最近鄰、隨機(jī)林或基于用戶(hù)偏好和業(yè)務(wù)規(guī)則的過(guò)濾。 DL 推薦模型對(duì)候選對(duì)象進(jìn)行重新排序，并將預(yù)測(cè)概率最高的候選對(duì)象呈現(xiàn)給用戶(hù)。

推薦系統(tǒng)面臨的挑戰(zhàn)

培訓(xùn)大規(guī)模推薦系統(tǒng)時(shí)面臨許多挑戰(zhàn)：

龐大的數(shù)據(jù)集： 商業(yè)推薦系統(tǒng)通常是在大數(shù)據(jù)集（通常是 TB 或更多）上訓(xùn)練的。在這種規(guī)模下，數(shù)據(jù) ETL 和預(yù)處理步驟通常比訓(xùn)練 DL 模型花費(fèi)更多的時(shí)間。

復(fù)雜的數(shù)據(jù)預(yù)處理和特征工程管線(xiàn)： 需要對(duì)數(shù)據(jù)集進(jìn)行預(yù)處理，并將其轉(zhuǎn)換為與 DL 模型和框架一起使用的適當(dāng)形式。同時(shí)，特征工程試驗(yàn)從現(xiàn)有特征中創(chuàng)建了許多新特征集，然后對(duì)這些特征集進(jìn)行有效性測(cè)試。此外，列車(chē)時(shí)刻的數(shù)據(jù)加載可能成為輸入瓶頸，導(dǎo)致 GPU 未充分利用。

大量重復(fù)實(shí)驗(yàn)： 整個(gè)數(shù)據(jù) ETL 、工程、培訓(xùn)和評(píng)估過(guò)程可能必須在許多模型體系結(jié)構(gòu)上重復(fù)多次，這需要大量的計(jì)算資源和時(shí)間。然而，在部署之后，推薦系統(tǒng)還需要定期進(jìn)行再培訓(xùn)，以了解新用戶(hù)、項(xiàng)目和最新趨勢(shì)，以便隨著時(shí)間的推移保持較高的準(zhǔn)確性。

巨大的嵌入表： 嵌入是當(dāng)今處理分類(lèi)變量的一種普遍使用的技術(shù)，尤其是用戶(hù)和項(xiàng)目 ID 。在大型商業(yè)平臺(tái)上，用戶(hù)和項(xiàng)目庫(kù)很容易達(dá)到數(shù)億甚至數(shù)十億的數(shù)量，與其他類(lèi)型的 DL 層相比，需要大量的內(nèi)存。同時(shí)，與其他 DL 操作不同，嵌入查找是內(nèi)存帶寬受限的。雖然 CPU 通常提供更大的內(nèi)存池，但與 GPU 相比，它的內(nèi)存帶寬要低得多。

分布式培訓(xùn)： 正如 MLPerf benchmark 所反映的那樣，分布式訓(xùn)練在視覺(jué)和自然語(yǔ)言領(lǐng)域的 DL 模型訓(xùn)練中不斷創(chuàng)造新的記錄，但由于與其他領(lǐng)域和大型模型相比，大數(shù)據(jù)的獨(dú)特組合，分布式訓(xùn)練對(duì)于推薦系統(tǒng)來(lái)說(shuō)仍然是一個(gè)相對(duì)較新的領(lǐng)域。它要求模型并行和數(shù)據(jù)并行，因此很難實(shí)現(xiàn)高的擴(kuò)展效率。

在生產(chǎn)中部署大規(guī)模推薦系統(tǒng)的一些顯著挑戰(zhàn)包括：

實(shí)時(shí)推斷： 對(duì)于每個(gè)查詢(xún)用戶(hù)，即使在候選縮減階段之后，要評(píng)分的用戶(hù)項(xiàng)對(duì)的數(shù)量也可能多達(dá)幾千個(gè)。這給 DL 推薦系統(tǒng)推理服務(wù)器帶來(lái)了極大的負(fù)擔(dān)，它必須處理高吞吐量以同時(shí)為許多用戶(hù)提供服務(wù)，同時(shí)還必須處理低延遲以滿(mǎn)足在線(xiàn)商務(wù)引擎嚴(yán)格的延遲閾值。

監(jiān)測(cè)和再培訓(xùn)： 推薦系統(tǒng)在不斷變化的環(huán)境中運(yùn)行：新用戶(hù)注冊(cè)、新項(xiàng)目可用以及熱點(diǎn)趨勢(shì)出現(xiàn)。因此，推薦系統(tǒng)需要不斷的監(jiān)測(cè)和再培訓(xùn)，以確保高效率。推理服務(wù)器還必須能夠同時(shí)部署不同版本的模型，并動(dòng)態(tài)加載/卸載模型，以便于 a / B 測(cè)試。

NVIDIA Merlin ：在 NVIDIA GPU 上的端到端推薦系統(tǒng)

圖 2 。 Merlin 架構(gòu)。

為了系統(tǒng)地解決上述挑戰(zhàn)，NVIDIA 引入了 Merlin。 NVIDIA Merlin 是一個(gè)應(yīng)用程序框架和生態(tài)系統(tǒng)，旨在促進(jìn)推薦系統(tǒng)開(kāi)發(fā)的所有階段，從實(shí)驗(yàn)到生產(chǎn)，并在 NVIDIA GPU 上加速。圖 2 顯示了 Merlin 的架構(gòu)圖，包含三個(gè)主要組件：

Merlin ETL 公司： 一組用于在 GPU 上進(jìn)行快速推薦系統(tǒng)功能工程和預(yù)處理的工具。 NVTabular 提供高速的、在 GPU 上的數(shù)據(jù)預(yù)處理和轉(zhuǎn)換功能，以處理 TB 級(jí)的表格數(shù)據(jù)集。 NVTabular 的輸出可以通過(guò) NVTabular 數(shù)據(jù)加載器擴(kuò)展以高吞吐量提供給訓(xùn)練框架，例如 NVTabular 、 PyTorch 或 TensorFlow ，從而消除輸入瓶頸。

Merlin 培訓(xùn)： DL 推薦系統(tǒng)模型和培訓(xùn)工具的集合：

HugeCTR 是一種高效的 C ++推薦系統(tǒng)專(zhuān)用培訓(xùn)框架。它具有多點(diǎn) GPU 和多節(jié)點(diǎn)訓(xùn)練，并支持模型并行和數(shù)據(jù)并行擴(kuò)展。 HugeCTR 涵蓋了常見(jiàn)和最新的推薦系統(tǒng)架構(gòu)，如 寬而深 （ W & D ）、 深交叉網(wǎng)絡(luò) 和 DeepFM ，深度學(xué)習(xí)推薦模型（ DLRM ）支持即將推出。

DLRM 、 寬深（ W & D ） 、 神經(jīng)協(xié)同濾波 和 可變自動(dòng)編碼器（ VAE ） 構(gòu)成了 NVIDIA GPU – 加速 DL 模型組合 的一部分，它涵蓋了除推薦系統(tǒng)之外的許多不同領(lǐng)域的廣泛網(wǎng)絡(luò)體系結(jié)構(gòu)和應(yīng)用，包括圖像、文本和語(yǔ)音分析。這些模型是為訓(xùn)練而設(shè)計(jì)和優(yōu)化的 TensorFlow 和 PyTorch 。

Merlin 推論： NVIDIA TensorRT 和 NVIDIA Triton ?聲波風(fēng)廓線(xiàn)儀推斷服務(wù)器 （以前的 TensorRT 推理服務(wù)器）。

NVIDIA TensorRT 是一個(gè)用于高性能 DL 推理的 SDK 。它包括一個(gè) DL 推理優(yōu)化器和運(yùn)行時(shí)，為 DL 推理應(yīng)用程序提供低延遲和高吞吐量。

Triton Server 提供了一個(gè)全面的 GPU 優(yōu)化推斷解決方案，允許使用各種后端的模型，包括 PyTorch 、 TensorFlow 、 TensorRT 和開(kāi)放式神經(jīng)網(wǎng)絡(luò)交換（ ONNX ）運(yùn)行時(shí)。 Triton Server 自動(dòng)管理和利用所有可用的 GPU ，并提供為模型的多個(gè)版本提供服務(wù)和報(bào)告各種性能指標(biāo)的能力，從而實(shí)現(xiàn)有效的模型監(jiān)控和 a / B 測(cè)試。

在接下來(lái)的部分中，我們將依次探討這些組件中的每一個(gè)。

NVTabular ：快速表格數(shù)據(jù)轉(zhuǎn)換和加載

對(duì)推薦系統(tǒng)數(shù)據(jù)集執(zhí)行特征工程和預(yù)處理所花費(fèi)的時(shí)間常常超過(guò)訓(xùn)練模型本身所花費(fèi)的時(shí)間。作為一個(gè)具體的例子，使用開(kāi)源提供的腳本處理 Criteo-Terabyte 點(diǎn)擊日志 dataset 需要 5 。 5 天才能完成，而在單個(gè) V100 GPU 上對(duì)已處理數(shù)據(jù)集上的 DLRM 進(jìn)行培訓(xùn)則需要不到一個(gè)小時(shí)的時(shí)間。

NVTabular 是一個(gè)功能工程和預(yù)處理庫(kù)，旨在快速方便地操作 TB 級(jí)數(shù)據(jù)集。它特別適用于推薦系統(tǒng)，推薦系統(tǒng)需要一種可伸縮的方式來(lái)處理附加信息，例如用戶(hù)和項(xiàng)目元數(shù)據(jù)以及上下文信息。它提供了一個(gè)高級(jí)抽象，以簡(jiǎn)化代碼并使用 cuDF cuDF 庫(kù)加速 GPU 上的計(jì)算。使用 NVTabular ，只需 10-20 行高級(jí) API 代碼，就可以建立一個(gè)數(shù)據(jù)工程管道，與優(yōu)化的基于 CPU 的方法相比，可以實(shí)現(xiàn)高達(dá) 10 倍的加速，同時(shí)不受數(shù)據(jù)集大小的限制，而不管 GPU / CPU 內(nèi)存容量如何。

執(zhí)行 ETL 所用的總時(shí)間是運(yùn)行代碼所用時(shí)間和編寫(xiě)代碼所用時(shí)間的混合。 RAPIDS 團(tuán)隊(duì)在 GPU 上加速了 Python 數(shù)據(jù)科學(xué)生態(tài)系統(tǒng)，并通過(guò) cuDF 、 Apache Spark 3 。 0 和 Dask- cuDF 提供了加速。

NVTabular 使用了這些加速，但提供了一個(gè)更高級(jí)別的 API ，重點(diǎn)放在推薦系統(tǒng)上，這大大簡(jiǎn)化了代碼復(fù)雜性，同時(shí)仍然提供相同級(jí)別的性能。圖 3 顯示了 NVTabular 相對(duì)于其他數(shù)據(jù)幀庫(kù)的位置。

圖 3 。 NVTabular 與其他流行數(shù)據(jù)幀庫(kù)的定位比較。

下面的代碼示例顯示了轉(zhuǎn)換 1-TB Criteo Ads 數(shù)據(jù)集所需的實(shí)際預(yù)處理工作流，使用 NVTabular 只需十幾行代碼即可實(shí)現(xiàn)。簡(jiǎn)單地說(shuō)，指定了數(shù)字列和分類(lèi)列。接下來(lái)，我們定義一個(gè) NVTabular 工作流，并提供一組訓(xùn)練和驗(yàn)證文件。然后，將預(yù)處理操作添加到工作流中，并將數(shù)據(jù)持久化到磁盤(pán)。相比之下，定制的處理代碼，比如 Facebook 的 DLRM 實(shí)現(xiàn)中基于 NumPy 的 有用數(shù)據(jù) ，在同一管道中可以有 500-1000 行代碼。

import nvtabular as nvt
import glob

cont_names = ["I"+str(x) for x in range(1, 14)] # specify continuous feature names
cat_names = ["C"+str(x) for x in range(1, 27)] # specify categorical feature names
label_names = ["label"] # specify target feature
columns = label_names + cat_names + cont_names # all feature names

# initialize Workflow
proc = nvt.Worfklow(cat_names=cat_names, cont_names=cont_names, label_name=label_names)

# create datsets from input files
train_files = glob.glob("./dataset/train/*.parquet")
valid_files = glob.glob("./dataset/valid/*.parquet")

train_dataset = nvt.dataset(train_files, gpu_memory_frac=0.1)
valid_dataset = nvt.dataset(valid_files, gpu_memory_frac=0.1)

# add feature engineering and preprocessing ops to Workflow
proc.add_cont_feature([nvt.ops.ZeroFill(), nvt.ops.LogOp()])
proc.add_cont_preprocess(nvt.ops.Normalize())
proc.add_cat_preprocess(nvt.ops.Categorify(use_frequency=True, freq_threshold=15))

# compute statistics, transform data, export to disk
proc.apply(train_dataset, shuffle=True, output_path="./processed_data/train", num_out_files=len(train_files))
proc.apply(valid_dataset, shuffle=False, output_path="./processed_data/valid", num_out_files=len(valid_files))

圖 5 顯示了 NVTabular 相對(duì)于原始 DLRM 預(yù)處理腳本的相對(duì)性能，以及在單節(jié)點(diǎn)集群上運(yùn)行的 Spark 優(yōu)化的 ETL 進(jìn)程。值得注意的是培訓(xùn)占用的時(shí)間與 ETL 占用的時(shí)間的百分比。在基線(xiàn)情況下， ETL 與訓(xùn)練的比率幾乎完全符合數(shù)據(jù)科學(xué)家花費(fèi) 75% 時(shí)間處理數(shù)據(jù)的普遍說(shuō)法。在 NVTabular 中，這種關(guān)系被翻轉(zhuǎn)了。

圖 5 。 NVTabular 準(zhǔn)則比較。

GPU （ Tesla V100 32 GB ）與 CPU （ AWS r5d 。 24xl ， 96 核， 768 GB RAM ）

使用原始腳本在 CPU 上處理數(shù)據(jù)集和訓(xùn)練模型所花費(fèi)的總時(shí)間超過(guò)一周。通過(guò)大量的努力，使用 Spark 進(jìn)行 ETL 和 GPU 上的培訓(xùn)可以減少到四個(gè)小時(shí)。使用本文后面將介紹的 NVTabular 和 HugeCTR ，您可以將單個(gè) GPU 的迭代時(shí)間縮短到 40 分鐘，將 DGX-1 集群的迭代時(shí)間縮短到 18 分鐘。在后一種情況下， 40 億個(gè)交互數(shù)據(jù)集只需 3 分鐘即可處理完畢。

HugeCTR ： GPU ——大型 CTR 機(jī)型加速訓(xùn)練

HugeCTR 是一個(gè)高效的 GPU 框架，設(shè)計(jì)用于推薦模型訓(xùn)練，目標(biāo)是高性能和易用性。它既支持簡(jiǎn)單的深層車(chē)型，也支持最先進(jìn)的混合動(dòng)力車(chē)型，如 W&D 、 深交叉網(wǎng)絡(luò) 和 DeepFM 。我們還致力于使用 HugeCTR 啟用 DLRM 。模型細(xì)節(jié)和超參數(shù)可以用 JSON 格式輕松指定，允許從一系列常見(jiàn)模型中快速選擇。

與 PyTorch 和 TensorFlow 等其他通用 DL 框架相比， HugeCTR 專(zhuān)門(mén)設(shè)計(jì)用于加速大規(guī)模 CTR 模型的端到端訓(xùn)練性能。為了防止數(shù)據(jù)加載成為訓(xùn)練中的主要瓶頸，它實(shí)現(xiàn)了一個(gè)專(zhuān)用的數(shù)據(jù)讀取器，該讀取器本質(zhì)上是異步的和多線(xiàn)程的，因此數(shù)據(jù)傳輸時(shí)間與 GPU 計(jì)算重疊。

HugeCTR 中的嵌入表是模型并行的，分布在一個(gè)由多個(gè)節(jié)點(diǎn)和多個(gè) GPU 組成的集群中的所有 GPU 上。這些模型的密集組件是數(shù)據(jù)并行的，每個(gè)模型上有一個(gè)副本 GPU （圖 6 ）。

圖 6 。 HugeCTR 模型和數(shù)據(jù)并行架構(gòu)。

對(duì)于高速可擴(kuò)展的節(jié)點(diǎn)間和節(jié)點(diǎn)內(nèi)通信， HugeCTR 使用 NCCL 。對(duì)于有許多輸入特征的情況， HugeCTR 嵌入表可以分割成多個(gè)槽。將屬于同一時(shí)隙的特征獨(dú)立地轉(zhuǎn)換為相應(yīng)的嵌入向量，然后將其降為單個(gè)嵌入向量。它允許您有效地將每個(gè)插槽中有效功能的數(shù)量減少到可管理的程度。

圖 7a 顯示了 W & D 網(wǎng)絡(luò)的訓(xùn)練性能， HugeCTR 在 Kaggle 數(shù)據(jù)集 上的單個(gè) V100 GPU 上，與相同 GPU 上的 TensorFlow 和雙 20 核 Intel Xeon CPU E5-2698 v4 上的 HugeCTR 相比， HugeCTR 的加速比 TensorFlow CPU 高達(dá) 54 倍，是 TensorFlow GPU 的 4 倍。為了重現(xiàn)結(jié)果， HugeCTR repo 中提供了 寬深樣品 ，包括指令和 JSON 模型配置文件。

圖 7a 。 TensorFlow v2 。 0 CPU 和 GPU 與 HugeCTR v2 。 1 在單個(gè) V100 16-GB GPU 上的性能比較。 CPU ：雙 20 核 Intel （ R ） Xeon （ R ） CPU E5-2698 v4 @ 2 。 20GHz （ 80 線(xiàn)程）。型號(hào)： W & D ， 2 × 1024 FC 層。條形圖表示加速系數(shù) vs 。 TensorFlow CPU 。越高越好。括號(hào)中的數(shù)字表示一次迭代所用的平均時(shí)間。

圖 7b 顯示了 HugeCTR 在 DGX-1 上對(duì)全精度模式（ FP32 ）和混合精度模式（ FP16 ）采用更深入的 W & D 模型的強(qiáng)縮放結(jié)果。

圖 7b 。 HugeCTR 8X V100 16-GB GPU 上的強(qiáng)縮放結(jié)果。批量： 16384 。型號(hào)： W & D ， 7 × 1024 FC 層。

NVIDIA 推薦系統(tǒng)模型組合

DLRM 、 寬而深 、 NCF 和 VAE 構(gòu)成較大的 NVIDIA GPU – 加速 DL 模型組合 的一部分。在本節(jié)中，我們將展示 DLRM 的參考實(shí)現(xiàn)。

與其他基于 DL 的方法一樣， DLRM 被設(shè)計(jì)成同時(shí)使用分類(lèi)和數(shù)字輸入，這通常存在于推薦系統(tǒng)的訓(xùn)練數(shù)據(jù)中。模型架構(gòu)如圖 8 所示。

為了處理分類(lèi)數(shù)據(jù)，嵌入層將每個(gè)分類(lèi)映射到一個(gè)密集的表示，然后再將其輸入多層感知器（ MLP ）。數(shù)字特征可以直接輸入 MLP 。在下一級(jí)，通過(guò)計(jì)算所有嵌入向量對(duì)和處理后的密集特征之間的點(diǎn)積，顯式地計(jì)算不同特征的二階交互作用。這些成對(duì)交互被輸入到頂級(jí) MLP 中，以計(jì)算用戶(hù)和項(xiàng)目對(duì)之間交互的可能性。

圖 8 。 DLRM 體系結(jié)構(gòu)。

與其他基于 DL 的推薦方法相比， DLRM 在兩個(gè)方面有所不同。首先，它顯式計(jì)算特征交互，同時(shí)將交互順序限制為成對(duì)交互。其次， DLRM 將每個(gè)嵌入的特征向量（對(duì)應(yīng)于分類(lèi)特征）視為一個(gè)單元，而其他方法（如 Deep 和 Cross ）將特征向量中的每個(gè)元素視為一個(gè)新單元，該單元應(yīng)產(chǎn)生不同的交叉項(xiàng)。這些設(shè)計(jì)選擇有助于降低計(jì)算和內(nèi)存成本，同時(shí)保持具有競(jìng)爭(zhēng)力的準(zhǔn)確性。

圖 9 顯示了 TB 數(shù)據(jù)集 上的 DLRM 訓(xùn)練結(jié)果。在采用第三代張量核技術(shù)的 NVIDIA A100 GPU 上，采用混合精度訓(xùn)練，與 CPU 上的訓(xùn)練相比，訓(xùn)練時(shí)間縮短了 67 倍。

圖 9 。 DLRM 訓(xùn)練性能。條形圖表示 GPU 與 CPU 。 CPU ：雙 Intel （ R ） Xeon （ R ） Platinum 8168 @ 2 。 7 GHz （ 96 線(xiàn)程）。 GPU ： Tesla A100 40 GB 。越高越好。

TensorRT 和 Triton Server 進(jìn)行推斷

NVIDIA TensorRT 是一個(gè)用于高性能 DL 推理的 SDK 。它包括一個(gè) DL 推理優(yōu)化器和運(yùn)行時(shí)，為推理應(yīng)用程序提供低延遲和高吞吐量。 TensorRT 可以使用一個(gè)公共接口，即開(kāi)放式神經(jīng)網(wǎng)絡(luò)交換格式（ ONNX ），從所有 DL 框架接受經(jīng)過(guò)訓(xùn)練的神經(jīng)網(wǎng)絡(luò)。

TensorRT 可以使用垂直和水平層融合等操作，并使用降低的精度（ FP16 ， INT8 ）利用了 NVIDIA GPU s 上張量核的高混合精度算術(shù)吞吐量。 TensorRT 還根據(jù)手頭的任務(wù)和目標(biāo) GPU 體系結(jié)構(gòu)自動(dòng)選擇最佳內(nèi)核。對(duì)于進(jìn)一步的特定于模型的優(yōu)化， TensorRT 是高度可編程和可擴(kuò)展的，允許您插入自己的插件層。

NVIDIA Triton 推斷服務(wù)器提供了一個(gè)針對(duì) NVIDIA GPU s 優(yōu)化的云推斷解決方案。服務(wù)器通過(guò) HTTP 或 gRPC 端點(diǎn)提供推斷服務(wù)，允許遠(yuǎn)程客戶(hù)端請(qǐng)求對(duì)服務(wù)器管理的任何模型進(jìn)行推斷。 Triton Server 可以使用多種后端為 DL 推薦程序模型提供服務(wù)，包括 TensorFlow 、 PyTorch （ TorchScript ）、 ONNX 運(yùn)行時(shí)和 TensorRT 運(yùn)行時(shí)。使用 DLRM ，我們展示了如何使用 Triton ?聲波風(fēng)廓線(xiàn)儀部署預(yù)訓(xùn)練的 PyTorch 模型，與 CPU 相比， A100 GPU 的延遲減少了 9 倍，如圖 10 所示。

圖 10 。 DLRM 使用 Triton 推理服務(wù)器進(jìn)行推理。條形圖表示 GPU 與 CPU 的加速系數(shù)。批量大小 2048 。 CPU ：雙 Intel （ R ） Xeon （ R ） Platinum 8168 @ 2 。 7 GHz （ 96 線(xiàn)程）。 GPU ： Tesla A100 40 GB 。越高越好。

在最近發(fā)表在 在 GPU s 上加速 Wide & Deep 推薦推理 上的文章中，作者詳細(xì)介紹了優(yōu)化方法，使用 TensorFlow 估算器 API 訓(xùn)練的 W & D 模型適合大規(guī)模生產(chǎn)部署。通過(guò)實(shí)現(xiàn)融合嵌入查找內(nèi)核來(lái)利用 GPU 高內(nèi)存帶寬，運(yùn)行在 Triton Server 自定義后端， GPU W & D TensorRT 推理管道與同等的 CPU 推理管道相比，延遲減少了 18 倍，吞吐量提高了 17 。 6 倍。所有這些都是使用 Triton Server 部署的，以提供生產(chǎn)質(zhì)量指標(biāo)并確保生產(chǎn)健壯性。

結(jié)論

NVIDIA Merlin 的組件已作為開(kāi)源項(xiàng)目提供：

NVTabular

HugeCTR

DLRM and other DL 推薦系統(tǒng)模型

TensorRT

Triton 推斷服務(wù)器

關(guān)于作者

Vinh Nguyen 是一位深度學(xué)習(xí)的工程師和數(shù)據(jù)科學(xué)家，發(fā)表了 50 多篇科學(xué)文章，引文超過(guò) 2500 篇。在 NVIDIA ，他的工作涉及廣泛的深度學(xué)習(xí)和人工智能應(yīng)用，包括語(yǔ)音、語(yǔ)言和視覺(jué)處理以及推薦系統(tǒng)。

Even Oldridge 是 NVIDIA 的高級(jí)應(yīng)用研究科學(xué)家，并領(lǐng)導(dǎo)開(kāi)發(fā) NVTabular 的團(tuán)隊(duì)。他擁有計(jì)算機(jī)視覺(jué)博士學(xué)位，但在過(guò)去的五年里，他一直在推薦系統(tǒng)領(lǐng)域工作，專(zhuān)注于基于深度學(xué)習(xí)的推薦系統(tǒng)。

About Minseok Lee

審核編輯：郭婷