一、模型場(chǎng)景介紹

1、實(shí)時(shí)大模型

*本文數(shù)據(jù)具有即時(shí)性，不代表實(shí)時(shí)數(shù)據(jù)。

快手的模型場(chǎng)景主要是實(shí)時(shí)的大模型。實(shí)時(shí)主要體現(xiàn)在社交上。每天都有新用戶上傳 1500 萬(wàn)以上的視頻，每天有億級(jí)以上的直播活躍用戶，并且上傳數(shù)每年都在同比上漲。

大主要體現(xiàn)在流量規(guī)模。快手現(xiàn)在的日活達(dá)到了 3.87 億，有千億級(jí)別的日均曝光，百億級(jí)別的日均播放，模型量級(jí)非常大，還要保證實(shí)時(shí)。并且快手的核心價(jià)值觀是平等普惠，即千萬(wàn)級(jí)的用戶同時(shí)在線時(shí)，個(gè)性化請(qǐng)求時(shí)會(huì)推薦不同的內(nèi)容。

總結(jié)起來(lái)，數(shù)據(jù)處理的特點(diǎn)是既大，又要實(shí)時(shí)。

2、推薦業(yè)務(wù)復(fù)雜

一般的推薦業(yè)務(wù)架構(gòu)如上圖所示，在視頻池里（比如有幾千萬(wàn)的視頻）會(huì)經(jīng)過(guò)固定的四個(gè)階段：

• 召回：從幾千萬(wàn)的視頻里召回幾萬(wàn)或者幾千的視頻。
• 粗排：通過(guò)一個(gè)粗排漏斗，選出幾千的視頻。
• 精排：幾千的視頻又會(huì)通過(guò)精排，篩選 top 幾百的視頻。
• 重排：進(jìn)入重排，給出模型打分，做模型校驗(yàn)。
• 返回：加上一些機(jī)制和多樣化操作，最后選出幾十個(gè)結(jié)果返回給用戶，整個(gè)漏斗要求非常高。

快手的業(yè)務(wù)類(lèi)型比較多樣，主要可以分成大型業(yè)務(wù)和中小型業(yè)務(wù)。

大型業(yè)務(wù)的樣本量級(jí)很大，像主站推薦一天的樣本可能有千億，存儲(chǔ)能達(dá)到 p 的級(jí)別。迭代主要用流式迭代，即在線迭代特征和模型，速度會(huì)非常快。如果選用批式迭代的話，回溯樣本要 30 天，需要的資源是流式迭代的幾十倍，快手大場(chǎng)景下的流量分配又比較多，所以傾向于做在線的流式迭代實(shí)驗(yàn)，速度快，消耗資源量相對(duì)也少很多。

中小業(yè)務(wù)，一天的樣本大約在百億級(jí)別，存儲(chǔ)大概幾十 T。選擇流式迭代會(huì)需要頻繁上線迭代，而且流量分配也不夠。這種情況下一般盡量選用批式迭代，此時(shí)需要很大量級(jí)的計(jì)算樣本，比如要回溯至少 60 天以上，回溯樣本能達(dá)到 p 級(jí)別。因?yàn)閷?duì)于大模型來(lái)說(shuō)，如果數(shù)據(jù)量不夠，模型訓(xùn)練不充分，效果就會(huì)相應(yīng)地下降。所以在這種小的業(yè)務(wù)場(chǎng)景里，還是傾向于批式迭代，回溯更多天的樣本，以使模型達(dá)到一個(gè)更穩(wěn)定的狀態(tài)。在這種場(chǎng)景下面，會(huì)傾向于批次迭代實(shí)驗(yàn)。

3、推薦模型的數(shù)據(jù)量

這里是之前在快手發(fā)布的一個(gè)萬(wàn)億級(jí)別模型文章里的截圖，快手是個(gè)性化模型，所以參數(shù)量非常大。從圖中對(duì)比來(lái)看，OpenAI 的 GPT3 參數(shù)量是 175B，但快手參數(shù)量 1900B，已經(jīng)到萬(wàn)億級(jí)別了。主要是因?yàn)榭焓诌x用的是 SIM 長(zhǎng)序列模型，需要用戶長(zhǎng)期的興趣，然后把該序列輸入到模型。快手有億級(jí)用戶，life-long 興趣需 10 萬(wàn)以上序列，再加上千億級(jí)的樣本的疊加，因此參數(shù)量非常大，能達(dá)到 1.9 萬(wàn)億。雖然這 1.9 萬(wàn)億參數(shù)跟 OpenAI 的 GPT 3 模型的參數(shù)類(lèi)型不一樣，計(jì)算量也不太一樣。但從參數(shù)量級(jí)上來(lái)看，快手推薦是非常大的。

4、語(yǔ)言模型的演進(jìn)

推薦模型跟語(yǔ)言模型緊密相關(guān)，一般新模型都會(huì)在語(yǔ)言模型上去做迭代，成功之后就會(huì)引入推薦模型，比如 DN、RNN、Transformer。上圖是亞馬遜 3 月份時(shí)發(fā)布的一個(gè)圖，主要介紹了語(yǔ)言模型的一些進(jìn)展。

可以看到，17 年之前主要是 RNN 模型，RNN 模型是按次序去順序遍歷數(shù)據(jù)后訓(xùn)練，該模型對(duì)并行算力要求并不高，但模型收斂比較復(fù)雜，因?yàn)榭赡軙?huì)存在梯度消失的問(wèn)題。2017 年出現(xiàn) Transformer 之后，語(yǔ)言模型突破了原有的限制，可以做并發(fā)迭代，所以其算力大規(guī)模增長(zhǎng)。

圖中的樹(shù)分為三個(gè)部分：（1）紅線部分是 encoder-only 技術(shù)，最早是 Bert 模型；（2）綠線是 encoder-decoder 類(lèi)型，Google 主要選擇這一類(lèi)型；（3）藍(lán)線主要是 open API 里 ChatGPT 選用的類(lèi)型，這一類(lèi)模型發(fā)展得最好，因?yàn)樗銐蚝?jiǎn)單，只需要考慮 decoder，運(yùn)算量小，而且模型效果也會(huì)很好。

二、大規(guī)模模型數(shù)據(jù)處理

1、背景-實(shí)效性

快手對(duì)數(shù)據(jù)時(shí)效性要求很高，用戶看到視頻后會(huì)反饋到快手的 log 收集系統(tǒng)，該用戶的行為會(huì)實(shí)時(shí)地拼接推薦日志（推薦日志就是推薦服務(wù)落下來(lái)的特征），特征流加上行為流成為樣本流進(jìn)入后面的特征處理，然后進(jìn)入模型訓(xùn)練。模型訓(xùn)練完成后實(shí)時(shí)更新到在線預(yù)估，在線預(yù)估會(huì)根據(jù)模型的更新推薦出最符合用戶需求的一些視頻。該鏈路要求延遲必須要在一秒內(nèi)，需要將用戶行為盡快反饋到模型里，所以對(duì)于大數(shù)據(jù)處理的時(shí)效性要求是非常高的。

2、大數(shù)據(jù)量處理

快手有千萬(wàn)級(jí)用戶在線，不考慮行為多樣性的情況下，QPS 至少是千萬(wàn)級(jí)的，如果區(qū)分到行為的多樣性，這個(gè)組合數(shù)量就更爆炸了，高峰期大概每秒需要處理 30T 左右的狀態(tài)。

業(yè)界方案主要是采用 Flink 流式框架，但如果直接用 Flink 引入 state join，在并發(fā)幾千的情況下會(huì)造成大量的慢節(jié)點(diǎn)。因?yàn)?30T 狀態(tài)如果 1000 并發(fā)的話，需要存 30G 的狀態(tài)，如果 1 萬(wàn)并發(fā)也得存 3G。3G 在 1 萬(wàn)并發(fā)下的慢節(jié)點(diǎn)的概率會(huì)非常大。在這種情況下如果出現(xiàn)慢節(jié)點(diǎn)，需要幾個(gè)小時(shí)恢復(fù)，這對(duì)于推薦系統(tǒng)肯定是不能忍受的。

所以快手選擇了一個(gè)折中方案，把狀態(tài)下沉至高性能存儲(chǔ)上，然后采用無(wú)狀態(tài) hash join 的方式來(lái)做一個(gè)實(shí)時(shí) join 的狀態(tài)，只要用戶的行為和特征都到齊，就立即觸發(fā)樣本的下發(fā)，這樣就可以保證行為能夠及時(shí)地反饋到模型。雖然特征和行為來(lái)的順序不一樣，但通過(guò)外部的狀態(tài)，再加上 Flink 流式框架并行的操作，就能實(shí)現(xiàn)大規(guī)模高性能的 join。

3、復(fù)雜特征計(jì)算

在上述處理完成之后，是特征計(jì)算場(chǎng)景，主要有兩種計(jì)算，標(biāo)量計(jì)算和向量計(jì)算。標(biāo)量計(jì)算類(lèi)似于特征處理，比如要把某些值求和、求平均。在向量計(jì)算里，會(huì)對(duì)一批樣本同一列進(jìn)行一個(gè)同樣的操作，放在 GPU 通過(guò) cuda 計(jì)算。這樣，通過(guò)使用 GPU 和 CPU 協(xié)同的方式實(shí)現(xiàn)高性能計(jì)算，一些標(biāo)量操作在 CPU 上計(jì)算，內(nèi)存訪問(wèn)也會(huì)在 CPU 上進(jìn)行，然后傳輸?shù)?GPU 上去做高性能的 GPU 計(jì)算。

為了保證算法迭代的靈活性，采用了 DSL 抽象。因?yàn)?SQL 不能完全描述所有的特征處理場(chǎng)景。比如有一些在時(shí)間窗口的操作，如果通過(guò) SQL 去做需要寫(xiě)一些自定義的 UDF，這樣很不利于迭代。所以我們的 DSL 是用 Python 描述的，用戶可以通過(guò) Python 直接調(diào)用下層的高效執(zhí)行算子。第一步先寫(xiě)計(jì)算層，使用 C++ 實(shí)現(xiàn)一些高效的 operator，包括 cuda 和 CPU 相關(guān)的計(jì)算也都是通過(guò) C++ 庫(kù)去做的。在 runtime 下面采用 Flink 的分布式框架加上 GNI 的方式去調(diào)用 C++ 的這些算子，以達(dá)到高性能、高吞吐的處理。

4、推薦場(chǎng)景特點(diǎn)

推薦場(chǎng)景下有兩個(gè)特點(diǎn)，一個(gè)是批流一體，另一個(gè)是潮汐。

批式調(diào)研和在線實(shí)驗(yàn)這兩種場(chǎng)景會(huì)需要有批流一體，因?yàn)樵谂鷪?chǎng)景里調(diào)研特征或調(diào)研模型結(jié)構(gòu)完成之后，需要到在線去做上線，因此需要有一個(gè)批流一體的統(tǒng)一描述語(yǔ)言加上統(tǒng)一的執(zhí)行引擎。用戶在批式上調(diào)研，會(huì)使用 DSL、Hadoop 和 Spark 把所有的數(shù)據(jù)計(jì)算出來(lái)，做模型迭代。模型迭代成功之后做特征上線，上線到流式通用特征處理框架上，或是上線到流式特征框架特化的一個(gè)處理框架上。這里之所以會(huì)分出兩個(gè)節(jié)點(diǎn)，主要是因?yàn)橛幸恍┨卣魇撬心Ｐ凸玫模钥赡茉谕ㄓ玫目蚣芟旅妫@樣只需要計(jì)算一次。而在特化的算子下面則是一些模型所特有的特征，因此分開(kāi)處理。但這兩個(gè)計(jì)算引擎和語(yǔ)言描述其實(shí)是一樣的。同樣地，這些通用處理的數(shù)據(jù)需要落盤(pán)到批場(chǎng)景下。批場(chǎng)景下有很多是基于 base 的特征去迭代，會(huì)加入它自己的性價(jià)特征，所以在批次場(chǎng)景下面計(jì)算的也是 Delta。

上線完之后就會(huì)到在線服務(wù)，這里會(huì)有一個(gè)高性能的存儲(chǔ)和計(jì)算庫(kù)去承接，這一點(diǎn)在后文中還會(huì)講到。在流式場(chǎng)景下，注重的是高吞吐、低延遲和高可用。在批場(chǎng)景下，主要關(guān)注高吞吐、高可靠。

另外一個(gè)特點(diǎn)就是請(qǐng)求潮汐。上圖是請(qǐng)求潮汐的示意圖（并不是快手的真實(shí)流量）。從圖中可以看到，有早高峰和晚高峰兩個(gè)高峰。在高峰期需要給足在線的算力，在低峰期則要把冗余的算力利用起來(lái)。

在這種情況下，快手的大數(shù)據(jù)處理框架以及在線所有的模塊需要針對(duì)潮汐的特點(diǎn)，去做云原生架構(gòu)的一些改造，比如快速恢復(fù)、自動(dòng)伸縮、快速伸縮。快速伸縮主要是因?yàn)樵谧詣?dòng)伸縮的時(shí)候并不能保證是高效的，比如一次自動(dòng)伸縮需要耗一小時(shí)或者幾個(gè)小時(shí)之久，那么在線的請(qǐng)求在這幾個(gè)小時(shí)之間會(huì)有比較大的損失。

另外，還需要把在線服務(wù)的資源池和大數(shù)據(jù)處理的資源池統(tǒng)一起來(lái)，這樣所有資源在低峰期時(shí)可以把冗余算力給批式場(chǎng)景、大模型預(yù)訓(xùn)練場(chǎng)景或者大模型批量預(yù)估的場(chǎng)景，使資源得以利用。快手現(xiàn)在所有的架構(gòu)都在向云原生架構(gòu)演進(jìn)。

三、大規(guī)模模型數(shù)據(jù)存儲(chǔ)

1、存儲(chǔ)特點(diǎn)

大規(guī)模數(shù)據(jù)存儲(chǔ)的第一個(gè)特點(diǎn)就是超低延遲，因?yàn)榇鎯?chǔ)節(jié)點(diǎn)存儲(chǔ)的都是狀態(tài)，一些計(jì)算節(jié)點(diǎn)需要很多的狀態(tài)信息才能去計(jì)算，所以存儲(chǔ)節(jié)點(diǎn)大部分時(shí)間都是在葉子節(jié)點(diǎn)，而且推薦的在線實(shí)驗(yàn)有上千個(gè)模塊，每一個(gè)模塊只能給十毫秒以內(nèi)或者最多幾十毫秒的超時(shí)時(shí)間，因此要保證所有存儲(chǔ)節(jié)點(diǎn)都是低延遲、高吞吐并且高可用的。

推薦實(shí)驗(yàn)和推薦服務(wù) base 之間有一個(gè)互相切換的過(guò)程。一般并行的實(shí)驗(yàn)數(shù)量非常多，實(shí)驗(yàn)完成之后會(huì)去切換成一個(gè)在線的 base，這樣它承擔(dān)的流量就會(huì)非常大。比如在訓(xùn)練服務(wù) base 里會(huì)有召回的 base、粗排的 base和精排的 base，各個(gè) base 都需要去承擔(dān)千萬(wàn)級(jí)的 QPS，而且要提供超高的可靠性。所以在線存儲(chǔ)部分，大量選用的是全內(nèi)存架構(gòu)。

其次，快手有超大存儲(chǔ)的需求。前文中提到，快手大模型有 1.9 萬(wàn)億的參數(shù)量，如果換成普通八維的 float，需要的存儲(chǔ)也要有 64T，而且還有一個(gè)全用戶的行為序列，有 180T 左右的狀態(tài)信息。如果要采用全內(nèi)存的存儲(chǔ)，將會(huì)需要 2000 多臺(tái)機(jī)器。而且所有的狀態(tài)需要在 30 分鐘內(nèi)恢復(fù)，因?yàn)橥扑]系統(tǒng)如果超過(guò) 30 分鐘不恢復(fù)，會(huì)對(duì)線上產(chǎn)生非常大的影響，用戶體驗(yàn)會(huì)很差。

針對(duì)上述需求，我們的方案主要有以下幾個(gè)：

• 特征 score 的準(zhǔn)入：特征 score 可以理解為特征重要性，即將一些重要性比較低，對(duì)預(yù)估效果影響也微乎其微的特征不放在在線存儲(chǔ)上。
• LRU 和 LFU 的淘汰：因?yàn)槭窃诰€的模型，需要保證可靠性，即內(nèi)存需要維持在一個(gè)穩(wěn)定范圍內(nèi)，不能一直增長(zhǎng)。因此我們將最遠(yuǎn)更新的優(yōu)先淘汰，最先訪問(wèn)的優(yōu)先保留。
• NVM 新硬件技術(shù)：全內(nèi)存架構(gòu)的資源消耗也是一個(gè)非常大的問(wèn)題。我們引入了 NVM 硬件技術(shù)。NVM 是一個(gè)持久化存儲(chǔ)，是 Intel 新發(fā)布的一個(gè)硬件，它會(huì)在 DR 和 SSD 之間，有接近于內(nèi)存的速度，同時(shí)有接近于 SSD 的存儲(chǔ)空間，既能兼顧存儲(chǔ)也能兼顧性能。

2、存儲(chǔ)方案-NVM Table

存儲(chǔ)方案是 NVM Table，分成異構(gòu)存儲(chǔ)的三層：物理層提供底層存儲(chǔ)的 API，包括 NVM 存儲(chǔ)和 memory 存儲(chǔ)；中間 memory pool 封裝統(tǒng)一的管理功能，把 NVM 和 memory 的模塊都管理起來(lái)；上層業(yè)務(wù)通過(guò) memory pool 的一個(gè) API 去調(diào)用下層的 NVM 和 memory，提供統(tǒng)一的查詢邏輯。

在數(shù)據(jù)結(jié)構(gòu)布局方面，memory pool 采用的是 block 接口抽象。將 NVM 和 memory 分成若干不同的、可通過(guò)全局統(tǒng)一地址來(lái)訪問(wèn)的 block，這樣就可以實(shí)現(xiàn) zero copy 的訪問(wèn)自由化。對(duì)于一些頻繁訪問(wèn)的 key，會(huì)放到 mem-key 上。不常訪問(wèn)的 key 會(huì)放在到 NVM 上。一些索引的 key 會(huì)頻繁訪問(wèn)，但查找到 key 之后，其 value 在最后要返回給上游的時(shí)候才會(huì)用到，并且量級(jí)較大，所以將 value 放到持久化的存儲(chǔ)。Key 查詢比較多，同時(shí)也比較小，所以放在內(nèi)存，這樣就實(shí)現(xiàn)了內(nèi)存和 NVM 的零拷貝技術(shù)。這里的哈希表采用了業(yè)界領(lǐng)先的無(wú)鎖技術(shù)，以減少臨界區(qū)的競(jìng)爭(zhēng)，完成高效存儲(chǔ)。

從 NVM Table 的一個(gè)場(chǎng)景測(cè)試數(shù)據(jù)可以看出，其網(wǎng)絡(luò)的極限吞吐與 JIRA 是相當(dāng)?shù)摹？缇W(wǎng)絡(luò)訪問(wèn)一般是網(wǎng)絡(luò)達(dá)到極限，所以 NVM 帶寬可以完全覆蓋網(wǎng)絡(luò)帶寬，瓶頸主要在網(wǎng)絡(luò)上，這樣就能保證 NVM 既有成本上的收益，也有大存儲(chǔ)和高吞吐的收益。另一方面，恢復(fù)時(shí)間也下降了 120 倍。最開(kāi)始恢復(fù) T 的數(shù)據(jù)需要兩個(gè)小時(shí)，采用 NVM 之后只需要2分鐘。

3、存儲(chǔ)方案-強(qiáng)一致性

存儲(chǔ)方面，還有強(qiáng)一致性的需求，主要是因?yàn)樵谕扑]場(chǎng)景里也有一些廣告和電商的推薦，需要存儲(chǔ)的副本特別多。因?yàn)楫?dāng)一些新的短視頻或者新物料進(jìn)來(lái)時(shí)，下游所有模塊會(huì)有一個(gè)并發(fā)分發(fā)，需要保證這些視頻在 10 秒內(nèi)到達(dá)所有的推薦服務(wù)，且所有推薦服務(wù)里的狀態(tài)需要保證一致。否則對(duì)于模型的效果影響很大。

我們采用了 Raft 協(xié)議加 BT 的模式。Raft 協(xié)議主要負(fù)責(zé)選組和同步數(shù)據(jù)，BT 的模式主要是改造 BT 同步的模式，比如在幾千上萬(wàn)臺(tái)機(jī)器規(guī)模下的同步，如果同時(shí)用主從同步的話，主節(jié)點(diǎn)的出口帶寬可能會(huì)是從節(jié)點(diǎn)的千倍以上，帶寬就會(huì)成為瓶頸，下發(fā)的狀態(tài)就會(huì)非常少，高吞吐和數(shù)據(jù)同步會(huì)受到影響。

我們的方案是分布式的平衡樹(shù)分發(fā)，構(gòu)造一個(gè)平衡二叉樹(shù)，把所有主從節(jié)點(diǎn)進(jìn)行組織，每個(gè)節(jié)點(diǎn)只管有限個(gè)從節(jié)點(diǎn)，從而保證從主節(jié)點(diǎn)同步到葉子節(jié)點(diǎn)所需要的帶寬不變，但是單節(jié)點(diǎn)的帶寬限制為小于等于 2，這樣在全局下既能做到一次性，也能做到高效地同步，10 秒內(nèi)即可將所有視頻狀態(tài)分發(fā)到每個(gè)節(jié)點(diǎn)。

四、展望

推薦模型的發(fā)展跟語(yǔ)言模型是相關(guān)的，從 DNN 模型到 Wide&Deep，到 Transformer，再到 SIM 長(zhǎng)序列及生成式模型，模型增長(zhǎng)了很多倍。除了模型的增長(zhǎng)，算力增長(zhǎng)也會(huì)隨視頻的增長(zhǎng)和用戶的增長(zhǎng)，呈現(xiàn)出指數(shù)級(jí)的上升。從統(tǒng)計(jì)數(shù)據(jù)來(lái)看，最近兩年推薦模型的算力增長(zhǎng)接近 10 倍，我們的方案主要是優(yōu)化工程架構(gòu)和新的硬件技術(shù)。

生成式模型會(huì)帶來(lái)計(jì)算量的爆炸，因?yàn)樗且粋€(gè) token-based 的推薦，每次推薦需要之前所有的 token 作為 context，在這種情況下生成的效果才會(huì)最好。如果沒(méi)有 token-based，那么與算力不會(huì)呈指數(shù)級(jí)增長(zhǎng)。因此，推薦的壓力，將主要來(lái)自狀態(tài)存儲(chǔ)的大規(guī)模提升，因?yàn)槟壳暗耐扑]模型主要是 pointwise 的推薦，對(duì)于長(zhǎng)序列推薦模型算力也是有限的。如果全部采用深層次模型推薦，其狀態(tài)存儲(chǔ)還將再增長(zhǎng) 10 倍，挑戰(zhàn)會(huì)非常大。因此我們需要通過(guò)一些新硬件，比如 CXL、NVM 以及新推出的 Grace 架構(gòu)，再加上工程上的優(yōu)化，比如狀態(tài)做差分、傳輸計(jì)算等等，來(lái)應(yīng)對(duì)未來(lái)的挑戰(zhàn)。