Merlin HugeCTR(以下簡稱 HugeCTR)是 GPU 加速的推薦程序框架，旨在在多個(gè) GPU 和節(jié)點(diǎn)之間分配訓(xùn)練并估計(jì)點(diǎn)擊率(Click-through rate)。

V3.8 版本新增內(nèi)容

1. 第三代 Embedding 的示例：

這個(gè)版本我們新增了一個(gè)示例筆記本，介紹了 Embedding 集合的 Python API 以及第三代 Embedding 的使用方法。

2. 用于分級(jí)參數(shù)服務(wù)器查找功能的 DLPack Python API：

這個(gè)版本我們引入了對(duì)使用 DLPack Python API 從分層參數(shù)服務(wù)器 (HPS) 查找 Embedding 的支持。新方法是 lookup_fromdlpack()。

3. 使用 Python API 從 HDFS 讀取 Parquet 數(shù)據(jù)集：

現(xiàn)在您可以通過 DataSourceParams 來指定 Data Reader 的數(shù)據(jù)源的配置了，例如 Hadoop 分布式文件系統(tǒng)的 NameNode 的主機(jī)名和 NameNode 端口號(hào)。

4. 提高了日志記錄的性能。

5. 層類的改進(jìn)：

全連接層現(xiàn)已支持 3 維輸入，Matrix Multiply 層現(xiàn)已支持 4 維輸入。

6. 文檔的改進(jìn)：

a. 增加了導(dǎo)航長頁面以提供更好的體驗(yàn)。

b. Criteo 1TB 點(diǎn)擊日志數(shù)據(jù)集的 URL 已更新。

7. 修復(fù)的問題：

修復(fù)了 _metadata.json 配置文件內(nèi)的文件名和實(shí)際數(shù)據(jù)集文件名不一致的問題。

修復(fù)了在 AUC 預(yù)熱期間在多個(gè) GPU 上運(yùn)行大型模型時(shí)發(fā)生的內(nèi)存崩潰問題。

修復(fù)了 ETC 筆記本中鍵集生成的問題。

修復(fù)了使用調(diào)試模式編譯時(shí)發(fā)生的編譯錯(cuò)誤。

修復(fù)多節(jié)點(diǎn)訓(xùn)練出現(xiàn)重復(fù)日志的問題。

V3.9 版本新增內(nèi)容

1. 第三代 Embedding 的更新：

更新了 SOK 以使用 HugeCTR 第三代 Embedding 作為開發(fā)者預(yù)覽版本。

啟用了基于 cuCollection的動(dòng)態(tài)Embedding 模式。動(dòng)態(tài)的Embedding能夠在用戶不配置內(nèi)存使用信息時(shí)自動(dòng)拓展。

2. 全新的多節(jié)點(diǎn)訓(xùn)練教程：

我們提供了一個(gè)全新的基于 HugeCTR 最新 Docker 容器使用多節(jié)點(diǎn)訓(xùn)練的實(shí)例。

3. 現(xiàn)已支持 MMoE 模型的離線推理并提供了 Per-class AUC 和平均 AUC 計(jì)算。

4. 對(duì) HPS TensorFlow 插件使用的文檔和實(shí)例更新：

一個(gè)新的簡介文檔。

新的實(shí)例筆記本。

新的API文檔。

5. 修復(fù)的問題：

修復(fù)了一個(gè)訓(xùn)練性能受到 GPU 例程檢查影響的問題。該例程檢查輸入的 key 是否在規(guī)定的 Embedding Table 范圍內(nèi)。對(duì)于可以保證輸入的 key 能放在指定的 workspace_size_per_gpu_in_mb 的情況，我們提供了一種解決方法：通過設(shè)置環(huán)境變量 HUGECTR_DISABLE_OVERFLOW_CHECK=1 來關(guān)閉例程檢查，以便恢復(fù)訓(xùn)練性能。

我們修復(fù)了一個(gè) Softmax 層的正確性問題。

我們刪除了一個(gè)未更新且不再使用的內(nèi)聯(lián)分析器。

已知問題

以下是目前HugeCTR存在的已知問題，我們將在之后的版本中盡快修復(fù)。

HugeCTR 使用 NCCL 在 rank 之間共享數(shù)據(jù)，并且 NCCL 可能需要共享系統(tǒng)內(nèi)存用于 IPC 和固定(頁面鎖定)系統(tǒng)內(nèi)存資源。在容器內(nèi)使用 NCCL 時(shí)，建議您通過發(fā)出以下命令來增加這些資源 -shm-size=1g -ulimit memlock=-1

另見 NCCL 的 已知問題。

還有 GitHub 問題。

目前即使目標(biāo) Kafka broker 無響應(yīng)，KafkaProducers 啟動(dòng)也會(huì)成功。為了避免與來自 Kafka 的流模型更新相關(guān)的數(shù)據(jù)丟失，您必須確保有足夠數(shù)量的 Kafka brokers 啟動(dòng)、正常工作并且可以從運(yùn)行 HugeCTR 的節(jié)點(diǎn)訪問。

文件列表中的數(shù)據(jù)文件數(shù)量應(yīng)不小于數(shù)據(jù)讀取器的數(shù)量。否則，不同的 data reader worker 將被映射到同一個(gè)文件，導(dǎo)致數(shù)據(jù)加載不會(huì)按預(yù)期進(jìn)行。

正則化器暫時(shí)不支持聯(lián)合損失訓(xùn)練。

審核編輯：湯梓紅