一、模型場景介紹

1、實時大模型

*本文數據具有即時性，不代表實時數據。

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

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

總結起來，數據處理的特點是既大，又要實時。

2、推薦業務復雜

一般的推薦業務架構如上圖所示，在視頻池里（比如有幾千萬的視頻）會經過固定的四個階段：

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

快手的業務類型比較多樣，主要可以分成大型業務和中小型業務。

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

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

3、推薦模型的數據量

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

4、語言模型的演進

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

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

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

二、大規模模型數據處理

1、背景-實效性

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

2、大數據量處理

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

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

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

3、復雜特征計算

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

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

4、推薦場景特點

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

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

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

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

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

另外，還需要把在線服務的資源池和大數據處理的資源池統一起來，這樣所有資源在低峰期時可以把冗余算力給批式場景、大模型預訓練場景或者大模型批量預估的場景，使資源得以利用。快手現在所有的架構都在向云原生架構演進。

三、大規模模型數據存儲

1、存儲特點

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

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

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

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

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

2、存儲方案-NVM Table

存儲方案是 NVM Table，分成異構存儲的三層：物理層提供底層存儲的 API，包括 NVM 存儲和 memory 存儲；中間 memory pool 封裝統一的管理功能，把 NVM 和 memory 的模塊都管理起來；上層業務通過 memory pool 的一個 API 去調用下層的 NVM 和 memory，提供統一的查詢邏輯。

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

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

3、存儲方案-強一致性

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

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

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

四、展望

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

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