獨家揭祕：騰訊千億級參數分佈式ML系統無量背後的祕密

做者 | 袁鐿

編輯 | Vincent

AI 前線導讀：千億參數規模的模型已經被業界證實可以有效提升業務效果。如何高效訓練出這樣的模型？百 GB 級別的模型如何在線上實現毫秒級的響應？這些能力在各個大廠都被視爲核心技術競爭力和機器學習能力的技術壁壘。要具有這樣的能力，對相關係統有什麼樣的挑戰？本文將從系統的角度去詳細分析這些問題，並給出騰訊公司的無量系統對這些問題的解答。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

簡 介

在互聯網場景中，億級的用戶天天產生着百億規模的用戶數據，造成了超大規模的訓練樣本。如何利用這些數據訓練出更好的模型並用這些模型爲用戶服務，給機器學習平臺帶來了巨大的挑戰。下面以網頁 / 圖文 / 視頻推薦場景分析這些挑戰，下文中均稱爲推薦場景。

1. 樣本數量大。在推薦場景下，天天的樣本量能夠達到百億量級。若是須要按一個月的樣本進行訓練，樣本量會在千億級別。若是每一個樣本平均 500 特徵值，單個樣本的大小就是 5KB 左右，一千億樣本的大小就是 500TB。即使只使用一週內的樣本，樣本數據的大小也在 100TB 這個級別。

2. 特徵維度多。巨大的樣本量使高維度模型的訓練成爲可能。爲了給用戶提供更合理的推薦結果，須要對用戶和被推薦的文章 / 圖片 / 視頻進行詳細的描述。各個業務都會創建起豐富的用戶模型，也會對文章 / 圖片 / 視頻進行多維度的標註。

   在系統進行推薦時，還會使用到用戶如今的上下文信息，好比：時間，位置，以前瀏覽的頁面等。當這些特徵被引入到模型中時，會致使特徵規模的迅速增長。若是再考慮交叉等特徵轉換操做，模型的特徵維度會輕鬆地膨脹到千億甚至萬億級別。

3. 訓練性能要求高。咱們面對的是百 TB 的樣本和百億 / 千億參數的模型。而業務須要在短期內訓練出一個性能指標好的模型，以便快速上線驗證。這對機器學習平臺訓練能力有很高的要求。

前面 1～3 點，提出的是超大規模模型的訓練框架面臨的挑戰，然而訓練出模型只是重要的第一步。最終模型須要上線爲用戶提供服務才能體現其業務價值。對於以往的機器學習中的中小模型，模型上線服務並非一個特別被關注的事情。可是，當最終模型文件很大，甚至超過單機的內存大小時，模型上線服務就變成了棘手的問題。

1. 模型大但用戶須要毫秒級響應。以最簡單的 LR 模型爲例，一個 10 億特徵的模型的大小也會達到 12GB（每一個參數須要一個 8Byte 的 key 和 4Byte 的 float value）。若是是 DNN 模型，模型大小到達 TB 也是可能的。當訓練好一個模型後，模型就被上線，爲用戶提供預測服務。 爲了達到良好的用戶體驗，預測服務的響應時間須要在 10ms 這個量級。以手機用戶的推薦場景爲例，從用戶在手機上刷新頁面到看到推薦結果，時間不能超過 1s，扣除掉網絡通信的開銷，IDC 內在線服務的響應時間須要控制在 200ms 之內。可是，整個推薦的流程至少有召回，排序和展現控制三個階段。 在排序階段，須要對 200 個以上的文章進行特徵拼接和點擊率預估，因此模型對這 200 個文章進行點擊率預估的總時間要在 30ms 之內。如何使用這麼大規模的模型進行高性能，高併發的預測也對平臺能力的重大考驗。

2. 模型實時上線。對於資訊推薦類場景，用戶的關注點變化很快。系統須要根據最新的用戶行爲數據調整模型，而後以最快的速度將如此大規模的模型更新到多個地區的在線預測服務。

爲了解決以上挑戰，咱們：

1）開發了一個基於參數服務器架構的機器學習計算框架 -- 無量框架，已經可以完成百億樣本 / 百億參數模型的小時級訓練能力。無量框架提供多種機器學習算法，不但能進行任務式的離線訓練，還能支持以流式樣本爲輸入的 7*24 小時的在線訓練。

2）在無量框架的基礎上，咱們構建起自動化模型管理系統 -- 無量模型管理，模型可以在離線訓練任務，在線訓練集羣和在線預測服務之間無縫地高效流轉，實現 10GB 級模型的分鐘級上線。

3）爲了提升大模型的線上預測服務，咱們還開發了高性能的預測模塊和服務 -- 無量預測服務，對於數十 GB 的模型，只需幾毫秒便可完成 100 個樣本的預測。

無量框架，無量模型管理和無量預測服務共同構成了無量系統的主要部分。下面咱們將對無量系統的架構和各個主要組成部分進行詳細的介紹。

1. 系統流程與架構

工做流程

在廣告 / 推薦等場景下，模型的生產和使用過程，大體分爲幾個步驟：

1.日誌採集與樣本生成。經過收集用戶的線上行爲信息，生成模型須要的樣本。這些樣本能夠被存儲起來用於離線訓練，也可使用流式數據的方式推送給在線訓練集羣。

2.模型訓練。有了樣本以後，在訓練集羣中訓練出具體的模型。開發人員經過調整的超參數或模型結構來獲取好的模型。

3.模型評估。在模型被放到線上服務以前，須要對模型進行一些評估工做。

4.模型上線預測。無量系統目前包括以上步驟中的模型訓練，模型評估和上線預測。

爲了讓模型從訓練集羣到在線預測服務順利地流轉，無量系統提供了模型管理功能，可以自動化地將從訓練機器導出新模型到在線預測服務。業務也可以在模型自動化上線過程當中定義模型評估操做，避免訓練效果差的模型被放到在線預測服務中。另外當模型上線以後，也須要驗證線上的模型是否有問題。

在模型的開發過程當中，超參數調試耗費了模型開發人員大量的時間。無量系統經過與般若系統結合，實現了模型訓練效果的實時監控，爲自動化調參提供了決策數據。無量系統正在進行自動調參工具的開發。算法人員也能夠基於這些數據上實現自定義自動調參功能。

系統架構

在一個機器學習系統中，機器學習算法的代碼只是訓練或預測過程當中很是小的一部分。如下是 Google 對其機器學習系統的一個統計。

[1 ] Hidden Technical Debt in Machine Learning Systems, Google.

爲了讓機器學習任務運行起來，須要大量的配套服務設施的支持，包括數據管理與存儲，訓練框架，在線預測框架和資源管理等多個模塊。無量系統的系統架構以下所示：

系統架構圖

無量系統的訓練任務運行在 MIG 專門針對機器學習和深度學習任務的般若調度系統上，在線訓練集羣和在線預測服務部署在 Sumeru 系統上。般若系統和 Sumeru 系統均是基於 docker 容器化技術構建，爲無量系統的快速部署和擴展提供了可靠的基礎設施保障。

下層存儲系統支持 HDFS 和 ceph 兩種分佈式網絡存儲。HDFS 做爲經常使用的分佈式網絡存儲，與其餘的數據分析系統無縫對接。Ceph 以其高性能與靈活的文件操做，彌補了 Hdfs 在文件操做上的不便。

日誌採集使用 MIG 的燈塔系統，並配合了自研的流式數據處理服務實時生成訓練樣本。

經過自研的基於參數服務器架構的無量計算框架，無量系統支持了千億級模型的任務型離線訓練和流式在線訓練。無量計算框架採用 C++ 實現以達到優異的性能，並支持了推薦和搜索場景經常使用的 LR/FM/FFM/DNN 等模型，用戶只需作簡單的配置便可實現超大規模模型的訓練。

對於千億級參數的模型，模型大小至少會有幾十 GB。無量系統爲業務的在線預測服務提供了兩種模型使用模式：

1）模型服務組件。模型服務組件包含了模型版本管理和模型預測兩個主要功能。因爲模型服務組件對內存管理進行深度優化，業務可以在本身的預測服務中直接加載和使用 100G 如下的模型。

2）模型存儲服務。當模型大小超過單機可以存放的大小時，就須要分佈式的模型存儲服務來進行模型管理和提供預測服務。

在樣本生成，模型訓練，在線預測模塊之上，是無量系統的平臺服務。用戶在這裏管理本身的數據，訓練任務和模型。

至此，咱們簡單介紹了無量系統的各個部分。讓讀者可以對無量系統有一個總體的瞭解。下面，咱們將重點介紹無量計算框架，模型管理與模型預測服務。

2. 無量計算框架

爲了獲得一個好的模型，至少須要三個方面的內容：1. 數據；2. 模型和算法；3. 計算框架。

正如前面介紹中所述，互聯網用戶爲咱們產生了大量的樣本數據，爲學習出一個好的模型提供了數據基礎。在本節中，咱們將重點介紹後面兩部份內容。

首先咱們會介紹推薦場景經常使用的模型和算法，並由此推導出爲了實現這些模型的訓練，對計算框架有什麼樣的需求，以及無量計算框架如何知足這些需求，實現高性能的模型訓練。

推薦模型與算法

隨着商業化推薦的興起，預測用戶點擊率（Click Through Rate，簡稱 CTR）領域獲得了大量的研究關注，產生了不少 CTR 預估模型。下面對大規模場景下的幾個表明性的模型作簡單的對比介紹。他們分別是 LR，FM，DNN。對於推薦場景中經常使用的 GBDT 算法，因爲其不適應大規模特徵的輸入，在此不作對比。

LR 模型

LR 是一個簡單而有用的線性模型。優勢：它實現簡單並且很是容易支持大規模特徵的樣本輸入。在實際應用中，每每能取得不錯的效果，經常被用做 baseline。缺點：因爲是線性模型，須要大量的特徵工程的工做來讓它獲得好的效果。而特徵交叉等操做也直接致使了模型的特徵空間急劇膨脹。

FM 模型

FM 在 LR 線性模型的基礎上，引入了二次項，使得 FM 模型可以自動學習特徵之間的二階交叉關係。優勢：自動學習二階交叉關係，減小了部分特徵工程的工做。缺點：要學習二階以上的交叉關係，仍然須要進行交叉特徵選擇的工做來生成相應的樣本。

DNN 模型

隨着深度神經網絡（DNN）在圖像、語音等領域的突破性發展，DNN 被引入到 CTR 模型中來，但願學習到特徵之間的複雜關係，獲得更好的模型。在 CTR 預估中，輸入特徵是高維稀疏的，不能直接使用全鏈接網絡直接進行學習，因此用於 CTR 預估的網絡通常採用 embedding 層 + 全鏈接層的結構。經過 embedding 層將稀疏特徵轉換爲低維稠密特徵，再輸入後面的全鏈接層。優勢：能夠直接輸入原始特徵，減小了交叉特徵的選擇工做。缺點：訓練調參相比 LR 和 FM 等更難。因爲 DNN 稠密參數的引入，訓練性能也比 LR 和 FM 更低。

[Google 2016] Wide & Deep Learning for Recommender Systems

前面簡單介紹了三種表明性的模型，在這三種基本結構上，經過不一樣的組合和改進，衍生出了 FFM，FNN，DeepFM，DIN 等模型結構。若是想詳細瞭解相關的模型，請見參考文獻 [3][4]。

從上面的模型基本結構，咱們能夠總結出 CTR 模型的參數特色：

1）超大規模稀疏的輸入特徵參數。LR，FM 和 DNN 的 embedding 層的輸入都是稀疏的，參數值多是一個單獨的值（LR 的 w），也有多是一個向量（FM 中的 w+v 和 embedding 層的 w）。

2）稠密的交叉關係參數。DNN 中全鏈接層參數都是稠密的。

由此能夠看出，計算框架須要同時支持稀疏和稠密兩種參數格式。另外，一些統計類特徵（例如：文章的曝光數，點擊率等）在訓練中也是很重要的。這些參數也須要在訓練過程當中方便地計算獲得。

在推薦場景下，可推薦的內容存在必定的時效性，隨着熱點的變化，用戶的關注點也會發生相應的變化，致使 CTR 模型應用到線上後，預測性能會隨着時間的流逝而降低，因此 CTR 模型都須要進行及時的更新。在不一樣的業務應用場景下，這個更新頻率能夠是分鐘級，也多是天級別的。 然而，從新訓練一個百億規模的模型會消耗大量的時間和計算資源，爲了以低廉的資源成本完成模型的及時更新，推薦場景下會採用在線訓練的方式。因此計算框架須要支持多種在線訓練算法。目前應用於在線訓練的優化算法主要有 Ftrl，Adagrad 等。

高性能大規模並行機器學習框架

在咱們的系統設計目標中有三個關鍵維度：

1）千億級模型參數；

2）千億級樣本數據；

3）高性能。

如何同時提升上面的三個維度的目標，咱們須要仔細分析分佈式計算過程。以如今經常使用的基於梯度降低的分佈式優化算法爲例。在使用樣本數據 I 進行一輪訓練的過程當中，有如下幾個基本步驟，

1) 數據分片，將全部數據拆分後分配到多臺機器上；

2) 並行計算 g，各臺機器上的計算節點按照指定算法計算梯度；

3) 聚合 g，將各臺機器上計算的 g 收集起來；

4) 更新 w，使用上一步獲得的 g 更新 w；

5) 廣播 w，將更新後的 w 傳輸給計算機器。

這樣的學習邏輯經過將數據分佈到多臺機器上計算，有效地解決了樣本數據量的問題。Hadoop 和 Spark 都採用這樣的邏輯進行機器學習，Spark 因爲 RDD 的方式充分利用內存來存儲中間數據，大大提升了訓練性能。可是在這樣的訓練邏輯下，存在兩個問題：

1) w 被存儲在一臺機器上，限制了框架可以訓練的模型的規模，只能是單機可存儲的模型，以 128G 的內存的機型爲例，10 億個參數的模型就達到他的存儲極限了；

2) w 被廣播給各個機器。因爲是廣播推送方式，當模型規模變大的時候，廣播操做帶來的帶寬成本會急劇增長。以咱們的測試來講，用 Spark 訓練一個百萬參數的模型時就發現性能難以忍受了。

以上分佈式訓練邏輯是梯度降低算法的邏輯，而如今機器學習尤爲是深度學習中普遍使用的是隨機梯度降低算法（SGD）。模型參數是以 minibatch（128 個樣本，甚至更少）爲單位來更新的。這致使參數更新頻率急劇提高，帶來的是巨大的網絡帶寬需求。因此必需要解決上面兩個問題，纔可以進行千億級參數的模型訓練。參數服務器架構由此產生。

參數服務器的基本結構和工做流程圖

從 2010 年被提出，通過了幾年的發展演進，如今廣泛使用的是第三代參數服務器架構。相對於前面 Algorithm 1 的流程，參數服務器有兩點主要的不一樣：

1) 有一種新的角色 Server，專門用於分佈式地存儲模型參數，並進行參數的更新計算。這使得可以訓練的模型規模再也不受限於單機的內存大小，同時將多個 worker 節點的參數請求分攤到多個 server 上，減小了單個 server 上因參數和梯度傳輸致使的網絡瓶頸。

2) 負責計算的 Worker 節獲取參數的方式是 pull 方式。因爲不是被動的等待廣播參數，pull 方式使得 worker 節點能夠根據訓練數據的需求來獲取參數。尤爲是在推薦場景下，樣本都是很是稀疏的。 舉例來講，一個模型可能有 100 億個特徵輸入，而具體到一個特定的樣本，只會有幾百個有效特徵值。因此只須要獲取與這幾百個有效特徵值有關的參數便可，而不須要傳輸整個模型。

簡而言之，參數服務器架構下，多個 server 分攤參數存儲和傳輸的壓力，多個 worker 按需獲取和更新參數下降了參數和梯度傳輸的網絡需求。這使得千億參數模型的高性能訓練成爲了可能。

經過上面的分析，咱們獲得瞭如下的結論。參數服務器可以在模型規模，樣本數量和訓練性能三方面知足咱們的設計要求。

Hadoop/Spark/ 參數服務器對比

瞭解了通用的參數服務器架構以及其特色，咱們回到無量計算框架，繼續分析一個通用的參數服務器架構在實際中面臨的問題以及咱們的解法。

在模型和算法的分析中，咱們知道，要實現兩類稀疏和稠密兩類參數的傳輸與更新。

1）超大規模稀疏的輸入特徵參數。這裏稀疏有兩層含義。

首先，模型可能的參數是千億個，可是由於並非全部特徵都有可能出如今訓練樣本中，因此通常不會全部參數都有值，通常最終的模型可能只有 1/10 的參數是有值的。若是使用了稀疏化的技術，這個比例會更低。

其次，對於每一個樣本只會使用到很是少的特徵。在一個千億特徵的模型中，單個樣本一般只會命中到幾百個特徵。

從上面的分析中，能夠看出，參數服務器架構在大規模稀疏特徵的模型訓練中尤其高效。由於 worker 訓練一個 minibatch 的樣本時，只須要獲取與這些樣本相關的參數便可，若是每一個樣本平均有 500 個特徵，那麼 100 個樣本最多隻須要獲取 5 萬個特徵的相關參數便可。

2）稠密的交叉關係參數。與稀疏的輸入特徵參數不一樣，交叉關係參數規模相對較小，可是每一個樣本的訓練會使用到所有的稠密參數。假設全鏈接層中最大的一層是 1024*512，那麼每次計算使用到的稠密參數就是在 50 萬這個量級。

從這裏咱們能夠看出，稀疏和稠密兩種參數在訓練過程當中存在不一樣的性質。稀疏參數整體規模大，可是每次訓練只使用到很小的一部分。稠密參數整體規模相對較小，可是每次訓練都須要被所有使用到。因爲兩種類型參數的性質差別，被天然地切分紅了基於 Kv 和基於矩陣的數據結構。

下面咱們繼續分析訓練各個階段的性能問題與咱們的解法。

1）參數獲取。在實際的超大規模模型的訓練中，網絡常常成爲性能瓶頸。爲了減小由於參數獲取而致使的網絡傳輸壓力，咱們引入了參數緩存機制，worker 並非每一個 minibatch 都從 server 獲取最新的參數。然而，在分佈式訓練中，緩存模型參數存在訓練正確性的風險。 因爲在數據並行狀況下，各個計算節點使用的訓練數據是不一樣的，若是進行屢次訓練而不一樣步更新參數，則模型可能出現沒法收斂的問題。在學術研究領域，這是一個訓練的網絡帶寬與模型訓練正確性保障的問題。已有不一樣的同步控制協議的研究。 咱們的實現借鑑了 ssp 協議 [5] 中有限版本差別的思想，經過控制緩存的使用次數，在保障訓練正確性的前提下，減小因參數獲取而致使網絡傳輸。

2）梯度更新。計算完成後的梯度上傳也會有大量的數據須要經過網絡傳輸。按照模型的梯度計算邏輯，全部使用到的參數都會獲得相應的梯度。可是，是否須要發送某個參數的更新，或者以什麼樣的方式發送給Server倒是能夠選擇的，這個過程稱爲梯度壓縮。梯度壓縮的方法大體能夠分兩類：

1）梯度量化。將梯度從double/float等原始類型量化成二值/三值等用幾個bit就能表示的類型，以減小傳輸數據量。

2）梯度稀疏化。選擇重要的梯度當即上傳，不是很重要的梯度更新，則累積起來，稍後再上傳。如讀者對這個研究領域感興趣，能夠閱讀參考文獻[6][7]。

傳統的梯度壓縮技術存在與模型大小至關的內存消耗，因此主要使用在單機可存儲的稠密模型的訓練中，在無量所應對的超大規模模型的訓練中，咱們對現有的梯度壓縮技術進行了改進，使之適應了百億稀疏參數規模模型的訓練，能夠減小99%以上的梯度傳輸而不影響訓練效果。

3）梯度計算。在機器學習，尤爲是深度學習過程當中，模型的梯度計算過程會有大量的數值計算操做。除了使用多線程並行訓練的方式充分利用多個 cpu 的計算能力，咱們還使用 SSE 等 CPU 並行計算指令和 Eigen 線性計算庫實現梯度計算過程，充分利用了 CPU 芯片的流水線和並行指令能力，比單純的多線程並行的計算性能高 10+ 倍。

在實際的生產環境中，數據被存放在 hdfs 集羣上，而訓練時拉取數據變得很耗時。咱們經過將數據讀取異步化，使得數據讀取不影響訓練的參數傳輸，梯度計算和更新過程。同時經過優化數據讀取模塊的內存管理和樣本緩存機制，以極小的內存開銷知足訓練對樣本隨機性的需求。

3. 無量模型管理 -- 全流程模型管理

在推薦類業務中，文章和視頻資料快速更新，社會熱點隨時出現和消失，用戶的興趣也常常變化。爲了取得優秀的推薦效果，不少具備時效性的特徵信息被加入到預測模型中，致使 CTR 模型須要及時更新。無量系統提供了全流程的模型管理服務。

模型流轉的基本流程

在管理超大規模的模型時，存在兩個主要的挑戰：

1）模型超大致使的模型上線性能的問題。對於千億參數的模型，若是每一個參數都以 4 字節的 float 格式存儲，最終存儲的模型將會接近 TB 級別。若是要實現分鐘級別地將新模型更新到多地的在線預測服務上，僅從數據傳輸和文件解析的性能上看，每次都使用全量模型的方式就是不可行的。 幸運的是，模型在訓練過程當中的變化是漸進的，而當模型上線時，是一個相對穩定的狀態，在線訓練更多的是對模型的微調。所以，對於超大規模的模型，通常採用全量 + 增量的方式進行管理。首先使用全量模型加載到線上服務，而後按期將模型的差別部分以增量的方式疊加到線上服務的模型中。

2）模型分片致使的管理問題。在全量 + 增量的模型上線模式下，線上服務的模型對應着多個模型文件。若是線上服務出現故障須要恢復或者由於請求量上升須要擴容時，就須要使用多個模型文件來恢復出模型。在某些狀況下，業務發現當前模型效果差，須要替換模型或者進行版本回滾時，須要另外的一組模型文件。 另外，不一樣於單機可存儲的模型，在參數服務器框架下，模型被分片存儲在不一樣的機器上。爲了提升模型導出效率，多個 server 節點會並行導出多個模型分片文件。假設存在 100 個 server，那麼就會有 100 個模型分片文件。給模型管理工做帶來了挑戰。

爲了不模型開發和使用者陷入這些管理問題，同時也爲了保障系統的穩定運行，無量模型管理服務將全部模型管理的相關工做承接下來。用戶只需進行必要的配置，模型管理服務就會自動地發現新版本的模型，驗證模型的完整性並將新模型傳輸和發佈到指定的在線預測服務中。 對用戶徹底屏蔽下層相似全量，增量，分片等細節。後期，用戶還能夠自定義模型驗證的方法，對即將上線的模型進行模擬請求等校驗，避免有效果差的模型被上線，給業務形成損失。

4. 無量模型服務

使用千億參數的大模型進行線上預測，面臨有許多的問題，下面咱們就一些主要問題進行分析並介紹咱們的方案：

1）模型加載的內存問題。當被加載到內存中時，須要構建相關的數據結構，所消耗的內存大小會比模型文件大不少。以最簡單的 LR 模型爲例，每一個特徵只會有一個 float 類型的模型參數，一個 10 億有值特徵的模型的文件大小大概是 12GB（每一個特徵 8 字節 key+4 字節值 value）。使用 stl 標準庫中 unordered_map 加載這個模型須要超過 25GB 的內存。也就是說會有超過模型大小 1 倍的內存開銷，這使得單機可以存儲的模型大小受到極大的制約。 咱們本身實現了一個 hash_map：tl_hash_map，專門針對模型稀疏參數特色進行了內存優化。內存消耗只比模型數據大 20% 左右。這意味着 tl_hash_map 有效地提升了可以被單機存儲的模型的大小極限。以 128GB 內存的機器爲例，使用 tl_hash_map，最大能支持的 lr 模型文件大小是 100GB 左右，而標準 unordered_map 最大能支持 50GB 左右。

2）模型服務的性能問題。爲了達到良好的用戶體驗，預測服務的響應時間須要在 10ms 這個量級。以手機用戶的推薦場景爲例，從用戶在手機上刷新頁面到看到推薦結果，時間不能超過 1s，扣除掉網絡通信的開銷，IDC 內在線服務的響應時間須要控制在 200ms 之內，而整個推薦的流程至少有召回，排序和展現控制三個階段。在排序階段，須要對 200 個以上的文章進行特徵拼接和點擊率預估，因此模型對這 200 個文章進行點擊率預估的總時間要在 30ms 之內。

從排序服務發出請求開始，到請求完成，至少存在兩個性能瓶頸點：

1）請求包的網絡傳輸與編解碼。爲了預測文章的可能點擊率，須要爲每一個文章準備全部的樣本特徵。假定每一個樣本有 500 個特徵，那麼 200 個文章的請求就有 10 萬個特徵。整個請求包的數據會有 1MB 左右。網絡傳輸和編解碼的性能對整個 rpc 框架都帶來了極大的挑戰。咱們定義了一套針對模型預測場景的特徵編解碼格式，避開了現有 rpc 框架在編解碼格式上的性能缺點，而且最大化地減小了須要傳輸的數據大小。

2）模型參數查詢和計算性能。爲完成模型的預測功能，首先須要從模型中找到須要的參數，而後完成預測值的計算。面對超大規模的模型，首先要解決的就是模型存儲方式的問題。若是模型可以單機存儲，那麼模型參數的查詢則能夠在本機完成。若是模型超過單機存儲的極限，則須要使用分佈式存儲的方式提供查詢服務。 考慮上面的例子，一個請求須要 10 萬個特徵的參數，這些特徵被存儲在多臺機器上。即便忽略預測計算時間，要保證這個請求在 30ms 以內返回，那麼全部存儲參數的節點都必須在 30ms 以內返回結果。這就會出現木桶現象，任何一個存儲節點出現了超過 30ms 的響應延時，整體請求時間都必定會超過 30ms。這樣的存儲系統對請求排隊是接近 0 容忍的。但推薦場景又是一個高併發的場景，預測服務須要支持每秒上萬的用戶請求。 無量系統開發了一套分佈式模型預測服務，專門針對分佈式預測場景下高併發的模型參數請求的性能問題進行優化，實現對 TB 級模型的高併發預測服務支持。

5. 總結

隨着互聯網服務的發展，愈來愈精細和定製化的服務須要更好的模型支持，而超大規模預測模型已經成爲主流的解決方案。經過深度的研究與優化，無量系統開發了可以支持千億級參數模型訓練的高性能計算框架，並經過模型管理，模型預測服務，實現了超大規模模型的訓練，管理以及上線的全流程支持。 無量系統已經支持了 LR/FM/FFM/DNN 等多種經常使用模型，並在移動手機瀏覽器業務中實際使用和驗證，幫助業務取得了巨大的業務指標提高。無量系統將逐步擴展功能，好比正在探索的基於 GPU 的深度學習技術，以覆蓋更多的現有業務場景以及最新的 AI 類應用場景，爲業務的進一步提高提供強大的系統支持。

做者介紹

袁鐿博士，騰訊科技有限公司高級研究員

參考文獻

[1] Hidden Technical Debt in Machine Learning Systems, Google. In NIPS'15

[2] Wide & Deep Learning for Recommender Systems, Google 2016

[3] 常見計算廣告點擊率預估算法總結 https://cloud.tencent.com/developer/article/1005915

[4] 深度學習在 CTR 預估中的應用 mp.weixin.qq.com/s/CMZHhxAMn…

[5] Solving the stragglerproblem with bounded staleness. In HotOS (2013).

[6] TernGrad: Ternary Gradients to Reduce Communication in Distributed Deep Learning

[7] Deep Gradient Compression: Reducing the Communication Bandwidth for Distributed Training