一、模型場景介紹

1、實時大模型

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

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

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

總結(jié)起來，數(shù)據(jù)處理的特點是既大，又要實時。

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

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

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

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

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

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

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

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

4、語言模型的演進

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

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

圖中的樹分為三個部分：（1）紅線部分是 encoder-only 技術(shù)，最早是 Bert 模型；（2）綠線是 encoder-decoder 類型，Google 主要選擇這一類型；（3）藍線主要是 open API 里 ChatGPT 選用的類型，這一類模型發(fā)展得最好，因為它足夠簡單，只需要考慮 decoder，運算量小，而且模型效果也會很好。

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

1、背景-實效性

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

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

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

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

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

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

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

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

4、推薦場景特點

推薦場景下有兩個特點，一個是批流一體，另一個是潮汐。

批式調(diào)研和在線實驗這兩種場景會需要有批流一體，因為在批場景里調(diào)研特征或調(diào)研模型結(jié)構(gòu)完成之后，需要到在線去做上線，因此需要有一個批流一體的統(tǒng)一描述語言加上統(tǒng)一的執(zhí)行引擎。用戶在批式上調(diào)研，會使用 DSL、Hadoop 和 Spark 把所有的數(shù)據(jù)計算出來，做模型迭代。模型迭代成功之后做特征上線，上線到流式通用特征處理框架上，或是上線到流式特征框架特化的一個處理框架上。這里之所以會分出兩個節(jié)點，主要是因為有一些特征是所有模型公用的，所以可能在通用的框架下面，這樣只需要計算一次。而在特化的算子下面則是一些模型所特有的特征，因此分開處理。但這兩個計算引擎和語言描述其實是一樣的。同樣地，這些通用處理的數(shù)據(jù)需要落盤到批場景下。批場景下有很多是基于 base 的特征去迭代，會加入它自己的性價特征，所以在批次場景下面計算的也是 Delta。

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

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

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

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

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

1、存儲特點

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

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

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

針對上述需求，我們的方案主要有以下幾個：

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

2、存儲方案-NVM Table

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

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

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

3、存儲方案-強一致性

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

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

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

四、展望

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

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