在點擊率 CTR（Click Through Rate）預估算法的推薦場景中使用 TensorFlow Serving 熱更新較大模型時會出現短暫的延時毛刺，導致業務側超時，降低算法效果，為了解決這個問題，愛奇藝深度學習平臺團隊經過多個階段的優化實踐，最后對 TF Serving 和 TensorFlow 的源碼進行深入優化，將模型熱更新時的毛刺現象解決，本文將分享 TensorFlow Serving 的優化細節，希望對大家有幫助。

背景介紹

TensorFlow Serving是谷歌開源的用來部署機器學習模型的高性能推理系統。它主要具備如下特點：

同時支持 gRPC 和 HTTP 接口

支持多模型，多版本

支持模型熱更新和版本切換

TensorFlow Serving
https://github.com/tensorflow/serving

愛奇藝深度學習平臺上大量的 CTR 推薦類業務使用 TensorFlow Serving 來部署線上推理服務。

CTR 類業務對線上服務的可持續性要求很高，如果模型升級時要中斷服務是不可接受的，因此 TF Serving 的模型熱更新功能對這樣的業務場景提供了很大的幫助，可以避免重啟容器來做模型升級。

但是，隨著業務對模型更新實時性的要求越來越高，我們發現，模型熱更新時出現的短暫客戶端請求超時現象（稱之為毛刺現象）變成進一步提升實時性的一個比較大的障礙。

模型更新時的毛刺現象

先來看一下，

什么是模型更新時的毛刺現象？

下面這張圖是我們在 TF Serving 代碼中增加了 Bvar(https://github.com/apache/incubator-brpc/blob/master/docs/cn/bvar.md) 來查看內部請求的延遲情況。圖中是延遲的分位比，延遲分位值分別為 [p80, p90, p99, p999]，單位是微秒。

從圖中可以看到，在模型更新前后，p999的延遲都在 30ms以下。但是，在模型更新的瞬間，p999延遲突然抖動到 120ms+，持續了大概 10 秒時間，這就是毛刺現象，反應到客戶端就是會產生請求超時失敗。

為了完全解決這個問題，愛奇藝深度學習平臺經過多個階段的深入優化，最后將模型更新時的毛刺現象解決。

TF Serving 的模型更新過程

工欲善其事必先利其器，我們先來看看 TF Serving 內部的模型更新過程。

如上圖，Source會啟動一個線程來不斷查看模型文件，然后將發現的新模型構建相應的 Servable 數據結構放到 Aspired Versions 的隊列中去。

DynamicManager也會啟動一個線程，來不斷查看 Aspired Versions隊列是否有需要處理的請求，根據配置的 Version Policy 來執行模型更新策略，最后通過 SessionBundle來執行模型的加載和卸載。

Version Policy 默認為 AvailabilityPreservingPolicy，該 policy 的特點是當有新的模型加入時，會保證至少有一個可服務的模型版本，當新版本加載完成后，再卸載舊版本，這樣可以最大程度的保證模型的可服務性。

舉例子來講，如果只支持一個模型版本，當前版本是 2，如果有新的版本 3 加入，那么會先加載版本 3，然后再卸載版本 2。

接下來，詳細看一下 TF Serving 的模型加載過程，主要分成以下幾個步驟：

創建一個 DirectSession

將模型的 Graph 加載到 Session 中

執行 Graph 中的 Restore Op 來將變量從模型中讀取到內存

執行 Graph 中的 Init Op 做相關的模型初始化

如果配置了 Warmup，執行 Warmup 操作，通過定義好的樣本來預熱模型

TensorFlow 的模型執行有個非常顯著的特點是 lazy initialization，也就是如果沒有 Warmup，當 TF Serving 加載完模型，其實只是加載了 Graph 和變量，Graph 中的 OP 其實并沒有做初始化，只有當客戶端第一次發請求過來時，才會開始初始化 OP。

問題的初步優化

從上面的分析來看，可以看到初步的解決方案，那就是做模型的 Warmup，具體方案如下：

配置模型 Warmup，在模型目錄中增加 tf_serving_warmup_requests 文件

使用獨立線程來做模型的加載和卸載操作，配置 num_unload_threads和 num_load_threads

模型如何做 Warmup 詳細請參考 TF 的文檔 SavedModel Warmup。

https://tensorflow.google.cn/tfx/serving/saved_model_warmup

第二項優化主要是參考美團的文章基于 TensorFlow Serving 的深度學習在線預估。

https://tech.meituan.com/2018/10/11/tfserving-improve.html

我們來對比一下優化前后的區別：

可以看到，使用上面的優化，抖動的延遲減少了幾個數量級，效果很明顯。

問題的進一步優化

雖然上面的優化將模型更新時的毛刺降低到只有 120ms+，但是這個仍然會對客戶端的請求產生超時現象，如果模型更新的頻率不高，比如一天更新一次，那么基本上是可以接受的。

但是，如果業務對模型更新的實時性到一個小時以內，甚至更高，那么就必須進一步解決毛刺問題。我們不得不繼續思考，剩下的這個毛刺是由于什么原因產生的？

TF Serving 是一個計算密集型的服務，對可能產生影響的因素，我們做了如下猜測：

計算原因：是不是新模型的初始化，包括 Warmup 的計算，影響了推理請求？

內存原因：是不是模型更新過程中的內存分配或釋放產生鎖而導致的？

或者兩者都有？

計算原因分析

先來分析一下計算方面的原因，如果模型加載會影響到推理請求，那么能不能將模型的加載也用獨立的線程來做？

經過調研 TF Serving 的源碼，我們發現了這樣的參數，原來 TF 已經考慮到這樣的因素。

// If set, session run calls use a separate threadpool for restore and init // ops as part of loading the session-bundle. The value of this field should // correspond to the index of the tensorflow::ThreadPoolOptionProto defined as // part of session_config.session_inter_op_thread_pool. google.protobuf.Int32Value session_run_load_threadpool_index = 4;

通過配置 session_inter_op_thread_pool并設置 session_run_load_threadpool_index可以將模型的初始化放在獨立的線程。

修改配置后，并做了相關驗證，如下圖。

驗證的結論很遺憾，使用獨立的線程來處理模型初始化并不能緩解毛刺問題。

從而，進一步分析了 TF Serving 的線程機制，發現計算部分主要集中在 TF 的 Inter 和 Intra Op 線程，在模型初始化線程獨立出來后，原來的推理請求基本不會被影響到。

另外，經過分析還發現，TF 在執行 Restore Op 的時候會創建額外的線程池來恢復大的變量，于是嘗試將 Restore 時的線程池去掉，發現仍然沒有效果。

內存原因分析

先來看一下 TF 內存的分配機制，TF 的 GPU 顯存是通過 BFC (best-fit with coalescing) 算法來分配的，CPU 內存分配是直接調用底層 glibc ptmalloc2 的 memory allocation。

目前平臺上 CTR 類業務基本都是 CPU 推理，因此內存的分配和釋放都是通過 glibc ptmalloc2 來管理的。

經過調研了解到，Linux glibc 的內存管理也是經過優化的，原來的實現是 dlmalloc，對多線程的支持并不好，現在的 ptmalloc2 是優化后支持了多線程。

如果要深入到 ptmalloc2 優化內存管理就比較麻煩，不過調研發現已經有了開源的優化方案，那就是谷歌的 Tcmalloc和 Facebook 的 Jemalloc。

Tcmalloc
http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

Jemalloc
http://jemalloc.net/

Ptmalloc，Tcmalloc 和 Jemalloc 的優缺點網上有很多分析的文章，都指出 Tcmalloc 和 Jemalloc 在多線程環境下有比較好的性能，大體從原理上來講是區分大小內存塊的分配，各個線程有自己內存分配區域，減少鎖競爭。

對比試驗了三個內存分配器，實驗結果如下圖：

從實驗結果來看，Tcmalloc 和 Jemalloc 對毛刺都有比較好的緩解，但是 Tcmalloc 會增加正常情況下的 p999 延遲；而反觀 Jemalloc 的毛刺 p999 降到了 50ms 以下，正常情況下的 p999 比 Ptmalloc也有所優化。

看起來 Jemalloc 是一個相對比較理想的方案，不過在進一步的試驗中發現，如果同時更新兩個版本，Jemalloc 的 p999 毛刺會達到近 60ms，并且更新后會有一個比較長的延遲抖動期，會持續近一分鐘時間，如下圖：

優化到這一步，如果對這樣的延遲變化不敏感的話，基本就可以用 Jemalloc 來做為方案上線了，但對這樣的效果仍覺得不是非常理想，因此進行了更深入的優化。

問題的最終深入優化

上面內存方案的優化效果提供了一個很好的啟示和方向，毛刺的根本原因應該在內存的分配和釋放競爭上，所以來進一步分析 TF 的內存分配。

TF 內存分配和釋放的使用場景主要分成兩個部分：

一部分是模型 Restore 時變量本身 Tensor 的分配，這個是在加載模型時分配的，內存的釋放是在模型被卸載的時候

一部分是 RPC 請求時網絡前向計算時的中間輸出Tensor 內存分配，在請求處理結束后就被釋放

模型更新時，新模型加載時的 Restore OP 有大量的內存被分配，舊模型被卸載時的有很多對象被析構，大量內存被釋放。

而這個過程中，RPC 請求沒有中斷，這個時候兩者的內存分配和釋放會產生沖突和競爭關系。

因此設計了內存分配隔離方案：

將模型本身參數的內存分配和 RPC 請求過程中的內存分配隔離開來，讓它們的分配和釋放在不同的內存空間。

結合模型的更新，線上模型一個容器里面最多就兩個版本的模型文件，給每個模型版本各自分配了獨立的內存池，用來做 AB 切換。

在代碼的編寫上，TF 剛好有一個現成的 BFC 內存分配器，利用 BFC 做模型參數的內存分配器，RPC 請求的內存分配仍然使用 glibc ptmalloc2 來統一分配，因此最后的設計是這樣：

代碼改動主要在 TF 的源碼，主要是對 ProcessState，ThreadPoolDevice和 Allocator做了一些改動。

最后來看一下試驗效果：

從圖中，可以看到模型更新后，延遲抖動很少，大約在 2ms，在實際的線上測試高峰期大概有 5ms 的抖動，滿足業務需求。

總結

本文介紹了愛奇藝深度學習平臺對 TF Serving 毛刺問題的優化，主要歸納如下：

配置模型 Warmup 文件來初預熱模型

使用 Jemalloc 做內存分配優化

TF 模型參數分配和 RPC 請求內存分配分離

經過實踐，每個方法都有進一步的優化，最后基本解決了模型熱更新過程中的毛刺問題。

— 參考文獻 —

1. TF ServingAarchtecture

https://github.com/tensorflow/serving/blob/master/tensorflow_serving/g3doc/architecture.md

2. BVar

https://github.com/apache/incubator-brpc/blob/master/docs/cn/bvar.md

3. TF WarmUp

https://tensorflow.google.cn/tfx/serving/saved_model_warmup

4. 美團基于 TensorFlow Serving 的深度學習在線預估

https://tech.meituan.com/2018/10/11/tfserving-improve.html

5. Google Tcmalloc

http://goog-perftools.sourceforge.net/doc/tcmalloc.html

6. Facebook Jemalloc: http://jemalloc.net/

責任編輯：xj

原文標題：社區分享 | TensorFlow Serving 模型更新毛刺的完全優化實踐

文章出處：【微信公眾號：TensorFlow】歡迎添加關注！文章轉載請注明出處。